Modern Web Application Penetration Testing Part 2, Hash Length Extension Attacks

By: Adrien de Beaupre

I will be teaching SANS SEC642: Advanced Web App Penetration Testing, Ethical Hacking, and Exploitation Techniques at many events this year, I am also the co-author for the course. AKA the most advanced web app pentest course on the planet, probably the galaxy! This is one of the many techniques that I will be exploring in this series of posts.

I had the opportunity to sit with my friend Ron Bowes @iagox86 a while back to talk about SEC642 content and the state of web application penetration testing in general. He mentioned hash length extension attacks, and that coincidentally he had written the absolute best tool to exploit it! Definitely something that we could consider adding. Ron has also done writeups for CTF challenges that can be solved using his tool.

So I have some of the ingredients that we can talk about. We have a topic, we have a tool, and all that we need is a vulnerable application. We found a couple that had been used in CTFs, and one that also included some other interesting crypto challenges called CryptOMG by SpiderLabs. They published the solutions to the first and second challenges on their blog. This is the solution to the fifth challenge which is a hash length extension attack, and of course we will use hash_extender to do so. Installing CryptOMG is covered in Appendix A.

Opening up the new site in a browser and we see this:

modern_webapp_p2_01

The challenge appears to be a Local File Include (LFI) to see the contents of /etc/passwd.

Selecting Challenge 5 and we see the following:

modern_webapp_p2_02

Selecting SHA1 as the Algorithm and clicking on the test link proxying through Burp gives us the parameters that we presumable have to play with to succeed.

modern_webapp_p2_03

 

algo=sha1, file=test, and hash=dd03bd22af3a4a0253a66621bcb80631556b100e

 

Sending the same GET request to repeater and we see the following response:

modern_webapp_p2_04

We now have a baseline request that gives us a 200 response code, and presumably the contents of the file called test in the HTML.

If this were HMAC we would need the secret. Brute forcing that might take a while, so let’s try a hash extension attack. Without knowing the secret we can append to the file name parameter and try a directory traversal with a LFI attack. We just need to be able to create a valid hash. So our attack will look something like this:

algo=sha1, file=test/../../../../etc/passwd, and hash=??

The problem is that we do not know the secret, and also do not know the length of the secret. This is what we need to append our data to the input parameter, assuming that they did something like this to create the hash:

sha1(filename||secret)

Where they concatenate something that we can control with something that we do not to generate a hash. The magic of this attack is that we can append to the filename and still generate a valid hash without knowing the secret! However we do have to guess the length of the secret, or brute force it. In this case we are going to assume that the secret length lies between 10 and 40 bytes.

Enter hash_extender to the rescue. Downloading it from git and making it is quick and easy. The instructions are in Appendix B.

Running the following should give us some file names and hashes to try!

./hash_extender -f sha1 --data 'test' -s dd03bd22af3a4a0253a66621bcb80631556b100e --append '../../../../../../../../../etc/passwd' --secret-min=10 --secret-max=40 --out-data-format=html --table > hashesnsignatures.out

(I had intended to put a crazy one liner in there, but Ron is way cooler and more l33t than me). The first time I tried it I had not put enough ../ in and got a 200 response code without the file contents. 9 seemed like a good number. If we are not successful we see a 404 response code and the HTML does not contain the file that we are looking for:

modern_webapp_p2_05

Running the results from hash_extender through Burp Intruder we get a hit. This was done with the hashes in one file, the strings in another, with both used as payloads to Pitchfork.

modern_webapp_p2_06

 

As it turns out the length of the secret was 34 bytes. Let’s see what we have!

modern_webapp_p2_07

 

Success! Without knowing a 34 character secret password we are still able to grab the contents of /etc/passwd through the hash extension attack.

This is one of the many practical attack techniques that we teach in the SANS course SEC642.

Also see:

Modern Web Application Penetration Testing Part 1, XSS and XSRF Together

I am teaching SEC642: Advanced Web App Penetration Testing, Ethical Hacking, and Exploitation Techniques at multiple SANS training events around the world in 2018.

Cheers, Adrien de Beaupré
Intru-shun.ca Inc.
Certified SANS Instructor https://www.sans.org/instructors/adrien-de-beaupre
Co-author of SANS SEC642: Advanced Web App Penetration Testing, Ethical Hacking, and Exploitation Techniques

 

References:

https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks

https://github.com/iagox86/hash_extender

https://github.com/SpiderLabs/CryptOMG

 

Appendix A: Installing CryptOMG: (Using Ubuntu 14.04; apache, mysql, and php5 are already installed)

# cd /var/www/html

# git clone https://github.com/SpiderLabs/CryptOMG.git

# apt-get install libmcrypt4 php5-mysql php5-mcrypt

— edit /var/www/html/includes/db.inc.php for mysql database settings

# php5enmod mcrypt

# service apache2 restart

 

Appendix B: Installing hash_extender: (again using Ubuntu, but in this case the Samurai WTF VM)

samurai@samuraiwtf:~/Downloads$ git clone https://github.com/iagox86/hash_extender.git

