Millions of accounts compromised because there is no specialised user database

Re:Millions of accounts compromised because there is no spec... by viraptor on Wednesday April 22, 2015 @07:24PM (#9424206)

Uncommon - yes. Can do less than SQL injections - yes. Read-only - yes.

But it does exist. Saying that LDAP auth[nz] code should set sizelimit to 1 is like saying SQL auth[nz] code should set LIMIT 1. Correct and defensive code does that. But there's still code out there which doesn't and is vulnerable.

Then again, I don't think you understood the second example. It's not for auth, but rather user search - which is the probably the second most common corporate ldap usage.

As for LDAP injection being nonsense, how about searching some CVEs:

- LDAP injection and resulting STORED Cross Site Scripting in Events Planner - SmarterMail 7.x (7.2.3925) - https://www.exploit-db.com/exploits/15189/

- Graylog2 before 0.92 allows remote attackers to bypass LDAP authentication via crafted wildcards. - CVE-2014-9217

- PowerDNS before 2.9.18, when running with an LDAP backend, does not properly escape LDAP queries, which allows remote attackers to cause a denial of service (failure to answer ldap questions) and possibly conduct an LDAP injection attack. - CVE-2005-2301

And many many more...

[ Parent | on HN ]

Re:Millions of accounts compromised because there is no spec... by hyc_symas on Wednesday April 22, 2015 @11:43PM (#9424908)

For user search you still would set a size limit, and a server admin would set a server-side size limit to avoid other resource hogging issues.

I concede the point that there's poorly written code out there that is vulnerable. Still, to lump this into the label of "injection attack" along the lines of SQL injection attacks is grossly misleading. An SQL injection attack can cause destruction of data, invocation of arbitrary commands on the backend, and innumerable kinds of other mischief. A misparsed LDAP filter can do none of these things.

[ Parent | on HN ]