This is the first article in a new series: classic bugs. These are bugs that may not always be recent, but surely are interesting, or just still relevant. I think this first bug is both.
I am talking about a bug which could be read about on the Bugtraq mailing list in 1998. The poster, Max Schau started his e-mail with ‘this is an old exploit’, even then. With this bug, you can tell modems (the old analog 56k kind) to hang up. The problem is that with a modem, the data and the modem commands all go through the same communications channel. Sometimes, modems have hard time distinguishing between the two. So, if you can trick someone into sending a modem command, you can influence their modem.
The classic example is the hang up command (ATH0). If I can trick someone into sending that string (preceded by three plus signs) through their modem, a vulnerable modem will hang up. This is easier than it may sound, many systems respond to ICMP echo (ping) packets, and reply to the packet with the same data. So all I have to do is send a modem user an ICMP echo packet containing an AT command and it will reply to the packet, sending the command through the modem.
This denial of service used to be very popular and the beautiful thing is: it still works! At Fox-IT we still have an analog line we use for war dialing. Today, I hooked up a modem and dialed into one of the free dialup ISPs. Using a simple ping command from the original advisory, I was able trick the modem into hanging up! A couple of sources report some modems will hang up when merely visiting a site with an AT command in it, I was not able to reproduce that behavior with my modem.
I spend about half an hour trying to inject other commands (for example to trick the modem into dialing a given number), but was unsuccessful. With other modems this might work better. In the original advisory, someone mentions it may be possible to get modems to dial 911, which would be a big deal. In today’s world, criminals would most likely use it to get modems to dial their premium-rate telephone numbers.
Fortunately, not all analog modems are vulnerable to this attack. Some modems require a pause before sending commands, which makes this attack impossible (or at least very hard). A way of ‘patching’ your modem is in the original advisory, this involves changing the default escape character (+) in your modem using an ATS2 command. It seems the escape character can only be a single byte, so it would be easy to brute force if you know someone has changed it.
Tuesday, November 25, 2008
Thursday, November 20, 2008
Something strange is going on at wpad.be
After writing my last WPAD post, I decided to check if any WPAD TLDs are serving malicious wpad.dat files. So, I took a TLD list I found on the MozillaWiki and tried to retrieve wpad.dat on all of the wpad.tld domains, using cURL with a spoofed user-agent.
I was able to connect to 50 of the nearly 700 TLDs and 24 of them are serving a wpad.dat file. Of those, five seem to be non-malicious (at least, for now): they are either serving a legitimate wpad.dat file or are telling clients not to use a proxy.
The remaining 19 however, all contain the same wpad.dat file (at the same IP address). Among these are some serious domains, such as wpad.at, wpad.be, wpad.in and wpad.es. The wpad.dat tries to match the URL against these shell expressions and tells the browser to use a proxy only if the URL matches:
http://*ad*nd*c*m*sh*ds*js
http*//*s*s*mp*tn*s*p*
Clearly, these people are trying to obfuscate the URLs they are proxying. I had some trouble figuring out what the targets are, but a couple of my colleagues at Fox-IT were able to find a match: http://pagead2.googlesyndication.com/pagead/show_ads.js. Looks like they are intercepting requests for Google ads. At the moment, the proxy seems to return an empty .js file for this request.
According to the HTTP headers, the wpad.dat file has been there since 13 October 2008. It does contain the text ‘testin testin’ so perhaps they are just preparing for something.
I was able to connect to 50 of the nearly 700 TLDs and 24 of them are serving a wpad.dat file. Of those, five seem to be non-malicious (at least, for now): they are either serving a legitimate wpad.dat file or are telling clients not to use a proxy.
The remaining 19 however, all contain the same wpad.dat file (at the same IP address). Among these are some serious domains, such as wpad.at, wpad.be, wpad.in and wpad.es. The wpad.dat tries to match the URL against these shell expressions and tells the browser to use a proxy only if the URL matches:
http://*ad*nd*c*m*sh*ds*js
http*//*s*s*mp*tn*s*p*
Clearly, these people are trying to obfuscate the URLs they are proxying. I had some trouble figuring out what the targets are, but a couple of my colleagues at Fox-IT were able to find a match: http://pagead2.googlesyndication.com/pagead/show_ads.js. Looks like they are intercepting requests for Google ads. At the moment, the proxy seems to return an empty .js file for this request.
According to the HTTP headers, the wpad.dat file has been there since 13 October 2008. It does contain the text ‘testin testin’ so perhaps they are just preparing for something.
Sunday, November 16, 2008
Hacking random clients using WPAD
About two weeks ago, I registered the wpad.nu and wpad.fm domains. WPAD stands for Web Proxy Autodiscovery Protocol and is used by browsers to automatically find the correct proxy server for a URL. The protocol is quite simple: basically if your hostname is host-27.us.company.local, the browser will try to download a wpad.dat configuration file from wpad.us.company.local and if that doesn’t exist wpad.company.local and in some cases finally wpad.local. This doesn’t sound too bad, unless your hostname is wpad.us.company.com (notice the .com tld instead of .local). In this case your browser may be trying to download a proxy configuration file from wpad.com, which could be owned by anyone!
Fortunately wpad.com, wpad.net and wpad.org are owned by Duane Wessels, one of the good guys. He provides some statistics on his site, which show his domain serves about 25 404’s each second (he returns a 404 for the wpad.dat configuration file)!
I registered wpad.nu and wpad.fm thinking I would get a couple of requests every day, however in the last two weeks, nearly 600 unique IP addresses have been asking for the wpad.dat file! About 2/3 seem to access the file through wpad.fm, the rest through wpad.nu. The .nu TLD belongs to some small island in the South Pacific Ocean, but is quite popular as ‘nu’ is the word for 'now' in several languages, including Dutch.
As I am one of the good guys as well, I also do not serve a wpad.dat file. If I did, I could tell the victims browsers to use my server as a proxy, which would allow me to eavesdrop on or modify their web traffic (replacing all downloaded .exe files would be an easy attack). Also, as Chris Paget points out, Internet Explorer will happily NTLM authenticate against any proxy, so stealing domain credentials is also a possibility (which then could potentially be abused for VPN or Outlook Web Access).
Fortunately wpad.com, wpad.net and wpad.org are owned by Duane Wessels, one of the good guys. He provides some statistics on his site, which show his domain serves about 25 404’s each second (he returns a 404 for the wpad.dat configuration file)!
I registered wpad.nu and wpad.fm thinking I would get a couple of requests every day, however in the last two weeks, nearly 600 unique IP addresses have been asking for the wpad.dat file! About 2/3 seem to access the file through wpad.fm, the rest through wpad.nu. The .nu TLD belongs to some small island in the South Pacific Ocean, but is quite popular as ‘nu’ is the word for 'now' in several languages, including Dutch.
As I am one of the good guys as well, I also do not serve a wpad.dat file. If I did, I could tell the victims browsers to use my server as a proxy, which would allow me to eavesdrop on or modify their web traffic (replacing all downloaded .exe files would be an easy attack). Also, as Chris Paget points out, Internet Explorer will happily NTLM authenticate against any proxy, so stealing domain credentials is also a possibility (which then could potentially be abused for VPN or Outlook Web Access).
Finally blogging
Welcome to my shiny new blog! This is just a place for me to put up my ideas and the results of small experiments. I work for an IT security company in The Netherlands as a technical auditor/penetration tester, so I will keep things mostly technical and security related.
Subscribe to:
Posts (Atom)