LDAP Injection Rule

[CRS-migration-bot]

Issue originally created by user dnkolegov on date 2016-01-14 05:44:24.
Link to original issue: SpiderLabs/owasp-modsecurity-crs#276.

The following LDAP injection vectors from Alonso-Parada research are not detected by current LDAP Injection Rule:

• foo)(sn=100
• printer)(uid=*)
• printer)(department=fa*)
• printer)(department=*fa*)

Burp Suite uses the following vectors to test an LDAP Injection and they are also not detected:

• eb9adbd87d)(sn=*
• eb9adbd87d)!(sn=*
• *)(sn=*
• *)!(sn=*

Also it is not obvious the purpose of the top and middle parts of regular expression that check values beginning with (:

(?:\((?:\W*?(?:objectc(?:ategory|lass)|homedirectory|[gu]idnumber|cn)\b\W*?=|[^\w\x80-\xFF]*?[\!\&\|][^\w\x80-\xFF]*?\()) 

Which LDAP injection context is supposed here?

[CRS-migration-bot]

User dune73 commented on date 2016-03-06 08:34:03:

dnkolegov : Let's try and get this sorted out.

Do you have the capacity to test any new rules proposed here? My ldap knowledge is fairly limited and I do not want to introduce false positives here.

I think together we can get it done.

[CRS-migration-bot]

User dnkolegov commented on date 2016-03-09 04:16:25:

I propose to consider the following regex:

^[^:\(\)\&\|\!\<\>\~]*\)(?:\((?:[^,\(\)\=\&\|\!\<\>\~]+[><~]?=|[&!|](?:\)|\()?)|\)\([\&\|\!]|[&!|]\([^\(\)\=\&\|\!\<\>\~]+[><~]?=[^:\(\)\&\|\!\<\>\~]*)

Tests:

foo)(sn=100
foo)(&)
documents)(security_level=*))(&(directory=documents
printer))(&
printer)(&
printer)(uid=*)
printer)(department=fa*)
printer)(groupType:1.2.840.113556.1.4.803:=2147483648)
printer)(department=*fa*)
*pri*nter*)(department=*fa*)
*)(objectClass=*))(&(objectClass=void
*)(objectClass=users))(&(objectClass=foo
void)(objectClass=users))(&(objectClass=void)
eb9adbd87d)(sn=*
eb9adbd87d)!(sn=*
*)(sn=*
*)!(sn=*
ka0x)(|(homedirectory=*)
5faa0382d747b754)(sn=*
5faa0382d747b754)!(sn=*
*)(uid=*))(|(uid=*
aaa*aaa)(groupType:1.2.840.113556.1.4.803:=2147483648)
aaa*aaa)(memberof:1.2.840.113556.1.4.1941:=cn=Group1,OU=groupsOU,DC=x)
aaa*aaa)(cn>=bob)
cn=Group1,OU=groupsOU,DC=x)(memberof:1.2.840.113556.1.4.1941:=cn=Group1,OU=groupsOU,DC=x)
cn=Group1,OU=groupsOU,DC=x)(memberof:1.2.840.113556.1.4.1941:=cn=Group1,OU=groupsOU,DC=x))(&(memberof:1.2.840.113556.1.4.1941:=cn=Group1,OU=groupsOU,DC=x)
eb9adbd87d)(userAccountControl:1.2.840.113556.1.4.803:=65536)

[CRS-migration-bot]

User dune73 commented on date 2016-03-09 05:18:27:

Thank you. That looks remarkable.

So this is a list of attack strings and a regex, which detects them?

What about false positives?

[CRS-migration-bot]

User dnkolegov commented on date 2016-03-09 05:41:52:

I tested this regex only for some valid LDAP filters:

(&(objectCategory=computer)  (userAccountControl:1.2.840.113556.1.4.803:=8192))
(objectSID=S-1-5-21-73586283-152049171-839522115-1111)
(userAccountControl:1.2.840.113556.1.4.803:=67108864)(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483648))

[CRS-migration-bot]

User csanders-git commented on date 2016-08-11 02:13:54:

dune73 i guess this never got added - it is great work though I think we should put it on the 3.1 list.

[CRS-migration-bot]

User dune73 commented on date 2016-08-11 03:19:24:

I like this as well. But I think we need somebody with real ldap experience telling us, if FPs are likely.
LDAP traffic is rare so I totally see us ship this regex and kill some site with it.

[CRS-migration-bot]

User dnkolegov commented on date 2016-08-11 03:43:52:

Updated regex (fixed whitespaces):

^[^:\(\)\&\|\!\<\>\~]*\)\s*(?:\((?:[^,\(\)\=\&\|\!\<\>\~]+[><~]?=|\s*[&!|]\s*(?:\)|\()?\s*)|\)\s*\(\s*[\&\|\!]\s*|[&!|]\s*\([^\(\)\=\&\|\!\<\>\~]+[><~]?=[^:\(\)\&\|\!\<\>\~]*)

[CRS-migration-bot]

User lifeforms commented on date 2017-09-24 11:11:17:

A new exploit: https://blog.ripstech.com/2017/joomla-takeover-in-20-seconds-with-ldap-injection-cve-2017-14596/

[CRS-migration-bot]

User dune73 commented on date 2018-12-17 13:24:30:

This is still not added and given our lack of knowledge for everything LDAP we would rely on dnkolegov's word to go and include this into our rule set.

So dnkolegov, are you actively using this rule on your server(s)? Any feedback with regards to false positives?

[CRS-migration-bot]

User dnkolegov commented on date 2018-12-18 09:55:36:

This rule was developed and used within a proprietary Positive Technologies' Application Firewall. I do not remember customer requests regarding this rule. But I have not been working there for 2 years, so I do not have actual information.

[CRS-migration-bot]

User dune73 commented on date 2018-12-18 09:59:52:

Thank you for writing in again, dnkolegov!

So what do we do guys: I see this as a new paranoia level 3 rule, or we drop the endeavour despite the good contribution by dnkolegov because we simply lack the knowledge to support this.

[CRS-migration-bot]

User lifeforms commented on date 2018-12-18 10:28:49:

I would argue to bring back the rule in the default set (paranoia level 1). Vulnerability to LDAP injection may be somewhat rare, but nevertheless it's a well published attack class, I could see it being important to enterprise users, and even OWASP and Webappsec wikis have extensive pages on it.

The LDAP injection rule was present in CRS 2.x but removed, I have no data why, but I can't recall ever having operations trouble with the rule myself.

Our old rule was apparently not having enough coverage, but with the improvements by dnkolegov
it's a good start, he has supplied material for adding unit tests, and if users turn up more payloads we can handle them incrementally.

A risk could be false positives, but we'll have our regular development cycle with the release candidates to flesh them out. We can be a little more bold at the start of a cycle, and if we run into trouble we can always put the rule in a higher paranoia level.

[CRS-migration-bot]

User dune73 commented on date 2018-12-25 21:02:27:

OK. Let's do that. I'll prepare a PR.

[CRS-migration-bot]

User dune73 commented on date 2019-03-11 21:11:38:

I've done the following rule now

SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "@rx ^[^:\(\)\&\|\!\<\>\~]*\)\s*(?:\((?:[^,\(\)\=\&\|\!\<\>\~]+[><~]?=|\s*[&!|]\s*(?:\)|\()?\s*)|\)\s*\(\s*[\&\|\!]\s*|[&!|]\s*\([^\(\)\=\&\|\!\<\>\~]+[><~]?=[^:\(\)\&\|\!\<\>\~]*)" \
    "id:921190,\
    phase:2,\
    block,\
    capture,\
    t:none,t:htmlEntityDecode,\
    msg:'LDAP Injection Attack',\
    logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
    tag:'application-multi',\
    tag:'language-ldap',\
    tag:'platform-multi',\
    ctl:auditLogParts=+E,\
    ver:'OWASP_CRS/3.1.0',\
    severity:'CRITICAL',\
    setvar:'tx.msg=%{rule.msg}',\
    setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}',\
    setvar:'tx.%{rule.id}-OWASP_CRS/LDAP_INJECTION-%{MATCHED_VAR_NAME}=%{tx.0}'"

Triggered with $> curl localhost -d "a=printer)(department=fa*)"

Question: Where do we put this. I've added it to 921, protocol attacks, but so far there are only http protocol attacks in this group. Other options?

[CRS-migration-bot]

User dune73 commented on date 2020-02-11 14:06:34:

During the monthly CRS community chat, I re-confirmed my lifelong commitment to this problem and I promised to make this into a PR and get it merged.

Meeting minutes: SpiderLabs/owasp-modsecurity-crs#1671 (comment)

[CRS-migration-bot]

User dune73 commented on date 2020-05-05 12:50:52:

A long story comes to an end. We merged the fix for this with PR #1707.

Thank you for your contribution dnkolegov.