Finding Jank, doing better penetration tests

Introduction⌗

This is a heavily opionated piece about finding unique vulnerabilities.

What is Jank⌗

Let’s look up some definitions:

1. Ostensibly back-formation from janky (“shoddy, poor quality”).
2. Problematic blocking of a software application’s user interface due to slow operations.
3. Jank is like making a Rube Goldberg machine to open a door when you could just turn the handle.
4. I like to define jank as [something] that has found its usefulness in an unexpected way.

After looking at these definitions, I wasn’t really that happy with them. I’ve been using the word a bit differently…

So I’m just going to define what I think of it:

A problem that exists that defies all logic, or a macgyvered solution or technique that works, but really feels like it shouldn’t. Normally, a persons response whould be ‘What the heck’ i.e.

Did you see that I put /// in the URL to cause an open redirect… pretty jank right?

Now we are all on the same, albeit a bit crazy, page I can start talking about why you want to find jank, and how you might go about doing it.

Why do we want the jank⌗

Finding new, novel and unique vulnerabilities is what I think drives us as a community forward. Finding the same stored XSS bypasses in the same websites over and over is definitely a worthy cause, it helps businesses understand and fix security issues that could cause real world impact. This methodology is very good for helping companies be assured that their security measures have been impactful. However, in my brain, this moves us away from the goal of “breaking stuff” and more towards the goal of “assuring that something can’t be broken”. Penetration testing companies always give clients caveats that they can’t find everything, but I don’t think this really sinks into most project managers brains. Penetration testing goes from an exercise into understanding how impact can be leveraged between systems to cause damages, into a mandatory assurance step to prevent hackers getting in.

As I’ve been doing penetration testing the last year, I’ve been doing better on-boarding interviews, trying to ask crazy important questions like “what is the motivation for this test?” (This might sound like a no-brainer, but it’s actually not a normally asked question). In this motivation section I normally end up with something like:

• We do a penetration test every year.
• This is part of XXXX audit process.
• Our clients want a copy of the report

The underlying sub-text when you hear this is make us look good. The goal of the penetration test has moved from understanding risk to assuring customers that everything’s okay. In fact one client even asked for an assurance level penetration test… whatever that means.

Okay, so customers want us to assure them everything is okay… so that’s what we should do right? Give the customer what they want! The sad truth is that sometimes what customers want, which is a big green rubber stamp, is different to what they need, a report outlining how a single compromise is one step away from important customer data. At the end of the day the moral goal of penetration testing is to protect the company and the customers, not to make the one manager who ordered the testing happy.

So where does jank tie into this? Well I think that moving the testing methodology away from finding all bugs towards finding bugs that show impact helps better position you to understand the underlying risks the company faces, and to provide a report that can help drive change in organisations handling and management of security. Now, in our pursuit of finding bugs that show impact, we are going to take a slightly different approach to what a lot of testers do. We are going to have to think like a red-teamer.

A different approach⌗

For this section I’m going to heavily reference a book that I think all security professionals focused on offensive testing should have a gander at, Red Team Development and Operations… particularly the introduction. All quotes in this little sub-heading come from there 😊.

Let’s start by understanding first what a threat looks like:

Remember, a threat is really [just] an intelligent person determined to cause harm.

For most organisations, your threat is human being who has goals. They might want access to sensitive data, access to the underlying server or just to cause havoc.

The goal of a penetration test is to determine the risk associated with vulnerabilities and flaws. Penetration tests should be considered an effort in attack path validation with a goal to reduce the attack surface.

Our goal as penetration testers is to show how the vulnerabilities can be used to achieve impact. There is no point saying that you achieved Domain Administrator (DA) in a report, DA is not impact, it’s a level of privilege. The impact from this level of privilege is that you can access a file share containing financial records, or send emails as the CEO. This description shows an attack path, and helps for non-technical people to understand the impact.

In this way, you might say to yourself, okay if I’m trying to find vulnerabilities that demonstrate impact… how might I go about that? Well you’re going to have to try new things… and some of those things might make someone go what the heck… Introducing: jank.

The core tenants of jank⌗

Just try it⌗

People put boxes in their brains to say when something should and shouldn’t work. It helps them operate more quickly. Sometimes it’s best to throw that out. Every environment is slightly different, and weird behaviour can show up. You know that your AV bypass doesn’t work for Windows Defender, so it shouldn’t work for CrowdStrike’s EDR solution. Only logical. Oh whoops you tried it and it worked…

¯\_(ツ)_/¯

Put away the tools⌗

Most penetration testing tools are designed to look for the known. They help penetration testers to identify the same types of vulnerabilities. Put them away. Bye bye Nessus¹. Now I’m not saying put away Burp Suite or ffuf, but understand why you are using them and try not to rely on any automated scanning functionality.

Try stuff that no one else would⌗

Try something new, even if it sounds a bit ridiculous. Some good examples of real world jank I’ve found are:

• Accessing the read/write endpoints without Authentication headers at all.
• Performing NTLM relay on a windows server to itself on SMB².
• Accessing and downloading containers manually from a registry via the extra web UI when docker pull required authentication.
• Navigating to http://server.com///test.com to find an open redirect.
• Finding un-linked functionality in a developer version of a website, then exploiting this functionality on the main website.
• Accessing another users session by removing the authentication header and refreshing a bunch. (Thanks caches)

Have fun⌗

The number one benefit in trying to find jank is in trying to have fun. The more that penetration testing feels like play to me, the more I can employ variety and creativity. This might not work for you, but give it a go :).