www.hakin9.org

hakin9 Nr 6/2006

42

Teoria

A

naliza statystyk portu hosta stanowi
ważną część analizy bezpieczeństwa
sieci. Proces rozpoznawania udostęp-

nianej usługi i używanego przez nią protoko-
łu aplikacji jest jednak często powierzchowny.
Application Mapping udostępnia metodę peł-
nego, szybkiego i efektywnego pozyskiwania
tych informacji.

Prawdziwie klasyczną dyscypliną bezpie-

czeństwa komputerowego jest skanowanie
portów. Dzięki zautomatyzowanym próbom po-
łączeń oraz ocenie reakcji systemu docelowe-
go można określić statystyki portu. Wiele ła-
twych w obsłudze i od lat doskonalonych na-
rzędzi – np. nmap lub SuperScan – sprawia, że
czynność ta jest efektywna i łatwa [Ruef 1999,
Ruef et al. 2002, McClure et al. 2005]. W przy-
padku sieciowych ataków oraz tych na apli-
kacje sieciowe, bardzo duże znaczenie mają
wspomniane informacje. Otwarte porty i ofero-
wane przez nie usługi stanowią podstawę ata-
ków – definiują one w znacznej mierze obszar
hosta narażony na atak.

Często jednak do przeprowadzenia ata-

ku na aplikację sieciową nie wystarcza samo
ustalenie statystyk portu przy pomocy skano-
wania. Bezpośrednio po skanowaniu portu na-

leży określić, jaki protokół aplikacji jest wyko-
rzystywany na danym porcie. Wprawdzie wie-
lu administratorów wciąż przydziela usługom
standardowe porty zalecane przez IANA, jed-
nak nie można zawsze na tym polegać. W wie-
lu przypadkach spotyka się serwery WWW
na portach takich jak 81 lub 8000 zamiast na
oczekiwanym porcie TCP 80. Mogą również
występować warianty egzotyczne, np. 12345 i
55555 [Ruef 2004, 2006].

Application Mapping

Marc Ruef

stopień trudności

Za pomocą skanowania portów można poznać usługi oferowane

przez system. Chcąc dowiedzieć się jaka usługa kryje się

za danym portem, można skorzystać z techniki Application

Mapping (pol. odwzorowywanie aplikacji), która identyfikuje

rodzaj i protokół badanej usługi. W niniejszym artykule opiszemy

sposoby użycia i ochrony przed Application Mapping.

Z artykułu dowiesz się...

• czym jest Application Mapping i gdzie znajduje

zastosowanie,

• jakie techniki są wykorzystywane,
• jak wygląda automatyzacja przy pomocy na-

rzędzia amap,

• jak zaimplementować własne narzędzie,
• jak utrudnić tego rodzaju identyfikację.

Powinieneś wiedzieć...

• czym jest port;
• znać protokół TCP/IP oraz model komunikacji

klient/serwer.

Application Mapping

hakin9 Nr 6/2006

www.hakin9.org

43

W celu ustalenia użytego pro-

tokołu aplikacji stosuje się technikę
nazywaną ogólnie Application Map-
ping [Ruef 2003]. W zasadzie powin-
na ona nosić nazwę Application Pro-
tocol Mapping ewentualnie Protocol
Mapping, ponieważ celem nie jest
ustalenie właściwej implementacji
aplikacji sieciowej, a jedynie określe-
nie użytego protokołu aplikacji [Pac-
ketwatch 2004]. Nazwa Application
Mapping przyjęła się przede wszyst-
kim dzięki narzędziu amap (Applica-
tion Mapper) umożliwiającemu auto-
matyzację niektórych technik omó-
wionych w dalszej części artykułu.

Automatyczne

powitanie

Zasada działania Application Map-
ping bazuje na modelu komunika-
cji klient/serwer. Serwer udostęp-
nia aplikację sieciową, którą wią-
że z portem TCP lub UDP. Port ta-
ki znajduje się w trybie nasłuchiwa-
nia. Klient, który chce skorzystać z
danej usługi sieciowej, łączy się z
odpowiednim portem docelowym
serwera [Stevens 1994]. Najpopu-
larniejszym przykładem jest serwer
WWW, który zgodnie z zalecenia-
mi IANA jest udostępniany na porcie
TCP 80 (HTTP). Przeglądarka inter-
netowa, w tym przypadku klient, wy-
wołuje cel i docelowy port, żeby po-
brać dokumenty stron WWW. Po-
dobnie przebiega to w przypadku
serwera i klienta e-mail oraz innych
usług sieciowych opartych na mo-
delu klient/serwer.

Niektóre tekstowe aplikacje siecio-

we zostały stworzone z myślą o in-
teraktywności. Po ustanowieniu połą-
czenia witają one klienta specjalnym
banerem zawierającym informacje
dotyczące implementacji oraz innych
możliwości technicznych. Do aplika-
cji tego typu zaliczają się znane, kla-
syczne serwery usług SMTP (tcp/25)
i FTP (tcp/21). Połączenia tego typu
można łatwo inicjować przy pomocy
klienta Telnet, a następnie odczyty-
wać banery powitalne. Proces ten jest
w literaturze anglojęzycznej określa-
ny terminem Banner-Grabbing [Ru-
ef 1999, Ruef et al. 2002, McClure et
al. 2005].

W przypadku połączeniowych im-

plementacji dostępnych we wszyst-
kich popularnych systemach opera-
cyjnych, można to wykonać wpisując

telnet <host docelowy> <port doce-

lowy> [Ruef 2004, 2006]. Na przy-
kład do nawiązania połączenia z ser-
werem mail.computec.ch na porcie
TCP 25 (smtp) wystarcza wprowa-
dzenie telnet mail.computec.ch 25.
Po nawiązaniu połączenia na pozio-
mie protokołu TCP na wyjściu przy-
kładowej sesji Telnet można zaob-
serwować sposób wyświetlenia ba-
nera tego serwera e-mail. Znajduje
się tu nazwa Sendmail oraz numer
wersji 8.12.6 serwera SMTP.

C:\Documents and Settings\mruef>
telnet mail.computec.ch 25
220 mail.computec.ch ESMTP
Sendmail 8.12.6/8.12.6/taifun-1.0;
Wed, 30 Nov 2005 15
:54:54 +0100

Automatyczne powitanie klienta ba-
nerem jest cechą charakterystycz-
ną wielu aplikacji sieciowych. Jest
to wskazówką przy identyfikacji nie-
których znanych implementacji, su-
gerującą takie popularne usługi, jak
SMTP lub FTP. Z drugiej strony auto-
matyczna odpowiedź przemawia ra-
czej przeciwko wykorzystaniu ser-
wera sieciowego HTTP. Taka infor-
macja nie wystarcza jednak do okre-
ślenia użytych aplikacji sieciowych.
Konieczne są dodatkowe szczegóły,
którymi zajmiemy się w dalszej czę-
ści artykułu.

Proste Pattern-Matching

W obrębie komunikatów zwrot-
nych najprostszą w użyciu techni-
ką jest Pattern-Matching. Angiel-
ski termin Pattern-Matching jest na-
zwą techniki polegającej na wyszu-
kiwaniu łańcucha znaków lub dopa-
sowaniu (ang. to match) do okre-
ślonego wzorca (ang. pattern). Naj-
prostszą realizacją jest wyszukiwa-
nie łańcuchów znaków. W celu do-
kładnego wyjaśnienia podstawowej
zasady Application Mapping posłu-
żę się złożonym przykładem. Mamy
plik o nazwie data.txt, w którym za-
pisano następujące wiersze (numery

wierszy należą celowo do treści pli-
ku w celu lepszego zilustrowania za-
gadnienia):

