0

Conficker Mostly a Dud

Posted at April 6, 2009

After tons of breathless media coverage about how April 1st might be the latest “cyber-catastrophe,” the date has come and gone and… nothing happened.

There was, admittedly, some cause for concern.  With 250,000 known machines infected with Conficker.C (and estimates of the full number of infected machines as high as 15 million before antivirus software started knocking them out,) activation of the worm would have created the world’s largest botnet overnight, far surpassing the Storm Worm’s 120,000-machine network.  It would have the power to bring down pretty much any target on the Internet at will, at least for a short time.  People feared that it would be turned against some critical infrastructure target (e.g. the root DNS servers) or major commercial site and bring down the Internet.

And that threat… is still there.  April 1st was only the first day Conficker.C could have been activated — not the only day.  Those infected machines are all out there, still polling for their master every day.  While the mitigations that have been put in place at many domain registrars will greatly reduce its impact, the fact remains that it would still be a huge botnet, not to mention that it could execute arbitrary code on any of the infected machines.  (If you’re worried you might be infected, just check out the rather-ingenious Conficker Eye Chart.)  But with the security industry aware of the threat, chances are that most of the machines that try to “call home” will not find anything listening on the other side, even if the worm’s authors do try to activate it.

If they’re smart, they probably won’t activate it at all.  Since botnet controllers constantly try to steal each other’s botnets, modern worms contain code to ensure that only the author can take control.  In the case of Conficker, this defense is actually very strong — orders for the worm have to be cryptographically signed, using a public-key algorithm.  On one hand, this means no one but the worm’s actual authors can give it orders — but on the other hand, it leaves them holding a smoking gun.  Only the worm’s authors can possibly have the private key that creates the signatures Conficker looks for — which means that possession of that key is all but proof of authorship (and thus of a very serious crime.)  Having such a trail pointing at them may prevent them from trying to use it at all, especially since the domain-registration algorithm has been cracked and domain registrars are monitoring attempted registrations for anyone trying to register a name that Conficker will eventually look for.

Overall, the response to the Conficker worm is another success story for the security industry.  There’s a paper about containing the worm over at the Honeynet Project that makes for good reading.  This said, it also points to the problem with the “detect-and-patch” model of computer security — this could have been much worse.  If the original Conficker variants had been as sophisticated as the C variant, and the worm activated on February 1st instead of April 1st, we would have had a very different story.

attacks, industry
1

Exploiting Public Information for Stock Manipulation

Posted at September 14, 2008

Last Wednesday, 9/10, United Airlines saw its stock drop by over 75% in fifteen minutes, over a mistaken news story that came across the Bloomberg business wire announcing that it had filed for bankruptcy.  How this happened has interesting implications for security.

Back on December 10th, 2002, United Airlines really did file for bankruptcy.  It was all over the news, their stock plummeted, they went into reorganization (Chapter 11), and eventually emerged as a going concern.  it wasn’t a good thing for most involved, but it was over and done with.

Many online newspapers have archives of old stories that can be browsed.  The Florida Sun-Sentinel is no exception; it’s a pretty typical newspaper.  Online newspapers also often have dynamic lists of links — “Most Popular,” “Most Active,” etc., based on what articles have been read lately.  For some reason, which we may never know, the 12/10/2002 article somehow made it onto one of the lists.  Maybe it was a slow day and a couple people happened to click on it in rapid succession and it bubbled up to the list, and once it was there people started clicking on it (as the story would be pretty big news if it weren’t six years old.)  Whatever the cause, a link to this old story found its way onto the homepage — Tribune Co. says it was “due to traffic volume,” which I think lends credence to the “a few people clicked on a slow news day” theory, though it could have been deliberate, which I’ll get to later.

News aggregators, the most popular being Google News, crawl reputable news sources like online newspapers for interesting stories, then bump them up or down on their pages based on how popular they turn out to be.  Since this was on the Sun-Sentinel’s homepage, and probably their RSS feeds as well, the Googlebot pulled it up.  However, the Sun-Sentinel’s page did not list a dateline for the story — so, lacking any other information, the Googlebot concluded it was new; this is not unreasonable for something suddenly showing up on the front page of a newspaper.  Google News published the article in their aggregator with a dateline of 9/10/08.

People started reading the article, and that pushed it up in the rankings.  Soon, UAL’s bankruptcy was a top story on Google News, which is read by millions.  Some of those readers included stock analysts, one of whom proceeded to put the “news” on the Bloomberg wire, the primary source of breaking news used on Wall Street.  On one hand, it seems foolish of him, and this was probably a career-limiting move.  But on the other hand, Google linked him to the web site of a legitimate newspaper owned by Tribune Co. — he didn’t exactly read this on “hot-stock-picker.ru” or something; why would he doubt its veracity?  It was clearly a professionally-written news article in a major newspaper (or at least a minor paper from a major publisher.)

Wall Street today bears little resemblance to its history before the late 1980s, when “program trades” started.  Program trades are basically what they sound like — computer programs set to execute trades when certain conditions are met.  There were apparently a decent number of program trades set to dump UAL stock upon getting bad news about it over the Bloomberg wire, and they did just that.  UAL, as a mid-cap company with very high volatility, was quite heavily held by hedge funds, who are very heavy users of program trades.  Large, institutional investors — including hedge funds, perhaps especially hedge funds — limit their risk by having standing “stop-loss orders” on large positions.  These are orders to sell the entire position should its share price fall below a certain floor.  The hedge fund selling based on the news was enough to send the stock price down across a few stop-loss orders — and their selling sent it through more, and so on.  The stock dropped 79% in 15 minutes, eradicating literally billions of dollars in shareholder value.  At that point, the exchange stepped in and froze the stock, halting any further trading (as well as the runaway program trades.)

