Wat moeten app-developers doen om Log4j-exploits te bestrijden?
Waarom u mogelijk al risico loopt, hoe u de Log4j-kwetsbaarheden nu kunt detecteren en verminderen en hoe u uw codebeveiliging in de toekomst kunt verbeteren. Eind vorige maand ontdekten beveiligingsonderzoekers een reeks grote kwetsbaarheden in de Log4j Java-software die wordt gebruikt in tienduizenden webapplicaties. De code wordt veel gebruikt in consumenten- en bedrijfssystemen, in alles van Minecraft, Steam en iCloud tot Fortinet- en Red Hat-systemen. Een analist schat dat miljoenen eindpunten in gevaar zou kunnen komen.
Log4j is slechts de laatste in een reeks aanvallen op de toeleveringsketen van software, waaronder SolarWinds (met een gecompromitteerd bouwproces) en Kaseya (waaraan aanvallers code met malware hadden vervangen).
Sinds de eerste Log4j-kwetsbaarheid aan het licht kwam, hebben beveiligingsleveranciers en analisten veel informatie gepubliceerd over wat te doen, over de hele kaart. Sommige mensen hebben bijna-doemscenario’s gepost, terwijl anderen minder sombere voorspellingen hebben. Check Point Software Technologies heeft pogingen gezien bij bijna de helft van zijn klantenbestand. Contrast Security heeft ontdekt dat 58% van de Java-applicaties kwetsbare versies heeft, maar dat slechts 37% Log4j daadwerkelijk gebruikt.
De Amerikaanse Cybersecurity and Infrastructure Security Agency houdt hier een webpagina bij met links naar verschillende blogs van leveranciers, samen met een lijst met getroffen applicaties, en probeert beide up-to-date te houden met eventuele fixes.
De problemen hebben betrekking op verschillende functies van de logboeksoftware, waaronder de Java Naming and Directory Interface (JDNI) en JMSAppender-gebeurtenisberichten, die beide het uitvoeren van externe code mogelijk maken. Wat deze verzameling kwetsbaarheden gevaarlijk maakt, is dat aanvallers niet veel expertise nodig hebben om deze toegang op afstand te krijgen. De laatste kwetsbaarheid verwijst naar een denial-of-service-conditie, die iedereen scherp houdt. En recentelijk vond Blumira een nieuwe aanvalsvector die het totale oppervlak verbreedt met behulp van WebSockets.
Het lijkt erop dat we het einde van Log4j nog niet hebben gehoord. Wat duidelijk is, is dat je als applicatieontwikkelaar veel werk te doen hebt om log4j-problemen op korte termijn te vinden, op te lossen en te voorkomen, en een paar dingen om je op de langere termijn zorgen over te maken. Tanya Janca, van WeHackPurple stelt voor dat u dependencyGraph, Snyk of OWASP’s Dependency-Check gebruikt. Zodra u een dependency vindt, maakt u een opmerking over de code die Log4j aanroept als u deze niet onmiddellijk kunt patchen.
Begrijp hoe webtoepassingsfirewalls (WAF’s) werken. Als je nog geen WAF hebt, is dit het moment om er een aan te schaffen . Als een van uw code achter een WAF is geïmplementeerd, schakelt u hun detectieregels in en controleert u of de leverancier zijn regels heeft bijgewerkt om alle nieuwste kwetsbaarheden te dekken. Maar besef dat sinds de aankondiging van de fout, onderzoekers vele manieren hebben aangetoond om geneste en verduisterde payloads te bouwen die de voorgestelde WAF-filterregels zouden omzeilen. Fastly heeft een uitgebreide uitleg samengesteld hoe je de WAF-effectiviteit kunt testen.
Voordat je begint met het afsluiten van dingen, waarschuwt Ariel Parnes, COO van Mitiga: “Je moet kijken of je organisatie in het verleden al is gehackt met Log4j. De criminelen zijn misschien al binnen.” IT-manager John Cronin stelt de belangrijkste vragen: “Weet u welke van uw servers Log4j gebruiken? Hoe lang duurt het om een lijst van die servers te maken? Kun je ze in een oogwenk patchen? Heb je geautomatiseerde tools of moet iemand op elke server inloggen en dit handmatig doen? Heeft u een proces om live productieservers te patchen tijdens piekuren?” Het beantwoorden van die vragen zal ongetwijfeld enige moeite kosten. In een vorige post hebben we doorgenomen wat er nodig is om erachter te komen of je besmet bent.
Beveiligingsanalisten hebben exploits gevonden die teruggaan tot 1 december 2021, met behulp van een breed scala aan netwerkprotocollen, waaronder LDAP, RMI, DNS en HTTP. Deze exploits hebben een verscheidenheid aan malware geïnstalleerd, waaronder verborgen cryptocurrency-mijnwerkers, een nieuwe ransomware-familie die Bitdefender Khonsari noemt, en code om lid te worden van het Mirai-botnet. En als klap op de vuurpijl hebben verschillende onderzoekers exploits gemeld die afkomstig zijn van door de staat gesponsorde aanvallers in China, Noord-Korea, Turkije en Iran.
Uw eerste verdedigingslinie is om te upgraden naar de meest recente Log4j-versies. In eerste instantie bracht Apache een patch uit die nog kwetsbaarheden bleek te bevatten. De meest recente versies zijn Log4j v.2.17.0 , als u Java 8 of hoger gebruikt, en Log4j v.2.12.2 , als u Java 7 gebruikt in uw webapp-infrastructuur. Deze schakelen JNDI standaard uit en verwijderen de toegang tot het opzoeken van berichten, die beide de kern vormen van de verschillende kwetsbaarheden. Als u JNDI uitschakelt, kan er iets kapot gaan in uw apps, dus test dit zorgvuldig voordat u het in productiesystemen implementeert.
U kunt ook op Java gebaseerde logboekregistratie stoppen als u deze niet nodig hebt voor een van uw toepassingen. Nogmaals, test voordat u deze implementeert.
En degenen onder u die uw eigen Minecraft-server gebruiken, moeten controleren of Minecraft v.1.8.8 of hoger wordt uitgevoerd; deze versies zijn kwetsbaar. Microsoft heeft Minecraft v.1.18.1 uitgebracht, waarmee het probleem is opgelost. U moet onmiddellijk upgraden of een andere en betrouwbaardere server zoeken die is gerepareerd.
Beveiligingsleveranciers hebben overuren gemaakt om hun tools uit te breiden, en u moet profiteren van verschillende gratis aanbiedingen. Hieronder heb ik een aantal scanners opgesomd die kunnen worden gebruikt om de kwetsbare code in actieve toepassingen of bronbestanden te lokaliseren. U moet bepalen of die code in een productie-instantie is geïmplementeerd.
Begrijp eerst code-afhankelijkheden. Een van de uitdagingen van Log4j is zijn populariteit en opname in tal van Java-bibliotheken. Nadat u de oudere versies in uw eigen code hebt uitgeroeid, is het tijd om te onderzoeken wat u nog meer uitvoert, dat ervan afhangt. Als u de Apache-frameworks Struts2, Flume, Dubbo, Kafka, Solr, Druid of Fink gebruikt, moet u Log4j-bibliotheken binnen deze projecten upgraden. Als Struts een bekende opmerking maakt, leidde een exploit in 2017 tot het compromitteren van de databases van Equifax die privégegevens lekten van meer dan 140 miljoen klanten.
Bron: Infoworld | Categorie Java
