2010 05 Metasploit w praktyce cz III

HAKIN9

ATAK

5/2010

dwóch poprzednich artykułach
na temat praktycznej pracy w
środowisku Metasploit Framework

(Metasploit w praktyce, hakin9 3/2010
oraz Metasploit w praktyce cz. II, hakin9
4/2010) poznaliśmy podstawowe możliwości
tego cenionego frameworku w zakresie
przeprowadzania testów penetracyjnych z
wykorzystaniem gotowych modułów.

Oprócz kilku praktycznych przykładowych

testów penetracyjnych z wykorzystaniem
gotowych modułów, poznaliśmy także
podstawowe sposoby przetwarzania
oraz budowania od podstaw własnych
modułów pomocniczych z wykorzystaniem
klas oraz metod wchodzących w skład
całego środowiska. Wiemy już też,
że Metasploit wspiera zarządzanie
informacjami gromadzonymi w trakcie testu
penetracyjnego, pozwalając na utworzenie
prostej bazy danych zawierającej zbierane
na bieżąco informacje o odnalezionych
systemach informatycznych oraz ich
ewentualnych podatnościach na ataki
testowe.

Przy okazji poznaliśmy również

najważniejsze informacje na temat
zyskującego coraz większą popularność,
ofensywnego podejścia (ang. Offensive
Security) do tematu bezpieczeństwa
informatycznego. Przypomnijmy raz
jeszcze, że bezpieczeństwo ofensywne

WOJCIECH SMOL

Z ARTYKUŁU

DOWIESZ SIĘ

na czym polegają najbardziej

zaawansowane testy

penetracyjne,

jakie praktyczne możliwości

oferuje Metasploit Framework

w zakresie tworzenia własnych

exploitów,

w jaki sposób komputerowi

włamywacze oraz eksperci

ds. bezpieczeństwa odkrywają

nieznane wcześniej luki

(ang. Zero Day) w systemach

informatycznych.

CO POWINIENEŚ

WIEDZIEĆ

znać podstawy programowej

inżynierii wstecznej,

znać w stopniu co najmniej

podstawowym język

programowania Ruby

znać podstawowe możliwości,

funkcje oraz moduły

środowiska Metasploit

Framework.

opiera się przede wszystkim na
praktycznym sprawdzaniu bieżącego
stanu bezpieczeństwa systemu
teleinformatycznego. Praktycznym do tego
stopnia, że wykorzystuje w swych testach
narzędzia stosowane przez... komputerowych
włamywaczy. Najciekawszą część takiego
przedsięwzięcia będą więc stanowić testy
penetracyjne.

Same testy penetracyjne stanowią

metodę oceny bezpieczeństwa systemu
informatycznego poprzez symulowanie
prawdziwych ataków mogących pochodzić
od potencjalnych włamywaczy. Tester (zwany
często etycznym hakerem lub pentesterem),
korzystając z prawdziwych narzędzi
umożliwiających wykonanie udanego
włamania, próbuje przełamać zabezpieczenia
testowanego systemu. Dopiero tego
rodzaju testy są w stanie odpowiedzieć na
pytanie, czy dany system informatyczny jest
rzeczywiście odporny na znane obecnie
rodzaje ataków. Przykłady tego rodzaju
działań, polegających na wykonywaniu
testowych włamań do własnych systemów
(lub cudzych, za pełną zgodą uprawnionych
administratorów oraz właścicieli) poznaliśmy
właśnie w poprzednich opracowaniach.
Za każdym razem korzystaliśmy jednak z
gotowych, udostępnionych już w ramach
Metasploit exploitów. Natomiast najbardziej
zaawansowaną formę testu penetracyjnego

Stopień trudności

Metasploit

w praktyce

cz. III

Artykuł przedstawia krok po kroku wszystko to, co każdy

zainteresowany bezpieczeństwem IT chciał zawsze wiedzieć

o zaawansowanych testach penetracyjnych oraz metodach

tworzenia własnych exploitów dla Metasploit Framework, ale

bał się własnoręcznie sprawdzić...

HAKIN9

METASPLOIT W PRAKTYCE CZ. III

5/2010

stanowi... utworzenie od podstaw
własnego exploitu, zdolnego do
przejęcie kontroli nad określonymi
systemami informatycznymi. Właśnie z
tego typu zadaniem utworzenia exploitu
Zero Day, który następnie będzie mógł
być włączony do środowiska Metasploit
Framework spróbujemy się dziś
zmierzyć. Tym samym poznamy nie
tylko możliwości środowiska Metasploit
w zakresie tworzenia nowych exploitów,
ale również niezwykle interesującą
drogę, jaką musi przebyć cracker lub
specjalista ds. bezpieczeństwa IT
od momentu odkrycia nowej luki, do
utworzenia modułu zdolnego do jej
wykorzystania w praktyce.

Szukanie dziury w całym

Pierwszy etap tworzenia nowego
exploitu stanowi odnalezienie nowej,
nieznanej jeszcze powszechnie
luki. Jako że, odnajdowanie błędów
bezpieczeństwa w aplikacjach wykracza
poza temat artykułu, skupimy się na
luce, której opis jest już dostępny
w formie poradnika zabezpieczeń
udostępnionego przez producenta.

Jako przykład luki, dla której

utworzymy odpowiedni exploit,
rozważymy błąd obecny w
oprogramowaniu Timbuktu Pro. Z
poradnika bezpieczeństwa dostępnego
pod adresem http://labs.idefense.com/
intelligence/vulnerabilities/
display.php?id=809, dowiadujemy się
m.in. że:

błąd pozwala na przepełnienie

bufora stosu,

• błąd występuje w Timbuktu Pro w

wersji 8.6.5,

• błąd pozwala na uruchomienie

dowolnego kodu z uprawnieniami
systemowymi,

• wyzwolenie błędu możliwe

jest poprzez potok o nazwie
PlughNTCommand,

• potok nazwany PlughNTCommand

akceptuje połączenia typu NULL.

Wszystkie powyższe informacje są
niezwykle ważne i będą nam niezbędne
na etapie szczegółowej analizy luki
za pomocą inżynierii wstecznej (ang.

reverse engineering) oraz kodowania
samego exploitu.

Wiedząc już z grubsza na czym

polega luka w Timbuktu Pro, kolejny
krok stanowi dokładne zlokalizowanie
podatności w samej aplikacji. Zanim
jednak przystąpimy do analizy
wstecznej, musimy zgromadzić kilka
niezbędnych programów, najlepiej w
obrębie testowej maszyny wirtualnej.
Przede wszystkim potrzebujemy więc
program Timbuktu Pro8.6.5, który
dostępny jest pod następującym

adresem: ftp://ftp-xo.netopia.com/
evaluation/timbuktu/win/865/
TB2Win865eval.zip. Po zainstalowaniu
programu z domyślnymi opcjami za
pomocą instalatora TimbuktuPro.msi,
program powinien zasygnalizować swe
działanie za pomocą własnej ikony w
zasobniku systemowym Windows.

Po zainstalowaniu podatnego

na atak oprogramowania, warto na
początek zweryfikować informacje
podane w poradniku bezpieczeństwa.
Na początek potwierdzimy istnienie

Rysunek 1.

Poszukiwany przez nas potok nazwany PlughNTCommand

Rysunek 2.

Miejsce powstania potoku nazwanego PlughNTCommand

ATAK

HAKIN9 5/2010

METASPLOIT W PRAKTYCE CZ. III

HAKIN9

5/2010

potoku nazwanego PlughNTCommand.
W tym celu skorzystamy z narzędzia
PipeList dostępnego w ramach
darmowego pakietu Sysinternals
Utilities. Jak możemy się przekonać po
uruchomieniu programu pipelist.exe,
potok PlughNTCommand jest obecny
w systemie, w którym działa proces
serwera Timbuktu Pro. Jest to
niezbędne, w celu zlokalizowania kodu
zawierającego poszukiwaną przez nas
lukę. W tym celu należy zakończyć (np.
za pomocą Menedżera zadań) oraz
ponownie uruchomić (poprzez ponowne
uruchomienie programu) wszystkie
procesy związane z Timbuktu:

• tb2pro.exe,
• tb2launch.exe,
• Tnotify.exe,
• TimbuktuRemoteConsole.exe.

