Makers van malware hebben ingebroken op een buildserver van Adobe, om hun malware met een geldig Adobe-certificaat te ondertekenen. Dat heeft het bedrijf bekendgemaakt. Adobe brengt binnenkort nieuwe certificaten uit.
Voor zover bekend zijn twee malware-tools ondertekend met het Adobe-certificaat, schrijft een beveiligingsmedewerker van Adobe in een blog. Door software te ondertekenen met een geldig certificaat van betrouwbare afkomst, zoals Adobe, slaat beveiligingssoftware veel minder snel alarm.
De malware-auteurs bleken hun software te hebben ondertekend door in te breken op een buildserver van Adobe, die het bedrijf gebruikt om sourcecode om te zetten in executables en die ook direct de software ondertekent. Dat betekent ook dat de aanvallers toegang hadden tot de op de buildserver gehoste broncode. Volgens Adobe gaat het om één product waarvan de broncode toegankelijk was, maar om welk product het gaat, is onduidelijk. Alle commits op de broncode zijn nagetrokken om te verifiëren dat de aanvallers geen eigen code hebben toegevoegd.
Adobe gaat alle software die na 10 juli 2012 is ondertekend, een nieuw certificaat geven. Dat wijst erop dat de aanval mogelijk al in juli plaatsvond. Duidelijk is bovendien dat na 10 juli met het getroffen certificaat veel software is ondertekend, waaronder de Windows-versies van Photoshop CS6, Flash Player, Dreamweaver CS6, Premiere CS6 en Flash Professional CS6. Ook een drietal Air-applicaties, die ook op Mac OS X werken, is ondertekend met het getroffen certificaat. Het certificaat zelf is niet gestolen, benadrukt Adobe.
Omdat zo veel software is ondertekend met dit certificaat, is het niet zomaar mogelijk om het certificaat in te trekken. Dat gebeurt pas op 4 oktober, nadat alle software een update heeft gehad met een nieuw certificaat. Volgens Adobe is er geen reden om aan te nemen dat de gemiddelde internetter last kan ondervinden van de malware die is ondertekend met zijn certificaat; die zou waarschijnlijk vooral zijn bedoeld voor gerichte aanvallen. Of dat daadwerkelijk is gebeurd, is nog niet bekend.
De aanval op de certificaatserver is geen goed nieuws voor Adobe, dat de laatste jaren vaak in het nieuws kwam met kwetsbaarheden in zijn Flash Player- en Acrobat-software, die werden gebruikt om internetters aan te vallen.
[Reactie gewijzigd door MneoreJ op vrijdag 28 september 2012 09:24]
[Reactie gewijzigd door mxcreep op zaterdag 29 september 2012 08:04]
Dat vind ik niet en ben het met je stelling oneens, want zelfs in een zwaarbeveiligde kluis kun je inbreken. Niet dat beveiliging de wensen over moet laten. En dat zou geen logica kunnen zijn als ik dat laatste vergelijk met de gemeende stelling.Jouw logica is een beetje als je zegt dat omdat een geldtap-kluis in een buitenmuur moet zitten, het ook heel normaal is dat de Nederlandse bank haar goud kluis ook in een portiekje inbouwt.
Jij komt op een server, waar je misschien alleen maar lees rechten heb voor dat certificaat, en dan nog weet jij het te presteren om ff SVN/CSV/GIT te patchen zodat ze jou code niet kunnen zien?Als ik de aanvaller was geweest had dat geen zin gehad, omdat ik zowel de compiler als alle tools had veranderd om eventuele wijzigingen niet te laten zien.
Lekker aanmatigend. Zo kan ik ook wel met goedkope opmerkingen komen: "beheerder bij Adobe, toevallig?"Sorry, maar jij hebt duidelijk nog niet in de development industrie gewerkt.
Ja, als ik op een server kom die goed beveiligd is en mijn hack heeft me geen bijzondere rechten gegeven lukt me dat natuurlijk allemaal niet. Ik schets een doemscenario op basis van het feit dat een aanvaller je netwerk binnen is gekomen en toegang heeft gehad tot een server waar je software gebouwd wordt. Dat is echt wel een serieus probleem. Men gaat er vaak te makkelijk van uit dat je wel een betrouwbaar overzicht zal hebben van de omvang van de schade, maar de machines vanaf waar je dat overzicht probeert te krijgen zijn niet altijd meer te vertrouwen. Dat is de pest en het fundamentele probleem bij een goede kraak.Jij komt op een server, waar je misschien alleen maar lees rechten heb voor dat certificaat, en dan nog weet jij het te presteren om ff SVN/CSV/GIT te patchen zodat ze jou code niet kunnen zien?
Je hebt dan nog steeds een onafhankelijke manier nodig om de repository te controleren. In het ergste geval, waarin je geen enkele machine meer kan vertrouwen, is de veiligste handeling inderdaad om een nieuwe machine offline in te zetten die gegarandeerd niet gecompromitteerd is. Dat heeft niets te maken met het vervangen van de build server zelf, als dat een virtual is rol je die inderdaad gewoon opnieuw uit. Die nieuwe machine is alleen voor onafhankelijke controle.Of te wel, is een bouw server misschien ge-hacked, boeie, dan deployen we gewoon een nieuwe.
Sorry, maar jij hebt duidelijk nog niet in de development industrie gewerkt.vraag ik me serieus af als er eigenlijk wel aan security gedacht word bij Adobe
Bestaande installaties hebben hier niets mee te maken.Damn heftig,
Op deze manier kun je potentieel veeeeel makkelijker in pc's inbreken op bijna iedere pc draait tegenwoordig wel flash, reader en of air!
De maker kan inderdaad ook Mac malware ermee hebben ondertekend. Echter is Windows veel interessanter door het grootschalige gebruik ervan.Mac potentieel ook gevoelig via Adobe.
Deze inbraak is gewoon gedaan om zelfgemaakte malware te laten lijken op officiële software. Dit zal niet voor een 'grote kraak' gebruikt worden, maar wel om meer computers op het internet te besmetten.Hopelijk wordt het niet in het groot gebruikt, maar met zo'n inbraak moet er een doel zijn geweest vantevoren. Dus ik verwacht dat dit een inbraak is om een grote kraak elders te plegen
[Reactie gewijzigd door The Zep Man op vrijdag 28 september 2012 10:11]
Mijn opmerking sloeg 'dus' op jouw bericht waarin je schreef dat iedere PC wel Flash, Reader en/of Air draait en dat het hierom potentieel veel makkelijker is om in te breken. Bestaande installaties hebben hier geen last van omdat updates via een auto-updater ophalen. Tenzij deze auto-updater verbinding maakt met Adobe zonder SSL (waarbij het ook nog is nodig is om voor een enkele instantie een sessie te spoofen: te veel energie voor een enkele besmetting), is er niets aan de hand.Dit dus even naar jou reactie dat bestaande installaties hier niets mee hebben te maken. Potentieel houd Adobe informatie achter / maken ze minder bekend om paniek te voorkomen. (zet alu hoedje af)
Bij het ondertekenen met een certificaat is een timestamp nodig, zodat men achteraf kan controleren wanneer de software is ondertekend en of toen het certificaat nog geldig was. Het is natuurlijk niet veilig om daarvoor de systeemdatum van de buildcomputer te gebruiken, dus wordt een timestamp van de root certificate gevraagd. Dat is doorgaans een server bij Verisign of zo, en dus is toegang tot internet nodig.Waarom gebeurt een dergelijke procedure niet OFFLINE?
Bij alle software-uitgevers waar ik werkzaam ben geweest werd altijd één buildmachine gebruikt voor alle builds van een product. Als je meerdere machines met wisselende configuraties gebruikt wordt de kans op afwijkingen veel groter - en die krijg je dan juist in de final builds, gemaakt met een buildmachine waarvan de resultaten veel minder zijn getest.Het lijkt me niet dat je alle test en beta builds per sé moet signen.
Dat begrijp ik ook niet, veel organisaties doen dat inderdaad. Het klinkt alsof al die software werd gebouwd op één buildserver, wat helemaal onvoorstelbaar klinkt - je hebt per product een aparte buildserver.Waarom koopt men niet één certificaat per product?
Dat klopt maar dat betekent niet dat die machine de hele tijd aan het netwerk / internet hoeft gekoppeld te zijn.Bij het ondertekenen met een certificaat is een timestamp nodig, zodat men achteraf kan controleren wanneer de software is ondertekend en of toen het certificaat nog geldig was. Het is natuurlijk niet veilig om daarvoor de systeemdatum van de buildcomputer te gebruiken, dus wordt een timestamp van de root certificate gevraagd. Dat is doorgaans een server bij Verisign of zo, en dus is toegang tot internet nodig.
Van een bedrijf als Adobe met X duizend werknemers mag je toch wel verwachten dat ze 2 machines hetzelfde kunnen houden. Ik begrijp je opmerking maar deze is gebaseerd op angst" / onwetendheid bij de beheerder. Er is geen enkele reden waarom 2 dezelfde machines met exact dezelfde software(configuratie) erop een ander resultaat zouden geven bij het builden van softwareBij alle software-uitgevers waar ik werkzaam ben geweest werd altijd één buildmachine gebruikt voor alle builds van een product. Als je meerdere machines met wisselende configuraties gebruikt wordt de kans op afwijkingen veel groter - en die krijg je dan juist in de final builds, gemaakt met een buildmachine waarvan de resultaten veel minder zijn getest.
Mijn ervaringen tot op heden zijn dat zelfs QA en Productie machines afwijken ook al is de intentie ze gelijk te hebben. De geinstalleerde software is vaak niet het probleem. Het zijn de postconfiguraties die afwijken.[...]
Van een bedrijf als Adobe met X duizend werknemers mag je toch wel verwachten dat ze 2 machines hetzelfde kunnen houden. .... Er is geen enkele reden waarom 2 dezelfde machines met exact dezelfde software(configuratie) erop een ander resultaat zouden geven bij het builden van software
Na een maand of zes zijn twee configuraties waarvan wordt aangenomen dat ze identiek zijn, toch anders. Je ziet altijd dat ergens een systeembestandje een andere datum heeft, en zovoorts. Het blijkt onmogelijk om twee systemen voor langere tijd identiek te houden. Als daarna een probleem zich voordoet, en je kan het niet constateren met jouw build, dan wil je bij voorbaat uitsluiten dat het aan de buildserver heeft gelegen.Er is geen enkele reden waarom 2 dezelfde machines met exact dezelfde software(configuratie) erop een ander resultaat zouden geven bij het builden van software
Niets ten kwade van jou maar dat zullen niet al te complexe builds zijn. Ik heb gewerkt met processen waar de software wordt gecompileerd en gelinked, daarna ondertekend, vervolgens werd een setup en patch vanaf de vorige versie gemaakt, waarna die setup en patch ook werden ondertekend, waarna de setup automatisch werd geinstalleerd op een tiental computers, waar automatische testscripts werden uitgevoerd. En daarnaast veel logging, source control zaken enz. Met dit soort buildprocessen zie je dat het buildproces zelf ook invloed heeft op de uiteindelijke build - en je wil niet twee of meer buildprocessen onderhouden.Daarnaast zijn builden en signen eigenlijk aparte processen. Ik heb iig altijd eerst een build gedaan en deze daarna met een andere tool gesigned.
[Reactie gewijzigd door Sorcerer8472 op vrijdag 28 september 2012 10:10]
Dat ze 11.4 nog niet aanbieden is één ding, maar volgens mij geven ze redelijk vaak een update van 11.2. De laatste versie is van 11 augustus 2012, wat mij redelijk recent lijkt.Nou, als Adobe niet al z'n goodwill al kwijt was na het onbegrijpelijke linuxdebacle met hun Flash-client dan zijn ze het nu wel (youtube-filmpjes hebben nog steeds verkeerde kleuren, want ze bieden geen support meer op Linux en hun laatste update maakte alles stuk, los van dat de stabiliteit en performance een beetje jammer is)...
Je hoeft geen Flash te gebruiken. Als ontwikkelaar kan je bijvoorbeeld ook voor Java kiezen. Net zo onveilig met de browser-plugin en ook onderhevig aan updates die wel eens backwards compatibility kunnen breken, maar het is een (multi-platform) alternatief.Of het debacle waarbij ze expres bepaalde opties in de flash client reserveerden voor een dochterbedrijf dat bepaalde specialistische diensten aanbood: p2p streaming en echo cancellation, het zat er al een hele tijd in maar normale developers konden er niets mee omdat het expres niet toegankelijk werd gemaakt
[Reactie gewijzigd door The Zep Man op vrijdag 28 september 2012 11:53]
[Reactie gewijzigd door markwiering op vrijdag 28 september 2012 11:29]
Op dit item kan niet meer gereageerd worden.
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Apple Microsoft Sony Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True