Hackersgroepering kraakt OpenSSL-website

Een hackersgroepering die opereert onder het alias TurkGuvenligi heeft de website van OpenSSL, een opensource-implementatie van het ssl/tls-protocol, gekraakt. Daarbij werd op de homepage een korte tekst geplaatst.

OpenSSL wordt breed gebruikt om in software die met internet communiceert tal van cryptografische algoritmen toe te passen. Via Openssl.org wordt de code, die beschikbaar is onder een Apache- en BSD-licentie, door vrijwilligers onderhouden en verbeterd. Zaterdag is de website echter aangevallen door hackers. Op de homepage was de tekst 'TurkGuvenligiTurkSec Was Here @turkguvenligi + we love openssl _' te lezen. Korte tijd later was de normale webpagina weer beschikbaar. De beheerders van Openssl.org hebben nog niet op de hack en de defacement gereageerd.

Onder de naam @turkguvenligi is op Twitter de hack geclaimd. De Turkse hackersgroepering, die in 2011 ook al in het nieuws kwam met defacements, lijken geen kwalijke bedoelingen te hebben; zo zijn er geen andere pagina's gewijzigd. Mogelijk wilden de hackers met de aanval een kwetsbaarheid op de website aantonen. Een hacker die kwaad zou willen doen zou echter in theorie gemanipuleerde OpenSSL-bestanden op de webserver kunnen plaatsen. Daarin zouden bijvoorbeeld achterdeurtjes aangebracht kunnen zijn.

Reacties (31)

[WhatsappHack]

Hehe... het is lichtelijk ironisch. Toch kleeft hier een probleempje aan, wie zegt dat zij de eerste zijn die ingebroken hebben?
Zat groeperingen, en overheidsinstanties, die er enorm van benefitten als toegang tot deze servers verkregen kan worden... Die zitten dan niet op publiciteit te wachten en defacen niet...

Hopelijk was het louter een simpele site hack, en is er niet, aldanniet door een andere groep, een veel grotere privilege escalation verkregen.

[the_stickie]

Ik mag hopen dat beveiligingsbedrijven degelijke maatregelen nemen om hun online vertegenwoordiging te beschermen. Het lijkt me niet overdreven webservers te auditie/controleren/monitoren. Met name gewijzigde bestanden op het publieke deel van de website en installatie van software moeten opgemerkt worden in een beveiligde omgeving.

[Hanterp]

Turkse hackersgroepering, die in 2011 ook al in het nieuws kwam met defacements, lijken geen kwalijke bedoelingen te hebben; zo zijn er geen andere pagina's gewijzigd.

Zo! Dus het kraken van OpenSSL wordt niet als kwalijke bedoeling gezien?
Is er dus al zo'n gewenning t.o.v. het hacken opgetreden dat dit al niet meer ernstig wordt gevonden?
Verloedering van het internet is nabij

[YGDRASSIL]

Je kunt het ook zien als een publieke demonstratie van hoe makkelijk het blijkbaar is om sites waarop betrouwbare informatie moet staan binnen te komen. Elke organisatie met resources kan dit dus ook en de vraag is hoeveel binaries met backdoors er rondslingeren die van 'betrouwbare' sites komen.

Maar zodra de NSA en al die anderen overal alles kunnen lezen zal de verloedering inderdaad afnemen. Dan nog een partij aan de macht die de eigen denkbeelden aan de rest wil opleggen en dan krijg je echt een brandschoon Internet volledig volgens 1 moraal.

[Anoniem: 480243]

Ja, want dat geeft een duwtje in de goede richting. Iemand anders kan het ook eerst doen.

[Pieter van Ras]

Nee op deze manier vind ik dat geen kwalijke bedoelingen hebben.
Ten eerste: Als zij het kunnen, kunnen criminelen/overheden met minder goede bedoelingen het wss ook wel. Ten tweede hebben ze het op deze manier reelijk subtiel onder de aandacht gebracht, waardoor men bij OpenSSL & gebruikers van OpenSSL op de hoogte is.

[koesie10]

