Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Look into other ways than file extension to give Cuckoo file-type hints #47

Open
michaelweiser opened this issue Sep 21, 2018 · 6 comments

Comments

@michaelweiser
Copy link
Contributor

Discussion on #29 showed that mapping from MIME type to file extension throws up lots of questions. We should look into whether the whole issue can be avoided by using other means than the file type extension to give cuckoo a hint about how it needs to analyse a file. One possibility might be providing the MIME type itself to cuckoo and let it figure out what to do with it. This might be especially easy using the REST API.

Suggested by @Jack28.

@Jack28
Copy link
Member

Jack28 commented Sep 27, 2018

I don't see a straight way to achieve this

Here is the API documentation of CuckooSandbox:
https://cuckoo.sh/docs/usage/api.html?highlight=api#tasks-create-file

And the values which can be used via options:
https://cuckoo.sh/docs/usage/packages.html

@michaelweiser
Copy link
Contributor Author

michaelweiser commented Sep 27, 2018

The latter looks promising though: We could map certain mime types to specific packages. If e.g. we know the mimetype to be image/jpeg but do not know a file extension we could use the ie package to open those files with Internet Explorer explicitly because we know it should be able to do something useful with them.

The question is how much new information we might gain by this because we would explicitly be testing if the image tries to exploit some bug in the media libraries used by IE when it would normally be rendered by e.g. Outlook because it's an inline image of an HTML mail. But I'd say, something is better than nothing and Outlook and IE likely use the same libraries to render JPEGs anyway (just a guess).

@michaelweiser
Copy link
Contributor Author

... but if we're willing to add code to map mime types to packages we could just as well add our own code to map mime types to extensions instead of relying on or at least overriding parts of the logic of the magic python module. Feels like a toss-up.

@Jack28
Copy link
Member

Jack28 commented Sep 30, 2018

@michaelweiser michaelweiser modified the milestones: 1.7, 2.0 Apr 23, 2019
@Thorsten-Sick
Copy link

Windows goes by file extension. Linux by file magic. To make it a bit more complex: File can be differnt file types: https://github.com/corkami/pocs/tree/master/poly
The best way would be to decide outside of the VM which application to use to run this file and maybe even start several analysis processes. One fore Acrobat handling PDF, one for Chrome handling PDF, one ...

This would be the perfect case - but could require heavy re-design of the database.... Maybe do a quick fix now and start a new issue for this complex handling ?

@Jack28
Copy link
Member

Jack28 commented May 5, 2019

It would be best if the exact behavior would be configurable in the ruleset which package to use or multiple.

Probably the best default is the Cuckoo generic package that is closest to a double click on windows
cmd.exe /c start ...
https://github.com/cuckoosandbox/cuckoo/blob/c41c7c5cb09416b7cfc6159811792679e20762f2/cuckoo/data/analyzer/windows/modules/packages/generic.py#L28

@Jack28 Jack28 modified the milestones: 2.0, 2.1 Aug 27, 2019
@michaelweiser michaelweiser removed this from the 2.1 milestone Mar 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants