Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 51 reacties •
Submitter: RealSovereign

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.

Adobe LogoVoor 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.

Lees meer over

Gerelateerde content

Alle gerelateerde content (10)
Moderatie-faq• Wijzig weergave

Reacties (51)

-151051+138+28+30Ongemodereerd7
1 2
+2 WhiteDog
28 september 2012 09:34
Wat ik niet begrijp:
- Waarom koopt men niet één certificaat per product? Een Code Signing certificaat kost je amper 100 ¤.
- Waarom gebeurt een dergelijke procedure niet OFFLINE? Het lijkt me niet dat je alle test en beta builds per sé moet signen. Enkel final builds moet je even signen wat perfect offline kan. En als het echt moet gebruik je voor de rest maar een ander of self-signed certificaat.
+1 daan.timmer
@WhiteDog • 28 september 2012 09:51
het is inderdaad behoorlijk raar dat dergelijke systemen überhaupt aan het internet hangen.
+2 MneoreJ
@daan.timmer • 28 september 2012 10:18
Dat is allesbehalve raar. Alleen bij jongens die echt serieus werk maken van beveiliging komt het idee van offline machines uberhaupt op. Voor alle andere mensen weegt het gemak van machines centraal kunnen administreren en bereiken via het netwerk (met de daarbij behorende kostenbesparing) makkelijk op tegen het beveiligingsvoordeel.

Merk op dat de build server hoogstwaarschijnlijk niet aan het internet hing -- zo ja, dan moet er inderdaad iemand ontslagen worden -- maar dat hoeft ook niet. Je bedrijfsnetwerk hangt ergens op de een of andere manier wel aan het Internet, en er hoeft maar één webservertje de klos te zijn voor een aanvaller om binnen je eigen netwerk te komen. Nog simpeler, één persoon die even z'n persoonlijke mail checkt waar rommel aan hangt die nog niet door de virusscanner opgepikt wordt.

Goede beheerders timmeren dat allemaal van voor naar achter dicht met DMZs en policies, maar waar gewerkt wordt moeten resultaten behaald worden en er zullen op strategische plekken toch doorgeefluikjes zitten. Beveiliging sneuvelt altijd als eerste als mensen werk gedaan moeten krijgen.

TL;DR: beveiliging is moeilijk en duur en vergt voortdurende en vermoeiende waakzaamheid.
+1 Floor
@MneoreJ • 28 september 2012 10:36
Dat niet alleen. Je kan alles dichttimmeren van voor tot achter maar wanneer een of andere 'handige Harrie" besluit om een wifi punt op een kantoor te installeren omdat het zo makkelijk is kan je al gemakkelijk inbreken.
Dit gebeurd regelmatig.
0 Lennie
@MneoreJ • 29 september 2012 12:28
Een webservertje ? Ik denk eerder dat het via malware op een desktop zijn binnen gekomen.
+1 findftp
@daan.timmer • 28 september 2012 10:02
Is het al bewezen dat het via internet gebeurd is dan?
Wie weet wel via een stuxnet variant of een inside job van een ontevreden medewerker.
+1 SuperDre
@daan.timmer • 28 september 2012 13:21
Zo raar is het niet, hoe wil je anders bij de betreffende systemen komen vanaf verschillende locaties. Het is niet zo dat alle development op 1 plek in hetzelfde gebouw gebeurd..
+1 Free rider
@WhiteDog • 28 september 2012 10:26
Waarom gebeurt een dergelijke procedure niet OFFLINE?
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.
Het lijkt me niet dat je alle test en beta builds per sé moet signen.
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.
Waarom koopt men niet één certificaat per product?
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.
+1 WhiteDog
@Free rider • 28 september 2012 11:09
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.
Dat klopt maar dat betekent niet dat die machine de hele tijd aan het netwerk / internet hoeft gekoppeld te zijn.
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.
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 software 8)7

Daarnaast zijn builden en signen eigenlijk aparte processen. Ik heb iig altijd eerst een build gedaan en deze daarna met een andere tool gesigned.
+1 latka
@WhiteDog • 28 september 2012 11:47
[...]
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 8)7
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.
+1 Free rider
@WhiteDog • 28 september 2012 13:33
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.

Waar ik werkte (meerdere clubs) was het gevolg altijd dat de buildmachine (tegenwoordig VMWare image) bijna heilig werd verklaard. En mede daarom vind ik dit bericht zo bizar: de buildmachine is de best beheerde machine van het bedrijf. En juist die wordt gekraakt.
Daarnaast zijn builden en signen eigenlijk aparte processen. Ik heb iig altijd eerst een build gedaan en deze daarna met een andere tool gesigned.
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.
+1 gjmi
@Free rider • 28 september 2012 11:48
Bij mij op het werk kunnen honderden machines dezelfde build maken. De versies van buildtools zijn per product vastgesteld en staan op het netwerk. Dus elke computer kan een even betrouwbare build maken. Dan kunnen de computers wel knderling verschillende versies van buildtools hebben, maar die worden dus niet gebruikt.
Voor builden heb je niet een enkele computer nodig. Voor signen misschien wel.
+1 Diamondo25
@WhiteDog • 28 september 2012 09:56
- Je gaat niet zo snel 10 certificaten kopen die allemaal 'Gemaakt door Adobe (handtekening)' toevoegt aan het product.
- Waarschijnlijk oude software oid. Het is natuurlijk wel raar dat ze sowieso binnen zijn gedrongen, maar dit kan alsnog via het interne netwerk zijn gebeurd.
+2 MneoreJ
28 september 2012 09:22
Wow, dit is het digitale equivalent van je toegang verschaffen tot een bank om daar toegang te hebben tot de financiële administratie -- nog erger dan wanneer men gewoon de kluis zou hebben leeggeroofd. Dit is ongekend brutaal.

En dan heeft men nog geluk dat het opgemerkt is! Stel je voor dat een aanvaller erin slaagt dit te doen zonder opgemerkt te worden, bijvoorbeeld door een minder opvallende machine aan te vallen en je dan zo goed mogelijk in de build server te nestelen! Vergeet losse malware, letterlijk alle software van Adobe had op deze manier van malware voorzien kunnen worden door de build tools te compromitteren. Het zou de aanval van de eeuw zijn.

"Alle commits op de broncode zijn nagetrokken om te verifiëren dat de aanvallers geen eigen code hebben toegevoegd." 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. Afhankelijk van wat voor source control ze gebruiken en hoe diep de hack gaat kun je dit zo ver doortrekken als je wil. Adobe had hier echt voor miljoenen het schip in kunnen gaan.

[Reactie gewijzigd door MneoreJ op 28 september 2012 09:24]

+1 eL_Jay
@MneoreJ • 28 september 2012 09:53
Ik hoop (en denk) dat Adobe genoeg knappe koppen beschikbaar heeft om ten minste dezelfde conclusie als jou te trekken en vervolgens het budget ook heeft om daarop in te grijpen.
+2 MneoreJ
@eL_Jay • 28 september 2012 10:12
Het budget zeker, maar die "knappe koppen" zijn er wel mooi in geslaagd hun build server toegankelijk te maken met daarop een release-certificaat. Ook knappe koppen kunnen natuurlijk lui zijn, maar dit toont wel een ongezond gebrek aan paranoia aan. Als men nu grondig is doe je dit:
  • Build server uit het netwerk trekken en apart zetten voor latere analyse
  • Nieuwe machines kopen die nooit aan mijn netwerk gehangen hebben, offline prepareren
  • Verse installatie van het SCC-systeem op die machines
  • Fysieke media van de repository attachen aan een nieuwe machine en een backup maken (géén backup maken vanaf live!)
  • Offline backup restoren en vergelijken
En dan weet ik alléén nog maar of de repository nog OK is. Dan moet ik mijn hele build chain nog valideren, en al gebouwde binaries checken op onregelmatigheden...

