OpenSSH MaxAuthTries bypass

 ( trey | 2015. július 22., szerda - 13:51 )

KingCope egy OpenSSH sebezhetőségről blogolt a minap. Az OpenSSH szerver alapértelmezetten hat autentikációs próbálkozást (MaxAuthTries) engedélyez mielőtt lezárja a kapcsolatot (az OpenSSH kliens alapértelmezetten hármat). A sebezhetőség kihasználása lehetővé teszi a támadó számára, hogy annyi jelszó promptot kérjen a megtámadott SSH szervertől, amennyit a LoginGraceTime lehetővé tesz (alapértelmezetten 120 másodperc).

KingCope szerint az alapértelmezett két perces LoginGraceTime értékbe akár 10 000 próbálkozás is beleférhet.

[ OpenSSH keyboard-interactive authentication brute force vulnerability (MaxAuthTries bypass) ]

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Én biztosan nem tudok ilyen gyorsan véletlen jelszavakat gépelni. :-)
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Erre van az elore elkeszitett rainbow table?
Amugy 2factor auth-nal szerintem a 10e az nagyon karcsu sikeres bejutashoz.

rainbow table-nek ehhez semmi köze. nem hash értékeket variálsz, hanem jelszavakat próbálgatsz.

FYI: a rainbow tablak tartalmazzak a hash es reverz ertekeket is es brute force-ra is lehet hasznalani.

Hat, vegulis akar igazad is lehetne, de akkor sem erre valo a rainbow table, mert a kutyat nem erdekli, milyen hash-ek allithatoak elo egy-egy jelszobol kulonfele crypto algoritmusokkal, ha brute force van.

Total nem ertem mire akarsz kilyukadni. A rainbow table tartalmaz tobb 10e jelszo mintat (nem nem csak a hash-t, mi ertelme lenne), amivel lehet brute force-olni? Problem? Nem tudok rola, hogy kulon password dictionary-t gyartananak hash tabla nelkul barkik is. Mi ertelme is lenne, megis?

Nem tudom eldonteni, hogy tenyleg ennyire nem erted, amirol beszelsz, vagy csak megszokasbol kotozkodsz. A dictionary attack kifejezesrol hallottal mar? Ahol jelszavas authentikacio van, nem fersz hozza az eltarolt hashekhez, ott mi a fenenek kene rainbow table? Csak feleslegesen foglalnanak (egyaltalan nem elhanyagolhato meretu helyet) a kulonfele hash-ek, kulonosen, ha salting is van. 10e minta amugy nevetsegesen kevesnek szamit.

"Nem tudom eldonteni, hogy tenyleg ennyire nem erted, amirol beszelsz, vagy csak megszokasbol kotozkodsz."
Ugyan ezen gondolkodtam en is rolad.

"A dictionary attack kifejezesrol hallottal mar? Ahol jelszavas authentikacio van, nem fersz hozza az eltarolt hashekhez, ott mi a fenenek kene rainbow table? Csak feleslegesen foglalnanak (egyaltalan nem elhanyagolhato meretu helyet) a kulonfele hash-ek, kulonosen, ha salting is van. 10e minta amugy nevetsegesen kevesnek szamit."

Senki nem beszelt hash-ekrol csak te...de arrol folyamatosan.
De semmi gond, johetnek a linkek is, mutass egy nem pistike altal karbantartott, de hash-t semmilyen formaban nem tartalmazot.
Egeszen eddig arrol folyt a vita, hogy brute force-al be lehet-e maszni, ha van kb 10e probalkozasi lehetoseged,(ugy e a cikk szerint, 2perc alatt) innel a 10e szam, csak hogy ertse a kovetkezo is, aki nem olvassa el a cikket, amirol amugy beszelunk. Nekem ugy tunik szandekosan elbeszelssz mellettem.

nekem meg ugy tunik nem tudod mi az a rainbow table.

Gyartanak.

'Mi ertelme is lenne, megis?'

Mert auth method meg hash method az van kismillio, de ez emeberek egy adott teruletrol ettol fuggetlenul hasznalanak hasonlo szotari szavakat.

(A szotari szavak, kis modositasat nem szokas tarolni arra van mas tool.)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

rainbow table akkor kell neked, ha van egy adott hash-ed, és olyan bájtsorozatot akarsz gyártani, amit pont erre a hash-re lehet kiszámolni. (mindjárt belém köt valaki, hogy manapság a rainbow table már nem effektív, de nem ez a téma). ennél a sérülékenységnél azonban nincs a kezedben hash.

igen

Van még akinél a jelszavas belépés nincs tiltva? :)

Kulcs alapu auth-nal meg lehet vegre oldani policy kenyszeritest? (Ne lehessen jelszo nelkuli kulcs, meg netan a kulcs jelszavara is adott policy megkoveteles?)

A passphrase kliensoldali dolog.

Igen, ez a problemam, mert sokan kenyelmi szempontkent kezelik a kulcs alapu auth-ot, ertsd nem adnak meg hozza jelszot, amivel inkabb rosszabb szamomra mintha lenne jelszo alapu auth lenne, mert ha valaki hozzafer a gepehez/privat kulcsahoz onnantol kezdve be tud lepni, amit en nem tudok ellenorizni/kontrollalni hogy van-e rajta jelszo.
Persze emberi tenyezo attol ugyanugy meg van jelszo alapu auth eseten is, ha feltorik a gepet es lelopjak a jelszavat, vagy mashol lopjak el mert ugyanazt hasznalja sok helyen es meg kismillio dolog miatt lehet szinten gond.

Elméletileg sem lehet a problémát megoldani.

te adod ki a kulcsot.

Majd, akinek kiadja, atirja/megszunteti a jelszot, immar kontrolalatlanul. Kb ugyanez a gondom openvpnnel, es altalaban kulcs alapu authentikacioval. vpnnel legalabb van/lehet masodlagos auth, de az meg bonyolultta teszi az eletet a usernek.

Közben eszembe jutott, hogy a jelszót le lehet venni róla utólag.

Szerintem ilyen sose lesz, mert nem lehet jól megcsinálni, csak hardverből, arra pedig már vannak ketyerék.

Ha arra gondolsz, hogy en adjak egy hw-es megoldast amin rajta van a kulcs es azon felul ad egy megfelelo plusz azonositast az valoban lenne egy lehetoseg, csak draga es maceras, nem is elterjedt.

En valami olyan megoldast varok ami kibovitene szoftveresen a mostani kulcs alapu auth-ot olyan lehetoseggel, hogy ssh szerverben csak olyan publikus kulcsot fogadjon el a jelszoval vedve van, netan annak valami szintje is behatarolhato, avagy szerver adjon vissza valami hitelesitest a kulcshoz mikor feltoltik, hogy igen azt elfogadja.
Kozel sem trivialis es felvetne jopar uj kerdest vagy aggalyt is akar valami ilyen megoldas, viszont igy jelenlegi kulcs alapu auth-ot nem erzem biztonsagosabbnak a jelszo alapunal.

Megoldhatatlan. A passphrase arra valo, hogy a kliensoldalon hozzaferj a privat kulcshoz. Sosem mehet, es nem is megy at a droton, ergo semmifele ellenorzesre nincs lehetoseg a tuloldalon.

Ez így van. Szerver oldalon csak maszatolni tudna, ami semmit nem tenne hozzá a biztonsághoz.

Tudom jol, hogy jelenlegi megoldas nem kepes erre es nem is erre lett tervezve, de attol meg remelem lesz idovel valami megoldas arra is (nem en akarom megvaltani a vilagot, hogy megvalositas modjan otleteljek most).

A gyakorlatban biztonságosabb, ezt sok év alatt tapasztaltam. Aki egy kulcsot nem tud biztonságban tartani, az többnyire egy jelszót sem. Viszont fordítva ez nem igaz.

En sajnos a forditottjara is lattam jopar peldat az evek soran.

Nem, viszont
a.) ha a kulcshoz hozzafernek, akkor szinte biztos, hogy a jelszohoz is, max. a jelszonal nem azonnal, igy van egy pici eselyed detektalni az incidenst. Ha naponta tobbszor hasznalod, akkor ez kb. 0.
b.) 6.2-es openssh ota meg tudsz kovetelni mas authentikacios metodust is a kulcs melle (tehat csak akkor enged be, ha kulcsod is van, es pl. a PAM-on is atmentel). De akarmit csinalsz, ez a kompromittalt vegponttol nem tud teljesen megvedeni.

--
"You're NOT paranoid, we really are out to get you!"

a, Jelszo nelkuli kulcs eseteben ha bejutnak a gepre akkor mar kb meg is van a tovabbjutas, mert altalaban file szinten el fogja erni sajat kulcsat a user, jelszo eseten olykor macerasabb lehet. De ugyanakkor azt megfelelo modszerekkel meg ha ugyanazt jelszot hasznalja mashol is a user akkor akar konnyebb is lehet jelszot ellopni. Egyik megoldasra se mondom hogy jo vagy hibatlan, csak sokan a kulcs alapu auth-ot istenitik, mert az nem jelszo, pedig annak is vannak komoly hianyossagai.
b, Ez mar egy jo kezdemenyezesnek tunik, koszi!

Én használok még bőven jelszavast, de ott ugye az ssh jogosult usert megadom, és kb 2-3IP címről engedek be kapcsolatot, plusz fail2ban.

A fail2ban segít ezen?

Igen

Feltéve, ha a grace period alatt az összes hibás próbálkozást logolja, nem csak egyet a végén. Különben 10000 lehetőség így is lesz.

Az ilyen esetre, mint másodlagos védelmi vonal az IPTABLES-be ratelimit-et használok. 3 / perc hitcount. Működik.

Itt egy felépült(ESTABLISHED) TCP sessionbe lehet betolni a sok kérést, ez ellen nem véd a ratelimit.