dit lijkt gestoeld op niet goed begrijpen hoe de technology werkt.

SSH doet niet standaard de SSH-AGENT forwarden naar de remote, om dit te doen. moet je dit bewust aanzetten:


zie ook de release notes:

Waar het venijn in zit in deze is dat als je de SSH-AGENT foraward naar de remote, je dus communicatie mogenlijkmaakt van de remote naar jouw locale omgeving.. inclusief het remotely triggeren van laden van shared libraries. (waar deze CVE over gaat)

An sich is er niets mis met forwarden van je agent als je weet wat je doet,
toch adviseer ik altijd om gebruik te maken van een JumpHost in plaats van een Agent Forward, de jump host kan tijdens de connectie de agent request doorsturen, maar deze blijft niet open staan na de login. (en is dus on par met direct inloggen vanaf de jump host kwa security profile.)

sources:
- https://www.openssh.com/txt/release-9.3p2
- man ssh

Je hebt gelijk, ik heb het onhandig opgeschreven; -A is niet de default (wel potentieel gevaarlijke libraries die de "callback" exploit mogelijk maken). Dank voor de correctie!

Echter, het zou mij niet verbazen als veel beheerders -A gebruiken, het gaat immers om SSH'en naar "vertrouwde servers".

Beheerders zijn gek op handige trucjes die hun werk vereenvoudigen - in tegenstelling tot preken van securitymensen die hun werk lastiger maken (ook al is dat maar een beetje en met goede redenen - doch in strijd met "we doen dit al jaren zo en het is nog nooit fout gegaan").

Uit [6]:

Je weet niet wat je doet - in de zin van dat als een server gecompromitteerd is, je het probleem van kwaad tot erger maakt.

Bij de matrix aanval was een niet volledig gepatchte Jenkins server (die aan internet "hing") gehacked. Daarna, uit [6]:

Nadat iemand in die val getrapt was:
Zo raakt je hele infrastructuur gecompromitteerd.

Dat is ook één van de adviezen in [6].

Mensen doen van allerlei domme dingen, Als ik dit tegen kom bij een audit dan komt deze partij niet door de audit heen bij mij.

voor remote toegang is de `-a` optie gewoon niet nodig. En ik laat ze dan zien dat dat waar is.... en dat bij de andere optie je impleciet iedereen vertrouwt met root toegang.

Vandaat de Demo,

Ook wijs ik ze er op dat gebruiken van een config file je alle 'headache' voorkomt en zelfs nog makkelijker is dan het steeds intypen.
Dit weerspreekt niet wat ik zei, ansich (als op zichzelf staand) is er geen probleem met het forwarden van de ssh-agent...
immers deze heeft, als je weet wat je doet, geen key materiaal in zich behalve voor de huidige verbinding.

het is een trade-off. en alleen als je domme dingen doet is het gevaarlijk.

een voorbeeld van veilig gebruik:
- ssh-agent instellen om altijd verificatie te vragen voorf dat een sleutel worrd vrijgegeven.
- ssh-agent kan ook worden gebruikt om een SMARTCARD te laten werken over een tunnel.

deze doen wel de aanname dat je je ssh-agent op up to date houd, want deze CVE maakt je dan inderdaad vatbaar voor misbruik. (wel dan beperkt tot client <-> server comprimise, en niet verder dan dat).

Wat de attack op Jenkins betreft, ja dat is precies wat ik verwacht dat iemand met toegang probeerd te doen, zorgen dat ze toegang blijven hebben via een andere weg.

en het verbaast mij niets dat de jumphost ook onderdeel van het advies is...

Ik weet niet zeker of die aanname niet klopt.

Als ik het goed begrijp werkt SSH forwarding normaal gesproken (server S1 is niet gecompromitteerd), als volgt:

