We hebben het inmiddels allemaal wel voorbij horen komen: Log4J/Log4Shell, de nieuwe grote ramp van het internet. Maar wat is het nou precies? Is de paniek terecht? En wat kunnen we er zelf tegen doen? Wilt u bij toekomstige incidenten direct op de hoogte worden gebracht? Schrijf u dan nu in voor onze waarschuwingsdienst.
Wat is Log4j?
Log4j is een populaire Java library om logs te genereren binnen applicaties. Een library is in essentie een stuk software dat bedoeld is om te gebruiken binnen andere software. Meestal bevat een library functionaliteit die in bijna ieder project van belang is. Hierdoor hoeven programmeurs niet telkens dezelfde code opnieuw te schrijven. Vaak zijn de libraries ook Open Source. Dit heeft als bijkomend voordeel dat de code niet enkel gecontroleerd wordt door één persoon (de ontwikkelaar), maar in potentie door duizenden personen. Dit maakt de kans op fouten en kwetsbaarheden in de code veel kleiner, althans, in theorie.
Wat is de kwetsbaarheid?
Wat log4j in de basis dus doet, is het wegschrijven van data naar een logbestand. Echter, in de manier waarop dit gebeurt is dus een kwetsbaarheid gevonden. Normaal gesproken zou bijvoorbeeld gelogd worden waar een webrequest (een aanvraag naar een webserver) vandaan komt. Dan worden bijvoorbeeld het IP-adres, het webadres, en de UserAgent opgeslagen. De UserAgent geeft aan via welke browser je verbinding maakt, dus bijvoorbeeld Google Chrome, Mozilla Firefox, of Safari. De software stuurt deze data vervolgens door naar Log4j, die het opslaat in het logbestand.
Het probleem dat nu aan het licht is gekomen, is dat de te loggen tekst mogelijk (deels) als code geïnterpreteerd kan worden voordat het wordt opgeslagen. Dit is het geval wanneer gebruik gemaakt wordt van speciale karakters. Een normale log zou zijn:
10.0.0.14 – GET /api/items/17 – Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefoxversion
Dit wordt vervolgens ook letterlijk zo opgeslagen in het logbestand. Maar stel dat een gebruiker zijn request aanpast voordat het verstuurd wordt, dan wordt dat ook door log4j verwerkt. Een aangepast request zou bijvoorbeeld op deze manier naar Log4J gestuurd worden:
10.0.0.14 – GET /api/items/17 – ${java:os}
En op deze manier in het logbestand opgeslagen worden:
10.0.0.14 – GET /api/items/17 – Windows 10 10.0, architecture: amd64-64
Dit is nog een relatief onschuldig voorbeeld waarbij enkel het gebruikte besturingssysteem opgevraagd en ingevuld wordt in het logbestand, maar ditzelfde principe kan gebruikt worden om extern ingeladen code te laten uitvoeren op de server. Dit maakt gebruik van het JNDI protocol, wat in de Java wereld veel gebruikt wordt om externe bronnen in te laden. Normaal gesproken vormt dit geen risico, omdat de externe bronnen door de ontwikkelaar gekozen worden. Het probleem bij Log4J is echter dat deze externe bronnen door iedere willekeurige aanvaller ingeladen en uitgevoerd kunnen worden. Deze externe bron kan onschuldig zijn, maar zou ook zomaar een backdoor, ransomware of spionagesoftware kunnen zijn. Via deze weg kunnen kwaadwillenden het volledige systeem overnemen. Eenmaal binnen behouden ze toegang, ook als het lek eenmaal verholpen is.
Dus, het is kinderlijk eenvoudig om misbruik te maken van deze kwetsbaarheid, en het is mogelijk om verschillende soorten aanvallen uit te voeren, maar wat is nu daadwerkelijk de impact?
Zo’n kwetsbaarheid kan alleen massaal misbruikt worden als hij in veel toepassingen aanwezig is. Ook dit is het geval voor log4j: Legio aan populaire softwarepakketten maken gebruik van deze library. Volgens onderzoek van Snyk wordt de library in zo’n 60% van alle door hen gemonitorde Java projecten gebruikt.
Van de grotere enterprise producten mogen we verwachten dat zij snel met oplossingen komen (wat een groot aantal inmiddels ook al heeft gedaan), en ook de ontwikkelaars van de log4j library zullen snel een patch publiceren. Maar het grootste deel van die 60% zullen kleine tot middelgrote projecten zijn, vaak met maar één of enkele ontwikkelaars en vaak niet meer actief onderhouden. Deze projecten blijven dus kwetsbaar, en daardoor de organisaties die deze projecten gebruiken ook.
Hoe kunt u zich hiertegen beveiligen?
Allereerst door waar mogelijk log4j te updaten naar versie 2.15.0. De kwetsbaarheid is in deze versie deels opgelost. Invoer kan nog steeds zoals hierboven geïnterpreteerd worden als code, echter wordt het inladen van externe bronnen via JNDI nu standaard niet meer uitgevoerd.
Er zijn dus nog steeds manieren om hier misbruik van te maken, security onderzoekers komen aan de lopende band naar buiten met nieuwe manieren. De komende dagen en weken zal er meer duidelijk worden, maar vooralsnog is patchen je beste gok om niet tot de makkelijkste prooien te horen.
Ga intern na welke softwarepakketten worden gebruikt, of deze gebruik maken van log4j en of de ontwikkelaars al een update of advies hebben gepubliceerd voor hun product. Ook IDS/IPS oplossingen zoals in firewalls van gerenommeerde merken maken het moeilijker voor aanvallers om een succesvolle aanval uit te voeren.
Heb je het vermoeden al slachtoffer te zijn geworden van deze aanval? Dan is patchen te laat. Controleer met een security expert uw netwerk, of neem contact op met ons voor advies over verder te ondernemen stappen.
Wilt u op de hoogte blijven?
Wilt u op de hoogte blijven over de laatste ontwikkeling omtrent deze kwetsbaarheid en het laatste nieuws op gebied van Cyber Security? Schrijf u dan in voor onze waarschuwingsdienst. Bij toekomstige kwetsbaarheden brengen wij u dan direct op de hoogte van de risico’s en hoe u zich hier het beste tegen kunt beveiligen.
Bronnen:
https://logging.apache.org/log4j/2.x/manual/index.html
https://logging.apache.org/log4j/2.x/security.html
https://opensource.org/osd
https://nakedsecurity.sophos.com/2021/12/13/log4shell-explained-how-it-works-why-you-need-to-know-and-how-to-fix-it/
https://www.bleepingcomputer.com/news/security/log4j-list-of-vulnerable-products-and-vendor-advisories/
https://venturebeat.com/2021/12/13/less-obvious-uses-of-log4j-pose-a-major-risk/
