Forcing iOS and Android Data to Burp on a Mac

When pen testing web interfaces and REST APIs for mobile apps, intercepting the messages in Burp can be difficult, especially for those apps that do not respect the http proxy settings. The following guide will help you proxy all the information from your mobile device to a Mac and route specific messages of interest to Burp. We will setup a Mac to act as a proxy and route all of the mobile device’s data.
This guide assumes a few things:
1) Both of the devices need to be on the same network/subnet.
2) You have Burp and know how to use it.
3) You are familiar with basic routing; working with network settings on you mobile device and OSX command line.
4) The Mac device is running Sierra and Burp is version 1.7.22 (or there about)

On the Mac running Sierra, we will need to do a few things:
With Burp:
1. Start Burp
2. Goto Proxy -> Intercept, turn “Intercept is on” to “Intercept is off”
3. Goto Proxy -> Options and select the Proxy Listener and “Edit” it.

4. In the “Edit proxy listener” window, select the “Request handling” tab and enable “Support invisible proxying” and then select Ok.

5. While probably not necessary, I like to reset the Proxy Listener. Goto Proxy -> Options and uncheck and then check (selecting twice) the Running status for the Proxy Listener.

In OSX’s System preferences, under Security & Privacy, turn off the firewall. We will be forwarding all the data from the iOS device to the Mac and the firewall will prevent us from receiving. Do not forget to re-enable to firewall when you are done.

Next, we need to turn on forwarding. Once the Mac receives the data, it needs to forward it so information so it will be directed where it needs to go. Open Terminal and from the command line, run:
sudo sysctl -w net.inet.ip.forwarding=1

This command will prompt you for your password and tell the Mac to forward any data it receives to where it needs to go.

Now, we need to tell OSX to route specific messages to Burp. From the command line, run:

echo "rdr pass inet proto tcp from (Device IP Address) to any port 80 -> port 8080" | sudo pfctl -ef -

This command will route messages from your mobile device using port 80 to Burp. Remove the ‘(Device IP Address)’ and put your mobile device’s IP address in its place. If you wish to route different ports (say 443 for https messages), then change 80 to the desired port.

Note: the ip forwarding and rdr settings will not persist after a reboot but the firewall will remain disabled.

Now, let’s setup the mobile device: For iOS (iPad, iPhone, etc)
Goto the wireless connection’s settings; in iOS, this is under Settings -> Wi-Fi and select the blue circled i. The device cannot use DHCP but you must configure all the settings manually. Select the “Static” tab and set the device’s IP address (the same as in the above rdr setting), subnet mask and DNS setting. For the Router (or Gateway on Android), set it to the IP address of the OSX Mac device running Burp. This will force the mobile device to send all of its data to the Mac.

On the iOS device, open a web browser and go to a web site that is on port 80; should work. In Burp’s Proxy -> HTTP history, you should see the requests to the web site from the iOS device being captured.

Now that you are capturing the messages, you can utilize Burp’s capabilities for testing.

Double Reflected XSS

In a reflected XSS attack, what is sent to the server is immediately reflected back to the user. It allows an attacker to embed scripts that will force the victim to take action on behalf of the user.
Example:<script>Action Here</script>
If a victim triggers the above URL, the Reflected XSS will execute the action in the script tags on behalf of the attacker but with the victim’s account. One of the ways a victim can trigger an attack is through social engineering such as a targeted email or embedded link. The problem arises that if you want to do anything meaningful on the system with the link, it tends to require a long script, producing a very long URL. A long URL decreases the odds of such social engineering attacks.

Double Reflected XSS
In a double reflected XSS, we will present the Reflected XSS with a short URL that will forward to an offsite script, which will then forward the user back to the same Reflected XSS vulnerability but with the long script actions embedded.

Step 1:
The attacker crafts a URL for the victim with an embedded iframe to a URL shortener:<iframe src=’//’ ></iframe>

or URL encoded as:

This presents a URL that is nice and short.

Step 2:
The URL shortener reditects the iframe to a text file like pastebin. The pastebin file contains a a script that will run in the iframe and forward the user back to the Reflected XSS.
This is an example of a script one could put on pastebin that will redirect the user back to the reflected XSS but allowing the insertion of a much longer script.

<META HTTP-EQUIV=”Pragma” CONTENT=”no-cache”>
<meta http-equiv=”refresh” content=’0;url=</script>
Long Attack String Here </script>’
Double Reflected XSS

Step 3
Using the same vulnerability with the Reflected XSS, the attacker is now able to execute the long, multi-step script in the iframe.
Here is an example of a script that will grab the CSRF token in a device’s cookie and then embedded at the end of a URL that will insert a new user. The script then changes the iframe’s location again to be the location of the URL to add a new user.

var str=document.cookie;
url=” … URL encoded add a new user temp2 … ”

Step 4
The URL to add a new user is executed within the iframe and the attack is complete. The URL to add a new user on the device looks something like this:

In this manner, a long script can be hidden from the social engineering link. This iframe, redirect method can also be used with stored XSS where the number of characters available is limited. This technique is how I was able to exploit a stored XSS with very limited characters for my DefCon 23 Packet Hacking Village presentation.

Is SHA1 Dead?

Recently, there was a paper of an attack against SHA1 and its usage as a long lived cryptographic hash for digital signatures and file verification. (
To help garnish more hype, the research findings were named “shattered” and they put up a web site:
This being said, it does make it easier to find the information but I do have a few complaints about the hype and melodrama at their website.
“We have broken SHA-1 in practice.” when in reality, what is broken is SHA-1 for digital signature and other long lived hashing verification; there are still many usages of SHA-1 that are safe.
From their paper’s abstract “SHA-1 is a widely used 1995 NIST cryptographic hash function standard that was officially deprecated by NIST in 2011 due to fundamental security weaknesses demonstrated in various analyses and theoretical attacks.” Again, SHA-1 for digital signatures was deprecated but just nit picking here…
Again, from the paper, “As a result while the computational power spent on this collision is larger than other public cryptanalytic computations,”
Does this mean there are computationally less expensive attacks? If so, what is then novel about this paper other then they named their attack and put up a cool web site? After a bit of digging, it looks like the less expensive options required certain pre-conditions that may not be readily available in real world scenarios.
What are the implications beyond digital signatures and other long lived cryptographic verification?
I am fairly certain TLS and DTLS SHA1 is safe since the Hash then Encrypt structure (the hash is encrypted) of xTLS protects the hash from modification. The hash is encrypted; thus, without the key, an attacker cannot modify or even read the value. There is no opportunity for a collision attack.
Since IPSec encrypts and then does an HMAC, the HMAC is exposed in the clear unlike xTLS. The HMAC is also used to protect the ESP header which includes the IPSec packet sequence number. IPSec uses an incrementing sequence number to prevent attackers from injecting older messages into the stream of packets. If one wanted to modify the sequence number, they would need to also modify the HMAC such that a check of the HMAC would indicate the packet is safe.

IPSec’s HMAC is exposed unlike xTLS, but is still probably safe for now as long as the IKE rekey sequence is anything sane. IPSec will negotiate a new session key between the sender and receiver utilizing a protocol referred to as IKE; this also resets the sequence number.
From my quick digging, it looks like the Linux default ikelifetime value is 8 hours with a maximum of 24 hours. Since the attack still requires multiple days to achieve and because of the short-lived nature of the packets, (The attack still requires 2^63 checks) IPSec is probably safe. Additionally, the shattered attack requires the ability to manipulate some of the hashed data so as to create a collision. The ESP packet field does not offer many places to do this and altering the encrypted data section would corrupt the underlying information.
I think IPSec is safe for now… I assume the same holds true for SSH.
Passwords: This gets interesting as the paper outlines a collision technique. The idea would be to generate a password/string (could be the same or not) that combined with the salt would generate the same hash as stored in a system. What I don’t understand is the mutli-iterations used by PBKDF2 effects on the collision technique. When passwords are stored, each is combined with a unique string and then hashed multiple times (10,000+) to increase the work factor if someone attempts to break them. I do not think they have yet published the math behind the attack and it is a bit beyond my time budget to understand, so I am not sure.
This being said, here is a quick summary of the brute force cracking capabilities for a NVidia GTX 1080
SHA1: ~15,400 MH/s
SHA256: ~2,870 MH/s
SHA512: ~1080 MH/s
And a single core on a Intel Core i7 4960X:
SHA1: ~568 MH/s
SHA256: ~229 MH/s
SHA512: ~333 MH/s
It is interesting to note that on x64 system, SHA512 is faster than SHA256.

Given the speed difference in GPUs and CPUs and the desire to increase the work factor to help prevent brute force attacks, SHA512 should be used in multi-iteration hash functions like PBKDF2 to protect passwords even if SHA1 is still safe.

Analyzing the Shadow Brokers text.

There are several tools available that will examine the word choice, phrases and grammatical structure of text and provide analysis of the writers/authors. I am fairly certain that the way we express information is fairly unique and that algorithms today are linking materials posted in various venues together and attributing them to particular individuals. This analysis is baby steps on comparison and just for fun; the tools are far from precise and the text sample length is far too short. I also suspect that it was purposefully modified to try and remove identifying signatures, but let’s see what we can find.

As many know, the Shadow Brokers released a set of information that included some text (with the bitcoin address removed):

How much you pay for enemies cyber weapons? Not malware you find in networks. Both sides, RAT + LP, full state sponsor tool set? We find cyber weapons made by creators of stuxnet, duqu, flame. Kaspersky calls Equation Group. We follow Equation Group traffic. We find Equation Group source range. We hack Equation Group. We find many many Equation Group cyber weapons. You see pictures. We give you some Equation Group files free, you see. This is good proof no? You enjoy!!! You break many things. You find many intrusions. You write many words. But not all, we are auction the best files.

We auction best files to highest bidder. Auction files better than stuxnet. Auction files better than free files we already give you. The party which sends most bitcoins to address: before bidding stops is winner, we tell how to decrypt. Very important!!! When you send bitcoin you add additional output to transaction. You add OP_Return output. In Op_Return output you put your (bidder) contact info. We suggest use bitmessage or I2P-bote email address. No other information will be disclosed by us publicly. Do not believe unsigned messages. We will contact winner with decryption instructions. Winner can do with files as they please, we not release files to public.

From looking at the text, the sentences are very short and lack proper grammar. (please excuse my own) Two times commas were used correctly in poorly worded sentences and twice it was used incorrectly to join two sentences. Many of the sentences are very short but linguistically, I am not sure this points to translation issues.

The first tool is a gender analyzer:
This tool reports that there are not enough words for a good read with only 215 out of the suggested minimum of 300 words. So a point to consider, was the amount of text purposefully kept short to limit exposure. The tool rated the text author as overwhelmingly male (85.9%) for informal writing but for formal, it would be female (75.21%).

The next analysis tool starts to dig much deeper and as a result ist more interesting. It is based on IBM’s Watson services, Tone Analyzer:
Overall, the text rated highly on Anger (0.74), Extroversion (0.98) and Agreeableness (0.95) and interestingly, but probably not surprising very low on Openness (0.03).

The sentences with the highest Anger rating were:
0.47 How much you pay for enemies cyber weapons?
0.44 When you send bitcoin you add additional output to transaction.
0.38 Do not believe unsigned messages.
0.38 Winner can do with files as they please, we not release files to public.
0.36 You write many words.
0.34 No other information will be disclosed by us publicly.
0.33 We hack Equation Group.
0.32 We follow Equation Group traffic.

And those with the lowest:
0.11 You break many things.
0.10 But not all, we are auction the best files.
0.10 Auction files better than stuxnet.
0.07 We will contact winner with decryption instructions.
0.07 We auction best files to highest bidder.
0.00 You see pictures.
0.00 You enjoy!!!
0.00 Very important!!!

And the highest on Agreeableness:
0.99 We give you some Equation Group files free, you see.
0.99 We will contact winner with decryption instructions.
0.99 We hack Equation Group.
0.99 We follow Equation Group traffic.
0.98 Auction files better than free files we already give you.
0.98 We auction best files to highest bidder.

The next tools are from uClassify.
The first I tried is the Sentiment classifier and it gave it a slightly negative rating (56%) over positive (44%).
GenderAnalyzer_v5 gave the text a male (77%) classification.
Ageanalyzer struggled a bit, producing an age range of 65-100 with a 31% rating; next was a 24% rating for age range 26-35.
Mood was analyzed to be 95% Happy.
While there are a rather large number of classifiers available, this last one from uClassify, I found interesting, Value. It rated the text as Exploitive (44%) and Achieves (22%). The authors are taking advantage of what they found and bragging about it. While not surprising, it was interesting to see the tool pick up on it.

The last tool from Readability Score is one I like to use on my own works to help judge the readability and grade level of the writing. Given the short sentences, it is not too surprising that the level is approximately 6th grade and rated easy to read.


One of my favorite ways to bypass XSS input filters is with Unicode characters. What happens is the string like “%26#60;script%26#62;alert(1);%26#60;/script%26#62;” is sent to the server. The input filters find nothing wrong with it so it passes through fine. When it hits the web server, it attempts to normailze the characters and subsitutes approximates. So &#60; or &#x3c; will become “<“.

Here are a few Unicode strings that I will try out.

\074\057a\076\047\074script\076 alert(1) \074/script\076 // 


How to Recover a Lost iPad or iPhone Restrictions Pin

Too many pin and passwords and I forgot the Pin for the Restrictions setting on our family’s iPad. Apple used to store it clear text in the iTune backup, but now its just slightly harder to find.
This is for iOS 7+ and in my case 9.3.X and using iTunes on a Mac
Backup your iDevice.
Navigate to /Users/YOURACCOUNT/Library/Application Support/MobileSync/Backup/DEVICEBACKUPFOLDER
Where DEVICEBACKUPFOLDER will be a 40 randomish character string – There will be a DEVICEBACKUPFOLDER folder for each backed up device.
If you do not see the /Library/ directory, select the “Go” tool bar menu and then press and hold the “Option” key; it should toggle/show a “Library” option you need to select.
Find and open the file 398bc9c2aeeab4cb0c12ada0f52eea12cf14f40b in TextEdit
You will find the following:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">

The two data values will be different for your device; this is the stored pin. I did not change the values in the above; I set a temporary key to use in this example so you can test this yourself.

Go to Recover iOS7+ Restrictions Password and copy and paste the PasswordKey data string, this the above case: zm+4u+x37mZZb4wxEJxcYKNqvfo=
and copy and paste the PasswordSalt data string: ZOsf/w==
and select “Search for Code.” It will attempt to brute force all possible code combinations until it finds a match; this could take a while to grab a coffee. In the above case, pin it will find should be “1111”.

Playing with XSS

Want to learn more about XSS attacks – well the best way is probably to try some yourself. Here are two sites that offer XSS games that allow you to test and improve your skills.

One of my favorite strings to use in testing XSS when I am doing pen testing is the following:
<iframe src=//></iframe>
It will add an embedded iframe for the youtube video Rick Roll. 🙂 Its always amusing to see all the places I can get a Rick Roll to appear.
BTW, to keep the link from rendering, I had to HTML endode < to &lt;, and for good measure also change > to &gt; and change the & in &lt; to &amp;.

ShellShock Worm hitting QNAP NAS devices

Several months later and now a worm has been released hitting QNAP devices. It spreads by connecting to QNAP devices open to the internet (yeh, brilliant thing to do) that have not been patched. (just as brilliant) 🙂

How can I tell if my device is infect?
Look in /etc/shadow and /etc/passwd for an account named “request” If you find it, your infected.

I am infected! Help!
To delouse your system, go to QNap’s page.

How can I tell if my device is vulnerable to ShellShock?
SSH into your device and run the following command: (use at your own risk)
curl | bash
More information can be found at

How do I patch my device if it is vulnerable?
If your already infected, the worm nicely patches your system. How considerate. 🙂
Else, go to QNap’s page for instructions on how to update your device.

Test Your Server for the Poodle Vulnerablity

The latest crypto issue to hit is the “Poodle” attack. A good explanation of poodle can be found at the openssl website.

The simplest way to test your server is an online scanner at .
Putting results in the following report:
Scan results ( - Vulnerable

This server supports the SSL v3 protocol.

But how does one test a server that is not online or exposed to the world? OWASP’s website has some great information on how to extract a servers SSL/TLS information.
I ran a slightly modified version of the test (without the cert information dump) against Its a bit verbose but lets see the output:
nmap --script ssl-enum-ciphers -p 443

Starting Nmap 6.40 ( ) at 2014-10-28 15:20 EDT
Nmap scan report for (
Host is up (0.037s latency).
Other addresses for (not scanned):
rDNS record for
443/tcp open https
| ssl-enum-ciphers:
|  SSLv3:
|  ciphers:
|   TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong
|   TLS_RSA_WITH_AES_128_CBC_SHA - strong
|   TLS_RSA_WITH_AES_256_CBC_SHA - strong
|   TLS_RSA_WITH_RC4_128_MD5 - strong
|   TLS_RSA_WITH_RC4_128_SHA - strong
|  compressors:
|  TLSv1.0:
|  ciphers:
|   TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong
|   TLS_RSA_WITH_AES_128_CBC_SHA - strong
|   TLS_RSA_WITH_AES_256_CBC_SHA - strong
|   TLS_RSA_WITH_RC4_128_MD5 - strong
|   TLS_RSA_WITH_RC4_128_SHA - strong
|  compressors:
|  TLSv1.1:
|  ciphers:
|   TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong
|   TLS_RSA_WITH_AES_128_CBC_SHA - strong
|   TLS_RSA_WITH_AES_256_CBC_SHA - strong
|   TLS_RSA_WITH_RC4_128_MD5 - strong
|   TLS_RSA_WITH_RC4_128_SHA - strong
|  compressors:
|  TLSv1.2:
|  ciphers:
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong
|   TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|   TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong
|   TLS_RSA_WITH_AES_128_CBC_SHA - strong
|   TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
|   TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
|   TLS_RSA_WITH_AES_256_CBC_SHA - strong
|   TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
|   TLS_RSA_WITH_AES_256_GCM_SHA384 - strong
|   TLS_RSA_WITH_RC4_128_MD5 - strong
|   TLS_RSA_WITH_RC4_128_SHA - strong
|  compressors:
|_  least strength: strong

Nmap done: 1 IP address (1 host up) scanned in 2.39 seconds
While its a very long list of supporting ciphers, the culprits are the ones highlighted in red – those that support the *_CBC_* block cipher in SSLv3. If you find any of those then your server supports the vulnerability.

Crypto and Security Brain Teaser

Assuming this code works, what is wrong with the functionality from a security and crypto perspective?

#!/usr/bin/env ruby
# This program encrypts and decrypts messages at the command line.
# It runs setuid root, so that it can be used by users without giving
# them access to the (root-owned) secret encryption key.

require ‘openssl’


cipher =‘aes-256-ecb’)

case ARGV.shift
when ‘encrypt’
when ‘decrypt’
  puts “Usage: $0 [encrypt|decrypt] ”
  exit 1

input =
output =, “w”)

input.each_line do |l|
  output.write(cipher << l)

Here are a few hints…
I found 4 crypto related problems and one security/privilege escalation issue.