Searching for XSS found ldap injection

nc-lp.com · devanshbatham/Awesome-Bugbounty-Writeups · 22 hours ago · vulnerability
quality 6/10 · good
0 net
AI Summary

A bug bounty hunter discovered LDAP injection vulnerability while testing for blind XSS on a registration form; the application was vulnerable to LDAP injection despite having a .NET WAF in place, with the error message revealing LDAP directory pathname errors that enabled exploitation.

Entities
XSS Hunter The WebApplication Hacker's Handbook Davide Tampellini
Searching for XSS found LDAP injection | nc-lp.com nc-lp.com Blog Why this name? Contact Searching for XSS found LDAP injection 5th Jun 2018 vulnerability 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. Context 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? Blind XSS 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? LDAP injection 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. Oh Boy! 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. Conclusions 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. Related Posts Comments: Blog Comments powered by Disqus . Newer Post Older Post Home " Davide Tampellini This is 10% luck 20% skill 15% concentrated power of will 5% pleasure 50% pain And a 100% reason to remember the name SimpleSearch Popular Tags web scraping full disclosure vulnerability passwords reverse engineer Archives 2 January 2019 1 December 2018 1 September 2018 1 August 2018 1 July 2018 1 June 2018 1 May 2018 1 April 2018 2 July 2017 1 April 2017 2 March 2017 1 February 2017