Jonathan Greig Staff Writer
Jonathan Greig er journalist baseret i New York City.
Fuld bio den 6. januar 2022 | Emne: Sikkerhed
Sikkerhedsforskere fra JFrog sagde torsdag, at de opdagede en kritisk JNDI-baseret sårbarhed i H2-databasekonsollen, der udnyttede en rodårsag, der ligner Log4Shell. CVE er ikke blevet indsendt af NIST, men vil blive tildelt CVE-2021-42392.
I et blogindlæg sagde virksomheden, at CVE-2021-42392 ikke burde være så udbredt som Log4Shell, selvom det er et kritisk problem med en lignende rodårsag.
JFrog forklarede, at Java Naming and Directory Interface (JNDI) er en API, der giver navngivning og biblioteksfunktionalitet til Java-applikationer. H2 er en meget brugt open source Java SQL-database, der bruges til forskellige projekter lige fra webplatforme som Spring Boot til IoT-platforme som ThingWorks. Forskerne bemærkede, at com.h2database:h2-pakken er “en del af de 50 mest populære Maven-pakker med næsten 7.000 artefaktafhængigheder.”
Shachar Menashe, seniordirektør for JFrog sikkerhedsforskning, fortalte ZDNet, at i lighed med Log4Shell-sårbarheden, der blev afsløret i begyndelsen af december, kan angriberkontrollerede URL'er, der forplanter sig til JNDI-opslag, tillade uautoriseret fjernudførelse af kode, hvilket giver angribere enekontrol over driften af en anden person eller organisationens systemer.
Sikkerhedsfirmaet sagde, at CVE-2021-42392 til H2-databasekonsollen er det første kritiske problem, der er offentliggjort siden Log4Shell, på en anden komponent end Log4j, der udnytter den samme grundårsag til Log4Shell-sårbarheden, nemlig JNDI-fjernklasseindlæsning.
“Så vidt vi ved, er CVE-2021-42392 den første JNDI-relaterede uautentificerede RCE-sårbarhed, der er blevet offentliggjort siden Log4Shell, men vi formoder, at det ikke vil være den sidste,” skrev forskerne .
“En af vores vigtigste ting fra Log4Shell-sårbarhedshændelsen var, at på grund af den udbredte brug af JNDI, er der bundet til at være flere pakker, der er påvirket af den samme rodårsag som Log4Shell – at acceptere vilkårlige JNDI-opslags-URL'er. Således har vi justeret vores automatiske sårbarhedsdetektionsramme for at tage javax.naming.Context.lookup-funktionen i betragtning som en farlig funktion (sink) og frigivet rammen til Maven-lageret for forhåbentlig at finde problemer, der ligner Log4Shell.”
H2-databasepakken var en af de første, de validerede, og de rapporterede den til H2-vedligeholdere, som straks rettede den i en ny udgivelse og skabte en kritisk GitHub-advisory.
Ifølge JFrog passerer adskillige kodestier i H2-databaserammen ufiltreret i angriberkontrollerede URL'er til javax.naming.Context.lookup-funktionen, som de sagde tillader fjernindlæsning af kodebase. Af alle problemets angrebsvektorer er den mest alvorlige gennem H2-konsollen.
“Denne funktion kan påvirke dem, der kører en H2-databasekonsol udsat for netværket, og vi anbefaler at opdatere din H2-database til version 2.0.206 med det samme. Bemærk, at H2-databasen bruges af mange tredjepartsframeworks, inklusive Spring Boot, Play Framework og JHipster,” sagde Menashe.
“Selvom denne sårbarhed ikke er så udbredt som Log4Shell, kan den stadig have en dramatisk indvirkning på udviklere og produktionssystemer, hvis den ikke behandles i overensstemmelse hermed.”
Rapporten bemærker, at fordi H2 databasen bruges af så mange artefakter, at det er svært for dem at kvantificere, hvor mange sårbare implementeringer af H2-konsollen der findes i naturen. JFrog forklarede også flere andre angrebsvektorer, der bruger den samme sårbarhed.
JFrog foreslog brugere at opgradere deres H2-database til den nyeste version. De bemærkede, at de har set en række udviklerværktøjer, “at stole på H2-databasen og specifikt afsløre H2-konsollen.”
“Hvis du kører en H2-konsol, som er udsat for dit LAN (eller værre, WAN), er dette problem ekstremt kritisk (uautentificeret fjernudførelse af kode), og du bør opdatere din H2-database til version 2.0.206 med det samme,” sagde virksomheden. “Netværksadministratorer kan scanne deres lokale undernet for åbne forekomster af H2-konsollen med nmap. Det er højst sandsynligt, at alle returnerede servere kan udnyttes.”
Ifølge forskerne ligner version 2.0.206 Log4j 2.17 .0 fordi det løser problemet ved at begrænse JNDI-URL'er til kun at bruge den (lokale) java-protokol, hvilket afviser enhver ekstern LDAP/RMI-forespørgsel.
JFrog leverede også adskillige afhjælpningsmuligheder for dem, der ikke kan opgradere H2.
Matthew Warner, CTO hos Blumira, fortalte ZDNet, at der ifølge OSINT sandsynligvis er under 100 påvirkede servere på internettet, fordi H2 Database Console målrettet skal eksponeres for internettet ved at ændre konfigurationen til ikke kun at lytte på localhost.
“Selvom denne sårbarhed også bruger ekstern JNDI-klasseindlæsning, kræver den adgang, der ikke er tilgængelig med standardkonfigurationen af H2-databasen,” sagde Warner.
BreachQuest CTO Jake Williams sagde, at udbredt udnyttelse er usandsynlig, fordi denne sårbarhed er i en applikation i modsætning til et bibliotek som log4j, hvilket betyder, at sårbare systemer burde være meget nemmere at opdage og afhjælpe.
I en standardkonfiguration kan sårbarheden kun udløses fra den samme maskine, som databasekonsollen kører på, hvilket betyder, at udnyttelse er ekstremt betinget.
“Det er usandsynligt, at dette vil forårsage omfattende skade, selvom sårbarhedsadministratorer burde være klar til at lappe andre nyopdagede JNDI-sårbarheder, efterhånden som de afsløres,” sagde Williams. “Det er klart, at denne sårbarhed ikke vil være den sidste opdagede, der er relateret til log4j.”
Andre, som NTT Application Securitys Ray Kelly, sagde, at selvom udnyttelse var usandsynlig, brugte en mashup af SQL og JNDI at udnytte en RCE-sårbarhed “er ret kreativt og glimrende eksempel på, hvordan et enkelt problem kan misbruges på flere måder.”
Forskningen er også umagen værd, fordi selvom log4j havde specifikke kodningsfejl, der resulterede i Log4Shell, er den bredere idé om manglende validering på JNDI-opslag, der fører til sårbarheder, en generel angrebsvej, som sandsynligvis eksisterer andre steder, og givet log4j-sårbarhederne var' t opdaget før, har sandsynligvis ikke været genstand for rettet undersøgelse, ifølge Bugcrowd CTO Casey Ellis.
“Dette er et klassisk eksempel på 'research clustering', som er et fænomen, som Bugcrowd har observeret mange gange før, og et vi forudsagde efter den første udgivelse af Log4Shell,” sagde Ellis.
“Nogle forskerhold har valgt at udnytte en følelse af panik for at få deres budskab derud, mens JFrog-folkene ser ud til at have været meget omhyggelige med at få deres budskab igennem, men ikke forårsage unødigt arbejde for allerede overbelastede sikkerhedsteams.”
Sikkerhed
De største databrud, hacks i 2021 Copycat og fad-hackere vil være forsyningskædesikkerhedens forbandelse i 2022 Sikkerhed vil være prioritet #1 for Linux og open source-udviklere i år De 5 bedste VPN-tjenester i 2022 Security TV | Datastyring | CXO | Datacentre