Cały proces restartowania procesów
będziemy natomiast śledzić za
pomocą programu Sysinternals
Process Monitor. W wyniku takiej analizy
możemy stwierdzić, że za utworzenie
interesującego nas potoku odpowiada
proces tb2pro.exe. Skoro więc wiemy
już, że będziemy poszukiwać kodu
odpowiedzialnego za utworzenie potoku
nazwanego, poszukajmy wskazówek
mogących nam pomóc w tym zadaniu.
W tym celu przydatne okaże się
odwiedzenie witryny Microsoft Developer
Network, na której to znajdziemy
listę wszystkich funkcji Windows
API związanych z potokami (http:
//msdn.microsoft.com/en-us/library/
aa365781(VS.85).aspx). Dzięki temu
wiemy już, że będziemy poszukiwać
funkcji CreateNamedPipe(). Wiemy już
więc, że w poszukiwaniu tej specyficznej

funkcji będziemy musieli poddać
deasemblacji tb2pro.exe. Nie możemy
jednak zapomnieć o ładowanych
przez niego modułach, z których
najważniejsze to:

C:\Program Files\Timbuktu Pro\chat.dll
C:\Program Files\Timbuktu Pro\dial.dll
C:\Program Files\Timbuktu Pro\
Exchange.dll
C:\Program Files\Timbuktu Pro\invite.dll
C:\Program Files\Timbuktu Pro\
MUNGER.dll
C:\Program Files\Timbuktu Pro\note.dll
C:\Program Files\Timbuktu Pro\notify.dll
C:\Program Files\Timbuktu Pro\
PlughNT.dll
C:\Program Files\Timbuktu Pro\Salt.dll
C:\Program Files\Timbuktu Pro\
tb2cob.dll
C:\Program Files\Timbuktu Pro\tb2ftp.dll
C:\Program Files\Timbuktu Pro\
tb2phone.dll
C:\Program Files\Timbuktu Pro\
tb2plugh.dll
C:\Program Files\Timbuktu Pro\
Tb2Skype.dll
C:\Program Files\Timbuktu Pro\
TB2TOOLS.dll
C:\Program Files\Timbuktu Pro\
TMARINA.dll
C:\Program Files\Timbuktu Pro\TNAPI.dll
C:\Program Files\Timbuktu Pro\
tserial.dll
C:\Program Files\Timbuktu Pro\ttcp.dll

Do deasemblacji użyjemy programu IDA
Pro 4.9 Freeware Version, dostępnego
pod następującym adresem: http:
//www.hex-rays.com/idapro/
idadownfreeware.htm.

Poszukiwanie wywołania funkcji

CreateNamedPipe() rozpoczniemy od
załadowania do IDA Pro programu
tb2pro.exe i analizy importów (okno
Imports). Jak można się niestety
przekonać, program ten nie importuje
poszukiwanej przez nas funkcji. W
takim razie pozostaje nam analiza
uprzednio wspomnianych modułów.
Spośród wymienionych plików DLL
uwagę zwraca moduł C:\Program
Files\Timbuktu Pro\PlughNT.dll, warto
więc rozpocząć poszukiwania od
tego właśnie pliku. Poddanie tegoż

Listing 1.

Fragment kodu podatny na przepełnienie bufora po deasemblacji

text

602

FA8AD

loc_602FA8AD

;

CODE

XREF

sub_602FA160

222

text

602

FA8AD

;

DATA

XREF

text

602

FB669

text

602

FA8AD

cmp

hToken

text

602

FA8B4

short

loc_602FA8C3

text

602

FA8B6

mov

edx

hToken

text

602

FA8BC

push

edx

;

hToken

text

602

FA8BD

call

ImpersonateLoggedOnUser

text

602

FA8C3

text

602

FA8C3

loc_602FA8C3

;

CODE

XREF

sub_602FA160

754

text

602

FA8C3

lea

eax

[

ebp

var_2118

]

text

602

FA8C9

push

eax

text

602

FA8CA

lea

ecx

[

ebp

var_2114

]

text

602

FA8D0

push

ecx

text

602

FA8D1

lea

edx

[

ebp

var_20B0

]

text

602

FA8D7

push

edx

text

602

FA8D8

push

offset

aHdSHd_0

;

"%hd %s %hd"

text

602

FA8DD

lea

eax

[

ebp

var_1034

]

text

602

FA8E3

push

eax

;

char

text

602

FA8E4

call

_sscanf

text

602

FA8E9

add

esp

, 14

text

602

FA8EC

mov

ecx

text

602

FA8F1

test

ecx

