Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
Czy developerzy nauczyli się czegoś przez ostatnie kilka lat? RCE w Struts
Struts to popularna biblioteka (framework?), znana zapewne wielu fanom Javy. Znana jest ona również badaczom bezpieczeństwa, bowiem historia podatności jest tutaj dość pokaźna.
Tym razem zlokalizowano lukę w komponencie REST Plugin; w skrócie – wystarczy wysłać w tym przypadku odpowiednio spreparowanego XML-a do API REST i mamy wykonanie kodu na serwerze. Podatne są wszystkie wersje Struts od 2008 roku
Co ma XML do zdalnego wykonania kodu? Otóż podatność zasadza się na wykorzystaniu automatycznie wykorzystywanej deserializacji XML-a, przez komponent XStream wykorzystywany w Struts2.
Ale o RCE czającym się w XStream wiadomo już było 4 lata temu, a „bomba” tego typu wybucha co jakiś czas (patrz np. podatność na zdalne wykonanie kodu w Jenkins).
Czytelnicy Sekuraka z kolei wiedzą, że każda nieprzemyślana pod względem bezpieczeństwa deserializacja prowadzi do wykonania kodu w OS (przykład dla Javy, Pythona i PHP). W tym przypadku zwracam na kolejny problem – czasem nie wiemy, że wykorzystywane przez nas frameworki realizują „po cichu” deserializację…
Niepokojące jest też, że błędy tego typu ostatnio są explitowane zanim zostaną załatane (0-days) a najnowszy bug, wskazywany jest jako możliwe narzędzie w potężnym włamaniu do firmy Equifax – gdzie parę dni temu okazało się, że wyciekły dane o 143 milionach klientów. Dane klientów „nie są bezpieczne” – wykradziono bowiem ponad 200 000 numerów kart kredytowych. Dla rzetelności warto też dodać, że załoga Apache broni się przed zarzutami narażania użytkowników Struts na ryzyko związane z hackami (wspominają tu w szczególności temat Equifax).
Wnioski? Na pewno polecam zerknąć na opisywany przez nas projekt OWASP Dependency Check. Warto też być czujnym na bieżąco, jeśli chodzi o zagrożenia ze świata webowego (zerknijcie na nasz bezpłatny sekurak/zine o bezpieczeństwie aplikacji webowych).
–Michał Sajdak
Nie widzialem jeszcze soft developera, ktory dba/ma pojecie o bezpieczenstwie. Niektorzy wrecz otwarcie mowia, ze po to maja DevOpow i Sys adminow, zeby sie tym nie przejmowac. Czas i miejsce: Rok 2017, Wielka Brytania.
A co ma tutaj programista? Środowisko i konfiguracje przeprowadza właśnie administrator serwera, jak to nazywasz SysAdmin.
Myślisz, że programista takiego PHP powinien stawiać np. serwer www albo MySQL?
Pewnie tak jest w wielu przypadkach, ale umówmy się, co to ma wspólnego z programowaniem?
Właśnie dobre podejście mają Twoi koledzy z UK, nie wchodzą w kompetencje innych.
Tylko Polak chce i robi za wszystkich za cenę jednego a na końcu jeszcze za wszystko odpowiada osobiście :-)
Biblioteka to jest komponent programistyczny. Wiele razy zgłaszając podatność w zależnościach słyszałem, że nie da się zaktualizować bo implementacja uzależniona jest od konkretnej wersji (albo lokalna wersja z poprawkami i nie da się zmerdżować).
Ja odpowiadałem Pawłowi, nie był to komentarz do artykułu, ale odpowiadam.
Biblioteka to nie zawsze „komponent programistyczny” nad którym ma się pełną kontrolę – za bardzo upraszczasz.
Np. moduły do Apache są takimi bibliotekami.
Posiadają domyślne pliki konfiguracyjne, które powinny być tak ustawione, aby nie zagrażały bezpieczeństwu.
Programista może próbować je nadpisać, ale to admin powinien zadbać, żeby domyślnie działały jak trzeba.
Trudno żeby programista zajmował się jeszcze hostingiem.
Jak programista sam dołączą bibliotekę z zew. źródła, to oczywiście odpowiada za jej konfigurację.
Tak jeszcze się wtrącę – ten przytyk do developerów z naszej strony bardziej tyczy się devów Strutsa…
Z drugiej strony, czy nie pomija się w niusach o RCE faktu, że serwery aplikacji często śmigają z uprawnieniami roota / admina? Może warto zalecać adminom, by ograniczali systemowe uprawnienia aplikacji, a programistom, by ich appki nie wymagały takich uprawnień. Wtedy potencjalny RCE nie kompromisowałby systemu.