Project

General

Profile

Actions

Bug #5223

open

base64_decode does not populate base64_data buffer once hitting non-base64 chars

Added by Brandon Murphy 6 months ago. Updated 2 months ago.

Status:
In Progress
Priority:
High
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

consider the following rules and the attached pcap.

The rules are designed to test the behavior of when non-base64 characters are encountered by the base64_decode.

Pay particular attention to sid:4 and sid:2 where the only difference is how far into the base64 encoded string are decoded.

if the base64_decode was populating the base64_data buffer with data upto the non-base64 char, we expect the first byte of the base64 decoded value (|9d|) to be populated into base64_data

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"base64 decode - no url_decode"; flow:established,to_server; http.cookie; content:"foobar="; base64_decode:relative; base64_data; content:"|9e|"; startswith; sid:1; rev:1;)
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"base64 decode - url_decode"; flow:established,to_server; http.cookie; url_decode; content:"foobar="; base64_decode:relative; base64_data; content:"|9e|"; sid:2; rev:1;)
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"base64 decode - no url_decode, proves no base64_data buffer via pcre"; flow:established,to_server; http.cookie; content:"foobar="; base64_decode:relative; base64_data; pcre:"/./"; sid:3; rev:1;)
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"base64 decode - no url_decode grab only the first two bytes"; flow:established,to_server; http.cookie; content:"foobar="; base64_decode:bytes 2,relative; base64_data; content:"|9e|"; startswith; sid:4; rev:1;)

Files

2bfb4e704fd597e.pcap (474 Bytes) 2bfb4e704fd597e.pcap Brandon Murphy, 06/15/2022 04:24 PM
Actions #1

Updated by Brandon Murphy 6 months ago

correction:

Pay particular attention to sid:4 and sid:2 where the only difference is how far into the base64 encoded string are decoded.

should be

Pay particular attention to sid:4 and sid:1 where the only difference is how far into the base64 encoded string are decoded.

in testing, the following alerts are produced

03/30/2022-14:59:10.243824  [**] [1:2:1] base64 decode - url_decode [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.104.20:12926 -> 172.16.72.94:80
03/30/2022-14:59:10.243824  [**] [1:4:1] base64 decode - no url_decode grab only the first two bytes [**] [Classification: (null)] [Priority: 3] {TCP} 192.168.104.20:12926 -> 172.16.72.94:80
Actions #2

Updated by Brandon Murphy 6 months ago

the following rule, when run on snort 2.9.18 (only tested version) works as expected. this is equivalent to sid:1; of the above suricata rules.

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"base64 decode"; flow:established,to_server; content:"foobar="; http_cookie; base64_decode:relative; base64_data; content:"|9e|"; depth:1; sid:1; rev:1;)

[**] [1:1:1] base64 decode [**]
[Priority: 0] 
03/30-14:59:10.246444 192.168.104.20:12926 -> 172.16.72.94:80
TCP TTL:64 TOS:0x0 ID:1 IpLen:20 DgmLen:125
***AP*** Seq: 0xB  Ack: 0x65  Win: 0x2000  TcpLen: 20F
Actions #3

Updated by Victor Julien 4 months ago

  • Status changed from New to Assigned
  • Assignee changed from OISF Dev to Shivani Bhardwaj
  • Priority changed from Normal to High
  • Target version changed from TBD to 7.0rc1

Shivani could you craft an SV test for this and have a look at the issue? AFAICS we could introduce a new Base64Mode like BASE64_MODE_RELAX_PASSTROUGH that would just copy any invalid byte into dest. We should be careful with the buffer sizes though, as the dest buffer might be smaller than expected due to there normally being a size ratio between encoded and decoded data.

Actions #4

Updated by Brandon Murphy 4 months ago

Updated pcap as Shivani pointed out the 97b97bef320a2ea.pcap was missing the hose host header and resulted in anomaly alerts.

Actions #5

Updated by Brandon Murphy 4 months ago

  • File deleted (97b97bef320a2ea.pcap)
Actions #6

Updated by Shivani Bhardwaj 3 months ago

  • Status changed from Assigned to In Progress
Actions #7

Updated by Shivani Bhardwaj 2 months ago

Victor Julien wrote in #note-3:

Shivani could you craft an SV test for this and have a look at the issue? AFAICS we could introduce a new Base64Mode like BASE64_MODE_RELAX_PASSTROUGH that would just copy any invalid byte into dest. We should be careful with the buffer sizes though, as the dest buffer might be smaller than expected due to there normally being a size ratio between encoded and decoded data.

I was looking at this with this approach and realized that dest buffer would indeed be a problem but wondered why should we try to add some data that is not decoded to the decoded buffer?
I referred to the RFC again and it is advisable for the decoding software to skip on any such invalid chars in a stream of b64 encoded data. So, I was wondering if it makes sense to make our decoder such that it always skips on anything that is not supposed to be there?
Even if I try to put the string in this pcap on any reliable decoder, the results are the same as they would be if there were no special characters..

But, I am clearly missing the point of BASE64_MODE_RELAX while proposing this (which I don't know btw)..

Actions

Also available in: Atom PDF