実際の攻防戦 | 某自動車会社突破の一部始終を記録

0x00 序文

この記事では、著者が攻撃と防御の訓練中に外部ネットワークから自動車会社のイントラネットに侵入した詳細なプロセスを紹介します（機密情報を保護するために、すべてのデータは匿名化されており、一部のスクリーンショットは不完全です、ご容赦ください）自分）。

このネットワーク攻撃および防御訓練は合計 14 日間の 2 つのフェーズに分かれており、最初の 7 日間はプライベートリソースフェーズ、最後の 7 日間はパブリックリソースプールフェーズとなります。計12チームが参加し、弊社から全行程に参加した選手は2名のみでした。会社が補助的なツールや人材を提供することは一切なく、最近では多くのコンテストに参加しているため、各コンテストの後はお互いに非常に内省的でした。

0x01 情報収集

審判はターゲット企業の名前だけをあげ、他の情報は自分たちで調べてくださいと言いましたが、リソースが乏しい私たちのチームにとっては試練でした。

幸いなことに、作成者は以前に情報収集用の一連の補助スクリプトを作成しており、これを大いに活用できるようになりました。

まず、子会社収集スクリプトを使用して、第 1 レベルの子会社を検索します。このスクリプトは、特定の基準とルールに基づいて、Tier 1 企業と 50% の所有関係を持つ子会社を検索します。次に、これらの第一層子会社に対してスクリプト検索を再度実行し、50% の所有関係にある子会社を見つけました。このプロセスは、適格な子会社がなくなるまでループし続けるため、以下に示すように、最も深い企業がレベル 4 の企業に達していることがわかります。

