Det har skrivits mycket om Log4j-sårbarheten de senaste dagarna. Nedan har vi på Conscia gjort en uppdatering och rekommendationer för hur man kan åtgärda sårbarheten.
Hur ska vi åtgärda Log4j-sårbarheten?
- Skapa en tillgångslista; Vilka system som är tillgängliga från Internet eller andra osäkra zoner som gästnät och liknande.
Fråga dig själv – hur kan sårbarhet komma in i min verksamhet? - Finns det redan en patch tillgänglig för dina enheter? Få den installerad så snart som möjligt.
Se länkar till våra tillverkare nedan. Dessa listor innehåller pågående uppdateringar av system och produkter som antingen är sårbara, icke-sårbara eller under ytterligare utredning. - Om du inte redan gör det, aktivera full inloggning på din brandvägg, nätverk, servrar, applikationer och tjänster. Då kan vi se vad som har hänt, om du skulle ha sån otur att sårbarheten har utnyttjats.
- Granska aktivt dina loggar för Log4j-sårbarheten. Logghanteringssystem är lätta att söka och sårbarheten ses ända tillbaka till den 2 december.
Vad gör jag om en patch ännu inte finns för mina system?
Begränsa Internetåtkomst från dina servrar till nödvändiga resurser som licensiering, DNS och liknande. Du bör ange både källa och destination i dina brandväggsregler.
Tyvärr finns det många sätt att utnyttja sårbarheten, vilket beror mycket på det sårbara systemet. Om sårbarheten finns i en underliggande loggserver, till exempel en SIEM, kan den underliggande servern potentiellt ge åtkomst till din verksamhet, även om den inte är direkt exponerad mot Internet. Därför räcker det inte med att bara titta på alla tillgångar som är exponerade direkt mot internet.
Kom ihåg att kontrollera om din NGFW och proxy är uppdaterade med de senaste reglerna och att reglerna är i kraft. Se tidigare blogginlägg:
https://conscia.com/dk/nyheder/kritisk-saarbarhed-i-apache-log4j/
Har du ADC-lastbalansering framför dina externa publicerade tjänster och har trafiken dekrypterad på ADC-lagret? I så fall har du möjlighet att dra nytta av de inbyggda skyddsmekanismerna som applikationsbrandvägg och innehållsfiltrering, dessutom bör du också se till att du har nödvändig loggning aktiverad.
I ett antal scenarier kan det skydda mot Log4j-sårbarhet om de erbjudna tjänsterna ännu inte har patchats/säkrats. Det bör nämnas att det i vissa konfigurationer inte ger skydd. Vi hänvisar till leverantörernas publicerade artiklar här:
https://www.citrix.com/blogs/2021/12/13/guidance-for-reducing-apache-log4j-security-vulnerability-risk-with-citrix-waf/
https://blogs.vmware.com/load-balancing/2021/12/14/avi-waf-and-cve-2021-44228-apache-log4j-2/
Om du har frågor efter att ha läst artiklarna, kontakta gärna din Account Manager.
Använd alla dina vapen
Kom ihåg att använda alla vapen i din arsenal – Har du Stealthwatch, SIEM och Endpoint Protection som kan användas för att spåra och blockera all användning av Log4j? Använd den i så fall.
Hur tar vi reda på om vår utrustning är sårbar?
1. Kontrollera Conscias CNS. Om du har tillgång till Conscia Best Practice kan systemet tala om för dig om du är potentiellt sårbar. Manuell verifiering och analys kommer dock fortfarande att behövas.
2. Följ stegen nedan:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd#vp
https://unit42.paloaltonetworks.com/apache-log4j-vulnerability-cve-2021-44228/
https://aws.amazon.com/security/security-bulletins/AWS-2021-006/
https://www.vmware.com/security/advisories/VMSA-2021-0028.html
Vad har hänt sedan sist?
- Det börjar finnas ett antal olika tekniker för att dölja attackerna, inklusive att kringgå mönsterbaserade detektionsmekanismer, såsom IPS-regler. Tillverkare arbetar ständigt med att åtgärda dessa förändringar.
- Vi börjar se sårbarheten som försökt utnyttjas med SMTP. Tidigare har vi sett sårbarheten utnyttjas på LDAP (S), RMI, DNS, NIS, IIOP, CORBAL, NDS, HTTP.
- Log4j släpps i version 2.16.0. Du bör nog förvänta dig en hel del uppdateringar den kommande tiden, så alla kan tyvärr riskera att behöva patcha/uppdatera flera gånger.
Hur utnyttjas Log4j-sårbarheten?
Tyvärr finns det många attackvektorer på denna sårbarhet, inklusive några enkla exempel:
- En fråga skickas till en sårbar tillgång med (till exempel) en anpassad User-Agent, som innehåller följande sökväg $ {jndi: [protokoll]: // [fjärrserver och körbar kod]}
- Den sårbara enheten skapar en loggpost genom Log4j-ramverket med den anpassade User-Agenten
- Log4j läser den anpassade User-Agenten och skickar ett svar till fjärrservern.
Nedan följer ett enkelt exempel på ett Log4j-scenario:
Inklusive ett exempel från SMTP:
Källa: https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html
Andra källor:
https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html
https://conscia.com/dk/nyheder/kritisk-saarbarhed-i-apache-log4j/
Läs mer om Log4j här:
