Liam Tung er en australsk forretningsteknologijournalist som bor noen for mange svenske mil nord for Stockholm for hans smak. Han tok en bachelorgrad i økonomi og kunst (kulturstudier) ved Sydneys Macquarie University, men hacket seg (uten norrønt eller ondsinnet kode for den saks skyld) seg inn i en karriere som enterprise tech-, sikkerhets- og telekommunikasjonsjournalist hos ZDNet Australia.
Full bio 13. desember 2021 | Emne: Sikkerhet 
En feil i Log4j, et Java-bibliotek for logging av feilmeldinger i applikasjoner, er den mest høy- profil sikkerhetssårbarhet på internett akkurat nå og kommer med en alvorlighetsgrad på 10 av 10.
Biblioteket er utviklet av åpen kildekode Apache Software Foundation og er et nøkkelrammeverk for Java-logging. Siden forrige ukes varsling fra CERT New Zealand om at CVE-2021-44228, en feil ved ekstern kodeutførelse i Log4j, allerede ble utnyttet i naturen, har advarsler blitt utstedt av flere nasjonale cybersikkerhetsbyråer, inkludert Cybersecurity and Infrastructure Security Agency (CISA). ) og Storbritannias nasjonale cybersikkerhetssenter (NCSC). Internett-infrastrukturleverandøren Cloudflare sa at Log4j-utnyttelsene startet 1. desember.
Hvilke enheter og applikasjoner er i faresonen?
I utgangspunktet er enhver enhet som er eksponert for internett i fare hvis den kjører Apache Log4J, versjon 2.0 til 2.14.1. NCSC bemerker at Log4j versjon 2 (Log4j2), den berørte versjonen, er inkludert i Apache Struts2, Solr, Druid, Flink og Swift-rammeverk.
Mirai, et botnett som retter seg mot alle slags Internett-tilkoblede (IoT) enheter, har tatt i bruk en utnyttelse for feilen. Cisco og VMware har gitt ut oppdateringer for deres berørte produkter.
Log4j-feildekning – det du trenger å vite nå
Log4j-feil: Angripere gjør tusenvis av forsøk på å utnytte denne alvorlige sårbarheten
Sikkerhetsadvarsel: Ny nulldag i Log4j Java-biblioteket blir allerede utnyttet
Log4j RCE-aktivitet begynte 1. desember ettersom botnett begynner å bruke sårbarhet
AWS har detaljert hvordan feilen påvirker tjenestene og sa at den fungerer på å lappe tjenestene sine som bruker Log4j og har gitt ut avbøtende tiltak for tjenester som CloudFront.
På samme måte sa IBM at de “aktivt reagerer” på Log4j-sårbarheten på tvers av IBMs egen infrastruktur og dens produkter. IBM har bekreftet at Websphere 8.5 og 9.0 er sårbare.
Oracle har også utstedt en oppdatering for feilen.
“På grunn av alvorlighetsgraden av dette sikkerhetsproblemet og publisering av utnyttelseskode på ulike nettsteder, anbefaler Oracle sterkt at kunder tar i bruk oppdateringene fra dette sikkerhetsvarselet så snart som mulig,” heter det.
Nødvendige handlinger: Device discovery and patching
CISAs hovedråd er å identifisere internettvendte enheter som kjører Log4j og oppgradere dem til versjon 2.15.0, eller å ta i bruk begrensningene gitt av leverandørene “umiddelbart”. Men den anbefaler også å sette opp varsler for sonder eller angrep på enheter som kjører Log4j.
“For å være tydelig, utgjør denne sårbarheten en alvorlig risiko,” sa CISA-direktør Jen Easterly søndag. “Vi vil bare minimere potensielle påvirkninger gjennom samarbeid mellom myndigheter og privat sektor. Vi oppfordrer alle organisasjoner til å bli med oss i denne viktige innsatsen og ta grep.”
Ytterligere trinn anbefalt av CISA inkluderer: oppregning av eksterne enheter med Log4j installert; sikre at sikkerhetsoperasjonssenteret utfører hvert varsel med Log4j installert; og installere en nettapplikasjonsbrannmur (WAF) med regler for å fokusere på Log4j.
AWS har oppdatert sitt WAF-regelsett – AWSManagedRulesKnownBadInputsRuleSet AMR – for å oppdage og redusere Log4j-angrepsforsøk og skanning. Den har også reduksjonsalternativer som kan aktiveres for CloudFront, Application Load Balancer (ALB), API Gateway og AppSync. Den oppdaterer også for øyeblikket all Amazon OpenSearch Service til den oppdateringsversjonen av Log4j.
SE: En vinnende strategi for cybersikkerhet (ZDNet spesialrapport)
NCSC anbefaler å oppdatere til versjon 2.15.0 eller nyere, og – der det ikke er mulig – å redusere feilen i Log4j 2.10 og senere ved å sette systemegenskapen “log4j2.formatMsgNoLookups” til “true” eller fjerne JndiLookup-klassen fra klassebanen.
En del av utfordringen vil være å identifisere programvare som inneholder Log4j-sårbarheten. Nederland's National Cyber Security Centrum (NCSC) har lagt ut en omfattende og hentet A-Z-liste på GitHub over alle berørte produkter den er klar over enten er sårbare, ikke sårbare, er under etterforskning, eller hvor en løsning er tilgjengelig. Listen over produkter illustrerer hvor utbredt sårbarheten er, og spenner over skytjenester, utviklertjenester, sikkerhetsenheter, karttjenester og mer.
Leverandører med populære produkter kjent for å være fortsatt sårbare inkluderer Atlassian, Amazon, Microsoft Azure, Cisco, Commvault, ESRI, Exact, Fortinet, JetBrains, Nelson, Nutanix, OpenMRS, Oracle, Red Hat, Splunk, Soft , og VMware. Listen er enda lengre når du legger til produkter der en patch er utgitt.
NCCGroup har lagt ut flere nettverksdeteksjonsregler for å oppdage utnyttelsesforsøk og indikatorer på vellykket utnyttelse.
Endelig har Microsoft gitt ut sitt sett med indikatorer for kompromiss og veiledning for å forhindre angrep på Log4j-sårbarhet. Eksempler på etterutnyttelsen av feilen som Microsoft har sett inkluderer installasjon av myntgruvearbeidere, Cobalt Strike for å muliggjøre legitimasjonstyveri og sideveis bevegelse, og eksfiltrering av data fra kompromitterte systemer.
Sikkerhet
Log4j-feil: Angripere gjør tusenvis av forsøk på å utnytte denne sårbarheten. Alle er utbrent. Det begynner å bli et sikkerhetsmareritt. De beste VPN-ene for små og hjemmebaserte bedrifter i 2021. Sjefene er motvillige til å bruke penger på nettsikkerhet. Så blir de hacket. Truffet av løsepengeprogramvare? Ikke gjør denne første åpenbare feilen Security TV | Databehandling | CXO | Datasentre