A “Clear” Case of Failure
Clear, the “trusted traveler” program that allowed customers to bypass airport security lines, has shut down. The story is an interesting case of bureaucratic disincentives and general failure around the whole mess known as airport security.
A privately-run alternative to the TSA’s Registered Traveller program, Clear started out with what seemed like a good idea — allow frequent travelers to undergo a thorough background check to make sure they weren’t terrorists or criminals in lieu of screening them every time they went to the airport. For someone who travels by air every week or even every day, the long-run time savings would be worth a fortune. The TSA was all for this idea, since their goal is to prevent hijackings, not just have people take off their shoes for fun. So Clear (originally called Verified Identity Pass) was started — and frequent travellers could pay $200 per year, have a background check performed on them, and get a nifty-looking smart card that they could use at any of a dozen major airports to skip to the front of the security screening line.
Wait a minute… skip to the front of the security screening line? Yep, somewhere along the line some government bureaucrat changed the rules such that Clear and Registered Traveller-certified people still have to undergo the screening, they just get to go to the front of the line. I can easily see their motivation for doing so. Imagine being an assistant director at the TSA in charge of such a program: “So, what happens if, God forbid, someone with a Clear card blows up a plane? What would we say to the public? ’Yeah, he had a bomb on him, but we didn’t search him, because he’d undergone a background check a couple years ago. You see, he’d never blown up any aircraft before, so we had no idea this would happen.’” It would go even worse for the TSA if said terrorist were a member of a group that the public would consider an “obvious” terrorist suspect (e.g. a Muslim of Arabic descent) and would pretty certainly end the careers of everyone involed in the program, if not end the TSA itself.
So the Clear card was changed to only allow you to skip the line, while still undergoing the full security screening. What no one seems to have thought of, though, is… why bother with the background check? If you still have to be screened at the airport, what’s the point of having to be investigated to get the card? In what way does the screening line contribute to security? Many of these same airports let members of airlines’ top-tier frequent flyer clubs skip the line, too, and they’re not required to have background checks. Essentially, Clear and Registered Traveller simply morphed into HOT lanes — pay a fee, and you get to go faster than people who don’t pay a fee. It’s not “trusted” status, it’s “VIP” status. A smart card with associated fingerprint and iris scans seems kind of excessive for jumping a line.
Also, Bruce Schneier brings up an interesting point — now that Clear is out of business and having all its assets transferred to creditors, what happens to all the personal data in the background checks? Who gets that asset?
False Expense Service Reveals the Trouble With Documents
There’s been some news coverage lately about FalseExpense.com, a service that produces fake receipts to order “for novelty use only.”
The obvious purpose of this is to help people scam their companies’ expense reporting system by “padding” receipts. People who are reimbursed for hotel, meals, etc. can create receipts for slightly more than they actually pay (or for that matter, create receipts for meals they skip altogether or eat a balogna sandwich for) and pocket the difference. Apparently the same company aims to help people rip off their employers in any way they desire, as they also run “Fake Sick Notes USA.” (Though people running that particular scam are often caught by their own actions.)
It’s interesting that receipts are considered “proof” of purchase. A receipt, after all, is just a piece of paper, and what’s more, there is no standard for what a receipt looks like. People know it should be printed on “receipt paper” — which is usually thin thermal paper, but is sometimes quite heavy paper tape that’s inkjet or impact printed — and contain certain pertinent data, like the location of the purchase, the tax, the total, and some legalese at the bottom. In the modern era, receipts often have serial numbers or bar codes on them, which makes the receipt uniquely identifiable by the issuer, but is quite useless for anyone else to authenticate them. After all, only someone who has access to Target’s computer system can say if Target receipt #824935729345 is authentic or not. And when it comes to small mom-and-pop retailers (which often have cash register receipts that contain literally nothing but prices) and online retailers (whose receipts are trivially-forged HTML emails), receipt as proof of anything becomes even more ridiculous.
All this false expense site does is make available to the general public an ability that’s been available to the tech-savvy for years. Someone with Photoshop and a USB thermal printer (easily available on eBay for under $100) has been able to forge receipts since the 1990s. This is another case (like checking accounts) where the “security” of a system comes not from any internal defense, but simply from the fact that most people don’t have a security mindset — most people don’t look at everyday systems and think about their weak points and where they break down. Since a recept is used as proof of purchase, people assume it is proof of purchase.
Unfortunately, there’s really not much to be done to “secure” receipts. To do so would require data-sharing between merchants, employers, and the IRS, so as to make receipt numbers authenticable — and that’s a case of the solution being worse than the disease (the privacy implications would be staggering.) As an employer, the best solution may be to simply avoid the problem — have the company book hotel and travel for the employee (rather than reimbursing after-the-fact), and provide a per diem allowance for expenses rather than reimbursing exact receipts. Any time you rely on receipts from employees, there’s the potential for fraud losses.
Conficker Mostly a Dud
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.
Exploiting Public Information for Stock Manipulation
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.
DefCon 16, Day 1
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:
- 2004: Error in how AES counter mode was used resulted in cryptography with only 16 bits of entropy.
- 2005: A relay cell length overflow could be used to force an exit node to send contents of memory
- 2005: Diffie-Hellman handshake bug in OpenSSL didn’t check for trivial keys, so a malicious entry node could mount a man-in-the-middle attack
- 2006: By running several fast TOR servers, an attacker could end up as both entry & exit node for a user, thus compromising anonymity and potentially finding hidden services. The fix for this was the addition of “entry guards” — trusted entry nodes that are re-used by users.
- 2006: Clients could create or extend channels even if server mode was turned off
- 2007: “Stable” or “Guard” status, normally applied to the top n nodes, could be stolen by malicious nodes by claiming high uptime and bandwidth. The fix for this was to put in thresholds above which a node always gets guard status, rather than making it a top n calculation.
- 2007: XSRF attacks by web sites could make use of the TOR control port
- 2008: Nodes could be made to connect to their own public IPs
- 2008: The Debian OpenSSL PRNG flaw compromised 300 of the 1,500 relay identity keys, and 3 of the 6 directory authority keys. If one more authority key had been compromised, someone could have taken control of the network
There are still some outstanding issues in TOR:
- You can build infinite-length circuits and use them as a DOS multiplier
- Snooping on exit relays works — if someone uses an insecure protocol that gives away their identity (like POP… or even HTTP depending on what they send), TOR won’t necessarily protect them. This isn’t a bug in TOR, but just the nature of what it does — no software package will give totally anonymous communication if the communication itself gives your identity to the recipient.
- People who run relays are unknowns — there is no way to know how many are malicious. However, TOR depends on having a large, diverse set of servers, so making more restrictions on who can run servers might actually lower, rather than raise, the network’s secuirty.
- Exit relays sometimes end up in restricted space (e.g. behind China’s firewall) — which means TOR users get restricted, too.
- Many users of TOR toggle it on and off during a single browser session. However, a JavaScript refresh attack on one of the non-TOR sessions can sometimes retrieve data from the previous TOR session.
- Firefox bugs leak data, and that data doesn’t go through TOR, since on Windows it works as an HTTP proxy. Users can work around this by proxying their entire network stack through a VPN connection like a JanusVM.
- It’s possible to block access to TOR. If an adversary (say, the Chinese government) filters out the directory authorities, the download site, and all the relays, it’s very hard to get on.
- If you can see both input and output (by running many, many nodes, or having a massive filtering apparatus at the Tier3 ISPs — FBI, maybe?) traffic confirmation is easy. (i.e. if I already suspect you, specifcially, of doing something, I can confirm you did it much more easily than I can “go fishing” for people doing unknown bad things.) Defensive dropping or adaptive packing would help with this, but would raise TOR’s latency.
- You can fingerprint websites based on the size & response time of the pages and tell what people are doing via traffic analysis.
- A congestion attack by a website can find TOR nodes, and coupled with latency analysis on routers, can find the person communicating.
- Data retention laws in many countries are resulting in data being stored that could make traffic analysis easier.
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.
