WebGoat.* is a collection of insecure applications, mostly web, that allow a user to practice finding and exploiting vulnerable software. Since the web has become so popular of an initial attack, we begin this series with the .NET version of WebGoat that goes through the OWASP Top 10. In this series, we will perform white and black box testing to find exploits, exploit the condition, and finally secure the code.

WebGoat can be found here. Download on Commando, extract and open the solution.

Open in Visual Studio and hit build. Ensure we have no errors.

Now in Visual Studio terminal or powershell in the source directory type

dotnet publish -c release -o ./app

dotnet ./app/WebGoatCore.dll –urls=http://localhost:5000

Any errors that appear, will need to be resolved. In my case, I need to install the .netcore framework 5.

Phase 1

Reconossains.

Here we begin by browing the website, having a look around with the developer tools open and looking for potential errors.

First, we notice we can log in. Next, we notice the blog allows anonymous posting. Third, the browse section has an issues with images, a good sign the site may have configuration issues.

Visiting the login page, we try to login manually with username test and password password. We see an error that allows us to determine usernames. Trying different variants we also see we are never locked out. Returning information like usernames existing or not is a problem. Unlimited log ins also poses a major problem.

The blog allows anonymous posting. While this is probably not the best idea, in and of itself, it is not the main problem. Let’s attempt to post javascript to the login and see if it can be persisted. This could allow us to do a whole host of attacks on those visiting the page from stealing cookies to redirecting to a fake page.

Posting the <script>alert(“something to show the user”)</script> provides no error, and the comment is saved and the page reloads.

Note that just because <script /> works here, had the comment not worked, does not mean we would not be able to get something else to go through. Something say encoded? Give it a try.

Next, the products page shows an error with all the images. Errors are good signs of misconfigurations. Looking at the source, we see the url and attempt to load the image directly.

We are now given an error message providing a host of information to help us attack the site. Developer user message are a serious problem and must be turned off before release. Let’s attempt to traverse the directory using ../../3.jpg. An error.

On Commando Desktop open the tools folder. Browse Secure Lists and find directory traversal attacks. Let’s see if we can get to the c:\ directory. Other things to note about this exception are the user J, the downloads folder and what looks to be source controlled code. What can be done with this information?

We notice the dot, which means we can retrieve arbitrary data. Let’s attempt to get the file with curl.

Using curl to download the file, we do have to adjust our ‘../’ a number of times to ensure we get to the right place. We notice here the file is downloaded and have to change options slightly to be able to get to the file. We will pipe the file to a text file for reading.

How can that be done and what commands?

Next, can we get the sites DLL and decompile it somehow?

Next use cURL to retrieve the file and save it as a dll. Let’s save that for future use.

After our cursory review, let’s dig a bit deeper and open Burp Suite on Commando (or install it to your VM). Browsing to the site, we gather some initial information. Here we can see the headers and some odd values.

What do each of these headers mean and what do the values tell use? Can this information be used somehow to exploit the website?

Research how to use repeater and intruder to get the ini files above or different ini files. Even the images or other practice.

After some time, however, it becomes apparent we are limited with burp without purchasing the program. It is definitely worth the price and worth buying. For our demos however, we now switch to using ZAP the Zed Attack Proxy from OWASP. OWASP is the attack methodology we will follow in the future and a gentle introduction is worth the completing.

Notice in the top left the drop down with Standard Mode. Just browsing the site with standard mode provides a wealth of information. Changing from standard mode to attack mode now takes quite a while, but the amount of errors we find are significant.

Notice the open redirect. Can you use the XSS vulnerability and this open redirect to chain together something to exploit a user visiting the site?

Now we notice we have found User.txt and try to username/password combos to see if we can get in as an admin. Notice we could also try to brute force the login with ZAP or Burp Suite. We are taken to the admin page and notice an xml file for default cards is available. Maybe this is used to pay for suppliers or to test the site.

Either way, we are able to update the xml and perform to types of attacks.

Now, using Element and any, we can retried files or run commands. 

<!DOCTYPE foo [
  <!ELEMENT foo ANY>
  <!ENTITY xxe SYSTEM
  "file:///etc/passwd">
]>
<foo>
  &xxe;
</foo>

There is also ysoseriel the application we can use to generate deserialization attacks.

Remember the dll we downloaded? Using the Tools -> dotNet -> dnSpy we can decompile the DLL and look for more exploits to try out.