I slutet av förra veckan så kom information om en allvarlig säkerhetsbugg i Log4j (ett bibliotek för loggning av Java). Vad vi såg var att denna bugg CVE-2021-44228 har fått en riktigt hög poäng på skalan som innebär att sannolikhet för exploitation är hög och att det är utförbart remote. Detta är en hackers våta dröm – hen kan köra vad som önskas på en webbserver varifrån som helst.
Conscia gick direkt ut med information till ett urval kunder att de bör hålla koll på och följa med. Det är versioner innan 2.15.0 som är sårbara, och denna release släpptes den nionde december, således kan man dra slutsatsen att det mesta man har som använder sig av biblioteket är påverkat. Log4j används för allt du kan tänka dig, från alla möjliga tillverkare, från spel som Minecraft till produkter och appliances från de flesta leverantörer vi har i nätverket. Indikationer och proof och concepts har visat på mycket aktiva exploateringsförsök. Många större aktörer på nätet, Microsoft, Cloudflare m.fl har redan börjat implementera skydd.
Hur skyddar man sig mot Log4j-buggen?
Naturligtvis behöver man först se över vad man har externt exponerat. Skyddar man sin trafik med en IPS (Intrusion Protection System, se brief om Conscia brandväggstjänst med IPS till höger) och sina endpoints med någon form av EDR/XDR så har de flest leverantörerna varit ganska snabba med att släppa signaturer som implementerar ett skydd (t.ex. Talos, med signaturuppsättningen Talos Rules 2021-12-10, som är de som skapar strömmar med signaturer åt Ciscos säkerhetsverktyg).
Efter att ha sett att man är skyddad med signaturer bör man se över hur man levererar applikationer. Normalt sker detta genom någon form av ADC (application delivery controller) eller RP (reverse proxy). I de fall där man terminerar SSL sessioner och får möjlighet att kontrollera trafiken med någon typ av WAF regler är även det en bra punkt för att mitigera. Tyärr har vi sett att det är rätt vanligt att man släpper igenom krypterad trafik utan att terminera och re-enkryptera och då är man utelämnad till ev endpointskydd man har på bakomliggande server. Har man tillgång till en SOC (Security Operations Center) som övervakar trafik och serveraktivitet aktivt är det värt att ha en genomgång med dem och sedan utföra en grundlig scanning i nätverket.
Ett kritiskt säkerhetshål du kan åtgärda
Buggen i sig är ganska lätt att mitigera, om man själv har kontroll på produkten, beroende på version genom att t.ex. sätta en environmentvariabel eller ta bort vissa klasser från sin classpath. Alternativt att använda sig av t.ex. Ciscos produkter för att säkra upp applikationer. Men vad gör man när man inte själv har kontroll på produkterna? T.ex. alla leverantörsspecifika produkter man kan ha? Dem kanske man inte bara kan gå in och modifiera. Sen kommer frågan hur allvarligt är det egentligen, det mycket kanske bara finns exponerat internt på nätet.
Det är en avvägningsfråga, rekommendationen är att patcha dessa system så fort det finns patchar att tillgå, men eftersom sådana bibliotek som Log4j används på olika sätt av olika produkter håller de flesta större leverantörer fortfarande på att gå igenom och utreda vilken påverkan detta har. Men redan nu bör man säkra upp servicefönster med verksamheten så att man är klar för att agera så fort det finns fixar publicerade.
Cisco-listan med Log4j-påverkade produkter:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd
Produkterna inkluderar Webex, ISE, NSO, vManage, Intersight m.fl. så det är värt att hålla koll. Cisco har själva fixat en del av sina Cloud-baserade tjänster såsom Umbrella, CloudLock, Duo, Thousandeyes och Webex meetings.
Sen är det värt att se över vad man har i molnet. Glöm inte bort att de som jobbar med Devops och har lite parallell infrastruktur uppe i molnet som ibland kan gå lite under radarn också behöver så över sina implementationer.
För mer information, se Talos advisory och Ciscos advisory:
https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd
Missa inte briefen om vår brandväggstjänst med IPS – och hör gärna av dig!
