At PentesterLab, we have been helping thousands of people become pentesters or better pentesters:
- with PentesterLab PRO offering for students/individuals/enterprises
- with our free Boot Camp
- with our awesome free content
- answering emails on career choices, debugging payloads,…
- running trainings and doing talks at conferences
- ...
From that, we put together the common mistakes aspiring pentesters make.
Only reading books
Don’t get us wrong, books are great. The problem is that a lot of people focus on reading books instead of gaining real hands-on experience. You can’t read about a bug class and expect to know about it. You need to see how the server responds, what happens if you try different payloads, how to debug your payloads. This is the only way to progress and to gain real understanding of security issues.
Practice makes perfect
Kali everything
Another very surprising misconception is that you need this kind of magic “HACKING COMPUTER” to perform pentesting/hacking. And you need to attack with your Kali system (directly or in a VM).
Kali is an extraordinaire potpourri of pentesting tools and is very handy when you get started for some tools that can be hard to install (especially Wifi drivers). However, you will probably be a lot more comfortable and efficient using your everyday OS and not jumping from your system to your “hacking VM” all the time. Especially if you are doing or learning web testing, you probably rarely need to use Kali. It’s also not always a good idea to run Kali as your main system as you will probably need to run other tools (productivity tools) that may be harder to get working on it (as opposed to a boring standard Linux distribution).
Kali everything
We get a lot of questions around payloads that didn’t work even if it did (visible thanks to our scoring system). Getting HTTP 500 errors doesn’t mean you didn’t successfully exploit the bug. Shellshock and a lot of serialisation issues are common example of bugs for which you will get code execution followed by a HTTP 500 error since the payload will trigger an unexpected behaviour.
“How can I make sure it’s not vulnerable”
When doing a blackbox test, aspiring/young pentesters always want to make sure a system is not vulnerable (“How do I know I didn’t miss something”). The truth is that you can never be 100% sure that a system is not vulnerable during a blackbox test. You will just make sure you run out of test cases to check if it was.
Spending too much time learning reversing/exploit writing instead of assessing systems, mobile and web
Reversing and writing exploits are amazing things to do and you should definitely look into these two domains. However, if you want to break into infosec and score your first job, you need to be good at web (and mobile and network to a lesser extend) security. Most pentesting companies have a lot of their workload composed of web testing and this is not going to change in the next few months. Furthermore, they also have seniors people who are dying to do more research and will probably have priority on all the reversing/exploit writing jobs. So if you want to increase your likelihood of getting hired, you need to become a gun at web pentesting.
The same thing applies to Bug Bounty, only few bounties require people to do reversing, most of them are web or mobile based.
And if you want to learn web security, no better place than PentesterLab ;)
Reading a lot of security news without going in depth
This one is actually for a lot of people. When you read security news, try to go in depth on at least one subject. If you read a CVE:
- Try to get a diff of the fix
- Try to exploit the issue
- Try to understand the root cause
- See if you can find a bug bounty program running the same application or with a similar issue.
Doing that once a week goes a long way.
You can stay a passive observer or become an active learner!
The same applies to conferences! After a conference, try to pick one talk and reproduce it.
Spending too much time building the perfect lab/laptop/…
Don’t waste time getting your perfect setup with a full network and multiple ESX servers as well as the perfect laptop. Just get started. It’s always easy to procrastinate and push back on what really matters. Don’t stay in your comfort zone. Just get started, start learning/hacking even if you don’t have the perfect setup. Truth is, there is no perfect setup and your needs will evolve over time with your work and research.
Not writing code/script…
Like you should expect a developer to know some security’s basics in 2018, you should expect a security engineers/pentesters to be able to write simple programs/scripts to perform basic tasks. As a tester, you need to automate stuff all the time. You need to be able to write small script:
- Write a small TCP client without too much search
- Parse a CSV file to extract a column without any Google search
- Send HTTP requests based on a previous script (for example)
- Write a decent size tool (as in more than 1k loc).
- How to use regular expression
- ...
Not reading code
To become a better tester, you need to read code. As a (web) pentester, half of your job is to understand what the source code on the server side looks like (for the client side, you often get the code). Guess what… reading a lot of code helps tremendously with that! You will also learn what mistakes people usually make. You can also read the code of your favourite tools to get a better understanding of their inner working as well as their limitations.
Learning 20 programming languages
It’s a common mistake to try to learn too many programming languages as well. Don’t get me wrong it’s a good idea to know a lot of them and their differences (especially to write web shell and for CTF). But before doing that, you need to learn at least one language pretty well.
- How to disable/enable certificate verification in this language
- Common mistakes you can make that introduces vulnerabilities
- Good resources about this language
- How to quickly patch some code to make something work
You should also understand (and be able to write) common programming patterns like:
- Running code in parallel (thread/fork/…)
- Publishing/consuming to a queue
- TCP and UDP client and server
- Reading data from STDIN.
Once you grasp harder concepts in one language, you will get a better understanding of common patterns and mistakes (vulnerabilities?) associated with those. This will help you find more bugs.
Finally, once you know one language well enough you can learn another one just by comparing it to the one you already know.
Conclusion
Hopefully, this list helped you a bit and you will avoid falling for some of these mistakes. The most important is to remember:
