SSH publikus kulcsok megfertőzése backdoor-ral

Titkosítás, biztonság, privát szféra
In this article, you will learn how to add a backdoor to the SSH Public Key. The backdoor will execute whenever the user logs in. The backdoor hides as an unreadable long hex-string inside ~/.ssh/authorized_keys or ~/.ssh/id_*.pub.

The source is available from GitHub.

( zitev v | 2023. 05. 25., cs – 13:41 )

Na hala a joistennek..

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

( asch v | 2023. 05. 25., cs – 14:30 )

Szerkesztve: 2023. 05. 25., cs – 14:31

Ha jól értelmezem ezt úgy lehet kihasználni, hogy a rendszergazda kéri a publikus kulcsomat, hogy telepítse a gépre, ahová van belépésem, én meg egy ilyen kraftoltat adok oda neki. Ő ha nem ellenőrzi le, csak vakon bemásolja, akkor a szerveren lett egy sérülékenység.

Jól értelmezem? Ha feltételezem, hogy a user és a rendszergazda jóhiszeműek, akkor hogy tud ebbe a folyamatba harmadik fél homokot szórni?

Van egy rákás netes szolgáltatás, ahová kulcsot kell feltölteni, azokat érdemes lesz végignézni, hogy van-e sérülékenység bennük.

( DirtY_iCE | 2023. 05. 25., cs – 15:04 )

Haat. Ha egy admin kezzel teszi oda a pubkeyt, akkor csak feltunik neki hogy valaki 3x olyan hosszu kulcsot kuldott mint masok, raadasul a fele nem is base64. Netes szolgalatasok ahol be lehet adni pubkeyeket az meg vagy olyan, hogy a) kapsz rendes shellt, es akkor tokmindegy mert max kezzel futtatod le a payloadot, vagy b) ilyen git szerver szeruseg (ahol nem akarsz a usereknek shellt adni) ami amugy is hasznalja ezt a command atrributumot, es ott jo esellyel ugyis el fog romlani ha ezt igy becopypasteled. Ugyhogy igy eleg valoszinutlennek tunik hogy gyakorlatban ki lehessen hasznalni.

I hate myself, because I'm not open-source.

Szerintem inkabb ott szamit a dolog, ahol valami script teriti a publikus kulcsokat. Ott nem feltetlen van valaki aki eszerveszi.

Eddig nem hiszem, hogy sok eszkozben lett volna beepitett ellenorzes, hogy command attributum ne legyen benne, ezutan talan lesz. Bar mondjuk talalkoztam mar esetekkel, amikor volt valami regex match ssh-{rsa|dsa|ed25519} [a-zA-Z0-9/+=]\+ formatumra, bar leginkabb azert, hogy a hulye user ne valami -----BEGIN RSA PRIVATE KEY----- vel kezdodo dolgot akarjon publikus kulcskent berakni.

Régóta vágyok én, az androidok mezonkincsére már!

De pont ez a lenyeg, ha esz nelkul bemasolod ezt egy command="akarmi" moge, akkor kapsz egy command="akarmi" command="backdoor" ssh-rsa AA...-ot, ami meg invalid syntax es ignoralja az ssh. Esetleg ha annyira nincs semmi check az egeszen hogy ujsor karakter is lehet a public keyben, akkor lehet elerni valamit.

Ha meg a script nem akar command=-ot berakni a te pubkeyedhez, akkor meg tokmindegy mert ugyis kapsz shellt.

I hate myself, because I'm not open-source.

( thuthu | 2023. 05. 25., cs – 16:00 )

Valaki elolvasta a "man sshd"-t és a command="command"-ot úgy értelmezte, hogy backdoor.. Naccerű. Azt is írhatta volna, hogy az sshd -ban RCE van, mert távolról (!!!) lehet parancsokat futtatni! Mindenki fusson!

( sz332 v | 2023. 05. 25., cs – 17:12 )

Számomra ez nagyon ilyen log4j jellegű történtnek tűnik, a szokásos "valamira majd jó lesz" feature. Valószínűleg alapvetően tiltani kellene és külön configból engedélyezni, de valójában ennek

