マルウェアのURLを共有したいとして、普通にhttps://evil.example.com/xxx/yyyとか書いてしまうと、URLが自動リンクになってしまう可能性があります。
そこで、うっかりURLを踏んでしまったりしないように、脆弱性データベースなどではhttps://evil[.]example[.]com/xxx/yyyといった形式で表示してします。
しかし、この表現は特に決まっておらず各自が自由にやっていたのでサイトによって形が異なっており、互換に難がありました。
そこでこの表記を共通化しようというRFCが先日IETFに提出されていました。
以下は該当のドラフト、A Standard for Safe and Reversible Sharing of Malicious URLs and Indicatorsの紹介です。
A Standard for Safe and Reversible Sharing of Malicious URLs and Indicators
Abstract
URL、IPアドレス、メールアドレス、ドメイン名などの、潜在的に危険なセキュリティ侵害インジケーター(IoC)を共有するための一貫した可逆な手順を定義します。
IoCを表示・共有する際に、誤って実行されたり有効化されることを防ぐため、安全な難読化を行います。
この技術は、脅威インテリジェンスの安全な配信を標準化することを目的としています。
Introduction
悪意のあるアーティファクトを安全に共有することは、脅威インテリジェンス・オープンソースインテリジェンス、そしてインシデント対応において必要不可欠です。
しかし、マルウェアや脅威アクターのURL・IPアドレス・メールアドレスなどを生で共有すると、誤ってアクティベートしてしまうリスクがあります。
このドキュメントでは、様々なプラットフォーム・フォーマット・ユースケース間で安全に共有するために、難読化および難読化解除をおこなう可逆的な手法を定義します。
Problem Statement
問題提起。
一貫性のない難読化手法は、脅威インテリジェンスの信頼性や自動処理を妨げます。
たとえば以下のようなケースです。
・h**p://example[.]comを想定したツールではhxxp://example[.]comを解析できない。
・192.0.2(.)1を想定したツールでは192.0.2[.]1を解析できない。
このような不一致により、検出や対応の有効性に影響をおよぼします。
Obfuscation Techniques
難読化。
以下の変換を適用します。
・httpおよびhttpsスキームは、hxxp・hxxpsに置き換える。
・ドメイン・IPアドレスの全ての.は[.]に置き換える。
・メールアドレスの全ての@は[@]に置き換える。
・曖昧さを避けるため、.を%2eにするなどのエンコードは避ける。
例は以下のようになります。
オリジナル： https://evil.example.com/path
エンコード： hxxps://evil[.]example[.]com/path
オリジナル： http://username:password@attacker.com
エンコード： hxxp://username:password[@]attacker[.]com
オリジナル： user@phishing.example.com
エンコード： user[@]phishing[.]example[.]com
オリジナル： http://192.0.2.1
エンコード： hxxp://192[.]0[.]2[.]1
オリジナル： http://[2001:db8::1]:8080
エンコード： hxxp://[2001:db8::1]:8080
認証情報付きURLは、説明のみの目的で記載しています。
運用上は認証情報付きURLは推奨されません。
IPv6アドレスの角括弧内は、::ベースの構文を維持する必要があります。
De-obfuscation Techniques
難読化の解読。
難読化されたデータを取り込むツールは、この変換を自動的かつ決定論的に元に戻すべきです。
・hxxp・hxxpsをhttp・httpsに戻す。
・[.]を.に戻す。
・[@]を@に戻す。
誤解を避けるため、難読化解除ではセマンティクスを維持する必要があります。
例は以下のようになります。
難読化： hxxps://evil[.]example[.]com/path
解除後： https://evil.example.com/path
難読化： user[@]phishing[.]example[.]com
解除後： user@phishing.example.com
Example Use Cases
一般的なユースケース。
・OSINTによるURLの共有。
誤クリックを防ぐ。
・メールコミュニケーション。
セキュリティチーム等で危険なメールアドレスを共有する。
・脅威インテリジェンスプラットフォーム。
ブロックリスト更新のため、難読化IPアドレスを自動で取り込む。
Security Considerations
セキュリティの考慮事項。
この難読化により、脅威インテリジェンスを誤ってアクティベートするリスクは軽減されますが、難読化されたデータは慎重に扱う必要があります。
適切なコンテキストなしに難読化を複数回繰り返すと、曖昧な変換や不可逆な変換が発生する可能性があります。
・PDF内の難読化されたURLはハイパーリンクされる可能性があります。プレーンテキストを使用してください。
・難読化されたデータを処理するシステムは、それらを有害なデータとして取り扱う必要があります。
・認証情報は、セキュリティリスクがあるので、難読化された形式でも共有するべきではありません。
Implementation Guidance
実装ガイドライン。
脅威インテリジェンスを解析するソフトウェアは、これらの難読化・難読化解除を明示的にサポートする必要があります。
ユニットテスト・検証スクリプトで正しい難読化解除が行われることを検証しましょう。
以下はテストケースの例です。
インプット： "hxxp://192[.]0[.]2[.]1"
アウトプット： "http://192.0.2.1"
Edge Cases and Special Handling
エッジケースその他。
国際化ドメイン名のPunycodeも同様に処理します。
非標準のURIスキームも同様に処理します。
FTP： ftp://example.com
FXP： fxp://example[.]com
IPv6アドレス内のコロン:および括弧[]は変更しません。
感想
いにしえのttps://evil.example.com/xxx/yyyでええやろ、と一瞬思いましたが、これだと一部のエディタ等が自動でリンクにしてしまうので却ってまずいわけですね。
従って、この形式のURLは、一般的なエディタやブラウザ等は自動的に展開してはいけません。
単に難読化するだけなら適当な可逆暗号でもかませばいいわけですが、この変換のポイントは『人間の目でも読める状態を維持しながら』なので、今回の用途には適さないわけです。
これで脅威への対策がより進むといいですね。