regreSSHion: Sårbarhed ved fjernudførelse af uautoriseret kode i OpenSSH Server

En alvorlig fjernbetjening Uautoriseret kodeudførelse (RCE) Der er for nylig blevet identificeret en sårbarhed i OpenSSH's server (sshd) på glibc-baserede Linux-systemer. Denne meget alvorlige fejl, der er tildelt CVE-2024-6387, udgør en betydelig sikkerhedsrisiko, da den tillader uautentificeret fjernudførelse af kode som root.

Denne opdagelse følger en anden betydelig sårbarhed, der blev identificeret i XZ Utils-biblioteket for blot et par måneder siden, og som fremhæver de igangværende udfordringer inden for cybersikkerhed. Selvom CVE-2024-6387 er en alvorlig fejl, er den ret vanskelig at udnytte i praksis. Ikke desto mindre er det afgørende at forstå risikoen og tage skridt til at beskytte sine systemer. SSH bruges i vid udstrækning på tværs af forskellige platforme på Linux-servere, hvilket gør dets sikkerhed af afgørende betydning.

Tekniske detaljer

Dette problem opstår, når en klient ikke kan godkende inden for LoginGraceTime periode, som er sat til 120 sekunder som standard i nyere versioner og 600 sekunder i ældre versioner. Når denne timeout er nået, vil sshd's SIGALRM Handleren udløses. Problemet opstår, fordi denne handler kalder forskellige funktioner, f.eks. syslog(), som det er usikre at kalde fra en signalhåndtering. Denne kapløbstilstand udgør en betydelig risiko for systemer, der kører standardfunktionen sshd konfiguration.

Interessant nok er denne sårbarhed ikke helt ny. Det er en regression af et tidligere identificeret problem, CVE-2006-5051, rapporteret af Mark Dowd i 2006. Denne tidligere sårbarhed involverede også en signal handler race condition i OpenSSH-versioner før 4.4, hvilket kunne føre til et denial of service eller potentielt tillade fjernudførelse af kode.

