So, following up on my post on BSides LV 2015, I thought I’d give a summary of DEF CON 23. I can’t cover everything I did (after all, what happens in Vegas, stays in Vegas… mostly) but I’m going to cover the biggest highlights as I saw them.

The first thing to know about my take on DEF CON is that DEF CON is a one-of-a-kind event, somewhere between a security conference and a trip to Mecca. It’s one part conference, one part party, and one part social experience. The second thing to know about my take on DEF CON is that I’m not there to listen to people speak. If I was just there to listen to people speak, there’s the videos posted to YouTube or available on streaming/DVD from the conference recordings. I’m at DEF CON to participate, meet people, and hack all the things.

I generally try not to spend my entire DEF CON doing one thing, though I’d probably make an exception if I ever got to play in DEF CON CTF. (Anyone need a team member? :)) It’s a limited time (on papser, 4 days, but really, it’s about 2.5 days) and I want to get in all that I can. This year, I managed to get in a handful of major activities:

1. A Workshop on Auditing Mobile Applications
2. Playing OpenCTF
3. Playing Capture the Packet

I also attended a few talks in the various villages, including the wireless village and the tamper evident village, worked at an event for my employer, and got lots of opportunities for finding out what others are working on and the fun & interesting projects people are doing. (And perhaps I attended a party or two…)

Auditing Mobile Applications

The auditing mobile applications workshop (taught by Sam Bowne, an instructor at CCSF) was interesting, but wasn’t as much depth as I’d hoped. Firstly, it was strictly confined to Android and didn’t cover iOS at all (though some of the techniques would still apply). Secondly, a lot of the attendees were very inexperienced at what I would consider basic tooling. I’m all for classes for every level, but having the same class for every level means teaching to the lowest common denominator. I do have to give him a lot of credit for being well prepared: he had his own wireless router, network switches, and even several pre-configured laptops for student use.

The course attempted to cover several aspects of the OWASP Mobile Top 10, but mostly focused on applications that failed to use SSL, failed to implement SSL, or failed to implement anti-reversing protections (more on that later). The first two were basically tested by installing an emulator, installing Burp Suite, and pointing the emulator to Burp. If traffic was seen as plaintext traffic, well, obviously no SSL was in use. If traffic was seen as HTTPS traffic, obviously they weren’t verifying certificates properly, as Burp was presenting its own self-signed certificate for the domain. In this case, failing connections was treated as a “success” for validation, though not all of the edge cases were being tested. (We didn’t check for valid chain, but wrong domain, or valid chain + domain, but expired or not yet valid, etc. There’s a lot that goes into SSL validation, but hopefully they’re using the system libraries properly.)

Then we got to recovering secrets from APKs. Sam demonstrated using apktool, which extracts and decompiles APKs to smali (a text-based representation of Dalvik bytecode), to look for things like hard-coded keys, passwords, and other relevant information. Using apktool is definitely an interesting approach, and shows how trivial it is to extract information from within the APK.

Next Sam started talking about what he called “code injection.” He pointed out that you could take the smali, modify it (such as to log the username & password entered into the app) and then recompile & resign the app, then upload the new version to the play store. He claimed that this is a security risk, but I quite frankly don’t agree with him there. It’s always been possible for an attacker to provide malicious binaries, including those that look like legitimate software. Though decompiling, modifying, and recompiling may reduce the bar for the attacker, it’s still the same attack. I’m not convinced this is a new threat or really can be mitigated (he suggests code obfuscators), but I think there’s room for disagreement on this one.

If you’re interested in the details, you can find Sam’s course materials online.

OpenCTF

OpenCTF is the little brother of the DEF CON CTF, with anyone able to play. There are a wide range of challenges for any skillset, and even though we didn’t spend a whole lot of time playing, we managed a 10th place finish. (Team Shadow Cats). One of my favorites was aaronp’s “Pillars of CTF”, which took you on a tour through the various areas commonly seen in CTF: reverse engineering, network forensics, and exploitation. Each area was relatively simple, but it had great variety and just enough challenge to make it interesting. Other challenges included web challenges with a bot visiting the website (so client-side exploitation was possible), more difficult PCAP forensics, and plenty of reversing. I haven’t played much CTF lately (before the week in Vegas), but it was really good to get back into it, especially since this was more of a Jeopardy-style CTF than the Attack/Defense in Pros vs Joes.

Capture the Packet

I don’t do any network forensics at work, but I find it a fascinating area of information security. Every year (save one) I’ve been to DEF CON, I’ve played in the “Capture the Packet” challenge. Basically, you get a network port on a 100Mb network, and a set of ~15 questions, and you need to find the answers to the questions in the stream of network traffic. Questions range from “What is the password for ftp user x?” to “There was a SIP call between stations 1001 and 1002. What was the secret word?” It’s non-trivial, and will stretch anyone but the most seasoned incident responder, but it’s a great opportunity to exercise your Wireshark skills.

