Testing webapps, old and new

Well then, it’s the new year and I already got one pentest almost done, with about seven others in the making!

Why I am double-plus not good at web applications

Hacking web applications is currently the most in-demand service a pentesting company can provide. I bet you could name three companies off the top of your head that has a web application interface of some kind or another. This includes API, streaming services, and any new AI-slop SaaS you can think of. In short, webapps pay the bills. Unless your company wants to focus on a specific subset of penetration testing (like infrastructure, physical, social, etc.), you cannot afford to neglect web applications.

The reason I am nowhere near good enough in web application pentesting is simple: I never much cared for web applications. Ever since my Linux journey began, I preferred all my systems text-based. No GUI unless I had to, I even tried links for a few months (this blog is 98% created in neovim, btw). Furthermore, it was always easier for me to use the command line. It just made sense, you put something in, and read what comes out. You find a way, brute force some service, or generate some payload that gives you what you need. What more could I ever need? I am far behind the curve when it comes to web applications, and every time I encounter one, I get anxious. Why? I don’t have a workflow.

Having a workflow is half the battle

In network penetration tests, we can treat everything as a CTF. We scan for services, scan for vulnerabilities, try them, and if they work, we run the cycle again until we run out of time. There are attacks against people in the company we can run, spearphishing, etc. With webapps, it’s different: You get some accounts, and you have to find what’s wrong. The issue is the amount of data an application can spit at you. Just the home page shows me a ton of data that I have little understanding for, and it turns into reading the javascript line by line just to see what the application does, or just flop around and see what happens if I do something.

Add to that the situation where one application click can result in up to a dozen requests. The frontend talks to backend via API, then back to the frontend, some requests via WebSockets, and so on. The usual obsession with metrics and analytics makes my life even worse, with dozens of different requests for Google analytics. How am I supposed to make sense of it in the few days I have to test an application? This is where OWASP comes in.

Aside from OWASP Top10, which shows you the most frequently found vulnerabilities for webapps, mobile, and API, they also provide a “checklist” of sorts, the WSTG, the Web Security Testing Guide. Following it, it should be easy to check everyting possible, right?

That depends.

Webapps age like milk

In the last 3 months, I have come into contact with two web applications. The first one was an ancient product, originally developed and hardly maintained for around 8 years. It reeked of old-school UI, it was clunky, but it apparently did the job. (NOTE: This was a government-used application, which explains the UI). The other one was a few weeks before version 1.0, under very active development and made to the latest standards. Heck, I found a library that was about ten days old since release!

This difference should not come into account as far as testing goes (you still need to check everything), but one difference I may compare this to is a CTF, where the old service is DVWA where you can use known exploits, run XSS everywhere, LFI, RFI, the whole nine yards. The newer service has a much better security in terms of the low-level stuff, but in this case, business logic is the name of the game.

The old: Vuln galore

The old application test was almost amusing. It was in a test environment, no access outside, but no WAF. At that point, we found XSS in the first day (stored and reflected), code disclosure, LFI, RFI, basically anything that a web application can show you. Having been developed in the 2010’s, any exploit from 2016 onwards was fair game.

The client’s response was beautiful: They pleaded with us not to include everything (especially a finding about outdated libraries) and dragged us through meetings with their clients to explain that “really, it wasn’t that bad and that they could do something to keep the project secure.” All in all, they attempted to turn away from responsibility and even wanted a DocX version of the report to modify it.

The new: Business logic or bust

The new application was, as mentioned before, more secure on the software and maturity side. Any injection/SSTI/SSRF was met with a stern “this was an invalid action,” even without Cloudflare enabled. For 2 days, I just banged my head against a wall thinking I’d just toss the whole thing in the garbage, but I couldn’t just let it go. It was WebSocket hell and I wanted to find something.

On the third day, I found a breakthrough. I reset my approach for the nth time now, saying “Okay, I will go through every nook and cranny.” I checked the dumbest thing I could, the developer console in my browser, and there it was: A cookie labelled something like dev-mode. It was off. I turned it on, and guess what happened!

Yeah, I got access to the dev console. It wasn’t even what you may think, not a full admin access panel, but it provided me with a way to turn off Websockets, enable “Disaster logging” to overrun their own database with bullshit, etc.

From there, we found several nice vulnerabilities which would definitely result in monetary loss, but none of them were based on simply running a script and getting a great result. It was about thinking like a developer and attacker at once.

Developer: “What functions can I make quickly so that they work and don’t cost too much effort to develop?”
Attacker: “Where did the dev cut corners?”

I have yet to hear back from the actual dev team, but they appeared excited about my report.

Like a cow in a marijuana field

The way other clients came to use were along the lines of “Hey, we got an app, want to test it?” This client was different. My first meeting with them was so hostile I almost gave up.

The man I met that day is a great guy at his job, and he knows his stuff. Not my usual kind of crowd, with me being a massive fraud. Before the meeting, he sent me a PDF from another company and asked me to look at their results. I skimmed it, and concluded that “either they slacked off, or it is a great app. No big findings, one big one, several misconfigs in the DNS and stuff.” During the meeting, the guy spent about half the time hating on the company that did their pentest, saying they “don’t know shit” and that they are not paying for “some idiot to run an overpriced piece of software.”

*sweats in Burp Suite and Nessus*

Out of curiosity, I checked out the pentest company that did their first pentest (from Tor, just to be sure), and found out it was “the largest group of penetration testers in the country.”

Well fuck me. I and a buddy of mine were pitted against a team of dozens of people whose only job it was to pentest? I had no chance, right? If they didn’t find it, how could I?! The stakes have never been higher.

The big rugpull

Two days after the meeting, I’m working on the offer and contemplating just jumping out of a window to not bring shame on my family. At the low point, I get a message from the point of contact who just wanted to inform me about a finding from a dev. Apparently, this guy just checked the source code in the login page and found hardcoded credentials in a comment.

You could imagine me stepping off the ledge at that point, if they missed that, maybe I had a chance after all!

(I will keep you posted about how this evolves in this post or a quick update later this month.)

In closing

If I had to put the lessons learned into a Bear Grylls meme, I would say

Improvise, adapt, overcome

But really, it’s much simpler than that. Next time I get an application, I will have to think about what they are doing and if I encounter super-recent stuff, I will not waste my time trying to find a zero-day. I may find some, and I will, of course, test everything, but I will have to focus more on business-logic exploits, i.e. workflows and processes that users may be expected to perform (login, password change, 2FA) and focus on those more.

All in all, this has been a very fruitful engagement and please, keep your fingers crossed for me, because if this is not a total bust, I would love to get a look at their internal network.

See you in the next one, and thanks for reading!