Recently some bugs I found in browsers and a flash player have had their advisories released. The first is a bug in Camtasia that allows for XSS because they allow remote inclusion of configuration files. Inside of the configuration files you can specify a javascript:... URL inside of an XML Element. This javascript URL is executed after the movie has finished playing.
The other bug was one I found while working on WBTS. It's a bug in version 10.62 of Opera's browser. This allowed for CSS and potentially other data to be accessed cross origin. This bug was due to a problem with redirects and reading in the remote files cssRules. I said it in my WBTS talk and I'll say it again, redirects are a common source of browser bugs!
最近、ベンダーさんは僕が見つけた脆弱性情報を発表した。ひとつのバッグはCamtasiaというフラッシュ映画の作れるソフトにXSS攻撃が可能だった。 そのソフトはフラッシュ映画にリモート（他のサーバー）からXML設定ファイルを挿入できる。設定ファイルの中にXML要素で「javascript:」のURLを指定し、映画が終わったらフラッシュによってブラウザはこのURLをアクセスする。
他のはWBTSを作ったときに見つけた脆弱性だ。Operaバージョン10.62でのブラウザの問題だ。この脆弱性で他サイトのCSSか他の情報漏洩の問題だ。詳しくはCSSファイルをリダイレクトでアクセスすると、他のドメインのcssRulesを読める。WBTSプレゼンテーションでも再度言ったんだが、「ブラウザのセキュリティーにおいて、リダイレクトの問題は日常的だ！」。
Wednesday, October 20, 2010
Friday, October 8, 2010
Slides Available | スライドを発表した
Quick note I just uploaded my slides from the SyScan talk to the WBTS Project Page.
SyScanのWBTSプロジェクトのスライドをWBTS プロジェクトページにアップロードした。
SyScanのWBTSプロジェクトのスライドをWBTS プロジェクトページにアップロードした。
Tuesday, October 5, 2010
SyScan Done WBTS Released | SyScan終わったWBTS発表した
I finally finished all the work necessary for my SyScan talk at Ho Chi Minh. It went well and I had a pretty awesome time in Vietnam. I was going to post an update when I got back but I've been too tired to do anything. After 8-9 months of work, I would like to report I have finally released WBTS. There are a few missing test cases from the initial release as I have open bugs with Opera and BlackBerry. Once they fix those bugs I'll release the WBTS cases. Anyways you can download WBTS here and WBTS Runner here.
Enjoy!
やっとSyScanでのプレゼンテーションが終わった。本当によかった、ベトナムは楽しかった。戻った後にすぐブログを書こうと思ったけど、結構疲れたから今までやらなかった。9ヶ月間の努力の末にやっとWBTSを発表した。まだ、ブラウザベンダー「BlackBerry、Opera」が脆弱性を直してないから、最初のリリースはその直してない脆弱性のテストケースを含まない。直した後に発表する。以下のようなリンクでWBTSをダウンロードできる。WBTS。。。 WBTS Runner.
楽しんで！
Enjoy!
やっとSyScanでのプレゼンテーションが終わった。本当によかった、ベトナムは楽しかった。戻った後にすぐブログを書こうと思ったけど、結構疲れたから今までやらなかった。9ヶ月間の努力の末にやっとWBTSを発表した。まだ、ブラウザベンダー「BlackBerry、Opera」が脆弱性を直してないから、最初のリリースはその直してない脆弱性のテストケースを含まない。直した後に発表する。以下のようなリンクでWBTSをダウンロードできる。WBTS。。。 WBTS Runner.
楽しんで！
Wednesday, August 18, 2010
Overlong UTF-8 Generator | 不正なUTF-8シーケンスジェネレーター
Real quick post about some code I made to generate invalid UTF-8 sequences. I couldn't find this online so I made my own ;D.
Here it is:
Web検索で見つかれなかったので、自力で不正なUTF-8シーケンスジェネレーターツールを使った。
Example:
Here it is:
Web検索で見つかれなかったので、自力で不正なUTF-8シーケンスジェネレーターツールを使った。
Example:
overlongyourmom.py written by wirepair
Enter an ASCII char to make overlong, or hex (ex: h27) or 'quit': '
char ['] dec [39] hex [27] url: %27
overlong 2-byte sequence: c0 a7
overlong 3-byte sequence: e0 a7
overlong 4-byte sequence: f0 80 80 a7
overlong 5-byte sequence: f8 80 80 80 a7
overlong 6-byte sequence: fc 80 80 80 80 a7
Enter an ASCII char to make overlong, or hex (ex: h27) or 'quit': /
char [/] dec [47] hex [2f] url: %2f
overlong 2-byte sequence: c0 af
overlong 3-byte sequence: e0 af
overlong 4-byte sequence: f0 80 80 af
overlong 5-byte sequence: f8 80 80 80 af
overlong 6-byte sequence: fc 80 80 80 80 af
Enter an ASCII char to make overlong, or hex (ex: h27) or 'quit': ]
char []] dec [93] hex [5d] url: %5d
overlong 2-byte sequence: c1 9d
overlong 3-byte sequence: e1 9d
overlong 4-byte sequence: f1 80 80 9d
overlong 5-byte sequence: f9 80 80 80 9d
overlong 6-byte sequence: fd 80 80 80 80 9d
Enter an ASCII char to make overlong, or hex (ex: h27) or 'quit': \
char [\] dec [92] hex [5c] url: %5c
overlong 2-byte sequence: c1 9c
overlong 3-byte sequence: e1 9c
overlong 4-byte sequence: f1 80 80 9c
overlong 5-byte sequence: f9 80 80 80 9c
overlong 6-byte sequence: fd 80 80 80 80 9c
Enter an ASCII char to make overlong, or hex (ex: h27) or 'quit': h0a
char [
] dec [10] hex [0a] url: %0a
overlong 2-byte sequence: c0 8a
overlong 3-byte sequence: e0 8a
overlong 4-byte sequence: f0 80 80 8a
overlong 5-byte sequence: f8 80 80 80 8a
overlong 6-byte sequence: fc 80 80 80 80 8a
Tuesday, August 17, 2010
Designing a testcase system for browsers | ブラウザによるテストケースシステムの設計
The testcase system is an important piece to the WBTS project. It went through a few design changes while I was working on it. It is made up of two parts, the client side and the server side.
Client Side
The client side code is just a single javascript object called TestCase. It allows you in your testcase to store the following information:
1. input: A quick summary of the input to your testcase like document.cookie = 0x00-0xff.
2. output: The output of the test, if there is any. You can supply your own html formatting as well.
3. description: A quick description of the test like: "Inject headers into xhr object"
4. target host: The host name you expect the request to becoming from (usually only used for SOP tests).
5. expected result: What you expect the result to be like: "null" or "exception"
6. result: The actual result of the test.
7. test passed: Did the test pass or fail? (Usually true or false).
There are two methods of running a test. For simple tests, you can fill out the object, run a test then just call the testcase objects saveTest method. For more complex, or dangerous testcases you can use the savePreTest method. This allows you to set up all the test information and store it in a temporary document. You then run the test. If the test causes the browser to stop, the blade automation system will call a failTest method, indicating that it was unable to complete. This also causes the temporary data to be copied into the real results database.
Here is an example testcase:
Lines 6-12 are used to ensure our testcase function "f" fires when the window finishes loading.
Lines 15-25 create a string of bytes to be used as input.
Line 26 URL decodes the data into their "raw" form.
Line 27 creates a cookie value.
Line 29 sets the testcase input (this will be directly visible in the results database).
Line 30 sets the description.
Line 31 is the actual test, creating a cookie for the document, then making a request to a special resource. After showRequest is called via XHR, the "save_test" call back function will have access to the response data and our testcase object.
Line 36 takes the response data and sets that as our output.
Line 37-38 tries to remove the cookie data.
Line 39 finally saves the test to our results database.
It should be noted, each testcase is called with a query parameter called client_id. This value is generated by the blade automation system and used for tracking purposes. A request to a testcase would look like: http://www.attacker.com/testcases/headertests/sometest.html?client_id=<some unique id>
Server Side
Our test case system is mapped to /tc/ on all virtual hosts. It offers three resources: saveTest, savePreTest, and failTest. They are not very complicated, they just take in the data as POST parameters. A few fields are base64 encoded for storage as it may contain invalid UTF-8 bytes which may cause MongoDB to throw an error. savePreTest will store data in a temporary database. The pretest data contains the testcase information configured for a failure result. This way, when failTest is called, it can just copy the information into our results database.
WBTSプロジェクトのためにテストケースシステムが大事。作りながら何回もデザインが変更した。テストケースシステムは二つの部分（クライアント側とサーバー側）がある。
クライアント側
クライアントサイドコードはTestCaseというのJavaScriptオブジェクトだけである。このオブジェクトが以下のような情報を保存する：
1. input（入力）: テストケースの簡単な概要。例：document.cookie ^ 0x00 - 0xff。
2. output （出力）: テストの出力。HTML様式もできる。
3. description: テストケースの説明。例： 「XHRオブジェクトにヘッダーをインジェクトする。」
4. target host: テストケースの実行されるホスト名。普段は、SOP専用
5. expected result(予想通りの結果）: 例: 「null」または「exception」
6. result （結果）: 実際のテスト結果。
7. test passed （テストの成否）: テストは失敗か正解だったか。普段は 「true」か「false」。
（上記のコードーを見て。）
Line 6-12 Windowがロードーするのを完成したら「ｆ」という関数を実行する。
Lines 15-25 テストの入力による、文字列を作成する。
Line 26 データーをURLデコードする。
Line 27 クッキー値を作成する。
Line 29 テストケースの入力を設定する。(この情報は結果DBで見られるようにする）
Line 30 説明を設定する。
Line 31 これが実際のテスト。ドキュメントのクッキーを作成、特別なWebリソースに呼び出す。XHRでshowRequestを呼び出した後は「save_test」のコールバック関数を呼び出す。この関数がレスポンス情報とTestCaseのオブジェクトにアクセスできる。
Line 36 レスポンス情報を出力に設定する。
Line 37-38 クッキーを削除する。
Line 39 テストの結果をDBに送信する。
実は、「client_id」と言うパラメーターは格テストケースに送信する。トラッキングのため、この「client_id」値はbladeシステムによって作られたものだ。例えば、下記のようなURLはテストケースのリクエスト。
http://www.attacker.com/testcases/headertests/sometest.html?client_id=<some unique id>
サーバー側
テストケースシステムは全部のVirtualHostsで「/tc/」にマップした。このシステムは三つのリソース「saveTest」、「savePreTest」、「failTest」を実装する。そんなに複雑ではない。POSTでのパラメーターだけ受信する。テスト結果が不正なUTF-8バイトを持っているかもうしれないので、多少のDBフィールドはbase64エンコードする必要がある。エンコードしないと、MongoDBがエラーを発生する。「savePreTest」リソースはテストデータをDBに一時的に保存する。テストが失敗する場合、bladeシステムは「failTest」に呼び出すと一時的なDBから結果DBにコピーされる。
Client Side
The client side code is just a single javascript object called TestCase. It allows you in your testcase to store the following information:
1. input: A quick summary of the input to your testcase like document.cookie = 0x00-0xff.
2. output: The output of the test, if there is any. You can supply your own html formatting as well.
3. description: A quick description of the test like: "Inject headers into xhr object"
4. target host: The host name you expect the request to becoming from (usually only used for SOP tests).
5. expected result: What you expect the result to be like: "null" or "exception"
6. result: The actual result of the test.
7. test passed: Did the test pass or fail? (Usually true or false).
There are two methods of running a test. For simple tests, you can fill out the object, run a test then just call the testcase objects saveTest method. For more complex, or dangerous testcases you can use the savePreTest method. This allows you to set up all the test information and store it in a temporary document. You then run the test. If the test causes the browser to stop, the blade automation system will call a failTest method, indicating that it was unable to complete. This also causes the temporary data to be copied into the real results database.
Here is an example testcase:
Lines 6-12 are used to ensure our testcase function "f" fires when the window finishes loading.
Lines 15-25 create a string of bytes to be used as input.
Line 26 URL decodes the data into their "raw" form.
Line 27 creates a cookie value.
Line 29 sets the testcase input (this will be directly visible in the results database).
Line 30 sets the description.
Line 31 is the actual test, creating a cookie for the document, then making a request to a special resource. After showRequest is called via XHR, the "save_test" call back function will have access to the response data and our testcase object.
Line 36 takes the response data and sets that as our output.
Line 37-38 tries to remove the cookie data.
Line 39 finally saves the test to our results database.
It should be noted, each testcase is called with a query parameter called client_id. This value is generated by the blade automation system and used for tracking purposes. A request to a testcase would look like: http://www.attacker.com/testcases/headertests/sometest.html?client_id=<some unique id>
Server Side
Our test case system is mapped to /tc/ on all virtual hosts. It offers three resources: saveTest, savePreTest, and failTest. They are not very complicated, they just take in the data as POST parameters. A few fields are base64 encoded for storage as it may contain invalid UTF-8 bytes which may cause MongoDB to throw an error. savePreTest will store data in a temporary database. The pretest data contains the testcase information configured for a failure result. This way, when failTest is called, it can just copy the information into our results database.
WBTSプロジェクトのためにテストケースシステムが大事。作りながら何回もデザインが変更した。テストケースシステムは二つの部分（クライアント側とサーバー側）がある。
クライアント側
クライアントサイドコードはTestCaseというのJavaScriptオブジェクトだけである。このオブジェクトが以下のような情報を保存する：
1. input（入力）: テストケースの簡単な概要。例：document.cookie ^ 0x00 - 0xff。
2. output （出力）: テストの出力。HTML様式もできる。
3. description: テストケースの説明。例： 「XHRオブジェクトにヘッダーをインジェクトする。」
4. target host: テストケースの実行されるホスト名。普段は、SOP専用
5. expected result(予想通りの結果）: 例: 「null」または「exception」
6. result （結果）: 実際のテスト結果。
7. test passed （テストの成否）: テストは失敗か正解だったか。普段は 「true」か「false」。
（上記のコードーを見て。）
Line 6-12 Windowがロードーするのを完成したら「ｆ」という関数を実行する。
Lines 15-25 テストの入力による、文字列を作成する。
Line 26 データーをURLデコードする。
Line 27 クッキー値を作成する。
Line 29 テストケースの入力を設定する。(この情報は結果DBで見られるようにする）
Line 30 説明を設定する。
Line 31 これが実際のテスト。ドキュメントのクッキーを作成、特別なWebリソースに呼び出す。XHRでshowRequestを呼び出した後は「save_test」のコールバック関数を呼び出す。この関数がレスポンス情報とTestCaseのオブジェクトにアクセスできる。
Line 36 レスポンス情報を出力に設定する。
Line 37-38 クッキーを削除する。
Line 39 テストの結果をDBに送信する。
実は、「client_id」と言うパラメーターは格テストケースに送信する。トラッキングのため、この「client_id」値はbladeシステムによって作られたものだ。例えば、下記のようなURLはテストケースのリクエスト。
http://www.attacker.com/testcases/headertests/sometest.html?client_id=<some unique id>
サーバー側
テストケースシステムは全部のVirtualHostsで「/tc/」にマップした。このシステムは三つのリソース「saveTest」、「savePreTest」、「failTest」を実装する。そんなに複雑ではない。POSTでのパラメーターだけ受信する。テスト結果が不正なUTF-8バイトを持っているかもうしれないので、多少のDBフィールドはbase64エンコードする必要がある。エンコードしないと、MongoDBがエラーを発生する。「savePreTest」リソースはテストデータをDBに一時的に保存する。テストが失敗する場合、bladeシステムは「failTest」に呼び出すと一時的なDBから結果DBにコピーされる。
Friday, June 25, 2010
Linux GUI Automation | Linux GUI オートメーション
Recently, I've been researching UI automation in linux for driving web browsers. So naturally, I wanted to find a python library for doing this. I found two libraries, dogtail and ldtp for automation in python. Both use the AT-SPI Accessibility functionality for finding controls (like textboxes/buttons). I chose LDTP because dogtail has not been updated in 4 years. Also, a lot of dogtail's code seems to be unimplemented or not working. Since I am automating browsers, I'd like to show you how to automate the following:
1. Start Firefox
2. Type in a URL
3. Look for a pop up and close it if it exists.
4. If a pop up exists, go to a new url.
I will also use twisted python and setup a LoopingCall to monitor for the popups.
See the code below.
So let's review the code.
Line 27: Use ldtp to launch firefox.
Line 28: Create a LoopingCall task using our check_dlgs function.
Line 29: Set that function to be called every 3 seconds. (False says don't call now)
Line 30: Tell the twisted reactor to call 'typestuff' function in 1 second.
Line 24: typestuff is called. ldtp can use regex's for finding window names. Spaces and special characters are removed from the name. The name of the URL bar control is 'txtSearchBookmarksandHistory' and url is the text we want to enter.
Line 25: Type enter (we have focus on this window)
Line 15: 3 seconds pass and we should be at the popup.html URL. It is a dialog and the title is 'The page at 192.168.0.196:8080 says...' but we can just use the regex.
Line 17: Hit enter (activates the OK button)
Line 18. Go to a new URL
Lines 9-11: Do the same process to go to a new url.
Line 21: Stop reactor and quit.
Pretty neat huh?
最近、Webブラウザを動かせるのために、LinuxでのUIオートメーションを勉強している。もちろん、Pythonでのライブラリを欲しかったのでそれを探した。二つのライブラリを見つかった、「dogtail」と「ldtp」というのオートメーションライブラリがある。UIのコントロール（テクストボックスとかボタンなど）の探すよるに両方のライブラリがAT-SPIの機能を利用する。多くのdogtailコードが不実装か壊れたからLDTPを選んだ。それと、dogtailの最後のアップデートが4年前だった。今ブラウザのオートメーションを勉強するから以下のようなコードで自動的にブラウザでURLに動かせる。
1．Firefoxを起動
2．URLを入力する
3．ダイアログボックス存在する場合、自動的に閉じる。
4．ボックスを閉じ、新しいURLを入力する。
Twisted PythonのLoopingCallでFirefoxのダイアログボックスを存在すれば、自動的に閉じる。
上記のコードをレビューしましょうか？
Line 27: LDTPでFirefoxを起動
Line 28: check_dlgs関数でLoopingCallを造る。
Line 29: その関数が毎3秒後呼び出す。（Falseの値の意味は｢今呼び出さない」ということです）
Line 30: twisted reactorは1秒後、typestuff関数を呼び出す。
Line 24: typestuffを呼び出した。LDTPは正規表現を使う上でWindow名を探せる。スペース字と記号文字が抜いている。URLのテクストボックスの名前は「txtSearchBookmarksandHistory」というです。「url」はWebアドレスです。
Line 25: リターンを押す。（FirefoxのWindowはフォーカスがある）
Line 15: 3秒後は「popup.html」のページに着きました。ダイアログボックスの名前は「The page at 192.168.0.196:8080 says...」ですが、正規表現を使える。
Line 17: リターンを押す。（OKボタンを押す）
Line 18: 新しいURLに動く。
Lines 9-11: また、同じプロセスで新しいURLに動く。
Line 21: reactorを停止して、プロセスも停止。
カッコイイじゃないの？
1. Start Firefox
2. Type in a URL
3. Look for a pop up and close it if it exists.
4. If a pop up exists, go to a new url.
I will also use twisted python and setup a LoopingCall to monitor for the popups.
See the code below.
So let's review the code.
Line 27: Use ldtp to launch firefox.
Line 28: Create a LoopingCall task using our check_dlgs function.
Line 29: Set that function to be called every 3 seconds. (False says don't call now)
Line 30: Tell the twisted reactor to call 'typestuff' function in 1 second.
Line 24: typestuff is called. ldtp can use regex's for finding window names. Spaces and special characters are removed from the name. The name of the URL bar control is 'txtSearchBookmarksandHistory' and url is the text we want to enter.
Line 25: Type enter (we have focus on this window)
Line 15: 3 seconds pass and we should be at the popup.html URL. It is a dialog and the title is 'The page at 192.168.0.196:8080 says...' but we can just use the regex.
Line 17: Hit enter (activates the OK button)
Line 18. Go to a new URL
Lines 9-11: Do the same process to go to a new url.
Line 21: Stop reactor and quit.
Pretty neat huh?
最近、Webブラウザを動かせるのために、LinuxでのUIオートメーションを勉強している。もちろん、Pythonでのライブラリを欲しかったのでそれを探した。二つのライブラリを見つかった、「dogtail」と「ldtp」というのオートメーションライブラリがある。UIのコントロール（テクストボックスとかボタンなど）の探すよるに両方のライブラリがAT-SPIの機能を利用する。多くのdogtailコードが不実装か壊れたからLDTPを選んだ。それと、dogtailの最後のアップデートが4年前だった。今ブラウザのオートメーションを勉強するから以下のようなコードで自動的にブラウザでURLに動かせる。
1．Firefoxを起動
2．URLを入力する
3．ダイアログボックス存在する場合、自動的に閉じる。
4．ボックスを閉じ、新しいURLを入力する。
Twisted PythonのLoopingCallでFirefoxのダイアログボックスを存在すれば、自動的に閉じる。
上記のコードをレビューしましょうか？
Line 27: LDTPでFirefoxを起動
Line 28: check_dlgs関数でLoopingCallを造る。
Line 29: その関数が毎3秒後呼び出す。（Falseの値の意味は｢今呼び出さない」ということです）
Line 30: twisted reactorは1秒後、typestuff関数を呼び出す。
Line 24: typestuffを呼び出した。LDTPは正規表現を使う上でWindow名を探せる。スペース字と記号文字が抜いている。URLのテクストボックスの名前は「txtSearchBookmarksandHistory」というです。「url」はWebアドレスです。
Line 25: リターンを押す。（FirefoxのWindowはフォーカスがある）
Line 15: 3秒後は「popup.html」のページに着きました。ダイアログボックスの名前は「The page at 192.168.0.196:8080 says...」ですが、正規表現を使える。
Line 17: リターンを押す。（OKボタンを押す）
Line 18: 新しいURLに動く。
Lines 9-11: また、同じプロセスで新しいURLに動く。
Line 21: reactorを停止して、プロセスも停止。
カッコイイじゃないの？
Monday, June 21, 2010
Introducing... WBTS | WBTSの紹介
For those that know me, probably know I've been working a lot on a personal project called WBTS. WBTS is a Web Browser Testing System for finding bugs. I built it using the twisted python framework. But what exactly is WBTS?
1. A cross-platform web application server supporting SSL, Virtual Hosts, processors for various web languages and the ability to include your own. All built on python's stupid fast Twisted framework.
2. A built in DNS server to allow records to be created on the fly, as well as built-in DNS
rebinding functionality accessible via web requests.
3. A cross-browser JavaScript test case framework that allows you to quickly create new test cases for various browser bugs using different automation methods. The framework hooks into MongoDB to store the results in an easily search-able data store.
4. Lots of test cases both from public sources such as WebKit's LayoutTests, old known
browser vulnerabilities taken from Mozilla Firefox's and Google Chrome's bug tracker
systems as well as ones created by myself.
5. A slick management Web UI to review test results and configure WBTS.
6. Future plans to implement a fully featured fuzzing framework.
See the screen shots below!
たぶん知ってるけど、最近僕はWBTSというプログラムを作っている。WBTSというのは脆弱性を見つけるためのウェブブラウザテスティングシステムです。このアプリケーションはTwisted Pythonのフレームワークで作ったものだ。でも、WBTSとは何でしょか？
1. SSL,VirtualHosts,自分の好きな言語をサポートされているクロスプラットホームのWebアプリケーションサーバーです。
2. 組み込みDNSサーバーが一瞬的に記録を作られ、WebのURIアクセスすると、DNSリバインディング攻撃ができる。
3. 複数のオートメーション方法で簡単にテストケースを作られるクロスブラウザテストケースシステム。このシステムがテストの結果をMongoDBに保存します。
4. WebKitのLayoutTests、古いのMozillaとChromeの脆弱性と自分の作ったのたくさんのテストケースが入っている。
5. カッコイイWebUIで結果をレビューし、WBTSの設定も簡単にできる。
6. Fuzzingシステムを作る予定もある。
以下のようなWBTSの画像を見てください！
1. Cross Platform UI! (Windows) | クロスプラットホームUI! （windows版）
2. DNS Server Settings | DNSサーバーの設定
3. Test case results | テストケースの結果
4. Various WBTS Settings | いろいろなWBTSの設定
1. A cross-platform web application server supporting SSL, Virtual Hosts, processors for various web languages and the ability to include your own. All built on python's stupid fast Twisted framework.
2. A built in DNS server to allow records to be created on the fly, as well as built-in DNS
rebinding functionality accessible via web requests.
3. A cross-browser JavaScript test case framework that allows you to quickly create new test cases for various browser bugs using different automation methods. The framework hooks into MongoDB to store the results in an easily search-able data store.
4. Lots of test cases both from public sources such as WebKit's LayoutTests, old known
browser vulnerabilities taken from Mozilla Firefox's and Google Chrome's bug tracker
systems as well as ones created by myself.
5. A slick management Web UI to review test results and configure WBTS.
6. Future plans to implement a fully featured fuzzing framework.
See the screen shots below!
たぶん知ってるけど、最近僕はWBTSというプログラムを作っている。WBTSというのは脆弱性を見つけるためのウェブブラウザテスティングシステムです。このアプリケーションはTwisted Pythonのフレームワークで作ったものだ。でも、WBTSとは何でしょか？
1. SSL,VirtualHosts,自分の好きな言語をサポートされているクロスプラットホームのWebアプリケーションサーバーです。
2. 組み込みDNSサーバーが一瞬的に記録を作られ、WebのURIアクセスすると、DNSリバインディング攻撃ができる。
3. 複数のオートメーション方法で簡単にテストケースを作られるクロスブラウザテストケースシステム。このシステムがテストの結果をMongoDBに保存します。
4. WebKitのLayoutTests、古いのMozillaとChromeの脆弱性と自分の作ったのたくさんのテストケースが入っている。
5. カッコイイWebUIで結果をレビューし、WBTSの設定も簡単にできる。
6. Fuzzingシステムを作る予定もある。
以下のようなWBTSの画像を見てください！
1. Cross Platform UI! (Windows) | クロスプラットホームUI! （windows版）
2. DNS Server Settings | DNSサーバーの設定
3. Test case results | テストケースの結果
4. Various WBTS Settings | いろいろなWBTSの設定
Thursday, April 22, 2010
eXternal Xml Entities - 外部XMLエンティティ
You probably know all about XXE attacks. They've been around for years. There's even an OWASP page dedicated for testing Xml Injection bugs. In the past 2 months I have found this vulnerability in 3 separate applications. It appears that most xml processors are vulnerable by default if you are validating the XML. The most common fix is to replace the EntityResolver with an empty one. This is outlined for Java here and here for .NET. In some cases you can see the results. So I supply:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]>
<foo>&xxe;</foo>
And the server responds with:
Error parsing xml... blah blah:
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect
is not valid blah blah...
So what are the risks when I can't see the results? I'm glad you asked!
Here is what *I* think the risks are:
1. SMB Reflection attacks file:\\ip.ip.ip.ip/C$ (Windows only?)
2. Bypass of 'host based' protections... http://localhost/admin?newuser=...
2.a. Potential Access to unprotected internal systems http://someserver/user?command=new&user=...
3. Exploit vulnerabilities in client protocols (ftp, smb, http, https... etc) as they connect. Think fuzzing request/responses.
4. Exploit vulnerabilities in protocol handlers. telnet://ip.ip.ip.ip & cmd.exe ... Only http/file/ftp appear to be possible.
5. Discovery of allowed outbound ports via egress port scan http://ip.ip.ip.ip:1, http://ip.ip.ip.ip:2, http://ip.ip.ip.ip:3...
What do *you* think?
XXE攻撃を知ってるでしょうか。XXEは長年に公開の情報です。OWASPサイトではXMLインジェクション攻撃のページがあるから結構、よく知られているんじゃないでしょうか。二ヶ月間の間に三つのWebアプリでこの脆弱性を見つかった。XML構成をチェック（Validating）するなら、アプリケーションは脆弱みたいだ。
対策方法としては風通に新しい（外部のEntityを探さないように）Resolverに変更する。この対策方法はJavaの場合ここ、.NETの場合ここで説明する。攻撃する時に時々結果を見ないようにするケースある。例えば:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]>
<foo>&xxe;</foo>
サーバの返事が下のように:
エラーが発生しました。。。:
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect
構成が正しくありません。。。
でも、結果を見ない時もあるから、リスクは何でしょうか？質問ありがとう！
俺の場合は下のようにリスクがあると思う:
1. SMB Reflection(反映攻撃と言うかな？）file:\\ip.ip.ip.ip/C$ (Windows だけ?)
2. ホストでのアクセス予防の回避... http://localhost/admin?newuser=...
2.a. 守ってないの内部システムの攻撃... http://someserver/user?command=new&user=...
3. クライアント側(ftp, smb, http, https...等)での接続するときに脆弱性を攻撃する。リクエスト・レスポンスのFuzzingを考えたら。。。
4. プロトコールのハンドラの攻撃... telnet://ip.ip.ip.ip & cmd.exe... http/ftp/fileだけ使うみたい
5. 外部のアクセスできるポートスキャン: http://ip.ip.ip.ip:1, http://ip.ip.ip.ip:2, http://ip.ip.ip.ip:3...
どう思う？
Tuesday, April 13, 2010
.NET Controls
Investigating an issue today and learned something new. Microsoft chose to encode various ASP.NET controls differently. While some make sense, the entire list is pretty bizarre. Oh versions of ASP.NET also matter 1.1 is different than 2.0. Check out: http://msmvps.com/blogs/calinoiu/archive/2006/06/13/what-s-wrong-with-asp-net-html-encoding.aspx for a nice writeup. Still no updated list for 3.5 Framework though.
今日は新しいことを習うんだ。マイクロソフトはASP.NETのエンコーディングのやり方がコントロールと.NETバージョンによるみたいだ。ま、コントロールが違うからわかるけど、全部を見たら変じゃないかなっと思った。次のサイトはASP.NETの異常説明した: http://msmvps.com/blogs/calinoiu/archive/2006/06/13/what-s-wrong-with-asp-net-html-encoding.aspx.。でも、ASP.NET3.5のエンコーディングリストを見つかれなかった。
Thursday, April 8, 2010
Long time.. - 久しぶり。。。
It has been a while since I have updated this. I probably should seeing that I now that I quit Symantec and work for an American company www.veracode.com. I still live in japan but, i don't really use my Japanese much these days. Expect some new interesting technical stuff here soon!
久しぶりですね、ぜんぜん書いてないこれ。シマンテックを辞めて、Veracodeに勤めている。まだ日本に住んでいるが日本語をあまり使わない。なので、日本語の練習のために書いたほうがいいよね。そろそろ、新しい技術的なことを書くからもうちょっと待ってください！
Subscribe to:
Posts (Atom)