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を停止して、プロセスも停止。

カッコイイじゃないの？

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の設定

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...

どう思う？

.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のエンコーディングリストを見つかれなかった。

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に勤めている。まだ日本に住んでいるが日本語をあまり使わない。なので、日本語の練習のために書いたほうがいいよね。そろそろ、新しい技術的なことを書くからもうちょっと待ってください！

.WAR Games - .WAR ゲームズ

So lets talk about .WARs, if you see my previous post you will know they are simply web application archive files. They are zip files that contain all the necessary components (jsp/images/html/java classes) that are required for the web application to work. Lets go over the structure, ascii-style. And by ascii, I mean a bitmap of ascii art.


Yeah that looks Terrible. Anyways, so thats the structure of the .WAR file. How do you extract it? I mentioned earlier it is simply a zip file, you can exact it via an unzip program, or with java provided you installed the latest JDK. If the java directory is in your path, you can just do "jar -xf .war" without the quotes. Let's do a trial run here and download Some Random Java Application. Just download the ginp.war file. Once that is completed, unzip the file, and you should see a directory structure similiar to the one I described above. Always go directly to the WEB-INF/ directory and open the web.xml first. Let's pull out a servlet's details...
<servlet-name>ginp Controller Servlet</servlet-name>
...
<servlet-class>net.sf.ginp.GinpServlet</servlet-class>
...
<servlet-mapping>
<servlet-name>ginp Controller Servlet</servlet-name>
<url-pattern>/styles/backinblack/ginpservlet</url-pattern>
</servlet-mapping>

So the ginp Controller Servlet is mapped to a url /styles/backinblack/ginpservlet. This means we can access it via: http://thehost/appname/styles/backinblack/ginpservlet. Easy as that.
It may take some parameters, but we don't know, so lets look at the class.
Under servlet-class we see net.sf.ginp.GinpServlet, so if we go into the WEB-INF directory, then classes/net/sf/ginp/ directory we can see none other than... GinpServlet.class!
Lets decompile the class with Jad. From the /ginp/ directory run the command (provided jad is in your path):
C:\Documents and Settings\eff.bee.eye\Desktop\kougeki\ginp\WEB-INF\classes\net\s
f\ginp>jad -8 -s .java GinpServlet.class
Parsing GinpServlet.class... Generating GinpServlet.java
Couldn't resolve all exception handlers in method doHttpMethod
Couldn't fully decompile method _mthclass$
Couldn't resolve all exception handlers in method _mthclass$

Most servlets process GET requests and forward them to a POST (doPost) method. This one just forwards it to another method doHttpMethod. We're starting to see a number of classes being referenced outside our initial servlet. When this happens, it's usually a good idea to just decompile the entire package:
C:\Documents and Settings\eff.bee.eye\Desktop\kougeki\ginp\WEB-INF\classes>jad -8 -s .java -r */**/*.class
Parsing net/sf\ginp/CommandParameter.class... Generating net\sf\ginp\CommandParameter.java
....
From here we would begin to do a code-review to identify areas of potential vulnerability but, I think we will leave code-reviewing for the next installment! Until then!

.WARの話しましょう。前の記事を見たらWARファイルはWebアプリケーションアーカイブを知っています。アプリケーションの実行するためにWARは 必要なファイル（JSP/画像/HTML/Javaクラス）を含んでいるZipファイルです。　ASCIIスタイルでWARのディレクトリ構成をレビュー します。実はASCIIスタイルというのはbitmap画像です。


↑見た目が本当に悪いですよね。上記の画像はWARファイルの構成の説明です。どの方法でアーカイブから解凍しますか。前の時、zipファイルだと言ったので、Unzipプログラムで解凍するか、JavaのJDKをインストールしたらJarアプリでも解凍できます。 Javaパースを環境値に含んでいる場合、”jar -xf [appname].war"のコマンドを実行すると、自動的に解凍します。試しに適当なJavaアプリケーションを探して、サイトからginp.warファイルをダウンロードします。そのあと、解凍すると、上記構成のように見えます。いつも、初めにWEB-INFディレクトリのweb.xml設定ファイルを開きます。最初のJavaサーブレットを見ましょう。
<servlet-name>ginp Controller Servlet</servlet-name>
...
<servlet-class>net.sf.ginp.GinpServlet</servlet-class>
...
<servlet-mapping>
<servlet-name>ginp Controller Servlet</servlet-name>
<url-pattern>/styles/backinblack/ginpservlet</url-pattern>
</servlet-mapping>