Je zou toch verwachten dat een website waarop bestanden worden verspreid die een heleboel websites veiliger maken goed beveiligd is?

[Room42]

Hun core business is het beveiligen van verbindingen. Grote kans (niet onderzocht) dat ze een standaard CMS gebruken voor de site. Ik hoop wel dat ze de source code en binaries goed beschermd hebben (dus totaal losstaand van de site), zodat ze daarvan de authenticiteit kunnen garanderen.

Desalnitemin sta je wel in je hempie als je site gedefaced wordt.

[WhatsappHack]

Ik neem aan dat er wel MD5 oid checks bij zitten, maar ook dat valt mee te klooien natuurlijk.

Impact op webservers zal denk ik sowieso laag zijn, afhankelijk van hoelang een server mogelijk gehacked is.
CentOS/RHEL bijvoorbeeld dat op enorm veel servers gebruikt wordt doen er wel ff over om nieuwe versies te implementeren... Die kijken de code nu ook wel driedubbel na dunkt me.

[Reactie gewijzigd door WhatsappHack op 24 juli 2024 07:36]

[HenkEisDS]

Een signature heeft geen nut als de bron waarvandaan je de signature haalt gecompromitteerd is. Een slimme hacker zal de signature van de broncode inclusief de ingebakken malware opnieuw berekenen en op de site zetten.

Volgens mij heeft een signature alleen zin als deze op een veilige bron staat opgeslagen. Eigenlijk zal deze dus van één of meerdere andere sites gehaald moeten worden omdat het moeilijker is om meerdere CMS tegelijkertijd te hacken. Als één van de sites niet meer dezelfde signature heeft als de rest zou bij alle andere signatures een waarschuwing moeten komen te staan.

[Anoniem: 466420]

Niet helemaal. Signatures maken gebruik van assymetrische cryptografie: enkel de bezitter van een geheime 'private key' kan deze handtekeningen zetten, en iedereen kan vervolgens met de corresponderende 'public key' deze handtekening verifieren. Checksums die enkel een hash functie als MD5 of SHA265 gebruiken zijn geen signatures, en kunnen net zo makkelijk vervalst worden als de binary zelf (tenzij ze op twee verschillende plaatsen gehost worden).

Public keys horen voor de hele wereld bekend te zijn. Het verspreiden van deze sleutels is echter een lastig probleem: als je een publieke sleutel van OpenSSL ontvangt moet je zeker weten dat deze niet onderweg is aangepast en dat de partij die jou de sleutel geeft daadwerkelijk OpenSSL is. Als dit niet het geval is zou namelijk de aanvaller jou een eigen publieke sleutel kunnen geven (waarvan die de bijbehorende geheime sleutel kent) en vervolgens aangepaste binaries van OpenSSL opnieuw kunnen ondertekenen.

Er zijn verschillende oplossingen, maar geen van deze zijn perfect: SSL/TLS maakt bijvoorbeeld gebruik van een Public Key Infrastructure (PKI), waarbij een vertrouwde 'Certificate Authority' zelf een digitale handtekening achter een publieke sleutel zet waarvan is geverifieerd dat deze bij de juiste partij hoort. PGP gebruikt daarintegen een zogenaamd web of trust, een decentraal systeem waarbij gebruikers elkaars sleutels signeren totdat je met vertrouwen een uitspraak over de authenciteit ervan kan doen.

Bijna niemand checkt echter handmatig signatures (noch checksums) van binaries die via het internet worden gedstribueert, dus in deze context zijn ze niet erg nuttig. Windows-executables kun je wel signen (na een certificaat aangevraagt te hebben van Microsoft), wat erin resulteert dat je bedrijfsnaam weergegeven wordt in het 'weet je zeker dat je dit wilt uitvoeren?'-dialoog. Dit wordt echter ook massaal genegeerd en is ook best nutteloos.

Een stuk veiliger is het om je binaries te distribueren via een 'package manager' die zelf signatures verifieerd. Alle grote Linuxdistributies maken hier gebruik van. Als je toch je software via een website wilt aanbieden, is het beste wat je kunt doen SSL/TLS voor de site gebruiken (om integriteit van de binaries te garanderen) en proberen te voorkomen dat je gehackt wordt.

