Már megint (nem csak Open) SSH hiba: Terrapin Attack

Feltűnt, hogy már megint van FreeBSD-n frissítenivaló. Itt viszont mintha nem láttam volna a mögöttes információt.

Ha már frissítek, akkor nézzünk jobban utána a dolognak. Dec 18-n lett publikus, és ahogy az már lenni szokott, logo, név és weboldal is tartozik a dologhoz. Jó szórakozást (szarakodást?).

( godot v | 2023. 12. 21., cs – 11:52 )

Ha jól értem ez nem "csak" OpenSSH hiba.

Ez protokoll szintű probléma és különböző implementációk különböző mértékben érintettek.

https://www.openssh.com/txt/release-9.6

A release notes alapján ha jól értem olyan nagyon nem kell aggódni.

( zeller | 2023. 12. 21., cs – 11:56 )

Szerkesztve: 2023. 12. 21., cs – 11:57

 

/etc/ssh/sshd_config:
    Ciphers aes128-gcm@openssh.com,aes256-gcm@openssh.com
/etc/ssh/ssh_config:
    Ciphers aes128-gcm@openssh.com,aes256-gcm@openssh.com

Igen, ez nagyon jó, ha a klienseket is te koordinálod, és ezért biztos lehetsz benne, hogy mindenki kivétel nélkül annyira új klienssel rendelkezik, amivel ez nem akad össze. Ellenkező esetben biza lesz, akit ezzel kizársz a rendszerből. (Az nem válasz, hogy "meg is érdemli".)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Az AES-GCM "annyira uj"? Cirka 10 evvel ezelott kerult be az OpenSSH-ba. Minden ertelmes helyen van SSH hardening, aminek kereteben ugrik egy rakas elavult algoritmus, a TLS 1.3-ban sem veletlenul leptek ezt meg. A kellemetlen a chacha20-poly1305 erintettsege, de is csak az SSH-ban problemas hasznalata miatt van (csak ne jarjunk ezzel is ugy, mint annak idejen az RC4-gyel).

Pár száz millió hálózati eszköz (switchek, routerek, tűzfalak, szolgáltatói CPE eszközök stb) van kinn a "vadonban" szvsz amin sosem lesz már SSH hardening (támogatott szoftver verziókkal még a mai napig) Nagy gyártók is magasról tettek az SSH modernizálásra még a közelmultban is.

Erintett teruleten dolgozva egyet toduk erteni, hogy ismerten elavult konfigokkal/ komponensekkel hajlamosak szallitani a termekeiket a tavkozlesi cegek. Egyszeruen rajuk kell boritani a bilit, kulonben sosem fognak erdemben reagalni (es az, hogy tamogatott, az semmit sem jelent a gyakorlatban - siman mondhatjak azt, hogy tudomasul veszik a problemat, igy jartal).

( batyu v | 2023. 12. 21., cs – 19:35 )

Ez már nem az a HUP, ahol ezek a hírek nagy érdeklődésre tartanának számot...

Az Ars Technikás cikk amúgy szerintem tök jól körbejárja.

( Huncraft v | 2023. 12. 22., p – 16:41 )

Leírás alapján az alábbiakat sikerült elérniük:
- Kikapcsolták a további extension-ök betöltését
- Kikapcsolták a keystroke timing obfuscation-t (ami még 9.5-el jött be, szóval sok enterprise distronál ez még nem is elérhető, mert azok még mindig a régi 8.x-eket patkolják)

Kulcsot nem tudtak lopni, a hálózati forgalmat nem tudják decryptálni..
Van olyan extension aminek ilyen módú letiltása komoly biztonsági kockázatot jelent?

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Tudtommal az OpenSSH eseteben gyakorlatilag nincs mas problema, mint az, hogy sikerul x darab csomagot kiiktatni a streambol - igy gyakorlatilag blokkolva a session felepiteset (egy masik SSH implementacional volt komolyabb hatas). Ennek alighanem sokkal nagyobb a fustje, mint a langja, de megint remekul lehet kulonfele security scanner reportokkal revolverezni azokat, akik nem mernek visszaszolni a menedzsmentjuknek, hogy ertelmezni / ertekelni kene a kockazatot, nem pedig vakon nekiugrani a szoftvercsereknek... A minizipnel is at lehetett elni ugyanezt nemreg, ott is durvan tultolta a talicskat a "szakma"

Ez az értelmezés se nem protokol, se nem SSH hiba: Minden MitM támadás esetén a támadónak megvan a lehetősége, hogy az elkapott csomagokat, vagy azok ez részét ne forwardolja tovább a forrás / cél irányába.
Itt a hiba ténylegesen a protokolban van, mert az extensionök betöltését / handshake-jét befolyásoló csomagok még a biztonságos kapcsolat felépülése előtt mennek át, így azokat megfogva az extension betöltést meg lehet akadályozni anélkül, hogy az SSH server / kliens ebből bármit észre venne.

Ezért is kérdeztem, hogy tud e valaki olyan extension-ről, aminek az ilyen módon való kiiktatása biztonsági kockázatot jelentene, de eddig választ nem kaptam rá.
Ha pedig nincs ilyen, akkor ezt én is inkább akadémiai kutatásnak fogom fel (találtunk egy bugot), mint sem tényleges biztonsági incidensnek.

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..