This is a multi-part message in MIME format.
------=_NextPart_000_005D_01BE28EB.BDFE0740
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
This advisory is for those using MS Proxy 2.0 with packet filtering and =
use the same machine to Publish Web pages, or those that don't enable =
packet filtering. You network is at risk of attack unless you also =
employ other security measures.
In certain and quite common configurations of MS Proxy Server 2.0 it is =
possible to attack the machines it is there to protect. This can be =
acheived in a number of ways, more easily if access can be gained to the =
same IP subnet as the "Dirty" Internet Interface. But first some key =
facts on Proxy.
When MS Proxy is installed on a machine with two interface cards the =
Admin specifies the IP addresses of the machines on the local / =
corporate network. This information is stored in a file called the LAT =
or Local Address Table. Doing this lets Proxy know which interface is =
the clean client side and which is the dirty Internet side. The IP =
address of the dirty interface should not be listed in the LAT.=20
IP forwarding should be disabled.
Once installed MS - Proxy disables connections to TCP port 80 (assuming =
this is the port Proxy is listening on) on the dirty interface*. Only =
the clean interface will accept connections and service requests on port =
80 - meaning that only clients on clean side should be able to use the =
Proxy services.
It is possible, however, to make a connection to port 80 on the clean =
interface from the dirty side. To see this happening set up a host on =
the same IP subnet as the dirty interface and then set your default =
gateway to the IP address of the dirty interface on the Proxy - then =
telnet to port 80 on the IP address of the clean interface. You should =
be connected. Then issue the request:
"GET http://some.protected.machine.on.the.clean.side:port/ =
HTTP/1.0<enter><enter>"
Proxy will then establish a TCP connection to the protected machine on =
the port you have specified. It is easier to see this if the machine is =
an Internal Web Server. One would expect with IP forwarding disabled =
that this should not happen - ie the passsing of IP information from the =
dirty interface to the clean interface. This is the "hole" but this is =
not a bug but rather a feature. This happens due to the IP routing =
algorithm: If a multi-homed computer, not configured as a router, =
receives a packet on an interface it will check all of its local IP =
addresses and if a match is found - whether the IP address is bound to =
another interface card or not - the information is passed across. This =
should be acheivable also in an attack involving source routing, =
specifying the IP address of the dirty interface as the last "hop" to =
the target. Once on the clean side of the Proxy server it is then =
possible using the Proxy to redirect attacks into the "protected" LAN.
What can be done to prevent this?
First an foremost enabling packet filtering on the dirty interface card =
can prevent this. Don't allow inbound traffic on port 80. If, however, =
you also use the underlying IIS to publish Web pages to the Internet ( =
that is from the Web Proxy Properties -> Publishing -> Enable Publishing =
-> Send to local Server) then this is not an option and you are at risk.
Secondly, enable access control - this won't stop this from happening =
but unless the attacker has a USER ID and password there is not much =
they can do.
Thirdly, it seems that flushing the static routing table on the machine =
(c:\>route -f) also resolves the problem.
This issue has been reported to Microsoft and they have confirmed this =
to be a problem in some of the aforementioned scenarios but not others. =
I have demonstrated this a number of times now to Diligence's clients in =
all of the above scenarios. To be on the safe side check if you are =
susceptible. It is my opinion that one possible programatic solution to =
this, that MS could produce, would be to have the Proxy server, at the =
application layer in the OSI model, check the IP address of the =
requesting machine and if this address is not in the LAT then Proxy =
should simply discard the request.
David Litchfield
More information can be found at http://www.infowar.co.uk/mnemonix/
* Proxy does not 100% disable connections to port 80 on the dirty =
interface. It is still possible to create a TCP virtual connection but =
nothing useful can be done with it - no information is returned.
------=_NextPart_000_005D_01BE28EB.BDFE0740
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Times New Roman" size=3D2><B>
<P>This advisory is for those using MS Proxy 2.0 with packet filtering =
and use=20
the same machine to Publish Web pages, or those that don't enable packet =
filtering. You network is at risk of attack unless you also employ other =
security measures.</P></B>
<P>In certain and quite common configurations of MS Proxy Server 2.0 it =
is=20
possible to attack the machines it is there to protect. This can be =
acheived in=20
a number of ways, more easily if access can be gained to the same IP =
subnet as=20
the "Dirty" Internet Interface. But first some key facts on =
Proxy.</P>
<P>When MS Proxy is installed on a machine with two interface cards the =
Admin=20
specifies the IP addresses of the machines on the local / corporate =
network.=20
This information is stored in a file called the LAT or Local Address =
Table.=20
Doing this lets Proxy know which interface is the clean client side and =
which is=20
the dirty Internet side. <B>The IP address of the dirty interface should =
not be=20
listed in the LAT. </P></B><B>
<P>IP forwarding should be disabled.</P></B>
<P>Once installed MS - Proxy disables connections to TCP port 80 =
(assuming this=20
is the port Proxy is listening on) on the dirty interface*. Only the =
clean=20
interface will accept connections and service requests on port 80 - =
meaning that=20
only clients on clean side should be able to use the Proxy services.</P>
<P>It is possible, however, to make a connection to port 80 on the clean =
interface from the dirty side. To see this happening set up a host on =
the same=20
IP subnet as the dirty interface and then set your default gateway to =
the IP=20
address of the dirty interface on the Proxy - then telnet to port 80 on =
the IP=20
address of the clean interface. You should be connected. Then issue the=20
request:</P><B>
<P>"GET http://some.protected.machine.on.the.clean.side:port/=20
HTTP/1.0<enter><enter>"</P></B>
<P>Proxy will then establish a TCP connection to the protected machine =
on the=20
port you have specified. It is easier to see this if the machine is an =
Internal=20
Web Server. One would expect with IP forwarding disabled that this =
should not=20
happen - ie the passsing of IP information from the dirty interface to =
the clean=20
interface. This is the "hole" but this is not a bug but rather =
a=20
feature. This happens due to the IP routing algorithm: If a multi-homed=20
computer, not configured as a router, receives a packet on an interface =
it will=20
check all of its local IP addresses and if a match is found - whether =
the IP=20
address is bound to another interface card or not - the information is =
passed=20
across. This should be acheivable also in an attack involving source =
routing,=20
specifying the IP address of the dirty interface as the last =
"hop" to=20
the target. Once on the clean side of the Proxy server it is then =
possible using=20
the Proxy to redirect attacks into the "protected" LAN.</P>
<P>What can be done to prevent this?</P>
<P>First an foremost enabling packet filtering on the dirty interface =
card can=20
prevent this. Don't allow inbound traffic on port 80. <B>If, however, =
you also=20
use the underlying IIS to publish Web pages to the Internet ( that is =
from the=20
Web Proxy Properties -> Publishing -> Enable Publishing -> Send =
to=20
local Server) then this is not an option and you are at risk.</P></B>
<P>Secondly, enable access control - this won't stop this from happening =
but=20
unless the attacker has a USER ID and password there is not much they =
can=20
do.</P>
<P>Thirdly, it seems that flushing the static routing table on the =
machine=20
(c:\>route -f) also resolves the problem.</P>
<P>This issue has been reported to Microsoft and they have confirmed =
this to be=20
a problem in some of the aforementioned scenarios but not others. I have =
demonstrated this a number of times now to Diligence's clients in all of =
the=20
above scenarios. <STRONG>To be on the safe side check if you are=20
susceptible.</STRONG> It is my opinion that one possible programatic =
solution to=20
this, that MS could produce, would be to have the Proxy server, at the=20
application layer in the OSI model, check the IP address of the =
requesting=20
machine and if this address is not in the LAT then Proxy should simply =
discard=20
the request.</P>
<P>David Litchfield</P>
<P>More information can be found at <A=20
href=3D"http://www.infowar.co.uk/mnemonix/">http://www.infowar.co.uk/mnem=
onix/</A></P>
<P>* Proxy does not 100% disable connections to port 80 on the dirty =
interface.=20
It is still possible to create a TCP virtual connection but nothing =
useful can=20
be done with it - no information is =
returned.</P></FONT></DIV></BODY></HTML>
------=_NextPart_000_005D_01BE28EB.BDFE0740--
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:25:03 PDT