SBOM
SBOMについて
最近、SBOM（えすぼむ）という言葉をよく見る。
Software Bill of Materialsの頭文字をとっている。
BOM＝Bill of Materialsは、製造現場で部品表とか呼ばれて、製造物はどんな部品から構成されているかを示すもの。
それをソフトウェアの世界でやる場合、ソフトウェアがどのようなモジュールで構成されているのかを明らかにするものになる。
log4jで脆弱性が見つかった際、自分自身が明示的にlog4jを利用していれば利用の有無は分かる。しかし、他のオープンソースがlog4jを組み込んでいる場合、それを見つけ出すのは大変になる。これを推移的依存、と呼ぶらしい。
推移的依存では、脆弱性への対応に時間が掛かったり、対応が不十分になりやすい。
ソフトウェアで、どんなライブリの、どのバージョンを使用しているか一目で分かるようにするのがSBOMの役割。
最近の動向
アメリカでは、大統領令で政府機関と取引する企業にSBOMの提出を義務付けている。
日本では、経済産業省で検討されているようです。
マイクロソフトからも、SBOMを出力するツールが無償提供されています。
Dockerも、docker sbom コマンドでコンテナのSBOMを出力できるようになったようです。
SBOMの詳細
一口にSBOMと言っても、4パターン程あるようです。
・CycloneDX・・・OWASP
・SPDX・・・Linux fundation
・GitHub SBOM・・・GitHub
・SWID
出力されたSBOMを使用して、脆弱性の検知をする流れのようです。
OWASPにDependency Trackというプロジェクトがあり、これにSBOMを食わせると脆弱性などを表示してくれます。
今後、SBOMによるソフトウェアの構成の透明化は促進されると思われます。
ただ、べてのコンポーネントをもれなく抽出してSBOMに出力するには、課題もあるようで、開発者の制約にならないのか、気になるところです。
Shellbagsについて
ShellBagsって
ShellBags は、WindowsのExplorerで2度目以降にフォルダーを開いた際、前回と同じ状態で利用できるよう、フォルダーのウィンドウサイズ、表示レイアウト、表示位置などの情報を記録する仕組みのこと。
ShellBagsの情報自体はレジストリに保存されている。ShellBagsの情報は、そのフォルダが削除された後も残るので、フォレンジックスの際に使用されることも。
こちらの資料にShellBagsの詳細が述べられている。
Windows ShellBag Forensics in Depth (giac.org)
Windows8.1までの情報しかないが、レジストリの格納場所は以下になる。
NTUSER.DAT\Software\Microsoft\Windows\Shell\BagMRU
NTUSER.DAT\Software\Microsoft\Windows\Shell\Bags
UsrClass.dat\Local Settings\Software\Microsoft\Windows\Shell\BagMRU
UsrClass.dat\Local Settings\Software\Microsoft\Windows\Shell\Bags
Windowsにログインしている状態であれば、レジストリエディタから直接、レジストの内容を確認できる。ログインしていない場合、ユーザープロファイルフォルダに保存されているNTUSER.DATとUsrClass.datから確認できる。
これをメモ帳などで開くと、バイナリファイルのため、文字化けして内容が確認できない。これを閲覧するツールがいくつかある。
Regripper
Kali LinuxでRegripperというツールが使えるようなので、使ってみた。
- インストール
dpkg --add-architecture i386 && apt update && apt -y install wine32
をしてから、
sudo apt install regripper
でインストールできる。
- 起動
regripper -h
により、GUI画面が起動。
- 使い方
こちらの動画が分かりやすかった。
https://www.youtube.com/watch?v=aAzuMdis0uo
Hive File: .datファイルを選択
Report File: パースした情報の書き出し先
Plugin File: 「All」ですべての情報が書き出される
余談
ShellBagsの情報が削除されるタイミングは良く分からない。先ほどの資料では、基本的に削除されないように読み取れる。
放っておくと、レジストリが肥大化する原因になる。
実際、Windowsで移動ユーザープロファイルを使用していて、ログインに時間がかかるようになり、ShellBags関連のレジストリを削除したらログイン時間が短縮されたことがあった。
ただ、削除しすぎると、デスクトップのアイコンの位置がおかしくなったりします。
このようなツールも存在する。
確かにプライバシーの観点からも、履歴の削除は出来た方が良いのかもしれない。
しばらくの後、ShellBags関連のレジストリを削除していても、ログイン時間が長くなる現象が発生した。いろいろ調べてみても分からず、最終手段として、UsrClass.datを削除してみた。
当然、問題が発生すると思いきや、ログイン時間は短縮され、他にまったく影響がなかった。例えば、ログインに20分以上かかっていた人が、3分に短縮された。
UsrClass.datをRegripperで見てみると、Windowsストアアプリの情報がたくさん（重複・過去のもの）あり、ストアアプリを使用していない環境だったので、影響がなかったと思われる。
検索すると、UsrClass.datを削除したため、Windowsストアアプリを再インストールすることになった情報があった。
そもそもUsrClass.datに保存される以下のKEYはログオフ時に削除していた。
\Local Settings\Software\Microsoft\Windows\Shell\BagMRU
\Local Settings\Software\Microsoft\Windows\Shell\Bags
UsrClass.datに保存されるShellBagsの情報の必要性が分からない。
また、Windowsストアアプリを禁止している場合、UsrClass.datの存在意義って？と考えてしまう。
マイクロソフトとしては、レジストリを消さないで、と言いますが、消さないと何ともならない状況をなんとかして欲しい。
まとめ
NTUSER.DATとUsrClass.datをregripperなどでパースすることで、ShellBagsから過去に開いたファイル・フォルダを確認できる。それ以外にも、ログイン遅延の原因や対策を見つけられることがある。
VirusTotal
VirusTotal(ういるすとーたる)について
CEHのテキストでも紹介されていたVirusTotal。
https://www.virustotal.com/gui/home/upload
ファイルをアップロードしたり、URLやIPを入力すれば、70を超えるベンダのチェックの結果を教えてくれたりします。
2004年6月にスペインのセキュリティベンダーHispasec Sistemasが設立した無償のWebサービス。
2012年9月にGoogleに買収されて、それ以降はGoogleが運営している。
ブラウザの拡張やAPIからも上記検索を利用できる。
基本的に無料で使用できるが、有料サービスもあり、費用は年間10,000ドルとか情報が見つかるが定かではない。
有料サービスでは、無料サービスでアップロードされたファイルをダウンロードできるようになっている。
目的は、検体としての利用ではあるが、情報漏洩リスクが指摘されている。
VirusTotalのContributorが以下のURLに記載されている。
アンチウイルス：74社
ドメイン・IP：77社
振る舞い分析：14社
IDS：6社
Crowdsourced Sigma Rules:3社
YARA rule repositories:19社
File characterization tools & datasets:19社
と重複はあるものの、それらの企業のデータを用いて総合的に判定をしているようです。
CEHのオンライン講座では、マルウェアを作成して、VirusTotalにアップロードして検知率を測定して、その後、マルウェアに偽装工作をして、検知率が下がることを確認するために使用していた。
こんな記事もあり、VirusTotalで見つからない＝優秀なマルウェア、というKPI化にも。
有料機能を使って、アップロードされた情報から機密情報を収集している人もいるでしょう。
とはいえ、複数のアンチウイルスソフトをPCにインストールすることは少ないので、セカンドオピニオンとして利用するには有効と思われる。
フィッシングサイトのデータセット
フィッシングサイトの見分け方
今さらではあるが、フィッシングサイトの見分け方について。
2015年にフィッシングサイトに関するデータセットが提供されている。
30個の特徴量からフィッシングサイトを判定した2456件のデータとなっている。
これを機械学習させることで、他のサイトについてもフィッシングサイトの判定が可能になる。まずは、その特徴量をみることで、フィッシングサイトの見分け方のヒントになるのか確認をする。
特徴量については、以下の文書にまとめられている。
https://archive.ics.uci.edu/ml/machine-learning-databases/00327/Phishing%20Websites%20Features.docx
データについても、同様にダウンロードできる。
https://archive.ics.uci.edu/ml/machine-learning-databases/00327/Training%20Dataset.arff
ファイルはarffという形式で、特徴量が@attributeで記載され、そのデータが@data以下に表示される。
データ1番目の項目は、
@attribute having_IP_Address { -1,1 }となっている。
特徴量のドキュメントを見ると、以下のようになっている。
URLにIPアドレスを含んでいる場合、フィッシングサイトと判定している。しかし、その場合、-1 or 1なのかドキュメントに記載はない。
さらに見ていくと、データでは@attribute Request_URL { 1,-1 }となっているが、
ドキュメントを見ると、3パターンに分かれていて、どれが、どれなのやら。
最後には、フィッシングサイトの統計情報に含まれるもの、という特徴量もあり、もうそれだけでいいのでは？と思うものも。
2015年にデータが公開されているので、若干、特徴量としての考え方が古くなっているものもある。
曖昧ながら、特徴量をドキュメントに記載の順番通りにまとめたものが以下となる。
@attribute having_IP_Address { -1,1 }
の場合
と記載があるので、
前者が-1でフィッシングサイト
後者が1で正常サイト、とした。
| 特徴量項目 | 特徴量名称 | 選択値 | 値の詳細 | 具体例 | |
| 1 | URLにIPアドレスを使用している | having_IP_Address | { -1,1 } | -1:Yes（フィッシング） 1:No |
http://125.98.3.123/fake.html |
| 2 | URLの長さ | URL_Length | { 1,0,-1 } | 1:54文字未満 0:54-75文字 -1:それ以上（フィッシング） |
http://federmacedoadv.com.br/3f/aze/ab51e2e319e51502f416dbe46b773a5e/?cmd=_home&dispatch=11004d58f5b74f8dc1e7c2e8dd4105e811004d58f5b74f8dc1e7c2e8dd4105e8@phishing.website.html |
| 3 | URL省略を使用している | Shortining_Service | { 1,-1 } | 1:Yes（フィッシング） -1:No |
bit.ly/19DXSk4 |
| 4 | URLに@が使用されている | having_At_Symbol | { 1,-1 } | 1:Yes（フィッシング） -1:No |
www.fake@site.com |
| 5 | URL中の「//」の位置 | double_slash_redirecting | { -1,1 } | -1:7文字目以降にある 1:それ以外 |
http://www.legitimate.com//http://www.phishing.com |
| 6 | URLのドメイン名が「-」で分割されている | Prefix_Suffix | { -1,1 } | -1:Yes（フィッシング） 1:No |
http://www.Confirme-paypal.com/ |
| 7 | URLのドメイン部の「.」の数 | having_Sub_Domain | { -1,0,1 } | -1:1個 0:2個 1:それ以外（フィッシング） |
http://www.hud.phising.fake.ac.uk/students/ |
| 8 | サーバー証明書の状況 | SSLfinal_State | { -1,1,0 } | -1:信頼できるHTTPSで有効期限が1年以上 1:自己証明書 0:上記以外（フィッシング） |
|
| 9 | ドメインの有効期限 | Domain_registeration_length | { -1,1 } | -1:1年以下（フィッシング） 1:上記以外 |
|
| 10 | 外部のドメインからfaviconをロードしている | Favicon | { 1,-1 } | 1:Yes（フィッシング） -1:No |
|
| 11 | サーバーのポートの状況 | port | { 1,-1 } | 1:望ましい(80,443ポートのみオープン) -1:望ましくない（フィッシング？） |
|
| 12 | URLのドメイン部にhttpsが含まれる | HTTPS_token | { -1,1 } | -1:Yes（フィッシング） 1:No |
http://https-www-paypal-it-webapps-mpp-home.soft-hair.com/ |
| 13 | 全リクエストに占めるサーバー外部へのリクエストの割合 | Request_URL | { 1,-1 } | 1:22%未満 ?:22-61% -1:上記以外（フィッシング） |
|
| 14 | リンク先の無い<a>タグの使用の割合 | URL_of_Anchor | { -1,0,1 } | -1:31%未満 0:31-67% 1:上記以外（フィッシング） |
A. <a href=“#”> B. <a href=“#content”> C. <a href=“#skip”> D. <a href=“JavaScript ::void(0)”> |
| 15 | <Meta>, <Script> <Link> タグに含まれるリンクが自サーバードメイン宛ての割合 | Links_in_tags | { 1,-1,0 } | 1:17%未満 -1:17-81% 0:上記以外（フィッシング） |
|
| 16 | Server Form Handler (SFH)の値 | SFH | { -1,1,0 } | -1:"about: blank" Or ブランク（フィッシング） 1:その他のドメインを参照 0:上記以外 |
|
| 17 | メールの送信 | Submitting_to_email | { -1,1 } | -1:mail() or mailto: ファンクションを使用（フィッシング） 1:上記以外 |
|
| 18 | WHOISに登録されているホスト名がURLに含まれる | Abnormal_URL | { -1,1 } | -1:No（フィッシング） 1:Yes |
|
| 19 | Webサイトのリダイレクト回数 | Redirect | { 0,1 } | 0:1回 ?:2-3回 1:上記以外（フィッシング） |
|
| 20 | マウスオーバーによってステータスバーを変更している | on_mouseover | { 1,-1 } | 1:Yes（フィッシング） -1:No |
|
| 21 | 右クリックを禁止している | RightClick | { 1,-1 } | 1:Yes（フィッシング） -1:No |
|
| 22 | テキストフィールがあるポップアップウインドウを使用している | popUpWidnow | { 1,-1 } | 1:Yes（フィッシング） -1:No |
|
| 23 | Iframeを使用している | Iframe | { 1,-1 } | 1:Yes（フィッシング） -1:No |
|
| 24 | ドメインの年齢 | age_of_domain | { -1,1 } | -1:6カ月以上 1:その他(フィッシング） |
|
| 25 | DNSレコードの有無 | DNSRecord | { -1,1 } | 1:なし（フィッシング） 0:あり |
|
| 26 | Webサイトのランキング | web_traffic | { -1,0,1 } | -1:99,999位以内 0:100,000位以上 1:ランク外（フィッシング） |
|
| 27 | Webページのランキング | Page_Rank | { -1,1 } | -1:0.2未満（フィッシング） 1:上記以外 |
|
| 28 | Googleの検索対象 | Google_Index | { 1,-1 } | 1:Yes -1:No（フィッシング） |
|
| 29 | 外部からのリンク数 | Links_pointing_to_page | { 1,0,-1 } | 1:0個（フィッシング） 0:1-2個 -1:上記以外 |
|
| 30 | 統計調査に含まれるIPやドメイン | Statistical_report | { -1,1 } | -1:Yes（フィッシング） 1:No |
|
| 結果 | 判定結果 | Result | { -1,1 } | -1:フィッシングサイト 1:正常なサイト |
特徴量の中には、コードを読み解いたりしないといけないものもあり、その特徴量をどうやって抽出するのか気になる。
kaggleに同じデータセットを用いたものや、似たデータセットがあったりするのでそちらを見てみると参考になるのかも。
おまけ
このデータをもとにした論文とかもあるようですが、一番悩んだのが以下です。
・Table2なんてない
・PrefferedはPreferredのスペルミス？
・Preferred StatusだったらPhishingになる？
とノイズがいろいろあって、よく理解できなかった。
IDSやIPS（ネットワーク型）
侵入検知や防御
CEHのテキスト12章は、IDSについて。
IDSの一般論から、製品紹介。その後は、IDSをかいくぐるテクニックの紹介。
製品としては、SnortやSuricataが紹介されており、Snortに関しては、Snort Ruleというパケットフィルタリングルールの記述についても触れられている。
SnortやSuricataはオープンソースなので、導入自体は無料で出来る。一方で、IDSの有料製品・サービスを利用しようとすると、その金額は小さくない。
オープンソースでどこまで出来るのだろうか。
Snortについて
Snortは1998年に制作され、2013年にCiscoに買収され、今も開発は続いていて、Snort Version3.xが2021年にリリースされている。
Snortの概略
Snortは、ネットワーク型IDS。
・対応OS
殆どのLinux系OSに対応している。
Ver3では、Windowsはサポートしておらず、Ver2.9系のexeが配布されている。
・対応プロトコル
・対応モード
- Sniffer mode：パケット画面表示
- Packet Logger mode：ログ記録
- Network Intrusion Detection System (NIDS) mode：侵入防御
・ルールアクション
- alert - generate an alert using the selected alert method, and then log the packet
- log - log the packet
- pass - ignore the packet
- drop - block and log the packet
- reject - block the packet, log it, and then send a TCP reset if the protocol is TCP or an ICMP port unreachable message if the protocol is UDP.
- sdrop - block the packet but do not log it
・ルールセット
- Community
- Registered
- Subscriber
最新の脅威に対応したものはSubscriberで配布されるが、有料（399ドル/年）になる。
Ciscoのtalosと呼ばれるセキュリティ専門集団が対応しているようです。
IDSの導入をオープンソースで無料で出来るものの、最新のルールを適用しようとすればお金がかかる。
IPSで構成する場合は、サーバーとネットワーク機器の間に挟む構成になり、それなりのパフォーマンスとともに可用性も求められる。
パケットの処理は、ハードウェア的な処理の方が高速と言われる。IPSのアプライアンスでは、IPS機能障害時に、通信をバイパスする機能を持つものもある。
ネットワークレベルのセキュリティに対して、どの程度コストをかけるのか、非常に悩ましい。まずは、その判断のためにもIDSによるトラフィックの可視化が初手になるのだろうか。
SnortとELKで、オープンソースでグラフィカルなビューを提供できそうです。
YARA
マルウェア解析・検知ツール
YARAは、マルウェア解析・検知ツールで、Virustotalの開発者Victor Alvarezによって開発された、とWikiに記載がある。
たまに見かけるので、気になっていた。
YARAという単語自体は、
"YARA: Another Recursive Acronym(YARA、もう一つの再帰略語)"
"Yet Another Ridiculous Acronym(さらにもう一つのばかげた略語)"
の略語で、大きな意味は無いらしい。
公式サイトを見ると、Who's using YARA ということで、いろんな会社が使用していることが分かる。
YARAの使い方
『YARAルール』という文字列と条件、条件演算子、正規表現などを用いて、
マルウェアのファミリーの記述を作成し、"yara"コマンドで
# yara [OPTION]... [RULEFILE]... FILE | PID
とすることで、ルールに沿ってFILE or PIDからマルウェアを検出します。
security.sios.comから引用。
YARAルールの初歩的な意味はこちらのサイトが分かりやすい。
Deep Discovery Analyzerという製品ではYARAルールを独自に記述してマルウェアの検出の根拠とするようです。
すべて自分でルールを記述するのか、という訳でもなく、ESETはルールファイルを公開していて、YARAルールがマルウェア検知の共通基盤のようになっている。
YARAをテストする際に役立つファイル。
記載されているのは、こんな文字列だけ。
それでもウイルス対策ソフトでは、怪しいファイルとして削除されてしまいます。
各ウイルス対策ソフトのベンダーは、YARAによる検出などを組み合わせて、製品を構成しているんだろうか。
IoC（Indicator of Compromise）
IoCってなんだ
IoC（Indicator of Compromise）は、侵害の痕跡、侵害指標、痕跡情報などと訳されることが多い。
サイバー攻撃の痕跡をデータベース化して技術仕様として活用することで、攻撃を受けていることを素早く察知し、その影響範囲の最小化を目指すのがIoCの基本的な考え方のようです。
共有される情報としては、ファイルハッシュ、IPアドレス、ドメイン名など。
こちらの一連の記事でIoCを収集するツールが紹介されている。
・コミュニティ
① OTX (Open Threat Exchange)
② ThreatConnect Exchange
③ MISP (Malware Information Sharing Platform)
④ IBM X-Force Exchange
⑤ Twitter
したいことが色々ある⇒IBM X-ForceもしくはOTX
IOCの情報をとにかく沢山集めたい⇒OTX、ThreatConnect
他では見つけられない、ユニークな情報が欲しい⇒Twitter、MISP
・IPアドレスとドメイン
① VirusTotal
② Threat Intelligence Platform
③ IPVoidとURLVoid
④ DNSdumpster
⑤ CIRCL BGP Ranking
・さらなる調査
① ThreatCrowd
② VirusTotal
③ PassiveTotal
④ Yeti
IoCの標準化の動きもある。
- OpenIOC：Mandiant社が作成しオープンソースとして公開している
- STIX：MITRE と OASIS サイバー脅威インテリジェンス（CTI）技術委員会がサイバー脅威情報の記述のために開発した標準化言語
STIXをどのように伝達するのかがTAXIIで規定される。TAXII は「Trusted Automated eXchange of Intelligence Information」の略。
IoCとともに、IoBというものもある。Indicator of Behabiorで、振る舞いの痕跡、となる。
IoAもあって、Indicator of Attackで、攻撃の痕跡。IoAとIoCで対で表現されることがあり、前者は現在進行形で、後者は過去形、という捉え方。
サイバー脅威インテリジェンス（CTI）
サイバー脅威インテリジェンスは以下に分類され、プロアクティブな対応を推進する。
- 戦略的
- 戦術的
- 運用上
- 技術的
IoCが適用されるのは、戦術的・技術的部分。