Once people figured out what was going on, the stock was bid back up to $10 again (about 85% of its original value.)  A lot of people ended up upset with Bloomberg, and Google, and the Sun-Sentinel, but there’s no one to sue — the Sun-Sentinel didn’t do anything wrong (they didn’t republish the story or try to call attention to it, it just sat in its archives like it had for the last six years), and the newswires and aggregators aren’t liable for checking the accuracy of things they link to.

What I found interesting, though, is the implications this has for deliberate manipulation.  This appears to have been an accident, but what if someone were to set out to do this on purpose?  All they would need is to find a newspaper or other reputable news source that doesn’t have reliable datelines on all their stories, then pick a stock that has recovered from old bad news or plummeted after old good news — just something where the news, if new, would affect the price substantially.  Rather than waiting for the story to coincidentally rise to the top, a botnet or set of proxies could bid the story up to “most popular” quite quickly.  The attacker would just have to keep it there long enough to be picked up by aggregators.

Essentially, this person would have tomorrow’s news today, and could trade on it.  (Well, really it’s yesterday’s news, but they’d know it before everyone else “knew” it.)  If you were doing this intentially to UAL, you’d first buy put options and short-sell the stock, in anticipation of the sudden drop.  Once it dropped 50%, you’d unwind those positions and start buying — after all, once the error is discovered, the stock will mostly revert to its original value.  It’s not even clear that this sort of manipulation would be illegal — the attacker isn’t a fiduciary, and can’t be charged with insider trading or most securities violations.  Federal law is fuzzy enough that prosecutors can sometimes find a way to charge just about any person with a crime if they really want to, but this would be quite difficult to prove.  It’s not like lots of people don’t hold put options and short sales on volatile, risky companies like UAL, and reversing the position after a big drop would hardly make you alone among traders.  Making 5-10 times their investment on something like this would not be difficult if it worked.

The interesting part about this is that it doesn’t involve an “attack” in the traditional sense.  There’s no cross-site scripting or SQL injection, no stealing of confidential data.  Nothing is involved but clicking on an old news story a few dozen times, and being positioned in the market such that the resulting chaos works to your advantage.  It’s even possible that this did happen with UAL, and the companies involved don’t want to talk about it, for fear of giving people ideas.

attacks, legal
1

DefCon 16, Day 1

Posted at August 24, 2008

Having finished up with the BlackHat briefings, it was time to go on to DefCon.  While many of the speakers from BlackHat stay on for DefCon, there’s also a lot of DefCon-only presentations, usually with a more attack-oriented focus (in keeping with DefCon’s nature as a hacker convention rather than a security conference like BlackHat.)

The day began with Hacking E.S.P. (Educational Software Packages.)  Schools, by their nature, have sensitive PII data — transcripts, schedules, billing information, etc.  A lot of this data is either stored directly in web-based educational software used by students, or is stored in other systems students access… probably with the same password.  Overall, though, this was a pretty typical application service provider hacking presentation — many of the schools they investigated used the same software on their sites, and that software was often woefully bad: Passwords sent “encrypted” in Base64 encoding — and not even that if JavaScript is turned off.  Trivial session stealing via Hamster-style sidejacking, with the added bonus that the Session ID is set before login so you can steal a session ID then wait for someone to use it.  Copious cross-site scripting vulnerabilities to allow for cookie stealing.

Generally someone would have to have a login on such a system to be able to exploit these things.  However, the username/password scheme is often helpfully revealed on the front page, and some schools even allow you to create your own account on the system. Google showed 34,000 instances of this one flawed software package alone.  Considering as schools account for 34% of data breaches, this sort of buggy software is probably commonplace.

The second presentation I attended was about Adobe local shared objects.  In short, these are Flash cookies.  Just as your browser will store small data items (cookies) for a website, and return those items to the website when asked, Adobe Flash has a similar mechanism for Flash applets.  However, since these are stored by Flash and not by the browser, your browser doesn’t manage them — there is no indication to the user what data is being stored, and the data is not removed when you delete cookies or “private data” in your browser.  Ad networks have used these to “back up” your cookies — if you delete them, they are restored from a Flash local shared object when you next visit a site with the ads on it.  These are also hard to filter for systems like Privoxy and other anonymizers, because Flash uses a proprietary encoding for its XML RPC calls, in which the local shared objects are embedded.

On the bright side, there is a Flash applet on the Adobe site called Flash Settings Manager that will let you delete these objects and put in settings to manage them.  On the not-so-bright-side, this is in-band signaling (i.e. Flash is configured by a Flash applet), so any advertiser can override your settings later.  Also, as you may recall from the RIA presentation at Black Hat that I discussed earlier, there are a lot of other local storage mechanisms besides this one in Flash — Silverlight, HTML 5, and other frameworks also have local storage that is outside your browsers’ ability to manage.

