Continuing my Hacker Summer Camp Series, I’m going to talk about one of my Hacker Summer Camp traditions. That’s right, it’s the Pros versus Joes CTF at BSidesLV. I’ve written about my experiences and even a player’s guide before, but this was my first year as a Pro, captaining a blue team (The SYNdicate).

It’s important to me to start by congratulating all of the Joes – this is an intense two days, and your pushing through it is a feat in and of itself. In past years, we had players burn out early, but I’m proud to say that nearly all of the Joes (from every team) worked hard until the final scorched earth. Every one of the players on my team was outstanding and worked their ass off for this CTF, and it paid off, as The SYNdicate was declared the victors of the 2016 BSides LV Pros versus Joes.

What worked well

Our team put in incredible amounts of effort into preparation. We built hardening scripts, discussed strategy, and planned our “first hour”. Keep in mind that PvJ simulates you being brought in to harden a network under active attack, so the first hour is absolutely critical. If you are well and thoroughly pwned in that time, getting the red cell out is going to be hard. There’s a lot of ways to persist, and finding them all is time consuming (especially since neither I nor my lieutenant does much IR).

We really jelled as a team and worked very, very, well together on the 2nd day. We hardened faster than I thought was possible and got our network very locked down. In that day, we only lost 1000 points via beacons (10 minutes on one Windows XP host). Our network was reportedly very secure, but I don’t know how thoroughly the other teams were checking versus the “low hanging fruit” approach.

What didn’t work well

The first day, we did not coordinate well. We had machines that hadn’t been touched for hardening even after 4 hours. I failed when setting up the firewall and blocked ICMP for a while, causing all of our services to score as down. I’ve said it before and I’ll say it again: coordination and organization are the most important aspects of working as a team in this environment.

The Controversy

There was an issue with scoring during the competition where tickets were being counted incorrectly. For example, my team had ticket points deducted even when we had 0 open tickets: the normal behavior being that only when you had a ticket open would you lose points. This resulted in massive ticket deductions showing up on the scoreboard, which Dichotomy was only able to correct after gameplay had ended. This was a very controversial issue because it resulted in the team that was leading on the scoreboard dropping to last place and pushed my team to the top. The final scoring (announced on Twitter) was in accordance with the written rules as opposed to the scoreboard, but it still was confusing for every team involved.

Conclusion

Overall, this was a good game, and I’m very proud of my lieutenant, my joes, and all of the other teams for playing so well. I’m also very appreciative of the hard work from Dichotomy, Gold Cell, and Grey Cell in doing all of the things necessary to make this game possible. This game is the closest thing to a live fire security exercise I’ve ever seen at a conference, and I think we all have something to learn from that environment.

Just returned from Hacker Summer Camp (Black Hat, BSides LV, DEF CON) and I’m exhausted. 10 days in Las Vegas is a lot of Las Vegas, even if you don’t spend a lot of time at the slot machines, table games, and shows.

My week started off with a training class at Black Hat: Hardware Hacking with the Hardsploit Framework taught by a couple of guys who clearly knew their hardware. I’ve previously taken Xipiter’s Software Exploitation via Hardware Exploitation, which helped with some of the basic concepts, but the two classes were definitely complimentary. SexViaHex predominantly focused on dumping firmware from embedded microcomputers (that is, they had a kernel, typically Linux, and were running applications on them) and analyzing them for exploitable software vulnerabilities (mostly memory corruption-esque issues). HH with Hardsploit, on the other hand, mostly focused on microcontroller-based embedded devices. This was much more a class of dumping flash to locate stored secrets, understanding the hardware of the device, and working from there.

I’m not going to list every thing taught in the class (I don’t think the authors would like that much) but I’ll cover my highlights:

• Unlocking an electronic door lock (actually a dummy PCB to simulate an electronic door lock with keypad)
• Use GNURadio and an SDR to locate, identify, and receive an unknown wireless protocol. We then had to write scripts to decode the received data and understand this wireless protocol.
• Use the techniques we learned before to do a drone CTF capstone consisting of trying to reverse engineer your drone, patch the flaws, and then exploit the flaws against other drones. (Unfortunately, I feel there wasn’t enough time left by this point, so we weren’t able to get all the way through this exercise.)

This was only a two-day class, but I believe I learned a ton of new things and got to exercise some skills I don’t get to touch very often. It was an intense experience, and I’d rather think they could do so much more ina 4-day format. I would have no doubts about recommending this class to others, or to taking another (more advanced) class from Opale.

As far as Black Hat Trainings are concerned: well, it includes breakfast and lunch, which is nice, but the food is literally the worst food I had in Las Vegas all week. It was completely stereotypical hotel ballroom food: breakfast was fruit platters and pastries with mediocre coffee and bottles of juice, and lunch was a random assortment of “banquet quality” items (i.e., pasta that wasn’t drained properly so is now sitting in a puddle, salads that are swimming in dressing, etc.). There was also an afternoon coffee/tea service each day, which was surprisingly nice (though swamped by attendees). Having coffee all day long for trainings would have helped my brain, but YMMV.

