This is a super quick post on a simple method to exfiltrate data from systems running BusyBox, a shell commonly used on embedded devices. Such systems often lack common tools, presenting a challenge when you need to move data about. When I first looked into this topic I found solutions which were too specific or complex, so I hope this post is useful.

The BusyBox man page lists commonly available commands, which currently include *deep breath*:

Fuzzing is fun. But fuzzing is even more fun when you have a solid wordlist to work with. When it comes to hunting down subdomains there are a few lists out there to plug into your fuzzer, but most are small, one-shot affairs. I set out to build a list of popular subdomains which was comprehensive and could be easily kept up-to-date.

For this project I needed to get hold of DNS records. A lot of DNS records. After trying various sources, I settled upon Rapid7's Project Sonar Forward DNS data set, which includes "... regular DNS lookup for all names gathered from the other scan types, such as HTTP data, SSL Certificate names, reverse DNS records, etc". Rapid7's data set uses a really nice mix of real-world sources and is regularly updated. Perfect.

The first challenge was how to handle 1.4 billion (68 GiB) raw DNS records in a reasonable amount of time; my first attempt at processing the data took well over a week to complete on a reasonably beefy server, hardly ideal for updating frequently.

I'd like to start by saying that the company involved has my full respect for handling security in a mature manner and actively seeking researchers to take a deep look at their products. It's important to note that during testing I did not access personal data or files belonging to users other than my own.

Onto the chase.

It was a cool, dark night. The world was still, the bounties were calling. One in particular caught my eye. It had been running for nearly two weeks so I wasn't expecting to find many new bugs, but sometimes you get lucky. It was a time-limited affair, and with 24 hours left on the clock I decided to try my luck. At first I didn't find much - the odd information leak, header injection, an XSS, nothing that hadn't been reported half a dozen times. But then...

It's not every day you find a CSRF-RCE, where sending an admin to a malicious webpage gives you a shell on their server, but that's what I discovered while exploring the security of the Oculus developer portal. But I’m getting ahead of myself.

Oculus, known best for their Oculus Rift virtual reality headset, was founded in 2012 and quickly grew, raising over $2 million through Kickstarter for their first VR development kit, the DK1. Development continued towards the DK2, and in March 2014 Facebook announced that they would acquire Oculus VR for $2 billion, placing the Oculus websites in scope of the Facebook whitehat bug bounty programme in August 2014. That's when I decided to take a look.

Tesla Motors are cool. Founded by Elon Musk of PayPal and SpaceX fame, they design, build and sell next generation electric cars, which with the right infrastructure could help mitigate global warming and improve the quality of life in general. I'm into that, so when they launched a security responsible disclosure programme I took a look.

Tesla make extensive use of Drupal with a handful of plugins, and security is pretty tight. With a few hours poking around I'd covered most of the site and found a few XSS vulnerabilities, a couple of which were hard to exploit, and an easier to exploit vector in a non-Drupal script I found referenced in a commented out link.

I'd like to use my last blog post of the year to sum up five vulnerabilities I found in Google Sites during the course of the year. Google Sites grew out of JotSpot, a site creation service bought by Google in 2006 and made free to use in 2008. A multi-tiered permission system and multitude of customisation options makes Sites an interesting target to investigate.

For these issues Google awarded a total of $13,034.80, making Sites the most rewarding Google property I've looked at so far. The first four vulnerabilities described here earned Google's celebrated $3133.7 bounty, the last $500.

Historically, password security in PHP has been a bit slippery, requiring a measure of knowledge and care. Aiming to change that, PHP 5.5 introduces a special password_hash() function which makes password security much easier, and with features such as automatic algorithm upgrading, even more robust. There's also a compatibility library for PHP >= 5.3.7.

If you've ever looked at login code, the chances are you've seen developers using hash('sha256', $password), or even md5($password) to "secure" user passwords. Password hashes generated this way are laughably easy to crack; with weak algorithms and no salting or stretching in place you're almost giving your passwords to an attacker who gains access.

I was reminded by a recent article of an obscure and dangerous property of PHP's preg_replace() function which can lead to code execution in some not-all-that-uncommon circumstances. I recently found some code vulnerable to this attack in the wild, so I thought I'd put together a quick writeup for pentesters and PHP coders who may not be familiar with the danger.

Let's start with a code example:

<?php
$in = 'Somewhere, something incredible is waiting to be known';
echo preg_replace($_GET['replace'], $_GET['with'], $in);
?>

The code will take a user-supplied regular expression and replace whatever it matches with a user-supplied string. So if we were to call preg_replace.php?replace=/Known/i&with=eaten, the script would perform a case-insensitive regex search (the i modifier) and echo Somewhere, something incredible is waiting to be eaten. Seems safe enough, right?

Google's vulnerability reward programme gets a lot of attention, and includes not just Google's main websites, but also those of acquisitions older than 6 months. With this in mind, I thought I'd venture off the beaten path and take a look at Admob, one of the world's largest mobile advertising platforms according to Wikipedia.

Admob was acquired by Google for $750 million in November 2009, putting it well beyond the 6 months Google ask to patch up new arrivals, but also giving plenty of time for vulnerabilities to be found and fixed. At first glance things looked fairly good for Admob, but there was a nice little stored XSS waiting a little way under the surface.

I received an order from Amazon the other day which had a URL printed on the side of the box leading to the packaging feedback form. Amazon have a vulnerability reporting programme and I had a spare 20 minutes, so I thought I'd have a look to see if there were any obvious security vulnerabilities.

After a few dead ends I noticed that the form used a hidden input field named failureRedirect, which when set was followed when invalid user input was submitted. After testing, it seemed that the URL could be set to any domain as long as it started with a valid protocol; an open redirect. But there was more…