De gebruiker is ingelogd op S1, en wil van daaruit "doorhoppen" naar (inloggen op) S2. Dan haalt de SSH client op S1 de credentials voor S2 op bij de PC van de gebruiker, zonder dat de gebruiker hier iets voor hoeft te doen.

Echter, als server S1 gecompromitteerd is, kan de aanvaller, zodra de legitieme gebruiker is ingelogd op S1, zich voordoen als de legitieme gebruiker. Zo kan de aanvaller ook verbindingen opzetten naar andere servers (of doen alsof die verbindingen worden opgezet), en wellicht zo stilletjes de credentials voor andere servers van de PC ophalen (voor zover die bestaan natuurlijk, ik weet niet of de gebruiker een foutmelding krijgt als die niet bestaan - noch of de malware op S1 de PC "geluidloos" kan query'en voor welke servers er creds op die PC staan, om preciezer te zijn in het gebruikersaccount).

Als mijn aanname klopt, zou het plaatje eruit zien als volgt:

Het alternatief voor de aanvaller is dat zij of hij moet wachten tot de gebruiker, via S1, verbinding maakt met S3 en/of met andere servers.

Key Agent forward werkt als volgt:
Home:
- SSH key agent running on some socket
- Adds key material to agent (decrypts if needed)

Home -> Connects to UserA@Server1 with Agent forward:
- SSH -> Opens Socket locally that proxies request to Socket on Home of SSH-AGENT
- Adds SSH-AGENT environmental values to Environment
- Runs Shell in created Environment

Attacker@Server1 (with root privlidges) now has the following acces:
- can send request to SSH-AGENT to Encrypt / Decrypt Blocks with the Secret material in the Agent running on Home.
- can extract the Pub keys of the secrets in the Agent on Home.
- can connect to any server that Atteckter known credentials to and that SSH AGENT has the secret for.

Attacker can not retrieve the Secret, it stays on the machine running the agent (Bar, a CVE that allows Code Execution)
it can't read any other files on the Home either. (it could read the UserA's home for a config file assuming it holds the targeted machines connection details).

there is no querying aside from the list of secrets in pub key format.

and Attacker loses the ability to connect as soon as user disconnects from Server1.

Helpt dat met het begrijpen?

Jazeker, dank!

Het werkt inderdaad anders dan ik dacht: de private key(s) verlaten de PC van de gebruiker niet.

Maar dat maakt weinig uit voor een aanvaller: die kan een nieuw sleutelpaar genereren (dat is, zo te zien precies wat er gebeurde bij matrix.org), waarna die aanvaller zijn public key toevoegt op alle servers waar de legitieme gebruiker toegang tot heeft:

Nu begrijp ik ook de truc van de aanvaller om diens public key in /root/.ssh/authorized_keys2 te "verstoppen" (om de kans op ontdekking zo klein mogelijk te maken).

Kortom, hoewel aanvaller Bob niet de private keys van de legitieme gebruiker kan stelen, kan Bob, zolang de gebruiker ingelogd is op S1, toegang tot al die private keys wel benutten om op andere servers in te loggen en op elk daarvan Bob's public key toe te voegen.

Een veel gemaakte fout is denken dat, als private keys niet kunnen worden gestolen (bijv. omdat ze in een Yubikey, smartcard, TPM of HSM zitten en niet te extracten zijn), het dus veilig is. Maar dat is onzin, iets of iemand zal die private keys moeten kunnen gebruiken om er wat aan te hebben. Als dat de verkeerde iets of iemand is, is je enige winst dat het mogelijk een eenmalig probleem is. Maar ook eenmalig kan desastreuze gevolgen hebben.

Precies, jij snapt het nu.

dit is ook precie sde reden waarom je wanneer je Hardware sleutels / smart cards gebruikt je deze wel zo moet instellen dat er iedere keer interactie nodig is voor het vrijgeven van secret informatie.

of tewel, ze beschermen wel extreem goed tegen stelen van het geheim, maar niet tegen misbruik van het geheim.