Next I’m off to BSides Las Vegas and Dichotomy’s Pros versus Joe’s CTF.

For many of the tools on Kali Linux, it’s easiest to run them as root, so the defacto standard has more or less become to run as root when using Kali. Google Chrome, on the other hand, would not like to be run as root (because it makes sandboxing harder when your user is all-powerful) so there have been a number of tricks to get it to run. I’m going to describe my preferred setup here. (Mostly as documentation for myself.)

Download and Install the Chrome .deb file.

I prefer the Google Chrome Beta build, but stable will work just fine too. Download the .deb file and install it:

1
dpkg -i google-chrome*.deb

If it’s a fresh Kali install, you’ll be missing libappindicator, but you can fix that via:

1
apt-get install -f

Getting a User to Run Chrome

We’ll create a dedicated user to run Chrome, this provides some user isolation and prevents Chrome from complaining.

1
useradd -m chrome

Setting up su

Now we’ll setup su to handle the passing of X credentials between the users. We’ll add pam_xauth to forward it, and configure root to pass credentials to the chrome user.

1
2
3
4
sed -i 's/@include common-session/session optional pam_xauth.so\n\0/' \
  /etc/pam.d/su
mkdir -p /root/.xauth
echo chrome > /root/.xauth/export

Setting up the Chrome Desktop Icon

All that’s left now is to change the Application Menu entry (aka .desktop) to use the following as the command:

1
su -l -c "/usr/bin/google-chrome-beta" chrome

In February, I wrote a guide to planning travel for BSides, Black Hat, and DEF CON, occasionally referred to as “Hacker Summer Camp.” In my original post, I promised an update with information about your actual travels to BSides, Black Hat, and DEF CON: what to bring, what to do, and how best to stay out of trouble. This is my best advice on that, but I’m sure others have differing opinions.

Health and Safety

I discussed the idea of managing your energy in the first post, but I can’t stress enough how important that is. Las Vegas is hot, there’s a lot going on, and so it’s easy to not realize how much you’ve burned yourself out. Take your time and don’t try to do everything – it’s not possible and you’ll make yourself sick in the process.

DEF CON 101 attendees will hear about the “3-2-1” rule. No, it’s not some new variation on the TSA’s 3-1-1 rule, it’s the guideline for personal survival at DEF CON: 3 hours of sleep, 2 meals, and 1 shower. Per day. Every day. Please follow at least this! Many days you may want to shower more than once, and I’d strongly encourage that – you’ll be packed into rooms with 15,000 of your (soon to be) closest friends, and there’s nothing that will make it harder to network and meet people than smelling like a gym with no ventilation. So I will also add: use deodorant. If you start to smell, take a shower, don’t just try to cover it up with some kind of body spray. Body spray just means you smell like sweat and some $4.99 crap you got from the checkout register.

This is a good time to mention hydration: it’s Las Vegas, which means it will be dry and hot, which is the recipe for dehydration. So is moving around a lot. So you need to always be drinking, and I don’t just mean Beer, Gin & Tonic, or Vodka & Red Bull. Drink lots of water. If at any point you get headaches, nauseated, or generally feel like crap, odds are you’re dehydrated and water will help. Money saving tip: if you want bottled water, buy water from a drugstore or convenience store on the strip (or if you’re driving, bring it with you). It will be much cheaper than buying it in any of the hotels.

Finally, a word about physical safety: keep your wits about you. DEF CON gets attendees of all sorts, and you’re in Las Vegas, a city known for clueless tourists, so there’s plenty of opportunity for thieves and other criminals. Know where your stuff is at all times, and don’t leave it unattended. Don’t look like a conference attendee outside the hotel, and if you’re out very late at night, being with others will help ensure your safety.

What to Bring

What to Wear

Read the weather forecast, but you can pretty much count on hot & dry. And when I say hot, I mean like 40°C (100°F +, for those of you not working in SI units). DEF CON is a highly informal conference – t-shirts and shorts or jeans are probably the “average” attire. If you want to look more professional, you’ll be fine too, unless you wear a suit. Then you’ll stick out like a sore thumb. BSides is approximately the same, Black Hat tends more towards business casual, though you’ll see plenty of t-shirts & jeans here too. Generally, wear whatever your comfortable in in hot weather.

Electronics

The network at DEF CON has been called the most hostile network in the world, but I suspect that’s a little overblown. That being said, it’s probably a good idea to treat it as highly hostile – better safe than sorry.

At a minimum:

• Backup your data in advance
• Fully patched
• Full disk encryption
• Firewall enabled
• Use a VPN & SSL-enabled sites
• Don’t click past SSL warnings

Other possible considerations:

• Don’t bring sensitive data at all
• Use a different hard drive
• Use a different device

Picking your devices

What electronics you want to bring will depend on what you want to do. Some activities will require a laptop: CTFs, Capture the Packet, Badge Hacking (most likely). If you want to participate in these or something similar, you’ll want to bring a laptop. Otherwise, I’d encourage you to leave the laptop at home, or at least in your hotel room. (Being mindful, of course, of theft and evil maid attacks.)

