https://redmine.openinfosecfoundation.org/https://redmine.openinfosecfoundation.org/favicon.ico?17011170022015-08-27T12:53:45ZOpen Information Security FoundationSuricata - Bug #1526: Malformed encoded base64 packet in json logshttps://redmine.openinfosecfoundation.org/issues/1526?journal_id=54662015-08-27T12:53:45ZBakul Khannabakul.khanna@viasat.com
<ul></ul><p>I see a very similar issue with Suricata 2.1 Beta 4.</p>
<p>While running Modbus traffic via a pcap file, with EVE logging on, sometimes I see a corrupted base64 encoded "packet" field. At other times the base64 encoded "packet" field is perfectly fine.</p>
<p>------------------------------------------------------------------------------------<br />Following is an example of a EVE log with a corrupted base64 encoded "packet" field:</p>
<pre>
2015-08-26T10:58:16.364-07:00 Suricata[16810]: {"timestamp":"2015-08-26T10:58:16.359538-0700","flow_id":28633488,"event_type":"alert","src_ip":"192.168.1.1","src_port":47762,"dest_ip":"192.168.1.2","dest_port":502,"proto":"TCP","alert":{"action":"allowed","gid":1,"signature_id":2250003,"rev":1,"signature":"SURICATA Modbus invalid Length","category":"","severity":3,"tx_id":0},
"payload":"0MrzAgAAAAAAEAAABwQAAAFvAAAEAf8HAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=","payload_printable":".................o.....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................","stream":1,"packet":"AODtEcfoACOuLYlXCABFAAAoCudFAAAobJXAqAEGwKjAqAEBwKgBArqSAfb4WTHgBQrFLQAAAAAAAAAA"}
"payload_printable":".................o.....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................",
"stream":1,"packet":"AODtEcfoACOuLYlXCABFAAAoCudFAAAobJXAqAEGwKjAqAEBwKgBArqSAfb4WTHgBQrFLQAAAAAAAAAA"}
</pre>
<p>I decoded the "packet" as follows (Note how the ip addresses decoded are different from what is mentioned in the log above):<br />•Frame 1 (60 bytes on wire, 60 bytes captured)<br />•Ethernet II, Src: Dell_2d:89:57 (00:23:ae:2d:89:57), Dst: Silicom_11:c7:e8 (00:e0:ed:11:c7:e8)<br />•Internet Protocol, Src: 192.168.1.6 (192.168.1.6), Dst: 192.168.192.168 (192.168.192.168)<br />•Data (20 bytes)<br />•0000 01 01 c0 a8 01 02 ba 92 01 f6 f8 59 31 e0 05 0a ...........Y1...<br />•0010 c5 2d 00 00 .-..</p>
<p>------------------------------------------------------------------------------------<br />Following is an example of a EVE log with a perfectly fine base64 encoded "packet" field:</p>
<pre>
2015-08-26T10:58:16.365-07:00 Suricata[16810]: {"timestamp":"2015-08-26T10:58:16.359538-0700","flow_id":28633488,"in_iface":"eth0","event_type":"alert","src_ip":"192.168.1.2","src_port":502,"dest_ip":"192.168.1.1","dest_port":47762,"proto":"TCP","alert":{"action":"allowed","gid":1,"signature_id":2250003,"rev":1,"signature":"SURICATA Modbus invalid Length","category":"","severity":3,"tx_id":0},
"payload":"",
"stream":1,"packet":"AODtEcfoACOuLYlXCABFAAAoCudAAIAGbJXAqAECwKgBAQH2upIFCsUt+Fkx4FAUAAB7ggAAAAAAAAAA"}
I decoded the "packet" as follows (Note how the ip addresses decoded are identical to what is mentioned in the log above):
•Frame 1 (60 bytes on wire, 60 bytes captured)
•Ethernet II, Src: Dell_2d:89:57 (00:23:ae:2d:89:57), Dst: Silicom_11:c7:e8 (00:e0:ed:11:c7:e8)
•Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.1 (192.168.1.1)
•Transmission Control Protocol, Src Port: asa-appl-proto (502), Dst Port: 47762 (47762), Seq: 84591917, Ack: 4166595040, Len: 0
</pre>
<hr /> Suricata - Bug #1526: Malformed encoded base64 packet in json logshttps://redmine.openinfosecfoundation.org/issues/1526?journal_id=54942015-09-16T08:29:31ZJay MJjskier@gmail.com
<ul><li><strong>File</strong> <a href="/attachments/1115">Sample mangled base64 decoded.pcap</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1115/Sample%20mangled%20base64%20decoded.pcap">Sample mangled base64 decoded.pcap</a> added</li></ul><p>Provided more log (json alert, alert debug, scapy output) information here: <a class="external" href="http://pastebin.com/H2pwTUXj">http://pastebin.com/H2pwTUXj</a></p>
<p>Also attached sample base64 decoded pcap.</p>
<p>It looks like the encoding isn't properly done or something about it changed in suricata somewhere. I've tried a few versions of scapy to decode the packet field, and get the same results.</p>
<p>For me, it's always malformed, there haven't been any proper packet fields since testing erspan.</p> Suricata - Bug #1526: Malformed encoded base64 packet in json logshttps://redmine.openinfosecfoundation.org/issues/1526?journal_id=55852015-10-15T09:22:56ZJay MJjskier@gmail.com
<ul></ul><p>It appears md5sum hashes are also incorrect.</p> Suricata - Bug #1526: Malformed encoded base64 packet in json logshttps://redmine.openinfosecfoundation.org/issues/1526?journal_id=55872015-10-16T08:18:38ZJay MJjskier@gmail.com
<ul></ul><p>Confirmed that the issues below are only related to erspan traffic. Tested with regular rspan and the issues do not occur.</p>
<strong>Issues</strong>
<ul>
<li>Incorrect MD5sum (file magic appears to be correct)</li>
<li>Malformed packet field in eve log</li>
</ul>
<p><strong>OS information</strong><br />Linux stplidsn02 4.2.3-1-ARCH <a class="issue tracker-1 status-5 priority-4 priority-default closed behind-schedule" title="Bug: within doesn't respect distance while carrying out a match (Closed)" href="https://redmine.openinfosecfoundation.org/issues/1">#1</a> SMP PREEMPT Sat Oct 3 18:52:50 CEST 2015 x86_64 GNU/Linux<br />Suricata git ~ This is Suricata version 2.1dev (rev dcbbda5)</p>
<p>If developers need any further information or testing, please let me know.</p> Suricata - Bug #1526: Malformed encoded base64 packet in json logshttps://redmine.openinfosecfoundation.org/issues/1526?journal_id=55882015-10-16T08:21:31ZVictor Julienvictor@inliniac.net
<ul></ul><p>Can you reproduce the issues with a pcap recording of your erspan traffic as well?</p> Suricata - Bug #1526: Malformed encoded base64 packet in json logshttps://redmine.openinfosecfoundation.org/issues/1526?journal_id=55912015-10-16T12:05:42ZJay MJjskier@gmail.com
<ul></ul><p>Jay MJ wrote:</p>
<blockquote>
<p>Confirmed that the issues below are only related to erspan traffic. Tested with regular rspan and the issues do not occur.</p>
<strong>Issues</strong>
<ul>
<li>Incorrect MD5sum (file magic appears to be correct)</li>
<li>Malformed packet field in eve log</li>
</ul>
<p><strong>OS information</strong><br />Linux stplidsn02 4.2.3-1-ARCH <a class="issue tracker-1 status-5 priority-4 priority-default closed behind-schedule" title="Bug: within doesn't respect distance while carrying out a match (Closed)" href="https://redmine.openinfosecfoundation.org/issues/1">#1</a> SMP PREEMPT Sat Oct 3 18:52:50 CEST 2015 x86_64 GNU/Linux<br />Suricata git ~ This is Suricata version 2.1dev (rev dcbbda5)</p>
<p>If developers need any further information or testing, please let me know.</p>
</blockquote>
<p>Apologies, please disregard the hashing issue, that is a separate issue, and appears to be present across spans. I had made some configuration changes that probably borked that.</p> Suricata - Bug #1526: Malformed encoded base64 packet in json logshttps://redmine.openinfosecfoundation.org/issues/1526?journal_id=55922015-10-16T12:06:41ZJay MJjskier@gmail.com
<ul></ul><p>Victor Julien wrote:</p>
<blockquote>
<p>Can you reproduce the issues with a pcap recording of your erspan traffic as well?</p>
</blockquote>
<p>The pcaps suricata saves and tcpdump as well are the same, and OK. It appears to be how suricata parses the pcap.</p> Suricata - Bug #1526: Malformed encoded base64 packet in json logshttps://redmine.openinfosecfoundation.org/issues/1526?journal_id=56022015-10-19T11:50:52ZVictor Julienvictor@inliniac.net
<ul></ul><p>What capture method are you using? If you're not using regular libpcap (-i on commandline) can you try that? Wondering if possibly there is something about our afpacket/pfring support that is related to this.</p> Suricata - Bug #1526: Malformed encoded base64 packet in json logshttps://redmine.openinfosecfoundation.org/issues/1526?journal_id=56032015-10-19T14:54:48ZJay MJjskier@gmail.com
<ul></ul><p>Victor Julien wrote:</p>
<blockquote>
<p>What capture method are you using? If you're not using regular libpcap (-i on commandline) can you try that? Wondering if possibly there is something about our afpacket/pfring support that is related to this.</p>
</blockquote>
<p>I was using af-packet, tried doing libpcap, same results happen.</p>
<p>I think it has to do with the erspan component of suricata. Plain rspan itself works fine, but once I revert to erspan, the packet alert field becomes malformed. What I think is happening is the packet alert field parsing is not addressing the proceeding 50 byte erspan header. Then, subsequently generated pcap gets improperly offset and encoded into the alert packet field of suricata.</p> Suricata - Bug #1526: Malformed encoded base64 packet in json logshttps://redmine.openinfosecfoundation.org/issues/1526?journal_id=56152015-10-26T15:00:52ZJay MJjskier@gmail.com
<ul></ul><p>Victor Julien wrote:</p>
<blockquote>
<p>What capture method are you using? If you're not using regular libpcap (-i on commandline) can you try that? Wondering if possibly there is something about our afpacket/pfring support that is related to this.</p>
</blockquote>
<p>Also tried pfring, the results are the same.</p> Suricata - Bug #1526: Malformed encoded base64 packet in json logshttps://redmine.openinfosecfoundation.org/issues/1526?journal_id=62932016-02-12T10:05:40ZJay MJjskier@gmail.com
<ul></ul><p>Looking at this some more, appears perhaps the GRE header itself could be a factor when packet field gets encoded for eve log? I'll do some more testing in time.</p> Suricata - Bug #1526: Malformed encoded base64 packet in json logshttps://redmine.openinfosecfoundation.org/issues/1526?journal_id=63762016-02-17T15:11:23ZJay MJjskier@gmail.com
<ul></ul><p>It looks like a couple of things are happening comparing to rspan and erspan and pf_ring on both. The alert packet field is encoding in base64 but I believe it does so by looking at the original encoded GRE/ERSPAN packet, so everything is malformed.</p>
<p>I also noticed that the bpf filter often doesn't work with this encoded traffic most of the time. In fact suricata won't pick up any traffic (unless bpf is something simple like tcp protocol). If you would like another ticket for this let me know.</p>
So, at this point I would recommend:
<ul>
<li>Mapping the packet field to properly decoded GRE/ESPAN packet rather than raw</li>
<li>Apply bpf filters to properly decoded GRE/ERSPAN packet; not sure what it's using - perhaps also raw encoded original?</li>
</ul>
<p>Not sure if there is much demand for erspan support, seems like I'm the only one using it. I also looked into rcdcap to handle decoding pre suricata with a tunnel interface, however the software is older, and I have a pending issue with the developer of that project.</p> Suricata - Bug #1526: Malformed encoded base64 packet in json logshttps://redmine.openinfosecfoundation.org/issues/1526?journal_id=73222016-09-08T14:38:15ZAndreas Herzoisf@herzandreas.de
<ul><li><strong>Assignee</strong> set to <i>Anonymous</i></li><li><strong>Target version</strong> set to <i>TBD</i></li></ul> Suricata - Bug #1526: Malformed encoded base64 packet in json logshttps://redmine.openinfosecfoundation.org/issues/1526?journal_id=75112016-10-06T15:47:38ZJay MJjskier@gmail.com
<ul></ul><p>Not sure if someone started working on this (I see some activity in git), but it appears that the md5sum is working now and correct (but sha1/256 are still incorrect). I am testing 3.2beta1, one erspan comes in stripped of erspan header and then passed to suricata, other erspan is fed straight to suricata. Strangely both md5 hashes match and are correct, however sha1 and sha256 have both different values and are not the correct hash of the file. This may be another bug, as my test shows even without erspan header the sha1/256 hashes are incorrect.</p>
<p>Also, the alert packet field decoded at initial look appears to be correct now, although I would like to do more research for a couple of days before calling that good.</p>
<p>If any additional testing needs to be done, don't hesitate to let me know.</p> Suricata - Bug #1526: Malformed encoded base64 packet in json logshttps://redmine.openinfosecfoundation.org/issues/1526?journal_id=79542017-02-15T10:55:29ZJay MJjskier@gmail.com
<ul></ul><p>The hash issue was fixed in 3.2.1, Bug <a class="issue tracker-1 status-5 priority-6 priority-high2 closed" title="Bug: Invalid file hash computation when force-hash is used (Closed)" href="https://redmine.openinfosecfoundation.org/issues/2004">#2004</a>.</p>
<p>Still seeing malformed packet fields though (only with erspan traffic).</p> Suricata - Bug #1526: Malformed encoded base64 packet in json logshttps://redmine.openinfosecfoundation.org/issues/1526?journal_id=85672017-08-04T11:38:36ZJay MJjskier@gmail.com
<ul></ul><p>Jay MJ wrote:</p>
<blockquote>
<p>The hash issue was fixed in 3.2.1, Bug <a class="issue tracker-1 status-5 priority-6 priority-high2 closed" title="Bug: Invalid file hash computation when force-hash is used (Closed)" href="https://redmine.openinfosecfoundation.org/issues/2004">#2004</a>.</p>
<p>Still seeing malformed packet fields though (only with erspan traffic).</p>
</blockquote>
<p>Still seeing the issue with malformed pcaps, packet / payload fields in eve logs with suricata 4. <br />Testing with rcdcap (virtual tap) which strips the erspan headers and everything works fine. Happy to do any testing / provide more info if needed.</p> Suricata - Bug #1526: Malformed encoded base64 packet in json logshttps://redmine.openinfosecfoundation.org/issues/1526?journal_id=112222019-02-23T22:17:03ZAndreas Herzoisf@herzandreas.de
<ul><li><strong>Assignee</strong> set to <i>Community Ticket</i></li></ul> Suricata - Bug #1526: Malformed encoded base64 packet in json logshttps://redmine.openinfosecfoundation.org/issues/1526?journal_id=131752019-07-29T17:28:26ZJay MJjskier@gmail.com
<ul></ul><p>Jay MJ wrote:</p>
<blockquote>
<p>The hash issue was fixed in 3.2.1, Bug <a class="issue tracker-1 status-5 priority-6 priority-high2 closed" title="Bug: Invalid file hash computation when force-hash is used (Closed)" href="https://redmine.openinfosecfoundation.org/issues/2004">#2004</a>.</p>
<p>Still seeing malformed packet fields though (only with erspan traffic).</p>
</blockquote>
<p>Updating the proper ticket this time!</p>
<p>I have noticed that the only issue remaining in v 4.1.4 is the packet field in the eve log, which doesn't seem to be valid. The encoded packet field does not work when imported into scapy, or decoded and converted to a pcap file. Everything else appears to work properly (encoded payload, printed payload, recorded pcaps) with or without the erspan header.</p> Suricata - Bug #1526: Malformed encoded base64 packet in json logshttps://redmine.openinfosecfoundation.org/issues/1526?journal_id=131922019-07-29T22:15:35ZAndreas Herzoisf@herzandreas.de
<ul><li><strong>Assignee</strong> changed from <i>Community Ticket</i> to <i>OISF Dev</i></li></ul><p>Thanks for the update, we need to check that last missing piece of the puzzle</p> Suricata - Bug #1526: Malformed encoded base64 packet in json logshttps://redmine.openinfosecfoundation.org/issues/1526?journal_id=227692022-03-16T17:37:01ZJason Ishjason.ish@oisf.net
<ul></ul><p>Are you able to provide an input pcap as well as a rule that shows this issue?</p>