Jump to content

0x00長い探査

いつか、問題が見つかるかどうかを確認するために、特定の病院の情報システムのセキュリティテストを求めるタスクを受け取りました。予備情報収集の後、病院には公式ウェブサイトがなく、予約登録や支払いなどの機能が1つのWeChat公式アカウントのみが提供されていることがわかりました。ブレークスルーポイントは、この公式アカウントにのみ配置できるようです。

次の写真は、WeChatの公式アカウントのいくつかの機能を示しています。

1049983-20220112164840590-783996251.png

これらの関数をクリックしてパケットをキャッチしたとき、すべてのリクエストがドメイン名A.Test.comを指していることがわかりました。下の図に示すように、私の厚いコードを許してください.

1049983-20220112164841038-485934289.png

ドメイン名Test.comを検索した後、医療情報システムを提供する地元企業であることがわかりましたが、なぜ病院システムがサプライヤー会社に配置されているのだろうか?データはどのように同期しますか?これらの質問を使用して、ドメイン名a.test.comのテストを開始しました。

1049983-20220112164841437-906211697.png

このおなじみのページを見た後、このシステムはおそらくSing Bootによって開発されたことを確認しました。一連の通常の操作の後、私はswagger-uiページのみを見つけました。

1049983-20220112164841858-2061849480.png

私たちの目標は権限を取得することであるため、SQLインジェクションやオーバーライドの権利などのこのページのインターフェイスのテストに焦点を当てましたが、実りがなく、ファイルアップロードインターフェイスがなかったため、ここで立ち往生し始めました。

振り返ってみると、ドメイン名a.test.comはtest.comのサブドメインです。 test.comを通じて作成できますか?

Test.comにアクセスして、サプライヤー会社の公式ウェブサイトを開きます。

1049983-20220112164842400-1344011349.png

test.comのドメイン名に関する情報を収集した後、いくつかのサブドメインが特定のクラウドサーバーに解決されたが、IPは異なっていたことがわかりました。

1049983-20220112164842860-1821105685.png

まず第一に、ドメイン名git.test.comが私の注意を引きました。それを開いた後、それはgitlabサービスでした。

1049983-20220112164843265-832755396.png

Gitlabは歴史的にいくつかの脆弱性で構成されてきました。

1049983-20220112164843614-1636856631.png

残念ながら、このシステムバージョンは比較的高く、すべての脆弱性が固定されています。

パスワードが弱いですか?私はいくつかの一般的に使用されているユーザー名とトップパスワードを使用してそれを爆破しましたが、それは実りがありませんでした。また、この会社のQQグループに追加する方法を見つけ、グループファイルで有効な情報を取得しようとしました。

1049983-20220112164844031-1024609151.png

予想通り、従業員の詳細情報を記録するフォームがグループファイルにあります

1049983-20220112164844394-235393612.png

1049983-20220112164844922-1399525302.png

この情報を使用して、名前と作業番号を使用してGitLabユーザー名に組み合わせて、一般的に使用される弱いパスワードを使用して爆発を標的にしました。私は1つか2つの結果が得られることを望んでいましたが、それはまだ実りがありませんでした。このgitlabにはパスワード強度の要件があり、パスワードが弱いようです。

0x01 liu'an huaming yeyi村

Google Hack Syntaxを使用してこのgitlabを検索すると、認証なしでアクセスできるいくつかの公開リポジトリが見つかりました。

1049983-20220112164845620-264853675.png

私はこれらの公開されている倉庫に希望を固定し始めました。これらの倉庫を慎重に見ると、それらのほとんどはインターフェイスドキュメントでしたが、この侵入には役に立ちませんでした。

最後に、rabbitmqインストール紹介文でOracleデータベースの接続ユーザー名とパスワードを見つけました。

1049983-20220112164846054-1459380126.png

