root labs rdist

July 31, 2008

Blackhat talk picks

Filed under: Security — Nate Lawson @ 1:16 pm

Inspired by Chris Eng, here is a list of Blackhat talks I will probably attend.  It’s frustrating to have so many talks in conflicting time slots while some times have almost none relevant to me.

Wednesday

Highway to Hell: Hacking Toll Systems (11:15 am).  As much as I’d like to see the other talks, someone has to present this one.  If you’re just getting into hardware hacking or wondering how to secure toll systems, please drop in.  Too bad I also have to miss Ilfak’s talk on adding a decompiler to IDA (watch out Veracode!)  Oh, and there was some DNS thing too.

Software Radio and the Future of Wireless Security (1:45 pm). After lunch, I’m interested in hearing more about software radio. I do most of my work by soldering directly to the logic side, bypassing any demodulation circuitry. Temporal Reverse Engineering looks interesting also.

Return-Oriented Programming: Exploits Without Code Injection (3:15 pm).  This should be good since I haven’t seen an exhaustive treatment of this approach.  I think the stack has been overlooked since NX became common.  But it can still control program flow even without executing directly from it.

Pwnie Awards (6 pm).  The Oscars without the speeches and with more embarassment.  Awesome.

Thursday

Developments in Cisco IOS Forensics (10 am). I can get up early to enjoy FX getting back into Cisco again.

Timing Attacks on the MSP430 Bootstrap Loader (1:45 pm).  The BSL sometimes gives access to the flash even if the JTAG fuse has been blown.  I’ve become familiar with the MSP430 due to this FasTrak research so this is quite relevant to me.

How To Impress Girls With Browser Memory Protection Bypasses or Mifare – Little Security, Despite Obscurity (3:15 pm). Augh, can’t decide: amusing heap fung shui or more updates on the CRYPTO1 train wreck. I’ll probably flip a coin.

Inducing Momentary Faults Within Secure Smartcards/Microcontrollers (4:45 pm).  Chris Tarnovsky is the leading silicon hacker.  You’d have to be crazy to miss this.

