Web Vulnerabilities POC
This is a deliverable for my Cyber Security Bootcamp that focused on the simple concepts behind web application vulnerabilities, and various ideas for both exploit and remediation.
Last updated
This is a deliverable for my Cyber Security Bootcamp that focused on the simple concepts behind web application vulnerabilities, and various ideas for both exploit and remediation.
Last updated
This is a VERY simple example of a command injection for a text field in the DVWA web application. Here we can see an interactive input field that requires the user to enter an IP address. Because of the poor security measures surrounding input validation, however, I was able to utilize the field to inject a command && cat ../../../../../etc/passwd to reveal sensitive information a standard user should not have access to. This vulnerability exploits the system's trust of input information, and is clearly in need of security measures to prevent data leakage such as this.
The most important mitigation strategy here is input validation. Certain characters that the application server would interpret as commands need to be labelled as "bad characters" so they are rejected before any action is performed. Vulnerabilities like this can exist in truly any text input field, or even in a URL header. It is important to always validate input and only allow exactly what is expected as input.
This is a high level overview of a dictionary attack on a bWAPP application. The goal here was to utilize a predetermined wordlist of both usernames and passwords, in conjunction with Burp Suite, to test varying credentials for access to the application interface. This method simulates the scenario of a leaked credentials list from a previous breach that could have been obtained on the Dark Web. These credential lists are sold often, and utilized to attack other applications that a company or enterprise may utilize. Using Intruder from Burp, I was able to gain access with the proper credentials using the username and password lists provided.
Based on the simplicity of usernames and passwords, I feel that a more complex password requirement will aid in mitigating the effects of this attack. Along with this, I am a firm believer that multifactor authentication helps like a code being sent to a device or backup email. From an enterprise perspective, this is why password rotation and policy are so important. If a company is requiring all employees to change their passwords every 3 months, then the hypothetical leaked credentials will be depreciated over time. Strong, unique passwords are a must if the first line of defense needs to remain shut against brute forcing, but rotation of passwords maintains ephemeral access credentials, should they ever be leaked and sold on the Dark Web.
In this example of a BeEF hook URL, I was able to obtain access in a simulated phishing attack with a malicious link. I delivered the link (to myself for a proof of concept), and once selected by the "victim," a phony Facebook page was presented to the unsuspecting target. This allowed me to monitor them from the attacker perspective, and gain credentials they entered when attempting to log in to the false page with their ACTUAL credentials.
It is a little hard to see, but I utilized a combination of the BeEF Hook script and Burp Suite to intercept the POST request and edit it. The character limit on the DVWA was a hurdle to jump over, but intercepting the traffic and adding that script allowed me to bypass it. A major mitigation strategy would be recurring employee training. If the employee hadn't clicked on the malicious link, and followed guidelines to inspect the legitimacy of an email, the hook script would not have been able to run and traffic would not have been intercepted in the first place.