I next attended a presentation about vulnerabilities in TOR, the onion-routing anonymity provider originally developed by the Department of the Navy and until recently maintained by the EFF.  TOR has become quite popular, at this point containing 1,500 relays and 200,000 users.  However, over the last several years, it’s seen several vulnerabilities that have threatened the anonymity it provides:

There are still some outstanding issues in TOR:

So, with all these problems in TOR, does that mean we shouldn’t use it?  Not at all!  The known vulnerabiliites currently outstanding would apply to any low-latency mix network.  They’re not bugs in TOR, they’re limitations in this approach to anonymity, which remains better than any other approach to anonymity known.  TOR isn’t perfect, it’s just better than everything else.  Now, there may be better approaches to specific problems (e.g. there is one particular adversary you want to hide from, not just people in general), but for general anonymity, you still can’t beat TOR, even with its flaws.

I unfortunately missed much of strace and RSnake’s presentation on Google Gadgets.  In short, gadgets are pieces of HTML and JavaScript code hosted on third-party sites and brought into a Google-owned namespace.  Though this namespace doesn’t have direct access to Google cookies, the fact remains that it’s loading unknown JavaScript onto a Google page — it’s basically XSS-by-design.  Gadgets can communicate with or post to other users and gadgets on Google, and it turns out to be pretty easy to sneakily force a user to install a gadget onto their Google homepage.  If someone could crack a server hosting a trusted gadget, they could take control of the data of many Google users simultaneously.  Most of these vulnerabilities would apply to any gadget-based architecture, such as the Live start page, or Facebook’s apps, too.

The next presentation I attended was “Satan is on my Friends List,” about attacking social networks.  In short, social networks are full of promiscuous and pervasive trust relationships, which results in a large number of business logic flaws.  These attacks aren’t on code vulnerabilities like SQL injection, but rather just exploiting how the systems work.

Sites often don’t protect “non-sensitive” operations, like logging out or adding friends, from XSRF attacks.  Thus, it’s possible to craft comments that log out anyone who views them… which makes it rather hard to delete them (since you have to be logged in to delete a comment.)  XSRFs can be put into image links, meta refresh tags, IFRAMEs, etc.

In addition, social networks are ideal platforms for social engineering attacks.  Build a plausible profile for someone else using social and public sources, and then friend a few dozen people who are known to friend everyone right back to build a “respectable” number of connections.  Joing groups, and start friending real associates of the person being impersonated.  At that point, you have a web site that can be used to confirm your identity as someone else.

The Facebook and OpenSocial APIs for integrated social apps are also good avenues for attack.  They have convenient APIs and execute arbitrary code by design — the social networks don’t care about application malware, as it’s on a second domain and they’re legally protected by their EULA.  However, if you widely distribute an app based on some current meme, get hundreds of users, then replace that app in-place with malware, you have an instant social network botnet.  You can use them as open redirects, put phishing items on their social network page, etc.  Also, applications have all the access that friends do — just the data disclosure may be enough for identity theft, impersonation, or at least some minor mayhem.  They can publish to a user’s profile to infect others, too.

Unfortunately, the fixes for these issues are just what the social network sites don’t want to hear — less external content, reduced API functionality, no opt-in security models, review and lifetimes for applications, etc.  Thus, these vulnerabilities are probably here to stay.

The last presentation I attended was by Errata Security, about interesting penetration tests.  Modern penetration tests are “supposed to be boring” — they’re often done for the purpose of meeting compliance objectives, so companies are mostly interested in meeting a checklist, not in security.  They want to be secure against likely attacks and “script kiddies,” but are not interested in making the kinds of expensive changes required to defend against a determined, well-funded adversary.  The main exceptions are government agencies and Wall Street, who know they’re the targets for those determined adversaries.

Maynor & Graham walked through a couple of interesting things they did as part of penetration testing.  One of these involved hacking the well-firewalled network of a company that was based at a secure facility, one where they could not simply walk onto the premises.  Instead, the wired an iPhone to a UPS battery and put it into the original iPhone packaging, then mailed it to the company.  With a UPS battery, an iPhone can run for 5 straight days with the WiFi on.  They modified the phone to add tcpdump and APlogger, and added a cron job that would send an SSH tunnel out to their computers every hour over the AT&T EDGE connection.  The result was a WiFi sniffer & endpoint inside the “secure facility” from which they could scan the internal network and run Metasploit to break into things.  An iPhone, after jailbreak has been run, is essentially a tiny BSD box — a perfectly suitable hacking platform.  Who thinks about their network being hacked by a cardboard box in the mailroom?

They also built a better phishing site.  Even security-aware people who are looking for phishing sites look for a valid SSL certificate bound to the site and signed by a trusted authority.  However, all it takes to get a real SSL certificate signed is about $2,700.  Start a business, register with Dun & Bradstreet to get a credit rating, then apply for a real certificate from VeriSign or Thawte.  You can even sign ActiveX controls and require users to install them as a “secuirty feature.”  Since so many banks and companies outsource their applications or their HR and IT infrastructure, a phishing site with a good certificate is often indistinguishable from an outsourced site.  Just send someone at the comapany an email saying that the company has changed 401(k) providers, and they need to go to this outsourced site and sign up.

As is customary with DefCon, there wasn’t much talk about how to prevent these vulnerabilities.  However, it gives you something to think about, and it’s often very hard to guard against clever attacks against business logic flaws.  There’s no substitute for good threat modeling and flexible thinking.

