Támadók aktívan kihasználják az SSHole néven ismert hitelesítésmegkerülési sérülékenységet: biztonsági kutatók sikeres behatolásokat, rendszerfelderítést és tartós hozzáférés kialakítására irányuló kísérleteket dokumentáltak. A probléma bizonyos, musl C könyvtárat használó Linux-rendszereket érint, amelyeken az OpenSSH jelszavas hitelesítése PAM nélkül működik.
A CVE-2026-123158 azonosítójú hiba megfelelő feltételek mellett olyan fiókokba is beengedheti a támadót, amelyeknek elvileg el kellene utasítaniuk a jelszavas bejelentkezést. Ehhez nem szükséges a fiók érvényes jelszavának vagy engedélyezett SSH-kulcsának ismerete. A CVE-hez közölt 8,1-es CVSS-pontszám magas súlyosságot jelöl; az OpenSSH fejlesztői kritikus biztonsági kerülőmegoldásként írták le a november 5-én kiadott 10.6p2-es változat javítását. OpenSSH kiadási közlemény, CVE-adatlap
A javítás sürgősségét az aktív támadások is alátámasztják. A CISA november 9-én felvette a sérülékenységet a Known Exploited Vulnerabilities, vagyis az igazoltan kihasznált hibák katalógusába. Ez ugyanakkor nem jelenti azt, hogy minden OpenSSH-t futtató Linux-kiszolgáló érintett lenne. CISA közlemény
Amikor a jelszóellenőrzés hibája sikeres bejelentkezéssé válik
Az SSHole az OpenSSH jelszóellenőrzési logikája és a musl jelszóhash-elés közbeni hibakezelése közötti kölcsönhatásból ered.
Egy Linux-fiók jelszómezőjében használható jelszóhash helyett csillag, azaz * is szerepelhet. Ennek a jelölésnek az a célja, hogy a fiókhoz ne lehessen jelszóval hozzáférni, miközben más engedélyezett módszer, például az SSH-kulcs használata továbbra is lehetséges maradhat.
A sérülékeny ellenőrzési útvonal azonban másik fióktól vehet át a hash-eléshez szükséges sóértéket, ha a célfiók mezője nem tartalmaz használható értéket. A musl bizonyos SHA-alapú jelszóhash-elési műveletei túl hosszú bemenet esetén hibát jeleznek, méghozzá egy csillaggal.
Az OpenSSH ezt a hibajelzést összehasonlíthatja a célfiók tárolt csillagával, és az egyezést tévesen sikeres hitelesítésnek tekintheti. A támadó tehát nem feltöri a jelszót: a rendszer egy hibavisszatérési értéket fogad el helyes eredményként. A problémát Özgün Kültekin, a Wakefield kutatója jelentette. Alpine Linux biztonsági közlemény
Az OpenSSH karbantartói szerint a kiváltó ok az sshd komponensen kívül található, de a hiba az SSH-kiszolgálón keresztül kihasználható, ezért ott is megakadályozható. Ezt biztosítja a 10.6p2-es kiadás. OpenSSH kiadási megjegyzések
Mely rendszerek lehetnek érintettek?
A kihasználhatóság több feltétel együttes fennállásától függ. Önmagában sem a Linux, sem az OpenSSH, sem az Alpine jelenléte nem bizonyítja a kitettséget.
| Vizsgálandó feltétel | Miért fontos? |
|---|---|
| Javítatlan OpenSSH fut musl-alapú Linuxon | A leírt probléma ehhez a szoftverkombinációhoz kapcsolódik. |
| A jelszóellenőrzés PAM nélkül történik | Ez előfordulhat PAM nélkül fordított csomagnál, illetve letiltott PAM-használat mellett. |
| Engedélyezett a jelszavas SSH-hitelesítés | A támadás az érintett jelszóellenőrzési útvonalat használja. |
A célfiók jelszómezője * | A musl hibajelzése ezzel az értékkel egyezhet meg. |
| Legalább egy helyi fiók SHA-256- vagy SHA-512-alapú jelszóhash-sel rendelkezik | Ezeket a $5$, illetve $6$ előtag jelzi; a másik fiók hash-e szerepet kaphat az ellenőrzésben. |
| A célfiók bejelentkezését más szabály nem tiltja | Például a rootfiókra külön korlátozás vonatkozhat. |
| Az SSH-szolgáltatás elérhető a támadó számára | A hálózati hozzáférés a támadás előfeltétele. |
A konfigurációs feltételeket az Alpine közleménye és az Orca Security elemzése részletezi.
A glibc-alapú rendszerek és a PAM-on keresztül végzett jelszóhitelesítés nem tartoznak a leírt támadási útvonal körébe. A Red Hat például kifejezetten nem érintettként jelöli saját termékeit, amelyek OpenSSH-változatai glibc-re épülnek és alapértelmezésben PAM-ot használnak. Red Hat sérülékenységi adatlap
A sikeres támadó kezdetben a megszerzett fiók jogosultságaival rendelkezik. A rendszergazdai hozzáférés attól függ, hogy ez a fiók milyen műveleteket végezhet. Egy szolgáltatás- vagy telepítési fiók azonban rootjog nélkül is hozzáférhet alkalmazástitkokhoz, hozzáférési adatokhoz vagy más rendszerekhez.
Az Alpine felhős példányainál különösen fontos az ellenőrzés
Az Alpine tiny-cloud rendszerképei külön figyelmet igényelnek. Egyes érintett kiadásokban az alpine felhasználó csillagos jelszómezővel és jelszó nélküli doas jogosultsággal rendelkezik.
Ezek a példányok nem feltétlenül támadhatók közvetlenül az első indítás után. Ha azonban később megfelelő jelszóhash kerül a rendszerbe, létrejöhet a kihasználáshoz szükséges állapot. A támadó ilyenkor beléphet az alpine fiókba, majd annak meglévő jogosultságával rootként folytathatja a tevékenységét. Alpine Linux: tiny-cloud érintettség
A közvetlen rootbejelentkezés ettől külön kérdés. Az alapértelmezett PermitRootLogin prohibit-password beállítás megakadályozza a root jelszavas elérését ezen az útvonalon. Nem akadályozza meg viszont, hogy egy másik, már kompromittált fiók a számára engedélyezett adminisztratív műveleteket végrehajtsa.
Azok az Alpine-konténerek, amelyekben nem fut SSH-kiszolgáló, ezen a támadási útvonalon nem érintettek. Egy Alpine-alapú konténerkép használata ezért önmagában nem indokolja a kompromittáltság feltételezését.
Az üzemeltetési tanulság az, hogy a kitettség a telepítés után is megváltozhat. A rendszerképek mellett a futó példányok aktuális felhasználóit, hitelesítési beállításait és jogosultságait is ellenőrizni kell.
Sikeres behatolásokat és további támadói lépéseket figyeltek meg
A GreyNoise november 7-én észlelte az első sikeres kihasználást saját, szándékosan sérülékeny megfigyelőrendszerén. A vállalat a sikeres támadást a célrendszeren végrehajtott parancsok alapján különíti el a puszta kapcsolódástól vagy szkenneléstől.
A megfigyelt tevékenységek egy részét GT10 néven csoportosítja. Ezekhez Python-futtatókörnyezet, TAC Agent nevű eszköz és induláskor végrehajtott szolgáltatásbejegyzés kapcsolódott. Más tevékenységek a konténerkörnyezet felismerésére, felhős metaadatok lekérdezésére és érzékeny hitelesítési információk elérésére irányultak. GreyNoise élő vizsgálati jelentés
A megfigyeléseknek fontos korlátaik vannak. A GreyNoise által bemutatott egyik esetben a TAC Agent nem tudott regisztrálni a vezérlőszervernél, és nem kapott végrehajtandó feladatot. Az a feltételezés, hogy bizonyos visszajelzései automatizált parancstervezést támogathatnak, kutatói következtetés, nem bizonyíték autonóm AI-támadásra.
A kutatók arra is figyelmeztetnek, hogy a kapcsolódó infrastruktúra egy része maga is kompromittált rendszer lehet. Egy IP-cím földrajzi helye vagy a programban használt nyelv nem azonosítja megbízhatóan a támadás irányítóját. GreyNoise elemzés
A támadási kísérletek száma nem azonos az áldozatok számával
A Previdian november 11-én frissített adatlapja 26 kihasználási kísérletet, 17 egyedi forrás-IP-címet és 12 országhoz kapcsolódó forráscímet jelzett négy szenzor megfigyelései alapján. Az első jelzett esemény november 6-án, az utolsó november 10-én történt.
A szolgáltató külön hangsúlyozza, hogy ezek a mérések nem igazolják sem a célpont sérülékenységét, sem a támadás sikerét. A számok a saját megfigyelési hálózatának forgalmát mutatják, nem a világszerte érintett szervezetek számát. Previdian sérülékenységi adatlap
Ugyanezért az interneten észlelt nagyszámú SSH-kapcsolódást sem szabad automatikusan SSHole-kihasználásként értelmezni. Az SSH titkosítása megnehezíti annak pusztán hálózati forgalomból történő megállapítását, hogy milyen hitelesítési kísérlet zajlott. A célgépen megfigyelt parancsvégrehajtás ennél erősebb bizonyíték.
Mely csomagok tartalmazzák a javítást?
Az upstream OpenSSH-javítás a 2026. november 5-én megjelent 10.6p2 verzióban érhető el. A disztribúciók azonban korábbi verzióágakba is visszaemelhetik a korrekciót, ezért nem elegendő kizárólag az upstream verziószámot összehasonlítani.
Az Alpine hivatalos közleménye az alábbi javított csomagverziókat sorolja fel:
| Alpine ág | Javított openssh csomagverzió |
|---|---|
| edge | 10.6_p2-r0 |
| 3.24 | 10.3_p1-r2 |
| 3.23 | 10.2_p1-r1 |
| 3.22 | 10.0_p1-r11 |
| 3.21 | 9.9_p2-r1 |
| 3.20 | 9.7_p1-r6 |
| 3.19 | 9.6_p1-r3 |
| 3.18 | 9.3_p2-r4 |
| 3.17 | 9.1_p1-r7 |
| 3.16 | 9.0_p1-r6 |
Forrás: Alpine Linux hivatalos javítási táblázat.
A régebbi ágakhoz kiadott rendkívüli javítás nem jelenti azok általános támogatásának helyreállítását. Az ilyen rendszereknél a konkrét hiba elhárítása mellett támogatott kiadásra történő átállást is tervezni kell.
A csomagfrissítés után az SSH-démont újra kell indítani. A telepített fájlok cseréje önmagában nem váltja le a kapcsolatokat kiszolgáló, már futó folyamatot. A javítás lezárásához ezért a csomag és a ténylegesen futó szolgáltatás állapotát is ellenőrizni kell.
Átmeneti védelem: a jelszavas hitelesítés letiltása
Ha a frissítés nem telepíthető azonnal, a dokumentált támadási útvonal a jelszavas SSH-hitelesítés letiltásával megszüntethető:
PasswordAuthentication no
A módosítás előtt ellenőrizni kell, hogy a kulcsalapú hozzáférés működik-e. Célszerű a meglévő munkamenetet nyitva tartani addig, amíg egy új kapcsolattal sikerült igazolni a bejelentkezést.
A beállítás tényleges érvényesülését is ellenőrizni kell: a konfigurációs kiegészítések vagy feltételes szabályok miatt egyetlen fájl megtekintése nem feltétlenül mutatja a szolgáltatás teljes viselkedését. A módosítás nem helyettesíti a javított csomag tervezett telepítését. Alpine helyreállítási útmutató
A korábban elérhető rendszereknél behatolásvizsgálat is szükséges
A javítás megszünteti az eredeti belépési lehetőséget, de nem távolítja el a támadó által létrehozott hozzáférést, és nem érvényteleníti a már megszerzett hitelesítési adatokat.
Különösen gyanús a sikeres jelszavas SSH-bejelentkezés olyan fióknál, amelynek nem szabadna használható jelszóval rendelkeznie. Az ilyen eseményeket a fiók jogosultságaival, a folyamatindításokkal, fájlváltozásokkal és kimenő kapcsolatokkal együtt érdemes vizsgálni. Orca Security javítási és észlelési ajánlások
A vizsgálat fontosabb kérdései:
- Jelentek-e meg ismeretlen SSH-kulcsok vagy új felhasználók?
- Módosultak-e az induláskor futó szolgáltatások és feladatok?
- Történt-e szokatlan jogosultságnövelés vagy adminisztratív művelet?
- Indultak-e megmagyarázhatatlan folyamatok és külső kapcsolatok?
- Hozzáférhetett-e a támadó más rendszereken használható titkokhoz?
Ezek vizsgálati szempontok, nem annak bizonyítékai, hogy minden kitett gépet feltörtek. A további lépéseket a naplók, a hozzáférési lehetőségek és a feltárt tevékenység alapján kell meghatározni.
Egyre rövidebb idő marad a reagálásra
Az OpenSSH fejlesztői a kiadási megjegyzésekben arról is beszámoltak, hogy AI-eszközökkel azonosított biztonsági hibákat később más kutatók egymástól függetlenül újra felfedeztek. Emiatt gyakrabban terveznek javításokat kiadni, ahelyett hogy azokat a következő ütemezett verzióig összegyűjtenék.
Ez a sérülékenység-felfedezés ütemére vonatkozó megállapítás. Nem bizonyítja, hogy az SSHole ellen megfigyelt támadásokat mesterséges intelligencia irányította. OpenSSH kiadási közlemény
Az üzemeltetők számára a feladat egyértelmű: azonosítani kell a valóban érintett konfigurációkat, telepíteni a megfelelő javítást, újraindítani a szolgáltatást és megvizsgálni a gyanús hozzáféréseket. A prioritást a kihasználhatóság és a lehetséges következmények együtt határozzák meg: egy termelési titkokhoz hozzáférő telepítési fiók akkor is jelentős kockázatot hordozhat, ha a közvetlen rootbejelentkezés tiltott.
Eredeti cím: Hackers Exploit SSHole OpenSSH Flaw To Hack Linux Systems
