The OpenNET Project
 
Search (keywords):  SOFT ARTICLES TIPS & TRICKS SECURITY
LINKS NEWS MAN DOCUMENTATION


[NEWS] Java Sandbox and Stateful Firewalls Interaction


<< Previous INDEX Search src Set bookmark Go to bookmark Next >>
From: SecuriTeam <support@securiteam.com.>
To: [email protected]
Date: 1 Aug 2005 18:50:48 +0200
Subject: [NEWS] Java Sandbox and Stateful Firewalls Interaction
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20050801161137.D10C258B3@mail.tyumen.ru.>
X-Virus-Scanned: antivirus-gw at tyumen.ru

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html 

- - - - - - - - -




  Java Sandbox and Stateful Firewalls Interaction
------------------------------------------------------------------------


SUMMARY

Java sandbox for applets and  
<http://en.wikipedia.org/wiki/Stateful_firewall>; stateful firewalls 
interact in a surprising way. As a result, external hosts can initiate TCP 
connections to supposedly protected network services. An attacker use the 
technique detailed below to gain access to potentially vulnerable network 
services that are located behind firewall and/or NAT devices, so that 
direct access is impossible.

DETAILS

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.

This is a passive vulnerability which can only be used as a step stone for 
further attacks. As a result, the risk posed by this vulnerability alone 
is fairly low.

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,  
<http://www.rfc-editor.org/rfc/rfc959.txt>; RFC 959). This connection is 
permitted according to the  
<http://java.sun.com/docs/books/tutorial/applet/overview/security.html>; 
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.

Workaround:
 * 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.

  * Source code of the Java applet
 <http://www.enyo.de/fw/security/java-firewall/test.java>; 
http://www.enyo.de/fw/security/java-firewall/test.java


  * Perl source code of the FTP server emulation
 <http://www.enyo.de/fw/security/java-firewall/ftpd.pl>; 
http://www.enyo.de/fw/security/java-firewall/ftpd.pl


For convenience, the TCP port to which access from the web/FTP server is 
provided can be configured on the client. In a real attack scenario, this 
port would be chosen by the attacker.

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  
<http://www.rfc-editor.org/rfc/rfc3514.txt>; 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.



ADDITIONAL INFORMATION

The original article can be found at:  
<http://www.enyo.de/fw/security/java-firewall/>; 
http://www.enyo.de/fw/security/java-firewall/
The information has been provided by  <mailto:fw@deneb.enyo.de.> Florian 
Weimer.




This bulletin is sent to members of the SecuriTeam mailing list. To unsubscribe from the list, send mail with an empty subject line and body to: [email protected] In order to subscribe to the mailing list, simply forward this email to: [email protected]

DISCLAIMER: The information in this bulletin is provided "AS IS" without warranty of any kind. In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

<< Previous INDEX Search src Set bookmark Go to bookmark Next >>



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру