趣味の範囲でサイバーセキュリティの話この広告は、90日以上更新していないブログに表示しています。久しぶりにブログ書きます。最近あまりネタがなかったのでちょっとさぼり気味でした。Frameworkの脆弱性(CVE-2018-1270)についてです。Struts同様JAVAのアプリケーションフレームワークです。いうメッセージプロトコルをWebSocketで利用している場合に、攻撃者から細工されたメッセージを受け取ることで、任意のコード実行が行われる脆弱性。同様に細工されたURLにアクセスすることでディレクトリトラバーサルが行われる脆弱性も報告されています(CVE-2018-1271)。4.3.15また、すでにサポートが終了している過去のバージョンにおいても本脆弱性の影響を受けるとのことです。検証PoCがすでに公開されており、検証用のアプリケーションもあったので、検証してみました。検証用のアプリケーションを動かしました。8080ポートを開けてコンテナを動かします。Bootの脆弱性のあるバージョンを持ってきます(このへんから)。Bootのソースの中に検証用のアプリケーションのソースとpom.xmlを入れて、Mavenでビルドし、アプリケーションを動かします。Bootが色々と必要なものを落としてきて、アプリケーションを動かしてくれます。終わったら、localhostの8080番にアクセスします。検証用のサンプルなので、すでにPoCが入力されており、あとはSendするだけという親切設計になっています。中身がコピーされていました。ついでに修正されたバージョンでもやってみました。中身のバージョンを書き換えます。気を利かせて、脆弱なバージョンを持ってきてビルドするみたいですね。同じようにやってみましたが、コード実行は失敗、それ以外には変化はありませんでした。攻撃時のパケットパケットキャプチャをとってみました。WebSocketでやり取り(STOMP)という感じですかね。攻撃コードがバイナリになってどこが何をやっているのかがちょっとわからないです......。WebSocketがデータ圧縮を行っているため、攻撃コードが可読でなくなってるみたいです。permessage-deflate」というヘッダのせいみたいですね。試しにBurpを間に挟んで攻撃コードを実行してみました。例のヘッダがなくなり、一部平文で見えるようになりました。それでも攻撃コードはマスクされています。(BurpってWebSocketも対応してるんですね)ただ、WireSharkで見ると、マスクを解除してくれるので、攻撃コードがちゃんと見えています。普通のHTTP通信ならレスポンスが圧縮されることはあってもリクエストは平文だったのですが、WebSocketはリクエストが圧縮されたりマスクされたりするので、攻撃のポイントが見えにくくなり、検知がしにくくなります。WebSocket経由の攻撃はこれまで見たことなかったのですが、割と面倒くさいなというのが今回の印象です。追記(2018/04/17)WebSocketのマスクついて調べてみました。マスクされたペイロードということらしいです。攻撃者が任意のトラフィックを通信路に流せると、キャッシュ汚染の恐れがあるといった理由でこうなっているみたいです。これをIDSなどで検知しようとすると、攻撃コードがWebSocketのマスクされた値の中にあるので、それを解除したうえで、検知を行う必要があり、かなり難しいと思われます。WebSocket経由での攻撃というのは初めて聞いたのですが、このようなWebSocketのリクエストに対応した検知システムとかって、何かあるんでしょうかね......。乗り換えようという人もいるかもしれませんが、こまめにアップデートする必要はいずれにせよありそうですね。Frameworkは初めて触ったのですが、割と開発の使い勝手は良さそうな印象でした。今回の攻撃は影響は大きそうですが、まだ攻撃が行われたという話は聞かないです。先に述べたように一般的なWebの攻撃に比べて検知が難しいので、気づかないうちに攻撃が行われている、なんてこともあるかもしれません。自分の管理するサーバに異変がないか、確認してみるのがいいかと思います。脆弱性(CVE-2018-2894)についてXdebugとNetBeansを使ったDrupalのデバッグ環境をdocker-composeのみで立てる月別アーカイブはてなブログをはじめよう!blueBLUEさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。