[Bro] Mime-type issues (text/plain and application/x-msdownload)

Beyaz Şapka siberkartal at gmail.com
Wed Jan 4 03:56:11 PST 2017


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,


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.
> 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.
>
> 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
>> "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
>>
>>
>> --
>> Seth Hall
>> International Computer Science Institute
>> (Bro) because everyone has a network
>> http://www.bro.org/
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20170104/90b55131/attachment.html 


More information about the Bro mailing list