Ik denk helaas dat het een héél stuk waarschijnlijker is dat men bij Adobe geen heel project heeft opgestart voor het bovenstaande, maar gewoon hoopt dat de aanvallers niet zo inventief zijn geweest om meer te doen dan hun eigen malware ondertekenen. En laten we wel zijn, dat is gelukkig ook het meest waarschijnlijke scenario. Als Adobe pech had gehad waren het niet malwarebakkers geweest maar mensen van de concurrentie, en die hadden heel wat meer gerichte schade aan kunnen richten.
+1 TMDevil
@MneoreJ • 28 september 2012 10:37
Sorry, maar jij hebt duidelijk nog niet in de development industrie gewerkt. Sowieso, een nieuwe server kopen :?
En deze is ook mooi van je:
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.
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?

Even een voorbeeldje van de bouw straat op me werk; Alles draait onder ESX, bouw servers worden automatisch gedeployed en geconfigureerd dmv oa. Puppet.
Of te wel, is een bouw server misschien ge-hacked, boeie, dan deployen we gewoon een nieuwe.

[ontopic]
Dat deze hack heeft kunnen plaats vinden vind ik wel zeer kwalijk voor Adobe, en vooral gezien de aantal lekken in Flash en Reader vraag ik me serieus af als er eigenlijk wel aan security gedacht word bij Adobe :?
+1 MneoreJ
@TMDevil • 28 september 2012 10:54
Sorry, maar jij hebt duidelijk nog niet in de development industrie gewerkt.
Lekker aanmatigend. Zo kan ik ook wel met goedkope opmerkingen komen: "beheerder bij Adobe, toevallig?"

Je mag kritiek leveren zonder op de man te spelen, hoor. Heeft niemand moeite mee.
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?
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.
Of te wel, is een bouw server misschien ge-hacked, boeie, dan deployen we gewoon een nieuwe.
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.

Noem me maar paranoïde. "It's not paranoia if they are really after you."
vraag ik me serieus af als er eigenlijk wel aan security gedacht word bij Adobe :?
Sorry, maar jij hebt duidelijk nog niet in de development industrie gewerkt.

Ik kon het niet laten. :9~
+1 Floor
@MneoreJ • 28 september 2012 10:29
Niet lui maar ervaring. Het gevaar op nalatigheid is zelfs groter bij ervaren mensen dan bij onervaren mensen. Onervaren mensen met kennis van zaken zijn veel alerter op fouten dan ervaren mensen met dezelfde kennis. Dit komt door de routine.
Je ziet dit aspect dan ook terug bij veiligheidstraining en security awereness in de luchtvaart, ruimtevaart en en andere sectoren. Fouten worden sneller over het hoofd gezien wanneer mensen vanuit routine handelen. Goede teams bestaan daarom uit onervaren en ervaren mensen.

Nasa heeft hier bijvoorbeeld heel harde lessen uit getrokken na de crash van de Discovery spaceshuttle.
0 Vendar

@eL_Jay • 28 september 2012 09:57
Vreemd vertrouwen. Als ze zo knap waren dan was deze hack niet mogelijk geweest.
+1 Webmail
@Vendar • 28 september 2012 10:03
Dat is onzin. Anders zou iedereen met het IQ 130+ een website waterdicht kunnen maken. En dat is niet mogelijk. Alles kan gekraakt worden.

Niet mogelijk is niet mogelijk.
+2 sfc1971
@Webmail • 28 september 2012 10:33
Beetje een excuus truus.

Waarom is een build server uberhaupt van buiten te benaderen? Is dit echt iets dat niet puur intern kan worden geregeld?

Een build server is geen productie server die voor de hele wereld beschikbaar moet zijn. Slechts een paar mensen binnen een ontwikkel omgeving hebben hem nodig. Als daar op kan worden ingebroken dan is dit OF intern gebeurt OF een admin dient te worden ontslagen.

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.
+2 Stukjetaart
@sfc1971 • 28 september 2012 10:46
Die stelling is ook een beetje kort door de bocht.

TL/DR: buildserver zal altijd intern aanspreekbaar zijn door pc's die verbonden zijn met het internet.

Een developper heeft toegang nodig tot de buildserver en tot het internet (eventueel om op te zoeken en dergelijke).

Het enige wat de aanvaller hier moet doen is de pc van de developper te compromiteren om toegang te krijgen tot de buildserver.

Het is wel een beetje simplistisch voorgesteld, maar je kunt de buildserver onrechtstreeks niet gemakkelijk van het internet afkoppelen.

Tenzij je de developper steeds met een usb stick wil laten huppelen naar de buildserver, of eventueel door 2 pc's te geven op een verschillend netwerk, 1 om op te zoeken en 1 om code te typen (wat vrij omslachtig is, aangezien daardoor 2 compleet losstaande netwerken moeten opgezet worden, om nog maar niet te spreken om samen te werken met developpers van adobe uit verschillende regio's of zelfs landen.)
+1 Joolee
@Stukjetaart • 28 september 2012 11:08
Je hoeft natuurlijk niet het ondertekenen van de software op de build server uit te laten voeren. Developers kunnen een 'online' build server gebruiken om hun software te testen. Zodra de release versie klaar is wordt de usb stick/laptop met certificaat uit de kluis gehaald, deze wordt gedecodeerd met een wachtwoord dat enkel topmensen hebben, de software wordt getekend en het certificaat gaat encrypted de kluis weer in.

Zeker als groot softwarebedrijf moet het gewoon niet kunnen dat zulke certificaten benaderbaar zijn vanaf het internet. Of er nou firewalls, proxies, non-routerende machines of wat dan ook tussen zitten. Dit is bijna net zo fout als de Diginotar hack.
+1 arjankoole

@Joolee • 28 september 2012 11:17
Jouw methodiek werkt prima, tenzij het een internationaal bedrijf is, waar meerdere developers op projecten werken op verschillende locaties. Daar zijn dergelijke dingen altijd via een centraal beschikbaar systeem geregeld.

Je hebt immers niet per vestiging een Security Manager of CTO die het certificaat kan ondertekenen, om nog maar te zwijgen dat dergelijke mensen het stelselmatig te druk hebben en te vaak op pad zijn om met zulke dingen lastiggevallen te kunnen worden.

M'n vriendin had pas tijdens een audit nog een moment waarbij de inspecteur in kwestie totaal niet kon begrijpen dat er aspecten waren waar ze niets van wisten, omdat dat puur en alleen op andere locaties (in andere landen) belegd was. Dat betekend niet de gegevens niet opvraagbaar waren, die gegevens waren er binnen een half uur, ongeveer zo snel als iemand op locatie de archieven ingedoken was.
0 mxcreep
@Joolee • 29 september 2012 08:03
Je hebt een punt Jolee, alleen release versies hoeven ondertekend te worden, dus er zou een procedure kunnen bestaan waarbij de ondertekenings machine niet aan een netwerk gekoppeld is wat via welke wijze dan ook maar aan internet gekoppeld is. Ik zou daar in elk geval niet de build server voor willen gebruiken die door iedere developer benaderbaar is. Het aantal developers alleen al wat dan toegang heeft tot die sleutel maakt het minder veilig, er hoeft er maar een tussen te zitten die misbruik wil maken en je hele security ligt op zijn gat. Een ondertekenings sleutel dient maar in handen van een selecte groep mensen te zijn.

[Reactie gewijzigd door mxcreep op 29 september 2012 08:04]