以前の情報収集プロセス中に、サブドメインX.Test.comに対応するIPアドレスがOracleデータベースポートを開設したことがわかりました。このデータベースにすばやく接続して、ユーザー名とパスワードが正しく、接続できることがわかりました。

1049983-20220112164846474-1421207616.png

このデータベースバージョンは低く、SYSDBAアクセス許可は時間内にあるため、システム許可を使用してコマンドを直接実行できます。

1049983-20220112164846885-2131820977.png

次に、ユーザーを追加してログインし、Oracleデータベースを取得するサーバーを取得します。

1049983-20220112164847424-1193239882.png

MySQL構成ファイルは、このMySQLフォルダーで見つかりました。

1049983-20220112164847825-778890118.png

Server Test.comはMySQLデータベースを開き、この情報を使用しているため、MySQLデータベースに正常にログインしました。

1049983-20220112164848208-457276327.png

サプライヤーの公式Webサイトtest.comのバックエンドのユーザー名とパスワードは、MySQLデータベースで正常に取得されました。

1049983-20220112164848595-830344145.png

Joyでログインしに行ったとき、ログインできることがわかりましたが、ログイン後の背景関数はすべて放棄され、大きなThinkPhpエラーは1つだけでした。

1049983-20220112164849141-1723696813.png

何をするか?バックグラウンドゲッシェルを使用するというアイデアも失われました。 (Thinkphp3を使用してエクスプロイトも試みましたが、すべて失敗しました)

0x02絶望的な状況での生存

この時点で、私はこのMySQLデータベースにのみ希望を置くことができると思います。 Windowsシステムであるため、UDFパワーアップグレードは成功しない可能性が高いため、Webシェルを作成しようとすることしかできません。ウェブシェルを書くときは、絶対的なパスを知る必要があります。さまざまな方法を使用してtest.comにエラーを報告して、エラーメッセージに含まれる絶対パスがあるかどうかを確認しようとしました。一連の操作には結果がなく、404ページしかありません。

他の方法はありません、私は盲目的に推測することができます。 MySQLデータベーステーブルのテーブル名がWebサイトのディレクトリ名であるかどうかを突然考えましたか?

1049983-20220112164849575-2056083891.png

これらの2つのテーブル名を使用して、次の絶対パスを構築します

c: \\ hs_web

C: \\ hsweb

d: \\ hs_web

d: \\ hsweb c: \\ hs_webを試みると、ウェブシェルは書き込みが正常に行われたことを促します。

1049983-20220112164850211-435914576.png

アリの剣に正常に接続する:

1049983-20220112164850803-556108064.png

現在のユーザー許可は小さいため、ジャガイモを使用して許可が正常に提起されます。

1049983-20220112164851255-1871097223.png

ユーザーを追加して、リモートデスクトップに正常にログインします。

1049983-20220112164851816-949297729.png

数十の病院が関与するサーバー上のnginx構成ファイルでプロキシルールが見つかりました。

1049983-20220112164852341-1272237723.png

これらの病院のWECHAT公式アカウントビジネスは、最初にTest.comサーバーにアクセスし、次にこのサーバーのNginxから各病院の実際のサーバーに転送することがわかります。その後、これはあまりにも安全ではありません。サプライヤーのサーバーがダウンすると、ビジネスも失われます。

次に、WeChatの公式アカウントバックエンドソースコードがこのサーバーで見つかり、監査のためにコンパニオンに投げられました。バックエンドログインバイパスの脆弱性を発見した後、バックグラウンドに直接ログインできます。

1049983-20220112164852873-2114878581.png

次に、情報を自由に変更します。

この時点で、この浸透は終わりました。実際、病院の実際のIPを取得した後、詳細なテストを実施することもできます。

0x03要約

1。ターゲット病院の公開アカウントをキャッチし、すべてのリクエストがa.test.comドメイン名を指し示していることを発見しました

2。Test.comのドメイン名登録クエリを通じて、それがサプライヤーであることがわかりました。A.Test.comにアクセスすると、「Whitelabel Error Page」というエラーメッセージを促しました。

