[Raport CERT OPL] Diabeł tkwi w Open Source
Dziś w ramach akcji „Poczytaj Raport CERT OPL” oddajemy łamy Grzegorzowi Siewrukowi, naszemu ekspertowi, doktorantowi na Politechnice Warszawskiej, egzorcy… No dobra, z tym egzorcystą to przesada, bo ten diabeł to nie literalnie. W każdy razie Grzegorz przyjrzał się podatnościom w oprogramowaniu otwartoźródłowym.
Oczywiście to nie jedyny tekst, który warto przeczytać! Cały Raport CERT Orange Polska za rok 2019 znajdziecie tutaj.
Wykorzystanie rozwiązań o otwartym kodzie źródłowym (ang. Open Source) wzrasta z roku na rok. Organizacjewykorzystują biblioteki, systemy operacyjne oraz aplikacje w coraz szerszym zakresie. Niewiele osób zdaje sobie sprawę, że w dużej części komercyjnych rozwiązań zawartość otwartego kodu (w stosunku do całej bazy kodu) wynosi nawet 76%.
Obecnie wiele organizacji ma bardzo rozbudowane mechanizmy weryfikujące bezpieczeństwo kodu źródłowego, który jest wytwarzany na potrzeby budowania oprogramowania. Na te mechanizmy składają się takie elementy jak: przegląd kodu, statyczne analizy, zestawy przygotowanych testów czy w końcu testy penetracyjne. Wszystko jest możliwe dzięki coraz to nowszym rozwiązaniom, które można w prosty sposób wykorzystać wewnątrz łańcucha dostarczania oprogramowania. Niestety nie można powiedzieć tego samego o weryfikowaniu bezpieczeństwa bibliotek, które pochodzą z zewnętrznych źródeł. Brak kontroli nad tym obszarem może doprowadzić do katastrofalnych efektów. Jednym z przykładów jest prawdopodobnie najbardziej znany przypadek wycieku danych w firmie Equifax. Wyciek dotyczył danych 143 mln użytkowników i był spowodowany krytyczną podatnością w bibliotece Apache Struts (CVE-2017-5638), która umożliwiała zdalne wykonanie kodu na serwerze. Od momentu opublikowania podatności do wykrycia włamania (ale jeszcze nie do zaktualizowania) minęło ponad 5 miesięcy. Jeszcze dzisiaj możliwe jest znalezienie serwisów, które korzystają z podatnej wersji wyżej wymienionej biblioteki.
Aby przedstawić skalę problemu postanowiliśmy przetestować kilkanaście najpopularniejszych projektów stworzonych w języku programowania JAVA, które są umieszczone w serwisie GitHub. Dodatkowym wymaganiem było to, aby projekt był aktywnie rozwijany (ostatnia zmiana nie później niż miesiąc od momentu wykonywania eksperymentu). Eksperyment dotyczył 15 wybranych repozytoriów kodu.
| najstarsza podatność | CVE-2013-7285 | wykryta w 18% projektów |
| posiada podatności | 80% | repozytoria kodu |
| najpopularniejsza podatność | CVE-2018-14718 | wykryta w 30% projektów |
| najbardziej podatna biblioteka | jackson-mapper-asl:1.9.13 | 40 opublikowanych podatności |
Z badanych repozytoriów kodu, aż w 80% znalezione zostały opublikowane podatności w bibliotekach, które są wykorzystywane w rozwiązaniu. Należy pamiętać, że nawet pobierana z zewnętrznego źródła biblioteka może zawierać odniesienia do innych, w wyniku czego tworzona jest cała mapa zależności. Najstarsza wykryta podatność, w aktywnie rozwijanym projekcie została opublikowana w 2013 roku i dotyczyła biblioteki ‘XStream’ pozwalając na wykonywanie zdalnych komend w systemie operacyjnym. Jak widać 5 miesięcy na podniesienie wersji w przypadku wspomnianej wcześniej podatności w Apache Struts wygląda
bardzo dobrze w porównaniu do niemal 7-letniego CVE-2013-7285. Najbardziej popularna podatność, została wykryta w komponencie ‘jackson-databind’, wykorzystywanym przez 30% badanych repozytoriów kodu. Podatność opisana jako CVE-2018-14 pozwala na zdalne wykonanie kodu poprzez błędy związane z deserializacją. Ciekawe, że biblioteką, która posiada najwięcej opublikowanych podatności jest ‘jackson-mapper-
asl’ w wersji 1.9.13. Pomimo, że nie jest ona rozwijana od 2013 roku, to jest zawarta na ścieżce bardzo dużej ilości bibliotek. Podobne problemy można zaobserwować w wielu innych przypadkach, w których biblioteka, która nie jest potrzebna do wykonywania logiki biznesowej znajduje się na ścieżce. Jest to szczególnie niebezpieczne w przypadku wystąpienia błędów związanych z deserializacją, gdzie konkretna funkcjonalność nie musi być w żaden sposób wykorzystywana, aby atakujący miał możliwość zdalnego wykonania kodu.
Biorąc pod uwagę rozmiar eksperymentu nie można mówić o trendach, ponieważ próbka jest zbyt mała. Jednak problem związany z bezpieczeństwem oprogramowania pobieranego z zewnętrznych źródeł istnieje. Programiści często bezkrytycznie dodają kolejne zależności do rozwijanych aplikacji, a procesy dostarczania oprogramowania nie weryfikują stanu bezpieczeństwa otwartego oprogramowania wykorzystywanego przez budowany system. Są też pozytywy. Coraz więcej osób zajmujących się zarówno bezpieczeństwem, jak i rozwojem oprogramowania zauważa problem. Istnieją darmowe rozwiązania (oczywiście z otwartym kodem), które są już na tyle dojrzałymi projektami, że dorównują dokładnością swoim komercyjnym odpowiednikom. Teraz wystarczy powiedzieć „sprawdzam” i wykorzystać odpowiednie narzędzia do weryfikacji bezpieczeństwa tworzonego oprogramowania.
Grzegorz Siewruk
