thread "main" panicked when trying to use custom rules in `hunt` mode about chainsaw

[fscc-jamesd]

@rareguy - v1.0.1 was released today. 👍

[alexkornitzer]

The Panic

Right, so the issue for the panic was due to a stupid assumption by me. As you can see in the commit, and I am not sure why, I assumed that a sigma rule would always be valid and thus we would get a deserialisation. Obviously this was not the case and thus feeding an invalid rule, such as an empty file would cause a panic:

pub fn load(rule: &Path) -> Result<Vec<Yaml>> {
    let regex = Regex::new(r"---\s*\n").expect("invalid regex");
    let mut file = File::open(rule)?;
    let mut contents = String::new();
    file.read_to_string(&mut contents)?;
    let mut sigma: Vec<Sigma> = regex
        .split(&contents)
        .filter_map(|p| {
            if !p.is_empty() {
                serde_yaml::from_str::<Sigma>(p).ok()
            } else {
                None
            }
        })
        .collect();

    // NOTE: With an invalid rule we would end up here with an empty array and 
    // yet the code below assumes that we will have at least a single entry.
    let main = sigma.remove(0);
    ...

You may be asking why the above looks so complicated, that is for two reasons:

• serde_yaml does not support multiple files yet
• Sigma's use of multifile is odd

The Check 'Errors'

As you may or may not be aware, chainsaw does not use Sigma it actually uses Tau. For that reason we can't just drop the rules in and run them, so I wrote the Sigma to tau rule converter logic for James. Due to a lack of quality control on Sigma rules converting them is not the easiest of processes, thus we settled on the lowest hanging fruit for conversion.

A Tau rule is very basic because it needs to be incredibly performant, it consists of just the following:

• detection: the logic used to evaluate a document.
• true positives: examples document that must evaluate to true for the given detection.
• true negatives: examples document that must evaluate to false for the given detection.

We also keep the rule matching logic very simple, and therefore only support basic string matching operators as regex can be used for the more complicated scenarios (why reinvent the wheel) https://github.com/countercept/tau-engine#identifiers.

These design decisions in the Tau engine are where the conversion issues come in, we can consider Sigma's logic as a super set. In order to make them Tau compatible we would need to do some minor logic rewriting which is a tad challenging when there is no data to test the logic upon to ensure that it is correct. For example to support the rule you have shown above we would need to convert the match condition into regex as Tau does not support nested wildcards: https://github.com/countercept/chainsaw/blob/master/src/convert/sigma.rs#L106

From my memory we don't yet support the following Sigma features although apart from time there is nothing to stop us from adding them in:

• Nested wildcards
• Wildcards in condition names
• Aggregations

Hopefully my ramblings answer the questions and make sense :)

[alexkornitzer]

If you are able to isolate the rule or shove me at the repo that causes the crash that would be great, cause there will be combination logic that is causing Tau to get into a state it should not be in. I can't replicate it with the official Sigma rules or the Joe ones.

[alexkornitzer]

This is now live in master and will be out in the next release.

[alexkornitzer]

Right this is probably some funky assumption I have made in the sigma to tau conversion part of chainsaw. Is there any chance you could present a minimal reproducable example (i.e. a stripped down version of the rule that is being problematic)? If not don't worry, i'll get digging.

[rareguy]

I used rules (the entire rules directory) from [https://github.com/joesecurity/sigma-rules](Joe Security) repository. It immediately crashed though. I don't know the rules that might be the issue, since the error didn't seem to let me know where it crashed.

[alexkornitzer]

No worries, I have found the cause, its due to empty files. Going to get a fix out ASAP.

[rareguy]

btw, when is the next release?

[rareguy]

Hello,
When you mentioned that this error was due to empty files, I was not aware that it could be because all of the custom rules failed to load that it's assuming that there is no rules loaded. When I use the check module, it shows that almost all of the rules of those from Joe Security had "unsupported match" error that it chainsaw won't load. Maybe this highlighted another parsing error? Example:
this file
when checked:

[!] "...\\joe-security\\addfilefromsuspiciouslocationtoautostartregistry.yml": unsupported match - *reg add *\windows\currentversion\run /f /v *\appdata\roaming*

p.s.
sorry I misclicked the issue reopening

[rareguy]

Very well explained, thank you. So it's about Tau's limitation.

Also, I would like to reopen this issue because I have similar error after the update with different words.
When I do this command syntax:

PS> .\chainsaw.exe hunt .\evtx_attack_samples\ --rules .\sigma-rules-main\windows\rules\ --mapping .\mapping_files\sigma-mapping.yml

I got this output:

[+] Found 268 EVTX files
[+] Converting detection rules...
[+] Loaded 998 detection rules (240 were not loaded)
[+] Printing results to screen
[+] Hunting: [--------------------------------------------------] 0/268 \
thread 'main' panicked at 'internal error: entered unreachable code', C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\tau-engine-1.0.1\src\solver.rs:346:21

p.s.
Apologize there might be a mistake in typing, because I typed the output by hand for several reasons.

[alexkornitzer]

Hmm okay, so that looks like a Tau bug. Which set of sigma rules are you using there?

[rareguy]

So the rules folder filled with combinations of yml sigma rules (because I was assuming it's easier to work with when I put all the rules in bulk). I got it from various git repository, like Joe Security similar to previous one.

[alexkornitzer]

Right okay found the bug with this, its because the rule is invalid it has a typo:

detection:
  condition: (selection_process or selection_sysmon) and selection_command
  selection_process:
    EventID: 4688
    NewProcessName: "i*\\dnscmd.exe"
  selection_sysmon_process:
    EventID: 1
    Image: "i*\\dnscmd.exe"
  selection_command:
    CommandLine: i*dnscmd.exe /config /serverlevelplugindll*
true_positives: []
true_negatives: []

Above we can see that the identifier name in the condition does not match that of the identifier. The reason this gets into unreachable code in the Tau engine is because we are bypassing parts of Tau's validation in Chainsaw when we do the conversion. I will get this validation stage into the converter so that we don't pass invalid rules to the engine.

[fscc-jamesd]

v1.0.2 release is now out.