このシステムは、Sprint Boot Frameworkによって開発されています。 Dirsearchを介してディレクトリをスキャンし、Swagger-UIページがあることがわかります。

SQLインジェクションとファイルアップロードのテストは実りがありません

3.サブドメインスキャンツールを介してtest.comをスキャンし、www.test.com、git.test.com、およびhc.test.comが存在することを発見しました。

同時に、NMAPポートは3つのドメイン名をスキャンし、hc.test.comの対応するIPがポート1521をオープンし、www.test.comがポート3306をオープンしたことを発見しました。

4。Git.test.comを見つけ、いくつかのgitlabの脆弱性と爆破をテストすることは実りがありませんでした。

5. Test.comの公式Webサイトが提供するAfter-Sales QQグループに参加した後、グループに従業員情報フォームをダウンロードします。

従業員の名前と作業番号の組み合わせを通じてgit.test.comを爆破することは無益でした。

6. Google Hackを介してサブドメイン名Site:Git.test.comを検索し、GitLabのいくつかの公共図書館にアクセスできることを発見しました。いくつかのインターフェイスドキュメントが見つかりましたが、それらは役に立たなかった。 Oracleデータベースのユーザー名とパスワードがRabbitmaqライブラリに漏れていることがわかりました。

7.ここでは、リークされたデータベースのユーザー名とパスワードを介してoracleshell.jarを介してhc.test.comに接続します。入力後、SYSDBAアクセス許可、実行可能コマンド、ユーザーと管理者への追加、およびレジストリを介してポート3389を開き、リモートデスクトップのhc.test.comデータベースホストにログインすることがわかりました。

8.データベースホストでは、MySQLデータベース構成ファイルを含むMySQLディレクトリパスが見つかり、ファイルにはデータベースリンクのユーザー名とパスワードが含まれています。

9.サーバーwww.test.comがMySQLデータベースを開くため、NAVICATを使用して、リークされたデータベースユーザー名とパスワードを介してデータベースにリモート接続し、Webサイトログインのユーザー名とパスワードを取得します。

10。www.test.com/adminを入力して、バックグラウンドログインページを表示し、ユーザー名とパスワードを入力し、背景関数が使用されていないことを確認し、thinkphp3.13エラーを促します

11。Thinkphp3.13の脆弱性を通じてシェルを取得してみてくださいが、それは実りがありません

12。ここでは、MySQLログを介してシェルに書き込む必要がありますが、パスは見つかりません。データベースのテーブル名には、2つのテーブルHS_WEBとHSWEBが含まれています。あなたはウェブサイトのディレクトリ名だと思います。推測Webサイトへの物理的なパスは、次のディレクトリです。

c: \\ hs_web

C: \\ hsweb

d: \\ hs_web

d: \\ hsweb

13。c: \\ hs_webをc:にしようとすると、mysqlのログを介して文が正常に記述されます

14.アリの剣を介して文をリンクし、通常の権限を表示するためにWHOAIコマンドを実行します。ここでは、当局はジャガイモを通して首尾よく育てられます

sweetpotato.exe -a 'hoami'

15.コマンドターミナルの下にユーザーを追加し、リモートデスクトップを有効にします

16。システムにログインした後、nginx構成があることがわかりました。最後に、病院のWECHAT公式アカウントビジネスが最初にTest.comサーバーにアクセスし、次にこのサーバーのNginxから各病院の実際のサーバーに転送されることがわかりました。

17。その後、WeChatの公式アカウントバックエンドソースコードがこのサーバーで見つかり、ローカルソースコード監査が実施されました。バックグラウンドログインはバイパスされたログインが発見されたため、バックグラウンドに直接ログインできます。

オリジナルリンク:https://xz.aliyun.com/t/10531

0 Comments

Recommended Comments

There are no comments to display.

Guest
Add a comment...