趣味の範囲でサイバーセキュリティの話この広告は、90日以上更新していないブログに表示しています。WebLogicはパッチが出てましたが、その時に修正された脆弱性の攻撃コードが先週末あたりに公開されました。実際に攻撃も来ているようで、探すと中国語での解説記事をちらほら見かけます。氏のハニーポットでも攻撃が観測されているそうです。脆弱性(CVE-2017-10271)を狙った攻撃を検知してる。コインマイニングするプログラムのダウンロード&実行が目的みたい。脆弱性対策情報データベース)によると、脆弱性の内容は以下のようになっています。可用性に影響のある脆弱性が存在します。攻撃が行われる可能性があります。いくつかの中国語の記事を見る限り、場合によってはリモートコード実行が可能なようです。Google翻訳に突っ込んだ結果をかいつまんで書くと以下のような感じです(間違っている可能性があることはご容赦ください)。WebLogicのWLSコンポーネントにはリモートコード実行の脆弱性があり、該当するCVE-2017-3506のパッチが今年4月にリリースされたCVE-2017-3506の攻撃コードは公開されていないが、攻撃には利用されていた4月に公開されたパッチをバイパスできる脆弱性(CVE-2017-10271)が見つかり、これは10月のパッチで修正されたということのようです。影響を受けるバージョンは限られていますが、リモートコード実行が可能なため、注意が必要です。有償のプロダクトですが、開発などの用途で使うための無償版があります(Oracleへの登録が必要です)。12.1.3をDockerで建てます。projectsとりあえず、公式のDocker関連ファイルを持ってきます。https://github.com/oracle/docker-images.git色々あるのを全部持ってきますが、使うのはOracleJavaとOracleWebLogicです。ベースとなるJavaのイメージを作成します。cloneした「/OracleJava/java-8/」のディレクトリに「server-jre-8u151-linux-x64.tar.gz.download」というファイルがありますが、中身を見るとテキストでダウンロード先とファイルのハッシュが書いてあります。このファイルを落としてこいということなので、リンクから同名のファイル(server-jre-8u151-linux-x64.tar.gz)を落としてきます。落としてきたファイルは「~~.download」と同じディレクトリに置きます。ビルドにはスクリプトが用意してあるので、叩くだけです。images」で確認するとoracle/serverjre:8のイメージができています。これが、WebLogicのベースになります。次にWebLogicのイメージを作ります。やり方は上と同じです。今回は12.1.3なので、「/OracleWebLogic/dockerfiles/12.1.3/」のディレクトリを確認し、必要なファイルを落としてきます。「fmw_12.1.3.0.0_wls.jar.download」と「wls1213_dev_update3.zip.download」があるので、それぞれのファイル内のリンクから同名ファイルをダウンロード(登録が必要)し、同じディレクトリに設置します。その後、「/OracleWebLogic/dockerfiles/」にある、buildDockerImage.shを叩きます。12.1.3oracle/weblogic:12.1.3-genericのDockerイメージができます。WebLogicのベースイメージができたので、ここからサンプルのDockerfileからWebLogicサーバを建てます。「/OracleWebLogic/samples/1213-domain/」でREADME.mdの通りに実行します。.ADMIN_PASSWORDは英数8文字以上みたいな制約があるので気を付けてください。これでWebLogicサーバのDockerイメージができました。できたイメージはこんな感じ。アクセスして、こんな画面がでれば成功です。攻撃コード検証まず、「http://localhost:7001/wls-wsat/CoordinatorPortType」へアクセスしてみます。このパスが今回の攻撃対象になります。PoCはこのパスに対して、POSTで実行するコマンドを含んだSOAPのXMLを投げつけます。Errorが返ります。コマンドの結果はレスポンスには載ってきません。/tmp/Hack」というコマンドを実行してみました。コンテナの中に入って、確認します。確かにファイルが作成されていました。いうことで、リモートでコード実行ができました。まとめ日本ではあまり騒がれていませんが、すでに攻撃が行われており、該当するバージョンのWebLogicを利用している場合、おそらくデフォルトの状態で刺さる可能性がある危険な脆弱性です。対策としては、WebLogicのバージョンアップ、暫定策として、wls-wsatへのアクセス制御や、関連するコンポーネントの削除が挙げられています。WebLogicのログがどこにあるのか分からなかったのですが、もしログがあるなら、「/wls-wsat/CoordinatorPortType」へのPOSTでのアクセスログあるか、そのレスポンスが500になっていないかを確認するのがいいかと思います。WebLogicの環境構築がちょっと面倒でしたが(有償の製品なので仕方ないですね)、とりあえずは検証まで行うことができて満足しました。(2017/12/28)以下2点を補足として。今回利用したPoCでは「/wls-wsat/CoordinatorPortType」のパスへ攻撃しましたが、実際には「/wls-wsat/」配下の存在するパスであれば攻撃は成功するようです。アクセス制限を考えている場合は「/wls-wsat/」以下すべてのパスの制限をした方がいいです。検証したところ、上記の影響を受けるシステムとなっている以外のWebLogicのバージョンでも利用した攻撃コードが刺さりそうな感じでした。詳細な影響範囲は分かりませんが、WebLogicの10系と12系を利用している場合はとりあえず、攻撃影響・侵害の有無を確認した方がいいと思います。CTFCTF今年も会社のチームで参加しました。今年は昨年よりpwn以外の問題が増え、とっつきやすくなった感じです。最近はどのCTFも軒並み難易度が高く、参加しても1番簡単な問題が1問解けるかどうかというくらいだったので、今回のような手ごろな問題を解いて達成感を得られるのはとてもありがたいです。達成感、重要ですよね。"}"再起でフィボナッチ数列を求めていますが、再起が深すぎて実行するとプログラムが止まります。再起なしで、フィボナッチ数列を求めてやれば答えが出ます。"}")この問題はすぐに解けました。再起の上限の設定なんてあるんだなーと。POR4dnyTLHBfwbxAAZhe}}ocZR3Cxcftw9昨年のSECCONでも出てきたヴィジュネル暗号の3D版です。昨年と解き方は同じだろうということで、暗号処理の中身はあまり気にせず、頭の「SECCON{」を暗号し、出力の先頭と一致する鍵を探します。key鍵は2つあり、14文字の鍵とその逆順を使います。1文字ごとの2つの鍵の組み合わせを総当たりしています。この処理で鍵の前半7文字とその逆順の前半7文字(つまり後半7文字)の組み合わせが出てきます。ここで、それぞれの鍵は変数sのパターン分66通り出てくるのですが、実行してみると、66通りのどの鍵を使っても出力は同じになることが分かります。そのため、1文字目はすべて「A」となる鍵を持ってきています。これで、14文字の鍵が全てわかりますので、その鍵で復号して暗号文に一致する文字を探します。flag換字のテーブルの構造はほとんど考えず、ただ総当たりでやりました。鍵が66通りどれでやっても結果が同じことに気づくのに時間がかかりました。300)難読化されたPowershellを実行する問題。RemoteSigned」を実行します。$ECCON」にすると、難読化を解除したスクリプトが見えます。最初に耐解析的なセクションがあり、イベントログの件数を確認し、少なすぎればサンドボックスと判定します。この処理におそらく管理者権限が必要で、管理者権限のあるコンソールでなければ処理が停止します。管理者権限のコンソールでスクリプトを実行してみます。背景が黒くなり「SECCON」ロゴが出てきます。耐解析のセクションを抜けると鍵盤が出てきて、入力に応じて音がでます。$keytone」)。523.2691行目の「$secret」変数の値と一致するkeyが正解。「hhjhhjhjkjhjhf」を入力すると「さくらさくら」が流れて、次のステージに行けます。パスワードを求められるので、さらに100行目以降の難読化を解除していきます。やっているっぽいけど、とりあえず、「$plain」変数をechoします。すると、asciiが10進になっているようなものが出てくるので、これを文字列に変換。意味の分からない難読化されたスクリプトが出てきます。${;}=+$();${=}=${;};${+}=++${;};${@}=++${;};${.}=++${;};${[}=++${;};${]}=++${;};${(}=++${;};${)}=++${;};${&}=++${;};${|}=++${;};${"}="["+"$(@{})"[${)}]+"$(@{})"["${+}${|}"]+"$(@{})"["${@}${=}"]+"$?"[${+}]+"]";${;}="".("$(@{})"["${+}${[}"]+"$(@{})"["${+}${(}"]+"$(@{})"[${=}]+"$(@{})"[${[}]+"$?"[${+}]+"$(@{})"[${.}]);${;}="$(@{})"["${+}${[}"]+"$(@{})"[${[}]+"${;}"["${@}${)}"];"${"}${.}${(}+${"}${(}${|}+${"}${(}${)}+${"}${(}${)}+${"}${)}${|}+${"}${)}${&}+${"}${(}${+}+${"}${&}${@}+${"}${+}${=}${+}+${"}${|}${)}+${"}${+}${=}${=}+${"}${[}${]}+${"}${)}${@}+${"}${+}${+}${+}+${"}${+}${+}${]}+${"}${+}${+}${(}+${"}${.}${@}+${"}${[}${]}+${"}${&}${=}+${"}${+}${+}${[}+${"}${+}${+}${+}+${"}${+}${=}${|}+${"}${+}${+}${@}+${"}${+}${+}${(}+${"}${.}${@}+${"}${.}${|}+${"}${(}${|}+${"}${+}${+}${=}+${"}${+}${+}${(}+${"}${+}${=}${+}+${"}${+}${+}${[}+${"}${.}${@}+${"}${+}${+}${(}+${"}${+}${=}${[}+${"}${+}${=}${+}+${"}${.}${@}+${"}${+}${+}${@}+${"}${|}${)}+${"}${+}${+}${]}+${"}${+}${+}${]}+${"}${+}${+}${|}+${"}${+}${+}${+}+${"}${+}${+}${[}+${"}${+}${=}${=}+${"}${.}${|}+${"}${+}${.}+${"}${+}${=}+${"}${)}${.}+${"}${+}${=}${@}+${"}${[}${=}+${"}${.}${(}+${"}${(}${|}+${"}${(}${)}+${"}${(}${)}+${"}${)}${|}+${"}${)}${&}+${"}${.}${@}+${"}${[}${]}+${"}${+}${=}${+}+${"}${+}${+}${.}+${"}${.}${@}+${"}${.}${|}+${"}${&}${=}+${"}${[}${&}+${"}${+}${+}${|}+${"}${(}${|}+${"}${+}${+}${[}+${"}${.}${(}+${"}${)}${@}+${"}${]}${+}+${"}${[}${|}+${"}${[}${|}+${"}${.}${|}+${"}${[}${+}+${"}${+}${@}${.}+${"}${+}${.}+${"}${+}${=}+${"}${|}+${"}${&}${)}+${"}${+}${+}${[}+${"}${+}${=}${]}+${"}${+}${+}${(}+${"}${+}${=}${+}+${"}${[}${]}+${"}${)}${@}+${"}${+}${+}${+}+${"}${+}${+}${]}+${"}${+}${+}${(}+${"}${.}${@}+${"}${.}${|}+${"}${)}${+}+${"}${+}${+}${+}+${"}${+}${+}${+}+${"}${+}${=}${=}+${"}${.}${@}+${"}${)}${[}+${"}${+}${+}${+}+${"}${|}${&}+${"}${.}${.}+${"}${.}${|}+${"}${]}${|}+${"}${+}${.}+${"}${+}${=}+${"}${|}+${"}${&}${)}+${"}${+}${+}${[}+${"}${+}${=}${]}+${"}${+}${+}${(}+${"}${+}${=}${+}+${"}${[}${]}+${"}${)}${@}+${"}${+}${+}${+}+${"}${+}${+}${]}+${"}${+}${+}${(}+${"}${.}${@}+${"}${.}${[}+${"}${&}${.}+${"}${(}${|}+${"}${(}${)}+${"}${(}${)}+${"}${)}${|}+${"}${)}${&}+${"}${+}${@}${.}+${"}${.}${(}+${"}${(}${|}+${"}${(}${)}+${"}${(}${)}+${"}${)}${|}+${"}${)}${&}+${"}${+}${@}${]}+${"}${.}${[}+${"}${+}${.}+${"}${+}${=}+${"}${+}${@}${]}|${;}"|&${;}ここは本当に意味が分からなくて、しばらく悩みましたが、結局、一番最後についている「|&${;}」がスクリプトを実行している箇所だろうと考え、ここを削除し、「${;}」をechoすると、また10進数をcharに変換しているようだったので、これをascii化。"SECCON{$ECCON}"\r\n\x0c'でフラグにたどり着きました。Powershellはあまり詳しくないのですが、思っていたよりかなり柔軟な難読化ができるんだなあ、という印象です。挑んではいましたが、答えにたどり着けず。DSLをインジェクションするのかと思って色々試していましたが、「違うじゃん」と分かったところで、諦めました。Searchももっと触れておかないとなと感じました。みたいな問題はいつも、割と好きで解きたいと思いつついつも解けない問題です。Blueで坂井弘亮氏が話していたSOPの問題もありましたが、手を付けられませんでした。今回もpwn系も少し解けるようになりたいなー、とCTFのたびに思っています。2017に参加してきました。備忘録的に興味深かった内容をさらっと書いておこうかと思います。理解できていない部分もあるので、間違っている可能性もあるとご理解ください。基調講演:サイバースペースにおける国家主権サイバー犯罪と国家の主権に関する話。書いていたメモが消えたので、感想だけ軽く......。サイバー戦略および政策に関して企業として組織に助言しているとのこと。陸・海・空の軍事関係にサイバー空間を足してどう対応していくべきかを考える。原子力潜水艦や船舶、衛星などの実際の攻撃事例が面白かった。様々な課題がありますが、協力していきましょうというのはよくある国際社会とサイバー犯罪に関する講演の結論です。今回も教育や学習という面でこのカンファレンスを通じて理解を深めましょうといった内容で、最初の基調講演としてはふさわしい内容だったのではないでしょうか。講演者の坂井弘亮氏は独自組み込みOS「KOZOS」を作成している。それと、SECCONの実行委員の方。Programming)という方法で攻撃ができる(一般的な名称ではない?)組み込み機器ではRSPプロトコルを使ってリモートデバッグを行う組み込みのデバッグではプログラムカウンタを簡単にいじれるので、ROPのように既存のコードを使ったコード実行が容易SECCONでSOPを利用して解く問題を出したところ、みんなSOPを利用して問題を解いていたので、この手法自体は誰もが簡単に思いつくものである技術的な内容は難しかったですが、SECCONの問題の解説はなかなか面白かったです。実際にリモートデバッグを使ったコード実行のデモを行っていたので、漠然と何をやっているのかは理解できました。する人たちからしたら、今回の攻撃の手法はROPからすぐに思いつくのかなあという感想。いうマルウェアはとても多機能で、後からモジュールをロードできる攻撃者は多数のモジュールを用意し、攻撃対象に合わせたモジュールをロードし、目的を達成する結局のところ、狙われているのはWindowsであり、今回の解析対象もWindowsマルウェアでした。質疑で日本も標的になりうるかとい質問に、個別システムのモジュールを攻撃者が用意することができれば、どんなシステムも標的になりうるという点が印象深かった。APT攻撃インシデントSTIXデータベースJPCERTの方の発表。対象STIX形式で各内容まとめてみると、攻撃者の動向が把握できる各キャンペーンの活動時期をTimelineとして並べるデモを行ったただ、標的型攻撃のインシデント詳細をそこまで大量に持っているのはJPCERTくらいじゃないかと思う。問題提起がそもそもJPCERTの内部の問題なんじゃ......。JPCERTの持っている情報も機微なものが含まれるので、そのまま公開はできないとのこと。手軽な情報共有の基盤を作ったのなら分かるが、STIX形式の入力は現状「頑張って」やっているそうで、頑張らなきゃ使えないシステムは普及しないのでは......。JPCERT以外の組織での利用シーンはあまり思いつかないのが正直なところ。マルウェアの挙動なんかは面白かったので、もう少し掘り下げてほしかったけど、そこは次の講演者の発表で。-行動パターンに基づく横断的侵害の把握と調査-引き続きJPCERTの方の発表。イベントログの削除(イベントログを見ることもできるので、他の用途でも利用される)こうしたマルウェアの挙動を見るにはイベントログがもっとも有用ただし、デフォルトではコマンドの内容までは取れないので、監査ポリシーの設定は必要Sysmonというツールを併用するとよい攻撃者によってイベントログが削除されることを考えて、イベントログサスクリプションを利用するさすが、JPCERTは見ている量が違うなと。やっているその内容も逐次公開してくれているので、ありがたい限りです。ほとんどはJPCERTのサイトで公開している内容ですが、こうして改めて話を聞く機会があるのはとてもうれしい。v5のみという制約があり、また、ASMIをバイパスする手段も存在する.NETネイティブコードをフックして対象外のWindows、Powershellのバージョンで動作するASMIを実装するPowershellコードの実行時のメソッドをフックすることで、難読化されたスクリプトを解除した状態で表示できるスライド、実際のコードは公開されています。ASMIという機構については知らなかったので、勉強になりました。Powershellは最近攻撃によく利用されるので、勉強しなくちゃならないなーと。Teamに所属する西村宗晃氏の講話。国産IT資産管理ソフトウェアと聞くと、最近注意喚起のあった某社製品を思い浮かべますが、今回の話はそれではなく、(その事例に端を発してはいますが、)国産IT資産管理ソフトウェア一般に色々な脆弱性がありますという内容。IT資産管理ソフトウェアとは社員のPCを一元管理するためのソフトウェアソフトウェアファイルの管理、デバイスの利用制限、プログラムの配布(アップデート配信)、社員のPCの遠隔操作といった機能と持つ(話者曰く、つまりMeterpreterみたいなもの)通常、社内のイントラ内で利用しているが、持ち出し用のPCでUSBタイプのモデムを使うなど、グローバルIPが振られたときに攻撃される恐れがある。管理機通信の偽装クライアントPCと管理機は暗号化された独自プロトコルを利用して通信しているが、暗号化通信の鍵がインストーラに埋め込まれており、復号可能。復号した通信に管理機のドメインとポートが書いてあり、そこを書き換えることで管理機を偽装することができた。鍵は全て共通のものを利用しており、製品を利用している他社のPCにも同じことができる。クライアントPCの遠隔操作クライアントPCとVNCで接続するタイプのソフトウェアだが、認証がかけられていなかった。試したところ、特定のバージョンのVNCで接続すると、簡単にリモート接続ができてしまった。管理機へ認証なしでアクセスが可能だった。管理機にSQLインジェクションの脆弱性があり、社員のPCの情報をすべて見ることができるようになっていた。CryptAPIを利用しており、APIをフックするといった手法で暗号が解かれることがある。一度暗号化を解いてしまうと、SQLインジェクションや管理者のパスワードを窃取されるなどの攻撃が行われる。管理機に社員番号のディレクトリが作成されるようなタイプのソフトウェアでは、社員番号にディレクトリパスを指定することでディレクトリトラバーサルが可能な事例も存在した。したソフトウェアは体験版を個人で取り寄せることも可能で、おそらく攻撃者もそうやって脆弱性を探している例のソフトウェアの脆弱性の話をするのかと思っていましたが、予想とは違っていました。面白い内容で、こういうソフトウェアって意外と脆弱性多いんだな、と率直に思いました。別にIT資産管理ソフトウェアだけでなく、他の国産ソフトウェアもきっと似たような事例はあるんじゃないかと思っています。特定の国を狙った標的型攻撃にその国でよく利用されていているソフトウェアをハックする方法は以前からありますし、最近は特に増えている気もします。Teamの活動の重要性が分かりました。各社の公開資料や自動車のリバースエンジニアリング(OpenDBC)から自動車を運転するためのAPIを作る運転に必要なAPI:ブレーキ、ガス、ステアリングを既存APIをもとに組み立てるcabana:自動車のハッキングのためのオープンソースのPythonライブラリopenpilotのデモwww.youtube.com主に自動運転の話でしたが、リバースエンジニアリングや、自動車のAPIなど、普段聞かない話は面白かったです。法整備や国ごとの特色など、課題は多そうですが、自動運転は未来の技術として期待したいです。日本の国内外問わず、セキュリティに関するさまざまなトピックを聞くことができました。普段聞かない領域の話も多くあり、とても勉強になりました。今回は特に日本の事例が面白かったです。色々なセキュリティの記事やニュースを見ていると国外のすごい人は色々いますが、国内にもすごい人はいるなあ、と感じました。これからもセキュリティ業界をますます発展させていきたいですね。Tomcatのリモートコード実行の脆弱性についてです。それぞれが順番に出てきて、情報が小出しにされている感じでしたが、結局条件を満たしていれば、影響範囲は割と広いようです。早い段階で検証している方もいたので、PoCはあるということは分かっていました。Cat.6(ねころっく)脆弱性の内容自体は以下の通りです(サイオスのセキュリティブログから)。initialisationパラメータをfalseに設定している時)でで動作している際に、特別に細工されたリクエストにより、サーバにJSPファイルをアップロードすることが可能です。このJSPにコードを仕込むことで、サーバ上で任意のコードを実行することが可能になります。9/19に公開されたCVE-2017-12615に対する修正では、この問題は解決されませんでした。initialisationパラメータをfalseに設定している時)でで動作している際に、特別に細工されたリクエストにより、サーバにJSPファイルをアップロードすることが可能です。このJSPにコードを仕込むことで、サーバ上で任意のコードを実行することが可能になります。この修正は実際には、リリース時のチェックの関係で7.0.81に加えられているため、更新する際には7.0.81にする必要が有ります。7.0.80VirtualDirContextを使用している際に、セキュリティ制限をバイパスすることが出来ます。これにより、特別に細工されたリクエストを用いてVirtualDirContextにより提供されるJSPリソースのソースコードを見る事が可能になります。検証Linux環境でTomcatのリモートコード実行を行ってみました。readonlyパラメータをfalseにしておくと、PUTメソッドでファイルがアップロードできます。7.0.75設定ファイルの変更Tomcatの「conf/web.xml」ファイルでreadonlyパラメータをfalseにします。サーバに対してPUTメソッドでファイルを設置します。テストのファイルをPUTし、アクセスすると、ファイルが作成されていることが分かります。JSPファイルをアップロードすることで任意のコード実行が可能です。アップロードしたファイルにアクセスして、「whoami」を実行してみます。コマンドの実行結果が返ってきました。ちなみに、脆弱な設定になっていないTomcatサーバへPUTをしようとしても403が返ってきます。脆弱性の内容としてはPUTによるファイルアップロードが実態のようです。JSPファイルをアップロードしてコード実行が行うことができますが、バックドアをアップロードしてコード実行を行うのは一般的な攻撃手法なので、なぜリモートコード実行の脆弱性なのかが分かりません。検証してみた感想としては、これただのPUTじゃんという思いが強いのですが、PUTが可能ということ自体が重大な脆弱性であるので、アップデートするなり適切な対処をしましょう。リモートコード実行の脆弱性です。前回の脆弱性からさほど時間が経っていませんが、今回もまたCriticalな脆弱性が出てきました。ブログのネタを提供してくれるのはうれしいのですが、余計な仕事を増やされるのは困りものです。までは同時に公開されました。脆弱性はレートがCriticalとなっており、緊急性の高いものでした。プラグインが有効になっているという前提条件が付きます。2.5.12の環境を作ります。ヘッダに「application/xml」にし、ボディにコード実行のPoCを入れます。/tmp/hackedByMe」としています。500番のエラーが返ってきます。これで攻撃は成功しているようで、サーバ側で攻撃のプロセスは起動しているようです。Dockerのコンテナの中に入って確認すると、確かにtouchコマンドで作成したファイルが置いてありました。応答がエラーページになっており、使用したPoCでは、例えばcatのような標準出力の値をそのまま表示させることはできません。バックドアを作ったり、一度ファイルに書き込んで、外に投げるなどが必要です。試したところ、同様に500番エラーが返ってきましたが、プロセスは実行されませんでした。プラグインが有効になっていればほぼ攻撃は成功するため、緊急性の高い脆弱性です。S2-53(CVE-2017-12611)についてS2-053S2-052が公開されたしばらく後に公開された脆弱性はレートはModerateとなっています。こちらはアプリケーションの作りによって回避可能な脆弱性です。修正バージョンへのアップデート実装上の問題はあまり詳しくないので下手なことは書けませんが、Freemarkerタグを使って要求の値を読み取ることができるような実装になっている場合に脆弱性が発生するようです(違っていたらすみません)。検証S2-053に対して脆弱なアプリケーションが公開されていたので、検証してみました。Dockerで引っ張ってきて起動すると、以下のようなアプリケーションが立ち上がります。nameには任意の値を入れることができ、適当な文字列を入れると、その文字がnameに表示されます。%{100-9}のような値を入れると計算結果の「91」がnameに入ります。このnameという変数でFreemarkerタグが利用されており、脆弱な状態になっています。ここに攻撃コードを入れます。今回は「whoami」を実行してみます。ユーザ(root)が表示されました。/etc/passwd」を実行してみると以下のようになります。こちらは分かりやすいリモートコード実行ですが、アプリケーションがこのデモ用のサイトと同じような作りになっている必要があります。アプリケーション個別の実装を考慮する必要がある分、攻撃者にとっては若干攻撃コストが上がります。脆弱性の範囲はS2-045などをかぶっている部分が多いので、この攻撃を行うならS2-045のほうが...という気もしなくはないです。2.3系では最新版以外は有効ですし、S2-045などの脆弱性をパーサの変更などで対処してバージョンアップをしていないというような場合は、影響を受ける可能性があるので、注意が必要です。2の脆弱性(S2-052)や(S2-053)についてのまとめてみた。CONで発表されたSMBを狙ったDoS攻撃に関するお話です。いう名前をいう名前を付けています。因んだものでしょうか。成功したとの記述があります。株式会社ラックSMBLorisのサイトでは以下のように書かれています。/etc/samba).デフォルトでは影響を受けるようですが、設定によって回避ができるようです。すべてのバージョンのSMBで認証不要で攻撃可能ですので、445番ポートが空いていればほぼ攻撃を受けると考えてよさそうです。脆弱性についてですが、今のところCVE番号などは採番されていないようです。この脆弱性に対応するパッチは出ないそうです。445番ポート閉じろってことですね。みたいな445番ポートを狙った攻撃がしょっちゅう話題になっていたので、まさか今更そんなポートを外部に公開している企業なんかないだろう、と信じています。各所で検証動画とかが公開されているので、新しさはないですが、ちょっとやってみました。いえやるのは、PoCを打つだけです。打った際のタスクマネージャ。メモリの使用率が急激に上昇しています。表示上は72%ですが、この時点でタスクマネージャが固まって動かなくなりました。攻撃先ホストへPingを打っていたのですが、そこそこlossしています。攻撃止めてもしばらくは固まったままでした(普段使いのPCだったからちょっと心配した)。SMB経由のDoSが攻撃としてどの程度有用かわかりませんが、通常の脆弱性への対処ができていれば、今回の攻撃の影響はそこまでではないかなという所感です。Strutsの新しい脆弱性です。前回の脆弱性S2-045とS2-046がかなり大きな影響を与えただけあって、セキュリティ関係者はアンテナ張っていたようで、情報は早かったですね。公開されたのは、週末というちょっと嫌な時間でしたが。関する注意喚起S2-048概要S2-048またリモートコード実行です。今回は影響範囲は限定的です。させている場合に影響を受ける可能性があります。情報を参考にしてください。)ちなみに今回も、脆弱性公開時点で公式には修正バージョンが上がっておらず、Gitなどにあるテストリリースのみという状態でした。今回もPoCが出るのは早かったです。いうことで、さくっと検証してみました。Dockerでコンテナを立ち上げて、サンプルアプリのshowcaseを動かします。pluginの動いているページで、ここに対して攻撃コードをPOSTで送ります。testtesttest」を実行してみます。攻撃時のパケット(レスポンス)です。実行したコマンドの結果が返ってきてます。この辺りは以前のS2-045などと同じです。pluginが動いているパスにしか効きません。サンプルアプリケーションでは、「/struts2-showcase/integration/saveGangster.action」が対象です。pluginをどこで使っているかは上にのっているアプリケーションの作りによると思いますが、外から攻撃対象となるパスを判別することはできないのではないでしょうか。pluginを利用しているだけではなく、メッセージを受け取り、脆弱性のあるメソッドで処理するような実装である必要があり、攻撃の条件は厳しいと思われます。そのため、実質的にサンプルアプリケーションくらいにしか攻撃は成功しないのかもしれません。2を利用していたらどの時点でアウトだったので、無差別な攻撃が当たることもありましたが、今回はそこまでの影響はなさそうです。いえ、対策はちゃんとしましょう。ことが示されています。行により脆弱性を悪用されないことを確認しています。利用などの対策を検討してください。S2-047とS2-049なぜ番号が飛ばされたのか分かりませんが、今回はS2-048が先に出て、そのあとでS2-047とS2-049が出ました。ratingもそれぞれ、LowとMidiumとなっており、そこまで影響の大きな攻撃ではなさそうです。今回は攻撃を受けたりとあまり大きな騒ぎになってはいませんが、S2-045と同じようなRCEの脆弱性が今後も出てくる可能性があるということは十分わかりました。情報を追いかけていく必要はありそうです。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。