Pro tip: I like to separate capture from analysis. If you live capture in Wireshark, it gets slow, and when the number of packets is too large, filtering becomes extremely laggy. Instead, I’ll start tcpdump in a shell session, then analyze the pcaps with Wireshark or other tools. (I’m contemplating writing a collection of domain-specific tools just for fun, and to help in future CTPs.) If you’re not a tcpdump expert, the command line I use is something like this:

1
tcpdump -i eth0 -s 0 -w packets -C 100

What this does is capture on interface eth0, unlimited packet size, write to files named like “packets”, and rotate the file every 100 MB. This way I can keep my cap sizes manageable, but avoid too much risk of splitting connections across multiple pcap files.

If you haven’t tried CTP before, I really recommend it. The qualifying round only takes about an hour, and some years (not sure if it was this year) it’s a black badge challenge, though you need to qualify + win finals.

Thoughts on the new venue

So, this was the first year at Bally’s/Paris combined, and it wasn’t without growing pains. The first couple of days, traffic was crazy, especially near the Track 1-4 areas in Paris, but the Goons quickly adapted and got the traffic flowing again (making one-way lanes really helped).

The best part was being on the strip. It meant it was easy to get to restaurants outside the venue without cabbing, and it was a much more attractive hotel than the Rio. (Yay no more awkward bathroom windows!)

The worst part, however, is that the conference area at Bally’s is all the way in the back, so you have to walk a non-trivial distance between the two areas. I definitely got my 10,000 steps a day in every day that week. There’s nothing DEF CON can do about this at the current venue, and I can use the exercise.

Conclusion

I had a great time, but felt like I didn’t do as much as I had hoped. I’m not sure if this was unrealistic expectations, or just a perception of doing less than I actually did. I definitely learned new things, met new people, and generally consider it a successful year, but I’m always a little wistful when it ends, and this year was no exception. I keep telling myself I’ll do something interesting enough to end up on the stage one year – maybe 24’s my lucky number.

I’ve just returned from Las Vegas for the annual “hacker summer camp”, and am going to be putting up a series of blog posts covering the week. Tuesday and Wednesday were BSides Las Vegas. For the uninitiated, BSides was founded as the “flip side” to Black Hat, and has spawned into a series of community organized and oriented conferences around the globe. Entrance to BSides LV was free, but you could guarantee a spot by donating in advance if you were so inclined. (I was.)

As regular readers know, I play a little bit of CTF (Capture the Flag), and BSides LV is home to one of the most unique CTF competitions I’ve ever played in: the “Pros vs Joes” CTF run by dichotomy. This CTF pits multiple defending teams (Blue Cells), each consisting of Joes + 1 Pro Captain, against a “Red Cell” consisting of professional penetration testers. Even though I work in security, my focus is on Application Security and not Network Security (which PvJ highly emphasizes) so I’ve never felt comfortable playing as a pro. Consequently, this was my 3rd year as a “Joe” in the PvJ CTF. (Maybe one day I can make it through my Impostor Syndrome).

If you’re not familiar with this CTF, here’s the rundown: on the first day, each blue cell defends their network against attack by the red cell. For the blue cells, the first day is entirely defense. On the 2nd day, the red cell is “dissolved” into the blue cells. Each blue cell gained two new pros and it was blue cell vs blue cells, so we had to take on the role of both attacker and defender. It’s great fun and requires a ton of work to set up, so my hat goes off to dichotomy for organizing and running it all.

Though I’ve played in the past, this year brought new challenges and experiences. Firstly, there was significant integration between the CTF and the Social Engineering CTF. (Apparently even more than I realized when playing.) This brough interesting components, such as people trying to social engineer information out of us or get us to help them with tasks for the SECTF, but it also brough challenges, the most significant of which was people who joined the CTF solely to gain information to help them with the SECTF. It’s my hope that next year, team captains will be allowed to “fire” team members that are obviously attempting to “leak” information.

There were other changes as well. In the past, there were two blue cells and one red cell, this year dichotomy managed to up it to a whopping four blue cells! This brought us a total of 44 players, which was obviously no small feat for both dichotomy and the conference organizers. There was also a greater emphasis on the use of “tickets” in the scoring system. Now, I’m not a fan of the tickets myself. Most of them consist of boring inventory or asset management work, and it’s often not clear exactly what response is expected to them. Hopefully this is the sort of thing that will be tweaked by next year. (As it was, the scoring tweaks dichotomy made to the ticket system between the first and second day were a welcome improvement.)

By far, however, the most interesting change to me was obvious even upon walking in the room. As soon as I saw the tables, I noticed something new: SIP phones on each table. Yes, they were connected. To a PBX. That was in scope. And had default credentials. That was definitely new – and not something most of the teams picked up on.

All things considered, I feel that my team (“Endtroducing”) did pretty well with a 2nd place finish. The first place team just seemed unbeatable. I don’t know if it was a different ratio of attack/defense, luck, different skills or what, but it worked out well for them.

