Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
vuln: fwd ssh-agent + libs
27-07-2023, 12:48 door Erik van Straten, 7 reacties
Volledige titel:
Vulnerabilities in OpenSSH’s forwarded ssh-agent en in Linux libraries/lib-management
Vorige week publiceerde Qualys "CVE-2023-38408: Remote Code Execution in OpenSSH’s forwarded ssh-agent" ([1], bron: [2]), en dit deed mij denken aan mijn laatste post over RDP [3] (reacties over RDP s.v.p. aldaar). In het kort: indien je jouw systeem niet gepatched hebt kan, als agent forwarding aan staat (hetgeen de default lijkt in bekende Linux distro's), indien je met OpenSSH inlogt op een gecompromitteerde server, ook jouw client-account (of jouw hele client-systeem) gecompromitteerd raken.
De technische analyse daarvan [3] vond ik interessant (die tekstfile leest niet lekker op een smal scherm door de "harde regeleinden" op regels van 72 tekens lang, mogelijk gaat dat beter door die file lokaal op te slaan en dan met een lokale editor te openen). Met een fuzzer zagen de onderzoekers van Qualys veel "rommelig" gedrag, met de potentie om ASLR, PIE, en NX te omzeilen. Dit onderzoek kon daarom nog wel eens een staartje krijgen (met kwetsbaarheden in allerlei andere toepassingen en services).
OpenSSH Agent Forwarding betekent sowieso het nemen van fikse risico's, zoal Matrix.org in 2019 ondervond: zie [5] en lees vooral nog eens de m.i. goede "Post-mortem and remediations for Apr 11 security incident" [6].
[1] https://blog.qualys.com/vulnerabilities-threat-research/2023/07/19/cve-2023-38408-remote-code-execution-in-opensshs-forwarded-ssh-agent
[2] https://www.heise.de/news/OpenSSH-9-3p2-dichtet-hochriskantes-Sicherheitsleck-ab-9222861.html
[3] https://www.security.nl/posting/801650/RDP+risico%3A+rest+verwijderd+om+off+topic+BS+te+verhinderen
[4] https://www.qualys.com/2023/07/19/cve-2023-38408/rce-openssh-forwarded-ssh-agent.txt
[5] https://www.security.nl/posting/608805/SSH+agent+forwarding+en+Jenkins-lek+nekten+Matrix_org
[6] https://matrix.org/blog/2019/05/08/post-mortem-and-remediations-for-apr-11-security-incident/
Vulnerabilities in OpenSSH’s forwarded ssh-agent en in Linux libraries/lib-management
Vooraf: off-topic reacties worden niet op prijs gesteld. Begin je eigen draad als je denkt dat lezers van security.nl in een ander onderwerp geïnteresseerd zouden kunnen zijn. On topic zijn kwetsbaarheden in SSH en (of veroorzaakt door) Linux libraries + management daarvan, en veilig remote beheer uitvoeren (op niet-Microsoft-systemen).
Vorige week publiceerde Qualys "CVE-2023-38408: Remote Code Execution in OpenSSH’s forwarded ssh-agent" ([1], bron: [2]), en dit deed mij denken aan mijn laatste post over RDP [3] (reacties over RDP s.v.p. aldaar). In het kort: indien je jouw systeem niet gepatched hebt kan, als agent forwarding aan staat (hetgeen de default lijkt in bekende Linux distro's), indien je met OpenSSH inlogt op een gecompromitteerde server, ook jouw client-account (of jouw hele client-systeem) gecompromitteerd raken.
De technische analyse daarvan [3] vond ik interessant (die tekstfile leest niet lekker op een smal scherm door de "harde regeleinden" op regels van 72 tekens lang, mogelijk gaat dat beter door die file lokaal op te slaan en dan met een lokale editor te openen). Met een fuzzer zagen de onderzoekers van Qualys veel "rommelig" gedrag, met de potentie om ASLR, PIE, en NX te omzeilen. Dit onderzoek kon daarom nog wel eens een staartje krijgen (met kwetsbaarheden in allerlei andere toepassingen en services).
OpenSSH Agent Forwarding betekent sowieso het nemen van fikse risico's, zoal Matrix.org in 2019 ondervond: zie [5] en lees vooral nog eens de m.i. goede "Post-mortem and remediations for Apr 11 security incident" [6].
[1] https://blog.qualys.com/vulnerabilities-threat-research/2023/07/19/cve-2023-38408-remote-code-execution-in-opensshs-forwarded-ssh-agent
[2] https://www.heise.de/news/OpenSSH-9-3p2-dichtet-hochriskantes-Sicherheitsleck-ab-9222861.html
[3] https://www.security.nl/posting/801650/RDP+risico%3A+rest+verwijderd+om+off+topic+BS+te+verhinderen
[4] https://www.qualys.com/2023/07/19/cve-2023-38408/rce-openssh-forwarded-ssh-agent.txt
[5] https://www.security.nl/posting/608805/SSH+agent+forwarding+en+Jenkins-lek+nekten+Matrix_org
[6] https://matrix.org/blog/2019/05/08/post-mortem-and-remediations-for-apr-11-security-incident/
Reacties (7)
27-07-2023, 14:18 door
Sysosmaster
als agent forwarding aan staat (hetgeen de default lijkt in bekende Linux distro's), indien je met OpenSSH inlogt op een gecompromitteerde server, ook jouw client-account (of jouw hele client-systeem) gecompromitteerd raken.
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:
-A Enables forwarding of connections from an authentication agent such as ssh-agent(1). This can also be specified on a per-host basis in a configuration file.
Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's UNIX-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent. A safer alternative may be to use a jump host (see -J).
zie ook de release notes:
* Exploitation requires the presence of specific libraries on
the victim system.
* Remote exploitation requires that the agent was forwarded
to an attacker-controlled system.
the victim system.
* Remote exploitation requires that the agent was forwarded
to an attacker-controlled system.
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
Door Sysosmaster: SSH doet niet standaard de SSH-AGENT forwarden naar de remote, om dit te doen. moet je dit bewust aanzetten:
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]:
As a result, several of the team doing ops work had set Host *.matrix.org ForwardAgent: yes in their ssh client configs, thinking “well, what can we trust if not our own servers?”
This was a massive, massive mistake.
This was a massive, massive mistake.
Door Sysosmaster: An sich is er niets mis met forwarden van je agent als je weet wat je doet,
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]:
The attacker put an SSH key on the box, which was unfortunately exposed to the internet via a high-numbered SSH port for ease of admin by remote users, and placed a trap which waited for any user to SSH into the jenkins user, which would then hijack any available forwarded SSH keys to try to add the attacker’s SSH key to root@ on as many other hosts as possible.
Nadat iemand in die val getrapt was:
In this process, we spotted an unrecognised SSH key in /root/.ssh/authorized_keys2 on the Jenkins build server. This was suspicious both due to the key not being in our key DB and the fact the key was stored in the obscure authorized_keys2 file (a legacy location from back when OpenSSH transitioned from SSH1->SSH2). Further inspection showed that 19 hosts in total had the same key present in the same place.
Zo raakt je hele infrastructuur gecompromitteerd.Door Sysosmaster: toch adviseer ik altijd om gebruik te maken van een JumpHost in plaats van een Agent Forward,
Dat is ook één van de adviezen in [6].Door Erik van Straten:
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".
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.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".
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.
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").
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.
Je weet niet wat je doet - in de zin van dat als een server gecompromitteerd is, je het probleem van kwaad tot erger maakt.
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...
01-08-2023, 16:57 door
Erik van Straten
Door Sysosmaster: [...] 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.
Ik weet niet zeker of die aanname niet klopt.immers deze heeft, als je weet wat je doet, geen key materiaal in zich behalve voor de huidige verbinding.
Als ik het goed begrijp werkt SSH forwarding normaal gesproken (server S1 is niet gecompromitteerd), als volgt:
get key: S2
.———————————.
O v ^
/|\ [PC]———————>[S1]———————>[S2]
/ \ ssh#1 ssh#2
.———————————.
O v ^
/|\ [PC]———————>[S1]———————>[S2]
/ \ ssh#1 ssh#2
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:
get key: S2 (+stil: S3,S4,S5,...)
.———————————.
O v ^
/|\ [PC]———————>[S1]———————>[S2]
/ \ ssh#1 | ssh#2
|
+————————>[S3]
+————————>[S4]
+————————>[S5]
[...]
.———————————.
O v ^
/|\ [PC]———————>[S1]———————>[S2]
/ \ ssh#1 | ssh#2
|
+————————>[S3]
+————————>[S4]
+————————>[S5]
[...]
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.
01-08-2023, 18:05 door
Sysosmaster
Door Erik van Straten:
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:
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:
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?
Door Sysosmaster:[...]
Helpt dat met het begrijpen?
Jazeker, dank!Helpt dat met het begrijpen?
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:
user get key: S2 (+ S3, S4,...)
.———————————.
O v ^
/|\ [PC]———————>[S1]———————>[S2]
/ \ ssh#1 • | ssh#2 ^
• | |
• | Bob adds |
Bob O | his pubkey|
(attacker) /|\ +———————————'
/ \ |
| Bob ssh#3
| and adds
| his pubkey
+—————————>[S3]
|
| Bob ssh#4
| and adds
| his pubkey
+—————————>[S4]
:
.———————————.
O v ^
/|\ [PC]———————>[S1]———————>[S2]
/ \ ssh#1 • | ssh#2 ^
• | |
• | Bob adds |
Bob O | his pubkey|
(attacker) /|\ +———————————'
/ \ |
| Bob ssh#3
| and adds
| his pubkey
+—————————>[S3]
|
| Bob ssh#4
| and adds
| his pubkey
+—————————>[S4]
:
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.
02-08-2023, 18:50 door
Sysosmaster
Door Erik van Straten: 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.
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.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
IT Security Officer
Utrecht heeft jou nodig! Als Information Security Officer vertaal je beleid naar technische uitvoering. Dit is cruciaal voor het waarborgen van de informatiebeveiliging van onze inwoners. Je krijgt de kans om betrokken te zijn bij complexe projecten met de nieuwste technologieën en kunt jouw stempel drukken op innovatie. Solliciteer nu!
Ketenregisseur Gedigitaliseerde Criminaliteit en Cybercrime
Ben jij er klaar voor om de leiding te nemen in het bevorderen van de regionale samen-werking in de strijd tegen gedigitaliseerde criminaliteit en cybercrime? Samen met collega's, politie en regionale en landelijke partners? Dan is de dynamische rol van Ketenregisseur Gedigitaliseerde Criminaliteit en Cybercrime bij het Regionaal Samenwerkingsverband Integrale Veiligheid (RSIV) jouw op het lijf geschreven!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.