Re: Java Applets can connect to other hosts using HTTP 302 redirection

[Kanatoko <anvil () jumperz net>]

Hi

Angel Alonso wrote: 
> The problem could be in the java ( i think  java has been updaterecently to
> solve some similar problem),

That is right. I found that this issue was fixed in the jre1.6.0_03
( as a side affect, maybe ).

> could you send me the "foo.jar
> " code to try find out anything else?

import java.net.*;
import java.io.*;
import java.awt.*;

public class MTCPCApplet
extends java.applet.Applet
{
String log = "";
//--------------------------------------------------------------
public String getLog()
{
String tmp = log;
log = "";
return tmp;
}
//--------------------------------------------------------------
public void log( Object s )
{
log += s.toString();
}
//--------------------------------------------------------------
public void init()
{
try
    {
    Socket sock = new Socket( "www.jumperz.net", 1111 );
    log( sock );
    byte[] buffer = new byte[ 11 ];
    sock.getInputStream().read( buffer );
    log( new String( buffer ) );
    sock.close();
    }
catch( Exception e )
    {
    log( e );
    }
}
//--------------------------------------------------------------
}

Thank you for your comments.

-- 
Kanatoko<anvil () jumperz net>
Open Source WebAppFirewall
http://guardian.jumperz.net/

> Hi,
>
> looking at the RFC, I think it's normal,
>
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
> *
> "...302 Found
>
> The requested resource resides temporarily under a different URI. Since the
> redirection might be altered on occasion, the client SHOULD continue to use
> the Request-URI for future requests. This response is only cacheable if
> indicated by a Cache-Control or Expires header field.
>
> The temporary URI SHOULD be given by the Location field in the response.
> Unless the request method was HEAD, the entity of the response SHOULD
> contain a short hypertext note with a hyperlink to the new URI(s).
>
> If the 302 status code is received in response to a request other than GET
> or HEAD, the user agent MUST NOT automatically redirect the request unless
> it can be confirmed by the user, since this might change the conditions
> under which the request was issued.
> Note: RFC 1945 and RFC 2068 specify that the client is not allowed
> to change the method on the redirected request. However, most
> existing user agent implementations treat 302 as if it were a 303
> response, performing a GET on the Location field-value regardless
> of the original request method. The status codes 303 and 307 have
> been added for servers that wish to make unambiguously clear which
> kind of reaction is expected of the client......."*
>
> The problem could be in the java ( i think  java has been updaterecently to
> solve some similar problem), could you send me the "foo.jar
> " code to try find out anything else?
>
> I hope this could be helpfully for you.
>
> Regards,
>
> 2007/10/3, Kanatoko <anvil () jumperz net>:
> > It seems that the java applet located on the host A is allowed to
> > connect to the host B using HTTP 302 redirection on the host B.
> >
> > Is it a normal behaviour?
> >
> > PoC:
> > http://www.jumperz.net/exploits/appletTest1.jsp
> >
> > host A: www.gyosatu.com
> > host B: www.jumperz.net
> >
> > In this PoC, the java applet is downloaded from www.gyosatu.com and
> > connects to www.jumperz.net port 1111.
> >
> > Use "tcpdump port 1111" to see the packets.
> >
> > --
> > Kanatoko<anvil () jumperz net>
> > Open Source WebAppFirewall
> > http://guardian.jumperz.net/
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> > Hosted and sponsored by Secunia - http://secunia.com/
>
>
>
> -- 
> Angel J. Alonso Fernandez
> Security Consultant
> EC-CEH Certified

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