Under de sista dagarna på nätet har det pratats mycket om sårbarheten i Log4j där olika attackvektorer har upptäckts och olika funktionella exploater också har filtrerats för att utnyttja sårbarheten.
Allvaret i saken är att detta är ett populärt ramverk för att organisera registret i Java-applikationer., som tillåter att godtycklig kod exekveras när ett speciellt formaterat värde skrivs till registret i formatet "{jndi: URL}". Attacken kan utföras på Java-applikationer som loggar värden som erhållits från externa källor, till exempel genom att visa problematiska värden i felmeddelanden.
Och det en angripare gör en HTTP-begäran på ett målsystem, som genererar en logg med Log4j 2 Som använder JNDI för att göra en begäran till den angriparkontrollerade webbplatsen. Sårbarheten får sedan den utnyttjade processen att anlända till platsen och exekvera nyttolasten. I många observerade attacker är parametern som tillhör angriparen ett DNS-registreringssystem, avsett att registrera en begäran på webbplatsen för att identifiera sårbara system.
Som vår kollega Isaac redan delat:
Denna sårbarhet hos Log4j gör det möjligt att utnyttja en felaktig indatavalidering till LDAP, vilket tillåter fjärrkörning av kod (RCE), och äventyra servern (sekretess, dataintegritet och systemtillgänglighet). Dessutom ligger problemet eller vikten av denna sårbarhet i antalet applikationer och servrar som använder den, inklusive affärsprogram och molntjänster som Apple iCloud, Steam eller populära videospel som Minecraft: Java Edition, Twitter, Cloudflare, Tencent , ElasticSearch, Redis, Elastic Logstash och en lång etc.
På tal om saken, nyligen Apache Software Foundation släpptes genom ett inlägg en sammanfattning av projekt som tar itu med en kritisk sårbarhet i Log4j 2 vilket gör att godtycklig kod kan köras på servern.
Följande Apache-projekt påverkas: Archiva, Druid, EventMesh, Flink, Fortress, Geode, Hive, JMeter, Jena, JSPWiki, OFBiz, Ozone, SkyWalking, Solr, Struts, TrafficControl och Calcite Avatica. Sårbarheten påverkade också GitHub-produkter, inklusive GitHub.com, GitHub Enterprise Cloud och GitHub Enterprise Server.
De senaste dagarna har det skett en betydande ökning av aktiviteten relaterad till exploatering av sårbarhet. Till exempel, Check Point loggade in cirka 100 exploateringsförsök per minut på sina fiktiva servrar sin topp, och Sophos tillkännagav upptäckten av ett nytt botnät för gruvdrift för kryptovaluta, bildat av system med en oparpad sårbarhet i Log4j 2.
Angående informationen som har släppts om problemet:
- Sårbarheten har bekräftats i många officiella Docker-bilder, inklusive couchbase, elasticsearch, flink, solr, stormbilder, etc.
- Sårbarheten finns i produkten MongoDB Atlas Search.
- Problemet förekommer i en mängd olika Cisco-produkter, inklusive Cisco Webex Meetings Server, Cisco CX Cloud Agent, Cisco
- Avancerad webbsäkerhetsrapportering, Cisco Firepower Threat Defense (FTD), Cisco Identity Services Engine (ISE), Cisco CloudCenter, Cisco DNA Center, Cisco. BroadWorks, etc.
- Problemet finns i IBM WebSphere Application Server och i följande Red Hat-produkter: OpenShift, OpenShift Logging, OpenStack Platform, Integration Camel, CodeReady Studio, Data Grid, Fuse och AMQ Streams.
- Bekräftat problem i Junos Space Network Management Platform, Northstar Controller / Planner, Paragon Insights / Pathfinder / Planner.
- Många produkter från Oracle, vmWare, Broadcom och Amazon påverkas också.
Apache-projekt som inte påverkas av Log4j 2-sårbarheten: Apache Iceberg, Guacamole, Hadoop, Log4Net, Spark, Tomcat, ZooKeeper och CloudStack.
Användare av problematiska paket rekommenderas att omedelbart installera de släppta uppdateringarna för dem, uppdatera versionen av Log4j 2 separat eller ställ in parametern Log4j2.formatMsgNoLookups till true (till exempel lägg till nyckeln "-DLog4j2.formatMsgNoLookup = True" vid start).
För att låsa systemet är sårbart som det inte finns någon direkt åtkomst till, det föreslogs att man skulle utnyttja Logout4Shell-vaccinet, som genom att utföra en attack avslöjar Java-inställningen "log4j2.formatMsgNoLookups = true", "com.sun.jndi .rmi.objekt. trustURLCodebase = false "och" com.sun.jndi.cosnaming.object.trustURLCodebase = false "för att blockera ytterligare manifestationer av sårbarheten på okontrollerade system.