nem is lenne szabad léteznie.

Dehogynem. Ez pont egy biztonsagi feature.

A lenyeg, hogy beengeded a felhasznalot, de nem kap rendes shellt, ahol garazdalkodhat, hanem egybol elindul neki az a program amivel dolgoznia kell. Ha kilep belole, veget er az SSH session.

Ez egy igen hasznos feature, sok fejfajastol megkimel.

A git implementációk is ezzel működnek: van egy git user, ennek a nevében lép be mindenki, de úgy, hogy mindenkinek egy felparaméterezett parancs indul, amiből a git tudja, hogy mi a valódi user. Ügyes megoldás, nagyon hasznos. Mindenféle szolgáltatásokat lehet építeni rá.

Az egyetlen amin lehetne vitatkozni, hogy ez a megvalósítás, hogy mindent egy sorba írunk be, ez jó-e.

Nem a publikus kulcshoz csapja hozza, hanem az ssh authorized_keys formatuma olyan hogy a public key ele lehet irni meg igy extra dolgokat. Egy nagyon egyszeru formatum-check megfogja az egeszet (lenyegileg ssh-[dss/rsa] + egy valid base64 encodeolt cucc, ha van barmi utana az ignore, nem kell az asn.1-et kiparsolni belole vagy semmi ilyen extra)

I hate myself, because I'm not open-source.

De nem érezzük rohadtul veszélyesnek (security audit szempontjából én mindenképp) hogy kap a rendszer kívülről egy asset-et, amely security releváns attributumot tartalmaz (a belépéskor lefutó kód), és

csont nélkül betöltjük a rendszerbe, azzal a felkiáltással, hogy a beküldő biztos tudja mit akar?

Pont a leírt támadás miatt. Ha sikerül kompromittálni a kulcsot (illetve az adathalmazt amit átad a user) és ez autómatikusan betöltésre kerül, akkor az egy szép kis security kis lyuk tud lenni.

Nyilván nem egyszerű a támadás, de véleményem szerint itt össze van mosva két különböző történet, és ezt így nem lenne szabad.

Irj kerlek egy usecaset, hogy hogyan hasznalnad ki ezt a security hole -t, es hogy az atadott adathalmaz (parancs) miert nem veszelyes, ha ugyanazt a parancsot a shellben adom ki?

Szerintem tok mindegy, hogy hol adod ki a parancsot. Ezt fogd fel ugy, mint egy bashrc allomanyt, az is lefut belepeskor, pont mint ez a sor, es csak olxan utasitasok vannak benne, amiket a shellben is kiadhatsz. Raadasul a belepett usereddel adja ki, vagyis nem az sshd service jogaival fut, mely esetben valoban privilege escalation lennne. De itt nincs errol szo.

Szoval, kerlek, vazolj fel egy esetet, ahol ez visszaelest tud okozni.

"Szoval, kerlek, vazolj fel egy esetet, ahol ez visszaelest tud okozni."

Nham, majdnem rávágtam, hogy ez akkor is lefut, ha a shell pl. /sbin/nologin, de én nem bírtam olyan parancsot kraftolni, ami tényleg. Persze ez lehet az én hülyeségem is, de így kb. csak egy a sok másik lehetőség közül (bár nem tuti hogy benne lenne az első tízben ami eszembe jutna).

Ha sikerül kompromittálni a kulcsot (illetve az adathalmazt amit átad a user) és ez autómatikusan betöltésre kerül, akkor az egy szép kis security kis lyuk tud lenni.

Nagyon jó. Akkor most vegyük ki az sshd kódjából azt a részt, ami ezt a command attribútumot kezeli (kezelje úgy az sshd a kulcsot, mintha nem lenne ott a command attribútum). Kisebb lett a security lyuk? Szerintem nagyobb lett. Tehát akkor miért a command attribútum a sechole oka?

( ssikiss | 2023. 05. 26., p – 08:34 )

