Date: Mon, 01 Aug 2005 09:08:55 +0100
From: Dinis Cruz <dinis@...lus.net>
To: Florian Weimer <fw@...eb.enyo.de>
Cc: security-announce@...ts.enyo.de, full-disclosure@...ts.grok.org.uk,
	vulnwatch@...nwatch.org, bugtraq@...urityfocus.com,
	owasp-dotnet@...ts.sourceforge.net
Subject: Re: [VulnWatch] The Java applet sandbox and
	stateful firewalls


Is the Java Sandbox able to create outgoing connections on ports like 445?

Also, even if it is possible, if a service like MS-SQL is already binded 
to 1433, then wouldn't an error be thrown saying something like 'Port 
already in use'.

That said, this is a very interesting concept, and a real vulnerability 
in any 'stateful protected system' if one is able to create TCP (or UDP) 
packets with explicit return ports (I will try to replicate this in .NET 
and will post here my results)

Dinis Cruz
.Net Security Consultant


Florian Weimer wrote:

>The Java/Firewall vulnerability
>===============================
>
>Current version: <http://www.enyo.de/fw/security/java-firewall/>
>
>The Java sandbox for applets and stateful firewalls interact in a
>surprising way. As a result, external hosts can initiate TCP
>connections to supposedly protected network services.
>
>* Attack Requirements
>
>This is a passive attack. The attacker must lure the victim to a
>carefully crafted web page. The victim's web browser must download and
>execute the embedded Java applet. The victim's computer must offer
>some vulnerable networking service, and a stateful firewall must
>prevent access to this service from the Internet.  Impact
>
>An attacker can gain access to potentially vulnerable network services
>which are located behind firewall and/or NAT devices, so that direct
>access is impossible.
>
>* Severity
>
>This is a passive vulnerability which can only be used as a stepstone
>for further attacks. As a result, the risk posed by this vulnerability
>alone is fairly low.
>
>* Technical Description
>
>The attack is carried out as follows.
>
>   1. The attacker creates a specifically crafted web site.
>
>   2. She lures the victim to visit this web site.
>
>   3. The victim's browser downloads the applet and begins to run it.
>
>   4. The applet initiates a TCP connection back to the originating
>      web server, on port 21 (used by FTP, RFC 959). This connection
>      is permitted according to the standard Java sandbox model for
>      applets.  5.
>
>      A FTP server on the same machine that hosts the originating web
>      site answers.
>
>   6. The applet continues to pose as an FTP client, logs in and
>      issues an FTP PORT command, which prepares an active FTP
>      connection. The TCP port specified in the command refers to some
>      existing TCP service, such as 445/TCP (SMB over TCP) or 1433/TCP
>      (Microsoft SQL Server, MSDE). This port is chosen by the
>      attacker.
>
>   7. The firewall between the attacker and the victim recognizes this
>      command and prepares to open a second connection for the FTP
>      data transfer.
>
>   8. The applet issues a FTP command which requests the data
>      transfer, for example a LIST command.
>
>   9. The attacker uses her server to initiate a TCP connection to the
>      port indicated in the PORT on the victim host. The firewall
>      passes through the connection, assuming that it is a legitimate
>      FTP data transfer.
>
>This attack exploits the fact that the Java security model for applet
>assumes that arbitrary TCP connections back to the server pose no
>risks. However, the presence of stateful firewalls or NAT devices with
>heuristic FTP protocol modules between the involved hosts invalidates
>this assumption because TCP connections back to the originating
>servers do have side effects.
>
>This is not an error in the Java implementation or in the firewall
>implementation. Both programs implement their respective
>specifications. Even the specifications themselves are not inherently
>flawed. Only the combination of these two components creates a
>vulnerable configuration. This stresses an important point about
>secure systems: Security does not compose, and classic
>divide-and-conquer approaches do not necessarily result in complete
>systems which are secure.
>
>The attack differs from previous attacks using POST requests to ports
>such as 21/FTP. Such attacks could be detected by the firewall and
>stopped. In contrast, the Java applet could implement a
>fully-compliant FTP client, and the firewall cannot tell whether an
>FTP data transfer was initiated by a rogue Java applet or a legitimate
>FTP client controlled by the user.
>
>* Workarounds
>
>    * Use clients that do not support active client such as Java
>      applets.
>
>    * In firewalls, do not use heuristic approaches to stateful
>      filtering. Complex protocols should be handled by application
>      layer gateways that actually understand the protocols they are
>      letting through.
>
>Note that in principle, this vulnerability is not specific to Java or
>FTP protocol helpers (see below). A more general approach to eradicate
>this problem is therefore necessary.
>
>* Proof of concept
>
>A simple TCP server which emulates FTP and a corresponding Java applet
>is provided on the web: <http://www.enyo.de/fw/security/java-firewall/>
>
>* Open questions
>
>Some questions need further examination.
>
>    * Other implementations of mobile code might be used to carry out
>      the attack. For example, it could be possible that Flash objects
>      can achieve the same effect.
>
>    * The vulnerability is not inherently FTP-related. FTP is used
>      here because its active mode is widely used because it is the
>      default mode in a widely-used web browser, and stateful filters
>      usually implement heuristics to handle such FTP data
>      transfers. Other candidate protocols are IRC DCC, Sun and DCE
>      RPC, and in particular H.323 and SIP.
>
>    * We only tested one firewalling implementation (a custom-compiled
>      Linux 2.6 kernel and an OpenWRT Linux kernel, both with NAT
>      enabled). Other firewall implementations might enforce further
>      restriction and restrict the data flow on the FTP data
>      connection, which slightly mitigates the impact of this
>      vulnerability.
>
>    * Maybe it is possible to introduce a method by which Java virtual
>      machines can mark outgoing connections initiated by untrusted
>      applets. Even though the protocol described in RFC 3514 could be
>      used for this purpose, significant code changes are needed, and
>      it is not clear if this vulnerability is worth the complexity of
>      such a solution.
>
>* Acknowledgments
>
>Bastian Blank wrote the Java applet which demonstrates this
>exploitation technology. The applet contains source code copied from
>the GNU Classpath project.
>
>* Revisions
>
>2005-07-30 22:00: published
>
>  
>


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists