Project

General

Profile

Actions

Bug #5439

closed

Invalid certificate when Issuer is not present.

Added by Brandon Murphy over 2 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Target version:
Affected Versions:
Effort:
Difficulty:
Label:
Needs Suricata-Verify test

Description

When investigating the Sliver Framework, it was observed that certificates which lack an Issuer (or contain an issuer with a 0 length) are not parsed by suricata.

In attempting to write signatures for the framework, this lack of parsing resulted in rules which were written without the aid of typical TLS buffers and do not perform well.

Is it possible to somehow allow the tls.cert_subject buffer to still be populated and detected against?

Anomaly Log

[
  {
    "timestamp": "2022-07-05T19:04:40.880329+0000",
    "flow_id": 1013180826924639,
    "pcap_cnt": 7,
    "event_type": "anomaly",
    "src_ip": "192.168.116.130",
    "src_port": 54080,
    "dest_ip": "54.206.116.39",
    "dest_port": 443,
    "proto": "TCP",
    "pkt_src": "wire/pcap",
    "community_id": "1:TQlCVrrpCtVqPOOUKXjZ0qVC5qU=",
    "tx_id": 0,
    "anomaly": {
      "app_proto": "tls",
      "type": "applayer",
      "event": "CERTIFICATE_INVALID_DER",
      "layer": "proto_parser" 
    }
  }
]

sid:1; does not fire on sliver_cert_2.pcap

alert tls any any -> any any (msg:"test"; flow:established,to_client; tls.cert_subject; content:"localhost"; sid:1;)

sid:2; which makes no use of TLS buffers does fire on sliver_cert_2.pcap

alert tls $EXTERNAL_NET any -> $HOME_NET any (msg:"ET ATTACK_RESPONSE Sliver Framework TLS Certificate Observed M4"; flow:established,to_client; content:"|16|"; content:"|0b|"; within:8; content:!"|06 03 55 04 0a|"; distance:0; content:"|06 03 55 04 06 13 02|US"; distance:0; content:"|06 03 55 04 08 13 07|Arizona"; distance:4; within:14; content:"|06 03 55 04 07 13 0a|Scottsdale"; distance:4; within:17; content:"|06 03 55 04 09 13 00|"; distance:4; within:7; fast_pattern; content:"|06 03 55 04 11 13 04|"; distance:4; within:7; pcre:"/^\d{4}[01]/R"; content:"|06 03 55 04 03|"; distance:3; within:5; content:!"|2a 86 48 86 f7 0d 01 09 01|"; sid:4; rev:1; classtype:trojan-activity; reference:url,github.com/BishopFox/sliver/blob/97d3da75b6e24defb3a2a97443a15a632b3a8448/server/certs/subject.go;)


Files

sliver_cert_2.pcap (3.24 KB) sliver_cert_2.pcap Brandon Murphy, 07/07/2022 05:25 PM

Related issues 1 (0 open1 closed)

Related to Suricata - Bug #5266: rust: update time dependencyRejectedActions
Actions #1

Updated by Victor Julien over 2 years ago

Looks like this is an issue in tls-parser https://github.com/rusticata/tls-parser/issues/37

Actions #2

Updated by Victor Julien over 1 year ago

  • Label Needs Suricata-Verify test added
Actions #3

Updated by Victor Julien over 1 year ago

  • Status changed from New to Assigned
  • Assignee changed from OISF Dev to Philippe Antoine
  • Target version changed from TBD to 7.0.0

Fix should probably be in tls-parser or der-parser (see ticket link above).

Actions #4

Updated by Philippe Antoine over 1 year ago

@Brandon Murphy I do not reproduce the problem on latest master cf https://github.com/OISF/suricata-verify/pull/1255

Could you confirm ?

Actions #5

Updated by Philippe Antoine over 1 year ago

  • Status changed from Assigned to Feedback
Actions #6

Updated by Philippe Antoine over 1 year ago

This fails on suricata 6
master6 has x509-parser = "0.6.5" when master has 0.15.0 cf commit 5925b63d82883dda61bac9b0a8e6dfc6f9da5755

Should we retarget this ticket to 6 only ?
Can we upgrade x509-parse on master6 ? (looks like it needs a nom7 update)

Actions #7

Updated by Brandon Murphy over 1 year ago

Tested against RC3-Dev (643e674cb 2023-06-16) and I was not able to replicate. So looks fixed in suri7.

"tls": {
      "subject": "C=US, ST=Arizona, L=Scottsdale, streetAddress=, postalCode=6565, CN=localhost",
      "issuerdn": "",
      "serial": "00:99:EB:86:2A:01:F8:48:DD:B2:A6:39:F2:1A:FC:03:54",
      "fingerprint": "fa:5f:67:f7:3e:6e:24:53:e8:17:5d:7f:bc:a6:bc:20:66:fb:62:12",
      "version": "TLS 1.2",
      "notbefore": "2021-12-26T00:39:18",
      "notafter": "2024-12-25T00:39:18",
      "ja3": {
        "hash": "bcd93fc89dba4639942325c540ce598c",
        "string": "771,49196-49200-159-52393-52392-52394-49195-49199-158-49188-49192-107-49187-49191-103-49162-49172-57-49161-49171-51-157-156-61-60-53-47-255,11-10-13172-16-22-23-13,29-23-30-25-24,0-1-2" 
      },
      "ja3s": {
        "hash": "2de81c22ea32a57162df5cb08d4a2795",
        "string": "771,49199,65281-16-11" 
      }

Actions #8

Updated by Jason Ish over 1 year ago

Philippe Antoine wrote in #note-6:

This fails on suricata 6
master6 has x509-parser = "0.6.5" when master has 0.15.0 cf commit 5925b63d82883dda61bac9b0a8e6dfc6f9da5755

Should we retarget this ticket to 6 only ?
Can we upgrade x509-parse on master6 ? (looks like it needs a nom7 update)

Updating x509-parser on master-6.0.x is more invasive than we'd like, most significantly is it would require an update to the MSRV. Another option could be create a fix for the x509-parser 0.6 branch and request a release of 0.6.6.

Actions #9

Updated by Philippe Antoine over 1 year ago

  • Target version changed from 7.0.0 to 6.0.14

So, retargeting version

Actions #10

Updated by Philippe Antoine over 1 year ago

  • Status changed from Feedback to In Review
Actions #11

Updated by Jason Ish over 1 year ago

  • Related to Bug #5266: rust: update time dependency added
Actions #12

Updated by Victor Julien over 1 year ago

  • Status changed from In Review to Closed
Actions

Also available in: Atom PDF