[Oisf-users] again on filestore
Victor Julien
victor at inliniac.net
Sat Apr 21 10:13:37 UTC 2012
On 04/20/2012 08:09 PM, Marcos Rodriguez 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!
Unless you use the waldo the id of the stored files resets with every
run. So are you sure the above files are not from older runs?
--
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------
More information about the Oisf-users
mailing list