[Edit: added Travis Goodspeed's talk. I inadvertently left it out the first time]

July 21, 2008

DNS “novice” discovers secret flaw

Filed under: Security — Nate Lawson @ 12:19 pm

Being his usual humble self, Halvar casually discovers what I think is Dan Kaminsky’s DNS flaw.  The Register has a story that quotes me on this.  While I’m not certain it is the same attack, I’m moderately confident it is.

Note that neither Halvar nor I was part of the secret briefing Dan gave to researchers.  I didn’t receive that inside information and believe Halvar didn’t either.  This reinforces the perspective that information about a bug should be revealed quickly, given the likelihood that another party might rediscover it.  It’s possible a black hat hacker even beat Halvar, even though he’s very smart.

The debate about full or partial disclosure is really all about control.  In this case, the information about the patch (randomize source port and double check the randomization on TXID) was enough to independently rediscover the attack.  Even though there is not a direct connection between the attack and the patch, knowing that it was possible was enough.  Once the information was out there, Dan and the vendors had given up control.

So, patch your servers and back to business as usual…

Hacker or hooker?

Filed under: Hacking,Misc,Security,Software protection — Nate Lawson @ 6:00 am

Well-funded and motivated attackers are typically the hardest to defend against when designing a system.  Governments can attack systems in different ways and with more resources than a typical threat.  Consider a recent example where a British aide lost his Blackberry after spending the night with a woman who approached him in a Chinese disco.  While it’s possible he just lost it while drunk, this is a good example of how unconventional threats need to be carefully considered.

Let’s analyze the cost of two routes to getting this same information: hacker or hooker.  The hacker might try to crack passwords or develop a 0-day exploit against the Blackberry server.  Or, build a custom trojan and send it via a forged email that appears to come from the Prime Minister.  The hooker would try to get to his hotel room and steal the phone.  It would actually suffice to just borrow it for a few minutes and dump the RAM since passwords are often cached there.  This has the added advantage that he might never know anything had happened.

A 0-day exploit could be in the $20,000 range.  Hiring someone to develop and target a trojan at this aide would be less, but the chance of succeeding would be lower.  According to the stories about Eliot Spitzer, a high-end call girl is $1,500 per hour.  Assuming it takes four hours, the total cost would be $6,000.  The fact that both these approaches could be done in China means the actual cost would be lower but probably still a similar ratio.

There are a lot of other advantages to the hooker approach besides cost.  There is good deniability if the call girl gets caught.  Since the call girl remains within the attacking country’s jurisdiction, the police can be used to recover the Blackberry if she makes an extortion attempt.  The hacker approach has a lot more uncertainty as flaws could be patched or blocked, making the exploit useless.

I also think this gives good support to my claim that software protection techniques are on the verge of wider adoption.  With cold boot attacks and growing news of governments seizing laptops or stealing cell phones, systems must remain secure even when an attacker has physical possession of a powered-up device.  The only way to do this is to adopt software and hardware techniques that are already used to protect games, DRM, and satellite TV.  Traditional approaches like those used in network security are no longer enough.

I’ll be speaking on this topic along with Thomas Ptacek at WOOT, co-hosted at USENIX on July 28th in San Jose.  Since this event is invite-only, send me email if you’re a security researcher who would like to attend.  Please include a brief summary of your background.

July 15, 2008

Next Baysec: July 17th at Pete’s Tavern

Filed under: Security — Nate Lawson @ 9:56 pm

The next Baysec meeting is Thursday at Pete’s Tavern. Come out and meet fellow security people from all over the Bay Area.  As always, this is not a sponsored meeting, there is no agenda or speakers, and no RSVP is needed.  Thanks go to Ryan and Rick Wesson for planning all this.

See you on Thursday, July 17th, 7-11 pm.

Pete’s Tavern
128 King St. (at 2nd)
San Francisco

July 14, 2008

RFID industry tries to spin toll findings

Filed under: Crypto,Embedded,Hacking,Security — Nate Lawson @ 2:10 pm

I was interviewed today regarding my findings regarding the Fastrak electronic toll collection system.  It seems that the industry PR spin machine has already begun responding.

First, this article questions my credibility and claims that the Fastrak transponder is read-only.

‘If Lawson has not even established that FasTrak transponders are a read-only device (best called a “tag”) rather than read-write, then he’s totally unqualified to be talking about potential misuse.’

Apparently the author of the article has not even opened the cover on a Fastrak transponder.  They use an MSP430F1111A microcontroller, which is flash-based.  The firmware and all the data (i.e., your unique ID) are stored in flash.  I can easily authenticate this claim by revealing that your 32-bit ID appears at address 0×1002, which is part of the full “0×0001″ Title 21 response packet.

Also reverse engineering this device is hardly much of an accomplishment since all the specifications and protocols of Title 21 are open source.

The base specification for Title 21 is freely available, but the extensions to it are not.  On disassembling a firmware dump from a transponder, I found some surprising things, including messages that allow a reader to update the transponder flash in the field.  Again, I can back up this claim with the message IDs that start this update process: 0x00DE and 0×0480.  To unlock the update process, you need to provide a global key that I will not reveal.

Second, I’ve heard that a vendor plans to issue a press release.  Expect the standard claims that privacy is protected because they “encrypt” your unique ID in their database and data is not retained for very long.  What they mean by “encrypt” is “replace each unique ID with a different one”.  The problem is, replacing the unique ID “CAR-A” with “WXYZ” does not change much.  There is still a unique ID that is stored which always corresponds to the same car, enabling tracking.  Somehow, that information is subject to subpoena, something few Fastrak users are aware of.  Corporations issue privacy policies describing exactly what information is collected and how long it is stored.  Where can I find that information about Fastrak?

Finally, I spoke last week to a consultant to Caltrans who offered to get the local MTC agency technical staff in touch with me.  I explained that I’d be happy to describe my findings and recommendations to them in advance of my Blackhat talk at no charge.  Anyone from those agencies can contact me via my company website here.

July 3, 2008

Dead-listing while on vacation

Filed under: Embedded,Reverse engineering,Security — Nate Lawson @ 10:21 pm

I just got back from a nice vacation with no laptop.  What do I do on long plane rides or while listening to the waves lap against the beach?  Dead-listing.

Dead-listing is analyzing the raw disassembly of some target software and figuring it out using only pen and paper.  This is great for vacations because your laptop won’t get sand in it.  You usually have a long period of time to muse about the code in question without interruptions, something hard to find at home these days.  And I’ve gotten some of my best ideas after setting aside my papers for a while and going for a long swim.

Before you leave, pick an interesting target: not too big, not too small.  Not just x86 either — ever wondered how one of your cellphone’s applications worked?  Never looked at a familiar application’s Java bytecode?  Then, get a copy of a disassembler for your target and run it.  I often use IDA but for less common CPU architectures, any one will do.  Remember that you don’t need full analysis at this point, although it’s useful to be able to separate data from instructions and get basic symbols resolved.

Search the assembly code for any external libraries that might be important.  Disassemble them too.  While you’re at it, see if you can find the source code or API reference for any of those files.  Code reuse helps you reduce the amount you have to reverse yourself.

Now take the listing file and do some cleanup.  I like to use a small font that prints well and convert all the call (subroutine) instructions to bold.  I insert some extra empty lines before each call target to allow me room to write notes.  Finally, I print the listing in landscape with two columns per page.  This leaves room for notes on the righthand side of each column and some at the bottom.  A binder clip makes it easy to keep pages in order or remove them to compare.

Since you won’t have access to the Internet, you’ll need to find some basic reference materials.  The key is to get the basics without carrying a ream of paper.  For an embedded system, I usually find or make a small instruction set reference sheet including status flags, I/O port table, PCB layout photos, and any integrated peripherals I find during a brief search of the data accesses.  Print these out and put a full copy of all the files on a USB flash drive.  You might stop by an Internet cafe if you find you really need to read a missing page.  I’ve never found that necessary though.  If I can’t infer the function of a particular I/O access, I’ll just look at the whole block’s general effect and take a guess.

The most important part is to stay light.  You don’t need exhaustive manuals (e.g., instruction timing).  Instead, treat these barriers as a challenge.  For example, most timing loops are relative to each other.  You can figure out that one loop is twice as slow as the other without knowing its exact delay in nanoseconds.  Doing hexadecimal conversions on paper builds character.

Once you’re away, enjoy doing a little bit at a time.  I’d often work through a subroutine or lay out a switch statement over coffee before the family gets moving, then set it aside for the rest of the day.  Before putting it down, keep a separate log of open questions and tasks, marking them off as you solve them.  I usually reserve a page in this notebook as my “symbol table”, marking down function names/addresses as I finalize them.

I mostly work through the code in two modes: looking for high level blocks or walking through a single subroutine in detail.  Was this compiled C or C++?  How does the optimizer work?  When accessing hardware, where did the author use inline assembly?  Draw arrows, bracket blocks, use highlighters if that’s your style.  Since it’s more free-form than working on a computer, you’ll find new ways to annotate it.  The amount of marks per page gives a good idea as to code coverage so you can start a day by refining an existing page or try to take a broad guess what a blank page does.

I am always surprised how much I accomplish in only a little bit of time using this method.  It’s also so much fun.  Throw in reading a few interesting but unrelated books and you may wax philosophical on the meaning of life or why the compiler suddenly switched to byte instead of word operations for a single function.

I hope you have a great summer.  Be sure to stop by my Blackhat 2008 talk, “Highway to Hell: Hacking Toll Systems“.  I’ll be posting more details about it here in the coming weeks.

The Rubric Theme Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 81 other followers