Cloning into ‘hash_extender’…

remote: Counting objects: 587, done.

remote: Total 587 (delta 0), reused 0 (delta 0), pack-reused 587

Receiving objects: 100% (587/587), 153.34 KiB | 0 bytes/s, done.

Resolving deltas: 100% (396/396), done.

Checking connectivity… done.

samurai@samuraiwtf:~/Downloads$ cd hash_extender

samurai@samuraiwtf:~/Downloads/hash_extender$ make

[CC] buffer.o

[CC] formats.o

[CC] hash_extender.o

[CC] hash_extender_engine.o

[CC] test.o

[CC] util.o

[LD] hash_extender

[CC] hash_extender_test.o

[LD] hash_extender_test

samurai@samuraiwtf:~/Downloads/hash_extender$

samurai@samuraiwtf:~/Downloads/hash_extender$ ./hash_extender

hash_extender: –data or –file is required

——————————————————————————–

HASH EXTENDER

——————————————————————————–

By Ron Bowes <ron @ skullsecurity.net>

See LICENSE.txt for license information.

Usage: ./hash_extender <–data=<data>|–file=<file>> –signature=<signature> –format=<format> [options]

INPUT OPTIONS

-d –data=<data>

The original string that we’re going to extend.

–data-format=<format>

The format the string is being passed in as. Default: raw.

Valid formats: raw, hex, html, cstr

–file=<file>

As an alternative to specifying a string, this reads the original string

as a file.

-s –signature=<sig>

The original signature.

–signature-format=<format>

The format the signature is being passed in as. Default: hex.

Valid formats: raw, hex, html, cstr

-a –append=<data>

The data to append to the string. Default: raw.

–append-format=<format>

Valid formats: raw, hex, html, cstr

-f –format=<all|format> [REQUIRED]

The hash_type of the signature. This can be given multiple times if you

want to try multiple signatures. ‘all’ will base the chosen types off

the size of the signature and use the hash(es) that make sense.

Valid types: md4, md5, ripemd160, sha, sha1, sha256, sha512, whirlpool

-l –secret=<length>

The length of the secret, if known. Default: 8.

–secret-min=<min>

–secret-max=<max>

Try different secret lengths (both options are required)

OUTPUT OPTIONS

–table

Output the string in a table format.

–out-data-format=<format>

Output data format.

Valid formats: none, raw, hex, html, html-pure, cstr, cstr-pure, fancy

–out-signature-format=<format>

Output signature format.

Valid formats: none, raw, hex, html, html-pure, cstr, cstr-pure, fancy

OTHER OPTIONS

-h –help

Display the usage (this).

–test

Run the test suite.

-q –quiet

Only output what’s absolutely necessary (the output string and the

signature)

The arguments you probably want to give are (see above for more details):

-d <data>

-s <original signature>

-a <data to append>

-f <hash format>

-l <length of secret>

samurai@samuraiwtf:~/Downloads/hash_extender$

Upcoming SANS Special Event – 2018 Holiday Hack Challenge

KringleCon

SANS Holiday Hack Challenge – KringleCon 2018

  • Free SANS Online Capture-the-Flag Challenge
  • Our annual gift to the entire Information Security Industry
  • Designed for novice to advanced InfoSec professionals
  • Fun for the whole family!!
  • Build and hone your skills in a fun and festive roleplaying like video game, by the makers of SANS NetWars
  • Learn more: www.kringlecon.com
  • Play previous versions from free 24/7/365: www.holidayhackchallenge.com

Player Feedback!

  • “On to level 4 of the #holidayhackchallenge. Thanks again @edskoudis / @SANSPenTest team.” – @mikehodges
  • “#SANSHolidayHack Confession – I have never used python or scapy before. I got started with both today because of this game! Yay!” – @tww2b
  • “Happiness is watching my 12 yo meet @edskoudis at the end of #SANSHolidayHack quest. Now the gnomes #ProudHackerPapa” – @dnlongen
kringle_02

Modern Web Application Penetration Testing Part 1, XSS and XSRF Together

 

By: Adrien de Beaupre

 

I enjoy performing penetration tests, I also enjoy teaching how to do penetration testing correctly. I will be teaching SANS SEC642: Advanced Web App Penetration Testing, Ethical Hacking, and Exploitation Techniques at many events this year. This is one of the many techniques that I will be exploring in this series of posts. When I am teaching one of the points I make is to never consider the vulnerabilities in isolation, using them in combination truly demonstrates the risk and impact. My team were performing a web application penetration test, and the list of things that it was vulnerable to was quite impressive!

 

The list of vulnerabilities:

  • Content can be framed
  • XSS
  • Method interchange
  • DoS, application hangs on long abnormal inputs, relies on client side validation
  • Able to upload files, including malicious content
  • Information leakage, internal server names, IP addresses, install locations…
  • XSRF
  • User enumeration via forgot password function
  • Administrators can disable their own account

