For et par uger siden vendte nyheden om sikkerhedsproblemerne i Log4j mange brugere på netværket på hovedet, og det er, at det er en af de fejl, der er blevet udnyttet mest, og som mange eksperter har stemplet som "den farligste i lang tid", af de sårbarheder, der blev afsløret på netværket, vi talte om nogle af dem. her på bloggen og ved denne lejlighed har vi fundet nyheden om en anden.
Og det er det for et par dage siden nyheden om, at en anden sårbarhed blev identificeret i Log4j 2-biblioteket (som allerede er opført under CVE-2021-45105), og som i modsætning til de to foregående udgaver blev klassificeret som farlig, men ikke kritisk.
det nye problem tillader et lammelsesangreb og manifesterer sig i form af loops og abends ved behandling af bestemte linjer.
Sårbarhed påvirker systemer, der bruger kontekstopslag, såsom ${ctx: var}, for at bestemme outputformatet for loggen.
den Log4j-versioner fra 2.0-alpha1 til 2.16.0 manglede beskyttelse mod løbsk rekursion, hvad tillod en angriber at manipulere den værdi, der blev brugt til substitution at forårsage en endeløs løkke, der ville løbe tør for stabelplads og få processen til at hænge. Især opstod problemet ved erstatning af værdier som "${${::-${::-$${::-j}}}}".
Derudover det kan bemærkes, at Blumira-forskere har foreslået et angreb på sårbare Java-applikationer som ikke accepterer anmodninger fra eksterne netværk, for eksempel udviklersystemer eller brugere af Java-applikationer, kan blive angrebet på denne måde.
Essensen af metoden er, at hvis der er sårbare Java-processer på brugerens system, der kun accepterer netværksforbindelser fra den lokale vært, eller behandler RMI-anmodninger (Remote Method Invocation, port 1099), angrebet kan udføres af udført JavaScript-kode når brugeren åbner en ondsindet side i browseren. For at etablere en forbindelse til netværksporten på en Java-applikation i et sådant angreb, bruges WebSocket API, som i modsætning til HTTP-anmodninger ikke gælder restriktioner med samme oprindelse (WebSocket kan også bruges til at scanne netværksporte på den lokale vært for at bestemme tilgængelige netværksdrivere).
Også af interesse er resultaterne af evalueringen af sårbarheden af bibliotekerne forbundet med afhængighederne med Log4j udgivet af Google. Ifølge Google påvirker problemet 8% af alle pakker i Maven Central-depotet.
Især 35863 Log4j-relaterede Java-pakker med direkte og indirekte afhængigheder blev udsat for sårbarheder. Til gengæld bruges Log4j som en direkte afhængighed af første niveau kun i 17% af tilfældene, og i 83% af de pakker, der er omfattet af sårbarheden, sker binding gennem mellempakker, der er afhængige af Log4j, dvs. afhængigheder af det andet og højeste niveau (21% - det andet niveau, 12% - det tredje, 14% - det fjerde, 26% - det femte, 6% - det sjette).
Tempoet med at rette sårbarheden lader stadig meget tilbage at ønske, en uge efter at sårbarheden blev identificeret, ud af 35863 identificerede pakker, er problemet indtil videre kun rettet i 4620, det vil sige på 13%.
Ændringerne af pakkerne er nødvendige for at opdatere afhængighedskrav og erstatte gamle versionsbindinger med faste versioner af Log4j 2 (Java-pakker praktiserer binding til en specifik version, ikke et åbent område, der tillader installation af den seneste version).
Elimineringen af sårbarheden i Java-applikationer hæmmes af, at programmer ofte medtager en kopi af bibliotekerne i leveringen, og det er ikke nok at opdatere Log4j 2-versionen i systempakkerne.
I mellemtiden udstedte US Cybersecurity and Infrastructure Protection Agency et nøddirektiv, der kræver, at føderale agenturer identificerer informationssystemer, der er påvirket af Log4j-sårbarheden, og installerer opdateringer, der blokerer problemet senest den 23. december.
Til gengæld blev der givet en retningslinje frem til den 28. december, hvor organisationerne havde pligt til at rapportere om det udførte arbejde. For at forenkle identifikationen af problematiske systemer er der udarbejdet en liste over produkter, hvor manifestationen af en sårbarhed er blevet bekræftet (der er mere end 23 tusinde ansøgninger på listen).
Endelig Det er værd at nævne, at sårbarheden blev rettet i Log4j 2.17, som blev offentliggjort for et par dage siden. og brugere, der har opdateringer deaktiveret, rådes til at opdatere i overensstemmelse hermed, plus faren for sårbarheden mindskes af det faktum, at problemet kun viser sig på systemer med Java 8.
kilde: https://logging.apache.org/