Jonathan Greig Staff Writer
Jonathan Greig är journalist baserad i New York City.
Fullständig bio den 6 januari 2022 | Ämne: Säkerhet
Säkerhetsforskare från JFrog sa på torsdagen att de upptäckt en kritisk JNDI-baserad sårbarhet i H2-databaskonsolen som utnyttjar en rotorsak som liknar Log4Shell. CVE har inte lagts upp av NIST men kommer att tilldelas CVE-2021-42392.
I ett blogginlägg sa företaget att CVE-2021-42392 inte borde vara lika utbredd som Log4Shell även om det är ett kritiskt problem med en liknande grundorsak.
JFrog förklarade att Java Naming and Directory Interface (JNDI) är ett API som tillhandahåller namngivning och katalogfunktioner för Java-applikationer. H2 är en allmänt använd Java SQL-databas med öppen källkod som används för olika projekt, från webbplattformar som Spring Boot till IoT-plattformar som ThingWorks. Forskarna noterade att com.h2database:h2-paketet är “en del av de 50 mest populära Maven-paketen, med nästan 7 000 artefaktberoenden.”
Shachar Menashe, senior chef för JFrog säkerhetsforskning, berättade för ZDNet att i likhet med Log4Shell-sårbarheten som upptäcktes i början av december, kan angriparkontrollerade webbadresser som sprids till JNDI-uppslagningar tillåta oautentiserad fjärrkörning av kod, vilket ger angripare ensam kontroll över driften av en annan person eller organisationens system.
Säkerhetsföretaget sa att CVE-2021-42392 för H2-databaskonsolen är det första kritiska problemet som publicerats sedan Log4Shell, på en annan komponent än Log4j, som utnyttjar samma grundorsak till Log4Shell-sårbarheten, nämligen JNDI-fjärrklassladdning.
“Såvitt vi vet är CVE-2021-42392 den första JNDI-relaterade oautentiserade RCE-sårbarheten som har publicerats sedan Log4Shell, men vi misstänker att det inte kommer att vara den sista”, skrev forskarna .
“En av våra viktigaste aspekter av Log4Shell-sårbarhetsincidenten var att på grund av den utbredda användningen av JNDI, finns det oundvikligen fler paket som påverkas av samma grundorsak som Log4Shell – som accepterar godtyckliga JNDI-uppslagsadresser. Därför har vi har justerat vårt automatiska ramverk för upptäckt av sårbarheter för att ta hänsyn till javax.naming.Context.lookup-funktionen som en farlig funktion (sink) och släppte lös ramverket till Maven-förvaret för att förhoppningsvis hitta problem som liknar Log4Shell.”
H2-databaspaketet var ett av de första de validerade och de rapporterade det till H2-underhållare som omedelbart fixade det i en ny version och skapade en kritisk GitHub-rådgivning.
Enligt JFrog passerar flera kodsökvägar i H2-databasramverket ofiltrerat i angriparkontrollerade URL:er till javax.naming.Context.lookup-funktionen, som de sa tillåter fjärrladdning av kodbas. Av alla attackvektorer i problemet är den allvarligaste genom H2-konsolen.
“Denna funktion kan påverka de som kör en H2-databaskonsol som exponeras för nätverket och vi rekommenderar att du uppdaterar din H2-databas till version 2.0.206 omedelbart. Observera att H2-databasen används av många tredjepartsramverk, inklusive Spring Boot, Play Framework och JHipster,” sa Menashe.
“Även om den här sårbarheten inte är lika utbredd som Log4Shell, kan den fortfarande ha en dramatisk inverkan på utvecklare och produktionssystem om de inte åtgärdas i enlighet därmed.”
Rapporten noterar att eftersom H2 databasen används av så många artefakter att det är svårt för dem att kvantifiera hur många sårbara distributioner av H2-konsolen som finns i naturen. JFrog förklarade också flera andra attackvektorer med samma sårbarhet.
JFrog föreslog användare att uppgradera sin H2-databas till den senaste versionen. De noterade att de har sett ett antal utvecklarverktyg “som förlitar sig på H2-databasen och specifikt exponerar H2-konsolen.”
“Om du kör en H2-konsol som är exponerad för ditt LAN (eller ännu värre, WAN) är det här problemet extremt kritiskt (oautentiserad fjärrkörning av kod) och du bör uppdatera din H2-databas till version 2.0.206 omedelbart”, sa företaget. “Nätverksadministratörer kan skanna sina lokala undernät efter öppna instanser av H2-konsolen med nmap. Alla returnerade servrar är mycket sannolikt att kunna utnyttjas.”
Enligt forskarna liknar version 2.0.206 Log4j 2.17 .0 eftersom det löser problemet genom att begränsa JNDI-webbadresser till att endast använda det (lokala) java-protokollet, vilket nekar alla fjärranslutna LDAP/RMI-frågor.
JFrog tillhandahöll också flera begränsningsalternativ för dem som inte kan uppgradera H2.
Matthew Warner, CTO på Blumira, sa till ZDNet att det enligt OSINT sannolikt finns under 100 påverkade servrar på internet eftersom H2 Database Console måste exponeras medvetet för internet genom att ändra konfigurationen så att den inte bara lyssnar på localhost.
“Medan den här sårbarheten också använder fjärrladdning av JNDI-klass, kräver den åtkomst som inte är tillgänglig med standardkonfigurationen för H2-databasen,” sa Warner.
BreachQuest CTO Jake Williams sa att utbredd exploatering är osannolik eftersom denna sårbarhet finns i en applikation i motsats till ett bibliotek som log4j, vilket innebär att sårbara system borde vara mycket lättare att upptäcka och åtgärda.
I en standardkonfiguration kan sårbarheten endast utlösas från samma maskin som databaskonsolen körs på vilket innebär att exploateringen är extremt villkorad.
“Det är osannolikt att detta kommer att orsaka omfattande skada, även om sårbarhetshanterare borde vara redo att korrigera andra nyupptäckta JNDI-sårbarheter när de avslöjas”, sa Williams. “Det är uppenbart att den här sårbarheten inte kommer att vara den sista som upptäcks som är relaterad till log4j.”
Andra, som NTT Application Securitys Ray Kelly, sa att även om exploatering var osannolik, använde de en mashup av SQL och JNDI att utnyttja en RCE-sårbarhet “är ganska kreativt och ett utmärkt exempel på hur ett enskilt problem kan missbrukas på flera sätt.”
Forskningen är också värd besväret eftersom även om log4j hade specifika kodningsfel som resulterade i Log4Shell, är den bredare idén om bristande validering på JNDI-uppslagningar som leder till sårbarheter en allmän attackväg som sannolikt finns någon annanstans och med tanke på log4j-sårbarheterna var Om det inte upptäcktes tidigare har det troligen inte varit föremål för riktad granskning, enligt Bugcrowd CTO Casey Ellis.
“Detta är ett klassiskt exempel på 'forskningsklustring' som är ett fenomen som Bugcrowd har observerat många gånger tidigare och ett som vi förutspådde efter den första publiceringen av Log4Shell,” sa Ellis.
“Vissa forskarlag har valt att dra nytta av en känsla av panik för att få ut sitt budskap, medan JFrog-folket verkar ha varit mycket noga med att få fram sitt budskap, men inte orsaka onödigt arbete för redan överbelastade säkerhetsteam.”
Säkerhet
De största dataintrången, hackarna under 2021 Copycat och modehacker kommer att vara förbannelsen av säkerheten i leveranskedjan 2022 Säkerhet kommer att vara prioritet #1 för Linux- och öppen källkodsutvecklare i år De 5 bästa VPN-tjänsterna i 2022 Security TV | Datahantering | CXO | Datacenter