John McCain’s pick for VP, Sarah Palin, knows a thing or two about retrieving evidence from a computer. The mainstream reporting calls her a “hacker” because she is able to retrieve files from the Windows recycle bin.

The Anchorage Daily News reports back in September 2004:

Sarah Palin never thought of herself as an investigator. Yet there she was, hacking uncomfortably into Randy Ruedrich’s computer, looking for evidence that the state Republican Party boss had broken the state ethics law while a member of the Alaska Oil & Gas Conservation Commission.

The next week, when Palin went back to work at the AOGCC, she noticed that Ruedrich had removed his pictures from the walls and the personal effects from his desk. But as she and an AOGCC technician worked their way around his computer password at the behest of an assistant attorney general in Fairbanks, they found his cleanup had not extended to his electronic files.

The technician “said it looked like he tried to delete this, but she knew a way to go around and get some of the deleted stuff,” Palin said in an interview. “I didn’t know what I was looking for, but I was there.”

And this is how Salon reports the same incident:

“In a neat symbolic fit, the agent responsible for Alaska’s current moment of reform and modernization is a woman, a breed once nearly as rare in far Northwest politics as a Democrat. Sarah Palin, a libertarian and hockey mom from the fast-growing suburbs of Anchorage, began her political career — as an appointed member of the state’s Oil and Gas Commission — by hacking into the computer of another commissioner, Randy Ruedrich, chairman of the Alaska Republican Party. Palin was seeking the evidence that she would eventually use to charge him with an improper relationship with lobbyists. (Ruedrich would later settle state ethics charges against him by paying a $12,000 fine.)”

Is this where the McCain administration is going to get their computer security expertise? She’s not a security expert but it is nice to see someone at the level of state govenor who knows their way around a computer.

One of my old L0pht collegues, Peiter “Mudge” Zatko, is featured in Mass High Tech today in an article titled Bay State hackers find security holes in defibrillators, RFID.

Hackers getting a free T pass may be the least of our worries — local hackers-turned-security experts suggest RFID keycards, wireless networks and medical devices implanted in the body are also vulnerable to hacks.

At last week’s Defcon hacker convention in Las Vegas, a team of researchers showed it was possible to get information such as Social Security numbers and medical diagnoses, and change the settings on an implantable defibrillator by impersonating the computer it communicates with wirelessly. By doing so, a hacker could send a fatal shock to a patient’s heart, said William Maisel of the Beth Israel Deaconess Medical Center.

It is almost like things haven’t changed since the 90’s when the L0pht worked to change the mindset of security:

1. Don’t trust vendor claims around security
2. Attacks aren’t “theoretical”
3. Security by obscurity is no security

The L0pht worked as an independent security research think tank. For us it was non-profit side job researching and publishing vulnerabilities in software and hardware. We did it for our love of technology and published what we found out because purchasers and users of the vulnerable systems deserve to know.

It’s 10 years later and the situation hasn’t improved much. Mudge talks about the vulnerabilities the L0pht found in highway transponder systems that are still in systems being fielded today. But more important than the vulnerabilities themselves is the nature of how these vulnerabilities are coming to light. They are being found by hobbyists, students, and IT people working in their spare time. How can something as important as the security of public fare collection systems and medical equipment not have a standard process for security acceptance testing?

As we become more reliant on digital systems, with some even keeping us alive, it is high time for security testing to move beyond student papers and part time IT work. Security testing needs to become a formal part of the process of purchasing and fielding digital systems. Our lives are starting to depend on it.

Earlier today, the US District Court dealt a victory to the MBTA hackers and the EFF, lifting the injunction issued on August 9th to prevent the three MIT students from presenting their findings at DEFCON 16. In summary:

The lawsuit claimed that the students’ planned presentation would violate the Computer Fraud and Abuse Act (CFAA) by enabling others to defraud the MBTA of transit fares. A different federal judge, meeting in a special Saturday session, ordered the trio not to disclose for ten days any information that could be used by others to get free subway rides.