anonymity, attacks, crypto, networks, physical security
2

BlackHat 2008, Day 2

Posted at August 13, 2008

The second day of BlackHat 2008 began with a keynote speech by Rod Beckstrom, the director of NCSC (the National Cyber Security Center.) Most of this consisted of painfully strained Civil War analogies and the overuse of the word “Cyber” to describe absolutely everything. He made some good points — specifically, that in order to truly solve information (er, “Cyber”) security problems, we have to know the desired end state, which is more than just fixing the exploits or vulnerabilities of the week. We don’t even fully understand the physics and economics of networks, security, and risk management. The economics of security has to be based around risk management — if the marginal cost of a security measure exceeds the marginal loss it prevents, it’s counterproductive (something the government seems to often miss when it comes to “national security” anti-terrorism measures.) He seemed overly worried about the IP protocol stack as a single point of failure, and wants to keep it out of the systems it’s currently out of (say, SMS, which works even when most of the cell network is down.) I find this overly alarmist mainly because the IP protocol stack has been constantly attacked and exhaustively examined for nearly thirty years, and even the hackers have pretty much given up on this sort of attack. Yes, a successful exploit of the IP stack that let you, say, reroute, modify, or destroy traffic would be catastrophic on the same scale as Kaminsky’s DNS attacks of the last month, but so would an asteroid strike — the potential impact is huge, but the likelihood is very low.

All that said, I wouldn’t argue for IP-izing currently-working non-IP networks like SMS, either. There’s simply no reason to.

Next, Arian Evans of WhiteHat security spoke on web application canonicalization, encoding, and transcoding attacks. This was one of the more interesting (and personally useful) talks of the conference for me. Web application vulnerabilities fall into two categories — syntax vulnerabilities, which fork code-paths, like SQL injection, cross-site scripting, etc., and semantic issues, consisting of errors in business logic. Syntax issues are normally fought by signature-based methods like IDS/IPS, WAFs (Web Application Firewalls), and XML firewalls. However, encoding syntax attacks can cause them to bypass these defenses.

Internationalized websites often require encoding and code page transitions in order to work. In addition, developers use encodings for type safety. An attacker can take advantage of these to get a syntax attack to its target:

  1. Choose a vulnerability you want to exploit (e.g. XSS, SQL Injection)
  2. Identify the parser on the target (browser, database, application, etc.)
  3. Identify the supported encodings, codepages, and character sets on the target
  4. Identify intermediate interpreters between you and the target that canonicalize alternative encodings, such as web browsers, web application firewalls, proxies, or other applications
  5. Encode your attack such that it will be parsed in the desired way by the target after being canonicalized by all the intermediaaries

This results in complex nested encodings, such as encoding SQL with the CHAR/CHR functions, then decimal encoding that, then URI encoding that result. The resultant mess goes right past IDS/IPS, but each interpreter strips off a layer of encoding, and when the payload finally reaches the target, it is interpreted property and works. More sophisticated, internationalized apps are often easier to hit, because you have more options for submitting encoded (in another codepage) metacharacters that are later transcoded by the applications.

The solutions offered for this were the usual — strong data typing, strong output encoding (to prevent XSS), and enforcing the code/data boundary whenever possible (which isn’t often when it comes to web apps.) Still, this is very good stuff for demonstrating a SQL injection or XSS vulnerability to a business manager who insists that it’s not really exploitable.

Next, Ivan Buetler gave a presentation on smart cards, specifically the security of APDU, the Application Protocol Data Unit. Smart cards are mass-produced by a few companies, then sent out to companies or agencies that want to use them for security. The buyer initializes them with software and policy, then gives them to a user, who personalizes them with specific keys (often under the guidance of their employer.) Software from the manufacturer can be used to initialize or personalize cards. This demo used the Axalto Access Client, specifically the COVE and CMS administration tools.

The card itself enforces PIN policies and (sometimes) generates keys. During initialization, applets (written in Java and converted to a smart card bytecode) are uploaded to the card to add functionality. The upload, and all communication with the card, is done in APDU codes. These are laid out in the ISO 7816 specification, but there are many vendor extensions, which tend to be poorly documented — so many that the ISO spec is almost useless in reading APDU. However, it’s a simple command structure — a command consists of a class byte, an instruction byte, two 1-byte parameters, a data length, and a variable-length data field (and of course a checksum.) Ivan used an app called Smart Card Toolkit Pro 13.4.2 (I can find no reference to it on the Internet other than offers to pirate or crack it) to sniff the communication with the cards and read the APDUs. He also developed his own tools to hook winscard.dll so as to add himself to the stream as a man in the middle and be able to modify APDUs (and thus send arbitrary commands to the card.)

This revealed some significant vulnerabilities. For instance, during initialization, a card can be set to either generate its own keys, or to accept keys being uploaded as-is. However, this is “enforced” by the card later telling the personalization software that it would like to generate its own keys. It’s a classic trusted-client scenario; if you modify the APDUs, the application can be convinced to ignore the card’s settings, and the card takes whatever the app sends. Lacking any APDU documentation, Ivan was only able to find a few settings like this, but if the designers of the Axalto smart card system think that’s an acceptable practice, there are probably many more.