01 To jest pierwszy wiersz
02 To jest drugi wiersz
03 To jest trzeci wiersz
04 To jest koniec pliku

Polecenie grep umożliwia w Uni-
xie przeszukanie treści pliku. Wyko-
rzystuje się w tym celu zwyczajną
składnię polecenia grep <wzorzec>

<plik>. W tym przykładzie wyszu-
kamy w pliku data.txt ciąg znaków

To. Ponieważ wzorzec odpowiada
wszystkim czterem wierszom, zosta-
ną zwrócone w wyniku wszystkie:

mruef@debian:~$ grep To data.txt
01 To jest pierwszy wiersz
02 To jest drugi wiersz
03 To jest trzeci wiersz
04 To jest koniec pliku

Jeśli wyszukiwalibyśmy ciągu zna-
ków występującego tylko w jednym
wierszu, zostałby zwrócony odpo-
wiedni wiersz. Przykładem są wzor-
ce wiersz (wiersze 01, 02 i 03) lub

koniec (tylko wiersz 04). W systemie
Windows można to zrobić przy po-
mocy polecenia find wykorzystują-
cego podobną składnię:

C:\Documents and Settings\mruef>
find data.txt "koniec"
04 To jest koniec pliku

Zastosujmy technikę Pattern-Mat-
ching do odpowiedzi nawiązanego
połączenia. Wynik próby połączenia
z portem TCP 21 hosta ftp.compu-
tec.ch wygląda w następujący spo-
sób:

C:\Documents and Settings\mruef>
telnet ftp.computec.ch 21
220 ProFTPD 1.2.10 Server
(ftp.computec.ch) [80.74.129.35]

Prostą metodą Pattern-Matching
użytą w Application Mapping jest
skorzystanie z nazwy protokołu
[Ruef 2004, 2006]. Ciąg znaków
FTP wskazuje np. na usługę FTP
(File Transfer Protocol) na porcie

hakin9 Nr 6/2006

www.hakin9.org

Teoria

44

docelowym. Podobnie jest ze skró-
tami SMTP dla usług mailowych i
HTTP przy implementacjach ser-
werów sieciowych. Jeśli wykorzy-
stamy wspomniane trzy akroni-
my jako wzorce do dopasowania,
stwierdzimy zgodność w przypad-
ku FTP i brak zgodności odnośnie
SMTP i HTTP. Tak więc we wcze-
śniej nawiązanym połączeniu przy-
puszczalnie jest używany protokół
FTP (File Transfer Protocol). Przy-
puszczenie to pokrywa się również
z użytym portem docelowym, gdyż
IANA przewiduje dla tego rodzaju
komunikacji port TCP 21 (ftp-con-
trol).

False Positives

w Pattern-Matching

Technologia Pattern-Matching ma
wiele zastosowań. We wszystkich
pojawiają się dwa podstawowe pro-
blemy:

•

[baza danych]

można rozpoznać

jedynie te wzorce, które wcze-
śniej już zostały jako takie rozpo-
znane,

•

[rozbieżności]

w zależności od

dokładności zdefiniowania wzor-
ca, zgodności mogą zostać prze-
oczone (false negatives) lub
stwierdzone nieprawidłowo (fal-
se positives).

Problem uprzednio znanej bazy da-
nych ma w odniesieniu do Applica-
tion Mapping ma mniejsze znaczenie
niż w przypadku oprogramowania
antywirusowego, czy automatycz-
nego rozpoznawania włamań. Dzięki
specyfikacjom i ścisłemu przestrze-
ganiu standardów, definicja danych
wejściowych jest prosta. Większe
problemy mogą się pojawić w związ-
ku z dokładnością wyrażeń wzorców
(ang. expressions).

Załóżmy, że w komunikacie

zwrotnym przyjmujemy ciąg znaków
SMTP jako odniesienie do Simple
Mail Transfer Protocol (RFC 821).
Jest to standardowy przypadek, po-
nieważ wiele implementacji SMTP
identyfikuje się nazwą i żądaną wer-
sją protokołu aplikacji. Co się jednak
stanie, jeśli zastosujemy SMTP-
Mapping na serwerze WWW. W ja-
kiś sposób skłonimy go do odesła-
nia nam danych – dokumentu strony
WWW. Dokument ten zawiera rów-
nież ciąg znaków SMTP, ponieważ
przypadkowo jego treścią są połą-
czenia e-mailowe i ich standardy.
W tym przypadku Pattern-Matching
wskaże nieprawidłowo na SMTP ja-
ko potencjalnie zastosowany proto-
kół aplikacji.

Zafałszowanie wyników występu-

je w przypadku automatyzacji więk-
szości procesu Application Mapping.

Aby temu zapobiec, należy wprowa-
dzić bardziej złożone metody w obrę-
bie Pattern-Matching. Wyrażenia re-
gularne umożliwiają wprowadzenie
wyraźnych ograniczeń, dzięki cze-
mu samo wystąpienie określonego
ciągu znaków nie jest równoznaczne
ze zgodnością. (Implementacja funk-
cji amap dodatkowo pomaga w roz-
wiązaniu tego problemu przy pomo-
cy analizy długości odpowiedzi. Bliż-
sze informacje na ten temat w roz-
dziale dotyczącym funkcji amap.)

W obrębie Application Mapping

dla SMTP można ograniczyć wy-
szukiwanie np. do pierwszych wier-
szy odpowiedzi. Nagłówek SMTP
jest zwracany po ustanowieniu po-
łączenia jako pierwszy baner powi-
talny zawierający żądane informacje
(ok. 100 pierwszych bajtów). W przy-
padku połączenia HTTP z serwerem
sieciowym udostępniającym doku-
ment strony WWW z ciągiem zna-
ków SMTP w treści, zostanie on zna-
leziony dopiero po nagłówku HTTP
(po ok. 250 bajtach). Umożliwia to
eliminację lub przynajmniej znaczne
zminimalizowanie komplikacji.

Istnieją jednak sytuacje wymaga-

jące użycia bardziej rozbudowanych
wyrażeń regularnych. Jest tak np.
w przypadku dynamicznych ciągów
znaków o podobnej strukturze pod-
stawowej. Dobrym przykładem jest
usługa daytime, oferowana zarów-
no na TCP jak i UDP, na przydzielo-
nym przez IANA porcie 13. W przy-
padku daytime, po ustanowieniu po-
łączenia serwer przesyła do klienta
ciąg znaków informujący o aktualnej
godzinie oraz dacie. Forma jest czy-
telna również dla człowieka. W przy-
padku Unixa, odpowiedź wygląda
następująco (wiersz 02):

01 C:\Documents and Settings\
mruef>telnet 192.168.0.10 13
02 Mon Nov 28 13:42:23 2005

W amap, pierwszej zautomatyzo-
wanej implementacji dla Application
Mapping, w pliku odpowiedzi app-
defs.resp wykorzystuje się następu-
jący wiersz, który dzięki regularne-
mu wyrażeniu jest w stanie zapisać
odpowiedź:

Tabela 1.

Proste wzory rozpoznawania usług

Nazwa

Protokół

Port

Wyzwalacz