“The judge today correctly found that it was unlikely that the CFAA would apply to security researchers giving an academic talk,” said EFF Staff Attorney Marcia Hofmann. “A presentation at a security conference is not some sort of computer intrusion. It’s protected speech and vital to the free flow of information about computer security vulnerabilities. Silencing researchers does not improve security — the vulnerability was there before the students discovered it and would remain in place regardless of whether the students publicly discussed it or not.”

This sets a good precedent for future cases, and perhaps next time a similar situation arises, a judge will not be so quick to issue a gag order. It’s not a happy ending yet though, as the original lawsuit is still in effect.

As Chris Wysopal pointed out last week, the MBTA’s ire is misdirected. Rather than suing the vendor who sold them the defective system, they sued and attempted to silence the students who discovered the weakness. This is 2008, not 1988 — did they honestly think a gag order would prevent the information from reaching the general public? The DEFCON presentation was already available on the Intertubes prior to the injunction being issued, and the MBTA attorneys included a copy of the confidential whitepaper with their filing, thereby making it public.

I guess you wouldn’t expect that a transit authority would have paid any attention to the Ciscogate fiasco from a few years ago. That presentation never got out either, did it? All that taxpayer money the MBTA spent on ridiculous lawsuits and restraining orders could have been put toward fixing the security flaws. What a concept.

A lot of the focus of the MBTA vs MIT case has been discussion of the CharlieCards. These are MiFare classic cards which have been known to be broken earlier this year. There is also a paper disposable card called the CharlieTicket that uses a magnetic stripe. The MIT students presentation states that these are cloneable and forgeable using a $150 magnetic stripe reader/writer.

From the Confidential Memo Prepared for the MBTA which was publicly disclosed by the MBTA is court filing:

This seems to break all the rules of integrity of sensitive data storage. How could someone store money on a magnetic stripe in 2008 and not store an identifier that references the account in a central database?

The tickets do have a unique identifier generated when the card is initially purchased so a fraud detection system could be in place or is planned. But this would require tracking the value on the ticket or the usage of the ticket centrally so it isn’t clear why the value is stored on the card in the first place.

There are so many question about the security of this public system. Fraud costs the Massachusetts taxpayer money and refitting an insecure, ill-designed system costs the Massachusetts taxpayer money. [Disclosure: I am a Massachusetts taxpayer.]

It should be a requirement that the current system or the (hopefully) upgraded system be tested by an independent organization that specializes in cryptosystems. If the independent testing uncovers vulnerabilities, they need to be fixed before the system is fielded. Then the system should be retested to verify the fixes. Once the system is deemed secure by an independent organization, a summary of the test document should be published for public inspection. It should include the types of testing conducted and the results.

The public trust requires inspection of taxpayer funded projects to make sure they meet acceptible standards and vendors held responsible for deficiencies. Projects that use computers and software should not get a free pass. It will be interesting to see if the CharlieTicket system is ever held up to public scrutiny.

A hearing will be held in Boston tomorrow to decide whether or not the restraining order gagging the MIT students from talking about the vulnerabilities they have found should be lifted. Even though the Defcon presentation is widely available and the MBTA disclosed the “Confidential” memo from the MIT students in their court filings, they are seeking a permanent speech injunction. An august group of computer scientists has signed a letter which will be entered into the record for the case. This list includes: Dave Farber of Carnegie Mellon University, Steve Bellovin from Columbia University, David Wagner from UC Berkeley, Dan Wallach from Rice University, Matt Blaze from the University of Pennsylvania, and Bruce Schneier. An excerpt:

We write to express our firm belief that research on security vulnerabilities, and the sensible publication of the results of the research, are critical for scientific advancement, public safety and a robust market for secure technologies. Generally speaking, the norm in our field is that researchers take reasonable steps to protect the individuals using the systems studied. We understand that the student researchers took such steps with regard to their research, notably by planning not to present a critical element of a flaw they found. They did this so that their audience would be unable to exploit the security flaws they uncovered. . . .