Scott Stender of iSec Partners spoke next, about concurrency attacks in web applications. This started out with an explanation of multiprocessing (in short, on any given core, two things that execute “simultaneously” don’t really — they alternate really fast, which means that they do execute in an order, and you can’t always predict what that order is.) This would have been a more interesting talk to me had I not spent years debugging crazy stress and performance issues in the past — I’m quite familiar with concurrency and race conditions.

With web applications, web app frameworks like .NET and Java Struts define an interface that contains request context (e.g. cookies, local variables, session variables.) Access to shared resources needs to be protected, but since web access is asynchronous, threads sometimes find themselves working with dirty or stale data. The classic example is a bank – imagine a money transfer process like this:

  1. Collect source account number, destination account number, source account balance, destination account balance, and amount to transfer.
  2. Verify that the source account balance exceeds the amount to transfer.
  3. Set the destination account balance to its former balance plus the amount transferred, and set the source account balance to its former balance minus the amount transferred.

Seems perfectly sane. Now imagine that I put in a request to transfer my entire balance, then while that request is between steps 2 and 3, I start another request to transfer my entire balance, and it completes steps 1 and 2 before the first request resumes at 3. With multiprocessing this is quite possible — and it would result in my transferring twice as much money as I have (and likely without even having a negative source account balance.)

Concurrency flaws allow manipulating stateful assets (like the above bank accounts) or changing security parameters (like auth credentials or single-use redemption tokens such as gift certificate codes.)

The solution is well-established in the database world — transactions. Transactions are atomic, concurrent, isolated, and durable (the so-called “ACID test”) — a transaction succeeds or fails as a single unit (no part of it happens unless all of it happens), and none of the resources in a transaction may be touched until the transaction is complete. Web apps can implement their own transactions, or use the transactional support of their underlying database architecture. The important part is that there is some kind of end-to-end scoped lock (and global locks — that is, eliminating multiprocessing altogether and just doing one thing at a time — are both impractical for performance and lead to deadlocks.)

Concurrency flaws can be found in testing pretty easily — run load/stress tests and check for discrepancies afterwards. Usually something will show up. You can also add test hooks that encourage context changes to increase the likelihood of finding something. Scott also promised to upload his own tool, SyncTest, here in the coming weeks.

Jeremiah Grossman and Arian Evans also presented “Making Money on the Web the Black Hat Way.” This was all about business logic flaws, and the way they’ve been exploited to help underhanded people make tons of money without exploiting traditional “bugs” at all. These included:

  1. Creating artificial scarcity in ticket sales for events via denial of service. When you consider purchasing tickets, the site “reserves” them for a short time until you choose to purchase or not. Since it costs nothing to reserve tickets for a few minutes… one person can reserve a lot of tickets.
  2. Breaking CAPTCHAs for spammers. Some have terribly flawed implementations (e.g. the correct answer in a hidden field, or the image name), while others can be recognized by OCR software. Keep in mind that if OCR can read the CAPTCHA even 10% of the time, it’s “broken” — and it’s hard to make something that a computer can’t read even one time in ten that a human can still read. Also, there’s the Mechanical Turk solution — disguise CAPTCHA-solving as a “game” (usually one with porn as a prize) or just pay people overseas to solve them at low rates.
  3. Various overseas companies offer “password recovery” services, that will tell you “your” password for a small fee, usually $30-$150. Basically, they just guess those horrible cognitive password questions (“What was your first car? Who was your favorite teacher?”)
  4. Coupon fraud. Electronic coupons sometimes have predictable numbers, and some offers allow many coupons per order. Some people have bought over $150,000 of stuff with these coupons.
  5. Gaming micro-deposits. When you set up an electronic transfer, the bank will sometimes send you a small deposit (less than $1), which you then tell them the amount of to verify account ownership. Michael Largent opened 58,000 brokerage accounts and collected these payments. It’s not illegal under any normal financial law — the bank is sending you a gift. However, he got charged under the USA PATRIOT Act for using fake names (58,000 of them.) This is a really dubious charge (who uses a fake name on the Internet? Oh, that’s right, everybody), but that’s par for the course in Federal law.
  6. Application service provider bank robbery. Small banks don’t really make and run their own web sites — they buy a standard “banking product” from an application service provider. Some of these are really, really bad – the example one Grossman showed had no authorization. Once you logged in as a user, you could transfer money to and from any user so long as you knew the right account numbers (which other bugs in the site were very helpful in providing to you.) Crack an ASP, and you don’t just get to rob a bank, you get to rob many banks.
  7. Slow order cancellation. QVC, the popular shopping channel, was apparently not very good at canceling orders. One woman started to order something, then canceled the order at the last step, and received the order anyway. Finding this interesting, she tried it again. And again, and again, until she’d received $412,000 in QVC merchandise and sold it on eBay. According to law, if you are sent merchandise you did not order you’re entitled to keep it as a free gift. She’d probably been able to keep doing it for years, too, if QVC hadn’t caught on because she sold the items on eBay still in their QVC packaging. Ah, criminals are always so entertaining.
  8. Affiliate scams. People take advantage of affiliate offers in a host of ways. The most common are cookie-stuffing methods — rather than getting people to click links to affiliate sites like they’re supposed to, sneaky affiliates will embed links to the affiliate sites (often dozens or hundreds of offers) in IMG or IFRAME tags. Now whenever someone buys anything online the affiliate gets a check. They avoid referrer fields with SSL pages (or META REFRESH, or several other techniques.) Some get much more devious, with DNS rebinding, GIFAR, Flash malware, or other techniques. However, the affiliate networks can catch all this, because people sent to affiliate sites by such scams convert at a much lower rate (nearly zero) than those who clicked through to the site on purpose. This said, while people are caught constantly, apparently there is no evidence that anyone has ever been sued or charged over this sort of activity — it’s in a legal grey area where it’s not clear what, if anything, to charge them with.
  9. Trading on semi-public information. BusinessWire (a popular place to post press releases for business) had a forceful browsing vulnerability — press releases that had been uploaded but not officially released were stored at publicly-accessible URLs and just not linked to the home page. When someone found out, they started reading tomorrow’s news today and making stock trades on it. They made $8 million. A federal judge declared that they did not violate SEC regulations, because they had no insider privilege or fiduciary duty to the company — they were trading on nonpublic information, but no one who was forbidden to give it to them gave it to them. They could still be prosecuted for hacking, maybe (is typing a URL directly to a page and not following a link trail “hacking”?). but that’s hard to prove if you’re remotely careful — usually we catch hackers by following the money to them, Al Capone style. If the money is legal, and you have to catch them for the technical exploit, that’s hard.

The moral of the story: business logic flaws are serious money, possibly much more than the syntax flaws we spend so much time worrying about. Test everywhere, profile users, detect leaks and aberrant behavior.

The final presentation of the day that I attended was one by Michael Slaviero and Haroon Meer of SensePost on getting data out of protected networks.

Long ago, once someone compromised a machine, they could simply enable a shell on some port, then telnet in. However, firewalls stopped that, so they began to do reverse tunneling with ssh and netcat (as well as more custom software like tcpr and fport.) Outbound filtering stopped that, too, and so we got web shells — pieces of ASP/ASP.NET/PHP/whatever-the-web-server-runs code that could be uploaded into a webroot and would provide remote control facilities and file transfers. However, there are now a host of mechanisms available for tunneling data out of a compromised machine.

For one, XP’s IPv6 support can be used as a port proxy. The netsh command can set up a proxy such that one port on one (internet-accessible) machine is redirected to a different port on another (internal, behind the firewall) machine. Thus, one compromised edge machine can provide direct network access to any machine it can reach on any port. The ssh -L and -R can be used to similar effect on UNIX hosts. This is a great reason for defense in depth — if an edge machine is owned, the firewall as a source of protection is largely eliminated.

There is also DNS2TCP. If an attacker can get this onto a compromised machine, it allows full 2-way tunneling of arbitrary TCP over DNS — the one protocol that is allowed everywhere. Once again, this bypasses the firewall. SensePost also demonstrated their own app (glenn.jsp) which encoded TCP over well-formed HTTP POST via base64 encoding. This is not just sending arbitrary traffic over port 80 (where an application-layer firewall will block it) — it’s true, valid HTTP requests against a real web page on the server, tunneling arbitrary TCP.

So with an edge web server under the attacker’s control, the firewall is bypassed in several ways, and your network is open to the attacker. But what if the attacker uses SQL Injection to get in? Then instead of a web server, they have a back-end SQL server with (hopefully) no access to the Internet, and thus no way to upload DNS2TCP or reach glenn.jsp. Well, it turns out that there are other ways that operate only on SQL.

Squeeza is an advanced SQL Injection tool. It separates content generation from return channel — you can have it return output via HTTP errors, via DNS tunneling (entirely in SQL!), or even via a blind timing channel (which is hideously slow — over a hundred milliseconds per bit — but works.) You can send all sorts of content through it — profile the version of the server, use existing OLE objects on the server in the server’s context (such as to write a working portscanner entirely in SQL), or (in many cases) take control of the machine.

SQL Server 2005 was the first SDL-developed version of SQL Server, and was intended to be far more secure by default than previous versions of SQL Server (which had over 1,000 stored procs enabled by default.) However, SQL Server is by its nature very hard to secure — it is very public, very capable, and highly targeted. What’s more, new features sell while better security doesn’t — so while most things are disabled by default, SQL 2005 has more “things” than ever before.

The downfall of a compromised SQL Server is in-band signaling. SQL Server’s configuration is controlled by stored procedures within SQL Server — so if you’ve gained sa access on a SQL Server, you can just turn all the disabled services back on. This includes the dreaded xp_cmdshell stored procedure (which runs shell commands as the server.) Using the new web service integration, you can write new SOAP endpoints entirely within SQL and place them on arbitrary ports — enable batch mode on those endpoints and they’ll allow running arbitrary SQL (thus getting you out of having to tunnel over DNS or use blind timing to get data out.) And if you enable the CLR, you can run arbitrary .NET code in the server (subject to CAS restrictions — unless you’re running as sa, in which case there are no restrictions at all.)

There are several interesting ways to get your arbitrary .NET apps onto the server. You can order the server to load them directly from a UNC path — if the server has outbound access to your server, which is unlikely. However, you can write SQL that creates the assembly in memory from raw hex and loads it. You leave no trace on the disk, and run arbitrary code.