[Ventieldopje]

En als de bron gecompromiteerd is er een grote kans dat de hacker ook de private key heeft en dus lekker allemaal malafide packages kan gaan signeren

[.Peter.]

Je kunt niet meteen concluderen dat men toegang tot de private signing key hebt als de server is gecompromiteerd. Voor een ontwikkelaar van OpenSSL mag ik toch wel verwachten dat ze minstens een smartcard o.i.d. hebben waar de sleutel in zit. Ondertekenen van bestanden wordt dan hierdoor uitgevoerd, de sleutel verlaat nimmer de hardware.

@AardvakSoep Een web-of-trust is minstens even veilig als de package manager. Tenslotte halen de distributies ook hun sources ergens vandaan, deze worden ook geverifieerd met checksums (md5, sha1, sha256, etc.) of signatures (gpg). De publieke sleutel hoef je maar één keer ergens vandaan te halen, daarna kun je het altijd hergebruiken (totdat de sleutel verlopen of teruggetrokken is).

SSL/TLS helpt niet als de server zelf wordt gecompromiteerd (of als een CA valse certificaten verstrekt). Het wordt gebruikt voor de versleuteling van de verbinding. Voor binaries of sources zouden signatures het veiligste zijn, deze kun je niet zomaar terugtrekken, de integriteit blijft en je kunt er ook zeker van zijn dat het authentiek is.

[_JGC_]

Een gpg key is als een bankpas: die laat je niet op publieke plekken slingeren en is beveiligd met een code. Bij verlies laat je de key intrekken net zoals je een bankpas laat blokkeren.

Als ik een key validation doe op de openssl sources en dat ding is gesigned met een andere key, dan valt dat meteen op.

[Treenaks]

MD5 is broken. Maar inderdaad, OpenSSL-source wordt geleverd met PGP signatures.

[esak]

Bron? Als je "a597112f6b3b6a6750d1b58c34ab60ab" weet te kraken krijg je van mij een gelijk.

[CAPSLOCK2000]

Heb je zelf onderzoek gedaan voor je om een bron begint te vragen? Zelfs wikipedia was genoeg geweeest: http://nl.wikipedia.org/wiki/MD5

md5 is nog niet zo stuk dat je ieder hash onmiddelijk kan kraken, maar er zijn te veel problemen om het nog te blijven gebruiken voor beveiliging.

[esak]

Dat heb ik zeker gedaan. Ik zeg ook zeker niet dat md5 nog steeds een goede keus is om te gebruiken bij alle applicatie's echter is het zeker niet zo dat het helemaal onveilig is.

Wachtwoorden etc. moet je niet meer hashen met md5 maar er zijn tal van applicatie's die niet zo een top cryptografische hash nodig hebben en dus nog prima md5 kunnen gebruiken. Daarom vind ik hem niet broken. Zo zie ik bijvoorbeeld ook niet bij wikipedia dat onderzoekers de originele bron hebben gevonden maar "slechts" een collision.

Wat ik veel zorgelijker vind is dat sommige bedrijven limieten zetten op wachtwoorden als "maximaal 12 karakters", "er moet wel/niet een cijfer inzitten".

[Slurpgeit]

Het heeft niks te maken of je de plain-text weer kan terugvinden van een hash, maar of je twee verschillende items met dezelfde hash kan genereren, ook wel bekend als hash collisions. Zoals bijvoorbeeld: http://learncryptography.com/hash-collision-attack/, http://eprint.iacr.org/2010/643 of http://th.informatik.uni-...ple/lucks/HashCollisions/.

Daarnaast is MD5 nooit ontworpen om informatie veilig mee op te slaan, maar alleen om te zien of twee dingen gelijk zijn aan elkaar. Daarom is een MD5 hash berekenen van iets ook snel, terwijl je voor bijvoorbeeld wachtwoorden een algoritme is wat zo langzaam mogelijk is.

