Shellcode - NSM utfordring 6

Nasjonal Sikkerhetsmyndighet (NSM) har lagt ut en rekke utfordringer / oppgaver som mann kan løse. Jeg satte meg ned i helgen for lese litt på oppgavene, etter å ha lest gjennom de en gang løste jeg noen av, andre var igjen umulig for meg å løse. Denne blogg-posten omhandler "utfordring 6" hvor mann skal analysere noe som ser ut som en shellcode.

Koden vi ser er skrevet som ren maskin-kode (assembly op-codes). Slik maskin-kode kalles ofte for shellkode og blir brukt i forbindelse med utnyttelse av sårbarheter i programmer og OS. Man ønsker at shellcode skal være så liten som mulig, og er ofte bare små program-snutter, slik som vi ser i eksempel under. Navnet kommer av at man ønsker å starte ett skall/shell hvor angriperen har full tilgang til kommandoer etter at en sårbarhet er utnyttet.

Det er lett å identifisere teksten som en shellcode da jeg så noen kjente "op-codes", som xor (31) og cd 80 (unix' syscall: int 80).

31 db f7 e3 68 ff f4 f5 e2 68 fb f5
b0 f8 68 b0 fb fc ff 68 fc f5 e2 f5
68 f5 e2 b0 f6 68 e2 f5 fe f7 68 c6
f9 b0 e4 b9 90 90 90 90 31 0c 04 04
04 3c 1c 75 f7 89 e1 31 c0 b0 04 b2
1c cd 80 b0 01 cd 80

Derfor kan jeg anta at programmet er ment for ett UNIX operativ-system da vi ser nettopp den instruksjonen.

Man kan konvertere dette om til assembly manuelt ved hjelp av "X86 Opcode and instruction Reference" eller ved hjelp av ConvertShellcode.exe diskutert i denne blogg-posten av Lenny Zeltser. Når shellcoden er konvertert kan vi analysere koden ved hjelp av noe så enkelt som ett skrive-program eller om man vil gjøre dynamisk analyse av filen kan mann kompilere som vist i neste steg.

Slik ser maskinkoden ut når den er konvertert til assembly, og det er en liten programsnutt som dekrypterer en text-streng ved hjelp av en xor loop. På bildet ser vi hvilken "nøkkel" som verdiene skal utføres en logisk xor mot.. Jeg måtte ligge inn en "loop" funksjon i assembly koden, slik at JGE-instruksjonen hadde et sted å hoppe til om den IKKE er lik 28, så koden ser da slik ut:

På dette tidspunktet kan man gå mange forskjellige "veier" for å utføre videre analyse av filen. Man kan f.eks kompilere filen som vist på bildet under og kjøre den, enten direkte eller analysere den videre i en disassembler....

Men jeg følte for å koze meg litt til med utfordringen og lagde derfor ett Ruby-script som tar de krypterte dataene og xor'er de med nøkkelen som er 0x90909090. Når jeg først så disse verdiene i maskin-koden trodde jeg det var "nop"-instruksjoner men de viste seg å være verdien dataene skal utføre logisk xor med...