[tor-dev] Trip Report: Defcon

[Damian Johnson <atagar@xxxxxxxxxxxxxx>]

Hi all. When tor developers go on trips we commonly write a trip
report afterward. My recent trip to Defcon didn't contain anything
sekrit so sending the notes I took here. If any of these presentations
sound interesting to you then videos should be available later on the
Defcon site.

Cheers! -Damian

PS. I was new to many of the things being presented so my notes quite
likely have some inaccuracies. Don't quote me on anything - watch it
for yourself if interested.

tl;dr
Only presentations related to the privacy field were...

* Can You Track Me Now?
Panel discussion on mobile GPS tracking with lots of interesting stats.

* Crypto and the Cops
EFF presentation on the 5th amendment protections and how it applies
to compulsory decryption.

========================================

  Las Vegas is... an unusual city. Like most people I knew I wasn't in
Kansas any more when I saw slot machines in the airport. By day the
city's not much to look at. Mostly just a bunch of dusty buildings
baking in the 110 degree desert heat. But by night the whole city
illuminates in neon lights making it quite a spectacle.
  My first night I explored the strip and several of the larger
casinos including Bally's, Bellagio, Caesar's Palace, and the Rio
where the conference was taking place. They were... enormous. Caesar's
in particular took me almost a half hour simply to walk the length of
it. Probably my favorite sight was the Bellagio fountains which had a
magnificent water show choreographed to 'Singing in the Rain'. It was
very classy.

========================================

The second day was the first of the conference and mostly consisted of
two things: standing in line a couple hours for registration and
introductory talks. The talks were just a single track and included...

* Wireless Security: Breaking Wireless Encryption Keys
Handshake process for WPA, WEP, and WEP2 among other things. I was
still sorting out the material that I got during registration so I
didn't pay very close attention which was a pity since I could use a
refresher.

* Intro to Forensics: Tools & Tactics
A very brief introduction to nmap, tcpdump, netcat, ntop, and
Metasploit. Nothing new to me here though it was a nice reminder that
I know less about them than I'd like. I haven't played with them since
grad school and should try them again when I get home...

* Cerebral Source Code
Presentation on social engineering. Sadly missed a large part of this
one since I still hadn't had breakfast. The QA portion that I saw was
fun, mostly questions about how he'd extricate himself from various
sticky situations. His answers were clever, as well as entertaining.
My favorite...

Q: What would it take to have more trust in this community?
A: LSD?

* DC101: Defcon Survival
This was a panel discussion with general advice for enjoying Defcon.
Mostly it boiled down to 'you get what you put in' which caught me a
little off guard. I came here expecting to watch some talks, see
Vegas, and schmooze with other conference attendees. Defcon, however,
aims to be a lot more interactive than that and the organizers put a
lot of effort into events that weave throughout the conference.

* HF Skiddies suck, don't be one. Learn some basic Python.
This one made me twitch. The speaker both gave a very bad tutorial for
getting started with python (who the hell fires up *Eclipse* every
time they want to write python?!?) and seemed to be incoherently drunk
for most of it. Mostly I spent this time reading the program.

* Hacking the Hackers: How Firm is Your Foundation
This was a long checklist of various topics the speaker thought the
Defcon audience should know about, largely focused on hardware hacking
since that was his specialty. Interestingly 'TOR' was the first thing
he listed. I always wondered how that spelling persists despite our
efforts to stamp it out. Considering that this conference had roughly
20,000 attendees, each of whom will pass it along I guess now I
know...

* Fun with the Lockpicking Village
A few years back I read the MIT guide to lockpicking and spent a
couple days practicing against my door. Since then I've fallen out of
practice and this was a nice reminder about both the basics and a few
things that I didn't know (how bump keys work, defeating deadlatches,
how to use a can of compressed air to defeat magnetic locks that allow
egress traffic, etc).

The hallway track wasn't anything too notable. Met three developers
with Metasploit and someone from the security group I attended at WSU.
But that was about it.

========================================

