Kritieke kwetsbaarheid in PuTTY laat aanvaller bepaalde private keys stelen
Een kritieke kwetsbaarheid in de populaire ssh-client PuTTY maakt het mogelijk voor aanvallers om bepaalde private keys te stelen. Het gaat dan specifiek om 521-bit ECDSA private keys. Het beveiligingslek is aanwezig in PuTTY versie 0.68 tot en met 0.80. Er is een nieuwe versie (0.81) uitgebracht waarin het probleem is verholpen.
Het beveiligingslek (CVE-2024-31497) is aanwezig in de code die ECDSA (Elliptic Curve Digital Signature Algorithm) private keys gebruikt voor het genereren van signatures. Een aanvaller die een tiental gesigneerde berichten en de public key in zijn bezit heeft, beschikt dan over voldoende informatie om de betreffende private key te achterhalen. Vervolgens kan de aanvaller signatures vervalsen alsof ze van de gebruiker afkomstig zijn en op elke server inloggen waarvoor de key gebruikt wordt.
Gebruikers die een dergelijke key gebruiken wordt opgeroepen om die meteen in te trekken, de oude public key van alle OpenSSH authorized_keys files te verwijderen, en het equivalent in andere ssh-servers. Daardoor heeft een signature van de gecompromitteerde key geen waarde meer. Vervolgens moet er een nieuw key pair worden gegenereerd om het oude key pair te vervangen.
Het probleem wordt niet veroorzaakt hoe de betreffende key is gegenereerd. Het maakt dan ook niet uit of die via PuTTYgen is gemaakt of ergens anders. Het gaat erom of die ooit met PuTTY of Pageant (PuTTY authentication agent) is gebruikt. Het enige type key dat hiermee te maken heeft is 521-bit ECDSA, die in Windows PuTTYgen als ecdsa-sha2-nistp521 wordt weergegeven of de beschrijving 'NIST p521' heeft. Andere groottes van ECDSA of andere key-algoritmes zijn niet kwetsbaar.
https://www.openwall.com/lists/oss-security/2024/04/15/6
De samenvatting is correct - het probleem bestaat (alleen) als een key van dit type en lengte _door Putty gebruikt is_ en de aanvaller ermee gemaakte signatures heeft kunnen oogsten (offline , als commit signatures bijvoorveeld, of on-line op een compromised ssh server).
Net stukje uitleg over het onstaan van deze bug.
Totaal ander klasse van bug dan een overflow, 'off by one' , uninitialised variable etc etc.
De bug zit er al sinds 2001 in , of sinds ecdsa-521 een supported optie is.
Details of the error:
All DSA signature schemes require a random value to be invented during signing, known as the 'nonce' (cryptography jargon for a value used only once), or sometimes by the letter k. It's well known that if an attacker can guess the value of k you used, or find any two signatures you generated with the same k, then they can immediately recover your private key.
This means that it's dangerous to generate DSA signatures on systems with no high-quality source of randomness. Significantly more dangerous than generating the encryption keys for a single session: a leak of the private key compromises far more than one SSH session.
For this reason, since PuTTY was developed on Windows before it had any cryptographic random number generator at all, PuTTY has always generated its k using a deterministic method, avoiding the need for random numbers at all. The clever trick is to compute a secure hash whose input includes the message to be signed and also the private key. Secure hash output is indistinguishable from random data (or else the hash function isn't doing its job), and this generation method can't be repeated by an attacker who's trying to find out the private key – if they could generate the same hash input as you, they'd already have the private key.
This technique is now mainstream, and RFC 6979 documents a specific well-known way of doing it. But PuTTY didn't follow that specification, because we started doing the same thing in 2001, and the RFC wasn't published until 2013.
PuTTY's technique worked by making a SHA-512 hash, and then reducing it mod q, where q is the order of the group used in the DSA system. For integer DSA (for which PuTTY's technique was originally developed), q is about 160 bits; for elliptic-curve DSA (which came later) it has about the same number of bits as the curve modulus, so 256 or 384 or 521 bits for the NIST curves.
In all of those cases except P521, the bias introduced by reducing a 512-bit number mod q is negligible. But in the case of P521, where q has 521 bits (i.e. more than 512), reducing a 512-bit number mod q has no effect at all – you get a value of k whose top 9 bits are always zero.
This bias is sufficient to allow a key recovery attack. It's less immediate than if an attacker knows all of k, but it turns out that if k has a biased distribution in this way, it's possible to aggregate information from multiple signatures and recover the private key eventually. Apparently the number of signatures required is around 60.
To fix this vulnerability, we've completely abandoned PuTTY's old system for generating k, and switched to the RFC 6979 technique, for all DSA and ECDSA key types. (EdDSA keys such as Ed25519 already used a different system, which has not changed.) However, this doesn't affect the fact that information about existing P521 private keys has already been leaked whenever a signature was generated using the old k generator.
als er een pakket is waar de status 1.0 nooit van bereikt gaat worden voordat ik dood ben is het wel putty dacht ik.
kreeg ook al een update van openvpn binnen voor windows, terwijl linux geen probleem had..
nog effe kijken waarom dat het geval is, en of ik nu alle ubiquities moet nalopen.
Waar blijft dat standbeeld voor putty want daar heb ik echt al heel erg veel jaren plezier van gehad.
Bijvoorbeeld, maar is al weer heel lang geleden, vrienden die over huis kwamen. Ook geld gingen verdienen met internep. Maar wat geirriteerd in de salon zaten omdat ik altijd maar het "die zwarte schermen" bezig was. Ze dachten echt dat als je met "die zwarte schermen" kon werken de kassa vanzelf ging lopen.
Uiteindelijk lieten ze me uitlachenderwijs weten dat het gewoon in windows zat en dat ik dat zelf niet eens wist. Zwarte schermen. Helemaal blij en trots ook, want het verschil tussen een DOS prompt of een xterm maakte hun niks uit. Ze hadden ook zwarte schermen. Dus wie dacht ik wel niet dat ik nog was. Alsof ik de enige mocht zijn met het ei van Columbus met mijn zwarte schermen als ze op de koffie kwamen.
Ze zijn niet echt ver gekomen met hun zwarte schermen maar ik had in elk geval geen scheve ogen meer van ze.
Voor putty mag een standbeeld. Iets met een zwart scherm. En een eerbetoon aan al die mensen die geirriteerd zijn dat ze al die dingen toch gewoon zelf zouden moeten kunnen want wie denk jij wel niet dat je bent dan.
Gewoon, de(open) ssh client op linux, bsd of mac bijvoorbeeld.
die gebruiken natuurlijk openssh-client ;-) (of mobaxterm, remmina, terminus, pacmanager, securecrt)
Gewoon, de(open) ssh client op linux, bsd of mac bijvoorbeeld.
Op mijn Windows bak, waar ik dus ook op werk, gebruik ik toch echt PuTTY.
// Niet doorgewinterd, want pas 29 jaar bezig met de diverse OS'en. ;-)
putty is een drama als je er veel gebruik van moet maken, geen tab bladen maar allemaal losse vensters, gedoe met ssh keys want daar moet je eerst wat mee voor je ze kan gebruiken als je ze wilt gebruiken om mee in te loggen op een linux server, geen filetransfer mogelijkheid (drag/drop zoals bij andere clienten) enz enz...
Als antwoord op je vraag, ik ben 'fan' van mobaXterm, die biedt zo veel meer en is gratis voor persoonlijk gebruik.
putty is een drama als je er veel gebruik van moet maken, geen tab bladen maar allemaal losse vensters,
Op de servers onderling scp of rsync.
Maar goed, ik ben er een voorstander van dat iedereen het gereedschap moet gebruiken waar hij/zij/het zich prettig bij voelt.
// Te oud voor nieuwe trucs. ;-)
vrijdag 10 mei 2024, 10:06 door Redactie
https://www.security.nl/posting/841076/Citrix+wijst+beheerders+op+kritieke+PuTTY-kwetsbaarheid+in+XenCenter
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.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
