Wednesday, 9 November 2016

Adventures in SQLi

Adventures in SQLi

It has been a while since I've posted any real content on this blog, mainly just due to being so busy with project work and not being able to get my hands dirty. However a friend reached out for some help with a client who suspected they had SQLi vulnerabilities in their webapp, I confirmed quickly that yes there's indeed injection vectors, however I always try and provide proof of concept queries that actually select something meaningful.

This was one of the harder SQLi challenges I've come across which required a great deal of thought and some unusual techniques which I've never seen documented before, this was done with the help of my brother who has a very good knowledge of SQL.

If you don't know much about MySQL and SQLi using UNION queries then first read my guide here. This will familiarize you with the basics of UNION based SQLi and give you a point of comparison to see what I did differently here.

Testing for vulnerability

Our attack vector is a search form on the front page of an e-store, for obvious reasons I've masked the domain name. Let's put in hello as our search term, we find that our URL parameter on the search results page is searchStr.


Let's put an apostrophe in and try and break the SQL. hello'


Bingo, an error page 

1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '[[:>:]]' OR I.description RLIKE '[[:<:]]hello'[[:>:]]' OR I.productCode RLIKE '[' at line 1

Looks like we're dealing with a prebuilt shopping cart CMS called CubeCart. The entire query is dumped to screen which is handy, but I'll just use the first part

SELECT DISTINCT(I.productId), I.*, AS SearchScore FROM CubeCart_inventory AS I, CubeCart_category AS C WHERE ( RLIKE '[[:<:]]hello'[[:>:]]' OR 

So it looks like they are using a RLIKE which is RegExLIKE, and they're padding the search team with RegEx symbols which I've never seen used before, I'm taking a stab in the dark that this is essentially the equivalent of a LIKE '%hello%'

Let's see if we can escape out of the string and comment out the rest of the query and close this off to not throw any errors, this means closing off our open parenthesis and adding a comment, our input becomes


Notice that comments caused by double hyphen require a space between them and other SQL, also note that + in the URL is converted to the space character, you could equally use %20. What I expected was for this to be valid SQL and query abnormally but fundamentally still parse and not error, but what we get instead is this error.

SELECT DISTINCT(I.productId), I.*, AS SearchScore FROM CubeCart_inventory AS I, CubeCart_category AS C WHERE ( RLIKE '[[:<:]]hello')[[:>:]].*[[:<:]]--[[:>:]]' OR 

OK what is going on here? It's immediately obvious that they're conditionally building this query, and when they detect a search string that contains a space that it's treated as multiple search terms rather than a single string.

This means that more of these RegEx terms are inserted between the "words" and this fundamentally makes writing any kind of SQL that contains spaces, impossible. The first thing that came to mind is using a non breaking space this will parse with SQL quite nicely as a regular space however might not be treated as a break in the search string by PHP, and indeed this is the case. The URLencoded version of this character is %A0, so now we have to substitute every space with this character in our injection.


This parses correctly without error and neatly closes off the query and renders the search results page as expected.

So we do the normal thing while probing for UNION based SQL attacks, we want to UNION our own data set onto the bottom of a legit result set, this means knowing the right number of columns in the result set otherwise our UNION will fail with an error stating that we have an unequal number of columns. The typical trick is to tease out the number of columns with an ORDER BY, you can give this operator a number and if the column exists then it will order the results, if it doesn't exist you'll get an error saying so.

Let's try ORDER BY 10

No error, 20?
No error, 40?
No error, 50?

Finally an error, dialing back the order by value I teased out the final value as 41

The next step is to UNION that query with my own, just a comma separated string of values, typically you'd name these something unique so that when the final page renders out you can see which of these value is returned back to the page and is visible to be used for data exfiltration. Let's just use consecutive numbers.


And we enormous error.

SELECT DISTINCT(I.productId), I.*, AS SearchScore FROM CubeCart_inventory AS I, CubeCart_category AS C WHERE ( RLIKE '[[:<:]]hello')�union�select�1[[:>:]].*[[:<:]]2[[:>:]].*[[:<:]]3[[:>:]].*[[:<:]]4[[:>:]].*[[:<:]]5[[:>:]].*[[:<:]]6[[:>:]].

I've cut this short because the error is so large but you can see the pattern. Given what we know about this search form it's easy to guess that it's also treating commas as breaking up words in the same way that space does. So all we have to do is write SQL with no commas in it right?


OK so the first obvious thing to try is various different encodings of comma and different kinds of commas from the extended character sets, there's all sorts of different ones you can find, some are documented here.

Sadly none of these worked, MySQL is pretty strict about this, and all my attempts to find a character that worked with MySQL and parsed properly but didn't also split the search term, basically failed.

There's only one thing for it, we need to create a data row in MySQL without actually using any commas at all, after a while of faffing about trying several different methods we found something that worked. You can build a row of data simply creating temporary tables each with one column and then left joined. The principle works like this:

LEFT JOIN (SELECT 'b')t2 ON t1.a=t2.b OR 1=1
LEFT JOIN (SELECT 'c')t3 ON t1.a=t3.c OR 1=1
LEFT JOIN (SELECT 'd')t4 ON t1.a=t4.d OR 1=1
LEFT JOIN (SELECT 'e')t5 ON t1.a=t5.e OR 1=1

Jesus, OK we need 41x of these things, and we need to replace the spaces with non breaking spaces, what's the total length of this url? Well it exceeds 2500 characters. What's the standard for URL limits, well that's revised to 8000 octets but a lot of web servers won't deal with above 2048 characters, so fingers crossed...


And there you have it, the query executes just fine, returns the results page and hey presto field 10 is visible on the page.

There was a few other challenges using this, you can no longer use the common steps you'd normally see recommended with UNION based SQLi, so a lot of improvisation is required, to read something like the information_schema.tables database to see what tables were available was required to be entirely nested inside the 10th column, here's the relevent snippet.


This becomes:


This was throwing illegal mix of collations errors and so some of the tricks I've written about here helped, for some reason unhex(hex()) didn't work but uncompress(compress()) did, which gives us:


In the end I manged to read the database tables out, the columns out. This CubeCart CMS has an admin table with credentials inside, so this turned out to be extremely high risk. I think this post just goes to show how powerful SQL is and what you can do with when you're working inside restricted conditions. It also goes to show that if you want to be good at injecting sites you can't just follow pre-written guides, you need strong SQL knowledge in order to deal with anomalies like this.

Happy Injecting!



It's been a while since I attended DefCon24, my very first Con as it's expensive to fly from the UK, I really enjoyed myself this year and am determined to get back next year. This is just an update post to say that I've secured attendance next year as well, so I will be at DefCon25 with friends.

Part of what makes the experience really great is meeting other like minded people, so if you like this blog and want to get a beer together next year then hit me up on Skype: FrostyHacks

Tuesday, 11 August 2015

The substandard security practices of MSI

MSI and their substandard security practices.
This post is just a quick rant to highlight some issues with MSI who are primarily a hardware manufacturer, I decided to take a look through their sites for vulnerabilities in the hope they'd reward some merch for finding vulnerabilities - a long shot but worth a go right?
I pretty quickly found 2 XSS vectors on their pages, you can find them at the links below although they have subsequently been fixed:
I attempted to get in touch with them, sadly that provided much harder than I first thought, I looked for emails I could contact but they have nothing on their sites, I tried opening a ticket with their support system who provided to be incredibly unhelpful. I then went to their forums which apparently none of the staff work for MSI and aren't in touch with MSI. It was funny to scroll down the page and find other hackers registering on the forum to request exactly what I was, an email address to send sensitive vulnerability disclosures to, it seems like I'm not the only one that struggled to get a hold of them. I even tweeted their twitter accounts asking for directions to submit vulnerabilities with no reply - they've made it very hard work to get in touch with someone who could get this information to the right staff.
In the end I was contacted by a member of MSI team called Rex, he said he'd heard about that I'd found bugs on the site, so someone somewhere passed this info along but I have no idea where from, I wrote up a complete report on the vectors plus some other vulnerabilities I was concerned about.
I didn't get a single reply, I followed up asking if they wanted to discuss responsible disclosure and what time limit they wanted me to adhere to when disclosing the bugs, but again no reply, so I'm taking that to mean they don't care, so I've published them here.
They have been fixed as of testing today, and by fixed I mean in the weakest possible sense, they still allow arbitrary HTML through onto the page in the 2nd link except they deny <script> tags, this leaves them open to god knows how many other XSS vectors.
It would have only taken them 10 seconds to write a reply to me to say thank you and that they don't supply bug bounties, but they couldn't even manage that. Not only do MSI not care about security of their websites, they have no interest in making it easy to contact them, they don't run any kind of bug bounty or even have the common courtesy to reply to people who are responsibility disclosing vulnerabilities - basically screw MSI.

Tuesday, 28 April 2015


Passive GSM interception Part 1

This blog post will cover passive GSM interception of phone calls and text messages. It will include some of the history of GSM and how it was broken, the newer tools and attack methods and finally a guide on how to set up a test bed for interception using TWILIGHT VEGETABLE a suite of tools designed to make cracking GSM as easy as possible.

Part 1 of this guide will cover the requirements and setting up the environment, part 2 will cover traffic capture and decryption.


Global System for Mobile Communications (GSM for short) is a suite of protocols designed for second generation (2G) mobile phone communication, put simply it's used extensively around the world for making calls on your mobile.

GSM comes with various security features to authenticate users on the network, it uses the SIM of the caller to authenticate the mobile device with the base station using a pre-shared key and challenge/response, once authenticated the calls are encrypted with a stream-cipher typically A5/1 for America and most of Europe, you can read more about A5/1 here.

History of breaking A5/1

A5/1 has a long history of attacks, the Snowden leaks showed that the NSA can easily decrypt calls, there's also rumors that the strength of the standard when it was first introduced into Europe was deliberately limited with an encryption key length of only 56bits, this made interception by government agencies easier. The security work carried out on GSM has largely been kept private and out of the public domain, there has been many white papers and theoretical attacks but few projects have ever released easy to use tools until very recently.

Weaknesses in a5/1 were known as far back as 1994, however attacks on A5/1 as used in GSM didn't occur until 2003 where downgrade attacks forcing phones on to the much weak A5/2 stream cipher were possible. In 2007 COPACOBANA was developed as an FPGA hardware solution for attacks on A5/1 and DES, this was the first commercially available attack tool. In 2008 a group called The Hackers Choice started a project to break GSM using rainbow tables, a time memory trade off attack, however the tables were never released in to the public domain.

It wasn't until 2009 that Karsten Nohl and Sascha Krißler announced The A5/1 cracking project at Blackhat, you can find the talk on YouTube, part 1 is here. This project is similar to prior attacks and uses a mix of time memory trade off and distinguished point chains to create 2Tb of rainbow tables, a tool for using these tables called Kraken was also released, this allowed anyone to discover a5/1 keys for encrypted portions of GSM traffic.

Use of these tools was deliberately left difficult to help stop widespread use, this is where TWILIGHT VEGETABLE steps in. TWILIGHT VEGETABLE is one of many projects that are being developed by hackers working on the NSA Playset, it's essentially a custom distribution of Kali Linux with all the tools necessary to automate GSM sniffing pre-installed. The project was introduced at DefCon 22, you can see the presentation here. The project is aimed at making cracking of GSM as easy as possible.


While the project aims to make the process of decryption as easy as possible, it is still no trivial task setting up the tools, like most security work on GSM the documentation seems to be lacking and help is hard to find. Because of this I've written the following guide which will walk you through all the steps for setting up all the tools.


Here is everything you need in order to crack A5/1 using TWILIGHT VEGETABLE, note that while the rainbow tables are about 2Tb you'll need 4Tb of disk space total.

  • 2Tb USB external hard drive
  • 2Tb of additional storage
  • 16Gb USB flash drive
  • A USB SDR dongle based off the RTL chipset - example here
  • A laptop
  • Something that can uncompress .bz2 files, for windows I recommend 7zip from here.
  • The 7Gb compressed Twilight Vegetable image from here.
  • Something to write images to the USB drive, I recommend Win32 Disk Imager from here.
  • The 1.6Tb of Kraken GSM Rainbow tables, the torrents can be found here.

Step 1 - Create a TWILIGHT VEGETABLE bootable USB

The first step is to create a bootable USB flash drive with a install of TWILIGHT VEGETABLE. First you'll need to download the TWILIGHTVEGETABLE image from the link above, you'll also need some software to extract the image from the compressed bz2 file, on windows you can use a compression tool called 7zip, linked above. Once 7zip is installed, select the file "TWILIGHTVEGETABLE-1.0.img.bz2" file and extract the image, you'll need approximately 15.2Gb of space.

Plug in your 16Gb USB flash, make sure it doesn't contain any files you want to keep, as the following steps will erase everything on the drive. 

Download and install Win32 Disk Imager from the link above. Make sure you right click the applications and "run as administrator". Open the file browser and select your TWILIGHTVEGETABLE-1.0.img file. Use the device drop down menu and select the drive letter of your USB flash drive - it's important to get the drive letter right!

Click the "Write" button to write the contents of the img to the USB key, once this is finished you will have a bootable USB flash drive with all the tools you need.

Step 2 - Prepare your external 2Tb HDD

This next step is to create DRIZZLECHAIR by writing the rainbow tables into a partition on the external drive, they cannot simply be copied on to the drive, they're inserted inside a partition using a special tool, this is why you need an additional 2Tb of space on top of the 2Tb external drive.

Turn off the computer you want to use for copying the tables and insert your TWILIGHT VEGETABLE USB drive, then boot the machine from the USB key, in some cases this will happen automatically, otherwise you'll need to enter into your BIOS settings and set the boot order to boot from USB first, if you need to do this consult your motherboard manual for BIOS instructions. Once you've booted off the USB drive, select persistent mode to load Kali.

First you need to identify which mount name your 2Tb drive has, this step is crucial because if you get this wrong you'll delete the partitions on the wrong drive and if you accidentally delete the rainbow tables you'll be extremely mad. For the rest of this tutorial I'm going to use the mount name "sdz" you need to replace all instances of "sdz" in the instructions with your mount point name for the external drive, this will be different depending on your system. I am not responsible for any data loss if you do these steps incorrectly!

Open a terminal window and enter the following commands one at a time, remembering to replace ALL instances of sdz with your mount name.

umount /dev/sdz1
parted /dev/sdz rm 1
parted /dev/sdz mkpart primary 0g 5g
parted /dev/sdz mkpart primary 5g 100%
partprobe /dev/sdz
mkfs.ext3 -L DRIZZLECHAIR /dev/sdz1
e2label /dev/sdz1 DRIZZLECHAIR
partprobe /dev/sdz

These commands will mount the drive, remove any existing partitions, then it will create a 5Gb partition at the start of the drive (sdz1) where you can store the tools if you wish, and then create a 2nd partition (sdz2) which fills the rest of the drive which is where the rainbow tables will live, finally we format sdz1 with a file system and give it the label DRIZZLECHAIR. The drive is now prepared.

Step 3 - (OPTIONAL)

This step is optional depending on where you store your rainbow tables, if they're on a local disk attached to the computer you're booting off then skip straight to step 4.

For me the tables are shared on a file server on my network since my laptop doesn't have 2Tb of internal disk space, this step covers connecting Kali to a network share so you can copy files across the network. Beware this method is much slower than copying from an internal drive, an internal drive copy speed will take approximately 10 hours but across a wireless network it took about 3 days.

To connect to a windows share I installed cifs because I had trouble getting smb working, to install cifs make sure you have internet access, open a terminal window and type:

sudo apt-get install cifs-utils

Now create the mount point you want to use, you first need to create a new folder which I made at /mnt/gsm

cd /mnt/
mkdir gsm

Then you can mount your network share with the following command, replace "###.###.###.###" with the IP address of your network share, and "sharename" with the name of the shared folder. The 2nd path is where the share will be mounted to.

mount -t cifs //###.###.###.###/sharename /mnt/gsm

Double check you can browse this directory, if you get a permissions error make sure to set the shared folder settings to allow guest/anonymous access.

Step 4 - Preparing tools for use

The tool to insert the tables on to the drive is called TableConvert it's not actually compiled into the binaries so we need to do that first. Open a terminal window and browse to the TableConvert directory with:

cd /root/kraken/TableConvert

then compile the binaries by typing:

make TableConvert

We're not going to use this tool directly, we're going to use a wrapper called which is a python tool already on the system in the /root/kraken/indexes directory. However the version that comes with the current version of TWILIGHT VEGETABLE is out of date and requires some extra work sym linking directories before use, it's just easier to download the latest copy of with this already fixed. You can download this on github here, make sure to place it in the index directory and overwrite the current one.

Next we need to set up the config file which will point TableConvert to the right partition to insert the tables into. You need to make a copy of the sample conf file, in your terminal window type:

cp tables.conf.sample tables.conf

Now open this new tables.conf file for editing and remove the list of example devices and replace them with your drive and partition, the partition number will be 2, remember to replace sdz with your drive name. It should look something like this:

#Devices: dev/node max_tables
Device: /dev/sdz2 40
#Tables: dev id(advance) offset

The max tables value is set at 40 because there's 40 individual tables and we want them all on the same drive. Make sure to save changes to this file.

The last step is to copy all of the files from the /root/kraken folder in to the 5Gb partition at the start of the drive, when the tables are inserted into the external drive during the next step, index files are generated in the /indexes/ folder which are about 3.2Gb total, if you only have a 16Gb flash drive then you'll run out of space.

Mount the first partition of your DRIZZLECHAIR drive somewhere so you can get access via the terminal, I created a new directory in the /mnt/ folder called drizzlechair first,

cd /mnt/
mkdir drizzlechair

Then in a terminal type the following, remember to replace sdz with your drive name.

sudo mount -t ext3 /dev/sdz1 /mnt/drizzlechair

Copy the entire kraken folder to the DRIZLLECHAIR drive

cd /root/kraken
cp -R * /mnt/drizzlechair/kraken

Step 5 - Inserting the rainbow tables into the partition

Now to start the copy, make sure if you're using a laptop the power cord is in and nothing will interrupt the copy process, this step takes a long time. In a terminal window type:

cd /mnt/drizzlechair/kraken/indexes

Now type the following replacing "/mnt/gsm" with the directory you've stored the rainbow tables.

sudo python /mnt/gsm

Sit back and relax, you'll get info pop up on the screen to tell you what table is currently being copied, you have a 10 hour wait from an internal drive or a something closer to 72 hours across a network.

Step 6 - The you dun goof'd step (OPTIONAL)

If for any reason the process is interrupted you can resume it, you'll first need to make note of the last table name that was being written to the drive. Simply trying to resume it by running Behemoth again will it will skip all the tables, you need to remove entries from the tables.conf file 

Open the tables.conf file for editing and you'll see this file now has an entry for all the tables, one per line, simply delete the lines of the tables that have not been written including the the last partially written one, save changes to the file. Now delete any index (.idx) files in the indexes directory for any tables that weren't written, they're given the same name as the table number.

Then run Behemoth again, it will skip all the other tables with entries in tables.conf and resume where it ended.

Step 7 - Testing

Lastly we test Kraken, switch to the kraken directory

cd /mnt/drizzlechair/kraken/Kraken

Run Kraken and give it the directory where the indexes are stored

./kraken /mnt/drizzlechair/kraken/indexes

Now run the test command


It should run a test string of binary, a reasonable speed from an external drive is about 160 seconds on average, I get about 180-185 seconds but it depends on your hardware, USB version, drive speed etc.

Next time on FrostyHacks

In part 2 of this guide I will cover capturing GSM traffic with a USB RTL-SDR device and the steps to extract the keys to submit to Kraken. It will be available as soon as I've got everything working myself!

I appreciate any comments and feedback both positive and negative, especially if there's any mistakes that need correcting. You can also contact me on Skype for help or if you're willing to assist with the SDR steps. SkypeID: frostyhacks

Wednesday, 8 April 2015

Pixies Pwn WPS

WPS hacked again.

The department of "so what else is new" brings you another couple of attacks against Wi-Fi Protected Setup (WPS), a feature available on most WPA enabled routers. The original attack is known as Pixie dust and is based on the security research of Dominique Bongard. You can find his video presentation here and slides here.

This blog post will go through an in depth description of what WPS is, a history of some older attacks, why those attacks are generally not sufficient today and finally a close look at the premise behind the new vulnerabilities that these new attacks exploit so you can learn how they work. Finally I will introduce the brand new tools and their authors as well as a tutorial for use.

What is WPS?

Wi-Fi Protected Setup is a feature found on most modern home routers which makes connecting devices much simpler, there's several methods for connecting wireless devices to the network however the vulnerable method is the PIN method which is what these attacks target.

When doing a WPS PIN connection, you simply provide an 8 digit numeric PIN for the network you want to join, the device handshakes with the network and if the PIN is correct it joins the network, simple right? Behind the scenes what is really occurring is a handshake between the device and Access Point (AP), they both exchange the WPS PIN in a secure way to do a mutual authentication, if the PIN is correct the password which protects the WPA network is sent to the device and the device uses that to authenticate against the AP.

The WPS PIN is normally set with a default value when the router is shipped and will appear in the documentation or on a sticker on the physical AP device. Most routers allow you to enable or disable WPS and some even let you pick a new PIN which might be randomly assigned or user defined.

Prior WPS weaknesses

The history of weaknesses in WPS and specific implementations is embarrassing to say the least, here are some of the prior vulnerabilities I'm aware of.
  • Manufacturers picking unique PINs for each of the routers they ship which are derived in some way from the unique MAC address of the router, see here. The MAC address is publicly beaconed for all wireless networks and can be passively sniffed allowing users to derive the PIN from the MAC.
  • Brute force attacks such as Reaver created by Craig Heffner exploit several weaknesses in the PIN exchange that reduce brute force attacks down to at most 11,000 PIN attempts which can be done within a few hours providing routers didn't have any kind of throttling with attempts or WPS lockout.
  • Some older routers would not disable WPS despite it being shown as disabled in the config page, this lead to some people thinking they are safe disabling WPS when really they were still vulnerable.
These vulnerabilities were very serious and in most new routers seem to be fixed, modern WPS enabled routers tend to throttle WPS attempts as per the specifications, often they will disable WPS all together after a certain number of failures. Step in Pixie dust.

The Pixie Dust attack

To understand how the Pixie dust attack works you need to be familiar with the WPS handshake that is performed during a WPS PIN exchange. You'll also need to know a bit about hashing and PRNGs both of which I'll give an intro to. Here is the handshake documentation for reference.

The enrolment occurs in 8 steps M1 to M8 and we're primarily concerned with steps M1-M3, to avoid confusion it's worth pointing out that the Enrollee is the AP and the device connecting is called the Registrar, it seems counter intuitive and the source of some confusion.

There's several requirements of this handshake that need to be filled in order to help keep it secure.

First of all it needs to be protected against replay attacks, these are attacks where adversaries sniff the network traffic of a genuine Registrar talking to the AP and recording the traffic, then simply replaying it back at a later date. To prevent this Nonces are used which are one time use random numbers, these are the N1 and N2 numbers in the handshake above. Because they're randomly generated for each new WPS handshake attempt it means you cannot replay back old handshake data and successfully authenticate.

Secondly, the authentication needs to be mutual. Not only does the AP need to verify that the connecting device knows the real PIN before it hands out the WPA password, but the connecting device also needs to know the AP is the genuine AP and not spoofed, before it hands over proof of the PIN. This stops hackers from putting up fake access points which wait until someone attempts to connect with a real PIN and harvesting the credentials. It also explains why the AP is handing over the PIN to the Registrar in the first place, at first this can seem counter intuitive to security of the system.

This mutual exchange of secret information is an interesting and complicated problem which is solved using cryptography. Instead of exchanging the PINs in plain text which would destroy any hope of mutual authentication, both the AP and the connecting device swap hashes of the PIN instead.


For anyone not already familiar with hashing, this is simply a mathematical function which can be applied to a plain text of arbitrary length and scrambles that text to be an unrecognizable fixed length value called the hash. Hashes are useful as it's impossible to reverse the hash back into the plain text, because of this they're typically used to protect information you want to keep secret like passwords or in this case the PIN.

The premise is that both the AP and the Registrar provide each other the hash of the PIN and not the PIN itself. This way the plain text of the PIN remains secret and is never directly exchanged. To verify the hash you are given is correct you'd simply hash your own PIN and then compare the hashes, if they're the same then you have verified the other device also knows the PIN. In reality this step is done by breaking the 8 digit pin in half and creating 2 hashes for the Enrollee and 2 hashes for the registrar.

It's worth noting that during the handshake the AP sends the Registrar these 2 hashes first in step M3. You could imagine one possible attack against this system is a brute force attack against the hashes E-Hash1 and E-Hash2.

While you cannot mathematically reverse hashes back to their plain text you can however hash every possible combination of plaintexts (for short plaintexts) and then compare the hashes and if you find a match then you know the plaintext that caused the hash, this is known as a brute force attack. Because the total number of possible PINs is very small a brute force is trivial, each half of the PIN is only 4 digits of 0-9 which puts the total number of hashes to check for the first half at 10^4, or 10,000 and the 2nd half at 10^3 or 1,000 tries (because the 4th digit is a checksum and isn't used), a total of 11,000 tries which a modern CPU can do in less than a second.

The designers of WPS knew this kind of attack would be possible so they added an extra step in the process to stop brute force attacks, they first generate 2 random numbers E-S1, E-S2 for the Enrollee, these are simply 2 strings of 128 random bits, the hashes E-Hash1 and E-Hash2 become the hash of the combined PIN + the random number.

Now it becomes impossible for the registrar to brute force the PIN out of the M3 step, you'd need to check all possible combinations of random numbers for 128bits multiplied by the number of different PINs which is computationally infeasible. However if we could somehow find the secret random numbers E-S1 and E-S2 through some other method then our brute force is simple. The Pixie dust attack uses 2 different methods to find these random numbers.

Attack 1

This is a super simple attack, a certain class of routers use static or just blank values for the 2 random number E-S1 and E-S2, the firmware for these routers can be downloaded from the manufactures websites or the source code found online to determine these keys. Obviously this is a very bad implementation of the protocol, chipsets caught doing this are only Ralink so far, however it's plausible that others are effected, it's implementation specific so individual testing is required.

Attack 2

The 2nd attack is much more sophisticated and requires some knowledge of how random numbers are generated. I'll urge you to read my blog post on Pseudo Random Number Generators (PRNGs) here first to get a more detailed overview of PRNGs and why they're insecure for use with security such as cryptography.

The layman's explanation is that PRNGs are not actually random, they're in fact entirely deterministic, they spit out a very long and predictable string of numbers and it's possible to determine the state the PRNG is in (how far it is through that large string). If you have some sample output it had previously generated you can simply run a PRNG continuously until you spot that pattern of randomness. Once you know the state the PRNG is in you can predict all future output with 100% accuracy.

In the case of Broadcom/Ecos chipsets they are using the rand() function in C which is a PRNG with an internal state small enough to easily brute force. If you look back to the handshake one thing you'll notice is that before the E-Hash1 and E-Hash2 are sent to the Registrar, a "random" nonce N1 is first created and sent in plain text.

The attack against these chipsets then becomes simple, the attacker starts the handshake and captures N1 from the access point, this is used to brute force the state of the PRNG of the access point, you run the PRNG forward another 256bits of randomness which are what is used to determine the 2x128bit keys E-S1 and E-S2. You then hash every possible combination the first 4 digits of the PIN with E-S1 and compare to E-Hash1, and the first 3 digits of the 2nd half of the PIN with E-S2 and compare against E-Hash2 to recover the entire PIN.

Once you have the correct PIN you start a new WPS handshake with the access point as normal providing the correct PIN first time and recovering the plain text password for the WPA network, this can be done with Reaver.


Unfortunately Dominique Bongard never released a proof of concept tool to demonstrate this so it's remained largely unused among hackers, until a few days ago. A hacker by the name of SoxRok2212 contacted me after discussing this attack on, he wanted to create an attack tool, I explained the methodology of the attack in more detail and he found a coder named Wiire and they produced a working tool based on PoC code provided by DataHead. Big thanks to everyone who came together to make this work, apologies for prior inaccuracy crediting the relevant parties for the final tool.

You can find Pixiewps on github here
You need a modified version of Reaver 1.5 here

If you're looking for a clear and concise demo of it in use with instruction then check out this excellent tutorial by soxrok2212 on YouTube.


As always with WPS the mitigation for such attacks is to simply disable WPS, right now it's not clear to what extent this is a problem, it's implementation specific so there could be similar flaws in other chipsets and routers which haven't been tested yet. There's a document of known affected chipsets here but it's by no means exhaustive.

Thursday, 5 March 2015

Dumping all the polygons

DIOS for error based SQLi
I've been asked by a few people to provide DIOS (Dump In One Shot) examples for the newer method of error based SQLi against MySQL databases using the polygon() function. This post will quickly cover a generic example that can be adopted for your own use. If you do not know about error based SQLi you can read up my polygon() tutorial here.


You may already be familiar with DIOS, this is a method of dumping all rows of a table using just one line of SQL. Typically when doing SQLi you're limited to retrieving single strings in your modified query, these strings are inserted into the page content for example as an article headline or an author name. In order to dump lots of data using this method we have to concatenate all the fields we want to select into a single string, we quickly run into a problem when dumping large amounts of data where we reach the limit of the concat() and/or group_concat() functions - these limits are defined by the admin on the server but by default are only 1024 characters.
In order to bypass the limit of concat we can use user defined variables and keep appending individual rows from a table to the same variable and then simply select that variable as our result. I've explained this trick in great detail within the context of a union based SQLi attack vector here, I suggest you read this and become familiar with it first if you're new to DIOS.
The form of the original DIOS looks like this, it's just a fictional example for demonstration purposes, the red characters are the user supplied input. This query simply selects a list of tables names from information_schema.tables.
URL UNION SELECT 1,(select (@) from (select(@:=0x00),(select (@) from (information_schema.tables) where (table_schema>=@ and table_schema!=0x696e666f726d6174696f6e5f736368656d61) and (@)in (@:=concat(@,0x0a,table_name))))x),3,4--
SELECT id, headline, news, author FROM news WHERE id = -51 UNION SELECT 1,(select (@) from (select(@:=0x00),(select (@) from (information_schema.tables) where (table_schema>=@ and table_schema!=0x696e666f726d6174696f6e5f736368656d61) and (@)in (@:=concat(@,0x0a,table_name))))x),3,4--


Using the MySQL polygon() function we can do an error based SQLi attack, I've done another post on that here, again I suggest you read this attack in detail and become familiar with it first.
The form of the polygon() attack looks like this, again this is just an example.
URL * from (select * from(select group_concat(table_name) from information_schema.tables where table_schema=database())a)b))

Retrofitting DIOS for use with Polygon()

A naïve attempt to combine these together would to simply paste in the DIOS inside the inner most select of the Polygon() example, this will work however we need to make several modifications. First of all we cannot use the NULL character (0x00) when we declare and set our variable @, this will get turned from a DB NULL into a real NULL character in the output and cause the result to be blank, we can exchange this for another hex character, simply replace it with 0x01.
You might also have an issue with space in the output, for this you can reduce the amount of space taken up by any aliases you have assigned, simply assign blank aliases using '' (double apostrophe).
Our final query will look something like this when combined, I've given the DIOS part a blue colour and the red for the outer polygon() part of the select to make it easier to read. * from (select * from ((select (@) from (select(@:=0x01),(select (@) from (information_schema.tables) where (table_schema>=@ and table_schema!=0x696e666f726d6174696f6e5f736368656d61) and (@) in (@:=concat(@,0x01,table_name))))x))a)b))
 Once again thanks to Benzi.

Thursday, 29 January 2015

Becoming a hacker

Advice for starting out.
This is some advice to new aspiring hackers who are just starting out and trying to learn. I get a lot of people contact me especially from who like my tutorials and want some help over Skype (Skype: frostyhacks).


First of all and most importantly, drop the agenda. More than 90% of the people who are contacting me have an agenda, they have someone they want to hack for some reason, they're learning not for the sake of gaining a deep understanding of how to hack but because they want the smallest number of steps to achieve their goal.
If you're new to hacking and your intention is to jump straight into doing illegal things and you have little knowledge then you're more than likely going to get into some serious trouble with the law. Hacking often isn't the hardest part, doing it safely and anonymously is a lot harder, picking on specific targets and remaining safe is something you should consider 6-12 months down the line.
You also need to get some perspective on the situation. Almost all hacking techniques are opportunistic, by that I mean vulnerabilities aren't something that always exist, you can test for them and if they exist you can exploit them, if they don't exist you have to move onto the next vulnerability. If you spend weeks learning SQLi and test your targets website, there's a good chance they won't be vulnerable to it. You may need to learn several different methods of attack before you find one that works. It's possible you may never be able to attack directly, some systems are just too secure.
If you're starting with an agenda then you may be extremely disappointed to know that after all that effort you still can't do it. It makes more sense to learn to hack because it interests you, if you just trying to learn to hack to get revenge on some one then just pay someone else to do it for you. You wouldn't bother to learn how an entire car works in order to fix a problem with your car, you just take it to a mechanic.

Manage your expectations

This is very important. Most people contacting me need a massive shift in their expectations with the time and effort it takes to get good at hacking. You're not going to blow through an SQLi guide in a few hours and be hacking like a pro, following instructions is not the same as learning! Computer hacking in my opinion is largely knowing more about security than your target, that means being smart, it means being educated and the path to that goal is to spend a lot of time learning and practicing.
If you're consumed with trying to meet your agenda of revenge then you're probably trying to blow through a tutorial or guide as quickly as possible and getting stuck and confused and probably extremely frustrated. If this sounds familiar you need to stop for a moment and re-adjust your expectations - you won't be hacking in a few hours or days, you need to consider that you'll spend weeks or months at getting good at a handful of disciplines.
If you're hopelessly lost on advanced tutorials then you'll have to go back and learn the basics first and I generally advocate this in my guides, you need to learn some JavaScript before you can do XSS and you need to learn some SQL before you can do SQL injection. Again with the car analogies, it'd be like trying to learn to tune your engine without first knowing what the components are and how they work.

Help yourself

Start learning to help yourself, don't rely on hand holding, go out and search for guides and tutorials in the types of hacking you want to do and be proactive. When people contact me for help one of the biggest factors as to how much help I give is down to how much work or effort you've done yourself.
If person A contacts me as says, "I've followed your guide and it makes sense but I'm stuck at step number 7, and I've tried X and I've tried Y but I don't quite understand" then I'm likely to help that person as best I can.
If person B contacts me and says "I've read your guide but I don't really understand it, can you  teach me?", my answer is going to be no. You've made no effort to learn yourself, if you need help with step 1 then you'll need help with all the steps and I'm not tutoring someone in hacking, at least not for free.
Demonstrate that you've made an effort to figure it out when you're stuck and if you still cannot figure it out then I'm happy to help explain specific steps or where you're going wrong.


Don't bother asking me for help if:
1) You're new to hacking and only want to learn to screw with someone.
2) You're frustrated and angry because you're stuck after only a few minutes
3) You've made no effort to help your self or work it out.