みっきー申す

ITに関する興味関心のまとめ、サイバーセキュリティニュースのまとめ、Twitterで配信中の情報まとめなどを公開します。

Windows版Facebook Messengerにてバックドアを実行できる脆弱性について

f:id:micro_keyword:20200614143607j:plain:w400

Reason Cybersecurityが公開するブログにて、「Facebook Messengerデスクトップアプリを使用した永続化手法」という題で、WindowsFacebook Messengerの脆弱性についての情報が公開されました。

blog.reasonsecurity.com

このReason Cybersecurityという企業は、創業者でありCTOのAndrewが、2004年にWindowsに買収されのちのWindows Defender開発に寄与したとされる、GIANT Company Softwareの共同創業者ということで知られているようです。

www.reasonsecurity.com

当該記事では、WindowsFacebook Messengerの脆弱性について記載されていますが、そもそも、WindowsFacebook Messenger自体、COVID-19のあおりを受けてか、2020年の4月2日にリリースされたばかりのようですね。

jp.techcrunch.com

以下は、Facebookからのメッセージです。

about.fb.com

今回は、脆弱性がどのようなもので、何に注意しなければいけないかなどについて、記載していきます。


目次


影響を受けるバージョン

今回、脆弱性の存在が確認されたのは、Microsoft Storeで入手可能なWindowsFacebook Messengerです。

脆弱性が確認されたのは460.16だとのことですが、その後公開された480.5では修正されているようです。

公式からはバージョンを追えなかったのですが、以下のダウンロードサイトからはMessenger 460.16.123.0の次がMessenger 480.5.121.0であることが、推測できますね。

facebook-messenger.softonic.jp

採番規則が少々不思議。。。


脆弱性の概要

実行されるべきでないコードがアプリケーションで実行されるのが脆弱性

結果として、Messenger上のリソースを呼び出すことで悪意の第三者が用意したマルウェアを実行させ、端末を乗っ取ることができます。

また、攻撃者はアクセスを検知されずに永続的に端末へのアクセスを確保することができます。

Messengerのデスクトップアプリにて、Python27ディレクトリよりPowershell.exeを呼び出す動作が確認されました。

https://blog.reasonsecurity.com/wp-content/uploads/2020/05/1-4.png

画像からもわかる通り、powershell.exeというファイルをPython27ディレクトリより呼び出していることがわかります。

system32配下に配置されているものではないので、管理者権限を持たない場合でも呼び出すことが可能で、たとえ、それが外部からアクセスした第三者であってもMessengerの起動を機に、powershell.exeを実行可能なことがわかります。

報告元のReasonSecurityの検証では、ペネトレーションテストツールのMetasploitで利用されるmsfvenomコマンドを用いて、リバースシェルを作成します。

そして、作成したシェルをpowershell.exeにリネームし攻撃対象の端末の「c:\python27」ディレクトリに転送しておきます。

そうすると、Messengerが起動されたタイミングで当該シェルが起動し、攻撃者の端末との接続が可能になります。

以下のように、攻撃者側で接続を待機して、

https://blog.reasonsecurity.com/wp-content/uploads/2020/05/Create-listenr.gif

Messengerが実行されると、接続が確立。

被害端末でのコマンド実行が実行可能になります。

https://blog.reasonsecurity.com/wp-content/uploads/2020/05/4.gif


まとめ

今回取り上げたWindows版のMessengerのように、リモートワークの普及に合わせて開発されたアプリケーションのクライアント版は多いかと思います。

ただ、今回のように脆弱性のような脆弱性が顕在化しているケースも多いのかもしれないですね。

もしかすると、テスト期間などを十分に取れないまま、リリースしたということなのかもしれません。

Zoomの件もそうですが、組織として利用する際には、ソフトウェアの安全性を確認してから導入することの大切さを改めて感じさせられます。