[Oisf-users] again on filestore

Victor Julien victor at inliniac.net
Sat Apr 21 10:14:28 UTC 2012


On 04/20/2012 10:21 PM, Marcos Rodriguez wrote:
> 
> 
> On Fri, Apr 20, 2012 at 2:09 PM, Marcos Rodriguez
> <marcos.e.rodriguez at gmail.com <mailto:marcos.e.rodriguez at gmail.com>> wrote:
> 
>     On Fri, Apr 13, 2012 at 9:15 AM, Peter Manev <petermanev at gmail.com
>     <mailto: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 <mailto: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://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://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
>             <mailto: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
>         <mailto: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!

The file_data rules are not related with the file extraction feature.
file_data inspects the normalized http response body currently.

-- 
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------




More information about the Oisf-users mailing list