This document describes a technique called "backslash powered scanning" for automating vulnerability detection. It addresses the limitations of traditional scanners by iteratively probing websites using "probe pairs" to identify suspicious behaviors rather than scanning for known vulnerabilities. Probe pairs allow the technique to interrogate websites as a "black box" to determine input contexts and available functions. Attributes of responses are compared to gather evidence of potential vulnerabilities, which are then further explored. The technique aims to solve the "million payload problem" of testing all inputs and contexts exhaustively.
Imagine if you could conduct a pentest, and only do the interesting bits
Skip the hours of repetitive fuzzing and trawling through meaningless results, and jump straight to that one page that reacts in a mysterious way to your every input
that turns out to be code injection into a language you'd never even heard of, or SQLi behind a heavyweight filter that *almost* stops you from cracking open the database. The kind of page no black-box vulnerability scanner would ever find.
In this session, I'll share with you the conception and development of a new type of scanner that can find *research grade* injection vulnerabilities
45 plus questions
This all got started around four years ago. I'd just started a pentest on a company we'll call marketizer, and I had a problem that's probably familiar to many of you.
No credentials.
This was really upsetting. Just from the 90s visual design of the login page I could hear vulnerabilities screaming out at you? No attack surface
Didn't even know a valid username.
when I did get access, dumped out passwords naturally stored in plaintext and found director's password: [companyName1]
His username was more secure than his password
next time, I'll get access before the client gives me credentials. Letmein
Sometimes it worked spectacularly, but it mostly failed horribly
while trying to fix it, realised if I could use the response diffing tech for something far cooler, and that's what I'm here to share with you today
Three huge blind spots = million payload problem
I've avoided these issues by using a new approach, implemented in an open source scanner
Showcase the results of running this on live sites
By the end you'll know why scanners suck, how to build and modify a better scanner, how to use that scanner for maximum effectiveness
I work at portswigger where we make a tool you may have heard of called burp suite
My role is to design scanner checks
So although I'm about to spent some time slagging off scanners, it's coming from a position of respect
I think scanners are great I know they aren't close to their full potential at the moment
I also research new vulnerabilities. I spoke at black hat USA about a new type of vulnerability called Server-Side Template Injection. One of the objectives is to make a scanner that can do research for me.
Those are just the well known ones
@artsploit got RCE on demo.paypal.com via Dust.js
There's a huge tail of obscure tech. If you use it scanners will miss vulnerabilities,
Can happen in unexpected ways. For example, some scanners read the etc passwd file to identify XXE and LFI. Using SELinux can prevent a scanner from finding LFI. (the vuln still exists). That's pretty bad.
So, we're limited to languages we explicitly support like, say, PHP But how well can we do those?
of these three examples, two are from pentests
Most scanners will miss SQLi in double quotes
Assuming vulnerability is in a known technology, and there are no filters
Found because q has a spellchecker
Scanners can't do this, so they're reduced to best-effort payloads
Leads to people saying "scanners are good for finding low-hanging fruit"
which is a statement that breaks my heart
what we need and deserve is a scanner that finds high hanging fruit
If we want to make a scanner that doesn't have these blind spots, we need to harness the intuition that human testers have
Rather than sending a specific payload that says "find me injection into a double-quoted string being evaluated in PHP", we send a generic payload that says "find me something suspicious"
If they find something interesting, they focus on that area and gather further evidence
Concept: pairs of probes
To build something powerful, we need to start out with something crude and simple
This payload is about as simple as it gets
"nice try but there's no sqli here"
as a human, we can look at see what's going on
scanners try to simulate this by grepping for error messages: flawed – miss handled exceptions
We can use a property of the vulnerability to send a payload that is really similar but doesn't break
everything I'm going ot show you is built on this concept of pairs of almost identical probes
Concept: visual overview of last slide
base response - application's original response before we did any tampering
Does it change if we supply '
once again, we have something that's very efficient
Does it change back if we supply \'
=> something interesting is happening
the application is probably putting out input in a single quoted string
this decision tree underlies all the probe pairs
Using this concept of probe-pairs, we can ask questions of the application
You've already seen how to ask if we're in a single-quoted string
You can also ask...
This is a tiny sample of the questions you can ask
If you can think of a vulnerability you can express as a probe pair, you can add it yourself in five lines of code.
Concept: iteration
So that's cool, but the true power we can use the answers from these questions to decide what to do next
This can detect variants, it can handle filters, it can handle unknown languages
This is just one possible outcome from hundreds of combinations
Iteration makes this highly efficient - one request to majority of inputs
So it addresses all three blind spots!
I've got ahead of myself slightly - haven't defined how to know when two responses are different
simple equality will never work - meaningless junk
In order to use probes, we need to answer the question 'are these two responses significantly different'?
Originally tried to solve this by generating a regular expression
Most important thing to note is that at no point do we predict what effect a specific payload will have on the application
Here's a simple example - one valid attributes
This scanner has found real sqli vulnerabilities where the only tell is a single word disappearing
If there are multiple valid attributes they'll all appear in a table
Status code is normal
But the word count isn't static - it's changing randomly
Two causes - words attribute is overloaded, or our payload flawed
As of todays update, italics + starred
Should be taken with a pinch of salt
This diffing strategy is good, but we need to back it up with carefully crafted probes
Although the probe pairs look quite simple, the way they're chosen and delivered is really important.
This approach will only work if
Cosmetic variations
hopefully made sense
View from server log
This isn't relevant to interpreting results, so it could be skipped
Application expects specific input value
Syntax error indistinguishable from incorrect value
that's enough about how the scanner works in theory
'Black box' doesn't do this justice
The goal was to be polite and avoid flooding people with traffic, but the result (if you're just using backslash powered scanner) is really quite stealthy.
From the server's point of view, you're sending a tiny number of innocuous payloads really slowly. So it might come in useful if you're on a red team..
.mil blah
Helps to think of the scanner as a highly enthusiastic rookie security tester
Give them a well known vulnerability with no filters, they will identify exactly what's happening
Real report from a live website
That's cool but no better than any other scanner really.
The strength of this scanner will tell you "I've found something interesting"
This was the first critical vuln my scanner found
Can anyone tell me what this is?
Yep, blind spot #2. PHP with parenthesis filtered out
Missed because the input was in the path
Kind of thing you expect from an internet of crap device, not a household name website
Whenever you see a partial issue, you can be sure things won't be straightforward
When I tried to verify, all requests were being blocked by a WAF - got ip banned!
Affects over 100 servers
guess other scanners got banned before they finished the scan
if you spend hours investigating, possibly the most disappointing outcome
False positives are caused by flaws in the probe pairs,
The ones in backslash powered scanner have been gradually refined
But if you add your own probes, you'll need to refine then
Something's odd – 403 on valid function
Example of why payloads should be as similar as possible
By bringing the payloads syntactically closer, we've avoided the vulnerability
Another use of iteration!
Almost matches Java eval on single-quoted regex
\" causes an error when it shouldn't
Server-side HTTP Parameter pollution
If the frontend fails to URL-encode the input, they can injection extra paramters
It's easy to enumerate usernames if you start with a username you know is valid.
It's the same for parameters – you don't know in advance what the response to a valid parameter will be
Files/folders easy to do basic, needs this to be reliable
(hello mass assignment&extract)
Edge case detection:
Integer overflows {2147483647 vs 2147483648}
With a bit of creativity, we can go far beyond injection vulnerabilities
As a human, you can read that URL and know what it does
All the scanner sees is an input that's a number
Enumerable – we're accessing a set of items.
Need three unique responses because if we get two, then it could be the intended response, and something saying 'invalid id'
Kinda works but it will find things like calendars and other things than transform your input. We can filter out such things by asking the question..
Prototype of this has found all kinds of crazy things, planning on implementing next week
If you simply want to install it, it's in the bapp store
This is not one of those security tools that gets released in a presentation and never updated. It has huge potential and I'm planning on loads of improvements to it over the next few months.