text

602

FA8F3

short

loc_602FA8F7

text

602

FA8F5

jmp

short

loc_602FA913

Rysunek 3.

Funkcja wywołująca utworzenie potoku nazwanego PlughNTCommand

ATAK

HAKIN9 5/2010

METASPLOIT W PRAKTYCE CZ. III

HAKIN9

5/2010

pliku analizie w programie IDS
Pra da nam wreszcie oczekiwane
rezultaty. Za pomocą okna Imports
odnajdziemy bowiem wystąpienie
funkcji CreateNamedPipe(). Po
analizie zewnętrznych referencji XREF,
dojdziemy do wniosku, że funcka
CreateNamedPipe() wykorzystywana
jest przez dwie funkcje. Natomiast
poszukiwaną przez nas funkcję
rozpoznamy po argumencie lpName
o wartości \\.\pipe\PlughNTCommand,
przekazywanym do funkcji
CreateNamedPipe(). Nie pozostaje
nam już w takim razie nic innego, jak
przeprowadzenie analizy odnalezionej
funkcji, w celu dokładnego przyjrzenia
się luce. Naszą uwagę powinno zwrócić
wykorzystanie w felernym fragmencie

kodu funkcji sscanf() oraz strcpy(),
których nieostrożne użycie często
prowadzi właśnie do powstania błędów
przepełnienie bufora.

Rzeczywiście, po dokładnej analizie

kodu, dojdziemy do wniosku, że
problem leży w jednej z funkcji sscanf().
Problem sprawia bowiem kod na
Listingu 1.

Kod ten przekazuje dane pobrane z

wejścia bezpośrednio do funkcji sscanf.
W ten sposób pobrane dane wejściowe
są wczytywane do dwóch zmiennych
typu integer oraz string. Właśnie
beztroskie pobranie danych z wejścia
do zmiennej typu string (2. w kolejności)
pozwala na przepełnienie bufora.

W pseudokodzie wygląda to tak jak

na Listingu 2.

Skoro już

odnaleźliśmy podatny na
atak kod oraz wiemy już
na czym polegał błąd
programisty, kolejnym
etapem będzie teraz
utworzenie kodu Proof
of Concept. By mieć
całkowitą pewność,
że błąd obecny w
programie Timbuktu
można rzeczywiście
wykorzystać w praktyce,
stworzymy program
zdolny do spowodowania
przepełnienie bufora.
Będzie do jednocześnie
pierwszy etap na
drodze do utworzenia
właściwego exploitu.

PoC

Zadaniem naszego prostego kodu
PoC (ang. Proof of Concept) będzie
nawiązanie połączenia z potokiem
nazwanym PlughNTCommand
oraz przesłanie do niego pewnych
określonych danych. Stojąc przed tak
postawionym zadaniem, okazuje się,
że środowisko Metasploit Framework
świetnie nadaje się do tego celu.
Zadanie na pierwszy rzut oka wydaje
się niebanalne, w rzeczywistości jednak
dzięki temu, że możemy skorzystać ze
wszystkich klas oraz metod obecnych
już w ramach środowiska Metasploit
Framework, rozwiązanie okazuje się
zaskakująco proste. Otóż nasz kod
PoC można utworzyć za pomocą
poniższej, stosunkowo prostej definicji,
przedstawionej na Rysunku 4.

Jak widać skorzystaliśmy z

bogactwa otwartego kodu dostępnego
w ramach Metasploit Framework i
wykorzystaliśmy w naszym programie
klasę Msf::Exploit::Remote::SMB. Dzięki
temu, do swojej dyspozycji otrzymaliśmy
gotowego klienta protokołu SMB.
Natomiast działanie naszego kodu
PoC sprowadza się przed wszystkim
do nawiązania połączenia SMB (typu
NULL) z serwerem (określonym za
pomocą parametru RHOST) oraz
wykonania żądania dostępu do potoku
nazwanego PlughNTCommand. Metoda
exploit stanowi zalążek właściwego
exploitu, natomiast na chwilę obecną jej
działanie sprowadza się do przesłania
do odpowiedniego strumienia za
pomocą protokołu SMB uprzednio

Listing 2.

Pseudokod obrazujący przyczynę problemu

int

cmd

someint

char

clientinput

[

]

CreateNamedPipe

