[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