While searching for bugs on target website, I decided to check if it was vulnerable to blind XSS.
It turns out that the system was vulnerable to LDAP injection.
Some time ago I was assessing a website for vulnerabilities and I was reviewing all the possible endpoints.
While surfing, I encountered a registration form to the service, it was pretty packed with fields and it seemed your account needed to be valuated and activated by a human.
Usually registering to websites is a trivial test: if the website is built with a CMS, the workflow is pretty secure, otherwise there are chances to find some trivial SQL injections.
However, this time I tried to exploit some side-channel vulnerabilities: if someone needs to review my data, maybe I can inject something into their backend and extract some data?
That "something" is a blind XSS payload, where the payload is not executed directly on target website, but rather on another interface (for example admin backend).
Detecting blind XSS is a little more complicated than regular onces, since you don't know when (and if) the payload would be executed. A great online tool is XSS hunter, that allows you to setup a test subdomain that will collect a lot of info once the vulnerability is triggered.
So, I grabbed one of the default payloads, put into the fields and... bummer
Built-in WAF and elusion
Ok, it seems that there's some kind of protection in place.
After some reading, it seems that's the default WAF for .NET applications. However, when there are default settings there are known workarounds, too.
Searching on Internet, I found this article about some tags being allowed even if the WAF is turned on.
Long story short, tag
<%tag is allowed, which could cause isseus with IE9. Ok, it's quite old, but maybe it's my lucky day?
I put the payload into the form and... wait what?
Looking for the error code
0x80005000 and the error text
An invalid directory pathname was passed I learnt that they are related to an LDAP error.
This means that the server was taking user input with filtering it and trying to create a new user inside the LDAP server.
Exploiting LDAP injections is tricky, since they are ultra-blind and they aren't so common, I had to take back from the shelf my copy of The WebApplication Hacker's Handbook to refresh my memory.
Luckly the error page was enough for a valid POC, so I reported it back.
If I had to sum up the whole experience in one phrase, I'd chose Expect the unexpected.
Additionally, that's another reminder that you should never ever trust user input, even if there are protections in place.