Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Firmowy serwis internetowy – rozwiązania opensource kontra dedykowane – w kontekście bezpieczeństwa (cz. 2.)
Od redakcji: czytasz kontynuację pierwszej części tekstu.
Podejście pierwsze – gotowe rozwiązanie
Pierwszym krokiem na drodze do bezpiecznego, firmowego serwisu WWW to wybór pomiędzy już istniejącym na rynku, sprawdzonym rozwiązaniem, a zleceniem zbudowania go od podstaw. W sieci roi się od darmowych systemów CMS (polecam stronę OPENSOURCE CMS , na której znajdują się informacje na temat kilkuset najpopularniejszych), gotowych systemów CRM czy sklepów internetowych. Często są to rozwiązania typu opensource – czyli mające tak zwany otwarty kod źródłowy. Oznacza to, że każdy może pobrać kod takiego systemu, dowolnie go zmodyfikować i dopasować do swoich potrzeb, a następnie gotowy serwis umieścić w sieci.
1. Dostępność, popularność, wsparcie
To bardzo wygodne rozwiązanie. Popularność części z nich wiąże się też z ogromną rzeszą użytkowników, niezależnych programistów oferujących gotowe rozszerzenia (w przypadku np. systemu blogowego WordPress ich liczba szacowana jest na kilkadziesiąt tysięcy), setkami stron oferujących gotowe projekty graficzne layoutów (kompletnych, zawierających w sobie wszystkie elementy kompozycji definiujących wygląd ostateczny na ekranie komputera) oraz społecznościami służącymi pomocą i radą przy napotkaniu jakiegokolwiek problemu przy pracy z takim systemem.
Są jednak i wady. Powszechnie dostępny kod źródłowy aplikacji wykorzystywanej w milionach serwisów na całym świecie przyciąga uwagę cyberprzestępców. Mogą do woli taki kod analizować, szukając potencjalnych wektorów ataku (słabych punktów aplikacji, które wykorzystane w odpowiedni sposób pozwolą na nieuprawniony dostęp do danych). Paradoksalnie największa zaleta opensource staje się jej najsłabszym punktem.
Oczywiście, deweloperzy pracujący nad takim projektem, gdy ten zdobędzie już uznanie i stanie się popularny, także są informowani o potencjalnych lukach i zagrożeniach. Starają się je eliminować w kolejnych wydaniach swoich systemów, często propozycje poprawek przysyłają sami użytkownicy. Im więcej użytkowników, tym łatwiej jest wszelkie błędy wychwycić i poprawić.
Problem pojawia się w momencie, gdy bazowa funkcjonalność oferowana przez taki system nie wystarczy do naszych potrzeb i musimy posiłkować się rozszerzeniami.
W tym momencie pojawia się kolejna, bardzo istotna wada.
2. Zagrożenia – ciągle pod lupą
Rozszerzenia tworzone są przez różnej maści deweloperów, przywiązujących mniejsze bądź większe znaczenie do kwestii związanych z bezpieczeństwem. W rezultacie powstaje kod o bardzo zróżnicowanej jakości. W skrajnych przypadkach celowo publikowane są rozszerzenia zawierające złośliwe oprogramowanie, sporadycznie zdarzają się także próby umieszczania szkodliwego kodu bezpośrednio na serwerach zawierających gotowy do pobrania system.
Taka sytuacja miała np. miejsce w Polsce w 2012 roku i dotyczyła polskiej wersji systemu Joomla!. Weźmy pod lupę ten bardzo popularny system CMS i poszukajmy informacji na jego temat w serwisach monitorujących zagrożenia sieciowe
Istnieje wiele serwisów oraz list dyskusyjnych, które zajmują się zbieraniem informacji na temat podatności (luk) w rozwiązaniach nie tylko opensource, ale także tych płatnych (komercyjnych). Do najbardziej znanych i zawierających najwięcej informacji należą: Packet Storm Security , OSVDB (The Open Source Vulnerability Database), CVE (w powszechnie przyjętym standardzie zapisu informacji o podatnościach w oprogramowaniu, ale o CVE więcej za chwilę), Secunia oraz listy dyskusyjne serwisu Security Focus – w szczególności lista znana pod nazwą BugTraq (BugTraq). Oczywiście w sieci można znaleźć ich więcej, ale to od tych wymienionych z reguły rozpoczynają poszukiwanie informacji między innymi cyberprzestępcy mający „na oku” konkretną witrynę. Z drugiej strony ich popularność zapewnia dość duże prawdopodobieństwo, że informacja o nowej luce pojawi się w pierwszej kolejności właśnie w którymś z nich.
Wróćmy do systemu zarządzania treścią Joomla!. W witrynie Packet Storm Security możemy odszukać następujące informacje na temat podatności znalezionych w tym systemie:
Jak widzimy, w wersji 2.5.6 zdiagnozowano błąd znany jako XSS (Cross-site scripting):
Cross-site scripting (XSS) – sposób ataku na serwis WWW polegający na osadzeniu w treści atakowanej strony kodu (zazwyczaj JavaScript), który wyświetlony innym użytkownikom może doprowadzić do wykonania przez nich niepożądanych akcji. Skrypt umieszczony w zaatakowanej stronie może obejść niektóre mechanizmy kontroli dostępu do danych użytkownika.
za: Wikipedia
Na temat tego błędu można też poczytać na stronie OWASP XSS, natomiast bogaty zbiór przykładowych sposobów odnajdywania i wykorzystywania luki można znaleźć pod adresem XSS Filter Evasion Cheat Sheet . XSS jest bardzo często występującą podatnością, niestety lekceważoną z uwagi na pozornie małą szkodliwość. Jest to bardzo mylne podejście, bo we wprawnych palcach doświadczonego crackera może doprowadzić do poważnych konsekwencji.
Wróćmy do odnalezionej podatności. Gdy zajrzymy na stronę ze szczegółami, znajdziemy ogólne informacje o tym, przez kogo błąd został wykryty, krótki PoC (Proof of Concept – „naoczny” dowód wykorzystania luki) oraz linki referencyjne do innych stron z informacjami o błędzie. Z reguły jest także informacja dotycząca sposobu pozbycia się zagrożenia. W tym wypadku autor zaleca aktualizację do najnowszej wersji 2.5.7:
Po przejściu na stronę projektu Joomla! w notkach dotyczących wspomnianej najnowszej wersji możemy znaleźć wpis, jakie błędy związane z bezpieczeństwem zostały załatane:
Przeglądając wcześniejsze wpisy w serwisie Packet Storm Security na temat Joomla!, łatwo zaobserwować, że takich błędów programistom tego CMS-a zdarzało się wcześniej wiele. Z reguły były one wyłapywane i poprawiane w kolejnych wydaniach, jednak nie możemy mieć całkowitej pewności, że nie pojawią się kolejne.
W tym momencie wrócę na chwilę do terminu CVE (Mitre.org). Jest to ustandaryzowany sposób katalogowania informacji o odkrytych lukach i podatnościach w oprogramowaniu. Każdy zgłoszony do CVE błąd ma swój identyfikator (składa się on z bieżącego roku oraz kolejnego numeru, np. CVE-2012-1234) i pod tym identyfikatorem można znaleźć wszystkie informacje – datę zgłoszenia, opis techniczny, „Proof of Concept” (dowód na możliwość wykorzystania), linki do strony producenta lub autora, linki do informacji o luce w innych bazach i serwisach poświęconych bezpieczeństwu czy też informacje o sposobie załatania. Z przykładowymi informacjami w formacie CVE o luce XSS w systemie Joomla! można zapoznać się pod adresem CVE-2012-1612
Opisana sytuacja dobitnie ukazuje jedną z największych zalet opensource – gotowy system jest monitorowany, z reguły przez dużą społeczność, błędy są zgłaszane i poprawiane, a deweloperzy dbają, by poprawki pojawiały się w nowych wydaniach.
Pozostają dwie inne istotne kwestie:
- dodatki (wtyczki, pluginy, komponenty, moduły – nazewnictwo jest różne, ale generalnie chodzi o dodatkowe fragmenty kodu pisane w celu rozszerzenia funkcjonalności wersji bazowej) oraz
- 0-Day (zero-day) exploit – bardzo niebezpieczne zjawisko.
Przyjrzyjmy się im dokładniej.
Nieznany wróg?
1. Dodatki
Często zdarza się sytuacja, gdy oferowana funkcjonalność gotowego oprogramowania opensource jest dla nas niewystarczająca i musimy posiłkować się rozszerzeniami, spełniającymi określone przez nas wymagania lub wykonującymi określone czynności. Jak już wspomniałem, w przypadku najpopularniejszych rozwiązań opensource ich ilość jest liczona w dziesiątkach tysięcy. Sęk w tym, że tworzą je często amatorzy, pasjonaci i hobbyści nie bardzo obeznani z kwestiami zabezpieczeń.
Zainstalowanie (włączenie do naszego serwisu) takiego rozszerzenia to duże ryzyko, chyba, że wcześniej upewnimy się, że nic nam nie grozi.
Aby to zrobić, tym razem posłużymy się innym serwisem – OSVBD – Open Source Vulnerability Database (w wolnym tłumaczeniu: bazą podatności oprogramowania o otwartym kodzie źródłowym). Z prawej strony znajdziemy wyszukiwarkę, gdzie w polu 'General Search’ jako frazę podamy słowo 'joomla’.
Po chwili naszym oczom ukaże się niezbyt optymistycznie nastrajająca lista:
Po lewej stronie znajdziemy zestawienie informujące, ile, kiedy i jakiej kategorii podatności zostały zgłoszone. Łatwo policzyć, że na przestrzeni ostatnich czterech lat było to około tysiąca (!!!) różnego rodzaju błędów w dodatkowych komponentach oraz w samym systemie, zarówno bardzo niebezpiecznych, jak SQL Injection (wstrzykiwanie kodu SQL – OWASP SQL injection), wspomnianych już wcześniej XSS, czy też błędów związanych z systemem plików i błędną konfiguracją serwera WWW i interpretera PHP (Local File Inclusion – OWASP LFI, Remote File Inclusion – Wikipedia RFI).
SQL Injection (z ang., dosłownie zastrzyk SQL) – luka w zabezpieczeniach aplikacji internetowych polegająca na nieodpowiednim filtrowaniu lub niedostatecznym typowaniu i późniejszym wykonaniu danych przesyłanych w postaci zapytań SQL do bazy danych. Podatne są na niego systemy złożone z warstwy programistycznej (przykładowo skrypt w PHP, ASP, JSP itp.) dynamicznie generującej zapytania do bazy danych (MySQL, PostgreSQL itp.). Wynika on zwykle z braku doświadczenia lub wyobraźni programisty.
za: Wikipedia
Dla porównania przeprowadźmy podobne wyszukiwanie dla najpopularniejszej w tej chwili platformy blogowej – WordPress. Ogromna, nie przewidziana chyba nawet przez samych twórców, popularność tego systemu, zaowocowała wysypem wszelkiej maści wtyczek, a wyspecjalizowane w takiej działalności firmy budują serwisy o bardzo rozbudowanej funkcjonalności bazując właśnie na WP. Niestety, i w tym wypadku mamy podobnie „bogate” zestawienie, w którym znów królują wspomniane rozszerzenia (w nomenklaturze WordPress’a znane jako 'pluginy’):
Gdy rzucimy okiem na wykres przedstawiający liczbę zgłoszonych błędów w ostatnich latach, łatwo zauważymy trend wzrostowy. Pocieszającym może być jedynie fakt, że w stosunku do liczby powstających rozszerzeń do WordPressa nie jest to trend proporcjonalny, niemniej jednak nie ulega wątpliwości, że jest to coraz więcej zgłoszeń:
W wykorzystaniu podatności w takich wadliwych rozszerzeniach cyberprzestępcom pomagają gotowe narzędzia, przeszukujące katalog serwera WWW, w którym umieściliśmy naszą aplikację, pod kątem ich występowania. Jednym z nich jest WPScan przeznaczony do skanowania serwisów zbudowanych z wykorzystaniem WordPressa. Jego użycie w celu wykrycia zainstalowanych pluginów jest banalne:
ruby wpscan.rb --url www.example.com --enumerate p
W rezultacie otrzymujemy podaną na złotej tacy listę wtyczek ze wskazaniem, jakie błędy w nich występują
Należy zdać sobie sprawę z faktu, że podobne narzędzia dla większości najpopularniejszych systemów opensource (także dla równie popularnej Joomli) są ogólnie dostępne w Internecie, a część cyberprzestępców ma także w arsenale własnoręcznie napisane skrypty do przeprowadzania takich rekonesansów.
2. 0-Day exploits
Na koniec pozostawiłem najbardziej niebezpieczny rodzaj podatności: tzw. 0-Day exploits.
Exploity – to programy bądź skrypty, które wykorzystują błąd w oprogramowaniu (więcej na ten temat można przeczytać na stronie Wikipedia exploit oraz Wikipedia 0-Day exploit).
0-Day exploit umożliwia atakującemu wykorzystanie luki, którą odkrył on sam, bądź która jest już znana, ale jeszcze nie została zastosowana żadna łatka naprawiająca tę lukę.
Wróćmy na chwilę do przykładu poszukiwania podatności w serwisie Packet Storm Security i wyobraźmy sobie, co byłoby, gdyby błąd XSS w wersji 2.5.6 nie został wyeliminowany lub, co gorsze, ten błąd byłby znany jedynie wąskiemu gronu crackerów? Nic o tym nie wiedząc, z pełną nieświadomością czyhającego zagrożenia pobieramy i instalujemy wersję 2.5.6, zapełniamy bazę danych informacjami firmowymi, a dwa tygodnie później okazuje się, że ktoś dokonał udanego ataku na naszą witrynę i dane zostały wykradzione. Dwa dni po ataku znajdujemy informację, że w wersji 2.5.6 znaleziono poważny błąd, a developerzy Joomla! publikują wersję 2.5.7 ze stosowną poprawką. Niestety, dzięki 0-Day exploitowi dla nas jest już za późno…
Podsumowanie
Chciałbym zaznaczyć, że podane przeze mnie przykłady w żaden sposób nie przekreślają użycia gotowych systemów jako bazy dla serwisu internetowego przedsiębiorstwa. Wskazują jedynie, na co zwrócić uwagę oraz jakie niebezpieczeństwa mogą się z nimi wiązać. Nie musimy popadać w paranoję, bowiem nie istnieje na świecie w 100% bezbłędny kod.
Co więcej, deweloperzy Joomla!, WordPress, Drupal, Magento i innych równie popularnych otwartoźródłowych rozwiązań dawno już nauczyli się wyciągać właściwe wnioski z różnego rodzaju raportów i zgłoszeń, prowadzą własne bug-trackery (systemy zgłaszania błędów), kod tych systemów z wersji na wersję jest na bieżąco poprawiany i dostosowywany do nowych warunków, w jakich przychodzi mu działać. Z jednej strony, bezpośredni atak na witrynę zbudowaną z wykorzystaniem jednego z nich jest tak naprawdę w większości przypadków skazany na porażkę, gdyż znalezienie nowej luki wymaga dużego nakładu czasu i środków. Z drugiej strony, jeśli nasz serwis firmowy stanie się obiektem zaplanowanego, celowego ataku, a nie przypadkowego bądź zautomatyzowanego, może okazać się, że nawet regularne aktualizacje i solidne zabezpieczenia nie uchronią nas przed utratą danych.
Dużo zależy też od prawidłowo zainstalowanej i skonfigurowanej infrastruktury dla serwisu (serwer WWW, system bazodanowy) – ale o tym pokrótce w kolejnych częściach opracowania, gdy omówię dodatkowe zabezpieczenia, jakie możemy zastosować niezależnie od wybranego rozwiązania.
– Rafal “bl4de” Janicki [bloorq<at>gmail.com]
Kolejne dwie części opracowania – niebawem na sekuraku.
O autorze
Rafał 'bl4de’ Janicki: z komputerami i programowaniem związany od 1992 roku, gdy rodzice zakupili mu pierwszy 8-bitowy komputer. Samouk, programista aplikacji webowych, domorosły badacz zabezpieczeń serwisów internetowych. Gdy nie śpi – z reguły jego palce spoczywają na klawiaturze :)
Od 2007 roku zawodowo związany z programowaniem. W swojej karierze pracował m.in. w Wirtualnej Polsce, obecnie jako JavaScript developer w brytyjskiej firmie zajmującej się oprogramowaniem dla sektora finansowego.
W 2012 roku Autor tego cyklu artykułów zdobył 2. miejsce w konkursie zorganizowanym przez Securitum. Tekst opublikowany na licencji CC – uznanie autorstwa.
Fajny artykuł, czekam na kolejne części.
Rzeczowy, wart poczytania i przemyślenia, ale…
1. Autor przywołuje „polską wersję Joomla”, a przytacza argumentację dotyczącą po prostu Joomla. Owszem, istnieje coś takiego, jak „polska wersja Joomla”, tyle że to po prostu oficjalne wydanie z przykładowymi danymi w języku polskim, a nie jakaś inna niż oficjalna wersja.
2. Tysiące wykrytych luk w zabezpieczeniach (zwłaszcza w tysiącach rozszerzeń – w Joomla od wersji 1.0 do 3.5 opublikowano blisko 30 000 rozszerzeń) to, niestety,nie jest poważny argument. Odczytać z niego można, że skoro aż tyle było luk to musi być mocno na bakier z bezpieczeństwem, a to fałszywy wniosek. Za pomocą takiej powierzchownej statystyki każdą tezę można „udowodnić”.
Ale rzecz warta lektury