Open Information Security Foundation: Issueshttps://redmine.openinfosecfoundation.org/https://redmine.openinfosecfoundation.org/favicon.ico?17011170022024-03-25T13:22:29ZOpen Information Security Foundation
Redmine Suricata - Bug #6897 (In Review): detect/port: upper boundary ports are not correctly handled (7....https://redmine.openinfosecfoundation.org/issues/68972024-03-25T13:22:29ZOISF TicketbotSuricata - Bug #6896 (Resolved): detect/port: upper boundary ports are not correctly handledhttps://redmine.openinfosecfoundation.org/issues/68962024-03-25T13:22:19ZShivani BhardwajSuricata - Bug #6894 (New): bsize valdation FP on content negation with hex encoded 0d 0ahttps://redmine.openinfosecfoundation.org/issues/68942024-03-24T22:43:09ZBrandon Murphy
<p>consider the following rule, which contains</p>
<pre>
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"TEST"; flow:established,to_server; http.header_names; bsize:10; content:!"|0d 0a|User-Agent|0d 0a|"; content:"|0d 0a|Host|0d 0a 0d 0a|"; sid:1;)
</pre>
<pre>
[129 - Suricata-Main] 2024-03-24 22:40:11 Error: detect-bsize: signature can't match as required content length 14 exceeds bsize value: 10
[129 - Suricata-Main] 2024-03-24 22:40:11 Error: detect: error parsing signature "alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"TEST"; flow:established,to_server; http.header_names; bsize:10; content:!"|0d 0a|User-Agent|0d 0a|"; content:"|0d 0a|Host|0d 0a 0d 0a|"; sid:1;)" from file /tmp/49c7c31b54ecbe71_Mar-24-2024_22-40-11/dalton-custom.rules at line 1
</pre>
<p>I've been able to isolate the issue to the hex encoded values within the content negation.</p>
<p>if you remove one of the <code>|0d 0a|</code> within <code>content:!"|0d 0a|User-Agent|0d 0a|";</code> the error produced reports a required length of 12.</p> Suricata - Bug #6886 (Assigned): HTTP Chunk Length Value disappearinghttps://redmine.openinfosecfoundation.org/issues/68862024-03-22T15:13:35ZTony Robinson
<p>Hey folks!</p>
<p>I'd like to report what I think is an issue with Currently supported (and developing) versions of suricata - 6.x, 7.x and 8.x.</p>
<p>Recently, I was working on providing coverage for cve-2024-21762. To summarize, its an issue with Fortinet FortiOS products and their handling of chunked HTTP requests.</p>
<p>Bishop Fox developed a python script that can be used to test whether fortinet products are vulnerable to exploitation of this CVE. The original code is here: <a class="external" href="https://github.com/BishopFox/cve-2024-21762-check">https://github.com/BishopFox/cve-2024-21762-check</a></p>
<p>I made some slight changes to the code in order for it to throw the vulnerability check over plain HTTP. I've taken the liberty of attaching my modified script to this request.</p>
<p>So I ran the exploit checker against python http.server listening on port 80 in order to just get the pcaps I needed. I wrote a relatively simple rule designed to capture vulnerability checks using this vulnerability scanning tool:</p>
<p><code>alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET WEB_SPECIFIC_APPS Bishop Fox Fortigate CVE-2024-21762 Vulnerability Scanner Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/remote/VULNCHECK"; fast_pattern; http.header; content:"Transfer-Encoding|3a 20|chunked"; http.request_body; content:0000000000000000FF|0d 0a 0d 0a|"; reference:url,github.com/BishopFox/cve-2024-21762-check; classtype:trojan-activity; sid:1; rev:1;)</code></p>
<p>I tested this rule again using Dalton, and the rule didn't fire. In an effort to troubleshoot it, I used dalton's ability to dump the HTTP buffers and noticed that the http client request buffer just contains |0d 0a|. That the chunk size isn't included in the buffer. I've attached a screenshot to better illustrate what I'm experiencing.</p>
<p>However, with a slight edit to the original rule, looking for the chunk size value WITHOUT the http.request_body buffer:</p>
<p><code>alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET WEB_SPECIFIC_APPS Bishop Fox Fortigate CVE-2024-21762 Vulnerability Scanner Attempt"; flow:established,to_server; content:|0d 0a 0d 0a|0000000000000000FF|0d 0a 0d 0a|"; http.method; content:"POST"; http.uri; content:"/remote/VULNCHECK"; fast_pattern; http.header; content:"Transfer-Encoding|3a 20|chunked"; reference:url,github.com/BishopFox/cve-2024-21762-check; classtype:trojan-activity; sid:1; rev:1;)</code></p>
<p>...triggers alerts just fine.</p>
<p>For the sake of testing, I ran dalton with the full series of http-events.rules, plus the following set of rules:</p>
<pre>
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET WEB_SPECIFIC_APPS Bishop Fox Fortigate CVE-2024-21762 Vulnerability Scanner Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/remote/VULNCHECK"; fast_pattern; http.header; content:"Transfer-Encoding|3a 20|chunked"; http.request_body; content:"0000000000000000FF"; reference:url,github.com/BishopFox/cve-2024-21762-check; classtype:trojan-activity; sid:1; rev:1;)
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET WEB_SPECIFIC_APPS Bishop Fox Fortigate CVE-2024-21762 Vulnerability Scanner Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/remote/VULNCHECK"; fast_pattern; http.header; content:"Transfer-Encoding|3a 20|chunked"; http.request_body; content:"0000000000000000FF|0d 0a|"; reference:url,github.com/BishopFox/cve-2024-21762-check; classtype:trojan-activity; sid:2; rev:1;)
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET WEB_SPECIFIC_APPS Bishop Fox Fortigate CVE-2024-21762 Vulnerability Scanner Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/remote/VULNCHECK"; fast_pattern; http.header; content:"Transfer-Encoding|3a 20|chunked"; http.request_body; content:"0000000000000000FF|0d 0a 0d 0a|"; reference:url,github.com/BishopFox/cve-2024-21762-check; classtype:trojan-activity; sid:3; rev:1;)
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET WEB_SPECIFIC_APPS Bishop Fox Fortigate CVE-2024-21762 Vulnerability Scanner Attempt"; flow:established,to_server; content:"|0d 0a 0d 0a|0000000000000000FF|0d 0a 0d 0a|"; http.method; content:"POST"; http.uri; content:"/remote/VULNCHECK"; fast_pattern; http.header; content:"Transfer-Encoding|3a 20|chunked"; reference:url,github.com/BishopFox/cve-2024-21762-check; classtype:trojan-activity; sid:4; rev:1;)
</pre>
<p>The only rule that would fire (aside from an http-events.rule for an invalid host header) was sid number 4. I've tested this on the latest suri 8, 7, and 6 builds, and have attached the dalton job zip files (includes pcap, rules, and suricata.yaml) to this ticket.</p>
<p>Here is what I want to know: Is this expected behavior? Should I assume that the http.request_body buffer is normalizing out the chunk length value in the request body? The reason I enabled the http-events.rules was to see if there were any triggers for anomalous http chunk/chunk length values in the packet capture I generated, but nothing related to http chunk anomalies triggered.</p>
<p>So, is suricata normalizing out the chunk length and not logging any details relating to that? If this is expected behavior, at a minimum I would like to see this documented in all currently supported releases of Suricata -- more specifically, the documentation relating to http.request_body and http.response_body should have notes about this somewhere.</p>
<p>In an ideal world, I'd like to be able to alert on this unusual traffic without resorting to the work-around of creating an unbuffered content match, because according to our conversations, unbuffered content matches are very inefficient. I don't know if that means re-evaluating how Suricata analyzes chunk data, and/or chunk length values, or adding in a new keyword in a future release to be able to analyze raw, chunked data in the http.request_body http.response_body and/or file.data buffer (maybe a modifier like dotprefix --- e.g. --- <code>http.request_body; raw_chunks; content:"0000000000000000FF|0d 0a 0d 0a|";</code></p>
<p>Thank again for all you do to make Suricata better with every release. Please let me know if there are additional details I can provide.</p> Suricata - Bug #6871 (In Review): dpdk: fix compatibility issues for ice cardshttps://redmine.openinfosecfoundation.org/issues/68712024-03-19T12:58:32ZLukas Sismis
<p>Currently:<br />DPDK v23.11.0 doesn't startup on ice cards (tested on E810) - complains about invalid RSS hash key length settings - the length was changed to 52 bytes from 40 (similar as is in i40e).</p>
<p>DPDK v22.11.2 <br />closing the device ends with a segfault</p>
<p>DPDK v21.11.6<br />works fine</p>
<p>DPDK v20.11.10<br />works fine</p>
<p>DPDK v19.11.14<br />works fine</p> Suricata - Task #6573 (New): rust: set new minimum Rust version for Suricata 8https://redmine.openinfosecfoundation.org/issues/65732023-11-23T21:43:03ZJason Ishjason.ish@oisf.net
<table>
<tr>
<th>OS/Distribution </th>
<th>Version </th>
<th>Rust Version </th>
<th>Supported </th>
<th>Notes</th>
</tr>
<tr>
<td> AlmaLinux </td>
<td> 8 </td>
<td> 1.71.1 </td>
<td> Yes </td>
<td></td>
</tr>
<tr>
<td> AlmaLinux </td>
<td> 9 </td>
<td> 1.71.1 </td>
<td> Yes </td>
<td></td>
</tr>
<tr>
<td> CentOS </td>
<td> 7 </td>
<td> 1.72.1 </td>
<td> Yes </td>
<td> Requires EPEL (<code>yum install epel-release</code>) </td>
</tr>
<tr>
<td> <del>CentOS</del> </td>
<td> <del>8</del> </td>
<td> <del>1.52.1</del> </td>
<td> No </td>
<td> EOL </td>
</tr>
<tr>
<td> CentOS Stream </td>
<td> 8 </td>
<td> 1.75.0 </td>
<td> Yes </td>
<td></td>
</tr>
<tr>
<td> CentOS Stream </td>
<td> 9 </td>
<td> 1.75.0 </td>
<td> Yes </td>
<td></td>
</tr>
<tr>
<td> <del>Debian</del> </td>
<td> <del>9</del> </td>
<td> <del>1.41.1</del> </td>
<td> No </td>
<td> EOL </td>
</tr>
<tr>
<td> Debian </td>
<td> 10 </td>
<td> 1.41.1 </td>
<td> No </td>
<td> Must use rustup. Note: Debian's package needs checking, see <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: rust: undefined symbol: llvm.x86.subborrow.64 (Closed)" href="https://redmine.openinfosecfoundation.org/issues/4204">#4204</a>. In Debian LTS state until 2024. </td>
</tr>
<tr>
<td> Debian </td>
<td> 11 </td>
<td> 1.48.0 </td>
<td> No </td>
<td> Must use rustup.</td>
</tr>
<tr>
<td> Debian </td>
<td> 12 </td>
<td> 1.63.0 </td>
<td> Yes </td>
<td></td>
</tr>
<tr>
<td> Fedora </td>
<td> 38+ </td>
<td> 1.74.0 </td>
<td> Yes </td>
<td></td>
</tr>
<tr>
<td> <del>Ubuntu</del> </td>
<td> <del>18.04</del> </td>
<td> 1.65.0 </td>
<td> No </td>
<td> EOL April 2023</td>
</tr>
<tr>
<td> Ubuntu </td>
<td> 20.04 </td>
<td> 1.74.1 </td>
<td> Yes </td>
<td></td>
</tr>
<tr>
<td> Ubuntu </td>
<td> 22.04 </td>
<td> 1.75.0 </td>
<td> Yes </td>
<td></td>
</tr>
<tr>
<td> Ubuntu </td>
<td> 24.04 </td>
<td> 1.75.0 </td>
<td> Yes </td>
<td></td>
</tr>
<tr>
<td> <del>FreeBSD</del> </td>
<td> <del>12.3</del> </td>
<td> <del>1.61.1</del> </td>
<td> Yes </td>
<td> EOL March 2023 </td>
</tr>
<tr>
<td> <del>FreeBSD</del> </td>
<td> <del>12.4</del> </td>
<td> <del>1.68.2</del> </td>
<td> Yes </td>
<td> pkg install rust cargo </td>
</tr>
<tr>
<td> FreeBSD </td>
<td> 13.2 </td>
<td> 1.74.1 </td>
<td> Yes </td>
<td> pkg install rustc cargo </td>
</tr>
<tr>
<td> FreeBSD </td>
<td> 14.0 </td>
<td> 1.74.1 </td>
<td> Yes </td>
<td> pkg install rustc cargo </td>
</tr>
<tr>
<td> <del>OpenBSD</del> </td>
<td> <del>7.0</del> </td>
<td> <del>1.55.0</del> </td>
<td> No </td>
<td> EOL </td>
</tr>
<tr>
<td> <del>OpenBSD</del> </td>
<td> <del>7.1</del> </td>
<td> <del>1.59.0</del> </td>
<td> No </td>
<td> EOL May 2023 </td>
</tr>
<tr>
<td> <del>OpenBSD</del> </td>
<td> <del>7.2</del> </td>
<td> <del>1.63.0</del> </td>
<td> Yes </td>
<td></td>
</tr>
<tr>
<td> OpenBSD </td>
<td> 7.3 </td>
<td> 1.68.0 </td>
<td> Yes </td>
<td></td>
</tr>
<tr>
<td> OpenBSD </td>
<td> 7.4 </td>
<td> 1.72.1 </td>
<td> Yes </td>
<td></td>
</tr>
<tr>
<td> MinGW </td>
<td> ?? </td>
<td> 1.76.0 </td>
<td> ?? </td>
<td> Can be installed through pacman </td>
</tr>
</table> Suricata - Feature #5773 (In Review): Support DNS over HTTPS (DoH)https://redmine.openinfosecfoundation.org/issues/57732023-01-03T16:08:51ZBrandon Murphy
<p>Feature request is for Suricata, when presented with, likely decrypted, pcap/traffic that includes DoH traffic, it'd be parsed and included with DNS logs.</p>
<p><a class="external" href="https://datatracker.ietf.org/doc/rfc8484/">https://datatracker.ietf.org/doc/rfc8484/</a></p>
<p>Example pcap included.</p>
A couple of quick notes I found when looking through the RFC:
<ol>
<li>"HTTP/2 [RFC7540] is the minimum RECOMMENDED version of HTTP for use with DoH." <br />I suppose this doesn't mean it can't use HTTP/1.1, just that it's not RECOMMENDED. </li>
<li>"DoH client encodes a single DNS query into an HTTP request using either the HTTP GET or POST method..." </li>
<li>"Reuses the format of DNS once base64 decoded</li>
</ol>
<p>Ideally all normal "dns" support would work with data that occurs via DoH, datasets, dns keywords, logging, etc.</p> Suricata - Documentation #5485 (New): userguide: explain that the http.header_names buffer is nor...https://redmine.openinfosecfoundation.org/issues/54852022-08-05T15:04:05ZJuliana Fajardini Reichow
<p>libhtp normalizes the http.header_names buffer, as it resides in a structure that does not allow duplicates.</p>
<p>As someone inspecting Wireshark packet traffic may be expecting something different when writing a rule, make this behavior clear on our documentation.</p> Suricata - Feature #5234 (In Progress): SSL/TLS Sticky Buffer for subjectAltNamehttps://redmine.openinfosecfoundation.org/issues/52342022-04-06T23:35:42ZGenina Po
<p>Hi Team,</p>
<p>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.</p>
<p>The attached .pcap may be used to test this feature request.</p>
<p>Please note there is an observed inconsistency with how the subjectAltName is being parsed amongst Suricata engine versions.</p>
<p>If Suricata 6+ is used on the attached .pcap, the subjectAltName is parsed:<br /> Suri7<br /><pre>
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
</pre></p>
<p>If Suricata 5 and below are used, the subjectAltName is not parsed:<br />Suri5 <br /><pre>
'issuerdn': 'C=XX, CN=mamzon.ru/L=XX/O=XX/OU=XX/ST=XX/emailAddress=webmaster@mamzon.ru/unknown=*.mamzon.ru www.mamzon.ru',
</pre></p> Suricata - Optimization #5207 (Assigned): Common Rust parser for *bitshttps://redmine.openinfosecfoundation.org/issues/52072022-03-25T11:59:31ZShivani Bhardwaj
<p>All the *bits are parsed in almost exactly the same manner. which results in same errors as well. Make it more Robust by moving it to Rust.</p> Suricata - Documentation #5182 (New): userguide: better document rule keywordshttps://redmine.openinfosecfoundation.org/issues/51822022-03-07T18:16:54ZJuliana Fajardini Reichow
<p>This could probably become more than just one ticket.<br />The motivation behind it is that there are many rule keywords<br />that are mentioned but lack proper explanation on what they are/<br />how they related to what is seen on the wire.<br />Example: dzise (<a class="external" href="https://suricata.readthedocs.io/en/latest/rules/payload-keywords.html#dsize">https://suricata.readthedocs.io/en/latest/rules/payload-keywords.html#dsize</a>)</p>
<p>Improving that would be great.</p> Suricata - Bug #5031 (Assigned): flowbits - no error on invalid optionshttps://redmine.openinfosecfoundation.org/issues/50312022-02-01T14:50:58ZBrandon Murphy
<p>as per <a class="external" href="https://redmine.openinfosecfoundation.org/issues/4786#note-8">https://redmine.openinfosecfoundation.org/issues/4786#note-8</a> - creating a new issue</p>
<p>sid 7, despite not having a valid option provided, does not produce an error/warning from suricata.<br /><pre>
alert http any any -> any any (msg:"flowbits with noalert option"; flow:established,to_server; http.method; content:"POST"; flowbits:set,ET.whatever,asdfasdf; sid:7;)
</pre></p> Suricata - Feature #4904 (Assigned): dcerpc: add stream app-layer records supporthttps://redmine.openinfosecfoundation.org/issues/49042021-12-14T15:21:47ZShivani BhardwajSuricata - Bug #4786 (Assigned): xbits: no error on invalid 'expire' valueshttps://redmine.openinfosecfoundation.org/issues/47862021-10-27T22:04:06ZBrandon Murphy
<pre>
alert http any any -> any any (msg:"TEST - No Error")"; flow:established,to_server; http.method; content:"GET"; xbits:set,ET.2020_8260.1,track ip_src,expire 10,noalert; sid:1;)
alert http any any -> any any (msg:"TEST - Error")"; flow:established,to_server; http.method; content:"GET"; xbits:set,ET.2020_8260.1,noalert,track ip_src,expire 10; sid:2;)
alert http any any -> any any (msg:"TEST - No Error")"; flow:established,to_server; http.method; content:"GET"; xbits:set,ET.2020_8260.1,track ip_src,expire 10,asdf; sid:3;)
</pre>
<p>only sid 2 produces an error, despite that all 3 sids should be considered "invalid"</p>
<p>Error Produced by sid:2<br /><pre>
[1539] 27/10/2021 -- 21:58:51 - (detect-xbits.c:208) <Error> (DetectXbitParse) -- [ERRCODE: SC_ERR_PCRE_MATCH(2)] - "set,ET.2020_8260.1,noalert,track ip_src,expire 10" is not a valid setting for xbits.
</pre></p>
<p>I'd also add that the documentation is a bit vague on the proper use of the noalert keyword in relation to xbits. It currently reads <br /><pre>
To not alert, use noalert;
</pre></p>
<p>I suggest adding a bit of context which indicates it should be a standalone keyword in the rule and not an "option" to the xbits keyword.</p> Suricata - Optimization #2725 (Feedback): stream/packet on wrong threadhttps://redmine.openinfosecfoundation.org/issues/27252018-12-04T23:04:51ZPeter Manevpetermanev@gmail.com
<p>Looking for feedback.</p>
<p>While investigating various research points with af-packet on live traffic and latest gitmaster (ex eedf08be/4.1) I noticed that I have never seen those to be 0 in any occasion<br /><pre>
stream.wrong_thread | Total | 2982446
tcp.pkt_on_wrong_thread | Total | 156187846
</pre></p>
<p>Those statistics can be made available via - ( <a class="external" href="https://github.com/OISF/suricata/blob/master/suricata.yaml.in#L66">https://github.com/OISF/suricata/blob/master/suricata.yaml.in#L66</a> ) <br /><pre>
# global stats configuration
stats:
enabled: yes
# The interval field (in seconds) controls at what interval
# the loggers are invoked.
interval: 8
# Add decode events as stats.
decoder-events: true
# Add stream events as stats.
stream-events: true
</pre></p>
<p>I have tried different NICs/drivers(tested ixgbe/i40e), af-packet v3/v2, cluster_flow/cluster_cpu/cluster_qm, vlan tracking enabled or not, on different live traffic machines, different kernels (4.18/4.19) - <br />capture.kernel_drops and stream.wrong_thread are never 0 and always increasing.(it is more like 10-15% of the total in my test cases)</p>
<p>Looking for any feedback in terms of - if you are experiencing the same issue or not and what is your setup (if you would like to share).</p>