Change regex engine?

[hach1yon]

SIGMAルールの正規表現とRustの正規表現に違いがあって、パースできないケースがある。というか、Rustの正規表現エンジンはちょっと特殊で細かいルールが普通の正規表現エンジンとちょっと違う。例えば、\/rという正規表現はSIGMAルール的にはOKだが、Rustではパースエラーになってしまう。他にも.*{という正規表現もSIGMAルール的にはOKだが、Rustではパースエラーになってしまう。

今は小手先の修正で対応しているが、結構怪しい実装になっているので他の正規表現エンジンを使いたい。他の正規表現のクレートを探すか、Rustから他の言語(例えばGolangとか)の正規表現エンジンを呼び出すような実装にしておいた方が無難。

現状での候補

• https://github.com/Project-Dream-Weaver/Python-Regex/tree/main/src
• Golangとかは速度も速いので、RustからGolangを呼び出してその正規表現を使うのもありかも

[kazuminn]

#148 でいっぺんにやっちゃう感じになるかな。と思いました。

[hach1yon]

ちょっと、どうするのが良いのか話す必要が有りますねー

[hitenkoku]

擬似メモ: Rustでなければokかもしれないが、基準となるルールがわからない状態
SIGMAが何で書くことを前提としているのかがわからない……

[YamatoSecurity]

主なregexエンジンがrustのデフォルトcrate、hyperscan、PCRE2のようです。(参考: https://sr.ht/~pierrenn/ripgrep/)
hyperscanが昔から一番速いので、そちらに変えた方が速くなる可能性があります。
参考: https://rust-leipzig.github.io/regex/2017/03/28/comparison-of-regex-engines/

SigmaがPCRE2を使っている情報は見つからなかったけど、昔から人気な正規表現なので、もしかしてPCRE2を使ったら、より多く検知できるかもしれません。実装してみないとなんともいえませんが。とりあえずhyperscanに変えてみましょう。

@kazuminn さんがやりたいと仰っているので、アサインします。

[kazuminn]

ありがとうございます。

現在、sigmaは、ElasticSearchの正規表現だけをサポートしており、それはjavaで実装されており、ライブラリはjava.util.regexのようです。
java.util.regexのexpressionを調べてみると、公式に

Perlに似た文字列形式で指定します。

と書いてありました。
https://docs.oracle.com/javase/jp/17/docs/api/java.base/java/util/regex/package-summary.html

Perlなので、PCRE2があってるかもしれませんが、perlと"似た"なので、何とも言えません。

とりあえず、hyperscanで実装してみます。

[YamatoSecurity]

なるほど、調べてくれてありがとうございます！
コンパイルが少し面倒になりますが、HyperscanのChimera APIを使ったら、PCRE2も使えるみたいですね。
https://crates.io/crates/hyperscan

[YamatoSecurity]

@kazuminn
Sigmaの元々のregexがそのままrust crateだとパースエラーを起こしています:

[WARN] Failed to parse rule file. (FilePath : ../sigma/rules/windows/powershell/powershell_module/posh_pm_invoke_obfuscation_via_var.yml)
[WARN] Cannot parse regex. [regex:(?i).*&&set.*(\{\d\}){2,}\\\"\s+?\-f.*&&.*cmd.*\/c, key:detection -> selection -> Payload|re]

[WARN] Failed to parse rule file. (FilePath : ../sigma/rules/windows/powershell/powershell_module/posh_pm_invoke_obfuscation_stdin.yml)
[WARN] Cannot parse regex. [regex:.*cmd.{0,5}(?:\/c|\/r).+powershell.+(?:\$\{?input\}?|noexit).+\", key:detection -> selection -> Payload|re]

[WARN] Failed to parse rule file. (FilePath : ../sigma/rules/windows/powershell/powershell_module/posh_pm_invoke_obfuscation_via_stdin.yml)
[WARN] Cannot parse regex. [regex:(?i).*(set).*&&\s?set.*(environment|invoke|\${?input).*&&.*", key:detection -> selection -> Payload|re]

[WARN] Failed to parse rule file. (FilePath : ../sigma/rules/windows/powershell/powershell_module/posh_pm_invoke_obfuscation_clip.yml)
[WARN] Cannot parse regex. [regex:.*cmd.{0,5}(?:\/c|\/r).+clip(?:\.exe)?.{0,4}&&.+clipboard]::\(\s\\\"\{\d\}.+\-f.+\", key:detection -> selection -> Payload|re]

が、 https://regex101.com/ で試したら、PCREもPCRE2もパースできました。hyperscanはPCREベースなので、そちらを使った方が速くなるだけではなくて、Sigmaルールとの互換性があって、コンバータスクリプトで正規表現を手直ししなくても良いようになるかも。

[kazuminn]

hyperscanのPCREを使ったhayabusaをコンパイルできましたが、リンクできませんでした。
git2ライブラリの方にも、PCREが使われており、リンク時に「二個あるのだめ」と怒られます。
どちらかに統一させようとしましたが、方法が提供されておらず、できませんでした。
hyperscanのPCREは、個別でビルドしており、依存関係の考慮に入らないようです。

@YamatoSecurity どうしましょうか？

1. git2を別のに変える（いや、まぁ無理か
2. PCREなしのhyperscanを実装
3. PCRE2

[YamatoSecurity]

@kazuminn
ありがとうございます！
最近のバージョンのPHP等はPCRE2を使っているので、その実装が良さそうですが、Sigmaの運営者に聞いてみました：
SigmaHQ/sigma-specification#25
返事が返ってきたら、ご連絡します。

[kazuminn]

うっ。私も二日前に質問していました。報告漏れてすみません。
SigmaHQ/sigma#3658

このまま両方残しておいて、レスポンスの遅い方をdeprecatedってことで閉じるのでいいかなとおもいます。

[YamatoSecurity]

なるほど、決まっていないっぽいので、返事は少し時間がかかるかもしれません。。（作者によって正規表現の書き方が違う気がします・・）
そうですね。このまま両方を残しておいて、レスポンスを待ちましょう。
PCREとPCRE2は書き方が若干違うみたいです: https://stackoverflow.com/questions/70273084/regex-differences-between-pcre-and-pcre2

こちらで、Python等でルールの正規表現を抽出して、PCREとPCRE2で書き方が正しいかどうかチェックするしかないかもしれません。

[YamatoSecurity]

@kazuminn こちらで確認しました。Sigmaルールの正規表現はPCREでもPCRE2でもパースエラーが出ませんでした。
ということで、PCRE2での実装をお願いできますか？

[kazuminn]

@YamatoSecurity 承知しました。

[YamatoSecurity]

@kazuminn
sigmaの人から返事が返ってきました。 ( SigmaHQ/sigma-specification#25 (comment) )
やはり、ちゃんと定義されていないようです。正規表現をそのままバックエンドに渡しているので、一番よく使われているPCREの正規表現だったら問題がないはずだけど、高度な正規表現だと、うまくいかない可能性があるので、以下の条件に絞った方が良いんじゃないかな〜？て言っています.

It's indeed not specified and currently existing conversion logic (pySigma, sigmac) passes it through to the query. I think PCRE is currently most prevalent in most query languages and other software, but usage of advanced features in rules could cause incompatibilities. Therefore I suggest to restrict to a basic subset of features, more specific:

    . placeholder
    [a-z] character sets with negation syntax [^...] but no character class syntax like [:...:].
    *, ? and + quantifiers.
    {min,max} repetition syntax.
    Grouping with (...), omitting all modifiers like lookahead/behind etc.
    OR operator | inside of groups.

[kazuminn]

@YamatoSecurity お知らせありがとうございます。

なるほど。
PCRE2で実装するのは、変わりないですか？jitなので早くて。
また、
条件に絞るのは、どうしましょう。（ドキュメントに書くやら、エラーをもうちょっと工夫るするとか？）

[YamatoSecurity]

@kazuminn
PCREで実装するのは、代わりありません。
条件は気にしなくて良いと思います。Sigmaのドキュメンテーションに書くものなので。
実装が終わったら、「HayabusaはPCRE2を使っています」とHayabusa-rulesのreadmeに書こうと思っています。

[YamatoSecurity]

@kazuminn 実装はどこまで進んでいますか？

[kazuminn]

@YamatoSecurity 今、一度コンパイルが成功しましたが、テストとclippyが通らない状況です。
思った以上にコンパイルを通すのに、疲れたので、少し作業を休憩していますが、年内リリースの意気込みです。

[YamatoSecurity]

@kazuminn ありがとうございます！
了解です。無理しないようにね！年内で大丈夫です。

[YamatoSecurity]

@kazuminn まだテストとclippyに失敗しても良いので、コンパイルできる状態だったら、こちらでどのぐらい速くなっているか等検証したいのですが、ドラフトのPRを上げて頂けますか？

[kazuminn]

@YamatoSecurity 上げましたー。#821

[YamatoSecurity]

参考: hscheckツールでsigmaの正規表現をPCREなしのHyperscanで使えるかどうかチェックできるようです: https://intel.github.io/hyperscan/dev-reference/tools.html

[YamatoSecurity]

今更気づいて、申し訳ございませんが、hyperscanはIntelが作っているせいかARMに対応していないようなので、そもそも使えないです。。(MAC M1にも対応したいので・・）

PCRE-JITはMac M1に対応しているかな？(ARM v5, v7, and Thumb2に対応しているようですが）
リンク： https://www.pcre.org/original/doc/html/pcrejit.html

[YamatoSecurity]

メモ：
rust-lang/regex#501 (comment)
regexの焼き寿司さんがデフォルトのunicode対応要らないんじゃない？というコメントを頂いたので、なしでコンパイルして比較してみました。
14GBに対して、unicode ONの場合はメモリが14GB、OFFの場合は13.7GBで約300MBメモリが減りました。また、約32分のスキャンが6秒速くなりました。検知数は同様でした。フィールドに日本語を探す場合があって、メモリ使用＋スキャン時間は対して変わらないので、今のままデフォルトのunicode ONの設定にしようと思います。

[YamatoSecurity]

The parsing errors in sigma rules were due to unneeded escapes in the regex so we submitted PRs to fix them and now we have no parsing errors with the regex crate. The regex crate is faster than PCRE2-JIT now, has the highest number of detections, and is more maintained than the pcre2 crate. hyperscan was also a candidate but only works on intel CPUs so we decided to keep using the regex crate. The only problem would be if people write regular expressions with lookarounds and/or back references which the regex crate does not support for performance reasons. In that case we may use pcre2 just for those rules but is not needed at the moment.