目次
- 初めに
- SplunkBOSSoftheSOCとは
- 蛇足
- Netis製ルータ53413番ポート
- ApacheLog4j8089番ポート
- MemcachedDDoS攻撃11211番ポート
- 5000番ポート
初めに
ログ分析の授業の一環でbotv1のログを3人チーム調べて報告書を作成しました。
最後の授業で企業の方に見せて結構褒めてもらいました。(多分お世辞)
せっかくなのでQiitaの記事にしときます。誰でもいいので一人でもこの記事が役に立ったと思ってもらえれば本望です。
担任の先生とチームメンバーには許可を取って載せています。先生、チームメンバーのみんなありがとう！
また、Qiita記事では私が担当した資料のみを載せますが、GitHubに本番用の資料を置いておきます。
GitHubの資料にはチームメンバーが作成した資料も含まれているので、よければご覧ください。
SplunkBOSSoftheSOCとは
Splunk BOSS of the SOC BOTSは、Splunkが主催するセキュリティ運用センター(SOC)向けのハンズオン競技イベントです。これは、サイバーセキュリティの専門家や初心者が、実際のSOC業務に関連する課題を解決することでスキルを向上させることを目的としています。
BOSS of the SOCの特徴
- CTF（Capture The Flag）形式の競技
- 参加者は、Splunkを活用してインシデント調査や脅威ハンティングを行い、問題を解決します。
- 各課題にはフラグ（正解）があり、正しい回答を提出するとポイントを獲得します。- 実際のSOC業務を模擬したシナリオ
- マルウェア感染の調査
- フィッシング攻撃の分析
- 不審なネットワークトラフィックの検出
- 内部不正行為の特定
など、実際のセキュリティインシデントを想定した問題が出題されます。- Splunkの活用スキルを向上できる
- Splunk Search Processing Language SPLを使ったログ分析の練習ができる。
- SOCアナリストとして必要なスキル（インシデント対応、脅威ハンティングなど）を実践的に学べる。
- 個人またはチームで参加可能
- SOCの実務担当者、セキュリティエンジニア、初心者など、さまざまなレベルの参加者が楽しめる。
- 競技形式で楽しみながら学べるため、セキュリティ教育にも適している。
開催情報
Splunk BOTSは、Splunk主催のカンファレンス（.confやSplunkLive!）などで定期的に開催されます。企業向けにカスタマイズされたBOTSイベントもあります。
もし参加を検討している場合は、最新の開催情報を公式サイトで確認すると良いでしょう！
↑全部ChatGPTに聞きました。BOTSの概要が分かる日本語サイトなかったので...
大きく間違ったことも言ってなさそうなので大丈夫だと思います。
一応参考になりそうなサイトも載せておきます。
Splunk BOSS of the SOCについて（その１ 概要とreconnaissance） #Security - Qiita
蛇足
Obsidianで書い報告書をPDFと出力して発表しました。PDF出力もめちゃくちゃ綺麗にできるので、GoogleドキュメントやWordなどを文書のPDFに使っている方は是非Obsidianを使ってみてください！！！
何個かObsidianのチュートリアルになるような記事を書いているのでリンクを貼っておきます。
Obsidianとマークダウン記法を使い快適なメモ生活を！ #初心者 - Qiita
Obsidianをプラグインでもっと便利に！ #初心者 - Qiita
コードブロックでサポートされているPrism.jsについて #JavaScript - Qiita
また、GitHubに置いてあるような見た目のPDFの出力はできないと思います。
CSSスニペットを変更したり、Code Stylerというプラグインをかなりいじっているからです。見出しのh1、h2、h3ごとに色を変えるCSSとかめちゃくちゃ便利でおすすめです。
テーマをデフォルトから変えると、重くなったり挙動がおかしくなるので、自力でCSSを書いた方がいいと思います。
Netis製ルータ53413番ポート
脆弱性についての説明
Netis製(中国製)のルータに関する脆弱性を発見した。
デフォルトで UDP の 53413ポートが開放されています。
このポートはパスワードで保護されていますが、すべての製品で共通であり、パスワードを入手すれば誰でも簡単に不正アクセスが可能になります。
本ブログでも既報の通り、「Netis」は中国国内で人気のネットワーク機器メーカ「Netcore」社の中国国外向けのブランド名です。ほとんどの Netis製ルータにはデフォルトで UDP の 53413ポートが開放されており、WAN側から接続可能になっています。この 53413ポートはファームウェア上でハードコードされた単体のパスワードで「保護」されていますが、それこそが脆弱性の本体です。すでにこのパスワードは明らかになっており、パスワードを入手した人物は誰でも外部から Netis製ルータに接続し不正アクセスが可能です。JPCERT／CC によれば、この 6月に観測された日本における 53413ポートへの通信増加は、まさにこのルータの脆弱性を狙い遠隔操作のためのボットを感染させる目的の攻撃であったようです。
インターネット定点観測レポート(2015年 10～12月)
ルータの脆弱性を狙う通信の増加をJPCERT/CCが報告 |
source_typeごとの件数を調べる
index=botsv1 dest_port=53413
| stats count by sourcetype
| sort -count
実行結果
fortigate_trafficのactionフィールドを調べる
actionフィールドを見ることでリクエストが拒否されたかどうかがわかる。
よってsourcetype=fortigate_trafficであるログの数とaction=blockedの数が同じであればすべてのリクエストが拒否されていることがわかる。
実行したSPL
index=botsv1 dest_port=53413 sourcetype=fortigate_traffic
index=botsv1 dest_port=53413 sourcetype=fortigate_traffic action=blocked
実行結果
source_typeがfortigate_trafficであるログはすべてactionがblockedである。
よってsource_typeがfortigate_trafficのログに関しては、53413番ポートに対する攻撃は防がれていることが分かる。
suricataのログを調べる
実行したSPL
index=botsv1 dest_port=53413 sourcetype=suricata
上記のSPLでログが2件合致し、日付は2016/8/11と2016/8/25でした。
- 2016/8/11のログ
{"timestamp":"2016-08-10T15:58:23.791919-0600","flow_id":3724372038,"in_iface":"eth1","event_type":"dns","src_ip":"8.8.8.8","src_port":53,"dest_ip":"192.168.250.20","dest_port":53413,"proto":"UDP","dns":{"type":"answer","id":41232,"rcode":"NOERROR","rrname":"55.58.203.23.in-addr.arpa","rrtype":"PTR","ttl":18660,"rdata":"a23-203-58-55.deploy.static.akamaitechnologies.com"}}
src_ip: 8.8.8.8やsrc_port: 53とあります。
このIPアドレスとポート番号からGoogle Public DNSサーバーからクエリを送っていることがわかります。
rcode: "NOERROR":やrrname: "55.58.203.23.in-addr.arpa":とあります。
これらからリバースDNSクエリ(IPアドレスからホスト名を引く)であり、対象のIPアドレスは 23.203.58.55である。
rdata: "a23-203-58-55.deploy.static.akamaitechnologies.com"
rdata(Resource Data)は、DNS(Domain Name System)でリソースレコード(RR: Resource Record)のデータ部分を指します。
rdataの内容からIPアドレス23.203.58.55の逆引きを行い、それがAkamaiの静的コンテンツ配信サーバーであることがわかりました。
Akamai Technologiesは、世界的なCDNのリーダー企業でありWAFなどを提供しています。
これらの要素からAkamaiの静的コンテンツ配信サーバーに対する正常な通信であると思われます。
- 2016/8/25のログ
{"timestamp":"2016-08-24T10:49:57.043008-0600","flow_id":3724372038,"in_iface":"eth1","event_type":"dns","src_ip":"8.8.8.8","src_port":53,"dest_ip":"192.168.250.20","dest_port":53413,"proto":"UDP","dns":{"type":"answer","id":6010,"rcode":"NOERROR","rrname":"147.24.93.85.in-addr.arpa","rrtype":"PTR","ttl":21599,"rdata":"dashmallicy.xyz"}}
8/11のログと同じくsrc_ip: 8.8.8.8やsrc_port: 53とあり、Google Public DNSサーバーからクエリを送っていることがわかります。
rrname: "147.24.93.85.in-addr.arpa":
とあるので、リバースDNSクエリ(IPアドレスからホスト名を引く)で対象のIPアドレスは85.93.24.147であることがわかります。
rdata: "dashmallicy.xyz":
なのでIPアドレス 85.93.24.147 のP逆引きレコードに対応するホスト名です。
このドメイン"dashmallicy.xyz"をVirusTotal - Homeで調べてみた結果危険だという報告はありませんでした。
サイバーキルチェーン
ここまでの情報から、ポートスキャンを行っており、サイバーキルチェーンの偵察段階のログであることが分かります。
対策
このメーカーのルータにしかない脆弱性なので別製品に乗り換える。
ポートフィルタリングの設定を見直す。
ApacheLog4j8089番ポート
実行したSPL
1つ目と同様に、宛先ポートが怪しいログを調べ8089番に辿り着いた。
下記のSPLで一意にログを特定できました。
index=botsv1 src_port=61746 dest_port=8089 flow_id=948947464
{"timestamp":"2016-08-28T12:00:37.000085-0600","flow_id":948947464,"event_type":"flow","src_ip":"192.168.225.173","src_port":61746,"dest_ip":"192.168.224.33","dest_port":8089,"proto":"TCP","app_proto":"tls","flow":{"pkts_toserver":20,"pkts_toclient":20,"bytes_toserver":3604,"bytes_toclient":6198,"start":"2016-08-28T12:00:37.504637-0600","end":"2016-08-28T12:00:37.525520-0600","age":28,"state":"closed","reason":"timeout"},"tcp":{"tcp_flags":"1f","tcp_flags_ts":"1f","tcp_flags_tc":"1b","syn":true,"fin":true,"rst":true,"psh":true,"ack":true,"state":"closed"}}
脆弱性についての説明
宛先ポート番号が8089であるログが多くあり、不審な点が見つかった。
ポート8089について参考記事
検証用AWSアカウントでGuardDutyと闘う話 〜不用意にポート開けるな編〜 #EC2 - Qiita
【セキュリティ ニュース】「Log4Shell」攻撃、対象ポートが拡大中 - 警察庁観測（1ページ目 / 全1ページ）：Security NEXT
8089ポートに関連する脆弱性がないか調べてみたところ、「CVE-2021-44228」や「CVE-2021-45046」が見つかった。
この脆弱性は「Apache Log4j」により、リモート攻撃が可能となるものである。
Log4jはApacheソフトウェア財団のプロジェクトである「Apache Logging」で開発されたオープンソースソフトウェアの1つであり、Javaで開発したプログラムに対してログを記録・出力するための機能を提供します。
Apache Log4jについて参考記事
Apache Log4jに見つかった脆弱性「Log4Shell」とは | ドコモビジネス | NTTコミュニケーションズ 法人のお客さま
初心者でも分かるLog4jとその脆弱性、影響範囲から対策方法のすべて - ペンタPRO：ペンタセキュリティが提供するセキュリティ情報まとめサイト
攻撃の仕組み
- 攻撃者は脆弱性を利用できるようにするため、特殊な文字列を含ませたhttpリクエスト（データ）をサーバに送信する
- サーバに脆弱性がある場合、Javaアプリケーションは送られてきたデータを処理した結果を、そのままログに書き込んでしまう
- ログに書き込まれたデータに特殊な変数が含まれていると、JDNI Lookup機能がそれを実行してしまう
- Log4j が、ダウンロードした悪意のあるプログラムを読み込み、実行してしまう
この文字列がログに書き込まれ、JNDI Lookup機能により実行された場合、アクセスを受けたLDAPサーバ（ldap://xxxxx.com/a）は、悪意のあるJava ClassファイルのURLを応答します。するとLog4jは、応答されたURLに配置されている悪意のあるJava Classファイルをダウンロード、メモリ内に読み込み実行してしまうというわけです。
初心者でも分かるLog4jとその脆弱性、影響範囲から対策方法のすべて - ペンタPRO：ペンタセキュリティが提供するセキュリティ情報まとめサイト
Log4jに見つかった深刻な脆弱性であるLog4Shellを利用すれば、任意のコードをリモートで実行する、RCE（Remote Code Execution：リモートコード実行）が可能です。背景にあるのはLookupと呼ばれる機能やJNDI（Java Naming and Directory Interface）と呼ばれる仕組みの処理にある問題で、攻撃者が送信した文字列をLog4jがログとして記録すると、その文字列に記述された通信先やサーバー内部のファイルからjava classファイルと呼ばれるファイルを読み込んで実行してしまうというものです。
Apache Log4jに見つかった脆弱性「Log4Shell」とは | ドコモビジネス | NTTコミュニケーションズ 法人のお客さま
TCPのフラグについて
先程示したログのフィールドにtcp_flags:1f(0001.1111)というものがあります。これはTCPヘッダのフラグを示すものです。
| 10ビット目 | 9ビット目 | 8ビット目 | 7ビット目 | 6ビット目 |
|---|---|---|---|---|
| Reserved | Accurate ECN | Congestion | ECN-Echo | Urgent |
| 5ビット目 | 4ビット目 | 3ビット目 | 2ビット目 | 1ビット目 |
|---|---|---|---|---|
| Acknowledgment | Push | Reset | SYN | FIN |
- tcp_flags:1f(0001.1111)がどういう意味なのか
| 立っていたフラグ | 説明 |
|---|---|
| FIN(Finish) | 接続の終了を要求するフラグ。通信を終了する際に使用される。 |
| SYN(Synchronize) | 接続の確立を要求するフラグ。シーケンス番号の同期に使用。 |
| RST(Reset) | 接続をリセットするフラグ。異常な接続やエラー時に使用。 |
| PSH(Push) | 即座にデータを受信側にプッシュすることを要求するフラグ。 |
| ACK | データの受信確認を行うフラグ。 |
FIN、SYN、RSTが同時に立っているのは明らかにおかしいと感じたのでさらに調べるとクリスマスツリー攻撃であることが分かりました。
※クリスマスツリー攻撃とは
TCPパケットの複数のフラグがオンになった異常ものを送り込むことで、プロトコルを適切に処理できないデバイスやコンフィグレーションに対して予期しない動作を誘発することが可能
サイバーキルチェーン
ここまでの情報から、サイバーキルチェーンの偵察段階のログであることが分かります。
対策
- Apache Log4j
最新版へアップデートを行いましょう。
バージョンアップしない場合の具体的な対策方法については、JPCERT/CCのページをご覧ください。
参考:
Apache Log4j の脆弱性対策について(CVE-2021-44228) | アーカイブ | IPA 独立行政法人 情報処理推進機構
「Log4j」の脆弱性とは？ リスクや対策など | 株式会社 日立ソリューションズ・クリエイト
Apache Log4jの任意のコード実行の脆弱性（CVE-2021-44228）に関する注意喚起
- クリスマスツリー攻撃
ファイアウォールの設定を見直し、適切なポートフィルタリングを行う
MemcachedDDoS攻撃11211番ポート
脆弱性についての説明
引き続き特定のポートに問題がないか調べると、11211番ポートに関連した製品の深刻な脆弱性を発見しました。
Memcachedサーバの脆弱性を利用したDDoS攻撃です。
Memcached とは？
Memcached は、オープンソースの高性能分散型のメモリー／データベースキャッシュシステムです。多くの場合にキー値を使用し、アクセスの多いデータをメモリーにキャッシュすることで、動的な Web サイトや Web アプリケーションを高速化します。Memcached は、Facebook、Twitter、YouTube などの企業で広く使用されています。UDP もサポートされ、 攻撃ベクトルに利用される大きな要因となっています。
攻撃の仕組み
memcached攻撃は次の4つのステップで発生します：
1.攻撃者は公開されたmemcachedサーバーにデータの大きなペイロード*を埋め込みます。
2.次に、攻撃者は標的となる被害者のIPアドレスで HTTP GETリクエストを偽装します。
3.リクエストを受信する脆弱なmemcachedサーバーは、応答することで役立てようとしているため、標的に大量の応答を送信します。
4.標的のサーバーまたはその周囲のインフラストラクチャは、memcachedサーバーから送信された大量のデータを処理できないため、正当なリクエストに対する過負荷とサービス拒否が発生します。
実行したSPL
- ポート番号だけで絞り込み
index=botsv1 dstport=11211
| sort _time
- DDos攻撃が疑われるので、1分以内に10件以上のトラフィックが存在するログを絞り込む
index=botsv1
dstport=11211
| bin _time span=1m
| stats count by _time, srcip, dstip, srcport, dstport
| where count > 10
実行結果
それぞれの実行結果を見てみると、どちらも623件です。
通信を試みたログが短時間に集中していることがわかります。
index=botsv1 dstport=11211 action=blocked
| sort _time
623件であり、すべて防がれていることがわかります。
サイバーキルチェーン
Memcached DDoS 攻撃を行うための準備としてポートスキャンを行っており、サイバーキルチェーンでは偵察段階に当たります。
対策
不要なポートである場合は閉じる。
- Memcached DDoS の直接のターゲット: この種の攻撃には、クラウド型の DDoS 対策を活用します。増幅係数が高く、オープンな Memcached サーバーが多いことから、データセンターのローカルな対策では、キャパシティの問題が生じる可能性があります。
5000番ポート
脆弱性についての説明
Windows XPでUPnPの実装に問題があり、UPnPサービスの脆弱性を突くものです。
5000番ポートはそのようなポート番号の一つで、いくつかの用途に用いられる。よく知られる用途の一つとして、コンピュータからネットワーク上の機器の検知や設定を行うためのUPnP（Universal Plug and Play）で用いられるプロトコルの一つであるSSDP（Simple Service Discovery Protocol）が利用していた。
コンピュータが周辺機器からのイベント通知を受け付けるポート番号としてTCPの5000番が用いられ、Windows XPではUPnPの実装に問題があったため5000番ポートが攻撃の標的となった。現在ではこの用途（SSDP Event Notification）はTCPの2869番が標準のポートとされる。
5000番ポート（ポート5000 / TCP5000番）とは - IT用語辞典 e-Words
TCP 5000番ポートへのアクセスが急増，原因は2種類の新種ワーム | 日経クロステック（xTECH）
また、Docker Remote APIやWebサーバー、カスタムサービスで使用されることが多く、特にFlaskサーバのポートとしてよく使われる。
認証が構成されていないDocker APIの場合、コンテナを自由に操作されるリスクがあり危険です。
Flask（フラスク）は、プログラミング言語Python用の、軽量なウェブアプリケーションフレームワークである
sourcetypeごとの件数を調べる
index=botsv1 dest_port=5000
| stats count by sourcetype
| sort -count
上記のSPLで検出されるログは、suricataが5件、stream:tcpが5件、fortigate_trafficが223件ありました。
suricataのログを調べる
index=botsv1 dest_port=5000 sourcetype=suricata
| sort time
suricataでのログは5件であり、5件のログのフィールドについて調べたものを表にしてまとめました。
| ログ番号 | 宛先IP | 応答 | 状態 | 終了理由 | 送信バイト数 | 受信バイト数 |
|---|---|---|---|---|---|---|
| 1 | 192.168.250.70 | なし | syn_sent | timeout | 124 | 0 |
| 2 | 192.168.250.70 | なし | syn_sent | timeout | 124 | 0 |
| 3 | 192.168.250.70 | なし | syn_sent | timeout | 124 | 0 |
| 4 | 192.168.250.41 | あり | closed | timeout | 124 | 120 |
| 5 | 192.168.250.40 | あり | closed | timeout | 124 | 120 |
1つ目~3つ目はsyn_sent状態なのでSYNを受信済みであることが分かります。
4つ目、5つ目のログではSYN,ACK,RSTのフラグが立っておりclosed状態なのでコネクション確立段階でないことが分かります。
stream:tcpのログを調べる
index=botsv1 dest_port=5000 sourcetype=stream:tcp
| sort time
| ログ番号 | 接続先 | 状態 (tcp_status) | 拒否 (refused) | 処理時間 (ms) | 送信バイト | 受信バイト | 接続 |
|---|---|---|---|---|---|---|---|
| 1 | 192.168.250.40:5000 | 拒否 (1) | 1 | 6 | 60 | 124 | 拒否 |
| 2 | 192.168.250.41:5000 | 拒否 (1) | 1 | 237 | 60 | 124 | 拒否 |
| 3 | 192.168.250.70:5000 | 成功 (2) | 0 | 1 | 0 | 124 | 成功 |
| 4 | 192.168.250.70:5000 | 成功 (2) | 0 | 5 | 0 | 124 | 成功 |
| 5 | 192.168.250.70:5000 | 成功 (2) | 0 | 2 | 0 | 124 | 成功 |
それぞれのログを表にまとめると上記のようになりました。
また、3~4つ目のログでは接続が成功しているので更なる調査が必要だと思われます。
fortigate_trafficのactionフィールドを調べる
index=botsv1 dest_port=5000 sourcetype=fortigate_traffic
上記のSPLで233件のログが検出された
index=botsv1 dest_port=5000 sourcetype=fortigate_traffic action=blocked
先程のSPLで検出された通信が成功していないログがどれだけの数なのかを調べると、sourcetype=fortigate_trafficであるログはすべてaction=blockedであった。
よって通信は成功していなことが分かります。
サイバーキルチェーン
ここまでの情報から、サイバーキルチェーンの偵察段階のログであることが分かります。
対策
UPnPを使う場合は2869番ポートを使う。
ポートフィルタリングの設定を見直す。