It’s obviously hard to go without a cell phone, but you may want to consider using a different phone from usual, for several reasons. This would give you the option to give out a number to arrange parties, events, etc., but not have them have your permanent contact information (as can various services) but also protects you against attacks on your devices. (There have been a lot of 3g/4g and mobile attacks lately, so it makes sense to pay attention there.)

Other things to Bring

• Cash: DEF CON tickets are cash-only, and you might want cash for cabs, drinks, etc. I’d recommend against using the ATMs in the immediate vicinty of the cons – you never know who’s found an 0-day or brought a skimmer!
• Notepad and pen: old fashioned note taking is sometimes the best.

Activities

There’s a lot of things to do in this week, and I’d like to focus on 3 principle ideas to help in choosing what to do:

• Don’t try to do it all – you just can’t
• Be active, not passive
• Try new things

Talks

Obviously, these conferences are best known for their talks and presentations, but I don’t actually consider those the most important reason for attending. I’ll attend a few talks, but since they’re nearly all recorded, I can always see the talks later. Attend talks that are of personal interest, but don’t force yourself to sit in the audience of a talk every hour – that’s being passive, and you won’t get as much out of things.

Villages

DEF CON hosts a number of villages each year, housing various demonstrations and activities, including the Lockpicking Village, Wireless Village, Packet Capture Village, and Tamper Evident Village. Each one will have talks and activities focusing on that particular aspect of “hacking”, and are great opportunities to learn something new from people who are extremely passionate about their niche. Some of the things you can try doing:

• Analysis of packets from the network
• Pick locks
• Try to open tamper-evident containers without leaving a trace
• Hunt for hidden wireless devices

The content from the villages is often not available anywhere else, so if you see a topic that you’re interested in, you should definitely pay them a visit.

Parties

It’s probably not a secret that there are parties in Las Vegas during this week. Many of these are great opportunities to get to know other security professionals and enthusiasts, discover what people are working on, and generally network. You never know when you might meet your next coworker. :)

Conclusion

I hope this has been helpful in your Hacker Summer Camp planning. Got a question? Check out /r/defcon or I’m @Matir on twitter.

Firtog gives us a pcap file that you can quickly see features several TCP sessions containing the git server protocol. The binary protocol looks like this in the follow TCP stream mode:

Switching Wireshark to decode this as “Git” almost works, but there’s a trick. If we read the git pack protocol documentation, we’ll see there’s a special side-band mode here, where the length field is followed with a ‘1’, ‘2’, or ‘3’ byte indicating the type of data to follow. We only want the data from sideband ‘1’, which is the actual packfile data. So we’ll grab that data using Wireshark and write it to a file, fixing up the last byte with quick python work.

Once we have the packfiles, we recreate the git repository. Begin by creating an empty git repository with git init. Then, we can use git unpack-objects < PACKFILE on each of the packfiles (in order, or else we won’t get the deltas resolved properly). Finally, to get the structure back to normal, run git fsck and you’ll see something like this:

1
2
3
4
% git fsck
Checking object directories: 100% (256/256), done.
Checking objects: 100% (21/21), done.
dangling commit 922faaf7d9a6f74eb661acc62b93b968ec3f781f

This dangling commit tells us it’s the only unreferenced commit in the repository (i.e., not referenced as a parent by a commit or merge), so let’s check that one out:

1
2
% git checkout 922fa
HEAD is now at 922faaf... a new encrypted flag :P:P

Ok, so now we’re somewhere. Let’s see what we have:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
% ls
flag.py  flag.txt  readme
% cat flag.py
#!/usr/bin/python
# Simple but secure flag generator for ASIS CTF Quals 2016

from os import urandom
from hashlib import sha1

l = 128
rd = urandom(l)
h = sha1(rd).hexdigest()
flag = 'ASIS{' + h + '}'
print flag
f = open('flag.txt', 'w')
flag_enc = ''
for c in flag:
  flag_enc += hex(pow(ord(c), 65537, 143))[2:]
f.write(flag_enc)
f.close()
% cat flag.txt
41608a606a63201245f1020d205f1612147463d85d125c1416635c854c74d172010105c14f8555d125c3c

So they grabbed some random data and hashed it, then did some exponentiation byte-by-byte to produce the output. There’s probably some better way to reverse it, but since it’s a limited character set, I just created a map of values to reverse the flag by performing the same math they did.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
% cat flagdec.py 
flag = '41608a606a63201245f1020d205f1612147463d85d125c1416635c854c74d172010105c14f8555d125c3c'

lookup = {}

for b in 'ASIS{}0123456789abcdef':
    lookup[hex(pow(ord(b), 65537, 143))[2:]] = b

i = 0
out = ''
while i < len(flag):
    try:
        out += lookup[flag[i]]
    except KeyError:
        out += lookup[flag[i] + flag[i+1]]
        i += 1
    i += 1

print out
% python flagdec.py 
ASIS{c691a0646e79f3c4d495f7c5db3486005fad2495}

(I apologize for the quality of the code, but hey, it’s CTF-quality, not production-quality.)