Archive for July 30th, 2012

DEFCON 20 notes: day 3, part 2.

Monday, July 30th, 2012

Where were we? Oh, yes: The Day of the Router.

(That’d be a good title for a movie. Maybe one about penetration testers. Hmmmm…a pen tester accidentally finds a vulnerability in the wrong system, and the bad guys want to shut him up?)

But I digress.

First in our router trilogy is Michael Coppola‘s “Owning the Network: Adventures in Router Rootkits“. (First link goes to his blog, second link goes to the presentation.)

Coppola has been working on altered versions of firmware for popular routers: “altered” in the sense that the firmware contains useful exploits. (‘But how do you get the firmware on the router?” Well, there are well known cross-site scripting attacks on router configuration pages: as I recall, that was the subject of a DEFCON presentation, but I don’t have time to dig out which one right now. When I get back, I’ll add a link. In addition, how many people leave their router login/password set to defaults? Too many.)

Coppola specifically attacked these routers:

  • Netgear WNR1000v3.
  • Netgear WGR614v9.
  • Belkin FD57230
  • Trendnet TEW652BRP 3.2r

And there’s a simple five-step process:

How much would you pay for all this? But wait, there’s more! The end result of Coppola’s work is rpef, a framework that automates much of this process. You point it at a firmware image, tell it what exploit you want to use and where to save the modified image…and it generates a new firmware binary for you, ready to upload to your favorite router. Isn’t that a clever cleaver?

(At the moment, rpef only supports a limited number of routers. I suspect if this takes off, the number of supported routers in rpef will expand dramatically.)

Second up on the router hit parade was FX with “Hacking [redacted] Routers“. The [redacted] in this case is Huawei, a large Chinese manufacturer of routers, and the short version of this talk is that their routers are crap. They have no known product security group, they do not issue security advisories, the quality of their code is poor, important ports (SSH, FTP, HTTP) are open by default (and you can access the flash file system by FTP), their OpenSSH implementation is a rewrite from scratch and is broken…

…and it is possible with a simple script to hijack a remote session to the router, there are built-in functions that allow execution of commands from the command line interface with no privilege checks…

….and there’s a heap overflow bug (which the presenters spent a great deal of time explaining) that allows you root on the router. Whew. I think that just about covers it. Luckily, in my opinion, Huawei routers are mostly used in other countries, and I can’t get very upset about those countries having their routers hacked. (What’s the worst case scenario? Less Chinese spam?)

(I can’t find FX’s presentation, and it isn’t on the DEFCON DVD. I’ll link to it when I can find it. Link added 8/1/2012.)

(Interestingly, these first two router panels were so popular, they had to move FX’s panel to a larger room to accommodate the people who wanted to see it. And I think there were still people who didn’t get in.)

Finally, we have “SQL Injection to MIPS Overflows: Rooting SOHO Routers” by Zachary Cutlip. (Link goes to a version of this talk he gave at Black Hat.)

The short summary here is that Cutlip attacked a specific router, the Netgear WNDR3700 v3. This is a highly popular router: as a matter of fact, WCD uses the v2 version of this router (reflashed with DD-WRT firmware) in our home office. One of the interesting aspects of this router is that it has DLNA support, so you can use it to serve things like music and movies. (It has an external USB port for connecting drives.)

As it turns out:

  1. As part of the DLNA setup, the router runs SQLite. (Apparently, it keeps a database of album art for DLNA device display purposes.)
  2. You probably already guessed this, but the implementation on the router is vulnerable to SQL injection attacks.
  3. You can leverage SQL injection and grab the router’s password file, or other arbitrary files from the running router.
  4. You can also leverage this to force a buffer overflow and run arbitrary code on the device.

Cutlip’s paper contains example Python code for implementing these attacks.

I totally spaced on the “Hacking the GoogleTV” panel and spent the last few hours trolling the dealer’s room for bargains. I did pick up a few things which I may discuss in more detail later. Or maybe not. It depends.

I don’t have a lot to say about the closing ceremonies, with one exception. DEFCON admission this year was $200: during the ceremonies, Dark Tangent stated that they had intended to raise the cost for this year only, to cover all the awesome stuff they wanted to do for DEFCON 20. Their plan was to roll the price back next year, but Dark Tangent found people were asking them how they were going to top this year…

…and he polled the audience to find out if they thought the $200 was a good value for the money. Overwhelming audience sentiment seemed to be that the $200 price tag was not too high, considering what folks got out of DEFCON. And Dark Tangent seems to be serious about getting Kraftwerk to do a concert next year.

I’m going to wrap things here. In the next day or two, I will probably be doing an after-action report, covering Vegas in general and some additional DEFCON odds and ends. I also will be posting updates as I find people’s presentations online, and as folks put them up.

As always, I welcome comments from presenters. I want to say that this year, I did not see a single panel that disappointed me; I liked every single panel I was able to get into.

Also, I want to make note of a thought from dinner tonight with some friends of mine. This may very well be a research idea for next year’s DEFCON.

So we all know how flash memory works, and that if you do repeated write/erase cycles, you’ll wear out your flash. We also know that manufacturers have implemented wear leveling to get around this.

Questions.

  1. Is it possible to bypass wear leveling on flash devices? Can you write software that does write/erase operations to specific flash memory locations?
  2. Can you write software that will do repeated write/erase cycles on flash memory devices and make those devices forensically useless? Similar to the old “three pass overwrite” for hard drives?