The restraining order at issue in this case also fosters a dangerous information imbalance. In this case, for example, it allows the vendors of the technology and the MBTA to claim greater efficacy and security than their products warrant, then use the law to silence those who would reveal the technologies’ flaws. In this case, the law gives the public a false sense of security, achieved through law, not technical effectiveness. Preventing researchers from discussing a technology’s vulnerabilities does not make them go away - in fact, it may exacerbate them as more people and institutions use and come to rely upon the illusory protection. Yet the commercial purveyors of such technologies often do not want truthful discussions of their products’ flaws, and will likely withhold the prior approval or deny researchers access for testing if the law supports that effort. . . .

Yet at the same time that researchers need to act responsibly, vendors should not be granted complete control of the publication of such information, as it appears MBTA sought here. As noted above, vendors and users of such technologies often have an incentive to hide the flaws in the system rather than come clean with the public and take the steps necessary to remedy them. Thus, while researchers often refrain from publishing the technical details necessary to exploit the flaw, a legal ban on discussion of security flaws, such as that contained in the temporary restraining order, is especially troubling.

It will be interesting to see what arguments the MBTA uses to keep the students from speaking on a topic where all the important vulnerability information seems to have already disclosed. Sure the students haven’t presented a cookbook exploit tool but they have also stated they have no intention of doing so.

Perhaps the court will investigate what the MBTA’s and their technology vendors response has been to the MiFare card vulnerabilities that were disclosed responsibly. If there has been no vigorous response to responsibly disclosed vulnerabilities of many months ago how can they say with a straight face that are truly responding to new security information and just need more time.

Another BlackHat has come and gone. As usual, it was a very busy week juggling customer meetings, recruiting, conference planning, vendor parties, and, oh yes, the actual BlackHat presentations. I had a fantastic time catching up with old friends and finally getting the opportunity to meet more of the Security Twits and others in the security community. I didn’t submit a talk this year, but nevertheless, fake Dan Kaminsky was still excited to see me.

My favorite talk, as expected, was the Sotirov/Dowd talk on How To Impress Girls With Browser Memory Protection Bypasses. The attack is a conceptually simple, yet completely reliable technique for exploiting vulnerabilities in web browsers. Of course, the media has sensationalized the impact of their findings, but ultimately, this is still significant as far as browser-based exploits are concerned (here is a more accurate report). It’s worth mentioning that part of the technique allowing them to load a .NET DLL at an arbitrary location under Vista was reliant on an implementation bug wherein the OS disables ASLR if the version in the .NET COR header was below a certain value. However, the address space spraying and stack spraying techniques are likely to be extended to other platforms utilizing similar memory protection mechanisms.

As for the girls? I can report first-hand that the ladies at TAO on Wednesday night were hanging on Alex’s every word. They were particularly impressed when he whipped out the laptop for a live demo. Unfortunately, none of the dozen iPhone owners in the immediate vicinity thought to snap a picture (too busy Twittering). Oh well.

I also enjoyed Hovav Shacham’s talk on return-oriented programming. Simply put, he described a generalization of the return-to-libc shellcode approach with the intent to demonstrate that one could achieve Turing-complete computation using “found code” in process images. By chaining together series of mini-computations ending in return (RET) instructions, it was possible to build higher-level programming constructs such as branches and loops. The nature of the x86 instruction set provides some flexibility because instructions are interpreted differently depending on how you align the instruction pointer (i.e. the old shellcode trick of searching the process image for any JMP EBX instruction and using that as your EIP). In RISC architectures such as SPARC, however, you don’t have that luxury; if your %pc isn’t aligned properly you get a bus error. So it was quite interesting to see that they were able to extend the concept to RISC. The practicality of the attack technique is limited by the fact that the shellcode is tuned to a particular binary image — if the shellcode was built using instructions extrapolated from glibc 2.3.5, it won’t work for a system running glibc 2.4.