Az hogy az authorized_keys fájlban van lehetőség bármi másra, mint a használható kulcsok felsorolására (meg esetlegesen a hozzájuk tartozó biztonsági paraméterek megadására) - tervezési hiba. Most látszik, hogy miért. :)

Igen, a kulcsok meg az, hogy az adott kulccsal azonosított felhasználó milyen parancsot hajthat végre, az egymástól független információ, hülyeség is egyben kezelni. Például ha nekem van 15 kulcsom, attól még ugyanaz az egy felhasználó vagyok, ugyanazokkal a jogokkal. De jelenleg megtehető, hogy kulcsonként más és más parancsot hajthatok végre. Ez nem annyira jó.

A kulcs nem azonosít laptopot/telefont/yubikeyt. Ugyanis én használhatom ugyanazt a kulcsot ezer eszközről is egyszerre akár, semmi nem tiltja technikai szinten. Yubikeybe is importálhatok olyan kulcsot, amit máshol generáltam és használok többször. Persze, ellenjavalt, de ez megtehető.

A kulcs maga nem identitás ilyen értelemben: egy usernek lehet 15 különböző kulcsa is akár (ettől még a user ugyanaz a valóságban), de 1 kulcsot is használhat 15 különböző eszközről (ettől az még 15 különböző eszköz a valóságban).

Az egy felsőbb policy kérdés, hogy hogyan mappeled a kulcsokat identitásokhoz (userekhez, szerepekhez) - jogosultságot pedig identitásoknak adsz és nem kulcsoknak.

nalam mindennek (notik, telo, pl navicat tunnelnek) sajat kulon kulcsa van. megvan hogy adott kulcs mihez ferhet hozza (nem ilyen godmode-ban nyomom), es a visszavonhatosag is konnyeb: ha egy helyrol/eszkozrol mar nem akarom a belepest, eltavolitom az pubkey-et a megfelelo helyrol.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Nem értem, mit akarsz ezzel mondani. git esetén is megadhatom, hogy egy git userhez valójában 15 különböző kulcs tartozzon - bármelyiket mutatom be, megvan, hogy én melyik user vagyok. Ekkor mind a 15 kulcsnál ugyanannak a parancsnak kell benne lennei a kulcshoz, nem lehet 14 egyező meg 1 különböző.

Az ilyen git szervereknél nincs a git userekhez helyi user a gépen, hanem csak a git "agyában" vannak a userek. Valójában nem is a git agyában, hanem a gitolite agyában, az intézi a hozzáférés-kezelést. Itt van egy slideshot erről: https://gitolite.com/gitolite/how.html#(12)

( kassaiviktor | 2023. 05. 26., p – 14:14 )

legközelebbi sebezhetőség: ssh-val be lehet jelentkezni, és végre lehet hajtani destruktív műveleteket

rtfm!

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.

( hajbazer v | 2023. 05. 26., p – 14:53 )

Ha ezzel bárkit is sikeresen betámadnak, az egyben azt is jelenti, hogy a babzsákadmin még csak felületesen sem olvasta el, hogy mit másol az authorized_keys fájlba. Ez az igazán szomorú tény és nem az, hogy egy kattintásvadász IT-influenszer hírértéket adott egy rossz célokra is használható OpenSSH feature-nek.

( willy v | 2023. 05. 27., szo – 08:24 )

Szuper, hogy az IT-ban is láthatóan gyűlnek a kattintásvadász hírek, de biztos, hogy ezt ide kell hozni?

A meleg víz feltalálása óta ez a legnagyobb innováció. A felhasználó nevében futtathat le valamit, ha valami engedélyezett, azt addig is megtehette a felhasználó, ha nem tehette meg, azt ez sem fogja biztosítani. 

( YleGreg | 2023. 05. 27., szo – 09:34 )

Nem szeretnek panikot kelteni, de:

- autoexec.bat

- autorun.inf

- Inditopult!!

A linuxosat le sem irom, mert a systemd egy komplett halalcsillagot implementalt, hogy jol mukodjon az automata parancskiadas.

( vl v | 2023. 05. 28., v – 15:10 )

Kik ezek az idióták?!? Senkiháziak kezében a popszakma...