[ReTechNL]

MD5: a597112f6b3b6a6750d1b58c34ab60ab
Plain: cracking...

[esak]

? De tool die je gebruikt lukt het blijkbaar niet om het te cracken en daarom geeft hij "cracking..." terug, want dat is in iedergeval niet de plain tekst van de md5!

[Puch-Maxi]

Die hash is dus nog niet gekraakt Of bedoelde je dat?

[blorf]

Ik kan me voorstellen dat de concurrentie uit de commerciele hoek zal proberen het er zoveel mogelijk in te wrijven. I.i.g. lijkt het daar nu al erg op. Openssl zelf is slechts een toolkit/library die op zichzelf niets te verbergen heeft. Met het nieuws omtrent het hacken van hun homepage lijkt het alsof er een gecentraliseerde security-gerelateerde organisatie is aangevallen en wordt de SSL onterecht als onbetrouwbaar afgespiegeld.
Het zal wel nooit naar buiten komen maar ik ben erg benieuwd naar het echte motief van deze defacement en of dat ook geld heeft opgebracht.

[Reactie gewijzigd door blorf op 24 juli 2024 07:36]

[dipje2]

Ik neem inderdaad aan (maar geen idee for sure) dat dingen zoals de repositories niet op dezelfde (fysieke) server staan.

Dat ze de downloads kunnen aanpassen is al erg, maar zolang de source maar 'breach-free' is kan je er vanuit gaan dat een volgende versie gewoon weer veilig is.

Backups terugzetten van je CMS / site, mensen op hun hart drukken dat ze de hashes controleren van de downloads en niks aan de hand.

Aan de andere kant, als de source er op staat en je moet uit gaan van 'de goede bedoelingen' van de hackers, dan vind ik het enger, en moet er (juist voor een project als OpenSSL) uitgebreid gecontroleerd gaan worden of de source niet veranderd is.

[2TheMaks]

Ik hoop wel dat ze de source code en binaries goed beschermd hebben

Uiteraard maakt OpenSSL gebruik van een Source Code Management (SCM) systeem, in dit geval Git. De integriteit van de Git source repositories is te valideren, hetgeen reeds gebeurd is. Overigens staat er een clone van de OpenSSL repositories op Github, welke door de hackers gelijktijdig veranderd had moeten worden om aanpassingen/backdoors te verbergen.

Alle aanpassingen in Open Source code, of deze nu van bonafide contributors afkomstig zijn of van hackers, zullen eerst op een development branche van de SCM-repository terecht komen. Pas na goedkeuring middels een code review proces kunnen aanpassingen terecht komen op een z.g.n. stable branche van de SCM-repository. Dit zal bij OpenSSL ongetwijfeld ook het geval zijn.

Wanneer Open Source code (bijv. OpenSSL) opgenomen word in bijvoorbeeld een Linux distributie kan er door de distributeur (bijv. RHEL) nogmaals een code review gedaan worden om ongewenste backdoors te voorkomen.

Veilige broncode kan overigens alsnog een binary met gaten opleveren als tijdens het compileren onzorgvuldig met compiler-optimalisatie settings word omgegaan!!!

[Reactie gewijzigd door 2TheMaks op 24 juli 2024 07:36]

[Soldaatje]

Alle bestanden zijn ondertekend met PGP, dat zou dan toch veilig moeten zijn zolang de hackers de sleutel niet in handen krijgen?

[Wampa1]

Dat zal even schrikken zijn geweest daar bij OpenSSL. Ik mag inderdaad hopen dat het niet meer is dan een defacement anders gaan ze een naar traject in.

[flossed]

Bijzonder, Gisteren en vandaag de hele dag op Openssl.org geweest, niets gemerkt van een defacement.

[CAPSLOCK2000]

Ik neem aan dat een club als OpenSSL het snel door heeft als er iets gebeurd en onmiddelijk in actie komt. Het zou me niet verbazen als het minder dan een kwartier heeft geduurd.

[Will_M]

Wij van WC-Eend adviseren....