All this talk really tells you from a defender’s perspective is the importance of defense in depth. A compromise of either the web server or the database server essentially takes down the firewall from the attacker’s perspective — they can reach anything the server can, and can run port sweeps to find out what’s within reach. Thus, it’s vital to do several things:

  1. Run the web server and database server with least privilege. The attacker can’t get more access than the servers themselves have — both services should be running with only the minimal privilege required to perform their function. Web servers should only have access to the web root — and most importantly, only read access. Databases should never be accessed as sa — only as an account with execute access to needed stored procs and select access to needed tables. Don’t let a database INSERT or UPDATE — use stored procs for that.
  2. Segment your network securely. The web server shouldn’t be able to hit any IPs or ports that it doesn’t actually need to hit to serve web pages. Likewise with the database server. Both inbound and outbound filtering is important.

Overall, it was a great conference, and there was a lot of good information handed out.  I’ll be posting a recap of DefCon 16 over the next few days as well (once I have a chance to boil a notebook full of notes down to an intelligible post.)

SOA/XML, attacks, legal, mitigations, trusted client
1

BlackHat 2008, Day 1

Posted at August 6, 2008

Today was the first day of this year’s BlackHat Briefings in Las Vegas. The biggest security conference of the year, it’s always an interesting place to be and often involves the release of new and previously unknown exploits.

The keynote speaker was Ian Angell, of the London School of Economics, who was speaking, ostensibly, about risk. He is described as having “very radical and constructive” views on the subject. His primary point was that when you put together a bunch of parts into a system, it often goes off the rails — every action leads not just to a reaction, but a loop wherein the unintended consequences feedback into themselves. This makes control very difficult (he brought up Goodhart’s Law, “any observed statistical regularity will tend to collapse when pressure is placed on it for control purposes.) The IT industry is obsessed with providing more information, but omnipresent computer screens distract and cause errors in judgment — people come to rely entirely on the system, suspending independent thought and just blindly following the machine, while simultaneously missing details in the information overload.

Humans are obsessed with categorization — the attempt to treat the similar as identical. We deal with complexity by dropping less-significant relationships from our mental models — but those relationships still exist, and this creates uncertainty and risk. Not just computer systems have this problem; bureaucracy is the most effective way to deal with normal situations, but as anyone who has dealt with one knows, it is terrible at dealing with anything out of the ordinary.

However, for all this, I found Professor Angell basically useless. He’s comes across as very smart and amusing, but he points out problems without the slightest inkling of a solution. Yes, systems create complexity, from which comes risk. Shall we then abandon IT security in favor of a hunter-gatherer society? I don’t think I could get an answer on that from him.

The next presentation was by Billy Rios and Nitesh Dhanjani on the phishing culture and community. They observed some phishing code and noticed common strings, and thought to do a Google search on them with the intent of finding other places that phishing code was in use. Instead, they found thousands of credit card numbers, SSNs, and other identity information all over the Internet, in public forums, searchable on Google. The phishers throw around identities constantly, just to prove their authenticity. Meanwhile, they phish each other constantly — most of the phishing kits they found had back-doors in them or secret code to email a copy of all identities captured to their author. They’re not hackers at all; they generally know just enough to upload a kit someone else wrote to a site someone else hacked and collect the information. Also, ironically, the Google anti-malware blacklist turns out to be a fantastic way to find already-hacked sites to put phishing kits on — it’s full of Administrative logins and passwords.

This was followed by Dan Kaminsky’s DNS update, which I’m going to discuss in a separate post; for all its hype, I think it lived up to it. Faulty DNS is a Really Bad Thing.

Michael Ossmann had a presentation to give on software radio and the future of wireless security. Unfortunately, it was long on software radio and short on security. He mostly spoke about the USRP, a piece of open-source hardware (also available pre-built for $700) that gives full software radio capabilities to a PC. It can capture a significant amount of bandwidth in a range up into the 2.4 GHz band. Ossmann’s demonstration of this involved doing packet-capture on Project 25 radios, and a replay attack on a remote-control toy. Essentially, command-line tools can capture radio on most frequencies, and then (as it’s just a bitstream) DSP techniques can manipulate it arbitrarily.

While his speech had very little about security in it, the implications are significant in the long term. Making a good radio means either using very expensive analog components, or using cheap analog components and a lot of CPU power. In a few years, “a lot of CPU power” will be available on your phone, just given the rate at which CPUs improve. Wireless (802.11) security didn’t become a big issue as soon as it was possible to crack WEP (i.e. almost instantly) — it became a big issue when wireless cards with raw packet injection and monitor mode started to be cheap and ubiquitous. Wireless hacking takes a $700 USRP now; it’ll take a cell phone in 5 years (since as CPUs get more powerful, software radio gets cheaper than hardware, it’s only a matter of time until radios in phones and such are pure software, and thus reprogrammable.) You can see the beginning of this in THC’s GSM Project. If the cell phone network finds itself, security-wise, as badly off as 802.11 is today, it could be a frightening thing.

Alex Stamos and company from iSec Partners had a presentation on Rich Internet Application frameworks.  Rich Internet Applications aren’t well-defined, but they contain one or more of the following: AJAX UIs, local storage, an offline mode, running outside the browser, access to hardware resources, or the general appearance of a thick-client app.  Adobe, Microsoft, and others have created various apps and tools to help developers create these rich web apps.