We had determined that the primary threat would be for a user to escalate privileges and access information from other accounts. In order to achieve this goal we concentrated on the persistent XSS and XSRF. We would use the persistent XSS to launch the XSRF attack. We leveraged all of the vulnerabilities in one way or another, in other words, we were having a good time! Once you have XSS in an application all that you need is one or more attractive transactions to be performed. We find that XSRF is the best XSS payload there is.

Using the persistent XSS:

  • Create trouble ticket
  • Ticket will be first viewed by administrator
  • Script executes in the administrator browser
  • Administrator can perform all of the functions vulnerable to XSRF

A significant number of the functions were vulnerable to Cross Site Request Forgery (CSRF or XSRF), which is also known as session riding and transaction injection. The functions that were vulnerable had absolutely no anti-XSRF protection, and the interesting ones were all in the administrator part of the site.

An attacker could add a new user, put the user in the administrator group, change the passwords, and log out. The problem was, each of these were different transactions, and had to be performed in the correct order to pull off the attack. The application owner and the development team did not appreciate the severity of the issue, and pointed out that their automated scanning tool had not identified the issue, therefore it didn’t exist. Even if the issue did exist, it could only be of medium severity, because their tool said so. To top it all off, even if an attacker could pull off this mythical attack, it could not be done in one shot, the administrator had to click multiple times. In short, they did not appreciate the impact, the attacker would have complete control over the application. In order to make our point a demonstration was in order, that did the following:

  • Add a new user
  • Put the user in an administrator group
  • Lockout the super-user account
  • Logout the super-user account
  • Did the functions in the correct order
  • Each function would wait for the last to complete
  • Was all in one HTML page
  • Could be delivered as a single XSS payload
  • Would force the administrator to view a certain Rick Astley video :)
  • OK, we didn’t do the last one, that would be WAY too mean.

Google-fu was with us that day, we discovered a post by Tim Tomes (lanmaster53) that described exactly what we wanted to do. He also had sample code to start with:

http://www.lanmaster53.com/2013/07/multi-post-csrf/

The next problem was that obviously we could not use their custom application to do the proof of concept, but needed another application with similar vulnerabilities to demo for this post. Once again the force of Google-fu was with us:

http://www.zeroscience.mk/en/vulnerabilities/ZSL-2014-5193.php

Omeka is a free and open source web publishing application. Also quick and easy to install. Also quick and easy to exploit. Last, but not least, we could download the vulnerable version 2.2 and be up and running in no time.

 

Administrator (victim) logs into the application:

modern_beaupre01Click image for full-size

 

The add user function as seen in an interception proxy (OWASP ZAP):

modern_beaupre02Click image for full-size

 

The Add User function was just one of many that were vulnerable to XSRF, with no protection as shown above. The api_key_label POST parameter id not sanitized, it is our persistent XSS vector. The administrator would have to invoke that function for the code to run. The code used is shown below in a PDF format.
The code running:

modern_beaupre03Click image for full-size

 

Now the code. The important parts are getting the script to run, we used a body onload. The script runs each one of the forms. The forms each contain one of the XSRF attacks. Each form loads in a different iframe. The first one runs, then the second one waits from the iframe onload to fire before it runs, and so on. Victim logs in, they check their queue, the XSS runs, the XSRF runs, they have lost control of the application, attacker win, or in this case a very effective demonstration of risk.

I am teaching SEC642: Advanced Web App Penetration Testing, Ethical Hacking, and Exploitation Techniques at multiple SANS training events around the world in 2018.

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.
Certified SANS Instructor https://www.sans.org/instructors/adrien-de-beaupre
Co-author of SANS SEC642: Advanced Web App Penetration Testing, Ethical Hacking, and Exploitation Techniques

References:

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
http://cwe.mitre.org/data/definitions/352.html
http://www.lanmaster53.com/2013/07/multi-post-csrf/
http://www.zeroscience.mk/en/vulnerabilities/ZSL-2014-5193.php
http://omeka.org/
https://www.youtube.com/watch?v=dQw4w9WgXcQ

Code:


script

CODE – PDF Format (Copy & Paste):

http://blogs.sans.org/pen-testing/files/2017/03/modern_webapp_pentesting_blog_03012017_code.docx_.pdf

 

Upcoming SANS Special Event – 2018 Holiday Hack Challenge

KringleCon

SANS Holiday Hack Challenge – KringleCon 2018

  • Free SANS Online Capture-the-Flag Challenge
  • Our annual gift to the entire Information Security Industry
  • Designed for novice to advanced InfoSec professionals
  • Fun for the whole family!!
  • Build and hone your skills in a fun and festive roleplaying like video game, by the makers of SANS NetWars
  • Learn more: www.kringlecon.com
  • Play previous versions from free 24/7/365: www.holidayhackchallenge.com

Player Feedback!

  • “On to level 4 of the #holidayhackchallenge. Thanks again @edskoudis / @SANSPenTest team.” – @mikehodges
  • “#SANSHolidayHack Confession – I have never used python or scapy before. I got started with both today because of this game! Yay!” – @tww2b
  • “Happiness is watching my 12 yo meet @edskoudis at the end of #SANSHolidayHack quest. Now the gnomes #ProudHackerPapa” – @dnlongen
kringle_02