Project

General

Profile

Actions
Copy link

Feature #5234

open

SSL/TLS Sticky Buffer for subjectAltName

Added by Genina Po about 2 years ago. Updated 19 days ago.

Status:
In Review
Priority:
Normal
Assignee:
Shivani Bhardwaj
Target version:
8.0.0-beta1
Effort:
Difficulty:
Label:

Description

Hi Team,

Does Suricata support parsing subjectAltName data into a SSL/TLS sticky buffer? If not, it would be a nice feature to have if the subjectAltName is present in SSL/TLS certificate or in the X509 extension.

The attached .pcap may be used to test this feature request.

Please note there is an observed inconsistency with how the subjectAltName is being parsed amongst Suricata engine versions.

If Suricata 6+ is used on the attached .pcap, the subjectAltName is parsed:
Suri7

issuerdn       C=XX, CN=mamzon.ru, L=XX, O=XX, OU=XX, ST=XX, Email=webmaster@mamzon.ru, subjectAltName=*.mamzon.ru www.mamzon.ru
sample: d08f862fc5830ad381db2027c10823c5

If Suricata 5 and below are used, the subjectAltName is not parsed:
Suri5 

'issuerdn': 'C=XX, CN=mamzon.ru/L=XX/O=XX/OU=XX/ST=XX/emailAddress=webmaster@mamzon.ru/unknown=*.mamzon.ru www.mamzon.ru',

Files

Download all files
d08f862fc5830ad381db2027c10823c5.pcap (1.53 MB) d08f862fc5830ad381db2027c10823c5.pcap Genina Po, 04/06/2022 11:22 PM
414db0257c6eb46.pcap (2.79 KB) 414db0257c6eb46.pcap Brandon Murphy, 04/03/2024 01:19 PM

Related issues 2 (2 open — 0 closed)

Related to Suricata - Task #4772: tracking: parity between fields logged and fields available for detectionAssignedVictor JulienActions
Related to Suricata - Optimization #6575: detect/multi-buffer: use single definition of struct PrefilterMpmKrb5NameIn ReviewPhilippe AntoineActions
Actions
Copy link
 #1

Updated by Victor Julien over 1 year ago

  • Status changed from New to Assigned
  • Assignee changed from OISF Dev to Shivani Bhardwaj
  • Target version changed from TBD to 8.0.0-beta1
Actions
Copy link
 #2

Updated by Brandon Murphy over 1 year ago

An example of where Subject Alt Name Parsing would be handy is a pattern observed within Glupteba's new TLS certs

Reference: https://www.nozominetworks.com/blog/tracking-malicious-glupteba-activity-through-the-blockchain/

https://crt.sh/?q=4c2bac6c0493203dabaed2b14b99f2f8f17a9cab804a5ac6efd0e6415dbc568b

Actions
Copy link
 #3

Updated by Juliana Fajardini Reichow 8 months ago

  • Related to Task #4772: tracking: parity between fields logged and fields available for detection added
Actions
Copy link
 #4

Updated by Shivani Bhardwaj 28 days ago

  • Status changed from Assigned to In Progress
Actions
Copy link
 #5

Updated by Shivani Bhardwaj 21 days ago

  • Status changed from In Progress to In Review
Actions
Copy link
 #6

Updated by Brandon Murphy 20 days ago

@Shivani Bhardwaj

Do you know what the behavior of this keyword is when there are multiple entires in the subject alt name?

the cert referenced within the crt.sh link above is a good example.

I was wondering if this supported multi-buffer mode, or if they were concatenated together in some predictable format (http.header_names style), etc.

Thanks for you work on this issue!

Actions
Copy link
 #7

Updated by Brandon Murphy 20 days ago

upload pcap of referenced crt.sh cert being sent to the client

Actions
Copy link
 #8

Updated by Philippe Antoine 20 days ago

  • Related to Optimization #6575: detect/multi-buffer: use single definition of struct PrefilterMpmKrb5Name added
Actions
Copy link
 #9

Updated by Shivani Bhardwaj 19 days ago

Do you know what the behavior of this keyword is when there are multiple entires in the subject alt name?

It traverses over all the subjectaltnames to find a match.
For example, for the pcap you have uploaded (Thank you! :) ), I see the following in the output and you should be able to alert against any of these.

"subjectaltname": [
      "server1.xn--j1ahhq.xn--p1ai",
      "server10.xn--j1ahhq.xn--p1ai",
      "server11.xn--j1ahhq.xn--p1ai",
      "server12.xn--j1ahhq.xn--p1ai",
      "server13.xn--j1ahhq.xn--p1ai",
      "server14.xn--j1ahhq.xn--p1ai",
      "server15.xn--j1ahhq.xn--p1ai",
      "server16.xn--j1ahhq.xn--p1ai",
      "server2.xn--j1ahhq.xn--p1ai",
      "server3.xn--j1ahhq.xn--p1ai",
      "server4.xn--j1ahhq.xn--p1ai",
      "server5.xn--j1ahhq.xn--p1ai",
      "server6.xn--j1ahhq.xn--p1ai",
      "server7.xn--j1ahhq.xn--p1ai",
      "server8.xn--j1ahhq.xn--p1ai",
      "server9.xn--j1ahhq.xn--p1ai",
      "xn--j1ahhq.xn--p1ai" 
    ],

Please see this test: https://github.com/OISF/suricata-verify/pull/1743/files#diff-1fe69d447a4f37103b703b8e6ef28039c0853a6120f7b962487ffef188722ab0R1

the cert referenced within the crt.sh link above is a good example.

I was wondering if this supported multi-buffer mode, or if they were concatenated together in some predictable format (http.header_names style), etc.

It is indeed supported in multi-buffer mode.
Please see this test for ref: https://github.com/OISF/suricata-verify/pull/1743/files#diff-7c7feedc3fa804dbd48367362fede7508f802e42fafe0f8cc69b7523fee22263R1

Please lmk if this makes sense to you or if something is not as per your expectations. Also, can I make the tests better?

Actions
Copy link

Also available in: Atom PDF