- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Na hala a joistennek..
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
A kulcs hossza ugye sok mindentol fugg, pl hany bites kodolasd hasznalsz.
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
Kozbe rajottem hogy beneztem, rosszul emlekeztem a formatumra, a pubkey ele kell rakni ezeket az optionoket, az meg meg kevesbe valoszinu hogy ne tunjon fel az adminnak hogy nem ssh-valamivel kezdodik a pubkey.
I hate myself, because I'm not open-source.
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
thc.org?
- A hozzászóláshoz be kell jelentkezni
Újszülötteknek minden vicc új. Az sshban régóta adott a command="cmd" feature. És egyáltalán nem backdoor, hanem feature. Az, hogy lehet rossz célokra használni is, az meg régóta tudott.
- A hozzászóláshoz be kell jelentkezni
Nincs ezzel semmi baj, csak latszatintezkedesi szokasjog - majd kesobb jog ne legyen ebbol a hatalmas felfedezesbol. Mert az sem lenne pelda nelkuli. :(
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
Ennek semmi köze a log4j történethez.
Ez egy security feature, amivel korlátozhatod az sshzó user tevékenységét. Rengetegszer használtam én is, kollégák is.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
De várjatok, lehet hogy rosszul értettem, de ezt a publikus kulcshoz csapja hozzá a támadó, amit egyszerűen csak beimportálnak szerverbe? Ezt nem érezzük veszélyesnek?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Maga a veszély az, hogy a publikus kulcsokat sok esetben automatikusan importálják, mindenféle ellenőrzés nélkül. Nyilván nem kéne ilyet csinálni.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
A mesterem anno kb. mindenre azt mondta, hogy azt is lehet rosszul csinálni.
Szóval igen, ha ész nélkül importálnak kulcsokat, akkor az veszélyes. Mint ahogy ollóval szaladgálni is, de az se az olló hibája.
- A hozzászóláshoz be kell jelentkezni
Mitol veszelyesebb a kulcs command reszeben elhelyezett "cat /etc/shadow" mint az, hogy belepek, es kiadom azt a parancsot, hogy "cat /etc/shadow" ?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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. :)
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
a 15 kulcshoz 15 kulon entitas tartozik. mas-mas laptopok/telok/yubikey esetleg "szerepenkent" mas-mas.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
És ha jól értem, ennél a mappelésnél kellene szerepelni annak, hogy ha ezzel authentikálja magát a rendszerbe, akkor milyen egyéb folyamat fusson le.
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
Az, hogy nálad így van, az okés, de ez a fajta policy sehol nincs kőbe vésve - ez a te policy-d. Más cégnél, szervezetnél, embernél meg más policy-k képzelhetők el.
- A hozzászóláshoz be kell jelentkezni
Ja, lehet hogy valahol telnettel eresztik be a jonepet a gepekre, ott legalabb nincs ilyen problema. :-)
- A hozzászóláshoz be kell jelentkezni
Föntebb valaki a gitet emlegette, ahol marhára nem ugyanaz az entitás jön. Vagy nem értem.
- A hozzászóláshoz be kell jelentkezni
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ő.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
Én is csak git userekről beszéltem. Az, hogy melyik identitást rendeli egy szoftver az adott SSH kulcshoz, az a szoftvernek kell eldöntenie .
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Vagy automatikusan, egy script által történik az import. Vagy egyszerűen csak nem veszi észre az admin. Ezek mind támadási felületek, amiket kellene zárni.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
felkeszul:
*bashrc*
alias
... :D
- A hozzászóláshoz be kell jelentkezni
fakenews
- A hozzászóláshoz be kell jelentkezni
Kik ezek az idióták?!? Senkiháziak kezében a popszakma...
- A hozzászóláshoz be kell jelentkezni