I don’t know the answers (as I said, this came up at dinner literally two hours after my plane got in) but it seems like a possible area for exploration. I need to go back through my DEFCON archives, as I have a vague memory of someone doing a presentation on flash memory forensics.

(Also, I’m sorry it took so long to get this post up. I finished about 2/3rds of it in the Las Vegas airport, had a very tight connection in Phoenix (literally running to the plane and arriving just seconds before boarding started), got in, wrote most of the last third, and am now going to have a cold beverage and (I hope) about eight hours of sleep.)

Posted in DEFCON 20, Geek, Music | 1 Comment »

DEFCON 20 notes: day 3, part 1.

Monday, July 30th, 2012

The secret word for the day, boys and girls, is “routers”.

But first, a couple of pictures for my great and good friend Borepatch:

The Matt Blaze Security Bingo Card. (I hope folks can read it: I took that with a cell phone camera from the front row, so I didn’t have a great angle on it.)

And:

A gentleman in the hallway was kind enough to let me take a photo of his DEFCON Shoot shirt.

Speaking of Matt Blaze…

“SIGINT and Traffic Analysis for the Rest of Us” presented by Matt Blaze and Sandy Clark, and crediting a host of other folks.

For the past few years, Blaze and company have been working on APCO Project 25, or P25 for short. P25 is planned to be the next generation of public safety radio, and is intended to be a “drop-in” replacement for analog FM systems. Cryptographic security is built into P25: it uses symmetric algorithms and supports standard cryptographic protocols. All of this sounds great.

But there are a whole bunch of problems with this.

Encryption in P25 doesn’t work very well a significant portion of the time. There are user interface issues; on some radios, the “crypto” switch is in an obscure location, and the display doesn’t make it clear if encryption is on or off. Keys can’t be changed in the field; changing keys requires loading the radio in advance using a special device, or sending keys over the air (“Over The Air Rekeying”, or “OTAR”, which sometimes doesn’t work).

One important point is that the “sender” makes all the decisions: whether the traffic is encrypted, what encryption mode is used, what key is used, etc. The “receiver” doesn’t get to decide anything. If the “sender” sends in cleartext, either deliberately or by mistake, the “receiver” decodes it, automatically and transparently to the user. If the “sender” sends an encrypted message, the “receiver” first checks to make sure it has the proper key, then either decrypts the message or ignores it (if the “receiver” doesn’t have the key).

I feel like I am cheating a little here, but even Matt Blaze at this point in his talk recommended going and reading the group’s paper from last year, “Why (Special Agent) Johnny (Still) Can’t Encrypt: A Security Analysis of the APCO Project 25 Two-Way Radio System” for additional background.

But wait, there’s more! We have encryption, but do we have authentication? Do we know that the radios on our network are actually valid radios? Heck no! The radios transmit a “Unit ID” which is not authenticated, and which is never encrypted, even if the radio has encryption turned on. Just knowing the unit IDs lets you do some interesting stuff: you could, for example, set up two radios, do some direction finding on the received signals with the user IDs, and build a map of where the users are.

Even better: if you send a malformed OTAR request, the radios treat it like a UNIX “ping” and respond back with their Unit ID, even if they’re idle, and without the user ever knowing.

More: P25 uses aggressive error correction. But there’s a hole in the scheme; you can jam what’s called the “NID”, which is part of the P25 transmission, and render the transmissions unreadable. The Blaze group actually built a working jammer by flashing custom firmware onto the “GirlTech IM-Me”. (That was the cheapest way to get the TI radio chip they wanted to use.) You could use this to jam the NID in encrypted P25 traffic only, thus forcing cleartext on the users…

And even more: the basic problem with P25 and cryptographic security is usability. Every time an agency rekeys, someone is without keys for a period of time. Blaze mentioned the classic paper, ““Why Johnny Can’t Encrypt: A Usability Evaluation of PGP 5.0” and pointed out that many of the mistakes mentioned in that paper were repeated in designing P25.

How bad is the keying problem? Bad enough that agencies frequently transmit in cleartext, due to key management issues. (“NSA Rule Number 1: Look for cleartext.”) How frequently? Blaze and his group, for the past several years, have been running a monitoring network in several (unnamed) cites, recording cleartext P25 traffic and measuring how often this happens. About 20-30 minutes per day, by their estimate, of radio traffic is transmitted in unintended cleartext. And that traffic can contain sensitive information, like the names of informants.

Even if most of the traffic is encrypted, remember that the Unit IDs aren’t. So you’re getting some clear metadata traffic, which at the very least is useful for making inferences about what might be going on. (Zendian Problem, anyone?)

(If you’re monitoring P25 traffic, according to Blaze, the phrase you want to look for is “Okay, everyone, here’s the plan.”)

And what is the P25 community response to this? According to Blaze, the Feds have been very responsive and appreciate him pointing out the problem. The P25 standards people, on the other hand, claim Blaze is totally wrong, and that the problem is with the stupid users who can’t work crypto properly.

(This entry on Matt Blaze’s blog covers, as best I can tell, almost everything that was in his presentation. I haven’t found a copy of the actual presentation yet, but this should do to ride the river with.)

So it is getting late here, and I have to catch a plane early-ish in the morning. I think what I’m going to do is stop here for now, and try to get summaries of the three router panels up tomorrow while I’m waiting for my flight.

Posted in Cops, DEFCON 20, Geek, Guns, Law, Radio | Comments Closed