Second day of the conference I ran into someone from Amazon Infosec. A
talk I wanted to attend concerning the attack surface of near field
communication (NFC) devices was full, but several of the others were
interesting...

* Can You Track Me Now?
This was my favorite presentation of the whole conference. A panel of
four presenters, including Chris Soghoian, discussed geolocational
privacy of mobile devices including local threats, historical
information, and requests for real time tracking.
  Why does this matter, you ask? Because when it takes a team of
agents to track your every step surveillance is costly. But when a
single agent can track you and your every acquaintance from the
comfort of his desk we get a whole lot closer to a 1984 style
surveillance state real fast.
  Sprint now has a department of 200 people to service wiretapping
requests. They also provide a self-service portal to law enforcement
that has been used six to seven hundred thousand times a year, for 8
million GPS coordinates. This includes your every move going back 6
months to 2 years depending on your provider. 7 years in the case of
AT&T.
  And no, none of this requires probable cause or a warrant. In other
words, beware if your ex is a cop.
  Another eye opening bit of the talk was phone encryption. Apple has
a master skeleton key for all iPhone devices so, when requested, they
can send law enforcement a DVD with all the contents of your phone.
Android is a little different in that they remotely reset your
password to something that they can give the law enforcement agent.
  Beside three letter agencies, ad networks and apps are also a
concern. 47 of the top 100 mobile applications send locational
information to 3rd parties. For instance, 'Best Alarm Clock' sends
locational information in the clear to 3rd parties whenever the app is
used (somehow I doubt they need to do that for the alarm clock to
function...).
  On a policy front one slight glimmer of hope comes from a recent
case which ruled that placing a GPS tracking device on your car *does*
constitute a search and hence requires a warrant (which means they
kinda sorta need evidence of wrongdoing, *gasp*!). Don't read too much
into this, though. The majority opinion ruled this way because it
technically constituted trespassing on your property.
  Just because you're paranoid doesn't mean they're *not* out to get you...

* Crypto and the Cops
Marcia Hofmann from the EFF discussed 5th amendment protections and
how they apply to being compelled to reveal your passphrase for an
encrypted device. There have been five cases in this area so far, some
that ruled each way in terms of compulsory decryption. Though not
intuitive, the main determining factor in those cases constituted a
gap in knowledge. If law enforcement knows exactly what they're
looking for and where it is then there's less chance of the amendment
applying than if the search is a fishing expedition. Moral of the
presentation: never volunteer information, even if you're innocent.
Ask for a lawyer first.

* Making Sense of Static
Walkthrough of GPS signal acquisition, mostly focusing on how
receivers account for Doppler shift and determine the code phase. The
speakers also presented libswiftnav, an open source implementation of
a GPS receiver system.

* Life Inside the Skinner Box
Cautionary presentation about the automation of law enforcement and
where it might someday lead. This was pretty high level, discussing
the societal implications.

* Anti-Forensics and Anti-Anti-Forensics
Discussion by a forensic examiner of several tricks that can draw out
the length of an investigation (and by extension cost, increasing the
chance of settlement). He also covered how they can be mitigated. Some
of them included...

- using a non-standard RAID configuration
- randomizing file crated/modified timestamps
- altering file header types
- using restricted windows filenames (CON, PRN, AUX, etc)
- owning lots 'o media
- modifying files provided with your system so the checksums no longer
match what a default install would include (and hence adds to the
haystack of things to sift through)

Before heading back for dinner I also caught part of a Skytalk. I
didn't find the presentation to be too interesting (brainstorming
about mass data aggregation), but I got a chuckle from the sign on the
door: "Absolutely no cameras allowed. Violaters will be violated
violently." :P

========================================

I had less luck on the third day of the conference, hopping between
several talks that weren't particularly interesting. The best I found
were...

* World War 3.0 - Chaos, Control, the Battle of the Net
Policy talk about Dubai's upcoming WCIT negotiations (aka, the thing
that's gonna politicize the Internet). Most of the presentation was
surprisingly fluffy, the only interesting bit coming from Dan Kaminsky
who made the point that there's generally four interests involved...
- privacy
- security
- anti-piracy
- sovereignty

