Onderzoekers kraken encryptiesleutels Zeppelin-ransomware
Onderzoekers zijn er ruim twee jaar geleden in geslaagd om dankzij een kwetsbare encryptiemethode en met behulp van een achthonderd grote cpu-cluster van hostingprovider Digital Ocean de encryptiesleutels van de Zeppelin-ransomware te kraken, zodat slachtoffers sindsdien kosteloos hun data kunnen terugkrijgen. Dat is deze week bekendgemaakt. Afgelopen augustus waarschuwde de FBI organisaties nog voor aanvallen met de Zeppelin-ransomware, die met name tegen medische bedrijven en zorginstellingen is ingezet, maar ook defensiebedrijven, vitale infrastructuur, techbedrijven en onderwijsinstellingen.
De Zeppelin-ransomware is sinds eind 2019 actief. Onderzoekers van securitybedrijf Unit 221B ontdekten begin 2020 een kwetsbaarheid in de gebruikte encryptiemethode, waardoor het mogelijk is om door middel van een bruteforce-aanval de decryptiesleutel in een aantal uur te achterhalen. Zeppelin gebruikt drie verschillende encryptiesleutels voor het versleutelen van bestanden. Na de versleuteling worden de public keys van het systeem verwijderd. Het blijkt echter mogelijk om de volledige encryptie ongedaan te maken door een specifieke public key uit het Windows Register te halen en te kraken.
"Als we de RSA-512 Public Key uit het register kunnen halen, kunnen we die kraken en de 256-bit AES Key krijgen die de bestanden versleutelt", aldus onderzoekers Lance James en Joel Lathrop. De uitdaging was dat de public key na het versleutelen van alle bestanden van het systeem wordt verwijderd. Het lukte de onderzoekers om door middel van verschillende forensische tools de verwijderde public key veilig te stellen en daarna te kraken. Ze maakten vervolgens een tool die dit proces voor slachtoffers automatiseerde.
Hostingprovider Digital Ocean had een cluster van twintig servers beschikbaar gesteld met elk veertig processors om de veilig gestelde keys binnen vier tot zes uur te kraken. Zo konden de onderzoekers allerlei slachtoffers van de Zeppelin-ransomware helpen met het kosteloos terugkrijgen van hun bestanden. Het onderzoek naar de kwetsbare encryptie was begin 2020 al gedeeld met opsporingsdiensten en een selecte groep onderzoekers. Deze week werd het onderzoek voor iedereen openbaar en is het besproken tijdens de Black Hat-conferentie in Riyad Saudi-Arabië besproken.
In 2007 is de RSA Challenge gestopt 'omdat wetenschappers genoeg wisten over de veiligheid van RSA'. Jammer.
In 2007 is de RSA Challenge gestopt 'omdat wetenschappers genoeg wisten over de veiligheid van RSA'. Jammer.
Wat ik uit dit artikel begrijp is dat ze met heel veel moeite en computer kracht na meer dan twee jaar een 256-bits AES key wisten te regenereren.
Heb ik het nu fout begrepen?
In 2007 is de RSA Challenge gestopt 'omdat wetenschappers genoeg wisten over de veiligheid van RSA'. Jammer.
Wat ik uit dit artikel begrijp is dat ze met heel veel moeite en computer kracht na meer dan twee jaar een 256-bits AES key wisten te regenereren.
Heb ik het nu fout begrepen?
De tijdelijke 512 bit RSA sleutel wordt niet goed gewiped door de malware. Met forensische software is deze tijdelijke publieke sleutel van de harde schijf veilig gesteld. Met oude draaiende harddisks moet dit niet moeilijk zijn. Als je SSD net getrimd is zal dit moeilijker zijn maar de RSA sleutel staat nog wel ergens.
Als je een publieke sleutel van 512 bits hebt, heb je door het toepassen van de GNFS ook de private key. Welke gebruikt kan worden om de 256 bit AES sleutel te decrypten.
Maar 512 bits RSA is dus niet voldoende om dat veilig te doen. Dat is het nooit geweest. Jaren negentig versies van PGP raadden 1024 bit RSA sleutels aan. Er waren zelfs versies met 16384 bits RSA (de illegale cyber-knights templar builds). Deze builds waren gebaseerd op de publieke broncode van PGP 2 t/m 6 (versie 1 van PGP had onveilige symmetrische encryptie). Phil Zimmermann is nooit blij met deze builds geweest maar de gasten die ze compileerden waren altijd wel tof.
[knip nette samenvatting van de designfout in de ransomware]
Maar 512 bits RSA is dus niet voldoende om dat veilig te doen. Dat is het nooit geweest. Jaren negentig versies van PGP raadden 1024 bit RSA sleutels aan. Er waren zelfs versies met 16384 bits RSA (de illegale cyber-knights templar builds).
Illegaal is niet het juiste woord - PGP was open source onder een heel ruime licentie, en zolang je je aan die (heel ruime) voorwaarden hield was er niks illegaals aan.
"onofficieel" of "forked" is een betere omschrijving.
Deze builds waren gebaseerd op de publieke broncode van PGP 2 t/m 6 (versie 1 van PGP had onveilige symmetrische encryptie). Phil Zimmermann is nooit blij met deze builds geweest maar de gasten die ze compileerden waren altijd wel tof.
Als Microsoft een open protocol "extend" met incompatibele opties zijn "we" in Open Source land ontzettend boos.
Maar als wat oogklepperige nerds een protocol incompatibel forken om een langere piklengte te showen vinden sommigen dat super tof .
Erg logisch dat Phil zo'n fork met extensies die communicatie met "regular pgp" onmogelijk maken niet zag zitten .
PGP heeft in het hoofddoel gefaald - maar voor zo ver het een kans had, werd die kans al verkleind wanneer er een veelvoud een versies komt die communicatie met andere gebruikers (no shit - dat was het voornaamste doel van PGP) onmogelijk maakt omdat ze zinloos lange keys promoten.
De 'crypto key lengte' knop maximaal open draaien is een beetje vergelijkbaar met een dragster - een volkomen onbruikbare "auto" die op slechts één ding geoptimaliseerd is : topacceleratie/snelheid op een rechte baan van ca 400 meter.
Alle andere eigenschappen die normaal gewenst zijn in een "auto" zijn bij een dragster extreem slecht .
Een "oversized lange crypto key" komt evenzeer met allerlei gebruiksnadelen .
Het is wat dat betreft wel een raadsel waarom de ransomware auteurs voor deze constructie kozen met een korte ephemeral RSA key als tussenstap . Er is zeker (wat) snelheids winst bij kortere keys, maar waarom ze voor een lengte kozen die (al) binnen 'gevorderd amateur' bereik ligt qua factorisatie is raar
Maar als wat oogklepperige nerds een protocol incompatibel forken om een langere piklengte te showen vinden sommigen dat super tof .
Van de "cyber-knights templar builds" herinner ik me niet eerder gehoord te hebben (maar ik kan het makkelijk weer vergeten zijn als het me niet belangrijk leek), terwijl ik wel degelijk al op de hoogte was van PGP toen er in de VS nog een exportverbod voor gold. Laten we zeggen dat ik wel van Microsoft gehoord heb ;-).
Alle andere eigenschappen die normaal gewenst zijn in een "auto" zijn bij een dragster extreem slecht .
Een "oversized lange crypto key" komt evenzeer met allerlei gebruiksnadelen .
Het is een beetje lastig te onderzoeken nu (ik heb geen werkende Windows 98SE), maar je zou een tabel kunnen maken met welke sleutellengtes PGP ondersteunt voor het controleren van handtekeningen en voor het encrypten/decrypten. En welke sleutellengtes PGP ondersteunt bij het aanmaken van een sleutel. Het was zeker niet mogelijk een RSA sleutel groter dan 4096 bits te maken in de officiële versies maar er is een goede kans dat het bij het ontvangen van PGP data van andere builds coulant was.
Wat Imad R. Faiad van CKT wel heeft gedaan is de MDC toevoegen aan PGP 6.5.x CKT. Het GnuPG team had dit toegevoegd aan GnuPG maar niet gedocumenteerd. Daar was destijds een flinke ruzie over ontstaan in alt.security.pgp. Dus dat maakte de CKT versies juist meer compatible met bijvoorbeeld GnuPG.
Het grote nadeel van 16384 bit RSA keys waren de ontiegelijk lange handtekeningen op clear signed berichten.
Maar als wat oogklepperige nerds een protocol incompatibel forken om een langere piklengte te showen vinden sommigen dat super tof .
Het blijft een rare constructie om een incompatibele versie te maken en te zeggen dat het OK is omdat je helemaal amper gebruikt wilt of gaat worden - publiceer het dan niet, als je eigenlijk (ook) vindt dat het niet gebruikt moet worden.
Logisch dat Phil Zimmerman er niet blij mee was - ook al was het niet illegaal of zo iets . Gewoon het zoveelste voorbeeld waarin Open Source graag elkaar de tent uitvecht over een trivaal detail.
Ah - met een beetje google was het wellicht (ook) een license violation van de latere PGP versies die door NetWork Associates Inc gemaakt werden. Dus mogelijk ook technisch 'illegaal' (cq license/copyright violation) . Forks daarvan waren blijkbaar niet toegestaan onder de licentie.
Overigens lijkt het hoofdbezwaar van Phil Z inderdaad dat mensen geen incompatibele versies zouden moeten introduceren/gebruiken.
De vroege PGP versies vielen onder een MIT achtige licentie en die zat in mijn hoofd.
Van de "cyber-knights templar builds" herinner ik me niet eerder gehoord te hebben (maar ik kan het makkelijk weer vergeten zijn als het me niet belangrijk leek), terwijl ik wel degelijk al op de hoogte was van PGP toen er in de VS nog een exportverbod voor gold. Laten we zeggen dat ik wel van Microsoft gehoord heb ;-).
Mij waren ze destijd wel opgevallen , en toen vond ik het al jammer(lijk). Achteraf gezien is PGP toch gefaald , maar een "eco-systeem" van incompatibele versies zou niet goed geweest voor adoptie als het wel voet aan de grond gekregen zou hebben.
Deze posting is gelocked. Reageren is niet meer mogelijk.
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.
