[OWASP Top 10] A9

Cześć.

Witam w kolejnym odcinku z cyklu 10 najpopularniejszych błędów powiązanych z bezpieczeństwem stron internetowych.

Dzisiejszy temat jest prosty i szybki.

A chodzi o używanie komponentów ze znanymi podatnościami.

W krótkich słowach mógłbym zatem powiedzieć, aby pamiętać o regularnych aktualizacjach wszystkich komponentów naszej aplikacji.

Począwszy od języka, frameworka, bibliotek, a skończywszy na serwerach i loadbalancerach.

W tym punkcie chodzi bowiem o to, że zazwyczaj komponenty, które wymieniłem, wcześniej działają z wysokimi prawami - trudno bowiem aby serwer webowy nie posiadał dostępu do plików w systemie albo też żeby baza danych nie posiadała wglądu do tabel.

Obecnie popularne są mikroserwisy - czyli rozdzielanie całej aplikacji na drobne komponenty.

Ale to niczego nie zmienia. Dalej w każdej aplikacji znajduje się jakiś mikroserwis odpowiedzialny za wysyłkę plików czy obsługę bazy danych.

Jeżeli zatem tam znajduje się błąd - może to doprowadzić do kompromitacji całej strony.

Ale żeby zrozumieć dlaczego łatanie podatności jest tak istotne, musimy porozmawiać o poszukiwaniu błędów i o tym co to są "0 day".

0 day to podatność w oprogramowaniu, która pojawia się jeszcze przed oficjalnym opublikowaniem poprawki przez producenta.

Z naszego punktu widzenia jest to bardzo zła wiadomość - przestępcy bowiem mogą wykorzystać taką lukę do ataku na nasz serwer, a my jednocześnie nie mamy praktycznie żadnych szans aby się przed tym atakiem obronić.

Wszak producent nie wydał poprawki, a łatanie błędów samemu to nie taka prosta sprawa.

Oczywiście istnieją zewnętrzne rozwiązania, które niejako wypełniają tą lukę - mowa tutaj o "virtal patching" - ale nie każda firma jest w stanie sobie na nie pozwolić.

Na całe szczęście takie błędy to rzadkość.

Ludzi zajmujących się profesjonalnie bezpieczeństwem możemy podzielić na dwie grupy:

• White hat - czyli osoby działające w zgodzie w pewnym kodeksem, a także black hat - czyli mówiąc ogólnie z przestępcami.

Ci pierwsi w momencie wykrycia podatności starają się zminimalizować straty powiązane z tym błędem.

Dlatego też przed opublikowaniem informacji na ten temat kontaktują się z producentem danego oprogramowania przesyłając mu wszystkie potrzebne informacje.

Dzięki temu producent ma odpowiedni czas na zareagowanie, przygotowanie poprawki i wydanie jej w świat.

Taka procedura nazywa się "responsible disclosure".

W przeszłości bywało, że firmy po otrzymaniu informacji na temat błędu nie poprawiały go przez dłuższy okres czasu.

To sprawiło, że badacze byli w rozterce.

Z jednej strony wiedzą o błędzie, dopełnili wszystkich starań aby pomóc zagrożonym użytkownikom. Z drugiej jednak strony publikacja opisu przed oficjalną łatką może narobić dużo złego.

Ale ile taki badacz powinien czekać? Miesiąc, dwa, rok? 3 lata?

Jeżeli on był w stanie odnaleźć dany błąd to równie dobrze mogą to zrobić przestępcy - którzy zaczną go wykorzystywać do złych celów.

Wszystko zmienił ruch firmy Google - a mówiąc konkretniej osób pracujących w Project Zero.

Jest to dział w tej firmie, który odpowiedzialny jest za poszukiwanie nowych błędów w popularnych programach używanych przez miliony osób na całym świecie.

Oni to przyjęli politykę 90 dni - a więc informacja jest publikowana automatycznie po 90 dniach od jej zgłoszenia.

Tyle czasu wystarczy w większości przypadków na prawidłowe poprawienie błędu i wydanie łatki - a presja czasowa powoduje, że producenci nie czekają już z poprawkami do ostatnich godzin.

Po środku barykady stoją osoby wierzące w "full disclosure".

W tym przypadku informacja o błędzie jest równocześnie wysyłana do producenta oraz staje się ogólnodostępna w Internecie.

Takie podejście ma swoich zwolenników oraz gorliwych wrogów.

Z jednej strony presja czasu na producencie może sprawić, że błąd zostanie poprawiony szybciej niż w 90 dni.

Z drugiej jednak strony - tracą użytkownicy, którzy przez pewien okres czasu są pozbawieni ochrony.

Dodatkowo należy pamiętać, że niektóre aplikacje to złożone systemy.

Poprawianie błędów w protokołach to nie taka prosta sprawa - należy bowiem zadbać między innymi o kompatybilność wsteczną.

Na samym końcu mamy jeszcze osoby, które poszukują błędów i wykorzystują je w złośliwych celach.

Na szczęście takich ataków nie jest za wiele.

Trzeba bowiem pamiętać, że poszukiwanie błędów, zwłaszcza w popularnym oprogramowaniu, to mozolna i trudna praca wymagająca sporego doświadczenia.

