Jen Easterly, directeur van CISA zegt dat Log4j de ergste is die ze ooit heeft gezien en dat ze nog jaren zullen draaien

log4j

De directeur van CISA, Jen Easterly zegt dat de beveiligingsfout van Log4j de ergste is die ze ooit heeft gezien in zijn carriere en beveiligingsprofessionals zullen de gevolgen onder ogen zien van een fout voor een lange tijd.

Indien niet gepatcht de belangrijkste beveiligingsfout die een maand geleden werd ontdekt in de Java Apache Log4j-logboekbibliotheek brengt risico's met zich mee voor grote sectoren van het internet, hackers zouden de kwetsbaarheid van veelgebruikte software kunnen misbruiken om computerservers over te nemen, waardoor alles, van consumentenelektronica tot overheids- en bedrijfssystemen, het risico loopt op een cyberaanval.

Op 9 december werd het ontdekt een kwetsbaarheid in de logboekbibliotheek van Apache log4j. Deze bibliotheek wordt veel gebruikt in Java / J2EE-toepassingsontwikkelingsprojecten, evenals door leveranciers van standaard op Java / J2EE gebaseerde softwareoplossingen.

Log4j bevat een zoekmechanisme dat kan worden gebruikt om te zoeken via speciale syntaxis in een opmaakreeks. Standaard worden alle verzoeken gedaan met het voorvoegsel java: comp / env / *; Desalniettemin, de auteurs hebben de optie geïmplementeerd om een ​​aangepast voorvoegsel te gebruiken met behulp van een dubbele punt in de sleutel. Dit is waar de kwetsbaarheid ligt: ​​als jndi: ldap: // als sleutel wordt gebruikt, gaat het verzoek naar de opgegeven LDAP-server. Andere communicatieprotocollen zoals LDAPS, DNS en RMI kunnen ook worden gebruikt.

Daarom een externe server die door een aanvaller wordt bestuurd, kan een object terugsturen naar een kwetsbare server, wat kan leiden tot het uitvoeren van willekeurige code op het systeem of het lekken van vertrouwelijke gegevens. Het enige wat een aanvaller hoeft te doen, is een speciale string door het mechanisme sturen dat deze string naar een logbestand schrijft en daarom wordt beheerd door de Log4j-bibliotheek.

Dit kan worden gedaan met eenvoudige HTTP-verzoeken, bijvoorbeeld verzoeken die worden verzonden via webformulieren, gegevensvelden, enz., of met elk ander type interactie met behulp van het server-side register.

  • Versie 2.15.0 loste geen ander probleem op, CVE-2021-45046, waardoor een aanvaller op afstand de Thread Context Map (MDC) kon besturen om een ​​kwaadaardig item voor te bereiden met behulp van een JNDI-zoekpatroon. Het resultaat kan het uitvoeren van externe code zijn, gelukkig niet in alle omgevingen.
  • Versie 2.16.0 loste dit probleem op. Maar het loste CVE-2021-45105 niet op, dat door Apache Software Foundation als volgt wordt beschreven:

“Apache Log2.0j1 versies 2.16.0-alpha4 tot 2 beschermden niet tegen ongecontroleerde herhaling van zelfreferentiële zoekopdrachten. Wanneer de registerconfiguratie een andere sjabloonlay-out gebruikt dan de standaardindeling met een contextzoekopdracht (bijvoorbeeld $$ {ctx: loginId}), kunnen aanvallers die de invoergegevens van Thread Context Map (MDC) beheren inloggegevens maken. . , die een StackOverflowError genereert die het proces beëindigt. Dit wordt ook wel een denial of service (DOS)-aanval genoemd.

Het leveranciersonafhankelijke bug bounty-programma, Zero Day Initiative, beschreef de fout als volgt:

“Wanneer een geneste variabele wordt vervangen door de StrSubstitutor-klasse, roept deze recursief de substitutieklasse (). Wanneer de geneste variabele echter verwijst naar de variabele die moet worden vervangen, wordt recursie aangeroepen met dezelfde tekenreeks. Dit leidt tot oneindige recursie en een DoS-voorwaarde op de server”.

Een andere kritieke fout bij het uitvoeren van externe code wordt nu bijgehouden als CVE-2021-44832 werd ontdekt in dezelfde Apache Log4j-logboekbibliotheek. Dit is de vierde kwetsbaarheid in de Log4j-bibliotheek.

De kwetsbaarheid is als "matig" beoordeeld met een score van 6,6 op de CVSS-schaal en komt voort uit het ontbreken van aanvullende controles over JDNI-toegang in log4j.

Apache-beveiligingsteam heeft een andere versie van Apache Log4J uitgebracht (versie 2.17.1) die de recent ontdekte bug voor het uitvoeren van externe code CVE-2021-44832 verhelpt. Dit is een andere slechte situatie voor de meeste gebruikers, maar nogmaals, het wordt ten zeerste aanbevolen om uw systeem bij te werken om dit kritieke probleem op te lossen.

Geen enkel Amerikaans federaal agentschap is gecompromitteerd vanwege de kwetsbaarheid, vertelde Jen Easterly in een oproep aan verslaggevers. Bovendien zijn er in de Verenigde Staten geen grote cyberaanvallen gemeld die verband houden met de bug, hoewel veel aanvallen niet worden gemeld, zei hij.

Easterly zei de omvang van de kwetsbaarheid, met gevolgen voor tientallen miljoenen apparaten die met internet zijn verbonden, maakt het de slechtste die hij ooit in zijn carrière heeft gezien. Aanvallers kunnen hun tijd afwachten, zei hij, terwijl ze wachten tot bedrijven en anderen hun verdediging verlagen voordat ze aanvallen.

"We hopen dat Log4Shell in de toekomst zal worden gebruikt voor inbraken", zei Easterly. Hij merkte op dat het datalek bij Equifax in 2017, waarbij de persoonlijke informatie van bijna 150 miljoen Amerikanen in gevaar kwam, te wijten was aan een kwetsbaarheid in open source software.

Tot nu toe waren de meeste pogingen om de bug te misbruiken gericht op cryptocurrency-mining op laag niveau of pogingen om apparaten naar botnets te lokken, zei hij.

bron: https://www.cnet.com


Laat je reactie achter

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *

*

*

  1. Verantwoordelijk voor de gegevens: AB Internet Networks 2008 SL
  2. Doel van de gegevens: Controle SPAM, commentaarbeheer.
  3. Legitimatie: uw toestemming
  4. Mededeling van de gegevens: De gegevens worden niet aan derden meegedeeld, behalve op grond van wettelijke verplichting.
  5. Gegevensopslag: database gehost door Occentus Networks (EU)
  6. Rechten: u kunt uw gegevens op elk moment beperken, herstellen en verwijderen.

  1.   Luix zei

    Het komt door overengineering. Elk onderdeel moet maar één ding doen en het goed doen. Maar de ontwikkelaars hebben de slechte gewoonte om lagen en meer lagen en onnodige functionaliteiten te plaatsen, wat het niet complexer en vatbaarder maakt voor dit soort fouten... Ik heb gezegd...