+1 latka
@Stukjetaart • 28 september 2012 11:44
Ik heb wel gewerkt in organisaties waar het internet volledig los staat van het interne netwerk. Was niet makkelijk soms, maar wel veel makkelijker te beveiligen. Het is meer een kwestie van mindset dan techniek. Mensen zijn gewend overal nu.nl te lezen dat zodra dit niet kan ze moord en brand gaan roepen terwijl het heel logisch is om (bedrijfs)kritische zaken niet direkt aan het internet te hangen.
+1 Sypheron
@Stukjetaart • 28 september 2012 14:42
Kan heel makelijk van het internet afkoppeld worden.
De developer hoeft er toch nog geen certificaat aan te hangen totdat de software final is?
Waarom moet de buildserver dan aan een netwerk gekoppeld zijn überhaupt.
Dit is, zoals eerder al beschreven, nog gevaarlijker dan een 'reguliere' inbraak waarbij enkele gegevens buitgemaakt worden.
0 MaartenBE
@Sypheron • 28 september 2012 16:52
Kan aan mij liggen hoor, maar heb je ooit al een (professionele) omgeving tegengekomen waar een machine niet op één of andere manier aan een netwerk gekoppeld is?
0 mxcreep
@MaartenBE • 29 september 2012 08:06
Ja maartenBE, dat komt voor. Bij de digitale recherche bijvoorbeeld zijn complete omgevingen los gekoppeld van internet, wil men internetten dan kan dat alleen maar op een aantal pc's in een fysiek los netwerkje wat dan internet toegang heeft. Op die manier voorkom je ten alle tijden dat er zulke dingen mis gaan.
0 Lennie
@Stukjetaart • 29 september 2012 12:27
Het probleem wat mij betreft is:

waarom had de buildserver de keys/certificaten nodig ? Kunnen die mensen niet builden met een test-certificaat ? En pas de echte key/cert gebruiken als het nodig is om het product uit te leveren ?
0 Webmail
@sfc1971 • 28 september 2012 11:11
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.
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.
+1 Rick2910

@eL_Jay • 28 september 2012 10:17
Ik ken genoeg mensen die hoogbegaafd zijn maar extreem lui en laks in hun handelen. Zoals MneoreJ al aangeeft zou dat de feat van het jaar zijn, nog briljanter dan de kraak van het Windows Update certificaat door Flame. Vrijwel elke computer ter wereld heeft wel iets van Adobe geïnstalleerd staan (Adobe Reader, Flash Player, AIR, CS Suite enz). Stel dat je die binaries kunt voorzien van malware, dan hoef je nergens meer in te breken, maar hoef je slechts uit te breken, wat een stuk makkelijker is. De gevolgen zouden niet te overzien zijn geweest.
Is overigens al bekend wie hier achter zit? Het lijkt mij veel op een actie van de Byzantine Candor group (comment group) uit China. Hoewel het net zo goed iemand anders kan zijn geweest, maar een dergelijke actie bij een groot bedrijf uithalen toont wel een grote vorm van expertise (en middelen!) bij de aanvallers.
+1 MaartenBE
@eL_Jay • 28 september 2012 10:19
Ik ben daar niet zo zeker van. Er zullen vast wel intelligente mensen werken bij Adobe, maar één en ander zit duidelijk niet lekker in dat bedrijf. Na meer dan tien jaar ontwikkeling blijft hun meest geïnstalleerde product (Flash) regelmatig crashen en vol met lekken zitten (en nee dat ligt niet aan mijn computer), AIR is nooit echt van de grond gekomen, ze blijven mobiel niet begrijpen, .... In de grafische niche blijven ze sterk, maar ik heb echt geen idee wat hun lange-termijn strategie is. Jammer genoeg denk ik dat ze het zelf ook niet weten. Ik heb trouwens best wat Flex projecten gecodeerd destijds, ben dus zeker geen Adobe-hater.
+1 sspiff
@MneoreJ • 28 september 2012 11:50
Je denkt toch niet dat Adobe die server nog gaat gebruiken? Die VM wordt gewoon weggegooid en een nieuwe komt in de plaats. Bovendien worden de developer build servers heus niet gebruikt voor een build die ook gereleaset zal worden.

Tools enzo hacken heeft dus geen zin. De bron code is het enige dat gegarandeerd overleeft, dus zinvol is om aan te vallen, is de broncode, maar daar kunnen ze makkelijker je hack in terugvinden.
0 mxcreep
@sspiff • 29 september 2012 08:10
Moet je wel zeker zijn dat je VM omgeving niet te pakken is genomen... Hoewel in de meeste gevallen het VMWare (of welk platform ze ook gebruiken) beheer in compleet andere netwerken hangt. Moet ik wel bij vermelden dat veel organisaties laks zijn en ook weer op de VMWare omgeving een Desktopje hebben draaien wat zo lekker handig overal bij kan... of dat hier het geval is kan ik niet over oordelen, kom het alleen in de praktijk veel tegen.
+1 Robbels
28 september 2012 09:23
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!
Mac potentieel ook gevoelig via Adobe.

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
+2 The Zep Man
@Robbels • 28 september 2012 10:07
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!
Bestaande installaties hebben hier niets mee te maken.

