“Earth vs. The Giant Spider”: This was described as a collection of weird, bizarre, freaky, and unusual hacks compiled by the presenters during penetration tests. I figured this would probably be a high energy, lots of fun, lots of laughs panel. I ended up kind of disappointed. Maybe high energy is too much to expect at 10 AM on DEFCON Sunday, but the presenters seemed curiously subdued. (This may have had something to do with non-functional equipment that resulted in them having to drop the live penetration test portion of the presentation.)
As for the hacks…well, okay, owning an entire country’s credit card processing (bypassing the firewall by sending packets from source port 0) is kind of cool. Getting cheap food from a restaurant chain by hacking a Javascript that communicates with a 3rd party server, and doesn’t validate data being sent from the restaurant’s website to the server? Meh. The story about cloning the support mailbox on an old ROLM PBX (default field service user ID/password) which ended up with the penetration testers doing Checkpoint support for one of the corporate users? Mildly funny. The other hacks (doing a HTTPS man in the middle attack with a self-signed certificate, and using information gathered that way to hijack a session to an external VPN by cloning cookies; high-def IP cameras with undocumented default accounts located right over keyboards, Oracle session hijacking), well, maybe you just have to have been there.
As for the “Caucasian-American love hack” (in which they were able to guess an admin’s password from his profile on an Asian-American dating site), I felt more pity for the poor admin, who was probably just looking for love (and not even in all the wrong places) rather than admiration for the penetration testers. Sorry, guys: I know your intentions were good, but this didn’t click with me. It may just have been a personal thing: YMMV.
“Seven Ways to Hang Yourself with Google Android”: An excellent presentation by Yekaterina Tsipenyuk O’Neil (Fortify) and Erika Chin (UC-Berkeley) about the major mistakes programmers making developing Android applications. Specifically:
- “Intent spoofing”. Basically, “intents” are a type of message Android uses for inter-application communications, intra-application communications, and system event messages. Android intents can be either “explicit”, where the intent is directed to a specific destination or “implicit”, where the destination isn’t specified and Android decides where the intent should be delivered. The issue is that many developers just use implicit intents, which makes it possible for someone to write a malicious application that creates intents requesting some sort of change in state, and send those intents to other applications that use implicit intents.
- SQL query string injection. Yes, you can build a malicious app that queries Android’s SQLite database and (possibly) returns data the app otherwise wouldn’t be able to see.
- “Unauthorized intent receipt”. Very similar to #1, except instead of requesting a change in state, the malicious app harvests information from public intents intended for other non-malicious applications.
- “Persistent messages: sticky broadcasts”. Android has the capability to send broadcast intents to applications (more specifically, to components of applications that are set up to receive broadcast intents). There are some issues with this. The first issue is that any application registered to receive broadcast intents will get all broadcast intents; there’s no way to restrict broadcast intents to specific receivers. It is also possible to create “sticky” intents, which hang around after they are delivered, and are even rebroadcast to new receivers that are enabled in the future. And with the proper permissions, a malicious application can also remove “sticky” intents, possibly before they are received by the intended recipients.
- Insecure storage. Files on the SD card can be read by the entire world. Files created by an application (which might contain things like, oh, I don’t know, passwords?) persist even after the application is deleted, and can be accessed by other, possibly malicious, applications.
- Insecure communications. Basically, developers need to get into the habit of acting like their mobile applications are web applications, and use similar best practices; don’t send passwords in cleartext, for example.
- Overprivileged applications. Developers have a tendency to request more permissions than their app really needs. For example, an application that just displays images doesn’t need the “camera” permission; only an application that actually uses the camera to collect images needs that permission. One of the interesting facts that came out of this portion of the presentation was how Android’s developer documentation handles explaining permissions and what they represent. Quoting the presenters: “Android 2.2 documents permission requirements for only 78 out of 1207 API calls. 6 out of 78 are incorrect. 1 of the documented permissions does not exist.”
(Edited to add 8/10/2011: I’ve added a link to the final version of this presentation.)
“Build your own Synthetic Aperture Radar”: So this wasn’t as dangerous as I expected (the radar is low-power) and it wasn’t quite as awesome as I expected. But this was a decent presentation on radar technology, starting with an overview of basics and proceeding onwards to discussion of a homebrew radar system.
One minor problem with this presentation was that the presenter (Michael Scarito) had converted his system to use a custom-built data acquisition board (previous versions used a sound card and MATLAB) and didn’t have build documentation for that board prepared yet. However, much of Mr. Scarito’s work is based on other work done at MIT. The slides for the talk are not currently online, as far as I know, but here’s a link to a MIT Open Courseware presentation that gives exact, step-by-step detail, parts lists, and other resources for a very similar project (cited by Mr. Scarito in his presentation).
“Wireless Aerial Surveillance Platform”: UAVs are fun. UAVs that have onboard computing power to crack WEP encryption are more fun. UAVs that add the ability to spoof cellular base stations are even more fun. UAVs that have the ability to communicate with a remote server and offload heavier computational tasks (like attacking WPA) are perhaps the most fun of all. Note: the link above doesn’t go to slides, but to the build blog maintained by the two presenters (Mike Tassey and Rich Perkins). The build blog provides a lot more detail than the presentation, and includes resource links. Very well done, gentlemen.
“SCADA & PLCs in Correctional Facilities: The Nightmare Before Christmas”: Borepatch posted a few days ago about a presentation at Black Hat on SCADA vulnerabilities. You could consider this the other shoe dropping.
Summary: many prisons and jails depend on programmable logic controllers (PLCs) to do things like unlock and unlock cell doors. Usually, these PLCs are all controlled from a central control center, so all you have to do, once you find a PLC vulnerability to exploit, is to get your exploit code into the central control center.
“But they aren’t connected to the Internet, right?” Sometimes they are: the systems need to get updates, or send information to other systems, or communicate with other people (food service vendors, for example). Sometimes the systems aren’t connected to the Internet, but other systems they connect to are. (The presenters cited one example where someone was able to upload arbitrary files to the wireless system on a patrol car, and from their to a central jail control system.) Someone could carry an exploit in on a USB drive.
“But the people who run these systems don’t go out to arbitrary sites, right?” The presenters cited examples, from their personal experience, of correctional institution employees watching videos on the Internet, checking GMail accounts, etc. Friend the right correctional institution employee on Facebook…
“But they couldn’t do anything bad, right? I mean, if they open the cell door, the control panel shows it, and won’t the guards catch them?” As for the guards catching them, I remember a story from Pete Earley’s book The Hot House: Life Inside Leavenworth Prison
about an inmate who got hold of some clothes and a clipboard: he walked completely out of Leavenworth posing as a prison inspector. As for the control panel showing it, the presenters demonstrated an exploit that allowed a PLC controlled switch (think a door latch) to be open, while the PLC control software thought the switch was closed. (Video of this exploit is supposed to be on YouTube, but I can’t find it right now.) And opening jail doors isn’t the only thing you could do; you could also disrupt prison operations by trying to open all the doors at once. This would cause a massive power surge, and possibly destroy the system. (Generally, the doors open in a “phased” fashion, so you’re not trying to draw that much power at one time.) Or you could force the doors locked. Imagine the Mexican Mafia subverting a prison PLC system so they can force all the door locks for cells belonging to Aryan Brotherhood members closed at once. A squirt of rubbing alcohol or some other volatile liquid into each cell, toss in a match…
(“Christ, what an imagination I’ve got.” Spot the reference, win a cheese.)
(Edited to add 8/10/2011: I’ve added a link to a white paper by the presenters that pretty well summarizes their presentation and findings.)
That concludes my DEFCON 19 roundup. As more of the presentations get online, I’ll be adding links to them, and there will probably be one or two update posts. If you attended a panel I missed at DEFCON 19, and think it is worth linking to, please feel free to mention it in the comments. Responses from presenters are also welcome, especially if I mis-represented or misunderstood a point.
