[Oisf-users] again on filestore

Fri Apr 20 20:21:21 UTC 2012

On Fri, Apr 20, 2012 at 2:09 PM, Marcos Rodriguez <
marcos.e.rodriguez at gmail.com> wrote:

> 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
>

Hi again,

Looks like my apology was justified.  I just read the other thread where
Will mentioned rolling back the rules.   Thanks again!

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