Tutaj należy również wspomnieć o firmach, które skupują tego rodzaju błędy, a następnie odsprzedają je różnym instytucjom.

W taki sposób instytucje do tego uprawnione mogą używać ich w celu łapania przestępców.

Nas jednak nie interesują tego rodzaju ataki.

Trzeba bowiem pamiętać, że odnalezienie każdego błędu swoje kosztuje.

Dla przykładu możliwość zainfekowania iPhone'a to koszt około 1 miliona dolarów.

Dlatego też tego rodzaju podatności wykorzystywane są głównie w atakach targetowanych, czyli takich, których celem jest włamanie się do jednej konkretnej instytucji, firmy czy też osoby.

W tym odcinku interesują nas bowiem błędy typu "1 day" - czyli błędy załatane przez producenta, ale nie spatchowane u klienta.

Bo to właśnie o nie chodzi w tej podkategorii.

Skąd zatem czerpać wiedzę na temat exploitów, które są obecnie dostępne w Internecie?

Po pierwsze można śledzić strony, które udostępniają tak zwane pliki POC (z angielskiego "Proof of Concept"), czyli przykład działania.

Są tą kawałki kodu, które demonstrują daną podatność.

Na rynku jest wiele firm, które publikują tego rodzaju informacje.

Jedną z popularniejszych jest strona exploit-db¹, gdzie błędy te można segregować w zależności od platformy, czy też typu.

Wiedzę można też czerpać z grup dyskusyjnych. Bardzo szanowaną jest fulldisclosure², gdzie wszystkie posty są wcześniej moderowane tak, aby utrzymać na tej grupie swego rodzaju porządek.

Błędy mają nawet swoją własną organizację, która każdemu z nich nadaje unikalny numer.

Numer ten to CVE - mogłeś się już z nim spotkać.

Zaczyna się od literek "CVE", potem rok, w którym odkryto podatność, a następnie unikalna liczba, po której można zidentyfikować jeden, konkretny błąd.

Jest to dobre rozwiązanie - dzięki temu dyskutując lub odnosząc się do danej podatności, wszyscy mogą używać stałego, niezmiennego numeru.

To również upraszcza wyszukiwanie informacji na jego temat.

A ilość błędów zwiększa się z roku na rok.

O skali niech świadczy fakt, że jeszcze nie tak dawno numer CVE był 4 cyfrowy.

Dziś jednak 4 cyfry nie wystarczają i zaczęto używać 5 cyfr,

Dobrym źródłem jest również Twitter - gdzie badacze publikują informacje na temat odkrytych przez siebie luk.

Sporo dużych firm posiada specjalne biuletyny bezpieczeństwa, które z pewnym wyprzedzeniem czasowym informują, że tego i tego dnia opublikowana zostanie łata bezpieczeństwa.

Takie skoordynowanie akcje pozwalą wszystkim na zabezpieczenie swoich serwerów jeszcze przed realnymi próbami ataków.

Ale jak widzisz miejsc, w których można znaleźć potrzebne informacje jest wiele.

Jeżeli jesteś jednak deweloperem, którego nie interesują kwestie związane z bezpieczeństwem systemu operacyjnego, serwerów a tylko bezpieczeństwem aplikacji - nie jest tak źle jak mogłoby się wydawać.

Praktycznie w każdym języku programowania powstała firma lub też projekt, którego zadaniem jest monitorowanie zależności w naszej aplikacji i informowanie o tych, które albo są przestarzałe, albo zawierają jakieś błędy.

I tak dla npm istnieje snyk lub też retirejs.

Dla Javy - OWASP Dependency-Check.

Na samym końcu warto tutaj wspomnieć, że obecnie coraz mniej kodu piszemy, a coraz więcej kodu wykorzystujemy – korzystając z różnych repozytoriów w stylu npm.

Sporo osób nie uruchomiłoby pliku exe, który został do nich wysłany w wiadomości email, wiedząc że najprawdopodobniej znajduje się tam złośliwe oprogramowanie.

Ale równocześnie używamy zewnętrznych bibliotek, których treść nie do końca sprawdziliśmy.

Pomału pojawiają się przypadki, gdzie ktoś wykorzystuje tą lukę w naszym rozumowaniu i stara się wykorzystać takie paczki do wyrządzenia nam szkody.

Warto o tym pamiętać – zwłaszcza jeżeli tworzymy aplikację wysokiego ryzyka, a więc powiązaną z pieniędzmi, czy też kryptowalutami.

I to już wszystko na dziś.

W ostatnim odcinku opowiem o nie wystarczającym logowaniu oraz monitorowaniu.

W między czasie zapraszam do posłuchania podcastu Szurkogadanie, w którym opowiadam co ostatnio działo się w branży bezpieczeństwa.

Jeżeli ten materiał Ci się spodobał, nie zapomnij o subskrypcji kanału i zostawieniu łapki w górę.

Do zobaczenia.

Cześć!

Free stock footage by Videezy.com

Business vector created by freepik - www.freepik.com

Stock footage provided by Videvo, downloaded from https://www.videvo.net

Icon made by Smashicons, Freepik www.flaticon.com