Introduction

The topic of investigation that was introduced this week was Web Application Security. Specifically focusing on the absolute slew of web application vulnerabilities that exist in the modern web today.

In the modern day of today, businesses need to have open customer facing portals that allow them to remain in contact with customers as well as act as a platform to conduct their business. These portals commonly tend to be web applications that provide a more convenient platform for businesses to conduct their daily operations. In the modern day of today, businesses need to have open customer facing portals that allow them to remain in contact with customers as well as act as a platform to conduct their business. These portals commonly tend to be web applications that provide a more convenient platform for businesses to conduct their daily operations.

However, there is an issue that arises from the rapid adoption of web applications as alternative business platforms. From Robert Mitchell’s and Luke Fuehrer’s presentations over the last two weeks, the fact that the web landscape is not secure is more than apparent. These web applications being used by businesses also carry with them a whole suite of vulnerabilities that can be leveraged to gain access to valuable, sensitive data.

The issue that I chose to focus on this week revolves around the impact of web application vulnerabilities on businesses that use web apps as an alternative business platform.

How secure are web applications exactly?

To find out more about web application vulnerabilities, I was introduced to some challenges based around leveraging web app exploits by Darsh and Larry. Challenges were hosted on sites such as:

I’ve had previous experience with challenges on Natas(OverTheWire), HackTheBox and Root-Me so I do have some knowledge of web app penetration testing. I decided to have a look at some of the web challenges on HackTheBox, specifically Lernaean, a challenge I hadn’t attempted before.

The Lernaean Challanege 😫

Also known as how to try SQL Injection for 20 minutes before Larry asks if you’ve tried googling the challenge name for hints and you do and then you find out you have to use hydra and then you cry but then you suck it up because there is no time for crying in this subject.

  1. Starting the challenge instance and navigating to the URL presents you with this page. Lernaean 1

  2. Immediately seeing the password input box, I start trying SQL injection with 'OR 1==1-- queries. Setting up the intercept on Burp Suite, we can see that the server HTML encodes special characters. Changing the values back to their respective special characters does nothing. Lernaean 2

  3. Each time the SQL Injection failed, we would see the invalid password prompt appear in the top left corner.
    Lernaean 3

  4. It’s at this time that I ask Larry what I’m doing wrong and he asks if I’ve googled the challenge name yet? Googling Lernaean gives us the results Lernaean Hydra.
    Hydra?
    Cue traumatic CySCA 2018 flashbacks.
    The official THC Hydra repo can be found here.
    In essence Hydra is a brute force password cracking tool. But its’s pretty annoying to configure the exact parameters you need to successfully deploy the tool. Lernaean 4

  5. After some hit and miss attempts at using the GUI tool for Hydra (GTK Hydra) and then experimenting with CLI Hydra, I finally figured out the exact parameters I needed to crack the password. The payload:
    hydra -l administrator -P /usr/share/wordlists/rockyou.txt docker.hackthebox.eu -s 36983 http-post-form ":/password=^PASS^:Invalid Password!" -t 32
    Breakdown:

    • -l administrator - means login with this username.

    • -P /usr/share/wordlists/rockyou.txt - means load up a wordlist full of passwords to use to bruteforce.

    • docker.hackthebox.eu - the website login to bruteforce (both domain names and IP address can be used).

    • -s 36983 - the port number of the website if it’s not default 80443.

    • http-post-form - the service that you are trying to crack, Hydra can crack other logins, i.e. SSH.

    • ":/password=^PASS^: Invalid Password!" - the point of entry for Hydra, if there was a username input field, it would be prepended with :/user=^USER^&. The Invalid Password! section is to tell Hydra that if that text appears, the attempt was not successful.

    • -t 32 - tells Hydra to run 32 tasks in parallel.

    Lernaean 5

    After running the command, we get a password leonardo!

  6. After all that trouble, we get presented with this. Lernaean 6 Really HackTheBox? Really?

  7. I ran this through Burp Suite a few times trying to find anything, but i got zip zero nada. After wracking my brain for about 30 minutes, and Larry pretty much telling me to T R Y H A R D E R. I finally remembered that curl exists.
    Curl is basically a tool that allows your to send or receive files from the command line.
    I ended up using:
    curl --data-encode "password=leonardo" http://docker.hackthebox.eu:36983/
    This allowed me to get the flag! Lernaean 7 It was at this point that I was literally running laps in the classroom. There were 3 eye witnesses.

  8. A truly harrowing experience. However all of this could have been avoided if I decided to look closer at Burp Suite and find the response to the password. Something to remember for next time. Lernaean 8

Summary

Tools used:

  • Burp Suite - Interception proxy that has minimal setup and costs no money to use.
  • THC Hydra - Free brute force password cracker, some assembly required.
  • curl - Free command line tool to send/retrieve pages.

All of these tools are free and relatively easy to use.

Really puts into perspective how easy it can be to exploit web applications.

This process took approximately 2 - 3 hours, and I had no familiarity with these tools aside from Burp Suite before this.

Implications of this attack

So Lernaean has shown us that it is possible to brute force an administrator account on a web app, but what can we do with this? The end goal of any penetration testing/challenges is to get admin or root level access on a system or application. Administrators/Root level users have full access and permissions to that system, in a sense if you have that level of authentication, you would essentially own that machine, being able to do anything you wanted.

If you had administrator access to an e-commerce web application, you could redirect purchases made by customers to your own bank accounts or you could steal credit card information and sell it elsewhere for profit.

If you had root level access to a computer, you own that machine and can do anything you want, install malicious mining scripts, remote access tools or even install ransomware.

Impacts on Stakeholders

There will be an obvious reputation and financial loss to stakeholders in the event that this attack is successful. Having administrator level access to a web app would allow you to control all aspects of that web application.

In the case of the RSA Security hack in 2011, there was a financial loss of $66.3 million and obvious reputation loss, a security company as well known as RSA being hacked? They were certainly less trusted after the hack than they were before as a result of being breached.

Remediation

In the case that you are breached, first step is to secure your system, make sure to seal off the avenues that the hackers may have taken into the system. It’s recommended that businesses have a crisis management plan and follow it in the case of a data breach, it’s worth taking into account that data breaches require technical personnel to fix and public relations personnel to mitigate the damaged relations with the businesses customer base/clients.

After you’ve deployed patches and secured your system, you should start drafting up your disclosure to clients and the public about the circumstances of the data breach, what happened, how it happened, what you’ve done to recover information and the like. Businesses can survive data breaches so long as they act accordingly in the event of one, accept your fault in the situation and work to recover from it.

Security Prevention Systems and the SDLC

The Software Development Life-cycle (SDLC) is the process that software projects follow when under active development.

SDLC

The main issue that most companies face when implementing the SDLC with software projects is that they only think about the security of their product at the testing and integration stage.

Security should be intertwined with each step of the SDLC, theres no point only worrying about security when your product is half built and functional at the testing stage, and when you test it, you find it’s not secure at all and has to undergo more revisions of the SDLC to have it fully functional and secure.

Security Prevention Systems such as Intrusion Detection/Prevention Systems (IDS/IPS) is software that continuously monitors your platform for signs that indicate they’re under attack.

In theory, they sound great, but talk to any security professional and they’ll make their annoyance known.