Cisco PIX Firewall
SMTP

tcp

25

^220.*\**\**\**\**

Dict

tcp

2628

^220 .* dictd

FTP

tcp

21

^220.*\n || ^220.*FTP

ftp-darwin

tcp

21

^220 Inactivity timer

Glftp

tcp

21

^220.*SSH

Hylafax

tcp

4559

^220 .*hylafax

NNTP

tcp

119

^200.*NNTP

Oracle HTTPS

tcp

1526

^220- ora

POP3

tcp

110

^220.*poppassd || 500 Pas-
sword

SMTP

tcp

25

^220.*\n250 || ^220.*SMTP

TrendMicro Inter-
Scan SMTP

tcp

25

^220.*InterScan

vmware-authd

tcp

902

^220 VMware Authentication

hakin9 Nr 6/2006

www.hakin9.org

Teoria

46

daytime-unix:::26:^[A-Z].*
[A-Z].* [0-3].
[0-9][0-9]:[0-9][0-9]:
[0-9][0-9] 200.\rn

Wzorzec ten jest właściwie bardzo
dokładnie, ale nie bezbłędnie przy-
stosowany do odpowiedzi daytime
w środowisku unixowym. Możliwo-
ści optymalizacji są niewielkie. W od-
powiedzi daytime-unix na pierwszym
miejscu znajduje się dzień tygodnia
jako ciąg trzech znaków (np. Mon
dla poniedziałku (Monday) i Tue dla
wtorku (Thuesday). Wyrażenie re-
gularne jest w stanie rozpoznać ten
ciąg znaków, jednak nie uwzględnia
długości napisu. Teoretycznie zosta-
łyby więc rozpoznane również roz-
szerzone zwroty postaci „Monday
Nov 28 15:03:23 2005“. To samo do-
tyczy przedstawienia miesiąca przy
pomocy trzech liter (np. Nov dla listo-
pada (November) i Dec dla grudnia
(December). Ponieważ implementa-
cje unixowe są pod tym względem
dość usystematyzowane, nieprawi-
dłowe rozpoznania w tym obszarze
należą do rzadkości. Bardziej pro-
blematyczne jest ograniczenie cyfry
roku od 2000 do 2009. W przypadku
systemu o błędnej konfiguracji (np. w
roku 1984) prawidłowe sprawdzenie i
rozpoznanie nie jest możliwe.

Dodatkowym

interesującym

aspektem tej procedury analizy jest
możliwość uzyskania informacji do-
tyczących systemu operacyjnego tyl-
ko przy pomocy odpowiedzi tak nie-
pozornych usług jak daytime, nie za-

wierających bezpośrednich odnośni-
ków do wykorzystywanego syste-
mu operacyjnego. Z kolei baza da-
nych sygnatur (fingerprint) funkcji
amap prowadzi pięć różnych wpisów
dla daytime, przy czym dwa dotyczą
systemu Unix (wiersze 01 i 03), a je-
den Windows (wiersz 02). Pozostałe
wpisy są ogólne.

01 daytime-unix:::26:^[A-Z].* [A-Z]
[0-3].* [0-9][0-9]:[0-9][0-9]:
[0-9][0-9] 200.\rn
02 daytime-windows:::26-50:^
[A-Z][a-z]+, [A-Z][a-z]+ [0-9]+,
200[0-9] [0-9]+:[0-9]+:[0-9]+
\x0a\x00
03 daytime-unix:::20-36:^
[A-Z][a-z]+ [A-Z][a-z]+
[0-9 ][0-9] [0-9]+:[0-9]+:
[0-9]+ 200[0-9]\x0d\x0a
04 daytime:::25-30:^
[0-9][0-9] [A-Z][A-Z][A-Z]

200[0-9] [0-9][0-9]:
[0-9][0-9]:[0-9][0-9] .*
05 daytime:::26-45:^
[A-Z][a-z][a-z]*,
[A-Z][a-z][a-z]* [0-9]+, 200

Trzycyfrowe

kody statusu

Wiele aplikacji sieciowych stworzo-
nych w celu umożliwienia bezpo-
średniej interaktywności użytkowni-
ka korzysta z kodów statusu. Pole-
ga to na uprzednim przyznaniu każ-
demu wejściu i wyjściu liczbowego
kodu statusu, z reguły trzycyfrowe-
go. Np. FTP, SMTP oraz inne kla-
syczne protokoły wykorzystują war-
tość 220 do potwierdzenia pomyśl-
nego przetworzenia zapytania. Pro-
ducenci kierują się zasadą, wg której
pierwsza cyfra trzycyfrowego kodu
statusu określa kategorię (np. sku-
teczne), druga definiuje rodzaj ko-
munikatu (np. znaleziono zasób), a
ostatnia zróżnicowany opis (np. ode-
słano żądany zasób). Powodem za-
stosowania wartości liczbowej całko-
witej jako kodów statusu jest ich ła-
twe przetwarzanie przez klienta. Mu-
si on tylko wczytać trzy pierwsze baj-
ty zwrotu w celu uzyskania informacji
o aktualnym stanie rzeczy (w innym
przypadku konieczne byłoby rozpo-
znawanie pełnych słów).

Na kolejnej pozycji w tym samym

wierszu znajduje się oddzielony spa-
cją tekst statusu. Jest on wykorzysty-
wany w sytuacjach, kiedy usługa jest
używana bez odpowiedniego klienta,
i kiedy rezygnuje się z automatycz-

Tabela 2.

Polecenia wspierane przez popularne protokoły aplikacji

FTP

SMTP

POP3

NNTP

HELP

X

X

X

USER

X

X

PASS

X

PORT

X

STOR

X

HELO

X

VRFY

X

EXPN

X

RSET

X

NOOP

X

X

QUIT

X

X

X

X

Tabela 3.

Typowe zachowania timeout różnych usług

Zachowanie timeout

Przykłady

Brak funkcji timeout

Telnet, SSH, NNTP, Echo, Discard, Chargen

Zerwanie połączenia po
poleceniu timeout

FTP, netbios-ssn (ca. 30 Sek)

Zerwanie połączenia po
dowolnym poleceniu(ach)

HTTP, HTTPS/SSL, Finger, Time

Zerwanie połączenia po
ostatnim poleceniu(ach)

HTTP, HTTPS/SSL, Finger, Time

Zerwanie połączenia po
nieprawidłowym polece-
niu(ach)

Niektóre implementacje SMTP, niektóre auto-
ryzacje terminala (n[p. telnet lub SSH), Proxy z
listami dostępu (Access Lists)

Polecenie NOOP po po-
leceniu timeout

FTP

Application Mapping

hakin9 Nr 6/2006

www.hakin9.org

47

nej interpretacji trzycyfrowego kodu
statusu (np. w przypadku wykorzy-
stania interaktywnej sesji telnet). W
przypadku udanej komunikacji inte-
raktywnej przy pomocy FTP, pierw-
szy wiersz mógłby mieć postać 220

Found. Inne kody statusu wskazu-
ją na błędy serwera lub klienta, albo
brakujące implementacje. Spójrzmy
na krótki przykład sesji FTP:

01 C:\Documents and Settings\mruef>
ftp 192.168.0.10
02 Connected to 192.168.0.10.
03 220 debian.computec.ch FTP server
(Version 6.4/OpenBSD/

Linux-ftpd-0.17) ready.
04 User (192.168.0.10:(none)): mruef
05 331 Password required for mruef.
06 Password: xxxxxxxx
07 230- Linux debian 2.6.12-1-386 #
1 Tue Sep 27 11:02:18 JST
2005 i686 GNU/Linux
08 230 User maru logged in.
09 ftp>

Jako pierwsze z naszego windowso-
wego komputera nawiązujemy połą-
czenie FTP z systemem docelowym
o adresie IP 192.168.0.10 (wiersz
01). Nasz klient FTP pokazuje nam,
że nawiązanie połączenia przebie-

gło pomyślnie (wiersz 02). W pierw-
szym zwrocie serwera FTP (wiersz
03) wyświetlany jest baner powitalny.
Warunkiem wstępnym jest trzycyfro-
wy kod statusu 220, wskazujący na
udany dostęp. Po wprowadzeniu na-
zwy użytkownika mruef (wiersz 04),
konieczne jest wprowadzenie odpo-
wiedniego hasła (wiersz 05). Widzi-
my tutaj kod statusu 331, wskazujący
na konieczność autoryzacji.

Zasada działania Application

Mapping może być tutaj użyteczna
właśnie ze względu na wykorzysty-
wany przez różne systemy (trzycy-
frowy) kod statusu. Zasady seman-
tyczne tego rodzaju wskazują na
interaktywne protokoły ASCII NVT,
np. FTP, SMTP lub POP3 [Stevens
1994, Ruef et al. 2002]. Tabela 1 za-
wiera popularne protokoły warstwy
aplikacji wykorzystujące klasycz-
ną zasadę kodów statusu. W ostat-
niej kolumnie zamieszczono wyzwa-
lacz (trigger) umożliwiający identy-
fikację odpowiedniego rodzaju pro-
tokołu. Ich forma została możliwie
uproszczona aby ułatwić zrozumie-
nie zagadnienia. Istnieje możliwość
ich dodatkowej optymalizacji i dzię-
ki temu ograniczenia ilości błędnych
komunikatów.

Najpierw złożenie

formalnego zapytania

Istnieją również usługi nie posiadają-
ce funkcji powitania klienta po usta-
nowieniu połączenia. Tego rodza-
ju implementacje można ze wzglę-
du na zachowanie gospodarza na-
zwać niegrzecznymi lub nieuprzej-
mymi. Komunikacja tego rodzaju wy-
gląda przeważnie w taki sposób, że
po ustanowieniu połączenia ekran
po stronie klienta pozostaje pusty.
Serwer (aplikacja sieciowa) oczeku-
je na pierwsze zapytania zanim sam
zareaguje. Jeśli nie otrzyma zapytań
w ciągu kilku sekund lub minut, może
przy pomocy funkcji Timeout dopro-
wadzić do automatycznego zerwa-
nia połączenia, co zapobiega niepo-
trzebnemu wykorzystywaniu zaso-
bów trwających połączeń.

Z pewnością najbardziej znaną

implementacją protokołu aplikacji,
oczekującą formalnego zapytania,

Tabela 4.

Pełne wzory programu amap

Nazwa

Proto-

kół

Dłu-

gość

Wzorce

Dante

tcp

2

\x05\x02

Daytime-unix

tcp/udp

26

^[A-Z].* [A-Z].* [0-3].* [0-9][0-9]

Daytime-windows tcp/udp

26-50 ^[A-Z][a-z]+, [A-Z][a-z]+ [0-9]+,

200[0-9] [0-9]+

Daytime-unix

tcp/udp

20-36 ^[A-Z][a-z]+ [A-Z][a-z]+ [0-9 ][0-9]

[0-9]+

Daytime

tcp/udp

25-30 ^[0-9][0-9] [A-Z][A-Z][A-Z] 200[0-

9] [0-9][0-9]

Daytime

tcp/udp

26-45 ^[A-Z][a-z][a-z]*, [A-Z][a-z][a-z]*

[0-9]+, 200

Dhcp3d-isc

tcp

8

^\x00\x00\x00\x64\x00\x00\x00\
x18

Dns-pdnsd

tcp/udp

2

^\x00\x0c

Finger

tcp

1

\x66

http-compaqinsi-
ghtmanager

tcp

6

^HTTP/1

http-iis

tcp

34

^<h1>Bad Request .Invalid
URL.</h1>

Mailhurdle

udp

10

\x00\x08\x06\x9f\x7a\x06\x00\
x00\x00\x00

Mldonkey

tcp

1

\x31

ms-distribution-
transport

tcp(/udp) 6

^..\x0a\x00

Ms-dtc

tcp/udp

3

..\n

Netmeeting

tcp

4

^\x03\x00\x00\x11

NTP

udp

48

^....\x00\x00..\x00\x00

QOTD

tcp/udp

5-
1000

^"[A-Z].* .* .*[!?.]"\rn[A-Za-z].*\rn

SNMP

tcp

3

\x41\x01\x02

Spamd

tcp

1

\x32

SSL

tcp

1

\n

Time

tcp/udp

4

^\xc[2-5]

hakin9 Nr 6/2006

www.hakin9.org

Teoria

48

jest HTTP (Hyper Text Trabsfer Pro-
tocol). Przyjrzyjmy się przykładowi
ręcznego nawiązywania połączenia
z hostem o adresie IP 192.168.0.10
przy pomocy klienta Telnet na porcie
docelowym TCP 80:

01 C:\Documents and Settings\mruef>
telnet 192.168.0.1 80
02 HEAD / HTTP/1.0
03
04 HTTP/1.1 200 OK
05 Date: Mon, 28 Nov
2005 16:39:07 GMT
06 Server: Apache/
1.3.34 (Debian)
07 Connection: close
08 Content-Type: text/
html; charset=iso-8859-1
09
10
11
12 Connection to host lost.

Po zainicjowaniu połączenia przy
pomocy telnetu (wiersz 01), klient
musi sformułować zapytanie. Ponie-
waż wiemy, że chodzi o implementa-
cję serwera HTTP, została od razu
użyta prawidłowa składnia. Przy po-

mocy zapytania „HEAD / HTTP/1.0“
(zamkniętego przy pomocy dwóch
znaków nowej linii wiersze 02 i 03)
sprowokowano regularną odpowiedź
(wiersze 04 do 11). Zawiera ona ty-
powe cechy HTTP (np. rozpoczęcie
odpowiedzi ciągiem znaków HTTP
oraz wiersz rozpoczynający się „Se-
rver: “). Bez inicjacji przy pomocy za-
pytania HTTP HEAD nie byłoby to
możliwe w opisanej formie.

W standardowym przypadku

podczas Application Mapping nie po-
siadamy jednak informacji o usłudze
dostępnej na porcie docelowym. Tak
więc przy pierwszej próbie nie może-
my wykorzystać użytego w przykła-
dzie zgodnego zapytania. W takich
przypadkach należy jako czynność
inicjującą zastosować kilkukrotne
wciśnięcie klawisza Enter. W więk-
szości przypadków wywoła to ko-
munikat błędu (np. „Not supported“
lub „Syntax unknown“) zawierający
również wiele informacji przydatnych
do analizy protokołu. Statystycz-
nie z powodu łatwości implementa-
cji i użycia często wykorzystywane
są implementacje HTTP, nawet jeśli
chodzi o rzekomo trwające wywoła-

nia. W takim przypadku można uzy-
skać pozytywne wyniki również wy-
korzystując dane wejściowe typowe
dla HTTP, np. „GET / HTTP/1.0“.

Bodźce i reakcje

Stwierdziliśmy już, że niektóre apli-
kacje interaktywne charakterystycz-
nie witają klienta bezpośrednio po
nawiązaniu połączenia. Omówiliśmy
również inne nieuprzejme usługi ty-
pu HTTP, które należy prosić o na-
desłanie danych. Zajmiemy się teraz
szczegółami dotyczącymi tych ostat-
nich. Nie będziemy jednak ich oma-
wiać w powiązaniu ze wspomniany-
mi nieuprzejmymi implementacja-
mi. Naszym celem jest poprawa wy-
dajności funkcji Application Mapping
poprzez prowokowanie możliwie jed-
noznacznych reakcji.

Klasyczną,

acz

niekoniecz-

nie wykorzystywaną możliwością,
jest użycie funkcji pomocy. Polece-
nie HELP wyświetlające listę obsłu-
giwanych komend, oferują przede
wszystkim usługi interaktywne, np.
FTP lub SMTP. Przy pomocy funkcji
HELP, ewentualnie na podstawie za-
wartych w niej poleceń, można czę-
sto bardzo dokładnie określić użyty
protokół aplikacji. Tabela 2 zawiera
informacje dotyczące najczęściej
dostępnych poleceń w popularnych
protokołach aplikacji. Lista ta nie jest
jednak pełna, ani z punktu widzenia
protokołu, ani poleceń.

Tylko na podstawie komunikatu

błędu, bez względu na dostępność
polecenia, można wyciągnąć okre-
ślone wnioski dotyczące użytego pro-
tokołu. Zaleca się jednak ostrożność,
gdyż nie wszystkie implementacje
serwerów muszą wspierać wszystkie
polecenia. Wiele nowoczesnych ser-
werów SMTP rezygnuje ze względów
bezpieczeństwa z klasycznych pole-
ceń typu VRFY, EXPN, DEBUG lub
nawet HELP. Komunikaty błędu, o ad-
ministracyjnej odmowie tego rodzaju
dostępu lub braku implementacji da-
nego polecenia nie należą do rzadko-
ści. Zbyt duże znaczenie przykładane
do tego rodzaju charakterystyki może
prowadzić do błędnych rezultatów.

Jeśli kilka protokołów warstwy

aplikacji wspiera te same polecenia,

Rys. 1.

Przebieg procesu Application Mapping przy pomocy bodźca/reakcji

Application Mapping

hakin9 Nr 6/2006

www.hakin9.org

49

konieczne jest przeprowadzenie in-
nej analizy. Jest to możliwe np. po-
przez sprawdzenie odpowiednich
implementacji pod kątem wykorzy-
stania parametrów. Również regular-
ne odpowiedzi mogą się różnić w za-
leżności od usługi. Wiele serwerów
FTP zezwala np. na parametr po-
lecenia HELP. W przypadku wpro-
wadzenia polecenia „HELP PORT“,
uzyskuje się specyficzne informa-
cje dotyczące pomocy dla polecenia
FTP PORT. Podobnie bywa w przy-
padku protokołu SMTP.

Timeout

Widzieliśmy już, że podstawowe po-
witanie może zawierać charaktery-
stykę aplikacji sieciowej oraz udo-
stępnionego przez nią protokołu apli-
kacji. W zależności od powitania
klienta zautomatyzowanym bane-
rem, może to wskazywać na aplika-
cję interaktywną (np. SMTP) lub nie-
interaktywną (np. HTTP).

Podobną cechą charakterystycz-

ną, którą można wykorzystać ja-
ko wskaźnik służący do określenia
usługi jest tzw. zachowanie Timeout.
W standardowym przypadku Time-
out występuje w obrębie aplikacji, je-
śli przez dłuższy czas nie nastąpi re-
gularna wymiana danych. Czas za-
stosowania timeout'u wynosi od mi-
lisekund aż do godzin. Przeważnie
przy średnio aktywnych aplikacjach
opierających się na sesjach czas ten

wynosi kilka sekund (np. 10 sekund)
lub kilka minut (np. 2 minuty).

W obrębie analizy timeout mogą

być wyświetlane różne statusy. Nale-
ży przy tym zaznaczyć, że nie jest
to uzależnione od protokołu aplika-
cji, a w największym stopniu od po-
szczególnych implementacji i ich
konfiguracji. Wiele usług umożliwia
bowiem mniej lub bardziej ukryte de-
finiowanie wartości timeout w pliku
konfiguracyjnym. Ogólnie rozróżnia-
my sześć następujących statusów:

Najgorszym wariantem w obrę-

bie Application Mapping jest brak
timeout'u lub bardzo długi czas ti-

meout'u. Podobnie jak w przypadku
wyprowadzenia logicznego dowodu
ciężej jest określić brak stanu, niż je-
go istnienie. Weryfikacja statusu bra-
kującego timeout'u jest bardzo trud-
na i odpowiednio długa. Jest to jed-
na z przyczyn unikania tego rodza-
ju implementacji. Jeśli jednak chce-
my zastosować taką implementa-
cję, należy określić dla praktyczne-
go zastosowania krótki czas weryfi-
kacji (np. maksymalnie 120 sekund).
Przykładem aplikacji niestosujących
timeout'u są klasyczne usługi ty-
pu Echo, Discard i Chargen. Rów-
nież emulacje terminala, np. telnet
lub SSH rzadko są przerywane au-
tomatycznie.

Standardowe automatyczne prze-

rwanie połączenia odbywa się z re-
guły po ograniczonym czasowo po-
leceniu timeout. Dobrym przykładem
jest komunikacja FTP, która po okre-
ślonym czasie (i wielokrotnym użyciu
polecenia NOOP) zamyka połączenie
od strony serwera.

Rzadziej spotykaną opcją jest

półautomatyczne przerwanie połą-
czenia po wprowadzeniu polecenia
i wygenerowaniu odpowiedniej od-
powiedzi. Ma to miejsce przeważ-
nie w połączeniach sesyjnych, w któ-
rych istotne jest utrzymanie możliwie
niewielkiej ilości stałych kanałów ko-
munikacyjnych. Najpopularniejszym
przykładem jest HTTP, w przypadku

Listing 1

Prosta implementacja funkcji Application Mapping

01 #!/bin/sh
02
03

echo

"pmap v1.0"

04
05

if

[

$#

== 2

]

;

then

06

echo

"Starting protocol mapping ..."

07 RESPONSE=`

echo

-e

"QUIT

\n

"

| nc –vv –w 3

$1

$2

`

08
09

echo

-n

"Testing for trigger ftp ... "

10 MATCH=`

echo

"

$RESPONSE

"

| grep ftp`

11

if

[

"

$MATCH

"

]

;

then

12

echo

"Found!"

13

else

14

echo

"Not found."

15

fi

16

else

17

echo

"Please use the following syntax:"

18

echo

"pmap.sh <dhost> <dport>"

19

fi

Tabela 5.

Znaczenie wskazówek podczas rozpoznawania

Nazwa

Zna-

czenie

Opis

Numer portu

5 %

Jeśli na testowanym porcie jest dostępna usłu-
ga, dla której IANA zaleca dany port jako stan-
dardowy.

Protokół
transportu

5 %

Jeśli używany jest protokół transportowy, wyko-
rzystywany w standardowych implementacjach
(np. TCP dla HTTP i UDP dla TFTP).

Powitanie

5 %

W zależności od tego, czy dany protokół trans-
portowy stosuje automatyczne powitanie przy
pomocy banera.

Timeout

5 %

Jeśli aplikacja stosuje po upływie określonego
czasu automatyczny timeout.

Odpowiedź
bez bodźca

35 %

Przedstawienie banera powitalnego wysłanego
automatycznie po nawiązaniu połączenia.

Odpowiedź z
bodźcem

45 %

Przedstawienie odpowiedzi sprowokowanej
przez bodziec.

hakin9 Nr 6/2006

www.hakin9.org

Teoria

50

którego po zapytaniu klienta i odpo-
wiedzi serwera połączenie jest auto-
matycznie zamykane przez serwer.
Innymi implementacjami tego rodza-
ju są Daytime, Time i QOTD.

Inne usługi interaktywne zamy-

kają automatycznie połączenie, je-
śli klient nie spełni określonych wy-
magań. Wiele serwerów zamyka np.
nawiązywanie połączenia sesji emu-
lującej terminal przy pomocy telnetu
lub SSH w przypadku kilkukrotnego
wprowadzenia nieprawidłowego ha-
sła. Niektóre serwery SMTP kończą
nagle komunikację, jeśli klient chce
kilka razy z rzędu wykorzystać nie-
implementowane polecenie. Zacho-
wanie to jest w rzeczywistości rów-
nież zależne od architektury aplikacji
i nie odnosi się bezpośrednio do pro-
tokołu aplikacji.

Ostatni rodzaj zachowania do-

tyczący timeout'u ma miejsce pod-
czas użycia wygenerowanych auto-
matycznie poleceń NOOP. NOOP
jest skrótem od angielskiego zwro-
tu „No Operation“. Polecenie to jest
celowo stosowane okresowo w ce-
lu uniknięcia automatycznego za-
mknięcia połączenia. W ten spo-
sób klient lub serwer podtrzymu-
ją połączenie i kanał komunikacji
poprzez wymianę niewielkiej ilości
danych. Tego rodzaju operacja jest
często wykorzystywana przez apli-
kacje interaktywne, np. FTP. Do-
piero po wielokrotnym użyciu pole-
cenia NOOP przez kilka minut ma
miejsce przerwanie połączenia ze
strony serwera.

Analiza zachowania timeout'u nie

jest łatwa. Wymaga często dużych
nakładów czasowych, wielu zróż-
nicowanych testów i często nie da-
je jednoznacznych rezultatów. Z te-
go względu w przypadku amap zre-
zygnowano z implementacji tego ro-
dzaju analizy. Należy się również li-
czyć z rezygnacją z tego rodzaju roz-
szerzenia, gdyż współczynnik nakła-
dów do zysków tego rodzaju oceny
wypada zdecydowanie negatywnie.

Automatyzacja

przy pomocy amap

Jedną z pierwszych zautomatyzowa-
nych implementacji Application Map-

ping jest oprogramowanie amap. Je-
go nazwa nawiązuje do popularne-
go narzędzia służącego do skano-
wania i oceny nmap autorstwa Fy-
odora. Amap jest udostępniany na
licencji GPL (General Public Licen-
se), a stworzony został dla syste-
mów UNIX/Linux przez Van Hause-
r'a i DJ RevMoon'a z niemieckiej gru-
py THC (The Hackers Choice, http:

//www.thc.org).

Podstawowa obsługa oprogra-

mowania przypomina nmap. Rów-
neiż tutaj pierwszym argumentem
jest nazwa lub adres IP systemu
docelowego. Jako drugi parametr
należy obowiązkowo wprowadzić
numer portu w zakresie od 1 do
65535. Jeśli rezygnujemy z użycia
opcji –u, uzyskujemy standardo-
wy dostęp do portu TCP. W innym
przypadku jako protokół transportu
jest stosowany UDP. Jeśli kontroli
podlegają jedynie określone proto-
koły aplikacji, korzystne jest wyko-
rzystanie parametru -p <protokół>,
dopuszczającego specyfikację po-
szczególnych protokołów (np. ftp
lub smtp).

Dla programistów, profesjonal-

nych testerów oraz podczas wykry-
wania błędów (debugging) interesu-
jący jest przełącznik –d. Przy jego
pomocy można zalecić programo-
wi amap przekazywanie odpowiedzi
z docelowego portu na standardo-
we wyjście (stdout). W widoku szes-
nastkowym oraz ASCII odpowiedzi
są przejrzyste, dzięki czemu można
dokładnie określić bodźce i wywoła-
ne reakcje, a dzięki temu zbieżności
wzorców. Podobnie jest w przypadku
opcji –b wywołującej zwrot wszyst-
kich odpowiedzi ASCII skutecznych
wyzwalaczy.

Poza plikiem binarnym, będą-

cym sercem programu amap, istnie-
ją trzy modułowe bazy danych. Da-
ne zapisane jako standardowe pli-
ki tekstowe znajdują się w katalogu
/usr/share/amap. Duże znaczenie
ma plik appdefs.trig zawierający wy-
zwalacze służące do wykorzystania
bodźców. Np. do testu SMTP, prze-
prowadzanego standardowo na por-
cie

Port tcp/25

wykorzystywany jest

bodziec

HELO AMAP\r\n

.

Równie ważny jest plik app-

defs.resp zawierający możliwe odpo-
wiedzi poszczególnych usług w for-
mie wyrażeń wyrażeń regularnych.
Amap w przypadku odpowiedzi ser-
wera FTP spodziewa się ciągu zna-
ków Login name: lub

^220.*FTP

. Nie

stosuje się złożonych, pakietowa-
nych oraz rekursywnych wyrażeń re-
gularnych. Ich zastosowanie prowa-
dziło do odnajdywania dla różnych
usług wielu wierszy, które utrudniały
uzyskanie jednoznacznego wyniku.
Do analizy zachowania portu RPC
wykorzystuje się oddzielny plik app-
defs.rpc, który zapisuje odpowiednie
numery ID popularnych usług RPC.

Automatyzacja przy

pomocy zwrotów nmap

Funkcją szczególną programu amap
niedostępną w innych narzędziach
(nawet w przypadku stworzenia wła-
snego rozwiązania) jest analiza ob-
jętości reakcji. W czwartej kolumnie
pliku odpowiedzi appdefs.resp zapi-
sywana jest opcjonalnie przy pomo-
cy wartości całkowitej (bezwzględ-
nie lub zakres) oczekiwana dłu-
gość odpowiedzi. Jest to dodatko-
wy wskaźnik gwarantujący popraw-
ność kontroli.

Rys. 2.

Przebieg inteligentnego

procesu Application Mapping

Tworzenie własnego

rozwiązania

W pierwszej części artykułu omówi-
liśmy koncepcję oraz podstawy tech-
niczne Application Mapping, w drugiej
części przeanalizowaliśmy możliwą
implementację na podstawie przykła-
du THC amap. Nadszedł więc czas
na stworzenie własnego oprogramo-
wania. Chodzi tylko o przedstawienie
ogólnych przykładów, przy pomocy
których omówimy zasady tworzenia
własnych rozwiązań oraz poszcze-
gólne implementacje. Perfekcyjność
użycia oprogramowania nie ma tu-
taj znaczenia. Implementację nasze-
go rozwiązania przeprowadzimy przy
pomocy prostego skryptu Shell. Nie-
stety nie oferuje on, ani z punktu wi-
dzenia programisty wysokiej wydaj-
ności, ani szczególnych możliwości
pod względem ergonomii. Dzięki pro-
stemu i ogólnemu językowi skrypto-
wemu łatwiej jednak będzie wyjaśnić
omawiane zagadnienia. Nasz mały
projekt programistyczny ma następu-
jące wymagania:

•

[wykorzystanie oprogramowania]

implementacja aplikacji do ce-
lów półautomatycznych Applica-
tion Mapping,

•

[objętość]

wykorzystanie roz-

wiązania opartego na wierszach
przy pomocy skryptu Shell,

•

[Pattern-Matching]

tylko wyko-

rzystanie prostej funkcji Pattern-
Matching w obrębie odpowiedzi.

Jak widać na liście wymagań, zrezy-
gnujemy z implementacji niektórych
technik analizy (np. zachowania ti-
meout i analizy długości). Naszym
celem jest bezpośrednie przejęcie
komunikatów zwrotnych przy pomo-
cy wyzwalaczy, które sprawdzimy z
naszymi zapisanymi wzorami. Poniż-
szy diagram blokowy ilustruje te pro-
ste zachowania (Rys. 1.).

Najpierw sprawdzimy, czy docelo-

wy port znajduje się w trybie nasłuchi-
wania. Jeśli nie, stan ten zostanie za-
pisany, a program zostanie zamknięty
komunikatem błędu. Jeśli możemy na-
wiązać połączenie z portem docelo-
wym, wysyłamy pierwszy wyzwalacz,
którym chcemy sprowokować odpo-

hakin9 Nr 6/2006

www.hakin9.org

Teoria

52

wiedź. Następnie analizujemy odpo-
wiedź pod kątem obecności wzorca.
Jeśli odpowiedź zawiera wzór, wy-
nik zostanie zapisany oraz zostaną
przygotowane dane wyjściowe. Przed
opuszczeniem aplikacji zostanie wy-
świetlony wynik procesu skanowania.

Prosta implementacja

skryptu Shell

W rozdziale tym zajmiemy się pro-
stą implementacją zdefiniowanych
uprzednio wymagań narzędzia do
półautomatycznego przeprowadze-
nia procesu Application Mapping.
Wykorzystamy do tego celu prosty
skrypt Shell obejmujący łącznie 19
wierszy (Listing 1.)

W wierszu 03 wyświetlamy tytuł

naszej aplikacji. Naszą przykładową
implementację nazwiemy pmap, jako
skrót pochodzący od nazwy funkcji
Protocol Mapping.

W wierszu 05 przeprowadzamy

kontrolę liczby argumentów przeka-
zanych wywołaniem skryptu przy
pomocy instrukcji warunkowej if. Je-
śli nie przekazano 2 argumentów,
zapytanie przechodzi bezpośrednio
w gałąź else (wiersz 16), gdzie zwra-
cany jest tylko komunikat błędu, krót-
kie wyjaśnienie wymaganej składni
dla wywołania skryptu. po czym na-
stępuje zakończenie wykonywania
programu (wiersze 17 do 19).

Jeśli przekazano dokładnie 2 ar-

gumenty, aplikacja uruchamia Proto-
col Mapping (wiersz 06). Wiersz 07
można traktować jako serce aplikacji.
Tutaj przy pomocy narzędzia siecio-
wego NetCat tworzone jest połącze-
nie z systemem docelowym (pierw-
szy argument $1) oraz portem do-
celowym (drugi argument $2). Jeśli
ustanowiono połączenie, przez kanał
jest przesyłany znak nowej linii. Wy-
nik tego dostępu jest zapisywany w
zmiennej czasowej $RESPONSE.

Bezpośrednio po tym odbywa się

sprawdzenie istnienia wyzwalacza

ftp

w zwrocie zapisanym w zmiennej

$RESPONSE

. Wykorzystuje się w tym

celu polecenie grep z odpowiednim
wyzwalaczem dla pliku źródłowe-
go, a następnie zapisuje w zmiennej
czasowej

$MATCH

(wiersz 10).

Mózg programu pmap sprawdza

teraz, czy zmienna $MATCH posia-
da treść (wiersze 11 do 15). Jeśli
kontrola grep przebiegła negatyw-
nie, w zmiennej nie zostało nic zapi-
sane. W przeciwnym razie zmienna
zawiera ustalone wiersze. W zależ-
ności od tego, czy znaleziono zgod-
ność, zwracany jest określony sta-
tus (wiersze 12 do 14). Wynik uda-
ny (wiersze 01 do 04) lub nieuda-
ny (wiersze 06 do 09) przebieg tego
niewielkiego skryptu wygląda pod Li-
nuksem w następujący sposób:

01 mruef@debian:~$ ./pmap.sh ftp.
computec.ch 21
02 pmap v1.0
03 Starting protocol mapping …
04 Testing for trigger
ftp … Found!
05
06 mruef@debian:~$ ./
pmap.sh smtp.computec.ch 25
07 pmap v1.0
08 Starting protocol mapping …
09 Testing for trigger
ftp … Not found.

Jak już wspominaliśmy zastosowanie
pmap zostało maksymalnie uproszczo-
ne w celu łatwiejszego przedstawie-
nia zasady implementacji. W przypad-
ku profesjonalnej aplikacji należałoby

przeprowadzić liczne sprawdzenia błę-
dów, dodatkowe testy oraz obszerniej-
sze raportowanie. Jednak jeśli chodzi o
zasadę działania, wykorzystano przed-
stawione uprzednio możliwości.

Algorytm

niezawodności

Podstawową zasadą metody Appli-
cation Mapping jest szybkie zrozu-
mienie i prosta implementacja w kilku
wierszach. Według mnie aplikację ty-
pu amap można wyraźnie udoskona-
lić poprzez implementację dodatko-
wych mechanizmów oceny. Ta zróż-
nicowana analiza charakterystyk po-
łączenia lub serwisu musi zostać po-
nownie przetworzona przy pomocy
algorytmu, który w pełni obejmie zna-
czenie logiczne oraz zależności. Ta-
bela 5 przedstawia możliwości użycia
poszczególnych technik, ich znacze-
nie logiczne w obrębie analizy oraz
dotyczące ich części analizy.

Poniżej przedstawimy hipote-

tyczny przebieg takiego algorytmu
krok po kroku, zgodnie z jego działa-
niem w praktycznej implementacji:

• jeśli port docelowy określony przez

IANA oferuje usługą R, wartość R
jest zapisywana ze znaczeniem lo-
gicznym 5 %. A = { R, 5 },

O autorze

Marc Ruef pracuje jako Security Consultant w szwajcarskiej firmie scip AG, w której
jest szefem działu Security Auditing i Penetration Testing. W październiku 2002 uka-
zała się nakładem wydawnictwa Data Becker jego druga książka Hacking Intern. Poza
wieloma publikacjami dotyczącymi teorii informatyki i bezpieczeństwa IT wspiera róż-
ne projekty w tych dziedzinach. Od 1997 opiekuje się stroną internetową computec.ch,
będącą największym archiwum niemieckojęzycznych publikacji dotyczących bezpie-
czeństwa informacji. Poza tym jest programistą Attack Tool Kit (ATK), open source'o-
wego Exploiting Framework'a, będącego uzupełnieniem rozwiązań typu Nessus, słu-
żącego do ułatwiania testów penetracyjnych.
Kontak z autorem:
[e-mail]
http://www.computec.ch/

W Internecie

• computec.ch, http://www.computec.ch, niemieckojęzyczne archiwum z bezpłatny-

mi publikacjami dotyczącymi bezpieczeństwa IT,

• THC amap, http://thc.org/thc-amap/, popularna implementacja narzędzia do Ap-

plication Mapping,

• nmap, http://www.insecure.org/nmap/, popularne narzędzia do skanowania i

oceny.

Application Mapping

hakin9 Nr 6/2006

www.hakin9.org

53

• jeśli dla tego połączenia jest wy-

korzystywany dominujący proto-
kół transportu, wartość ta jest za-
pisywana ze znaczeniem logicz-
nym 5 %. B = { R, 5 },

• powitanie przy pomocy bane-

ra po ustanowieniu połączenia,
wartość jest zapisywana ze zna-
czeniem 5 %. C = { R, 5 },

• timeout jest zapisywany ze zna-

czeniem 5 %. R = { R, 5 },

• automatyczna odpowiedź po

ustanowieniu połączenia jest
sprawdzana pod kątem ewentu-
alnych wzorców, a wyniki są za-
pisywane ze znaczeniem 35 %.
E = { R, 35 },

• odpowiedzi sprowokowane przez

bodźce są również sprawdza-
ne pod kątem wzorców i zapisy-
wane ze znaczeniem 45 %. F =
{ R, 45 },

• poprzez ustalenie wspomnianych

usług o największym znaczeniu
można uzyskać najbardziej praw-
dopodobne wyniki. Z = { A, B, C,
D, E, F }.

Do zastosowania algorytmu powinno
się wykorzystywać bazę danych, któ-
rą można jednak zrealizować jedynie
wirtualnie w formie tablic lub jako
płaską bazę danych plików. Dzięki
prostym działaniom arytmetycznym
(dodawanie i dzielenie) możemy obli-
czyć średnie i prawdopodobieństwa,
ze znaczeniem logicznym.

Środki zaradcze

Na koniec pojawia się pytanie, jak od-
powiedzialny administrator może się
bronić przed automatycznymi lub ręcz-
nymi ocenami Application Mapping (np.
przy pomocy programu amap). Zasad-
niczo można zastosować te same tech-
niki, które wykorzystywane są od lat
przez wyrafinowanych twórców wiru-
sów lub wyspecjalizowanych testerów
penetracyjnych: poprzez zmianę za-
chowania wprowadza się w błąd ana-
lizy autentyczności uruchamiane przy
użyciu baz danych wzorców. Twórcy
wirusów walczą z rozwiązaniami an-
tywirusowymi, a testerzy z systemami
Intrusion Detection. Naszym przeciwni-
kiem jest w tym przypadku proces oce-
ny Application Mapping.

Widzieliśmy wprawdzie, że za-

stosowanie efektywnych i wyczerpu-
jących wyrażeń regularnych jest du-
żą sztuką. Dlatego możemy w nie-
których przypadkach zapobiec pro-
cesowi Pattern-Matching poprzez
zwykłe dopasowanie zachowania
lub danych wyjściowych. Niestety
również my podlegamy zasadom,
które zapobiegają dostosowywa-
niu protokołów lub ich wytwarzaniu.
Podobnie twórcy wirusów nie mogą
według własnych potrzeb zamieniać
wykorzystywanego przez rozwiąza-
nia antywirusowe bajtu X na inny. Te-
go rodzaju zabieg ma z reguły nieod-
powiedni wpływ na podstawowe za-
chowania samego produktu, co rów-
nież nie leży w interesie autora.

Jeśli przyjrzymy się bazie da-

nych wzorców programu amap, mo-
żemy stwierdzić, że wiele kontro-
li polega na wyszukiwaniu nazwy
protokołu w odpowiedzi. Np. obec-
ność ciągu znaków SMTP wskazu-
je na wykorzystanie protokołu Sim-
ple Mail Transfer Protocol. Podobnie
jest w przypadku FTP, HTTP i wielu
innych protokołów. Administrator mu-
si się więc postarać o nie publikowa-
nie tego rodzaju informacji. Przede
wszystkim należy dostosować apli-
kacje wykorzystujące banery powi-
talne w taki sposób, aby nie wymie-
niały własnych funkcji. W takiej sy-
tuacji atakujący może sprowokować
zdradziecką reakcję jedynie przy
pomocy odpowiednich bodźców. W
przypadku rozwiązań automatycz-
nych typu amap będzie to wymaga-
ło wielu testów. Tylko w wersji 4.8
programu amap z 349 wzorców od-
padłoby ok. 78 skutecznych warian-
tów dostępu, między innymi niektó-
re bardzo znane zastosowania typu
FTP lub SMTP.

Inną możliwością jest odłączenie

chronionej usługi przy pomocy Appli-
cation Gateway z dedykowanym Pro-
xy [Ruef et al. 2002, Ruef 2004, 2006].
W ten sposób nie możemy wprawdzie
bezpośrednio zapobiec pomyślnemu
sprawdzeniu oferowanego protokołu
aplikacji, jednak w większości przy-
padków możemy znacznie utrudnić
dalsze testowanie poszczególnych im-
plementacji (np. IIS lub Apache).

Podsumowanie

Metoda Application Mapping umoż-
liwia określenie używanego proto-
kołu na podstawie zachowania usłu-
gi udostępnianej na otwartym por-
cie. Dzięki zróżnicowanym metodom
można rozróżnić poszczególne apli-
kacje oraz częściowo ich charakte-
rystyczne implementacje. Istotną ro-
lę odgrywa przy tVym metoda Pat-
tern-Matching w obrębie odpowiedzi
sprawdzanej usługi.

Application Mapping jest wpraw-

dzie klasyczną dyscypliną bezpie-
czeństwa komputerowego, jednak
w literaturze poświęcano jej dotąd
niewiele uwagi. Praktycznie nigdy
nie uznano właściwego kroku roz-
poznawania protokołu za wyspecja-
lizowany proces. Dopiero dzięki pro-
gramowi amap – pierwszej popular-
nej implementacji zautomatyzowa-
nego rozwiązania - metoda Applica-
tion Mapping uzyskała stałe miejsce
w obrębie sieciowego audytu bezpie-
czeństwa.

W artykule przedstawiono pod-

stawowe zasady funkcjonowania
programu amap, dzięki którym mo-
gliśmy przejść do stworzenia po-
dobnego rozwiązania. Rozwią-
zanie to zostało uproszczone, co
umożliwiło przedstawienie zasady
działania tego rodzaju implementa-
cji. Poza tym omówiliśmy niektóre
możliwości zaimplementowane w
naszym rozwiązaniu oraz progra-
mie amap umożliwiające poprawę
skuteczności wyników. Dzięki po-
łączeniu dodatkowych technik (np.
analiza danych portów zalecanych
przez IANA lub zachowanie time-
out) można uzyskać dość jedno-
znaczne wyniki.

Na koniec przedstawiliśmy

środki bezpieczeństwa, jakie mo-
że podjąć odpowiedzialny admini-
strator w celu utrudnienia automa-
tycznego lub ręcznego procesu Ap-
plication Mapping. Poprzez zmianę
zachowania oferowanej usługi mo-
żemy zmylić przede wszystkim do-
stępy automatyczne, np. program
amap. Proces Application Mapping
stanie się czasochłonnym i żmud-
nym wykonywanym ręcznie zada-
niem. l