[Bro] Mime-type issues (text/plain and application/x-msdownload)
siberkartal at gmail.com
Wed Jan 4 03:56:11 PST 2017
I tried it in script land.
This is the related part.
event http_header(c: connection, is_orig: bool, name: string, value:
if ( !is_orig )
if ( to_lower(name) == "content-type" && value ==
#c$http$resp_mime_types = "application/x-msdownload";
_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?
On Wed, Jan 4, 2017 at 12:32 PM, Beyaz Şapka <siberkartal at gmail.com> wrote:
> 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.
> 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
> 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
> On Wed, Jan 4, 2017 at 6:23 AM, Seth Hall <seth at icir.org> wrote:
>> > On Dec 28, 2016, at 9:11 AM, Beyaz Şapka <siberkartal at gmail.com> wrote:
>> > 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
>> > The correct one is text/html, it is clear.
>> Are you referring to the first request in the "10.12.13.102 49192
>> 184.108.40.206 80" connection? It's showing as text/html for me in Bro
>> > 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 Hall
>> International Computer Science Institute
>> (Bro) because everyone has a network
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bro