Wat deze hacker bijvoorbeeld gedaan kan hebben is een gemodificeerde versie van de Flash Player installer die ook malware bevat laten ondertekenen. De Flash installatie is daardoor ondertekend op dezelfde manier als andere software van Adobe en daardoor vertrouwd. Op zich kan je overigens al voldoende chaos aanrichten door een oudere Flash installer in te pakken als nieuwere versie en deze te ondertekenen: exploits genoeg.
Mac potentieel ook gevoelig via Adobe.
De maker kan inderdaad ook Mac malware ermee hebben ondertekend. Echter is Windows veel interessanter door het grootschalige gebruik ervan.
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
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.

Het probleem van een 'grote kraak' is dat het opvalt. Heel veel 'kraakjes' zijn lastiger te traceren, lastiger als geheel op te lossen en veel flexibeler om in te zetten.

[Reactie gewijzigd door The Zep Man op 28 september 2012 10:11]

+2 Robbels
@The Zep Man • 28 september 2012 10:48
"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. "

Kortom als de aanval al in juli plaatsvond en de hackers hele diep zijn gekomen kunnen bestaande installaties van na juli potentieel "compromised" zijn..

Adobe zegt nu dat alleen het certificaat gehacked is maar potentieel is er toen ook iets in de software gestopt wat nog niet bekend is (gemaakt).

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)
+1 The Zep Man
@Robbels • 28 september 2012 11:52
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)
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.

Het gevaar zit meer in nieuwe/handmatige installaties die bijvoorbeeld via spam gepromoot worden ("Uw Adobe product X installatie is oud en moet voorzien worden van een nieuwe versie om <verzin een reden>. Klik hier om de nieuwste versie op te halen.").
+1 Sorcerer8472
28 september 2012 10:09
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)...
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
Ze zijn niet echt helemaal lekker bezig daar in meerdere opzichten, blijkt :{

[Reactie gewijzigd door Sorcerer8472 op 28 september 2012 10:10]

+1 The Zep Man
@Sorcerer8472 • 28 september 2012 10:18
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)...
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.
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
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.

[Reactie gewijzigd door The Zep Man op 28 september 2012 11:53]

+1 Meneerik
28 september 2012 10:46
Zou dit ook de reden kunnen zijn waarom de update van Sophos vorige week zich zelf en andere updates van oa adobe blokkeerde en als malware zag?
+1 moreasy
28 september 2012 09:49
Slimme move van deze hackers, als er iets bij voorbaat niet als verdacht wordt beschouwd is het wel de update tool van Adobe Flash en Adobe Reader...
+1 hibbit
28 september 2012 11:11
Outch!
Maar als deze certificaten niet zijn gestolen en op de juiste manier zijn ondertekend, dan moet de malafide-aanvrager van deze certificaten toch ook te achterhalen zijn?
0 0maarten0
28 september 2012 10:32
dit is zwaar ernstig, hide yourself!
0 markwiering
28 september 2012 11:28
Ik ben al sinds 2006 gestopt met het updaten van Adobe Flash Player. Ik heb er tot nu toe alleen maar profijt van gehad. Lekker veilig. :)

Adobe Reader heb ik trouwens wel altijd geüpdate. Daarvan gebruik ik wel de laatste versie.

[Reactie gewijzigd door markwiering op 28 september 2012 11:29]

0 P1nGu1n
@markwiering • 28 september 2012 23:39
Inderdaad heel veilig, voor een heleboel lekken die in de afgelopen 6 jaar gepatcht zijn ben jij nog kwetsbaar
0 r_AllocStarByte
28 september 2012 11:52
Wat een dikke boss hacker :O
1 2

Op dit item kan niet meer gereageerd worden.


Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. • Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. • Hosting door True