[Bro] Mime-type issues (text/plain and application/x-msdownload)
siberkartal at gmail.com
Wed Jan 4 01:32:49 PST 2017
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
If you are talking about *.sig files in bro directories, of course it does
However google says much:
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