次に、資産収集スクリプトを使用して、補助収集スクリプトの ICP 結果に対して、サブドメイン名の照合、ポートスキャン、Web パス検索、サービス識別などの一連の操作を実行します。最終的な結果は次の 3 つになります。ファイルのうち、IP ファイルは情報収集のためにライトハウスに渡すことができ、URL ファイルは POC スキャナに渡すことができ、詳細ファイルは POC スキャナで見つからないいくつかの脆弱性を手動で検索できます (弱いパスワード、手動のドッグヘッドなど）POC をスキャンするとき。

0x02 Web管理

まず、POC スキャナー (Xray Youth Edition、POC-bomber などのオープンソース作品) を使用して資産収集結果をスキャンしましたが、悪用可能な脆弱性は見つかりませんでした (人員が少なく、会社が経営リソースを提供していないため)。どうすればいいですか？、犬の頭が命を救います）。

どの URL に驚きが含まれているかを 1 つずつ手動で分析する以外に方法はありません。

退屈なページをたくさんめくった後、ある URL に目を留めました。この URL のタイトルは XXConfluence です。

この Web サイトが Confluence を使用していることを知ったとき、多くのマスターは何をすべきかを知っていたと思います。すぐに RCE が存在するかどうかを確認したところ、いくつか試した結果、このバージョンには RCE が存在することがわかり、サーバーのオペレーティングシステムが Linux であることが確認されました。

次に、シェルをサーバーにバウンスしたところ、無制限のシェルアクセスを取得したことがわかりました。早速リモコン馬を作成し、対象サーバーにアップロードしました。MSF がオンラインになった後、ネットワークカードを確認したところ、サーバーのネットワークカードが 172.32.0.30 であることがわかり、プロキシツールをアップロードしました。

0x03 イントラネット情報収集

frp ツールを使用してイントラネットを公開した後、172.32.0.0/24 ネットワークセグメントに正常にアクセスできました。

次に、私とチームメイトは正式なイントラネット情報収集作業を開始しました。

いつものように、fscan ツールを使用してスキャンし、脆弱なパスワードや悪用可能な脆弱性が見つかるかどうかを確認します。これにより、攻撃がよりスムーズになります。しかし、スキャン結果は残念で、ネットワークセグメント 32 には悪用可能な脆弱性はありませんでした。仕方なく、fscan を使用して 172.16 から 172.31 までのネットワークセグメントのスキャンを続け、何かを得ることを期待しましたが、スキャンしすぎるとアラームがトリガーされるのではないかと心配したため、慎重に作業を進めました。幸いなことに、セクション 172.16 をスキャンしているときに、F5 BIG-IP ファイルのアップロードの脆弱性を発見しました。

この脆弱性が本当に存在するかどうかを確認するために、テスト用の URL を作成したところ、正常に実行され、エコーされることがわかりました。密かにうれしかったです、遊ぶことができました！

https://172.16.0.11/tmui/login.jsp/..;/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd

次の手順は比較的簡単になり、リバウンドシェルコードを F5 サーバーにアップロードし、ローカル NC モニタを通じて実行しました。このようにして、F5 サーバーのリバウンドシェルを取得することに成功し、このサーバーに root 権限があることがわかりました。これは、このサーバーに関するより多くの情報を収集し、攻撃対象領域を拡大できることを意味します。

このサーバーの脆弱性をさらに調査するために、キーなしで SSH 経由で他のサーバーにログインできるかどうかをテストし、過去のコマンド記録といくつかの実行中のサービスを確認しましたが、貴重な情報は見つかりませんでした。その後、このサーバーは主に Java プログラムを多数実行しているので、設定ファイルから突破口を見つけられないかと、設定ファイル検索コマンドを使用しました。

find / -name "*.properties" -o -name "*.yaml" > ret.txt

複数のファイルを慎重に検索した結果、最終的に、base_config.yaml というファイルで Redis と MySQL のパスワードを見つけました。ただし、これらのサービスにログインしようとしたところ、機密データは見つかりませんでした。そして、最新のデータは 2022 年までしか更新されていません (このスクリーンショットのパスワードは作成者によってランダムに生成されましたが、元のパスワードと同じ長さです)。

やめようかなぁと思っていたところ、ふと思いついて、RedisとMySQLのパスワードが同じだからSSHのパスワードも同じなのかな？早速Xshellツールを使って接続してみたところ、なんと接続に成功しました！次に、他のサーバーでも同じパスワードが使用されるのではないかと考え始めました。イントラネットでは、多くの管理者がパスワードが十分強力であると考えているため、他のサービスでも同じパスワードを再利用するからです。

ここでは、fscan でスキャンした 172B セグメントサーバーの IP をリストにまとめ、パスワードのブラストにはブラストツールを使用します。最終的に、47 台のサーバーのパスワードを解読することに成功しました。Xshell を使用して手動でログインする場合、アセットの数が多いと、指が疲れることを認めざるを得ません (手動の犬の頭)。WeChat の侵入通信グループに hackctf55 を追加します。

以下はサーバーへのログイン成功です。

0x04 論理的分離の突破

Xshell を使用して手動でログインしていたときに、チームメイトから素晴らしいメッセージを受け取りました。172.32.0.81 にログインしようとしたところ、サーバーに複数のネットワークカードが搭載されていることがわかりました。

また、過去のコマンドでは、管理者がトラフィックを 10.54.0.0/19 ネットワークセグメントに転送するためにサーバーにソフトルートを追加したことがわかりました。

私たちはすぐに、10.54.0.0/19 ネットワークセグメント上のリソースにアクセスできるように、172.32.0.81 にプロキシを構築することにしました。

準備作業を完了した後、fscan を使用して 10.54.0.0/19 ネットワークセグメントをスキャンしたところ、MySQL データベースの脆弱なパスワードが見つかりました。

[+] mysql:10.54.15.233:3306:root P@ssw0rd

このデータベースでは、基本的な構成ファイル、車両のインターネット情報、自動車登録ファイル情報などを含むいくつかの機密データが見つかりました。特に、基本構成ファイルには、さまざまなサービスアカウントとパスワード、nacos 構成、クラウドサービスの SecretId および SecretKey などの機密データが含まれています。

0x05 クラウドイントラネットの浸透

クラウドサービスの SecretId と SecretKey を取得したので、さらなる検出のためにクラウド侵入アーティファクトである CF を使用します。AK を構成すると、アクセス許可が管理者アクセス許可であることがわかります。

次にサブアカウントを作成してコンソールを引き継ぎ、
コンソールにログインするとクラウドサーバーが64台、mysqlクラウドデータベースが13台、オブジェクトストレージが3TB、vpcネットワークが17台などの情報が確認できました。

これら 64 台のサーバーは、cf でコマンドを実行するときに root 権限を持ちます。

さらに、Shenxian のチームメイトは、保管バケットから数万人の連絡先情報、自宅の住所、運転免許証、ID カードの表と裏の写真、ナンバープレート番号などの非常に機密性の高い情報も発見しました。WeChat の侵入通信グループに hackctf55 を追加します。

このようにして、基本的に浸透は完了しており、物理サーバー 48 台とクラウドサーバー 64 台、および大量の設定ファイルデータ、開発環境設定、および大量の顧客機密データを使用して、スコアはオンラインをはるかに上回りました。スコア。

0x06 概要

クリーンアップの痕跡に注意してください: チームメイトと私はスコアが下がっているのを確認した後、他のアセットへの侵入を続けました。痕跡をクリーンアップするのに時間内にスプリングマシンに行くことができませんでした。その結果、ユニットは; 出所を突き止めて無事復活しましたが、それに応じて減点も受けてしまい、大きな損失となりました。
イントラネットが水平に実行されている場合、速度を上げる必要があります。特にセキュリティサービスを備えた Win ホストの場合、一般にアラームが遅延しますが、遅延はわずか 2 時間、4 時間、6 時間などである可能性があるため、資産を転送する必要があります。できるだけ早く、明確に整理して、より多くのパスポイントを獲得してください。
攻撃プロセスを要約すると:
外部ネットワーク上の Confluence アプリケーション RCE --> 内部ネットワーク上の F5 アプリケーション RCE --> F5 サーバー構成ファイルからデータベースパスワードを取得 -> データベースパスワードを SSH にパスワードブラスト -> サーバーのブラストに成功論理的に分離された 10 個のネットワークセグメントが履歴レコードで検出されました --> データベースの脆弱なパスワードを見つけます --> データベースの nacos 構成からクラウドサービスの管理者権限を持つ AK と SK を取得します --> コアビジネスイントラネットにアクセスします - -> コアデータを見つける;
さらにパスワードスプレーを試してみると、予期しない結果が生じる可能性があります。
従来の技術的手段でターゲットの脆弱性を攻撃するのはもはや容易ではないため、将来的には、ターゲットの機密情報を取得するためにソーシャルエンジニアリングフィッシング手法をさらに活用する予定です。

- 終わり -