Hi all,
I have two questions for the following pcap.
Bro says the mime-type as “text/plain” for the response of first HTTP GET request.
However, at least, wireshark (and also CapTipper) says it is “text/html”.
The correct one is text/html, it is clear.
I think, bro does not look only Content-Type (maybe due to malicious manipulation), but makes some heuristics. But there should be some issues for this case.
The other one is that, there are 3 binary files in this pcap.
Bro extracts them pretty fine.
However again there are some issues about content-type.
While their content type is application/x-msdownload, the http.log and files.log says dash dash (not found).
In relation to this issue, I have a local file extract bro script, although I have definition for application/x-msdownload extension, I am not able to set its extension as exe. Since meta$mime_type returns empty.
The sample:
[http://www.malware-traffic-analysis.net/2016/12/13/2016-12-13-pseudoDarkleech-Rig-V-sends-Cerber-ransomware.pcap.zip](http://www.malware-traffic-analysis.net/2016/12/13/2016-12-13-pseudoDarkleech-Rig-V-sends-Cerber-ransomware.pcap.zip)
Thanks,
Bro says the mime-type as "text/plain" for the response of first HTTP GET request.
However, at least, wireshark (and also CapTipper) says it is "text/html".
The correct one is text/html, it is clear.
Are you referring to the first request in the "10.12.13.102 49192 195.133.48.182 80" connection? It's showing as text/html for me in Bro 2.5.
I think, bro does not look only Content-Type (maybe due to malicious manipulation), but makes some heuristics. But there should be some issues for this case.
We have a fairly large set of signatures that identify file types. In HTTP traffic, the Content-Type header doesn't factor in at all.
The other one is that, there are 3 binary files in this pcap.
Bro extracts them pretty fine.
However again there are some issues about content-type.
While their content type is application/x-msdownload, the http.log and files.log says dash dash (not found).
Due to the fact that we detect mime type with signatures and I don't seem to be able to find any information about what application/x-msdownload is, I don't think we'll be able to make that detection. The files that are transferred are unrecognizable binary data too (at least I was unable to see anything recognizable there).
.Seth
Yes, I talk about the response for the first HTTP request.
signature file-html is good but still could be better.
The signature only check for the starting of the file for particular patterns, the problem originates from that.
From where, you are not able to find any information about what application/x-msdownload is?
If you are talking about *.sig files in bro directories, of course it does not exist.
However google says much: https://msdn.microsoft.com/en-us/library/ms775147(v=vs.85).aspx
application/x-msdownload is Executable (.exe or .dll) file.
It is similar to signature file-magic-auto433.
In addition, sure, they are unrecognized binary data, since they are encrypted.
I think, file-magic-auto433 flags plain ones correctly, but gives its mime type as application/x-dosexec
I will duplicate it and add an additional check (http-reply-header /Content-type: application/x-msdownload/) for a workaround.
Hi Seth,
I tried it in script land.
https://pastebin.mozilla.org/8958431
This is the related part.
…
event http_header(c: connection, is_orig: bool, name: string, value: string) &priority=3
{
if ( !is_orig )
{
if ( to_lower(name) == “content-type” && value == “application/x-msdownload” )
{
#c$http$resp_mime_types[0] = “application/x-msdownload”;
print(c$uid);
_mime_type = “application/x-msdownload”;
}
}
}
…
It does not set mime_type in the output correctly, order is erroneous.
It sets mime_type of a different response, so it also breaks it.
Could you please test it with the pcap file in the first post?
Thanks,
Yes, I talk about the response for the first HTTP request.
signature file-html is good but still could be better.
The signature only check for the starting of the file for particular patterns, the problem originates from that.
We accept patches if you have improvements to be made on our file type detection.
From where, you are not able to find any information about what application/x-msdownload is?
If you are talking about *.sig files in bro directories, of course it does not exist.
However google says much: MIME Type Detection in Windows Internet Explorer (Windows) | Microsoft Learn
That link doesn't actually describe what the purpose of that mime type is or what exactly the file format should look like. It's just more of the same stuff that I already found that makes references to the mime type and places some relation to windows executables but we already identify windows executables as application/x-dosexec as you discovered.
In addition, sure, they are unrecognized binary data, since they are encrypted.
I think, file-magic-auto433 flags plain ones correctly, but gives its mime type as application/x-dosexec
I will duplicate it and add an additional check (http-reply-header /Content-type: application/x-msdownload/) for a workaround.
Our file type detection is is meant to detect file types by inspecting the file content. What you want to do is just something different from the way Bro works and you are already doing the right thing by writing your own script to do something extra with that header.
.Seth