DeepSecurity考察ブログ(C1WSもあるよ!)

DSとかSecurity関連をメインにしたい感。あと豆腐メンタルだから許して・・・・

【マケプレ版】WafcharmがAWSのマケプレにやってきた【WAF】

お久しぶりです。芋です。(`・ω・´)ゞ

今年も終わりが近づいてますね。

あと数日ですが、最後までがんばりましょう。

 

 

っで本題となりますが、ついにマケプレ版のWafcharmがリリースされましたので、

代理店版とマケプレ版との違いや、subscribe(free trial)の方法を書いてみます。

ちなみにマケプレ版でもトライアルが可能です。

 

■購入先のよる違い(メリット/デメリット含む)

【代理店版】

◯ メリット

  • マケプレ版よりも安い。
  • 為替の影響を受けない。

 

✕ デメリット

  • 以下マケプレ版のみの機能が使えない(2022/12/26時点)

 

マケプレ版】

◯ メリット

    詳細:https://docs.wafcharm.com/manual/web_monitoring_JA.pdf

  -DNS監視

    →DNSのレコードを1時間ごとにチェック(nslookup)

    →DNS不通であることの検知

  -改ざん検知

    →当該FQDNへ6時間毎にクローリングを実施。

    →マルウェア配布などの攻撃サイトへのURLが含まれる場合に検知

  -HTTPS接続チェック

    →当該FQDNへのHTTPS接続設定に、非推奨・危殆化の設定が含まれる場合等に検知

  • 請求がAWSの利用料金に含まれる。

    →請求処理がAWS分だけで済む。

 

✕ デメリット

  • 為替の影響がある。
  • 代理店版よりも若干高くなる

 

 

マケプレ版WafCharmの注意事項

※注意点※

マケプレ版の場合、IAMポリシーに「CloudWatchReadOnlyAccess」も追加する必要あり。

  https://www.wafcharm.com/jp/blog/aws-iam-setting-for-wafcharm-jp/

・free trialは30日

 

マケプレ版WafCharmの申し込み方法(subscribeの方法)

 

1.AWSアカウントにログイン後、以下のページにアクセス。

右上の Try for free ボタンをクリック。

AWS Marketplace: WafCharm for AWS MarketPlace

 



 

 

2.Offer type が Free trial になっているのを確認し、 右下の Create contract ボタンをクリック

 

3.Subscribe 完了。Set up your account を押して WafCharm アカウントのセットアップに進む

 

4.以下の画面からwafcharmのアカウント作成画面にリダイレクト

         

 

 

5.メール、パスワード設定し登録。

6.登録完了のメールがくるので、メール内容にある「確認する」をクリック。

 

【完了】

 

WafCharmのアカウント側の設定については、

「■マケプレ版WafCharmの注意事項」のポリシーの設定が必要なので忘れずに!

 

 

 

 

 

 

 

 

 

 

 

【DSルール解説】1010564 - Joomla Arbitrary File Upload Vulnerability (CVE-2020-23972)【CVE-2020-2397】

■ルール名
 1010564 - Joomla Arbitrary File Upload Vulnerability (CVE-2020-23972)

■ルールの説明

攻撃者はアプリケーションに認証せずにアプリケーションのアップロード機能にアクセスし、ファイルも起因してアップロードできる また 2倍の拡張 内部形式と名前ファイルを変更することによってバイパスされうる無制限のファイルアップロードの問題 。

翻訳微妙なんで原文記載

An attacker can access the upload function of the application without authenticating to the application and also can upload files due the issues of unrestricted file uploads which can be bypassed by changing the content-type and name file too double extensions.


脆弱性

(主な脆弱性対象(他にもありますが詳細はリンク参照))

Joomlaコンポーネント

GMapFPバージョンJ3.5とJ3.5free

 
(ソース)

https://www.tenable.com/cve/CVE-2020-23972


【CVE番号】 

CVE-2020-23972

 

■ルールにて設定できること。

無し


■推奨設定の検索対象か否か
対応
 

【芋的見解】

CMSなんで、Joomla使ってる環境かつ、対象のバージョンを使用している場合、

根本対処として、アップデートすることをおすすめします。

アカウントや権限に関する脆弱性ではないので、漏洩等のリスクは無いですが、

ディスクを枯渇させることもでき最悪SSHできないとか自体に陥ったりすると面倒なことになるかと。

 

【DSルール解説】1010562 - Mantis Bug Tracker 'verify.php' Remote Password Reset Vulnerability (CVE-2017-7615)【CVE-2017-7615】)

■ルール名
1010562 - Mantis Bug Tracker 'verify.php' Remote Password Reset Vulnerability (CVE-2017-7615)

■ルールの説明

Mantis Bug Trackerで、リモートパスワードリセットの脆弱性が報告されています。
この脆弱性は、パスワードのリセット要求を検証するときに、confirm_hashパラメーターの入力検証が不足しているために発生します。
リモートの認証されていない攻撃者は、影響を受けるページに細工されたHTTPリクエストを送信することにより、
この脆弱性を悪用する可能性があります。悪用に成功すると、攻撃者は任意のアカウントのパスワードを変更できるようになります。

脆弱性

(主な脆弱性対象(他にもありますが詳細はリンク参照))
 MantisBT には、任意のパスワードにリセットされ、認証されていない管理アクセスを実行される脆弱性が存在します。

対象バージョン

MantisBT 2.3.0 まで


(ソース)

https://jvndb.jvn.jp/ja/contents/2017/JVNDB-2017-003161.html


【CVE番号】 

CVE-2017-7615

 

■ルールにて設定できること。

無し


■推奨設定の検索対象か否か
対応
 

【芋的見解】

Mantis Bug Tracker自体は課題管理ツールであり、

主な用途としてはバグ管理。といったものの私自体は使ったことはないですが、

課題管理ツールですので、パブリックに公開している場合、本脆弱性の攻撃をうけるリスクが高いです。

最も内部向けでもユーザ管理を厳格に行っている場合はパブリックに出しているよりもリスクは低いと考えるが、バージョンアップなり恒久対応は必要。

 

 

 

 

【マルチクラウド】Trend Micro Cloud One がやってきた【御三家】

2020年6月予定ではあるものの、

Trend Micro Cloud One 4/1〜公開された模様。

って、タイトルとここまでの内容では何が起こったのかわからんので、

まとめるとこんな感じだ!

 

・Cloud Oneとは?クラウドの保護に必要な6つのセキュリティサービスで

 構成されるらしい。内容から見るとCloud向けセキュリティについて、

 Cloud Oneシリーズで色んな製品売っていきまっせーってこと。

https://www.trendmicro.com/ja_jp/about/press-release/2020/pr-20200324-01.html

 

・DeepSecurity as a Service から Workload Security に変更。(6/1〜)

 →統合管理画面からはすでにWorkload Security になってる。

 

・Cloud Oneの統合管理画面はすでに開始。

・DSaaSで新規アカウントを作るとCloud OneのURLで作られる。

 →旧URLにテナントIDつければ今まで通りのログイン画面がでる。

 

【Cloud One】

https://cloudone.trendmicro.com/SignIn.screen?confirmation={テナントid:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}

【今までのDSaaS】
https://app.deepsecurity.trendmicro.com/SignIn.screen?confirmation={テナントid:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}

 

 

簡単にではあるが、さっそくレビューだ。

 

統合管理画面とやらを見てみよう!

f:id:inamo:20200403154646p:plain

 

 

 

ほーん?( ・ὢ・ )

 

 

f:id:inamo:20200403154844p:plain

 

 

なるほど、ログインすると、

Cloud Oneシリーズのメニュー画面って感じね。

そしたらDSaaSこと Workload Security にインしてるお。

 

f:id:inamo:20200403155538p:plain

 

ちょと上部のメニューみたいなところが旧式と違う。

とはいえ機能面や操作面については従来どおりである。

 

旧式だとユーザー名をクリックしてログオフをしていたが、

どうやらWorkload Securityになってから右上のSign  outからやるようになったようだ。

 

気になるポイントがあった。

 ↓これ。

 

f:id:inamo:20200403161511p:plain

 

私の場合は、基本的にパートナー契約を結んでいるので問い合わせは、

この機能は使わないですが、気になったので紹介。

f:id:inamo:20200403161653p:plain

 

なんと、ケース作成ができるようになっている。

どういう条件下で使えるのか気になるところではある。

というのも、基本的にライセンスを買うときはパートナー契約を行っている会社経由、

または、AWSならマーケットプレイスサブスクリプションで契約するパターンとなる。(ほかになんかあったか忘れた)

 

前者のパートナー契約を結んでいる会社から買っている場合は、

その会社へ問い合わせる必要がある。

後者のAWSマーケットプレイスについては、専用の問い合わせようのメールアドレスがあるので、そこから問い合わせる必要がある認識だ。

ってことは、これってどういうときに使えるのだろうか?

 

若干疑問が残るところもあるので、引き続き調査していきたいと思います。

今回はここまでといことでぜひお試しあれ。

 

 

 

 

【DSルール解説】1005402 - Identified Suspicious User Agent In HTTP Request

■ルール名
 1005402 - Identified Suspicious User Agent In HTTP Request

 

■ルールの説明

これは、WebサーバーまたはWebアプリケーションのスキャンと攻撃に使用されるHTTP要求の疑わしいユーザーエージェントヘッダーを識別するヒューリスティックベースのルールです。

注:追加のユーザーエージェントとイベントのアラート頻度を構成するための構成オプションが提供されています。

 


脆弱性

ルール上の説明は以下の通り。

※以下ではWordPressと書いてますが、どちらかいうと特定のUser Agentを拒否するルール。デフォルトでは詳細情報記載のものが対象となります。

 

WordPressは、不特定のマルウェアによるブルートフォース攻撃を受けやすい傾向があります。

 

■詳細情報

ルール上の詳細情報では以下のように説明

 

このDPIルールは、次のユーザーエージェント文字列で着信要求をブロックします。
これらのユーザーエージェントは、さまざまなWebスキャナー、脆弱性スキャナー、または悪意のあるボットによって使用されます。
これらのユーザーエージェント文字列を含むHTTP要求は、Webサーバーでの攻撃またはスキャン試行と見なされます。

 

Havij, dirbuster, SQLninja, Zeus, HTTrack,
JOC Web Spider, |3C|img, |3C|script, DBrowse,
Digger, WinHttp.WinHttpRequest.5, masscan/,
Sucuri Integrity Monitor/, NESSUS::, ScanAlert;,
w3af.sourceforge.net, Netsparker, ZmEu,
SiteLockSpider, Jorgee, WebCopier

 

■ルールにて設定できること。

+20210103_追加情報

今までルール側で設定されているUAを除外などできず、

追加設定のみであったがルールのアップデートにより、

ユーザ側でルールのデフォルト設定にあるUAを除外することができるようなってます。

 

誤検知あるもので、7年前に発売された↓の機種の

かんたんインターネットとかいうブラウザのUAを検知してしまうことがあるので

適宜除外してもいいかも。

原因は「DBrowse」っていうおそらくBOTかな?が↓のUAの文字列に含まてしまっていることが原因。

調べた感じこのUAにはバージョンも含まれるようなので、

手動で「DBrowse 1.」「DBrowse 2.」なり入れるといいかと。

 

SimplifiedBrowser

F-02F (4.2.2)|NTTドコモ 端末・ブラウザスペック

 

 

 

Event Frequency:
Alert always
 →アラートを常に鳴らす。

Alert in every {指定秒数} seconds
 →指定秒数毎にアラート鳴らす。

nter suspicious User Agent string to be blocked (one string per line):
For e.g. “MSIE” to block web client traffic from Microsoft Internet Explorer

 →指定したUser Agentを検知することができる。

  部分一致でもできます。

 

※↑ではblockedで書いてますが、ルール自体の動作モードに準じるので検知と書いてます。

 


■推奨設定の検索対象か否か
非対応
必要に応じてユーザサイドで手動で適用する必要があります。

 

【芋的見解】

このルールは、HTTPリクエストヘッダ上のUser Agentにかかれている内容をチェックします。

 

使い方の例ですが、

マイナーなところのCrawlerのリクエストが邪魔な場合は、

このルール自体の動作モードを防御モードにしたうえで、

そのCrawlerのUser Agentをリストに加えDSで遮断してしまうのもあり。

 

あとは、OpenVASなどOSSのスキャンツールの簡易的な対策として、

リストに追加するのも一つです。

 

とはいえ、

攻撃することを前提にしたスキャンについては、ルールで対象のスキャンツールのUser Agentを検知するように設定したとしても、クライアント側で簡単に変更可能なものになりことから一時対処としては、一定の効果は見込めますが簡単に変更可能な情報ですので、過度な期待は禁物です。

 

検索サイト系のCrawlerであれば、User Agentの名前はそこまで変わらないと考えますので、こちらは有効的かと考えます。

 

 

 

 

 

 

 

 

 

 

 

 

ルール解説テンプレ(※タイトルは、【DSルール解説】{ルール名}【CVE番号※ある場合】)

■ルール名
 

■ルールの説明


脆弱性

(主な脆弱性対象(他にもありますが詳細はリンク参照))


 
(ソース)
【CVE番号】 

■ルールにて設定できること。


■推奨設定の検索対象か否か
非対応
必要に応じてユーザサイドで手動で適用する必要があります。

対応
 

【芋的見解】

 

【DSルール解説】1002751 - Disallowed Resources【CVE-2010-0425,CVE-2013-4824】

■ルール名

1002751 - Disallowed Resources

 

■ルールの説明

このDPIルールは、特定のWebサーバーリソースタイプへのアクセスを制限します。特定のリソースに対して例外を指定することもできます。
注:許可されていないリソースタイプと許可されたリソースを入力するための構成オプションが提供されています。

 

脆弱性

主な脆弱性対象(他にもありますが詳細はリンク参照)

CVE-2010-0425の脆弱性について

Apache HTTP Server 2.3.6 未満」が対象となります。

 

【CVE-2010-0425】

https://jvndb.jvn.jp/ja/contents/2010/JVNDB-2010-001159.html

【CVE-2013-4824】

https://jvndb.jvn.jp/ja/contents/2013/JVNDB-2013-004636.html

 

■ルールにて設定できること。

 

【Disallowed extensions】
→検知する拡張子を指定できる。
デフォルトでは、以下の通り。

.exe
.dll
.bak
.old
.tmp


【Explicitly Allowed resources: (resources that are allowed even if their extension is in the disallowed extensions set eg. login.dll)】
→上記ブロックする拡張子ではあるが、部分的に許可したい場合、ここで指定できます。
デフォルトでは、特に設定はないです。

例:login.dllについては、本ルールで検知しないようにしたい場合は、本項目に追加することで除外が可能。

 

【推奨設定の検索対象か否か】

非対応

必要に応じてユーザサイドで手動で適用する必要があります。

 

【芋的見解】

上記の脆弱性が無ければ不要とも言えますが、

不要なリクエストをApacheなどに到達させたくない場合は適用しても良いと考えます。