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の形です。僕は簡単な鍵値を推測試みたが、出来ませんでした。たぶん、鍵値がカスタムアルゴリズムで基づくかもしれないんです。もし、さらにリサーチした場合、後で追記します。

Attack Surface 攻撃サーフィス

Before we get into the specifics of attacking a J2EE server lets quickly touch on the topic of attack surfaces. What is an attack surface? It's basically all of the points or areas that an attacker can access a system or application. It is very important for both attackers and defenders to know their applications attack surface. You can not protect what you don't know exists. As a defender, you want to have the smallest possible attack surface. As an attacker, you want to identify areas the defender may have missed, or did not consider as being a potential attack vector. Lets use a generic J2EE application server as our example.
Breaking down the possible attack surfaces:
1. HTTP Server Instances - Most application servers have multiple HTTP/HTTPS instances running.

• - Admin Instance, most come with a web management interface.
• - Example Content Instances, sometimes developers leave the example content http instances accessible.
• - User Created Instance(s), for hosting individual applications that the developers created.

2. ORB-IIOP listener - Most enterprise j2EE application servers have some sort of IIOP listener.　These are accessible via remote clients through RMI-IIOP.
3. JMX-RMI management ports - These are accessible remotely by clients (usually they come with the application server installation) over the Java Remote Method Protocol (JRMP).
4. JMS Service - Java Message Service, These are also accessible remotely by clients, the server software usually comes with a client that you can use to connect.
5. JDBC service - Some application servers come with their own database service, you'll commonly see Apache's Derby DB. (http://db.apache.org/derby/)

Depending on the application server, you may see more or less than this. These are just the ones I commonly see in large (enterprise level) J2EE application servers. So we just went from thinking our J2EE server only had HTTP services to attack, to identifying four additional places that may contain vulnerabilities.

J2EEのハッキング方法の話前に攻撃サーフィスを話します。攻撃サーフィスと言うのは何でしょうか。基本的に攻撃者がアプリケーションやシステムのアクセス（攻撃）できる所です。
攻撃者やディフェンダーとしても、攻撃サーフィスの知識は本当に大事です。攻撃サーフィスがわからないと守れません。ディフェンダーとしては攻撃サーフィスが小さいほどより良いです。
攻撃者としてはアプリケーション内のディフェンダーの気づかない所を見つけれなければなりません。以下の例は普通のJ2EEアプリケーションサーバーです。
1. HTTPサーバーインスタンス　－　殆どのアプリケーションサーバーは複数のHTTP・HTTPSのインスタンスを実行されます。

• 管理インスタンス　－　殆どのサーバーは管理者コンソールがあります。
• サンプルコンテンツのインスタンス　－　時々、開発者はサンプルコンテンツのサーバーを実行のままにする。
• 開発のインスタンス －　アプリケーションの配備インスタンス。

2. ORB-IIOP リスナー - 殆どの企業アプリケーションサーバーはIIOPリスナー実行されます。RMI-IIOPでリモートクライアントをアクセスできます。
3. JMX-RMI 管理ポート - JRMPでリモートクライアントをアクセスできます。通常のサーバーはクライアントと一緒にインストールをします。
4. JMSサービス - Javaメッセージサービス、また、リモートクライアントでアクセスできます。
5. JDBCサービス - いくつかのサーバーはDBと一緒にインストールするので、サーバーをアクセスできるクライアントもインストールをします。殆どのサーバーがApacheのDerbyをインストールします。（http://db.apache.org/derby/、http://ja.wikipedia.org/wiki/Apache_Derby）

アプリケーションサーバーによって多かれ少なかれこのサービスにアクセスできます。僕の経験では企業のJ2EEサーバーで以上のリストを結構見ます。J2EEサーバーの攻撃サーフィスはHTTP・HTTPSだけではなく、複数あります。

J2EE Hacking Server First Steps - J2EEサーバーのハッキング紹介

So, you just downloaded and installed some j2ee server and you want to hack it. What are the first steps you should take? You should be aware of the application servers architecture, usually you can read the manuals to get a high level understanding of how it works. You'll probably see a bunch of ridiculous java terms being thrown around, so lets do a quick run down of what they are;

• JSP - Java Server Pages, a form of scripting that allows the developer to inter-mix HTML and Java code in the same file. Much the same as ASP, PHP and other Web Programming Languages.
• Web Services - Basically an API that is accessible over the HTTP protocol using standard HTTP methods. Client sends a request, the server processes it, runs some code and returns the results back to the client. Messages are commonly transfered in XML messages that follow the SOAP standard.
• SOAP - [Simple Object Access Protocol] is a protocol for exchanging XML messages to a Web Service.
• WSDL - Web Services Definition Language, yet another xml format for determining how a client should call a web service.
  
• JAR - Java ARchive, basically a zip file with all html, images, java classes, jsp pages required for an application.
  
• WAR - Web ARchive, Web Application Archive, same format as a JAR but specifically for web applications. Contains the web.xml configuration file along with classes, other jars and anything else required by the web application.
  
• EAR - Enterprise ARchive, basically an application that contains a bunch of web 'modules' that work together to form an enterprise application. Think of it as a container for multiple web application(s) and their components.
  
• EJB- Enterprise Java Bean, used for housing the 'business' or 'application' logic. It's a rather advanced architecture that is run inside of a J2EE server. It has its own specifications and API, please see sun's website: http://java.sun.com/products/ejb/.
• RMI - Remote Method Invocation, allows programmers to write objects in a distributed environment. These objects can be called remotely.
• ORB-IIOP - Object Request Broker Internet Inter-Orb Protocol, a communication protocol for two systems to access objects. This is a language neutral communication protocol. These are accessible via remote clients through RMI-IIOP. For more information on RMI-IIOP see: http://en.wikipedia.org/wiki/RMI-IIOP.
• JRMP - Java Remote Method Protocol, like ORB-IIOP but for one java application to access the objects of a different java applications.
• JMS - Java Message Service, an API for sending messages between two or more clients.
  
• JMX-RMI - Java Management eXtensions Remote Method Invocation is used for managing and monitoring the servers applications.
  
• JNI - Java Native Interface, Allows java code to integrated with code in other langauges such as C/C++. (Good for legacy systems).
  
• JAX-WS - Java API for XML Web Services, basically an API that utilizes XML messages for communication between the web service and the client.
• JSF - Java Server Faces, a framework for building MVC (Model View Controller) web applications. Competes with Apache Struts.
• JBI - Java Business Integration, a specification for implementing a SOA (Service Oriented Archeticture). JBI is built upon the web services model.
• And many more...

This is one reason I hate java so much, too many acronyms and specifications, most of which are quite useless.

Tools.
I'm not much of a 'tools' person, I prefer simple methods and if required, I write my own scripts. But there are a few I simply can not live without and as they relate to hacking J2EE apps and servers here's what I usually use.

• Burpsuite - A HTTP Intercepter Proxy tool. I've been using it for almost 6 years now and I still love it.
• Jad - Java Decompiler. A *must* for decompiling java bytecode.
• cygwin - I'm a windows guy, but I also know when Unix tools are better served ;>.
• SysInternals Procexp and Tcpview. Good to see which files and ports are in use by a process.
• More to come later.

Thats it for my quick introduction, later I'll be posting what to actually /do/ to figure out what vulnerabilities may exist in J2EE servers.

新しいJ2EEサーバーをダウンロード、インストールするとハッキングをしたくなりますよね。最初はどうするか。はじめに、サーバーのアーキテクチャの説明書を読んで、一般的な知識を得ればいいと思います。
確かに、おかしいJava言葉をばっかり見るのでちょっとレビューしますよ。

* JSP - (Java Server Pages) 開発者のためにHTMLとJavaスクリプトコード同じファイルに入れるWebスクリプティング言語です。これはASPやPHPやほかのWebプログラミング言語と同じです。
* Web Services - 基本的に、HTTPプロトコールでプログラミングAPI。クライアントはリクエストを送信し、サーバー側でコードを実行し、レスポンスを送ります。一般的に送信データの構成がSOAP標準構成で実装します。
* SOAP - （Simple Object Access Protocol）シンプルオブジェクトアクセスプロトコールはXMLメッセージをクライアントからサーバーに切り替えるプロトコールです。
* WSDL - （Web Services Definition Language） WebサービスデフィニションランゲージはXMLドキュメントでWebServiceの定義ファイルです。このファイルを理解すれば、クライアントはサーバーのWebサービスを使えます。
* JAR - （Java ARchive） アプリケーションのために、HTML、画像、Javaクラス、JSPファイルなど、必要なファイルをジップファイルに含むアーカイブです。
* WAR - （Web ARchive） WebアプリケーションアーカイブはJARと同じ構成ですが、Webアプリケーションのだけです。このアーカイブはweb.xmlコンフィグレーションファイル、Javaクラスファイル、JARファイルなどの必要ファイルを含むアーカイブです。
* EAR - （Enterprise ARchive）企業アプリケーションの関連Webモジュールを含むアプリケーションアーカイブです。複数のWebアプリケーションためのコンテナーとして用いられる。
* EJB- （Enterprise Java Bean）EJBは事務ロジックかアプリケーションロジックのための実装です。 結構上級なJ2EEサーバーでJavaBean実装です。 EJBのAPI説明書を見てください：http://java.sun.com/products/ejb/.
* RMI - (Remote Method Invocation)分散型環境のためJavaオブジェクトを作れます。 このオブジェクトはリモートから呼び出します。
* ORB-IIOP - (オブジェクトリクエストブローカーインターネットインターオアブプロトコール）このプロトコールは二つのシステムの間でオブジェクトを交換する。ORB-IIOPがプログラミング言語に依存していません。 IIOPの説明書を見てください：http://ja.wikipedia.org/wiki/IIOP.
* JRMP - （Java リモートメソッドプロトコール）ORB－IIOPのようですが、JRMPは他のJavaアプリケーションオブジェクトへアクセスするJavaアプリケーションのために使用される。
* JMS - （Java メッセージサービス） 二つ（もしくはそれ以上）のクライアントの間でメッセージを送信する。
* JMX-RMI - (Java Management eXtensions Remote Method Invocation)JMX－RMIはサーバーのアプリケーションを管理や監視のために使用される。
* JNI - （Java Native Interface） Javaコードは他の言語（C/C++)でインテグレートできるインタフェースです。 (古いシステムに良いです）。
* JAX-WS - （Java API for XML Web Services） クライアントとサーバーの送信に使用するためのXMLメッセージAPI.
* JSF - （Java Server Faces）Sun MicrosystemsのMVC（モデル、ビュー、コントローラー）のWebアプリケーションフレームワーク。JSFはApacheStrutsに対抗する。
* JBI - （Java Business Integration）SOA（サービス向けアーキテクチャ）の実装です。JBIはWebサービスモデルで作成された。
* その他

略語と仕様がたくさんあるので僕はJavaが嫌いです。殆どの仕様は役に立ちません。

ツール。
僕はツールばかり使う人ではありません。僕の意見は簡単な方法でハッキングすることが一番良いと思います。もし、必要ならば、自分でツールやスクリプトを作ります。でも、J2EEアプリケーションとサーバーをハッキングするため、必要なツールをもちろん使います。
以下参照：

• Burpsuite - HTTPのインターセプタープロクシツール。 ６年間使用中、かなり気にいってます。
• Jad - Javaデコンパイラ。Javaバイトコードをデコンパイルするために使う必要があります。
• cygwin - 僕はWindowsの方が好きですが、Unixツールを使う時も多いです。
• SysInternals - ProcexpとTcpview。このツールの目的はどのファイルやどのポートをプロセスに使うか検索します。
• 随時追加。

以上ですが、次回はJ2EEのハッキングやり方と脆弱性の見つけ方を説明します。