Regressionen fandt sted i oktober 2020 med udgivelsen af ​​OpenSSH 8.5p1. Under en opdatering af logningsinfrastrukturen blev et afgørende direktiv (#ifdef DO_LOG_SAFE_IN_SIGHAND) blev utilsigtet fjernet fra sigdie() funktion. Denne funktion, direkte kaldet af sshd'er SIGALRM handler, blev gjort usikker igen. Her er en oversigt over tidslinjen for sårbarheden:

• OpenSSH < 4.4p1Sårbar over for race-tilstanden, medmindre der er foretaget en opdatering til CVE-2006-5051 eller CVE-2008-4109.
• 4.4p1 ≤ OpenSSH < 8.5p1Sikker på grund af tilstedeværelsen af ​​#ifdef DO_LOG_SAFE_IN_SIGHAND, som fik sigdie() til at kalde _exit(1) sikkert.
• 8.5p1 ≤ OpenSSH < 9.8p1Sårbar igen på grund af fjernelsen af ​​#ifdef DO_LOG_SAFE_IN_SIGHAND-direktivet.

Konsekvenserne af denne sårbarhed er særligt alvorlige på glibc-baserede Linux-systemer, hvor syslog() selv kan aktivere andre usikre funktioner som f.eks. malloc () og ledig()Dette skaber et scenarie, hvor en angriber potentielt kan udføre vilkårlig kode som root uden at skulle godkende. Dette skyldes, at sshds privilegerede kode fungerer med fulde systemrettigheder og mangler sandboxing.

Sårbarhedsdetaljer

Denne sårbarhed skyldes en signal handler race condition i OpenSSH's server (sshd), som påvirker systemer i deres standardkonfiguration. Søgninger ved hjælp af Censys og Shodan afslørede over 14 millioner potentielt sårbare OpenSSH-serverinstanser, der er eksponeret for internettet. Anonymiserede data fra Qualys indikerer, at cirka 700,000 eksterne internetvendte instanser er sårbare, hvilket tegner sig for 31% af alle internetvendte instanser med OpenSSH i den globale kundebase. Det er værd at bemærke, at over 0.14% af disse sårbare instanser kører End-Of-Life/End-Of-Support-versioner af OpenSSH.

Udvikling og offentliggørelse af udnyttelse

Ved at forstå den detaljerede udnyttelsesproces kan systemadministratorer og sikkerhedsprofessionelle bedre forstå alvoren af ​​denne sårbarhed og vigtigheden af ​​at implementere rettidige programrettelser og robuste sikkerhedsforanstaltninger.

Udnyttelse af signal handlerens race condition-sårbarhed i OpenSSH kræver en dybdegående forståelse af timing-angreb og hukommelsesmanipulation. Nedenfor skitserer vi de trin, en angriber ville tage for at udnytte denne sårbarhed.

Initier flere forbindelser

Angriberen initierer adskillige forbindelser til den pågældende OpenSSH-server og udløser gentagne gange LoginGraceTime grænsen uden at fuldføre godkendelse. Denne handling får serveren til at hæve SIGALRM signal.

Afbrydelsessignalhåndterer

Udnyttelse afhænger af at afbryde serverens signalhåndterer i det øjeblik, den udfører ikke-asynkrone signalsikre operationer, såsom syslog()Angriberen sender specielt udformede input for at manipulere serverens hukommelseslayout, hvilket fører til heap-korruption.

Manipuler hukommelseslayout

Ved at manipulere serverens hukommelse skaber angriberen en inkonsistent tilstand i heapen. Dette opnås ved at udløse SIGALRM-signalet under hukommelsesallokering eller deallokeringsfunktioner som f.eks. malloc () or ledig()Det kræver typisk omkring 10,000 forsøg at udnytte denne sårbarhed. Hvert forsøg nulstiller LoginGraceTime-timeren, hvilket giver angriberen et nyt vindue til at udløse sårbarheden.

Finjuster timingen

Under udnyttelsesprocessen justerer angriberen timingen af ​​deres input baseret på feedback fra tidligere forsøg. Denne finjustering er afgørende for at kunne afbryde signalbehandleren på det kritiske tidspunkt. Trods moderne forsvar som Address Space Layout Randomization (ASLR) og No-eXecute (NX) bruger angriberen forudsigelige hukommelsesmønstre og avancerede timingteknikker til at omgå disse beskyttelser.

Udfør vilkårlig kode

Vellykket udnyttelse gør det muligt for angriberen at overskrive kritiske hukommelsesstrukturer, hvilket fører til udførelse af vilkårlig kode og fjernstyring af serveren med root-rettigheder.

Forsknings- og udviklingsindsigt

Forskerne har primært fokuseret på virtuelle maskiner med overvejende stabile netværksforhold. Selvom der er gjort betydelige fremskridt, forventes yderligere forbedringer, især for at udnytte nyere amd64-systemer, hvor ASLR er stærkere. En relateret fejlrapportopdagelse førte til øjeblikkelig kommunikation med OpenSSH-udviklere, hvilket understregede vigtigheden af ​​hurtig handling i forbindelse med at håndtere sådanne sårbarheder.

OpenSSH: Sikring af sikker virksomhedskommunikation

OpenSSH (Open Secure Shell) er en essentiel pakke af sikre netværksværktøjer baseret på Secure Shell (SSH)-protokollen. Den sikrer robust kryptering for privatlivets fred og sikre filoverførsler, hvilket gør den afgørende for fjernserveradministration og sikker datakommunikation. Trods den nylige sårbarhed forbliver OpenSSH en benchmark inden for softwaresikkerhed på grund af dens omfattende sikkerheds- og godkendelsesfunktioner, skalerbarhed og evne til at håndhæve robuste adgangskontroller.

Berørte OpenSSH-versioner

• SårbarVersioner tidligere end 4.4p1 (medmindre der er opdateret opdateringer til CVE-2006-5051 og CVE-2008-4109) og versioner fra 8.5p1 op til, men ikke inklusive, 9.8p1.
• Ikke sårbarVersioner fra 4.4p1 op til, men ikke inklusive, 8.5p1 på grund af en transformerende programrettelse til CVE-2006-5051.

OpenBSD-systemer er ikke påvirket af denne fejl takket være en sikker mekanisme udviklet i 2001, der forhindrer denne sårbarhed.

Potentiel indvirkning af regresion

Hvis denne sårbarhed udnyttes, kan den føre til fuldstændig systemkompromittering, hvilket giver angribere mulighed for at udføre vilkårlig kode med de højeste rettigheder. Dette kan resultere i en komplet systemovertagelse, installation af malware, datamanipulation og oprettelse af bagdøre til permanent adgang. Det kan også fremme netværksudbredelse, hvilket gør det muligt for angribere at bevæge sig ind i og udnytte andre sårbare systemer i organisationen. Denne sårbarheds karakter af fjernløbstilstande gør den udfordrende at udnytte, men fremskridt inden for deep learning kan øge succesraten.

Øjeblikkelige skridt til at mindske risikoen

• Patch ManagementAnvend hurtigt tilgængelige programrettelser til OpenSSH og prioriter løbende opdateringsprocesser.
• Forbedret adgangskontrolBegræns SSH-adgang via netværksbaserede kontroller for at minimere angrebsrisici.
• Netværkssegmentering og indtrængningsdetektionOpdel netværk for at begrænse uautoriseret adgang og laterale bevægelser inden for kritiske miljøer, og implementer systemer til at overvåge og advare om usædvanlige aktiviteter, der indikerer forsøg på udnyttelse.
• Implementering af en midlertidig løsningHvis en opgradering ikke er mulig med det samme, skal du indstille LoginGraceTime parameter til 0 i OpenSSH-konfigurationsfilen. Dette forhindrer uautoriserede sessioner i at forblive åbne og blive udnyttet. Bemærk dog, at dette kan føre til denial-of-service, hvis alle forbindelsespladser er optaget.
• Forbedret sikkerhed med SeccompVed at begrænse sshd's systemkald, reducere angrebsfladen og forhindre udnyttelse af usikre funktioner som syslog, og dermed begrænse vilkårlig kodeudførelse i tilfælde af sårbarheder.

RELIANOID Load Balancer: Forpligtelse til sikkerhed

Alle versioner af RELIANOID Load Balancer har allerede de opdaterede pakker i repository'et, hvilket afspejler vores engagement i at levere den mest sikre og pålidelige load balancer. Sørg for at have de seneste opdateringer installeret i dine load balancers og servere.

Vær årvågen, og sørg for, at dine systemer er opdateret og beskyttet mod denne betydelige sikkerhedstrussel. Kontakt vores sikkerhedseksperter at vide mere om denne sårbarhed.