In the next week or so, I’ll be writing a blue team player’s guide based on my 3 years of experience. It’ll expose some things about the play environment that have been constant for the 3 years, some tactics I’ve used, and just some general guidance on preparing for the Pros vs Joes CTF.

Despite the fact that it’s been over 2 years since I posted Part 1, I got bored and decided I should take another look at the Patriot Gauntlet Node. So I go and grab the latest firmware from Patriot’s website (V21_1.2.4.6) and use the same binwalk techniques described in the first post, I extracted the latest firmware.

So, the TL;DR is: It’s unexciting because Patriot makes no effort to secure the device. It seems that their security model is “if you’re on the network, you own the device”, which is pretty much the case. Not only can you enable telnet as I’ve discussed before, there’s even a convenient web-based interface to run commands: http://10.10.10.254:8088/adm/system_command.asp. Oh, and it’s not authenticated. Even if you set an admin password (which is hidden at http://10.10.10.254:8088/adm/management.asp).

The device runs two webservers: on port 80 you have httpd from busybox, and on port 8088, you have a proprietary embedded webserver called GoAhead. It uses not ASP, as the file extensions would have you believe, but actually uses an embedded JavaScript interpreter called Ejscript to generate active pages.

I don’t intend to spend much more time on this device from a security PoV: it doesn’t seem intended to be secure at all, so it’s not like there’s anything to break. The device is essentially pre-rooted, so go to town and have fun!

I’ve been disappointed with myself for a while for not updating more often. It’s been months! I’d been pushing myself to update regularly, but I also only want to update with genuine content. Social networks are places where I can just place random thoughts, this is a place for meaningful content that will (hopefully) be useful to others. (Though the jury’s still out on that one.)

Part of the reason for the lack of updates is burnout. For one reason or another, I just haven’t been feeling myself for a while, and so haven’t been doing as many interesting things. Some of this burnout is due to the nature of things I’ve been doing at work, but it wouldn’t be fair to blame all of it on work.

I’ve also been dealing with some (potential) health issues. Mostly it’s been a case of symptoms with no obvious cause, which is even more maddening to me. Despite reassurances from doctors, I can’t help but have a nagging feeling that something is actually wrong. It’s quite the distraction, psychologically.

So, in more timely news, I’ve made the transition from “20s” to “30s” (two weeks ago). When I was 25, I posted asking if 25 was old, because I felt like I hadn’t accomplished anything. Though I think I’ve accomplished a few things in the interceding time, I’m not convinced it was 5 quality years worth. I need to get better at prioritizing my time and making sure that I use my time in good ways. I’d like to make sure I’m either doing something I enjoy, something meaningful, or something helpful to others. Anything else is just a waste of precious time.

The consensus in the security community is that passwords suck, but they’re here to stay, at least for a while longer. Given breaches like Adobe, …, it’s becoming more and more evident that the biggest threat is not weak passwords, but password reuse. Of course, the solution to password to reuse is to use one password for every site that requires you to log in. The problem is that your average user has dozens of online accounts, and they probably can’t remember those dozens of passwords. So, we build tools to help people remember passwords, mostly password managers, but do we build them well?

I don’t think so. But before I look at the password managers that are out there, it’s important to define the criteria that a good password manager would meet.

1. Use well-understood encryption to protect the data. A good password manager should use cryptographic constructions that are well understood and reviewed. Ideally, it would build upon existing cryptographic libraries or full cryptosystems. This includes the KDF (Key-derivation function) as well as encryption of the data itself. Oh, and all of the data should be encrypted, not just the passwords.

2. The source should be auditable. No binaries, no compressed/minified Javascript. If built in a compiled language, it should have source available with verifiable builds. If built in an interpreted language, the source should be unobfuscated and readable. Not everyone will audit their password manager, but it should be possible.

3. The file format should be open. The data should be stored in an open, documented, format, allowing for interoperability. Your passwords should not be tired into a particular manager, whether that’s because the developer of that manager abandoned it, or because it’s not supported on a particular platform, or because you like a blue background instead of grey.

4. It should integrate with the browser. Yes, there are some concerns about exposing the password manager within the browser, but it’s more important that this be highly usable. That includes making it easy to generate passwords, easy to fill passwords, and most importantly: harder to phish. In-browser password managers can compare the origin of the page you’re on to the data stored, so users are less likely to enter their password in the wrong page. With a separate password manager, users generally copy/paste their passwords into a login page, which relies on the user to ensure they’re putting their password into the right site.

5. Sync, if offered, should be independent to encryption. Your encryption passphrase should not be used for sync. In fact, your encryption passphrase should never be sent to the provider: not at signup, not at login, not ever. Sync, unfortunately, sounds simple: drop a file in Dropbox or Google Drive, right? What happens if the file gets updated while the password manager is open? How do changes get synced if two clients are open?

These are just the five most important features as I see them, and not a comprehensive design document for password managers. I’ve yet to find a manager that meets all of these criteria, but I’m hoping we’re moving in this direction.