Re: Reducing java leakage in windows
In the latest build of xB Browser, if you foolishly trust metasploit to allow scripts, you get the following results: External Address206.57.47.50Browser (CONTROL) Internal Host 192.168.0.4 Java(SUCCESS) Internal Address192.168.0.4 Java(SUCCESS) DNS Server (Java) unknown Java(FAIL) DNS Server (HTTP) unknown Browser (FAIL) External NAT (Java) x.x.x.x Java(SUCCESS) External NAT (Flash)unknown Flash (FAIL) icmp30 wrote: > How's it do against the decloak tests at metasploit? > http://metasploit.com/research/misc/decloak/ > > > --- Arrakis <[EMAIL PROTECTED]> wrote: > >> It appears that Java attacks for causing external IP data to be leaked >> can be mitigated to some good degree. The upshot is that you can now run >> Java applets that even when attempting to phone home directly (revealing >> your IP), they are routed through the socks port and thus Tor or any >> other socks speaking application. What we are doing is changing the >> proxy settings of the Java Control Panel in windows. The following will >> shortly be applied to xB Browser after testing, and I highly suggest it >> for other proxy programs. Needs lots of testing of course, and I would >> also like to know if Java applets can acquire the authority to modify >> that file as well. May require administrative access, but I imagine >> Vista will popup a priv escalation window. There are probably variations >> in the directories and syntax if you are running JRE <1.4. A good >> indicator of old versioning is to see if your shoes employ the use of >> velcro, you have a pair of 'jams' in your closet, or you've found >> yourself to be too legitimate to quit. >> >> Regards, >> Steve Topletz >> >> >> - >> >> >> 1. Look for $APPDATA\Sun\Java\Deployment\deployment.properties >> If there is no deployment.properties file there, try all administrative >> usernames we can enumerate until we find the file. This is not a certianty. >> >> 2. Back up deployment.properties to a new file name. >> 3. Open it up >> 4. Read and store all lines beginning with "deployment.version" >> 5. Read and store all lines beginning with "deployment.javapi" >> 6. Close the file >> 7. Create a new file deployment.properties where the old one was. >> 8. Open the file >> 9. Insert the following lines >> >> #deployment.properties >> deployment.system.tray.icon=false >> deployment.browser.vm.iexplorer=false >> deployment.proxy.socks.host=localhost >> deployment.proxy.type=1 >> deployment.proxy.same=true >> deployment.browser.vm.mozilla=false >> deployment.capture.mime.types=true >> deployment.proxy.socks.port=8080 >> >> (where port 8080 is your socks port. in Tor, use 9050 by default) >> >> 10. Write all previously stored lines from old opened file. >> 11. Close the new deployment.properties >> >> Continue starting your proxy program >> On program exit... >> >> 12. Delete the deployment.properties file we created. >> 13. Restore the deployment.properties file we backed up. >> > > > > > > Be a better pen pal. > Text or chat with friends inside Yahoo! Mail. See how. > http://overview.mail.yahoo.com/ >
Re: Reducing java leakage in windows
How's it do against the decloak tests at metasploit? http://metasploit.com/research/misc/decloak/ --- Arrakis <[EMAIL PROTECTED]> wrote: > It appears that Java attacks for causing external IP data to be leaked > can be mitigated to some good degree. The upshot is that you can now run > Java applets that even when attempting to phone home directly (revealing > your IP), they are routed through the socks port and thus Tor or any > other socks speaking application. What we are doing is changing the > proxy settings of the Java Control Panel in windows. The following will > shortly be applied to xB Browser after testing, and I highly suggest it > for other proxy programs. Needs lots of testing of course, and I would > also like to know if Java applets can acquire the authority to modify > that file as well. May require administrative access, but I imagine > Vista will popup a priv escalation window. There are probably variations > in the directories and syntax if you are running JRE <1.4. A good > indicator of old versioning is to see if your shoes employ the use of > velcro, you have a pair of 'jams' in your closet, or you've found > yourself to be too legitimate to quit. > > Regards, > Steve Topletz > > > - > > > 1. Look for $APPDATA\Sun\Java\Deployment\deployment.properties > If there is no deployment.properties file there, try all administrative > usernames we can enumerate until we find the file. This is not a certianty. > > 2. Back up deployment.properties to a new file name. > 3. Open it up > 4. Read and store all lines beginning with "deployment.version" > 5. Read and store all lines beginning with "deployment.javapi" > 6. Close the file > 7. Create a new file deployment.properties where the old one was. > 8. Open the file > 9. Insert the following lines > > #deployment.properties > deployment.system.tray.icon=false > deployment.browser.vm.iexplorer=false > deployment.proxy.socks.host=localhost > deployment.proxy.type=1 > deployment.proxy.same=true > deployment.browser.vm.mozilla=false > deployment.capture.mime.types=true > deployment.proxy.socks.port=8080 > > (where port 8080 is your socks port. in Tor, use 9050 by default) > > 10. Write all previously stored lines from old opened file. > 11. Close the new deployment.properties > > Continue starting your proxy program > On program exit... > > 12. Delete the deployment.properties file we created. > 13. Restore the deployment.properties file we backed up. > Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how. http://overview.mail.yahoo.com/
Re: Reducing java leakage in windows
I can confirm that this code does indeed expose the external IP address,
despite the setting in JCP/deployment.properties.
James Muir wrote:
> [EMAIL PROTECTED] wrote:
>> On Sun, Dec 02, 2007 at 11:35:49PM -0800, [EMAIL PROTECTED] wrote
>> 0.9K bytes in 21 lines about:
>> : I remember these tests. I can't seem to find a copy of the applets you
>> : used. Are you willing to publish them? Or point me in the right
>> : direction should I want to try implementing them?
>>
>> http://exitthematrix.dod.net/matrixmirror/ar01s05.html Jump down to the
>> "Web bugs" section. It references
>> http://exitthematrix.dod.net/matrixmirror/misc/superipbug.java from
>> http://www.inet-police.com/cgi-bin/env.cgi
>>
>> There is another more thorough test of a java applet completely ignoring
>> the jvm proxy configuration. However, my google-fu is weak.
>
> When I read that example it seems to indicate that the applet reads your
> IP address locally and then submits it back to the originating web site
> through the proxy. The applet does not seem to ignore proxy settings
> (i.e. it does not seem to open a non-proxied connnection); it just
> submits identifying information through the proxied connection.
>
> Jacob, Steve: I don't want to publish my complete ready-to-run code on
> the list, but here is an excerpt:
>
> /***/
>
> Socket socket_to_originating_host = null;
> int tcp_port = 80;
> InetSocketAddress originating_host =
> new InetSocketAddress(getCodeBase().getHost(), tcp_port);
>
> try {
> socket_to_originating_host = new Socket(Proxy.NO_PROXY);
> // timeout is in milliseconds
> socket_to_originating_host.connect(originating_host, 1);
> System.out.println(
>"Socket Local Address = " +
>socket_to_originating_host.getLocalAddress().getHostAddress());
> }
>
> catch (Exception e) {
> System.out.println("EXCEPTION THROWN: " + e);
> System.exit(1);
>
> }
>
> //
>
> More details can be found in the paper "Internet Geolocation" on my web
> site.
>
> -James
>
>
>
>
>
Re: Reducing java leakage in windows
Arrakis wrote: So what we want to see is an applet running around the deployment.properties setting, exposing the external network IP. I agree. This is what my applet does. -James
Re: Reducing java leakage in windows
Okay pause.
We need to distinguish here because ya'll are talking about different
terms. Internal network IP (192.168.x.x, etc), external IP (your public
IP address), and DNS requests (locally vs remote through socks). The
internal network IP probably isn't a terribly valuable piece of
information to most snoops. The local DNS is an issue because you're
telling your local network/ISP or whomever what addresses you're
looking at. The big issue is the external network IP, which is what the
public sees and identifies the home user's specific computer.
So what we want to see is an applet running around the
deployment.properties setting, exposing the external network IP. The DNS
leakage should also be investigate of course.
Steve
James Muir wrote:
> [EMAIL PROTECTED] wrote:
>> On Sun, Dec 02, 2007 at 11:35:49PM -0800, [EMAIL PROTECTED] wrote
>> 0.9K bytes in 21 lines about:
>> : I remember these tests. I can't seem to find a copy of the applets you
>> : used. Are you willing to publish them? Or point me in the right
>> : direction should I want to try implementing them?
>>
>> http://exitthematrix.dod.net/matrixmirror/ar01s05.html Jump down to the
>> "Web bugs" section. It references
>> http://exitthematrix.dod.net/matrixmirror/misc/superipbug.java from
>> http://www.inet-police.com/cgi-bin/env.cgi
>>
>> There is another more thorough test of a java applet completely ignoring
>> the jvm proxy configuration. However, my google-fu is weak.
>
> When I read that example it seems to indicate that the applet reads your
> IP address locally and then submits it back to the originating web site
> through the proxy. The applet does not seem to ignore proxy settings
> (i.e. it does not seem to open a non-proxied connnection); it just
> submits identifying information through the proxied connection.
>
> Jacob, Steve: I don't want to publish my complete ready-to-run code on
> the list, but here is an excerpt:
>
> /***/
>
> Socket socket_to_originating_host = null;
> int tcp_port = 80;
> InetSocketAddress originating_host =
> new InetSocketAddress(getCodeBase().getHost(), tcp_port);
>
> try {
> socket_to_originating_host = new Socket(Proxy.NO_PROXY);
> // timeout is in milliseconds
> socket_to_originating_host.connect(originating_host, 1);
> System.out.println(
>"Socket Local Address = " +
>socket_to_originating_host.getLocalAddress().getHostAddress());
> }
>
> catch (Exception e) {
> System.out.println("EXCEPTION THROWN: " + e);
> System.exit(1);
>
> }
>
> //
>
> More details can be found in the paper "Internet Geolocation" on my web
> site.
>
> -James
>
>
>
>
>
Re: Reducing java leakage in windows
[EMAIL PROTECTED] wrote:
On Sun, Dec 02, 2007 at 11:35:49PM -0800, [EMAIL PROTECTED] wrote 0.9K bytes in
21 lines about:
: I remember these tests. I can't seem to find a copy of the applets you
: used. Are you willing to publish them? Or point me in the right
: direction should I want to try implementing them?
http://exitthematrix.dod.net/matrixmirror/ar01s05.html Jump down to the
"Web bugs" section. It references
http://exitthematrix.dod.net/matrixmirror/misc/superipbug.java from
http://www.inet-police.com/cgi-bin/env.cgi
There is another more thorough test of a java applet completely ignoring
the jvm proxy configuration. However, my google-fu is weak.
When I read that example it seems to indicate that the applet reads your
IP address locally and then submits it back to the originating web site
through the proxy. The applet does not seem to ignore proxy settings
(i.e. it does not seem to open a non-proxied connnection); it just
submits identifying information through the proxied connection.
Jacob, Steve: I don't want to publish my complete ready-to-run code on
the list, but here is an excerpt:
/***/
Socket socket_to_originating_host = null;
int tcp_port = 80;
InetSocketAddress originating_host =
new InetSocketAddress(getCodeBase().getHost(), tcp_port);
try {
socket_to_originating_host = new Socket(Proxy.NO_PROXY);
// timeout is in milliseconds
socket_to_originating_host.connect(originating_host, 1);
System.out.println(
"Socket Local Address = " +
socket_to_originating_host.getLocalAddress().getHostAddress());
}
catch (Exception e) {
System.out.println("EXCEPTION THROWN: " + e);
System.exit(1);
}
//
More details can be found in the paper "Internet Geolocation" on my web
site.
-James
Re: Reducing java leakage in windows
On Sun, Dec 02, 2007 at 11:35:49PM -0800, [EMAIL PROTECTED] wrote 0.9K bytes in 21 lines about: : I remember these tests. I can't seem to find a copy of the applets you : used. Are you willing to publish them? Or point me in the right : direction should I want to try implementing them? http://exitthematrix.dod.net/matrixmirror/ar01s05.html Jump down to the "Web bugs" section. It references http://exitthematrix.dod.net/matrixmirror/misc/superipbug.java from http://www.inet-police.com/cgi-bin/env.cgi There is another more thorough test of a java applet completely ignoring the jvm proxy configuration. However, my google-fu is weak. -- Andrew
Re: Reducing java leakage in windows
James Muir wrote: > Arrakis wrote: >> It appears that Java attacks for causing external IP data to be leaked >> can be mitigated to some good degree. The upshot is that you can now run >> Java applets that even when attempting to phone home directly (revealing >> your IP), they are routed through the socks port and thus Tor or any >> other socks speaking application. What we are doing is changing the >> proxy settings of the Java Control Panel in windows. > > Some time ago, I conducted several tests that demonstrated that Java > Applets have the ability to disregard proxy settings in the Java Control > and open direct non-proxied connections. I do not think what you have > described will work. > I remember these tests. I can't seem to find a copy of the applets you used. Are you willing to publish them? Or point me in the right direction should I want to try implementing them? Regards, Jacob
Re: Reducing java leakage in windows
James, Do you have a copy of these tests? I'm definitely interested in seeing it. However, I am NOT posing this as a solution to java issues, just another defense layer. This effectively keeps non-malicious applets from surreptitious leakage. I highly doubt a determined application would be cornered in, but most seem to be. Regarding DNS, well that is again another issue to be looked at, unfortunately. Steve James Muir wrote: > Arrakis wrote: >> It appears that Java attacks for causing external IP data to be leaked >> can be mitigated to some good degree. The upshot is that you can now run >> Java applets that even when attempting to phone home directly (revealing >> your IP), they are routed through the socks port and thus Tor or any >> other socks speaking application. What we are doing is changing the >> proxy settings of the Java Control Panel in windows. > > Some time ago, I conducted several tests that demonstrated that Java > Applets have the ability to disregard proxy settings in the Java Control > and open direct non-proxied connections. I do not think what you have > described will work. > > -James >
Re: Reducing java leakage in windows
Arrakis wrote: It appears that Java attacks for causing external IP data to be leaked can be mitigated to some good degree. The upshot is that you can now run Java applets that even when attempting to phone home directly (revealing your IP), they are routed through the socks port and thus Tor or any other socks speaking application. What we are doing is changing the proxy settings of the Java Control Panel in windows. Some time ago, I conducted several tests that demonstrated that Java Applets have the ability to disregard proxy settings in the Java Control and open direct non-proxied connections. I do not think what you have described will work. -James
Re: Reducing java leakage in windows
On Dec 2, 2007 11:02 AM, Arrakis <[EMAIL PROTECTED]> wrote: > It appears that Java attacks for causing external IP data to be leaked > can be mitigated to some good degree. The upshot is that you can now run > Java applets that even when attempting to phone home directly (revealing > your IP), they are routed through the socks port > ... [ discussion of deployment.properties for socks setup ] the last time i looked into this (over a year ago) the socks proxy settings, either 4 or 5, still did name lookup external to the proxy (not 4a nor 5 with names). this means the same DNS resolution tricks to leak your IP will work, even if the simpler "open a TCP sock to eve" does not. i think HD Moore's revealer used this as one of the tricks, so it might be worth checking against that with an updated deployment.properties to confirm. if you really want to use java you should use it behind a transparent Tor proxy. best regards,
Reducing java leakage in windows
It appears that Java attacks for causing external IP data to be leaked can be mitigated to some good degree. The upshot is that you can now run Java applets that even when attempting to phone home directly (revealing your IP), they are routed through the socks port and thus Tor or any other socks speaking application. What we are doing is changing the proxy settings of the Java Control Panel in windows. The following will shortly be applied to xB Browser after testing, and I highly suggest it for other proxy programs. Needs lots of testing of course, and I would also like to know if Java applets can acquire the authority to modify that file as well. May require administrative access, but I imagine Vista will popup a priv escalation window. There are probably variations in the directories and syntax if you are running JRE <1.4. A good indicator of old versioning is to see if your shoes employ the use of velcro, you have a pair of 'jams' in your closet, or you've found yourself to be too legitimate to quit. Regards, Steve Topletz - 1. Look for $APPDATA\Sun\Java\Deployment\deployment.properties If there is no deployment.properties file there, try all administrative usernames we can enumerate until we find the file. This is not a certianty. 2. Back up deployment.properties to a new file name. 3. Open it up 4. Read and store all lines beginning with "deployment.version" 5. Read and store all lines beginning with "deployment.javapi" 6. Close the file 7. Create a new file deployment.properties where the old one was. 8. Open the file 9. Insert the following lines #deployment.properties deployment.system.tray.icon=false deployment.browser.vm.iexplorer=false deployment.proxy.socks.host=localhost deployment.proxy.type=1 deployment.proxy.same=true deployment.browser.vm.mozilla=false deployment.capture.mime.types=true deployment.proxy.socks.port=8080 (where port 8080 is your socks port. in Tor, use 9050 by default) 10. Write all previously stored lines from old opened file. 11. Close the new deployment.properties Continue starting your proxy program On program exit... 12. Delete the deployment.properties file we created. 13. Restore the deployment.properties file we backed up.