(

“\\\\.\\

pipe

PlughNTCommand

”, …

)

ConnectNamedPipe

()

clientinput

ReadFile

()

sscanf

(

cmd

, “

”,

clientinput

)

switch

(

cmd

)

case

...

case

…

case

…

case

sscanf

(

Src

, “

”,

cmd

clientinput

someint

)

Rysunek 4.

Kod Poc

HAKIN9 5/2010

HAKIN9

5/2010

ATAK

przygotowanej zawartości bufora. W ten
oto sposób, specjalnie spreparowana
zawartość bufora pozwala nam
na wyzwolenie błędu obecnego w
programie Timbuktu.

Chcąc przetestować skuteczność

naszego programu, wystarczy już tylko
zapisać go (w systemie Linux BackTrack
4 Final) jako poc.rb w katalogu /pentest/
exploits/framework3/modules/exploits/
windows/smb/.i uruchomić z poziomu
interfejsu msfconsole. Nasz kod
wywołuje błąd w docelowym programie
Access violation, co ostatecznie

dowodzi praktycznej możliwości
wykorzystania luki.

Podsumowując, nawet w przypadku

wymogu utworzenia całkowicie nowego
modułu, środowisko Metasploit
Framework okaże się zaskakująco
pomocne dzięki niezwykle prostym
metodom wykorzystania istniejącego już
w jego ramach kodu.

Exploit

Dysponując już działającym kodem
PoC, który w sposób praktyczny
dowodzi możliwości wykorzystania luki

w oprogramowaniu Timbuktu, pozostaje
nam już tylko utworzenie właściwego
exploitu.

Najtrudniejszym zadaniem, z jakim

musimy się zmierzyć w trakcie tworzenia
exploitu jest przejęcie kontroli nad
błędem w aplikacji oraz wypracowanie
sposobu na odnalezienie w pamięci
procesu odpowiedniego miejsca na
umiejscowienie oraz wykonanie payloadu.
Spójrzmy więc na instrukcję, która
spowodowała błąd access violation
(Rysunek 5) oraz na zawartość rejestrów
w momencie jego wystąpienia:

• EAX 98474B97
• ECX FFFFFFFF
• EDX 00000006
• EBX 003F3560
• ESP 00C8D958
• EBP 00C8D95C
• ESI 7C90D95C ntdll.7C90D95C
• EDI 0006EFA4
• EIP 602F1CA0 PlughNT.602F1CA0

Ponieważ przepełniliśmy bufor stosu,
miejsce, w którym się znajdujemy,
nie jest dla nas w ogóle użyteczne.
Do naszych celów potrzebny nam
jest natomiast prawidłowy adres w
statycznym obszarze z prawem zapisu.
Do tego celu dobrze nada się adres
0x7C97B0C0, który to związany jest z
plikiem ntdll.dll. W celu dostania się do
naszego zamierzonego adresu, musimy
ustalić, który wskaźnik nadpisujemy, tak
by ostatecznie nadać mu oczekiwaną
przez nas wartość za pomocą wartości
przesyłanej do potoku nazwanego.

Analizując dalej docelowy program,

możemy stwierdzić, że ze względu na
obecność instrukcji call dword ptr [edx+4],
dogodnym miejscem na umiejscowienie
własnego wykonywalnego kodu jest
obszar w pamięci, wskazywany w
momencie wystąpienia błędu, właśnie
przez wskaźnik EDX. Natomiast w celu
poznania adresów obecnych na stosie
dokonamy swego rodzaju zdalnego
zrzutu pamięci docelowego systemu.
W tym celu skorzystamy z obecnej
w programie funkcji WriteFile(), która
jest odpowiedzialna za przesyłanie
odpowiedzi do klienta. Manipulując
liczbą przesyłanych bajtów, jesteśmy

Rysunek 5.

Linia kodu powodująca błąd Access violation

Rysunek 6.

Nasz exploit w akcji

HAKIN9 5/2010

HAKIN9

5/2010

właśnie w stanie pobrać zrzut pamięci
z docelowego systemu. Biorąc pod
uwagę powyższe założenia, kod naszego
exploitu jest następujący: plik timbuktu_
plughntcommand_bof.rb.

Widzimy więc, że nasz exploit

