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

Implement YARA rules #17

Open
eth0izzle opened this issue Oct 1, 2019 · 8 comments
Open

Implement YARA rules #17

eth0izzle opened this issue Oct 1, 2019 · 8 comments
Assignees
Labels
enhancement New feature or request help wanted Extra attention is needed
Milestone

Comments

@eth0izzle
Copy link
Owner

eth0izzle commented Oct 1, 2019

To replace the current yaml signatures. This will allow us to create mroe powerful rules. For example to find GitHub API keys we would regex on ([a-f\d]{40}), but currently that would produce a lot of false positives (it's a SHA1 hash). With a YARA rule we could do:

rule GitHubApikey
{
    strings:
        $re1 = /[a-f\d]{40}/
        $re2 = /Authorization: token/
        $re3 = /https://api.github.com/

    condition:
        $re1 and ($re2 or $re3)
}
@eth0izzle eth0izzle added enhancement New feature or request help wanted Extra attention is needed labels Oct 1, 2019
@audibleblink
Copy link
Contributor

@eth0izzle does your ideal implementation

  1. replace yaml with YARA?
  2. add yara as an option, leaving yaml?
  3. add yara as the new default, making yaml optional?

For 2 and 3, a cli option could be added to choose the default matching engine.

I'm all for number 1. Easier to maintain just 1 code path. But what do you see being more merge-able, from a maintainer's standpoint?

This would probably close out #10 too, yeah?

@audibleblink
Copy link
Contributor

Could also potentially use both.

Since yara won't do filename or extension matching, perhaps we leave the yaml config file for the filename and extension parts. Eliminate contents as a part option from the config file and only use yara for pattern matching.

Or some variation of all of the above.

@eth0izzle
Copy link
Owner Author

Definitely the first option. I've already written the code for this and it seems to work well, just a little slow. I need to do further testing and cleanup. We can pass in YARA variables to check the extension, path and file name.

Have you made a start on this @audibleblink ?

@audibleblink
Copy link
Contributor

I haven't @eth0izzle. Just spent some of today reading through the project, getting a feel for where I'd put the code for each option. Glad I checked!

@eth0izzle
Copy link
Owner Author

The main problem is it's a bit of a bitch to setup the libyara on a platform other than Linux. See https://github.com/hillu/go-yara#installation

I'm thinking the best way forward is running shhgit in a docker container. What do you think?

@audibleblink
Copy link
Contributor

Would certainly make it easier.
...
I started typing some other ideas, re-read them, and deleted them with extreme prejudice.
It involved words like 'wrap with cgo', 'precompile', 'shellcode', and 'injection'.

Docker is fine.

@eth0izzle
Copy link
Owner Author

Hey @audibleblink I've just pushed the code to the v2 branch which includes the YARA rules and a lot of other stuff + code cleanup - definitely a WIP for now but would appreciate if you could test when you get a chance.

@eth0izzle eth0izzle self-assigned this Aug 14, 2020
@eth0izzle eth0izzle added this to the v2 milestone Aug 14, 2020
@audibleblink
Copy link
Contributor

audibleblink commented Aug 15, 2020

Oh awesome! Initial reports:

  • Had to delete outputs.raw from config.yaml to get it to run. It was yelling at me about a missing key.
  • With outputs.file.path and outputs.file.type set, nothing was being written to disk. (I wasn't able to find any code that parses it yet, but I'm still familiarizing myself.)

Runs great otherwise. Love the work on the rules. Works with the standalone yara binary as well (provided I define external vars). It's gonna take me a bit to dive deeper and give any meaningful feedback but I'm excited to spend some time on this.

edit: just noticed the TODOs. makes sense

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants