[Oisf-users] again on filestore

[Marcos Rodriguez]

On Fri, Apr 13, 2012 at 9:15 AM, Peter Manev <petermanev at gmail.com> wrote:

> Hi Francesco,
> What are your file-data rules like for this particular case?
>
> thanks
>
> On Fri, Apr 13, 2012 at 1:18 PM, Travel Factory S.r.l. <mc8647 at mclink.it>wrote:
>
>>
>> It drove me crazy that several identical .exe downloaded from the web
>> had different MD5, also "not-human" downloads like the automatic
>> update checks of the software.
>>
>>
>> Please have a look at this:
>>
>> # cat file.1237.meta
>> TIME:              04/06/2012-11:53:29.220774
>> SRC IP:            <proxy - ip >
>> DST IP:            <client - ip >
>> PROTO:             6
>> SRC PORT:          8080
>> DST PORT:          1697
>> HTTP URI:
>>
>> http://cache.pack.google.com/edgedl/chrome/install/1025.151_1025.142/chrome_updater.exe
>> HTTP HOST:         cache.pack.google.com
>> HTTP REFERER:      <unknown>
>> FILENAME:
>>         /edgedl/chrome/install/1025.151_1025.142/chrome_updater.exe
>> MAGIC:             HTML document text
>> STATE:             CLOSED
>> SIZE:              333
>> root at a01:/var/log/suricata/201204131244/files# cat file.1238.meta
>> TIME:              04/06/2012-11:53:29.220774
>> SRC IP:            < proxy - ip >
>> DST IP:            < client - ip >
>> PROTO:             6
>> SRC PORT:          8080
>> DST PORT:          1697
>> HTTP URI:
>>
>> http://o-o.preferred.mil01s10.v16.lscache1.c.pack.google.com/edgedl/chrome/install/1025.151_1025.142/chrome_updater.exe?cms_redirect=yes
>> HTTP HOST:
>>        o-o.preferred.mil01s10.v16.lscache1.c.pack.google.com
>> HTTP REFERER:      <unknown>
>> FILENAME:
>>         /edgedl/chrome/install/1025.151_1025.142/chrome_updater.exe
>> MAGIC:             PE32 executable for MS Windows (GUI) Intel 80386
>> 32-bit
>> STATE:             CLOSED
>> SIZE:              26259
>>
>>
>>
>> So it seems a client asks for an update and gets a 333 bytes HTML
>> answer and then gets the same file from another server and receives
>> 26259 bytes of a PE32 executable.
>>
>> The 333 HTML file is actually a 302 http redirect.. why does it get
>> dumped ?
>>
>> The second file is actually a PE32 file but it is truncated. Of about
>> 15 logged downloads, only 3 dumps were complete.
>> Do you have similar results ?
>>
>> Francesco
>> _______________________________________________
>> Oisf-users mailing list
>> Oisf-users at openinfosecfoundation.org
>> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>
>
>
>
> --
> Regards,
> Peter Manev
>
>
> _______________________________________________
> Oisf-users mailing list
> Oisf-users at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>
>
Hi Everyone,

I wanted to piggyback on this topic and add some observations I've noticed
today:

While I haven't checked MD5 summing yet, I have noticed that with just one
rule specifying Windows PE's for extraction, I'm also getting JPEG, CSS,
and other files.

Here's a copy of my rule (blatant rip-off of Victor's example
here<https://redmine.openinfosecfoundation.org/projects/suricata/wiki/File_Extraction>
):

alert http any any -> any any (msg: "EXE Detected over HTTP";
filemagic:"executable for MS Windows"; fileext:"exe"; filestore; sid:
2000000; rev:1;)

Here are my yaml settings pertaining to file extraction:

- file-store:
      enabled: yes       # set to yes to enable
      log-dir: /data/suricata/files    # directory to store the files
      force-magic: no   # force logging magic on all stored files
      force-md5: yes     # force logging of md5 checksums

magic-file: /usr/share/file/magic

default-rule-path: /etc/suricata/rules
rule-files:
- file-extract.rules  (This is the only rule file enabled, and it contains
only the rule I listed above.)

Here is some output as an example:

# file file.[0-9][0-9][0-9]

file.206: JPEG image data, JFIF standard 1.01
file.207: JPEG image data, JFIF standard 1.01
file.208: GIF image data, version 89a, 1 x 1
file.209: HTML document text
file.210: GIF image data, version 89a, 1 x 1
file.211: ASCII text, with no line terminators
file.212: UTF-8 Unicode text, with very long lines, with no line terminators
file.213: GIF image data, version 89a, 1 x 1
file.214: GIF image data, version 89a, 1 x 1
file.215: GIF image data, version 89a, 1 x 1
file.216: XML 1.0 document text
file.217: ASCII text, with very long lines, with no line terminators
file.218: ASCII text, with no line terminators
file.219: PNG image data, 256 x 256, 8-bit colormap, non-interlaced
file.272: PE32 executable for MS Windows (GUI) Intel 80386 32-bit
file.273: PE32 executable for MS Windows (GUI) Intel 80386 32-bit
--------------------------------------------------------------------------------------------------------------

I apologize if this has been covered and I just missed the proper search
for the answer.  Any ideas?  Don't get me wrong, I LOVE the file extraction
capabilities, and it's getting better with each update.  I really just want
Windows PE's for now for research and tool development to analyze said
PE's.   Thanks, guys.  You all rock!

marcos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20120420/c087994c/attachment-0002.html>