Jonathan Greig Staff Writer
Jonathan Greig er journalist basert i New York City.
Full Bio 6. januar 2022 | Emne: Sikkerhet
Sikkerhetsforskere fra JFrog sa torsdag at de oppdaget en kritisk JNDI-basert sårbarhet i H2-databasekonsollen som utnytter en rotårsak som ligner på Log4Shell. CVE-en er ikke lagt ut av NIST, men vil bli tildelt CVE-2021-42392.
I et blogginnlegg sa selskapet at CVE-2021-42392 ikke burde være like utbredt som Log4Shell selv om det er et kritisk problem med en lignende grunnårsak.
JFrog forklarte at Java Naming and Directory Interface (JNDI) er et API som gir navngivning og katalogfunksjonalitet for Java-applikasjoner. H2 er en mye brukt åpen kildekode Java SQL-database som brukes til ulike prosjekter, alt fra nettplattformer som Spring Boot til IoT-plattformer som ThingWorks. Forskerne bemerket at com.h2database:h2-pakken er “en del av de 50 mest populære Maven-pakkene, med nesten 7000 artefaktavhengigheter.”
Shachar Menashe, seniordirektør for JFrog sikkerhetsforskning, fortalte ZDNet at i likhet med Log4Shell-sårbarheten som ble avdekket tidlig i desember, kan angriperkontrollerte URL-er som forplanter seg til JNDI-oppslag tillate uautentisert ekstern kjøring av kode, og gi angripere enekontroll over driften til en annen person eller organisasjonens systemer.
Sikkerhetsselskapet sa at CVE-2021-42392 for H2-databasekonsollen er det første kritiske problemet publisert siden Log4Shell, på en annen komponent enn Log4j, som utnytter den samme grunnårsaken til Log4Shell-sårbarheten, nemlig JNDI ekstern klasselasting.
“Så vidt vi vet, er CVE-2021-42392 den første JNDI-relaterte uautentiserte RCE-sårbarheten som er publisert siden Log4Shell, men vi mistenker at det ikke vil være den siste,” skrev forskerne .
“Et av de viktigste tipsene våre fra Log4Shell-sårbarhetshendelsen var at på grunn av den utbredte bruken av JNDI, er det garantert flere pakker som er berørt av samme grunnårsak som Log4Shell – som aksepterer vilkårlige JNDI-oppslags-URLer. Dermed har vi justert vårt automatiske rammeverk for sårbarhetsdeteksjon for å ta hensyn til javax.naming.Context.lookup-funksjonen som en farlig funksjon (sink) og sluppet løs rammeverket til Maven-depotet for å forhåpentligvis finne problemer som ligner på Log4Shell.»
H2-databasepakken var en av de første de validerte, og de rapporterte den til H2-vedlikeholdere som umiddelbart fikset den i en ny utgivelse, og skapte en kritisk GitHub-rådgivning.
Ifølge JFrog passerer flere kodestier i H2-databaserammeverket ufiltrert i angriperkontrollerte URL-er til javax.naming.Context.lookup-funksjonen, som de sa tillater ekstern lasting av kodebase. Av alle angrepsvektorene til problemet er den mest alvorlige gjennom H2-konsollen.
“Denne funksjonen kan påvirke de som kjører en H2-databasekonsoll som er utsatt for nettverket, og vi anbefaler å oppdatere H2-databasen til versjon 2.0.206 umiddelbart. Merk at H2-databasen brukes av mange tredjeparts rammeverk, inkludert Spring Boot, Play Framework og JHipster,” sa Menashe.
“Selv om denne sårbarheten ikke er like utbredt som Log4Shell, kan den fortsatt ha en dramatisk innvirkning på utviklere og produksjonssystemer hvis den ikke behandles deretter.”
Rapporten bemerker at fordi H2 databasen brukes av så mange artefakter at det er vanskelig for dem å kvantifisere hvor mange sårbare distribusjoner av H2-konsollen som finnes i naturen. JFrog forklarte også flere andre angrepsvektorer som bruker samme sårbarhet.
JFrog foreslo brukere å oppgradere H2-databasen sin til den nyeste versjonen. De bemerket at de har sett en rekke utviklerverktøy “som stoler på H2-databasen og spesifikt eksponerer H2-konsollen.”
“Hvis du kjører en H2-konsoll som er utsatt for ditt LAN (eller enda verre, WAN) er dette problemet ekstremt kritisk (uautentisert ekstern kjøring av kode), og du bør oppdatere H2-databasen til versjon 2.0.206 umiddelbart,” sa selskapet. “Nettverksadministratorer kan skanne sine lokale undernett for åpne forekomster av H2-konsollen med nmap. Eventuelle returnerte servere vil sannsynligvis kunne utnyttes.”
I følge forskerne ligner versjon 2.0.206 på Log4j 2.17 .0 fordi den løser problemet ved å begrense JNDI-URL-er til kun å bruke den (lokale) java-protokollen, som nekter alle eksterne LDAP/RMI-spørringer.
JFrog ga også flere avbøtende alternativer for de som ikke kan oppgradere H2.
Matthew Warner, CTO hos Blumira, fortalte ZDNet at ifølge OSINT er det sannsynligvis under 100 berørte servere på internett fordi H2 Database Console må eksponeres målrettet mot internett ved å endre konfigurasjonen til ikke bare å lytte på localhost.
“Selv om denne sårbarheten også bruker ekstern JNDI-klasselasting, krever den tilgang som ikke er tilgjengelig med standardkonfigurasjonen til H2-databasen,” sa Warner.
BreachQuest CTO Jake Williams sa at utbredt utnyttelse er usannsynlig fordi denne sårbarheten er i en applikasjon i motsetning til et bibliotek som log4j, noe som betyr at sårbare systemer bør være mye lettere å oppdage og utbedre.
I en standardkonfigurasjon kan sårbarheten bare utløses fra den samme maskinen som databasekonsollen kjører på, noe som betyr at utnyttelse er ekstremt betinget.
“Det er usannsynlig at dette vil forårsake omfattende skade, selv om sårbarhetsledere bør være klare til å lappe andre nylig oppdagede JNDI-sårbarheter etter hvert som de avsløres,” sa Williams. «Det er klart at denne sårbarheten ikke vil være den siste oppdaget som er relatert til log4j.»
Andre, som NTT Application Securitys Ray Kelly, sa at selv om utnyttelse var usannsynlig, brukte en mashup av SQL og JNDI å utnytte en RCE-sårbarhet “er ganske kreativt og utmerket eksempel på hvordan et enkelt problem kan misbrukes på flere måter.”
Forskningen er også verdt fordi selv om log4j hadde spesifikke kodefeil som resulterte i Log4Shell, er den bredere ideen om mangel på validering på JNDI-oppslag som fører til sårbarheter en generell angrepsvei som sannsynligvis vil eksistere andre steder, og gitt log4j-sårbarhetene var t oppdaget tidligere, har sannsynligvis ikke vært gjenstand for rettet gransking, ifølge Bugcrowd CTO Casey Ellis.
“Dette er et klassisk eksempel på 'forskningsklynger' som er et fenomen som Bugcrowd har observert mange ganger før og et vi spådde etter den første publiseringen av Log4Shell,” sa Ellis.
“Noen forskerteam har valgt å utnytte en følelse av panikk for å få ut budskapet sitt, mens JFrog-folket ser ut til å ha passet godt på å formidle budskapet sitt, men ikke forårsake unødig arbeid for allerede overbelastede sikkerhetsteam.”
Sikkerhet
De største datainnbruddene, hackingene i 2021 Copycat og kjepphackere vil være leverandørkjedesikkerhetens forbannelse i 2022 Sikkerhet vil være prioritet #1 for Linux og åpen kildekode-utviklere i år De 5 beste VPN-tjenestene i 2022 Security TV | Databehandling | CXO | Datasentre