Feature #4227
openbreakout components of tls.cert_subject and tls.cert_issuer into additional "sub" buffers
Description
Problem¶
Writing signatures that use tls.cert_subject and tls.cert_issuer to match on content within the CommonName (or any other component) field while allowing for optional subdomains or wildcards and ensuring the desired value only occurs within the specific "certificate component" within the buffer requires PCRE matching. Additionally, without knowing the position of the specific "certificate component" within the buffer, the PCRE must be unanchored. This results in a rule that encounters higher level of ticks compared to non-pcre based rules. This is a common problem when reviewing research papers/blogs which provide only a C2 domain and indicate communications occur over TLS.
Proposal¶
Breakout the components of tls.cert_subject and tls.cert_issuer into "sub" buffers which will allow the use of transforms to make non-PCRE matches and more exact content matches.
Example Signatures:¶
Current Method¶
alert tls $EXTERNAL_NET any -> $HOME_NET any (flow:established,to_client; tls.cert_subject; content:"example.com"; fast_pattern; pcre:"/CN=(?:[^\r\n]+?\.)?example\.com(?!\.)/";)
Proposed Method¶
alert tls $EXTERNAL_NET any -> $HOME_NET any (flow:established,to_client; tls.cert_subject.cn; dotprefix; content:".example.com"; endswith;)
Notes of Interest¶
I've seen some certs that include an "emailAddress" in them as well, this would be a handy breakout as well
OU=rf23, ST=r32r23, C=BA, O=r32r, CN=tridayacipta.com/L=w32r32r3/emailAddress=3DS@fds.com
Problems with Proposal¶
1. There are some certificate components I've observed which suricata does not break out into "readable" names, which would make the "sub" buffers unusable. I'm not sure how this could be addressed.
"tls": { "subject": "OID(1.3.6.1.4.1.311.60.2.1.3)=US, OID(1.3.6.1.4.1.311.60.2.1.2)=Washington, OID(2.5.4.15)=Private Organization, OID(2.5.4.5)=600413485, C=US, OID(2.5.4.17)=98052, ST=Washington, L=Redmond, OID(2.5.4.9)=1 Microsoft Way, O=Microsoft Corporation, OU=Passport, CN=gateway.login.live.com", "issuerdn": "C=US, O=Symantec Corporation, OU=Symantec Trust Network, CN=Symantec Class 3 EV SSL CA - G3", "serial": "7E:91:C2:1D:E5:0B:21:74:6D:19:78:FA:4B:DE:BE:48", "fingerprint": "6c:dd:c8:d2:4e:b4:92:15:3f:af:76:5a:b0:77:a7:e9:5c:7f:5b:7a", "version": "TLSv1", "notbefore": "2015-11-20T00:00:00", "notafter": "2017-11-20T23:59:59", "ja3": { "hash": "de350869b8c85de67a350c8d186f11e6", "string": "769,4-5-10-9-100-98-3-6-19-18-99,,," }, "ja3s": { "hash": "5cd6efb8d804faf03e1462073b729151", "string": "769,10," } } }
Updated by Brandon Murphy over 3 years ago
Another use case for the "sub" buffers is for negations on specific components of the certificate. Such as negating on a domain found within the CommonName field. Similar to the above described problem, this requires an unanchored PCRE today to ensure the content negations exists only within the CommonName Field.
Updated by Philippe Antoine 4 months ago
- Assignee set to OISF Dev
- Target version set to TBD