... with 'reliability' being the golden goose that no one wants to
cook. His point was simply that these four camps war and forge
alliances, privacy and security for instance sometimes at odds over
anonymity but thick as thieves on other obvious fronts. He also said
something like "We have made a system optimized for moving pictures of
cats. And it's *really* good at it. Though we'd like it to do more."
(likely horribly misquoted)

* Exploit Archeology: Raiders of the Lost Payphone
Step by step process of reverse engineering and reprogramming an
Exetel payphone. Twenty year old software from a company that imploded
without a trace long, long ago. Ye gods each step turned out to be a
trek to Mt. Doom and back...

* Off Grid Communication with Android
Mesh network by introducing a transparent proxy after going through
the Java networking interface. He wrote something based on the 'Wi-Fi
Tether for Root Users' app to put his phones into ad-hoc mode then
tried both the OLSR and BATMAN proactive routing protocols. He also
tried a reactive protocol that broadcasts messages, then left routing
decisions to the receiver which can trivially pick the shortest path
though this had issues scaling above 200 devices or so.

* Back Ops
My favorite talk of the day, given by Dan Kaminsky. It was originally
slated for two hours, but got crunched at the last minute into a one
hour slot so he went pretty fast over five different topics
including...

- Timing Attacks
Attacks can distinguish 15-100 ms deltas over the Internet and 100
nanoseconds over a LAN. Making everything take an identical amount of
time is generally unrealistic since it forces everything to worst case
performance. His view was not to let the perfect be the enemy of the
good, and simply introduce random delay into requests.

- Bad Random Number Generation
First a rant that for twenty years security engineers have worried
about entropy sources, yet we still haven't gotten it right. The
common sources of entropy are: hardware RNG, keyboards, mouse, and
disk rotation. However... most servers don't have any of these,
especially with the move to virtual storage devices. Roughly 1/200
keys on the Internet are poorly generated, and he proposed using
idiosyncrasies in clock timing as an alternative source of randomness.

- Security Aspects of Languages
Starting with the question 'why is PHP so damn popular?', he discussed
why secure coding practices like prepared statements often aren't
followed. His conclusion: SDEs are in charge and they just want their
service to work. The more of a pita security makes itself the more
it'll be viewed as an obstruction and hence circumvented. He then
proposed more usable security patterns, for instance making the
languages smart enough to translate queries like "SELECT name FROM
users WHERE username=$id" into the proper prepared statement
counterpart.

- Censorship Detection
After a brief mention of OONI-Probe he discussed a censorship
detection method of his via the use of favicons. I saw this in an
earlier presentation of his and he mostly skimmed through it.

- Vulnerability Scanning
Trying to answer the question of 'how much of the Internet is
vulnerable to X', he used *stateless* TCP connections to scan hosts
far quicker than he usually could. The trick was to skip retaining any
information about outbound connections, making fire-and-forget TCP
handshakes and leaving it to the other end to remember the state of
the connection.

========================================

I didn't expect much from the lineup on the last day, but some of them
were surprisingly good. I also ran into a couple more people from
Amazon and Runa very briefly.

* SIGINT and Traffic Analysis for the Rest of Us
Very good talk on APCO Project 25 (P25), two way radio communication
used by police, fire departments, federal enforcement, the secret
service, and the DoD. A drop-in replacement for analog FM, this was
first introduced in the early 1990s. It can optionally be encrypted,
with federal/DoD users commonly enabling it and police/fire leaving it
off. If you see an earpiece or bulky walki-talky then this is what
it's probably using.
  The speaker discussed several vulnerabilities in P25. Firstly, it
uses a forward correcting protocol that is easy to jam. Usually a
jammer needs to be stronger than the signal it's jamming, but with P25
it's sufficient to selectively block a message's header to cause the
rest of the message to be ignored. How hard is this, you ask? To
cheaply jam a P25 signal you just need a $15 GirlTech IMME toy (it
cost less to buy the toy than the transmitter that comes in it). As an
added bonus it comes in pink or purple and comes with ponies on the
box!
  Second, P25 has no notion of authentication. Anyone can transmit and