I thought Scott Stender’s talk on Concurrency Attacks in Web Applications was interesting as well. In a nutshell, spewing thousands of simultaneous requests at web application transactions that are not thread-safe can create interesting problems. In the presentation, Scott ran his demo against a VM running on the attack machine. I found myself wondering how effective the same attack would be over the Internet — would it be significantly less reliable (or not at all)? Race conditions are generally easier to exploit locally than remotely due to more predictable execution conditions. Certainly this is an under-tested vulnerability class though.

One presentation I wasn’t able to attend but want to follow up on is Nate McFeters, John Heasman, and Rob Carter’s talk which discussed the GIFAR attack I’ve been hearing so much about lately. The gist is that you can create a file that is both a valid GIF and a valid JAR, then use some Java applet tricks to initiate HTTP requests on behalf of the victim.

Finally, the Pwnie Awards didn’t fail to disappoint. Drama ensued over the Most Overhyped award, but at least this year some of the winners showed up to claim their awards! Halvar rapping Symantec lyrics was also quite memorable.

All in all, a fun and informative week, but as usual, I was relieved to get the hell out of Vegas and head home on Friday morning.

P.S. For a much more entertaining BlackHat/Defcon Recap, read Jennifer Jabbusch’s account of the week’s events. It’s my favorite one so far!

It sure seems like the CharlieCard, which is used by the Boston subway system, has a serious security weakness. The MBTA has sued 3 MIT students to stop them from giving a planned talk at DEFCON.

Doesn’t this seem backwards to you? Shouldn’t the MBTA be suing the vendor who sold them the flawed system? Security problems go away by mandating independant security testing before a product is accepted, not by trying to get security researchers to be quiet. This is a good example of how the reactive approach doesn’t work. The flaws are still in the system and suing researchers has just shined a bright light on them.

Update 08/09/2008 6:00pm EST:

The EFF is appealing the injunction which is blocking the students from speaking about the results of their testing.

A telling quote from Kurt Opsahl, staff attorney at the EFF gets to the heart of the issue:

“Courts have found that the First Amendment covers these things. We believe that this is a protected speech activity. When you discuss security issues, if you are telling the truth, that is something that should be protected.”

Apparently the MBTA has known about this problem since at least March, 2008 when a graduate student from the University of Virginia announced he was able to break the encryption system.

The U of VA researcher gave an interview where he described why security by obscurity is not a valid security approach for a cryptosystem:

Q: What are your thoughts on security by obscurity? Is NXP using this method of protection?

A: Security-through-obscurity hardly ever works. The lack of proper peer-review often even hurts the security of the system. Our Mifare work discovered several vulnerabilities that could be fixed without increasing the cost of the cards. NXP did for a long time rely on obscurity for the security of some of their products, but now decided against this outdated design approach and instead bases the security of newer RFID cards on publicly scrutinized cryptography and independent evaluations.

Q: Can you explain “Kerckhoffs Principle” and why it applies to your work?

A: Kerchoff, who lived in the 19th century, observed that keeping anything secret is really hard. So instead of relying on the secrecy of your whole system, it would a lot easier to only rely on the secrecy of a small secret key. Security systems should hence be publicly known and analyzed, and only the key should be secret. When properly realised for RFID cards, Kerchoff’s principle means that by analyzing their own cards, thieves cannot compromise your cards. This is contrary to our Mifare work, where we only analyzed a few copies of the the secret algorithm that is found in all cards and were consequently able affect the security of all the other billion cards out there.

The MBTA not only accepted a security system which relied on security by obscurity but once accepting this flawed model must try to maintain this obscurity with the court system.

The documents detailing the presentation are here.

Three French journalists have been booted for life from Black Hat and Defcon for compromising the Black Hat press room wired network and grabbing the credentials for at least one reporter. Their goal was to publicize the risks to reporters especially current given the massive reporter presence in Bejing for the Olympics. This risk is certainly real and it is a shame that these journalists had to compromise and embarass one of their own and potentially run afoul of US Federal wiretap laws.

