Growing up in the Netherlands, Pepijn van der Stap started hacking when he was 14. At 16 he realized it didn’t just have to be a hobby. With a background in software engineering Pepijn was excited to come work for Hadrian, to grow himself professionally, and combine his passion for hacking with his passion for development. In this interview, Pepijn discusses the vulnerabilities he’s coming across most often, why they’re emerging, and how the scale of Hadrian’s hacking ambitions and its event-based framework has led him to think about code in new and exciting ways.
The first question is a bit straightforward, but also something I always want to know when I meet hackers: How did you first become interested in hacking?
From a young age I was really interested in IT. However, I didn’t want to use things the way they were intended to be used. I wanted to use technology the way I wanted to use it. It was the desire to make technology work in the way I pictured it that led to me becoming interested in hacking. At 14 I discovered how easy it was to access websites, and how absurdly simple I could gain access to restricted data. I would try changing numbers in the requests, and I would apply common methodologies to test the limits of what I could do. I was constantly trying new strategies and learning.
When I was 16 I discovered a website with a responsible disclosure policy, and that was my first inkling that hacking could be more than a hobby. I was studying software engineering at the time, and when I finished my internship in programming I began to focus on the security sector. Getting involved in the security sector was when it really clicked for me that I could turn hacking into a profession.
Having a background in software engineering must have given you an edge when it came to approaching exploits. How do you feel that studying software engineering has impacted your approach to hacking?
My background in software engineering has given me a better sense of the business logic of a company: what’s a real risk, how a specific application works. Because of my background, when I conduct pentests I really understand what’s going on behind the scenes.
Are business logic vulnerabilities increasingly common in the work that you’re doing?
I think business logic vulnerabilities are one of the most impactful vulnerabilities I’m seeing right now. Even on web applications that put a lot of effort into secure development, business logic vulnerabilities are everywhere.
One vulnerability that I discovered recently - was really impactful because it didn’t just give access to the website of the company I was testing, but also to the IT company behind the application. I got server access after only a few days of research because the application only allowed certain users to just upload any file, but the web app did not perform checks against whether the username belonged to the current session. It’s examples like that which show just how impactful business logic vulnerabilities can be to supply chains: not only their customers were at risk, but the Managed Service Provider also exposed all other clients.
Why do you think business logic vulnerabilities are becoming increasingly common?
I think that companies are developing a lot of applications these days. Some companies create a new application for every little event they do. For instance, they’ll create a new website for a giveaway and then forget about the website. When you’re launching that many applications so quickly it makes it hard to monitor them all and to make sure that they’re developed in a secure way. From a hacker’s perspective, you look at all those applications and it’s easy to find one that gets you right to the core of the business.
Do you feel that the Hadrian product will help defend against these kinds of vulnerabilities?
It’s really hard to determine what is a risk for a company in terms of business logic vulnerabilities so I think the help Hadrian will give is in a more indirect way. By automating the easier vulnerabilities, Hadrian will free up hacker time to focus on really figuring out what is a risk for a company and targeting those more custom business logic vulnerabilities. Also, the visualization of the attack surface Hadrian supplies will help hackers manually see all the company’s assets in one place. That visualization will make it easier to pentest certain applications, and look deeper, rather than having to do the discovery process over and over again. Instead of repeating all the reconnaissance you can just pick a target and begin to test. This really aids hackers in automating their research.
It seems that Hadrian compliments the work that hackers are already doing then in a nice way. I noticed that you’ve done a lot of work researching vulnerabilities, has working at Hadrian required a different approach than you’re used to?
There are generally two ways of approaching research on a potential vulnerability: You can search for something in the product, which can take weeks, or you can write a specific exploit for a specific application and use it against your customers. What we’re doing at Hadrian is a little bit different. We’re trying to identify what type of software and products are running for the customers, and then doing simple exploits on them based on that research.
In some ways what we’re doing is a very different approach. When I’m doing basic research I’m testing one specific application that is used by a lot of different customers, but we’re trying to find vulnerabilities in a lot of applications at the same time. This approach means that we’re doing really small checks, for instance trying request smuggling at a large scale. Instead of writing one huge exploit, we’re writing a lot of small scripts that can do different checks.
The event-based framework of Hadrian also forces us to consider our scripts in a unique way. For example, we end up writing specific scripts for ‘triggered’ events. If we know a web server runs a specific software, we write the script that will be deployed if that software is identified.
What’s the most exciting project that you’re currently working on at Hadrian?
One of the most recent projects I’ve worked on involves rewriting some really old exploits from Java in Go. They were originally written in Java which makes them hard to scale and thus not fit for our purposes. Someone wrote thousands of lines of Java that takes minutes to run - you look at it and it’s really hard to understand what’s happening in the script. When you switch it over to Go it runs in seconds, and it’s less lines so it’s easier to maintain. While it might seem simple, people have forgotten about these exploits a bit, which makes turning them into scalable tools really exciting.
Finally, I have to ask, what’s been one of the best parts about the work-style of Hadrian?
Honestly, freedom. Normally I find it hard to make time to write my own code, and automate the tools I want to automate. At Hadrian, there’s a focus on what you produce rather than keeping you to a strict timetable. I can switch back and forth between writing code for myself and then writing code for Hadrian. It allows me to be creative, and innovative which I really appreciate.