user ids can be trivially spoofed. The user id of transmitters are
sent in the clear, even when encryption is enabled.
  Third, any P25 device that receives a malformed signal will reply
with the user id (again, in cleartext). This is invisible to the user
and means that you can ping all P25 devices and triangulate their
positions. Think of it as the "Marauder's Map" for the secret service.
  Fourth, P25 is a narrow band radio broadcast (12.5 Khz) which is
fairly easy to intercept via a scanner (such as an Icom R-2500). This
makes encryption a must for private communications. However, the
encryption of P25 devices has several usability issues...

- Encryption is enabled or disabled via a switch on the handset. The
only indication of if encryption is enabled or not is a "1" or "(/)"
symbol on the handset. Which means 'encrypted' and which means
'cleartext' is evidently a common point of confusion.

- The beep that the device makes to indicate that it's in encrypted
mode is the same that's used to indicate a low battery among other
things.

- Encryption is transparent to the receiver, so if an individual in a
group is broadcasting in cleartext then it's impossible for anyone
else in the group to know and correct them.

- Rekeyed P25 devices become incompatible while being rekeyed, forcing
users to drop to cleartext if any of the devices haven't yet been
updated.

As a result, about 30 minutes per day of federal communications are
sent in the clear. In a multi-city study on what this included
researchers were able to gather the names of informants, license
places of vehicles being tailed, etc. These snippets were also enough
to reasonably figure out what investigations were going on at a given
time.
  When brought up with the federal field offices encryption rates
improved for a week or so, then dropped back to their prior ratio of
cleartext. The researchers also discussed these with the
manufacturers, who insisted that it wasn't their fault if their users
couldn't properly use their devices.
  Btw, the only federal service to have a spotless record in terms of
encrypting their communications? The US Postal Service.

* SCADA Strangelove or: How I Learned to Start Worrying and Love the
Nuclear Plants
This was a talk on the security of SCADA HMI software (or lack
thereof), which is used throughout several minor things like nuclear
power plants. Originally to prevent plant operators from installing
pong on the kiosks, HMI applications hasn't evolved much since those
humble origins. This talk was funny as hell, going over issues with
several widely deployed HMI systems...

- Microsoft Bob: Early attempt at a friendly, 'helpful' interface. If
you made three incorrect password attempts you got a dialog saying "I
see you forgot your password. Please enter a new one here...". It also
stores passwords in plaintext.

- InvisiLink: Stored passwords are an xor with a static key. What is
that key, you ask? "0123456789"

- KingView: Passwords simply have their last byte subtracted from 0xff.

- Iconies Genesis32 9.2.2: The login dialog includes a 'challenge
code' that can be used as an alternative method of getting local admin
access. To use this code the user is supposed to call customer
service, who then provides the password corresponding with the code.
Alternatively, you can take the first eight characters of the
challenge code's md4 hash to do the same.

  There were also a couple talks on 'firesheep inspired' frontends for
various exploits. The first did NTLM relaying against Windows
corporate networks to allow for a variety of not-so-nice things like
reading through another person's Exchange inbox.
  The second was a UI to automatically ARP poison a network then use
sslstrip to snag credentials. I felt a little embarrassed for the
speakers in this talk since they first tried to sensationalize what
sslstrip could do. After that they claimed to have a stealthy MITM,
then described the noisiest attack I can think of. Not only did they
ARP poison the network and do SSL downgrading, but they did a nmap
scan of every host on the network and, just for added stealthyness,
blocked all tunneling protocols (ssh/vpn). The later was on the theory
that "they'll just use the local network instead". Uggg.
  So more annoying push-button solutions for script kiddies. Yay.

========================================

Ending conclusions:
Fun and interesting conference, but *damn* vegas is pricey. The trip
was 1.5k and only $200 of that was the conference registration. I
enjoyed it and it was a good thing to do at least once, but way too
costly to do again.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev