Category Archives: Uncategorized

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.

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

Hello world!

import java.util.*;
public class main {
   public static void main(String[] args) {
      System.out.println(“Hello World!”);

// Time to get my security and comp sci blog going again.
// I’ve attempted this before and it always go stale
// then I take it down and a few weeks later
// wish I had it up again. So lets try again 🙂