Od dwunastu lat regularnie, co drugi wtorek każdego miesiąca, użytkownicy otrzymują aktualizacje Windows. Oczywiście system operacyjny to niejedyny systematycznie aktualizowany kod. Flash Player czy biblioteki Java są kolejnymi często aktualizowanymi programami. Celem aktualizacji jest usunięcie wykrytych błędów w kodzie. Takie błędy to nie tylko możliwość nieprawidłowego działania danego rozwiązania, ale dodatkowo poważne zagrożenie dla bezpieczeństwa danych. Program zawierający błędy może stać się narzędziem ułatwiającym dystrybucję złośliwego oprogramowania, infekowanie kolejnych komputerów, infiltrację użytkowników itd. Regularna dbałość o kod danego rozwiązania jest o tyle istotna, że wiele programów – a w szczególności systemy operacyjne – to produkty o długim czasie życia na rynku. Windows stanowi podstawę działania setek tysięcy aplikacji, a przecież kod wciąż najpopularniejszego dziś systemu Windows 7 został opracowany już dawno. Odrębną kwestię stanowią wady projektowe. Przykładem może być platforma do zarządzania licencjonowanymi i cyfrowo chronionymi publikacjami elektronicznymi – Adobe Digital Editions. W starszych wersjach narzędzie to wymieniało z serwerami Adobe nie tylko dane dotyczące licencji (weryfikacja licencji), ale również dane dotyczące baz e-booków konkretnych osób. Problem polegał na tym, że dane przesyłane były otwartym tekstem. Dopiero wdrożenie aktualizacji poprawiło poziom bezpieczeństwa.
Bezpieczeństwo nie jest priorytetem
Gdy przysłuchujemy się zapewnieniom przedstawicieli działów marketingu producentów oprogramowania, może się wydawać, że bezpieczeństwo to ważna, bodaj najważniejsza kwestia uwzględniona w promowanym rozwiązaniu. Niestety, tak nie jest. Szczególnie jaskrawym przykładem zbyt błahego podejścia czy wręcz lekceważenia zagadnień związanych z bezpieczeństwem jest firma Apple i jej system mobilny – iOS. Przyjęcie niewłaściwych priorytetów spowodowało, że pierwsze wersje najnowszej generacji systemu iOS 8 pełne były rażących błędów, niekiedy wręcz uniemożliwiających użytkownikom normalne korzystanie z urządzeń z tym systemem. Wprowadzenie aktualizacji 8.0.1 okazało się jeszcze gorszym posunięciem, bo aktualizacja, zamiast poprawiać sytuację, tylko ją pogarszała. Wyraźnie widać konflikt interesów pomiędzy deweloperami aplikacji a wydawcami, menedżerami odpowiedzialnymi za wdrożenie nowych rozwiązań. Ci pierwsi chcą mieć więcej czasu na dokładniejsze sprawdzenie kodu, tym drugim zależy na jak najszybszym wprowadzeniu produktu na rynek. Problem jest na tyle poważny, że wady kodu stały się przedmiotem obrotu. Uruchomiony w 2010 roku Google Vulnerability Reward Program wynagradza tych, którzy w oprogramowaniu Google’a odnajdą luki stwarzające potencjalne zagrożenie dla bezpieczeństwa użytkowników. Wypłacane stawki są zależne od wielu czynników: typu zagrożonego produktu, zasięgu oddziaływania luki itp.
Egzemplifikacją najlepiej wynagradzanych zdarzeń jest odkrycie luki umożliwiającej zdalne wykonanie kodu – znalezienie tego typu błędów oznacza dla odkrywcy gratyfikację w wysokości 20 tysięcy dolarów. Z kolei Kevin Mitnick otworzył sklep internetowy, w którym przedmiotem obrotu są luki w oprogramowaniu, i to te najniebezpieczniejsze. Cena? 100 tysięcy dolarów za sztukę. Odrębnym zagadnieniem są luki “zaprojektowane”. Ich istnienie podejrzewano od dawna, a fakt ten potwierdziły rewelacje Edwarda Snowdena. Dyrektor FBI James Comey jest zwolennikiem monitoringu – uświadamia, że prywatność jednostki i bezpieczeństwo publiczne często znajdują się na kursie kolizyjnym.
Feler w systemie
Brak wykrytych luk w programie nie oznacza, że mamy do czynienia z produktem bezpiecznym. Może znaczyć tylko, że dany kod jest mało popularny i po prostu nie wzbudził zainteresowania agresorów. W centrum zainteresowania cyberprzestępców znajduje się kod popularny, bo tylko taki gwarantuje szybką propagację zagrożenia “wstrzykniętego” przez odkrytą lukę. Dlatego też zarówno osoby odpowiedzialne za bezpieczeństwo, jak i cyberprzestępcy poszukują luk w powszechnie stosowanych aplikacjach i systemach operacyjnych.
Próba oceny, na ile bezpieczny jest program, to zadanie trudne. Liczba znanych błędów stanowi zaledwie jeden ze wskaźników, ale istotne jest również, na ile poważne konsekwencje niesie ze sobą wykorzystanie danego błędu. Odpowiedzi dostarczają oceny zgodne z systemem CVSS (Common Vulnerability Scoring System; standard oceny stopnia zagrożenia bezpieczeństwa systemów komputerowych). Każde wykryte zagrożenie (opublikowane np. w bazie NVD – National Vulnerability Database – nvd.nist.gov; informacje o ocenach CVSS publikowane są też w biuletynach informacyjnych towarzyszących pakietom aktualizacyjnym – tak robi np. Microsoft) jest oceniane w skali 10-punktowej. Wartość 10 oznacza najpoważniejszy problem, przy czym luki mające oceny od 7 do 10 uważa się za niezwykle poważne zagrożenie dla bezpieczeństwa. System Windows od dawna uchodzi za niezbyt bezpieczny, zaś obydwa systemy operacyjne Apple’a – stacjonarny OS X oraz mobilny iOS – uznawane są przez konsumentów za bezpieczne rozwiązania. Jednak statystyki NVD i oceny CVSS mówią coś innego.
Windows bezpieczniejszy, niż się wydaje
Liczba wykrytych błędów w kodzie systemów Microsoft u od kilku lat systematycznie spada. Tak samo wygląda sytuacja w przypadku popularnego pakietu biurowego tej firmy. Z kolei Adobe, choć regularnie łata swój czytnik Adobe Reader czy program Flash Player, nie osiąga już podobnych rezultatów. Pomysłem na ograniczenie ryzyka związanego z potencjalnym wykorzystaniem luk w popularnym oprogramowaniu jest zastąpienie powszechnie używanych aplikacji znacznie mniej popularnymi odpowiednikami, np. w przypadku Microsoft Office może to być pakiet LibreOffice, a zamiast czytnika Adobe Reader program Sumatra PDF. Niemniej trudno nie zauważyć, że taki pomysł oznacza również zgodę na rezygnację z pewnych funkcji i często konieczność zmiany przyzwyczajeń, a to cena, którą nie wszyscy zdecydują się zapłacić.
Lepszym rozwiązaniem jest implementowanie przez producentów oprogramowania mechanizmów umożliwiających otwieranie dokumentów w bezpiecznym, izolowanym środowisku. Przykładem może być oprogramowanie Adobe Reader. Od wersji 10 czytnik wyposażony jest w tzw. piaskownicę, w której otwierany jest dokument PDF. Istotą piaskownicy jest to, że dane w niej przetwarzane są oddzielone od reszty systemu i działających w nim aplikacji, co skutecznie ogranicza możliwość infiltracji i infekcji systemu-gospodarza. Niestety, w 2014 roku odkryto trzy luki, które zniweczyły starania związane z użyciem piaskownicy, co miało zwiększyć poziom ochrony. Jeszcze innym rozwiązaniem okazuje się system Docker. To platforma do uruchamiania aplikacji włącznie z wymaganymi przez dany program bibliotekami w jednym, wirtualnym pojemniku. Microsoft planuje wdrożyć rozwiązanie typu Docker w kolejnej edycji swojego systemu serwerowego.
Surferzy w niebezpieczeństwie
Dla każdego cyberprzestępcy pierwszym celem na atakowanych komputerach domowych są często przeglądarki WWW. Najpierw skłania się użytkownika do odwiedzenia konkretnej, często zainfekowanej niebezpiecznym skryptem strony internetowej, po czym następuje próba wyłudzenia ważnych informacji. Nie trzeba w tym przypadku nawet otwierać jakiegoś zainfekowanego pliku. Wystarczy w trakcie surfowania znaleźć się w niewłaściwym czasie na niewłaściwej stronie. Jednym z popularniejszych rodzajów zagrożeń wykorzystujących przeglądarkę są ataki typu drive-by-download. Użytkownik po odwiedzeniu zainfekowanej złośliwym skryptem strony nie zdaje sobie sprawy, że przeglądarka rozpoczyna automatyczne pobieranie licznych złośliwych programów, które następnie próbują wykorzystać luki w zainstalowanych w danej przeglądarce rozszerzeniach i wtyczkach. Zainfekowanie aplikacji działających w samym systemie jest już trudniejsze, dzięki wbudowanym w Windows mechanizmom ochronnym znanym pod wspólną nazwą DEP (Data Execution Prevention). Obszary danych w pamięci oznaczane są jako niewykonywalne, dzięki czemu nawet “wstrzyknięcie” kodu wykonywalnego (możliwe dzięki luce w aplikacji) w obszar pamięci zajęty przez dane nie umożliwi agresorowi działań. DEP stanowi dość skuteczne zabezpieczenie przed exploitami, ale nie w pełni skuteczne. Agresorzy posługują się w takim przypadku specjalną techniką zwaną ROP (Return Oriented Programming), umożliwiającą wykonanie kodu mimo obecności DEP.
Oblężony Internet Explorer
Oprogramowaniem, które wydaje się szczególnie podatne na ataki z wykorzystaniem technik typu ROP, jest przeglądarka Internet Explorer. Pod tym względem produkt Microsoft u wypada gorzej od alternatyw takich jak Firefox czy Google Chrome. Skuteczność technik exploitowania typu ROP jest ograniczana poprzez wbudowany w system Windows mechanizm ASLR (Address Space Layout Randomization). Powstał on jako środek ochrony przed atakami bazującymi na przepełnieniu bufora (buff er overfl ow attacks). Wyjaśniając rzecz obrazowo, ASLR powoduje, że agresor po prostu nie wie, gdzie umieścić swój kod, zatem chcąc zwiększyć skuteczność ataku, próbuje losowo wczytać kod w różnych obszarach pamięci, co w pewnym stopniu zwiększa prawdopodobieństwo przeprowadzenia skutecznego ataku mimo aktywnego mechanizmu ASLR. Microsoft EMET (Enhanced Mitigation Experience Toolkit) to oprogramowanie służące zapobieganiu wykorzystywania luk w aplikacjach i zabezpieczeniach systemowych. EMET wprowadza dodatkowe mechanizmy ochrony, współpracujące z dowolnym oprogramowaniem opracowanym kiedykolwiek i przez dowolnego dewelopera. Jeżeli korzystasz z przeglądarki Firefox, zalecamy instalację rozszerzenia NoScript umożliwiającego indywidualną blokadę różnego typu innych wtyczek i skryptów. Z kolei możliwość ataku wykorzystującego luki w oprogramowaniu Java Runtime znacznie ograniczymy, zwiększając standardowy poziom zabezpieczeń za pomocą panelu konfiguracyjnego Javy w systemie operacyjnym.
Java to poważny problem dla Oracle’a – tylko w 2014 roku odkryto 115 nowych luk, dwa razy więcej niż w uznawanym za “dziurawy jak sito” oprogramowaniu Flash Player.
Z jednej strony oprogramowanie otwarte uniemożliwia ukrycie funkcji szpiegowskich, gdyż te mogą być z łatwością wykryte przez osoby analizujące kod danego programu. Z drugiej jednak głośna luka w oprogramowaniu OpenSSL o nazwie Heartbleed udowodniła, że otwartość oprogramowania nie oznacza produktu wolnego od wad. Otwartość kodu to w pewnym sensie również wada, bo jawność kodu ułatwia potencjalnym agresorom wyszukanie w nim błędów, które można następnie wykorzystać podczas ataków – tak właśnie było w przypadku luki Heartbleed. W 2014 roku odnaleziono bardzo poważne (ocena CVSS: 10) luki w powłoce systemowej (Linux/UNIX) bash. Tzw. błąd Shellshock istniał w otwartym oprogramowaniu przez… 22 lata (sic!).
Projekty Open Source są niedofinansowane
Szyfrowanie stosowane w sieci WWW również oparte jest w znacznym stopniu na kodzie otwartym. Nawiązanie bezpiecznego połączenia pomiędzy serwerem a przeglądarką WWW w przypadku dwóch trzecich wszystkich serwerów na świecie odbywa się w oparciu o otwartą implementację protokołów i algorytmów kryptograficznych znaną pod nazwą OpenSSL. Pod koniec kwietnia 2014 roku w jednej z bibliotek kryptograficznych wchodzących w skład OpenSSL odkryto lukę umożliwiającą atakującemu odczyt danych chronionych przez szyfrowanie SSL i TLS. Opisywana luka zaliczana jest do tzw. luk implementacyjnych (wadliwy nie jest sam algorytm, lecz sposób jego wdrożenia). Problem był bardzo poważny: bo możliwy był nieautoryzowany odczyt danych oraz poznanie kluczy prywatnych, które powinny stanowić najściślej strzeżoną tajemnicę stron szyfrowanej komunikacji.
Heartbleed i Shellshock mają jedną wspólną cechę – to kod zbudowany głównie przez wolontariuszy. OpenSSL używany przez gros serwerów na całym świecie jest kodem, którym opiekuje się jedenastu deweloperów z rocznym budżetem 2000 dolarów! Wszystkie główne firmy informatyczne i bogate światowe korporacje oczywiście wykorzystują bezpłatnie kod OpenSSL. Gdy uporano się z Heartbleedem, pojawił się kolejny problem: luka o nazwie Poodle, ponownie związana szyfrowaną komunikacją. Tutaj nie znaleziono rozwiązania, a właściwie rozwiązaniem jest całkowita rezygnacja z korzystania z SSL 3.0 i przejście wyłącznie na standard TLS. Potencjalnym kolejnym celem może być mechanizm szyfrowania poczty (i nie tylko) wykorzystujący narzędzie szyfrujące PGP. Wielu ekspertów ds. bezpieczeństwa, m.in. profesor Matthew Green, uważa, że powstały w 1991 PGP jest w znacznym stopniu przestarzały i absolutnie nie przystaje do dzisiejszych realiów bezpieczeństwa. Skąd nagłe zainteresowanie PGP? Otóż zarówno Google, jak i Yahoo zamierzają wykorzystać mechanizmy PGP w swoich produktach pocztowych. Zdaniem Greena znacznie lepszym wyjściem byłoby posłużenie się metodą PFS (Perfect Forward Secrecy) – gdzie użyty do zaszyfrowania transmisji klucz jest usuwany po zastosowaniu.
Tuzy świata IT zdały sobie sprawę z problemu niedofinansowania świata Open Source. W ramach Linux Foundation firmy, takie jak Google, Microsoft, Adobe czy Amazon, wspierają projekt o nazwie
Core Infrastructure Initiative. Celem jest eliminacja luk w zabezpieczeniach otwartego oprogramowania. Najwyższy czas.