[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[WEB SECURITY] Anti-DNS Pinning and Java Applets
- From: David Byrne <davidribyrne@xxxxxxxxx>
- Subject: [WEB SECURITY] Anti-DNS Pinning and Java Applets
- Date: Sun, 8 Jul 2007 21:47:41 -0700 (PDT)
--0-1530436207-1183956461=:694
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
This was reported to Sun on July 2nd, but I have not received a response. I=
do not consider these to be critical vulnerabilities, which gives me a cle=
an conscious for disclosure. =0A=0ADavid Byrne=0A=0A=0A=0AAnti-DNS pinning =
and Java applets=0A=0A-----------------------------------------------------=
--=0AIntroduction=0A-------------------------------------------------------=
=0ADNS pinning is a technique HTTP clients use to prevent DNS spoofing atta=
cks that would otherwise defeat the browser=92s same origin policy [1]. Ant=
i-DNS pinning attacks are intended to bypass these controls, essentially tu=
rning the client into a proxy server [2,3]. In what was probably the earlie=
st documented technique, in 1996, Princeton researchers discovered a way to=
cause an untrusted Java applet to connect to an arbitrary host [4]. This w=
as quickly corrected by Sun [5]. More recently, Martin Johns and Kanatoko A=
nvil documented that LiveConnect [6] in Firefox or Opera allows for a simil=
ar attack [7].=0A=0AI have documented two related methods for successful an=
ti-DNS pinning attacks using Java applets. The methods documented below wor=
k with Firefox 2 and Internet Explorer 7 running either Java 1.5 or 1.6.=0A=
=0A-------------------------------------------------------=0AStandard JVM D=
NS Behavior=0A-------------------------------------------------------=0ATyp=
ically, an applet is loaded by the following series of events:=0A 1. =
The browser resolves the hostname via DNS, and pins the result in its cache=
=0A 2. The browser requests the HTML file from the web server. =0A =
3. If there is an <APPLET>, <EMBED>, or <OBJECT> tag referencing a Java=
applet, the JVM is loaded, and passed the path to the applet, and the orig=
in server of the HTML document.=0A 4. The JVM initializes, resolves t=
he origin server=92s name and pins the result in its cache.=0A 5. The=
applet file (usually .jar or .class) is requested from the server and run.=
=0A 6. If the applet is untrusted [8], socket connections are (or at =
least should be) limited to the origin server, but allowing any port.=0A=0A=
-------------------------------------------------------=0APrinceton Attack =
Summary=0A-------------------------------------------------------=0AThe Pri=
nceton attack [5] showed that the JVM was basing its same-origin policy on =
the DNS response, not on the actual IP address of the origin server. The at=
tack sequence follows:=0A 1. Victim browser visits a malicious site/d=
omain, and downloads HTML referencing the attack Java applet=0A 2. Th=
e JVM is loaded, and passed the path to the applet=0A 3. The JVM quer=
ies DNS for the server hosting the applet=0A 4. The attack DNS server=
responds with two IP addresses; the first belongs to the attack web server=
, and the second belongs to the victim server, presumably on a private netw=
ork=0A 5. The JVM loads the applet (class or JAR file) from the attac=
k web server=0A 6. The applet requests a socket connection to IP addr=
ess of the victim server=0A 7. Because the second IP address matches =
the origin server=92s DNS record, the JVM allows the connection=0A=0AThis w=
as Sun=92s response [6]=0A "A fix for the applet security manager is to b=
e more strict about deciding which computers an applet is allowed to connec=
t to. The Java system needs to take note of the actual IP address that the =
applet truly came from (getting that numerical address from the applet's pa=
ckets, as the applet is being loaded), and thereafter only allow the applet=
to connect to that exact same numerical address."=0A=0AAs the following me=
thods show, recent versions of the JVM do not exhibit this behavior.=0A=0A-=
------------------------------------------------------=0APrinceton Attack =
=96 Same Subnet=0A-------------------------------------------------------=
=0AThe Princeton attack is still possible with current versions of Java whe=
n both IP addresses returned by the DNS server are on the same subnet as th=
e client. No reverse lookups, etc. are required. This isn=92t a new attack =
per se, or a very large threat, but is revealing about how the JVM=92s DNS =
pinning functions. =0A=0A--------------------------------------------------=
-----=0AMethod 1: Modified Princeton Attack =96 PTR Records=0A-------------=
------------------------------------------=0AAs described above, if two IP =
addresses are supplied for the origin host name by DNS, the JVM will automa=
tically allow connections to the first address. If the applet tries to conn=
ect to the second address, the JVM performs a reverse DNS lookup for both a=
ddresses. If the results match the sequence below, the connection is allowe=
d. Thus, if an attacker controls the client=92s resolving DNS server, or if=
the DNS server is vulnerable to cache poisoning, matching PTR records can =
be supplied. =0A=0A Attack hostname host1 resolves to IP1, IP2=0A Rev=
erse lookup on IP1 resolves to host2 (can be the same as host1)=0A Rever=
se lookup on IP2 resolves to host2=0A Host2 resolves to IP1 and IP2=0A=
=0ABecause this requires a secondary vulnerability to allow DNS control, th=
e threat can be significantly limited by using good DNS practices. This doe=
s not necessarily represent a defect in the JVM.=0A=0A---------------------=
----------------------------------=0AMethod 2: Proxy Bypass=0A-------------=
------------------------------------------=0AIf the JVM is configured to us=
e an HTTP proxy server, it will still attempt to resolve the origin server =
hostname through DNS, but will retrieve the applet through the proxy server=
. With this method, the attack DNS server sends the proxy server an IP addr=
ess for the attack web server, but sends the JVM the IP address of the vict=
im host. This allows the JVM to successfully retrieve the applet, but cause=
s it to pin the victim=92s IP address in its cache. When it loads, the appl=
et can establish arbitrary socket connections to the victim.=0A=0AThis can =
be easily prevented by not allowing internal network resolution of Internet=
domains through DNS. This can also be corrected by changing the JVM behavi=
or to disable DNS resolution of the origin server when a proxy is in use, o=
r disabling socket support altogether.=0A=0A-------------------------------=
------------------------=0AReferences =0A----------------------------------=
---------------------=0A[1] http://www.mozilla.org/projects/security/compon=
ents/same-origin.html=0A[2] http://viper.haque.net/~timeless/blog/11/=0A[3]=
http://shampoo.antville.org/stories/1451301/ =0A[4] http://www.cs.princeto=
n.edu/sip/news/dns-scenario.html=0A[5] http://www.cs.princeton.edu/sip/news=
/sun-02-22-96.html=0A[6] http://developer.mozilla.org/en/docs/LiveConnect=
=0A[7] http://shampoo.antville.org/stories/1566124/=0A[8] http://java.sun.c=
om/sfaq/=0A=0A=0A=0A=0A=0A =0A_______________________________________=
_____________________________________________=0APinpoint customers who are =
looking for what you sell. =0Ahttp://searchmarketing.yahoo.com/
--0-1530436207-1183956461=:694
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:arial,helvetica,sans-serif;font-size:10p=
t">This was reported to Sun on July 2nd, but I have not received a response=
. I do not consider these to be critical vulnerabilities, which gives me a =
clean conscious for disclosure. <br><br>David Byrne<br><br><br><br>Anti-DNS=
pinning and Java applets<br><br>------------------------------------------=
-------------<br>Introduction<br>------------------------------------------=
-------------<br>DNS pinning is a technique HTTP clients use to prevent DNS=
spoofing attacks that would otherwise defeat the browser=92s same origin p=
olicy [1]. Anti-DNS pinning attacks are intended to bypass these controls, =
essentially turning the client into a proxy server [2,3]. In what was proba=
bly the earliest documented technique, in 1996, Princeton researchers disco=
vered a way to cause an untrusted Java applet to connect to an arbitrary ho=
st [4]. This was
quickly corrected by Sun [5]. More recently, Martin Johns and Kanatoko Anv=
il documented that LiveConnect [6] in Firefox or Opera allows for a similar=
attack [7].<br><br>I have documented two related methods for successful an=
ti-DNS pinning attacks using Java applets. The methods documented below wor=
k with Firefox 2 and Internet Explorer 7 running either Java 1.5 or 1.6.<br=
><br>-------------------------------------------------------<br>Standard JV=
M DNS Behavior<br>-------------------------------------------------------<b=
r>Typically, an applet is loaded by the following series of events:<br>&nbs=
p; 1. The browser resolves the hostname via D=
NS, and pins the result in its cache<br> 2. &n=
bsp; The browser requests the HTML file from the web server. <br> &nbs=
p; 3. If there is an <APPLET>, <EMBED>,=
or <OBJECT> tag referencing a Java applet, the JVM is loaded, and pa=
ssed the path
to the applet, and the origin server of the HTML document.<br> =
4. The JVM initializes, resolves the origin server=
=92s name and pins the result in its cache.<br> 5. &=
nbsp; The applet file (usually .jar or .class) is requested from the =
server and run.<br> 6. If the applet is=
untrusted [8], socket connections are (or at least should be) limited to t=
he origin server, but allowing any port.<br><br>---------------------------=
----------------------------<br>Princeton Attack Summary<br>---------------=
----------------------------------------<br>The Princeton attack [5] showed=
that the JVM was basing its same-origin policy on the DNS response, not on=
the actual IP address of the origin server. The attack sequence follows:<b=
r> 1. Victim browser visits a malicious=
site/domain, and downloads HTML referencing the attack Java applet<br>&nbs=
p;
2. The JVM is loaded, and passed the path to the applet<=
br> 3. The JVM queries DNS for the serv=
er hosting the applet<br> 4. The attack=
DNS server responds with two IP addresses; the first belongs to the attack=
web server, and the second belongs to the victim server, presumably on a p=
rivate network<br> 5. The JVM loads the=
applet (class or JAR file) from the attack web server<br>  =
; 6. The applet requests a socket connection to IP addres=
s of the victim server<br> 7. Because t=
he second IP address matches the origin server=92s DNS record, the JVM allo=
ws the connection<br><br>This was Sun=92s response [6]<br> "A f=
ix for the applet security manager is to be more strict about deciding whic=
h computers an applet is allowed to connect to. The Java system needs to ta=
ke note of the
actual IP address that the applet truly came from (getting that numerical =
address from the applet's packets, as the applet is being loaded), and ther=
eafter only allow the applet to connect to that exact same numerical addres=
s."<br><br>As the following methods show, recent versions of the JVM do not=
exhibit this behavior.<br><br>--------------------------------------------=
-----------<br>Princeton Attack =96 Same Subnet<br>------------------------=
-------------------------------<br>The Princeton attack is still possible w=
ith current versions of Java when both IP addresses returned by the DNS ser=
ver are on the same subnet as the client. No reverse lookups, etc. are requ=
ired. This isn=92t a new attack per se, or a very large threat, but is reve=
aling about how the JVM=92s DNS pinning functions. <br><br>----------------=
---------------------------------------<br>Method 1: Modified Princeton Att=
ack =96 PTR Records<br>----------------------------------------------------=
---<br>As described
above, if two IP addresses are supplied for the origin host name by DNS, t=
he JVM will automatically allow connections to the first address. If the ap=
plet tries to connect to the second address, the JVM performs a reverse DNS=
lookup for both addresses. If the results match the sequence below, the co=
nnection is allowed. Thus, if an attacker controls the client=92s resolving=
DNS server, or if the DNS server is vulnerable to cache poisoning, matchin=
g PTR records can be supplied. <br><br> Attack hostname h=
ost1 resolves to IP1, IP2<br> Reverse lookup on IP1 resol=
ves to host2 (can be the same as host1)<br> Reverse looku=
p on IP2 resolves to host2<br> Host2 resolves to IP1 and =
IP2<br><br>Because this requires a secondary vulnerability to allow DNS con=
trol, the threat can be significantly limited by using good DNS practices. =
This does not necessarily represent a defect in the
JVM.<br><br>-------------------------------------------------------<br>Met=
hod 2: Proxy Bypass<br>----------------------------------------------------=
---<br>If the JVM is configured to use an HTTP proxy server, it will still =
attempt to resolve the origin server hostname through DNS, but will retriev=
e the applet through the proxy server. With this method, the attack DNS ser=
ver sends the proxy server an IP address for the attack web server, but sen=
ds the JVM the IP address of the victim host. This allows the JVM to succes=
sfully retrieve the applet, but causes it to pin the victim=92s IP address =
in its cache. When it loads, the applet can establish arbitrary socket conn=
ections to the victim.<br><br>This can be easily prevented by not allowing =
internal network resolution of Internet domains through DNS. This can also =
be corrected by changing the JVM behavior to disable DNS resolution of the =
origin server when a proxy is in use, or disabling socket support
altogether.<br><br>-------------------------------------------------------=
<br>References <br>-------------------------------------------------------<=
br><span>[1] <a target=3D"_blank" href=3D"http://www.mozilla.org/projects/s=
ecurity/components/same-origin.html">http://www.mozilla.org/projects/securi=
ty/components/same-origin.html</a></span><br><span>[2] <a target=3D"_blank"=
href=3D"http://viper.haque.net/%7Etimeless/blog/11/";>http://viper.haque.ne=
t/~timeless/blog/11/</a></span><br><span>[3] <a target=3D"_blank" href=3D"h=
ttp://shampoo.antville.org/stories/1451301/">http://shampoo.antville.org/st=
ories/1451301/</a> </span><br><span>[4] <a target=3D"_blank" href=3D"http:/=
/www.cs.princeton.edu/sip/news/dns-scenario.html">http://www.cs.princeton.e=
du/sip/news/dns-scenario.html</a></span><br><span>[5] <a target=3D"_blank" =
href=3D"http://www.cs.princeton.edu/sip/news/sun-02-22-96.html";>http://www.=
cs.princeton.edu/sip/news/sun-02-22-96.html</a></span><br><span>[6] <a targ=
et=3D"_blank"
href=3D"http://developer.mozilla.org/en/docs/LiveConnect";>http://developer=
.mozilla.org/en/docs/LiveConnect</a></span><br><span>[7] <a target=3D"_blan=
k" href=3D"http://shampoo.antville.org/stories/1566124/";>http://shampoo.ant=
ville.org/stories/1566124/</a></span><br><span>[8] <a target=3D"_blank" hre=
f=3D"http://java.sun.com/sfaq/";>http://java.sun.com/sfaq/</a></span><br><br=
><br></div><br>=0A <hr size=3D1>Got a little couch potato? <br>=0AChec=
k out fun <a href=3D"http://us.rd.yahoo.com/evt=3D48248/*http://search.yaho=
o.com/search?fr=3Doni_on_mail&p=3Dsummer+activities+for+kids&cs=3Dbz">summe=
r activities for kids.</a></body></html>
--0-1530436207-1183956461=:694--
Brought to you by http://www.webappsec.org
Search this site
|