Bug #5439
closedInvalid certificate when Issuer is not present.
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
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
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).
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 ?
Updated by Philippe Antoine over 1 year ago
- Status changed from Assigned to Feedback
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)
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" }
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 5925b63d82883dda61bac9b0a8e6dfc6f9da5755Should 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.
Updated by Philippe Antoine over 1 year ago
- Target version changed from 7.0.0 to 6.0.14
So, retargeting version
Updated by Philippe Antoine over 1 year ago
- Status changed from Feedback to In Review
Updated by Jason Ish over 1 year ago
- Related to Bug #5266: rust: update time dependency added
Updated by Victor Julien over 1 year ago
- Status changed from In Review to Closed