Adobe AIR is the most full-featured of them — an AIR application runs in a full desktop runtime based on Flash.  There’s no sandboxing — a locally-installed AIR app has the full powers of the user, like an ActiveX control.  You can develop them in Flash, Flex, or JavaScript.  However, AIR apps can be launched from the web by ordinary Flash files (assuming the app is already installed on your computer.)  There is a remote mode, for running directly off the web with reduced privileges, but there’s a method for communicating and even passing objects between the local (full-trust) and remote modes.  Overall, it’s a scary thing, in the way that EXEs are scary (i.e. it’s insecure, but not any more insecure than everything else.)

Microsoft’s Silverlight is rather more restricted; it’s closer to Flash than to AIR.  Silverlight apps can be written in XAML with any .NET language, and use a scaled-down .NET runtime.  There is socket support, like Flash, but it is limited to certain sockets (4502-4534) and requires a policy file (clientaccesspolicy.xml) on the target server, even if the target server is the same site it came from.

Google Gears is even less functional than Flash and Silverlight; it’s essentially running HTML and JavaScript from the local machine.  There is local storage, and data sync with an API and SQLite for relational-database-like storage.  Also, it has the ability to run processes in a threadpool outside the browser, so as not to get shut down by the browsers’ tight-loop detection.  Bizarrely, it allows the app author to customize the installation warning dialog, making it quite easy to convince people to install weird Gears apps.  It would be good for distributed malware, like cryptanalysis.

Yahoo! Browser Plus is designed to make it easy to write browser plugins, which is kind of like making it easy to make bombs.  There are some things that shouldn’t be easy, because the less of them, the better, and browser plugins (almost all of which seem to be adware/spyware) are one of them.  BrowserPlus add-ons are initialized by an HTTP call to Yahoo!, and run with full trust.  It’s like ActveX with a built-in Ruby interpreter (an old, buggy one, even.)

Finally, Mozilla Prism is a site-specific browser with the browser UI stripped off.  Formerly known as WebRunner, it’s used to “desktopize” web apps.  The risk here is comparitively low, though the script has XPCOM privileges (basically, control over the browser itself, like a Firefox extension would have.)

You can also just use HTML5 for some rich functionality, like local storage.  There is DOM storage, allowing you to persist up to 5MB of data locally, as well as SQLite-based database functionality.  DOM storage is essentially the ability to save immense cookies that are subject to SQL injection attacks.  The W3C has had better ideas.  Also, unlike cookies, you can’t easily turn DOM storage off (there’s a Firefox about:config setting, but nowhere in the UI.)  As mobile devices bundle Webkit browsers (like Safari), they’ll be subject to this type of storage — it would be pretty easy to DoS a mobile device by writing dozens of 5MB cookies.

So, what does all this lead to?  A host of new security issues we never had to think about before, of course!   The RIA data stores are vulnerable to XSS — if your email or other personal data is in an AIR or Gears app, and someone gets an XSS on the sites the apps come from, they can steal your entire data store.  You can have SQL injection against JavaScript now, thanks to SQLite databases.  The same Flash-based XSS attacks we’ve seen now work on Silverlight and AIR as well.

On the bright side, they had some good prescriptive guidance for app developers:

  1. Don’t use predictably-named data stores
  2. Parameterize SQL, even on local SQLite stores
  3. Domain-lock sites if possible
  4. Don’t use AIR when Flash/Flex/Silverlight/etc. will do fine
  5. Let users opt out of RIA functionality

Finally, Ty Miller had some shellcode to show us — reverse DNS tunnelling staged-loading shellcode, in fact.  The trend in vulnerabilities has been toward client-side exploits of late, now that socket-based servers have been hardened significantly.  However, if you do buffer-overflow a client app and get it to execute shellcode, the challenge is often getting a connection back to the attacker.  Clients are often behind firewalls, proxies, NATs, or all three.

Of the common shellcode techniques (port binding, callback, find-socket, address reuse, download & execute, and HTTP tunneling), only one (HTTP tunneling) works reliably with client apps — and Metasploit’s HTTP tunneling shellcode only works on IE6 with ActiveX enabled.  DNS tunneling (like Kaminsky’s OzymanDNS from 2004) would also get back — and even more reliably than HTTP, since it wouldn’t need to worry about authenticated proxies.

DNS gets through everything.  When you make a DNS request, it goes to your company or ISP’s DNS server, which forwards it on to a top-level server (like .com) and then to the DNS server that owns the domain name.  Practically everything makes DNS lookups (as Dan Kaminsky went into today), and nothing works if they’re blocked, so any computer is all but guaranteed to have DNS access.  With a malicious DNS server, you can actually tunnel arbitrary data through DNS.

Miller’s shellcode consisted of a tiny first stage which finds kernel32, creates pipes for STDIN and STDOUT, then makes an nslookup (yes, it shells out to nslookup) for a TXT record on the malicious DNS server.  The TXT record type can be extremely long, and the record it gets back contains the second-stage shellcode and a command to run.  The second stage shellcode runs the command, captures the output, and sends it back in fragmented DNS requests.  It then polls periodically for more commands to run.  The DNS requests all have a sequence number in them, guaranteeing that they don’t get cached and always get through.

He’s making his code available at projectshellcode.com, a site where he hopes to focus shellcode research and start a collection.  I think this is of dubious value (unlike exploits, shellcode is not really very useful to security folks on the “good guys’” side most of the time), but it’ll be interesting to take a look at what he’s come up with.

SOA/XML, attacks, hardware, industry, mitigations
Previous Page
Next Page