Pwning Networks Through Vulnerable Applications

Monday, December 08, 2014

Saurabh Harit

298ae75e0e4be21caa0c666fb05fcf67

If you are a pentester, you would agree that one of the most common ways of compromising a network is through vulnerable 3rd-party applications. I am talking about Apache tomcat, JBoss jmx-console, Hudson-Jenkins and such. I do a lot of internal network pentests and it seldom (more like, never) happens that I do not find atleast one instance of tomcat or jmx-console that is configured with weak or default password. I have actually started to suspect that Apache tomcat somehow installs itself on the network. If not that, I’m pretty sure that it atleast reverts back to the default login password after the user is done configuring it. I mean how else does an extremely well known insecure configuration keep popping up over and over and over again. How are we not getting this thing right? Its like web-based MS08-067.  

I am not going to discuss how to exploit tomcat or jmx-console or Hudson-jenkins. There are tons of very well written posts out there on the exploitation part. This post will discuss something that I believe is not very commonly talked about.  

Surely Apache tomcat, JBoss jmx-console etc. are the most popular applications that we usually look for and exploit, while on a pentest. Like I’ve mentioned before, it only rarely happens, but sometimes you end up on a network where you do not find these “popular” applications to exploit, in order to compromise the remote server. Or the discovered instances could either not be exploited or do not yield anything post exploitation.  

On such pentests, I have (accidently or luckily) come across other 3rd-party applications that could allow you compromise a remote server in the similar fashion. Ever exploited ADManager Plus or Cyberoam UTM or Testlink?  

“ADManager Plus is a simple, easy-to-use Windows Active Directory Management and Reporting Solution that helps AD Administrators and Help Desk Technicians with their day-to-day activities.” Find one of these on a network and you can add a domain admin for yourself. Fastest pwnage ever.  

“Cyberoam Unified Threat Management appliances offer assured security, connectivity and productivity to Small Office-Home Office (SOHO) and Remote Office-Branch Office (ROBO) users by allowing user identity-based policy controls.” The Cyberoam UTM exposes a web interface through a Jetty web server that is vulnerable to OS command injection. Additionally, it also integrates with Active Directory. In order to query data from a configured AD, domain credentials are stored within the device. These credentials are stored on the client-side and can be accessed by merely viewing the source of the page. I wish I were kidding. Here is the link to the two vulnerabilities that I reported a few years back: http://www.exploit-db.com/exploits/18646/  

The point I am trying to make is that there are many, many more vulnerable 3rd-party applications out there than just Apache tomcat and JBoss jmx-console. If you search through Exploitdb and grep for vulnerabilities such as remote code execution, SQL injection, RFI, LFI, malicious file upload etc., it’ll come back with over 12000 unique vulnerabilities that one could exploit to completely compromise the backend server and be on their way to becoming domain admin.  

Finding these applications on the network is not that trivial. A generic network vulnerability scanner would pick up some of these applications but only a few and the most common ones. Such scanners will also report the web applications with default or weak login credentials; however that does not mean that the application is also vulnerable and exploitable. We would specifically want to enumerate 3rd-party web applications / interfaces that are known to be vulnerable and exploitable.  

Introducing Yasuo. Yasuo is a ruby scanner that scans for vulnerable & exploitable 3rd-party web applications on a network that may lead to complete compromise of the backend server through vulnerabilities like malicious file upload, remote code execution, RFI, LFI, SQL injection and so on. It currently supports 115 vulnerable web applications; new application signatures are being added regularly.  

Yasuo accepts an IP address or IP range as well as port number(s) through the “-r” switch. It then performs a port scan using nmap libraries. You could also perform your own port scan, save the output in the xml format and feed the port scan output to Yasuo through the “-f” switch. It then parses the nmap xml output file, enumerates the open web-based ports (http, https, http-alt, websm etc.) and creates an initial URI. To enumerate vulnerable applications, it appends the unique application path from the signature file (default-path.csv) to the initial URI and sends a request to the server. If the discovered application implements http basic or form-based authentication, you could ask Yasuo to brute-force it using the “-b” switch.  

Below is a logical program flow of Yasuo:  

Enough said. You can download Yasuo from here: https://github.com/0xsauby/yasuo. Take it on a test drive when you’re on a network pentest the next time and please provide us with the feedback. Also, we could obviously use some help with more signatures.  

Cross-posted from the SC Labs blog.  

Possibly Related Articles:
8965
Privacy Vulnerabilities Webappsec->General
Application Security AppSec
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.