ginp Controller Servletは/styles/backinblack/ginpservletに参照します。そのurl-patternの値が存在するので、直接ブラウザーでhttp://thehost/appname/styles/backinblack/ginpservletへアクセスできます。
それは簡単です。そのサーブレットはパラメータが必要かもしれないので、Javaクラスを見ましょう。　servlet-classの値でnet.sf.ginp.GinpServletがあるので、WEB-INF/classes/net/sf/ginpのディレクトリに入って、GinpServlet.classファイルを見ます。このクラスファイルをJadでディコンパイルしましょう。「/ginp」ディレクトリで（Jadプログラムを環境値にパース入っている場合）以下のコマンドを実行します。

C:\Documents and Settings\eff.bee.eye\Desktop\kougeki\ginp\WEB-INF\classes\net\s
f\ginp>jad -8 -s .java GinpServlet.class
Parsing GinpServlet.class... Generating GinpServlet.java
Couldn't resolve all exception handlers in method doHttpMethod
Couldn't fully decompile method _mthclass$
Couldn't resolve all exception handlers in method _mthclass$

殆どのサーブレットはHTTPのGETメソッドを受付すると、POSTメソッド（JavaのdoPostメソッド）に転送します。このアプリは両方のメソッドを他のJavaメソッドdoHttpMethodに転送します。GinpServletは複数のクラスに
このGinpServletクラスを理解するには、クラスファイル内の複数の参照を見る必要があるので、全てのアプリケーション名前空間ファイルをディコンパイルしたら良いです。
C:\Documents and Settings\eff.bee.eye\Desktop\kougeki\ginp\WEB-INF\classes>
jad -8 -s .java -r */**/*.class
Parsing net/sf\ginp/CommandParameter.class... Generating net\sf\ginp\CommandParameter.java
ここから可能な脆弱性を発見するために、コードレビューをしますが、今度の記事でコードレビュー方法を説明します。それまで！

TASPO came! - TASPO着きました！

So, I'm a smoker (until I have kids, then I quit) . In Japan, cigarette vending machines now require a RFID card called TASPO before they allow you to buy cigarettes. Because they are free to get, I figured they would use a cheap system. I was right, they use MIFARE. How do I know? I put the card on my SCM Smart Card reader and it gave me the following information:
僕はタバコを吸う人です（子供を出来たら止めます）。今、日本ではタバコを買う前にタバコ自動販売機がTAPSOと言うRFIDカードが必要です。カードは無料なので、RFIDシステムはお金が掛からないシステムを使っていると思いました。僕は正解です。TASPOシステムはMIFAREを使います。（MIFAREは安い）何で僕はシステムがMIFAREを使っているのかわかるか？TASPOカードをSCMのスマートカードリーダの上に置くと以下の情報を読み込めました：
Unfortunately, I do not know the key so I can not authenticate to the card. If I could authenticate, I could add up to 200$ on the card and buy cigarettes for free. This is not a good thing, because well, MIFARE has been cracked already. For a non-technical explanation please read this url. For a technical explanation see this one. So how do you authenticate to a MIFARE card? Well you need a smart card reader, and either RFIdiot or tools that come with the reader (I just use the ones from my SCM reader.) Here's a simple table of commands:
残念ですが、TASPOカードの認証鍵わからないので、ログインできませんでした。もし、出来たら、カードの金額を追加し、無料でタバコを買えます。でも、誰かが既にMIFAREの暗号アルゴリズムをクラックしたので、鍵情報は必要ありません。これは本当にだめです。簡単な説明を見たい場合このURLを読んでください。もっと難しい説明を読みたい場合、このURLを読んでください。ところで、もし、鍵値を知っている場合、MIFAREカードのログインプロセスは何でしょうか。スマートカードリーダーとRFIDiot(ツール）かリーダーのツール（僕のSCMリーダーのツールを使う）を使います。RFIDのコマンドの表は以下のようになります。

To authenticate、 we would send 0xFC 0x20 0x60 0x00 0x06 [key] where [key] is a 6 byte value such as FFFFFFFFFF,000000000000, etc. I tried simple ones, but I imagine the keys are based off of some custom algorithm. Anyways, that was just a quick post on TASPO, if I do additional research I'll post it later.
ログインプロセスは「0xFC 0x20 0x60 0x00 0x06 ＜鍵＞」のバイトを送信します。鍵は６のバイトので、FFFFFFFFFF,000000000000の形です。僕は簡単な鍵値を推測試みたが、出来ませんでした。たぶん、鍵値がカスタムアルゴリズムで基づくかもしれないんです。もし、さらにリサーチした場合、後で追記します。