Sniffing, or monitoring all traffic on a network, is so 1999. That is when L0pht came out with AntiSniff, which could detect many scenarios where someone was sniffing a wired network. How can we be using plain text authentication protocols in 2008? It is a well known and easily solved problem. But people authenticate in clear text everyday when they log into social networking or blogs or other “unimportant” applications. The problem is when they use those same credentials for work or online banking.

We need to think of any application that alows users to authenticate in the clear as broken. If 3 journalists can monitor passwords, anyone can.

Update 08/08/2008 12:30pm EST:

It turns out the attack was likely a MITM attack where the attackers ran their own DHCP server and handed out a gateway IP that was controlled by them. At least one reporter was connecting to his organization’s content management system over unencrypted HTTP and got his password compromised. More details in “How eWeek Got Hacked at Black Hat.”

I’m not talking shipping as in boats, but shipping as in packages. David Maynor is giving a talk at Black Hat on his newest experiment: using a small and cheap WiFi platform that is remotely accessible over a WAN perform WiFi surveillance inside of a package delivered right to your victim. Guess what the cheap platform is? An iPhone of course. George Ou has some pictures and more details in his blog posting, The iPhone wireless LAN Ownage in a Box.

This new remote WiFi attack is particularly timely as a new indictment of 11 for ID theft of over 100 Million credit cards (watch video to see Veracode’s CEO) was handed down this week. Guess how they got in? They used War Driving to get on insecure internal WiFi networks and then used the internal access to install sniffing software. The attackers were mostly from foriegn countries and the companies attacked in the US. So at some point someone must have been in the country to physically scan the networks.

David Maynor’s WarShipping trick solves this “need to be there” problem to do wireless attacks. Why travel and risk being physically apprehended when you can just mail a package with a WiFi and WAN enabled device and just hack remotely?

We will have to see how insecure these businesses that need to be PCI compliant are now that this massive WiFi attack has been made public. I find it takes a widely publicized attack of your organization or a close peer to actually get many security problems fixed. I bet some retailer’s IT departments started scambling after this was made public.

Attackers like to keep updating their methods just ahead of compliance requirements. Sometimes I think that becoming compliant is protecting yourself from last year’s attack due to the lag time between attacks becoming prevelant, compliance standards changing, and then organizations making security updates to meet complaince.

With application security we may already be a little behind. PCI requirement 6.6 kicked in June 2008 and requires organizations handling credit card data to audit their applications for the vulnerability classes outlined in OWASP Top Ten 2004 (yes, note the lag time). I fear a 100 Million ID theft scale compromise is still looming using application security attacks.

Here’s the rest of my list:

10:00-11:00 FX, Developments in Cisco IOS Forensics.

11:15-12:30 Oliver Friedrichs, Threats to the 2008 Presidential Election (and more).

13:45-15:00 Option 1: Scott Stender, Concurrency Attacks in Web Applications. Option 2: Travis Goodspeed, Side-channel Timing Attacks on MSP430 Microcontroller Firmware.

15:15-16:30 Option 1: Alexander Sotirov and Mark Dowd, How To Impress Girls With Browser Memory Protection Bypasses. Option 2: Karsten Nohl, Mifare - Little Security, Despite Obscurity. This is one of the toughest time slots as you also have McFeters/Carter/Heasman and Grossman/Evans in the lineup. Choices, choices.

16:45-18:00 Option 1: Bruce Dang, Methods for Understanding Targeted Attacks with Office Documents. Option 2: Christopher Tarnovsky, Inducing Momentary Faults Within Secure Smartcards/Microcontrollers.

Lots of intriguing hardware talks on Day 2. A lot of it is probably over my head and my first options are more applicable to my day job. There might have to be some room hopping.

I fly out to Vegas tonight — see you all there!