A francia, a német, a luxemburgi és a svéd egyetemek Boffinjai mélyen belemerültek a Java deserializációs sérülékenységeibe, és most újra előkerültek megállapításaikkal. Röviden: felhívták a figyelmet arra, hogy a könyvtárak milyen módon vezethetnek be akaratlanul is komoly biztonsági hibákat.
A szerializálás arra szolgál, hogy a memóriában lévő adatobjektumot bájtok sorozatává alakítsák tárolás vagy átvitel céljából. A deszerializáció megfordítja ezt a folyamatot azáltal, hogy az adatfolyamot visszafordítja objektummá a memóriában.
Java-ban ez a következővel van megvalósítva java.io.Serializable párosít. A deszerializálás azonban nem feltétlenül biztonságos, mert az objektum bájtfolyamából való rekonstrukciója nem tartalmazza a konstruktort – a tervkódot, amely az objektumot kezdetben úgy építi fel, hogy rendelkezzen az összes funkcióval és metódussal, amivel rendelkeznie kell. Ha a konstruktor érvényesítési ellenőrzéseket hajtott végre, akkor azok nem kerülnek végrehajtásra. Így lehetséges a deszerializálás érvénytelen vagy megváltozott adatokkal rendelkező objektumokat létrehozni.
A Java deserializációs hibái meglehetősen súlyosak lehetnek.
Például a Log4Shell, az Apache Log4j naplókönyvtárat érintő távoli kódvégrehajtási hibája a Java deserializálása tette lehetővé. 2016 novemberében egy zsarolóvírus-támadás több mint 2000, a San Francisco Municipal Transportation Agency (SFMTA) által üzemeltetett számítógépet veszélyeztetett az Apache Commons Collections deserializációs sebezhetőségén keresztül.
Ezenkívül a 2017-es Equifax-hack belépési pontja, amelynek eredményeként 147,7 millió amerikai személyes adatait lopták el, az Apache Struts Java deserializációs hibája okozta. Tavaly júliusban pedig volt egy Atlassian Jira sebezhetősége, ahol egy támadó, aki képes volt csatlakozni egy Ehcache RMI hálózati szolgáltatáshoz, „tetszőleges kódot futtathat le a Jira-ban deserializálással a hiányzó hitelesítési sebezhetőség miatt”.
Az “An Depth Study of Java Deserialization Remote-Code Execution Exploits and Vulnerabilities” című tanulmányában Imen Sayar (Toulouse-i Egyetem), Alexandre Bartel (Umeå Egyetem), Eric Bodden (Paderborn Egyetem) és Yves Le Traon informatikusok. (University of Luxembourg) leírja, hogyan kutattak a 19 széles körben ismert Java deserializációs RCE exploitja által megcélzott szoftverkönyvtárak között, hogy megértsék, hogyan kerülnek be a modulok – kihasználható kódkonstrukciók – a Java könyvtárakba, és hogyan kudarcot vallanak néha az ezektől a kütyüktől való megszabadulási kísérletek.
Bár a szerializálás és a deszerializálás hasznos, a szerzők megjegyzik, ez a folyamat kockázatokat rejt magában, ha a deszerializált adatok nem megbízható forrásból származnak. “Valójában egy támadó létrehozhat egy bájtfolyamot, amely a távoli gazdagépen deszerializálva vezérelheti a Java-kód végrehajtási folyamatát azáltal, hogy összefűzi a Java-kód szekvenciáit, úgynevezett modulokat” – magyarázzák.
A gadget kifejezésnek van néhány konkrét jelentése a sebezhetőségek kihasználásának világában. Írásukban a szerzők a szót egy potenciálisan kihasználható Java metódusra utalják, amelyhez a támadó hozzáférhet. Egy könyvtár tartalmazhat olyan modulokat, amelyek összekapcsolhatók, így sorozatban működhetnek.
A deserializációs sebezhetőség kihasználása bonyolult támadási láncot foglalhat magában, vagy olyan egyszerű, mint egy hálózaton keresztüli GET kérés.
A fő következtetésünk az, hogy egy ártalmatlannak tűnő részlet megváltoztatása egy osztályban – például nyilvánossá tétele – már bevezethet egy modult.
A kutatók 19 sérülékenységet vizsgáltak meg 14 könyvtárban (néhányhoz több verzió is tartozik): beanshell, clojure, commons-beanutils, commons-collections, groovy, rome, js-rhino, spring-beans, spring-core, spring-aop, click-nodeps, javax.servlet, vaadin-serverés vaadin-shared.
“A 19 RCE exploit elemzése során számos módot találtunk arra, hogy egy modult bevigyünk a könyvtárba: osztályok, metódusok és interfészek hozzáadásával vagy a metódusok aláírásának megváltoztatásával” – olvasható a lapban. “A fő következtetésünk az, hogy egy ártalmatlannak tűnő részlet megváltoztatása egy osztályban – például nyilvánossá tétele – máris bevezethet egy modult.”
Mivel a deszerializációs exploit létrehozásához modulokra van szükség, az új modulokat beszúró kódmódosítás nyilvánvalóan nem ideális.
A tesztelt könyvtárak és változataik közül 14-et javítottak a potenciális kütyük eltávolítása érdekében. Ez többféleképpen megtehető, például törléssel java.io.Serializable a sebezhető osztályba tartozó interfészek listájáról, beleértve a sebezhető osztály teljes eltávolítását vagy biztonsági ellenőrzés bevezetését.
Az értékelt könyvtárak közül hat (commons-beanutils1.9.4, rome1.0, spring-beans-3.0.0.RELEASE, click-nodeps-2.3.0-RC1, javax-servlet-api-4.0.1és vaadin-shared-7.4.0.beta1) javítás nélküliként szerepelnek. Tehát, ha az alkalmazásai ezek közül bármelyiket tartalmazzák, fontolja meg, hogyan járjon el. A megoldásra várni azonban nem biztos, hogy a legjobb megoldás.
“Az ilyen könyvtárakból származó javítások tanulmányozása során azt láttuk, hogy a modulok eltávolításához szükséges idő néhány hónaptól majdnem 12 évig terjed, átlagosan csaknem hat év” – összegezték a kutatók. “Tehát úgy tűnik, hogy a deserializációs sebezhetőségek még nem kapják meg azt a figyelmet a szakemberektől, mint amilyennek valóban kellene.” ®