Project

General

Profile

Actions

Feature #4227

open

breakout components of tls.cert_subject and tls.cert_issuer into additional "sub" buffers

Added by Brandon Murphy 9 months ago. Updated 4 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Effort:
Difficulty:
Label:

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," 
      }
    }
}
Actions #1

Updated by Brandon Murphy 4 months 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.

Actions

Also available in: Atom PDF