Tips for an Information Security Analyst/Pentester career - Ep. 48: Web application pentesting

This post will deal with web application pentesting.

For this post, I'm going to use a vulnerable web app included in Georgia Weidman's book (within its additional files), based on IIS and SQL Server 2008.

I'm going to use BurpSuite to intercept and manipulate web requests.

Prep

Let's start out by inserting a single quote symbol in the login field. If any input validation were in place, nothing should happen, because the single quote wouldn't be an allowed character.

There's no reason why you should have such character in a login field, you should be allowed letters, numbers and specific characters such as dashes and underscores only.

Instead, lo and behold, we get a very nice error message, returning useful information about the back-end database.

Thank you, webmaster!

By entering a SQL injection in the login field (see video for more details), we can login as user Mike, very likely the first user in the database.

If we go to Profile/View Newsletters, we notice another handy input field, where can we look for the latest newsletter.

Intercepting the GET request with BurpSuite, we notice that each user has a newsletter, stored in a folder that's personal for each individual user.

The newsletter functionality seems to grab the newsletters from the local filesystem by using absolute paths.

Furthermore, it seems to be using the directory C:\inetpub\wwwroot\Book, instead of bookservice, as we would have expected.

If we change the file path within BurpSuite and forward the request, we can try accessing other files inside that directory.

Specifically, we can access the source code for the web server and, if change the filepath by including Authinfo.xml, we can also see all existing users and passwords listed in plaintext.

Needless to say, this shouldn't be going on.

Command injection

The Newsletter Signup field is vulnerable to command injection, so we can run the ipconfig command and store the content to a text file.

For this purpose, we're gonna run the command username@example.com & ipconfig  > C:\inetpub\wwwroot\Book.test.txt.

In the video, I inadvertently misspelled the output file name to text.txt, however, if we connect to its URL, we can see the output from the ipconfig command on the backend server.

Needless to say, this shouldn't be going on.

Wrap-up

This simple walkthrough points out once again how following secure coding practices is paramount for a web server to remain secure.

Input validation, a web application firewall and server-side validation would prevent such situations from occurring, but that's exactly how breaches often happen.

Overlooking these issues can lead to massive breaches, like Equifax and other recent cases have so dramatically shown.

Episode 49

Episode 47