nawiązuje połączenie SMB, a następnie
stara się pobrać 8184 bajtów danych ze
stosu i przesłać je z powrotem do klienta.
Na podstawie pobranej zawartości
pamięci oblicza następnie wartość
bufora tak, by zawarty również w jego
ramach payload trafił w odpowiednie
miejsce wykonania (EDX+4). Exploit (który
znajduje się już obecnie standardowo
w Metasploit Framework) w akcji
przedstawia Rysunek 6. Jak widać, exploit
działa poprawnie, a payload nawiązał
połączenie zwrotne z intruzem.

Podsumowanie

Poznaliśmy więc kolejne praktyczne
zastosowania środowiska Metasploit
Framework. Tym razem poznaliśmy
drogę, jaką trzeba przebyć od wykrycia
błędu w aplikacji do utworzenia
własnego exploitu.

Dzięki wykorzystaniu obecnego już

w środowisku Metasploit klienta SMB,
wymagany nakład pracy związany z
kodowaniem samego exploitu uległ
znacznemu ograniczeniu. Niemniej
jednak, jak się okazuje, najtrudniejsze
oraz najbardziej czasochłonne nie
jest wcale samo tworzenie kodu, lecz
wsteczna analiza aplikacji. Analiza ta ma
na celu dokładnie zrozumienie natury
błędu, co z kolei umożliwia opracowanie
skutecznej oraz niezawodnej metody jego

kontrolowania i ostatecznie wykorzystania.
Omówiony przykład jasno pokazuje,
że utworzenie wysokiej jakości exploitu
jest zadaniem niezwykle trudnym i
wymagającym, warto więc doceniać
pracę włożoną przez specjalistów
w rozwój darmowych środowisk do
przeprowadzania testów penetracyjnych.

Zachęcam więc ponownie wszystkich

zainteresowanych bezpieczeństwem
informatycznym do praktycznego
zapoznania się z testami penetracyjnymi
z wykorzystaniem środowiska
Metasploit Framework, ale również
spróbowania własnych sił w zakresie
implementowania własnych exploitów.
Nie ma bowiem skuteczniejszego
sposobu na poznanie prawdziwego
warsztatu hakerów oraz ekspertów ds.
bezpieczeństwa IT, niż własnoręczne
zmierzenie się z tym wymagającym
zagadnieniem. Tworzenie własnych
modułów będzie również świetną okazją
do zapoznania się (w sposób legalny) z
warsztatem komputerowych włamywaczy,
niekorzystających z dostępnych w
Internecie gotowych rozwiązań. Wszystko
to w konsekwencji pozwoli nam na lepsze
zabezpieczenia własnej infrastruktury
oraz lepsze zrozumienie czyhających na
nią zagrożeń!

W Sieci

• http://hcsl.pl/ – Hard Core Security Lab,
• http://www.metasploit.com/ – The Metasploit Project,
• http://www.offensive-security.com/metasploit-unleashed/ – Metasploit Framework: kurs

online,

• http://www.metasploit.com/redmine/attachments/download/95 – Advisory to Exploit

Using Metasploit,

• http://www.hcsl.pl/2010/01/ukaza-sie-dugo-oczekiwany-linuks.html – ukazał się długo

oczekiwany Linux BackTrack 4 Final!,

• http://www.backtrack-linux.org/ – nowa strona domowa projektu Linux BackTrack,
• http://technet.microsoft.com/en-us/sysinternals/default.aspx – SysInternals,
• Hex-Rays IDA Pro http://www.hex-rays.com/,
• http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=809 – Timbuktu Pro

PlughNTCommand Stack Based Buffer Overflow Vulnerability,

• http://msdn.microsoft.com/en-us/library/aa365781(VS.85).aspx – MSDN Pipe Functions.

Wojciech Smol

Autor jest absolwentem wydziału Automatyki, Elektroniki

i Informatyki Politechniki Śląskiej w Gliwicach. Ukończył

studia na kierunku informatyka, o specjalności Bazy

danych, sieci i systemy komputerowe. Pracuje jako

administrator sieci i systemów komputerowych

oraz specjalista ds. bezpieczeństwa IT. Prowadzi

serwis HARD CORE SECURITY LAB dostępny pod

adresem http://www.hcsl.pl/. Kontakt z autorem:

wojciech.smol@gmail.com lub wojciech.smol@mz.pl.

Wyszukiwarka

Podobne podstrony:

więcej podobnych podstron