Ongeveer 20GB aan vertrouwelijke data van Intel verschijnt online

Er is ongeveer 20GB aan data van chipontwerper Intel online verschenen, waaronder vertrouwelijke documentatie over processors. De data komt volgens het bedrijf van zijn Resource And Design Center.

Chat tussen Kottmann en anonieme hacker

Ontwikkelaar Tillie Kottmann heeft het bestaan van de documenten geopenbaard en zegt dat die via een anonieme bron bij hem gekomen zijn. Kottmann publiceerde eerder broncodes van meerdere bedrijven. Er zouden meer dumps gaan volgen na deze met nog meer documentatie. Er is een lijstje met dingen die in de download van 20GB zouden staan. Daaronder zijn roadmaps, maar ook '(very horrible) Kabylake FDK training videos'.

Intel bevestigt tegenover Bleeping Computer dat het gaat om interne documentatie en vermoedt dat iemand van een derde partij met toegang tot documentatie van het Resource And Design Center die gedownload heeft.

De hacker die Kottmann heeft gesproken zegt dat die een Intel-server aantrof op een CDN zonder goede beveiliging via een scan. Met een Python-script zou de hacker hebben gekeken naar bestanden en mappen die geen wachtwoord vereisen of die werken met standaardwachtwoorden.

Reacties (57)

Die geblurde wachtwoorden zijn ‘Intel123’ en ‘intel123’. Lekker sterke wachtwoorden.

Ik snap de andere comments hieronder wel. Het enige scenario dat hier echter aannemelijk lijkt is dat de zip archives een wachtwoord 'moeten' hebben omdat een policy in outlook (of een policy in een ander mail programma) het niet toeliet om de archives te versturen zonder wachtwoord. Hetzelfde geldt voor executables, of zip archives met executables er in.

In dat geval is het niet zo gek om deze relatief eenvoudige wachtwoorden daarvoor te gebruiken... als men ervan uitging dat het tussen (NDA) klanten/partners, medewerkers, of intranet zou blijven.

Ik ga er ook "vanuit" dat men niet door rood rijdt, men niet te veel zout in producten stopt, dat Google mijn gegevens niet doorverkoopt, etc. Kortom: je moet niet ergens vanuit gaan, je moet gewoon zorgen dat het in orde is. Punt.

Tsja, je kan natuurlijk niet teveel verwachten van je medewerkers, leg hun maar eens een lang en goed wachtwoord uit...
/s

Tis eerder dat in grote organisaties IT bijv nog altijd blijft bij het forceren van een nieuw wachtwoord elke 90 dagen.

Dan is het logisch dat je zo’n wachtwoorden krijgt, want wellicht dat je 1 of 2 keer een sterk wachtwoord kiest, maar naar de zoveelste keer krijg je dat mensen het niet meer boeit en gaan itereren op wachtwoorden en hele simpele gaan kiezen.

Dat ligt toch meestal bij de directie, die bepalen vaak het beleid hierom. Elke degelijker IT'er weet onderhand wel dat een wachtwoord als 'hetisvandaagechtveeltewarmmet33graden' vele male veiliger is dan '@#abcgr1' al denkt de "leek" van niet. Wachtwoord veiligheid zit immers in het aantal karakters, niet de complexiteit. Daar is Microsoft ook vanaf gestapt, ze geven nu ook de voorkeur aan lengte over complexiteit. Een "simpel" lang wachtwoord is ook makkelijker te verzinnen dan iets cryptisch wat je ook weer snel vergeet.

Daar ben ik het niet helemaal mee eens. Als je weet dat een doelwit een paswoord gebruikt op basis van gewone woorden, kan je hier makkelijker op bruteforcen omdat je niet alle random combinaties hoeft te proberen. Er zit wel degelijk minder entropie in dan een daadwerkelijk random string van dezelfde lengte. Zeker als je machine learning gebruikt om te prioritiseren welke woordenboek woorden daadwerkelijk naast elkaar gebruikt worden en welke niet. En zo lang als dit voorbeeld zie je ze zelden, meestal als er een passphrase aangeraden wordt is het iets van minimum 12 karakters. Met een woordenboek erbij en eventueel een beetje gerichte benadering op basis van een persoon zijn social media interesses is dat helemaal niet zoveel entropie.

Het is momenteel veiliger omdat elke aanvaller zich baseert op het bruteforcen van random korte strings. Maar de aanvalmethodes kunnen hier gewoon op aangepast worden.

Het is ook sowieso maar een lapmiddel. Zo'n lange string typen elke keer als je je computer unlockt is gewoon vervelend, veel beter is gewoon naar passwordless gaan.

[Reactie gewijzigd door GekkePrutser op 7 augustus 2020 12:55]

Je krijgt een hoge beoordeling maar je bericht is niet helemaal correct.
Als ik het 'complexe' wachtwoord van @naaitsab twee keer achter elkaar plak voor een totaal van 16 tekens(!) geeft een calculator aan dat 70.8 bits aan entropie bevat. Als je vervolgens naar Diceware gaat kijken, dan geven zij aan dat een wachtwoord van 6 woorden al 77 bits entropie heeft. Let op! Dit zijn 6 woorden uit een bekende en publiek beschikbare woordenlijst met slechts 7776 woorden(!). Als je als echte Nederlander verschillende talen inzet, zelf de woorden bedenkt en ook nog wat random tekens ertussen plakt (dus geen l33tspe4k) kun je af met minder woorden. Ik ben echter geen wiskundige dus dat kan ik niet voor je berekenen

Ik ben het wel absoluut met je eens dat je gewoon een password manager/2fa/biometrische login moet gebruiken tegenwoordig.

[Reactie gewijzigd door Joolee op 7 augustus 2020 19:46]

Het is momenteel veiliger omdat elke aanvaller zich baseert op het bruteforcen van random korte strings. Maar de aanvalmethodes kunnen hier gewoon op aangepast worden.

En dat is waarom je een passphrase gebruikt die een klein aantal willekeurige tekens voor- of achteraf heeft. Deze werken als pepper (in tegenstelling tot de meer bekende en publieke salt), waardoor een aanval op basis v/h concateneren van bestaande woorden, zal falen.

Op die manier heb je een makkelijk te onthouden passphrase met hoge entropie die niet eenvoudig te breken is via slimme op taal-analyse gebaseerde methodes.

[Reactie gewijzigd door R4gnax op 8 augustus 2020 15:49]

Dat we in 2020 nog steeds directies hebben die dit beleid kunnen maken is mij een raadsel. We krijgen alles voor elkaar, we bouwen hele organisatiestructuren om tot volledige DevOps toko's, maar een fatsoenlijk passwordbeleid er doorheen krijgen? Dat is de grens.

We krijgen alles voor elkaar, we bouwen hele organisatiestructuren om tot volledige DevOps toko's, maar een fatsoenlijk passwordbeleid er doorheen krijgen? Dat is de grens.

Die is eigenlijk heel simpel te verklaren:
een fatsoenlijk wachtwoordbeleid raakt niet alleen de technische mensen, maar iedereen in de organisatie. Alles en iedereen "moet mee om," en dat zijn hele zware stappen die raken aan bedrijfscultuur - iets waarvan we weten dat deze heel moeilijk is om middels extern opleggen van zaken, effectief te wijzigen.

Daarnaast concentreert de weerstand tegen dit soort zaken zich meestal juist aan de top, bij de beleidsmakers, omdat het niet zomaar overal bij kunnen gezien wordt als macht uit handen geven; of het opleggen van dit soort beleid voelt als een aantasting van hun autoriteit. (Treurig, maar waar.)

[Reactie gewijzigd door R4gnax op 7 augustus 2020 10:39]

Uhm, organisaties omvormen tot DevOps raakt ook per definitie elke laag in de organisatie.

[...]
Daarnaast concentreert de weerstand tegen dit soort zaken zich meestal juist aan de top, bij de beleidsmakers, omdat het niet zomaar overal bij kunnen gezien wordt als macht uit handen geven; of het opleggen van dit soort beleid voelt als een aantasting van hun autoriteit. (Treurig, maar waar.)

Mooaw... niet helemaal.
Het eerste deel klopt (concentratie) maar de macht is iets complexer.
De weerstand is niet logisch als het om macht gaat, complexe regels verhogen juist de macht.
Ik denk dat bij de bovenkant van organisaties in dit geval angst door onwetendheid regeert. Elke onderknuppel die boos de bovenste verdieping binnenstormt met de kreten als " zo kunnen we natuurlijk niet werken...) kan geen antwoord krijgen omdat de kennis ontbreekt bij de bovenkant van organisaties. Dit gebrek aan kennis mag niet zichtbaar zijn, dus krijgt iedereen die boos binnenrent volkomen en begripvol gelijk. De CIO is dus niet in staat om zijn collega's C's te informeren, onbekwaam?

Ik denk eerlijk gezegd niet dat 1 wachtwoord beleid voor een heel bedrijf de oplossing is.
Per rol een beleid bepalen lijkt me veel beter, want per rol is ook afgeschermd bij hoeveel data je kunt.
Even extreem: je kunt van de koffie-juffrouw niet verwachten dat zij een even sterk wachtwoord gebruikt als de cfo. Die cfo zou trouwens niet eens mogen inloggen zonder een 2fa (hardware of software) wanneer deze bij de meest gevoelige data wil komen...

Hetzelfde voor toegang tot bedrijfsgeheimen op het netwerk: voorzie ze van een audit trail door ze niet met een verkenner te kunnen kopiëren maar alleen met de van toepassing zijnde tool lokaal te kunnen opslaan (inclusief gebruikte licentie gegevens van die gebruiker). Of nog beter: zorg ervoor dat er niet lokaal kan worden opgeslagen dmv policies.

Maar ja, als het dan - vrijwel - onbeschermd ergens op een publiek toegankelijke server staat vraag ik me af of die van Intel zelf was of van die derde partij en of er in logs staat wie de downloader was. Klinkt in ieder geval alsof er iets serieus mis was in het beleid wanneer het om zulke hoeveelheden bedrijfskritieke data gaat.

Jup iets als ActivePasswords helpt uitstekend. Je moet t echter wel reeel houden voor iedereen.

Klopt, ik moet om de 90 dagen mijn wachtwoord aanpassen... ben daardoor minstens 15 minuten bezig om het wachtwoord aan te passen.. want wil deze sterk houden.. dus ook in mijn 1password hebben staan maar dan moet ik natuurlijk overal opnieuw inloggen etc.

Er zijn ook externe factoren die zorgen voor een streng wachtwoordbeleid. Komt niet altijd van "de IT-jongens" af .

Klopt, had ik ook op werk.

Eerst goede wachtwoorden, maar aangezien er een wachtwoord geschiedenis is en we mochten niet een wachtwoord na x aantal maanden hergebruiken, ging ik uiteindelijk een wachtwoord gebruiken als 'A12345678a' en dan na 3 maanden was het 'B12345678b' etc.

Ik denk niet dat geforceerde wachtwoordrotatie opgaat met willekeurige .zip-wachtwoordjes in een CDN.

Dit idd. Op het werk doe ik het ook.
Niet zo makkelijk als dit maar als je telkens een nieuw wachtwoord met verzinnen wat overal aan voldoet.

Dit dus. Dan krijg je wachtwoorden als "1J@nu@ri", "1Febru@ri" etc. Helemaal als je met collega's 1 extern account deelt (want dure accounts) en geen gedoe wilt met het spellen van een random string wachtwoord.

Niets menselijks is ons vreemd.

Ik moet ook elke 90 dagen mijn wachtwoord veranderen. Ik zit nu op nummer 9, en dan gaan we daarna weer bij 1 beginnen. Veilig? Nee, niet persé. Maar een random code met cijfers en nummers onthouden gaat ook niet.

Maar in dit geval gaat het over wachtwoorden op zip archives, die vervallen niet zomaar, wat het tegenbewijs is van je punt.

ADP maakt zich daar ook lekker schuldig aan, met als bijkomstigheid dat de afgelopen 4 wachtwoorden niet gebruikt mogen worden. Hoezo vinden ze dat veilig

Ooh ik heb altijd als wachtwoord mijn geboortedatum XOR de datum van vandaag

one time pad, maar dan onveilig zegmaar?

Nee joh was grapje

Ook wordt letterlijk 'I accept' als wachtwoord gebruikt.

intel@123 en Intel@123 worden ook gebruikt.

[Reactie gewijzigd door jordynegen11 op 7 augustus 2020 08:23]

En "i accept".

Als je het nie zou weten zou een brute force methode er nog steeds wat tijd voor nodig hebben.....

tja niet echt sterk nee, maar beter dan niks. ik heb wel eens bij een bedrijf een NAS gevonden vol kopieen van ID kaarten met als wachtwoord "12345678" tja, dat was toch een groter probleem dan dit denk ik.

Het zijn documenten uit de partner portal, niet echt interne documenten.

Het zijn documenten uit de partner portal, niet echt interne documenten.

Als je naar de thread unroll van de Twitter publicaties kijkt, dan zie je toch iets anders.

Er zitten o.a. schematics en design data in van het nooit uitgebrachte Tiger Lake platform.
En kale Adobe InDesign templates vermoedelijk voor gebruik door Intel's marketing afdelingen.
En source code dumps waarin letterlijk het bewaren van een memory pointer voor backdoor-doeleinden genoemd wordt.

Met name dat laatste wil Intel denk ik niet aan de grote klok gaan hangen bij partners...

[Reactie gewijzigd door R4gnax op 7 augustus 2020 10:50]

Er lijkt ook wat geheimers in te zitten, want een aantal presentaties in de dump lijkt een watermerk met "CustName" te hebben en een handleiding hoe die slide aan te passen voor een presentatie bij een specifieke klant.

Mij doet het vermoeden dat dit het voorbereidende materiaal is dat men verwerkt en daarna naar partners opstuurt.

Ah, goed gevonden! Mooie nuance

Het zal niet lang duren voordat er malware verschijnt die fouten in de "Management Engine" zal misbruiken, en niets die daar iets tegen kan doen.

Of wat dacht je van custom firmware dat iME helemaal disabled?

Hopelijk verschijnt die op een gegeven moment. Mijn hardware is inmiddels uit de garantie en ik zou maar al te graag die backdoor geneutraliseerd zien worden

Dat kan je zelf doen, zie hier.
Kan het me niet meer herinneren, maar vlgs mij had ik daarvoor alleen een IC clip en SPI programmer nodig.

Je noemt het "alleen," maar ik hoop dat je je realiseert dat zoiets ver, heel ver, buiten de comfort-zone van menig consument valt?

Natuurlijk weet ik dat, maar degene die van de ME af wil is niet menig consument.
Voor de tweaker is er dus een manier om vanaf te komen met slechts €10 ofzo aan gereedschap.

Graag een lijst van onderdelen die nodig zijn

Dat kan verschillen per machine (per flashchip waar de ME op staat).
Je moet eerst uitzoeken of de flash op 1,8 of 3,3V draait, en wat voor chip/pinout ie heeft.
En dan zoek/maak je daar de geschikte onderdelen voor.

Een "CH341A" programmer is populair, maar NB de goedkoopste/populairste zijn vaak slecht (geven 5V aan 3,3V chips, zoals de mijne, die moest ik dan zelf nog ombouwen).
Deze zou wel goed zijn voor 3,3V dacht ik. 1,8V geen ervaring mee.
Je kan voor 3,3V chips ook een Raspberry Pi gebruiken om een programmer te maken, zie hier.

Dan moet je een IC klem hebben die op de chip past. Meestal zijn die op SOIC8 formaat maar kan ook anders zijn. Die worden vaak meegeleverd bij zo'n programmer, maar ik had al n programmer dus had ik n losse gekocht. Ikzelf heb er een met vergulde contacten, en dan had ik er zelf n kabel voor gemaakt met korte koperdraad (meegeleverden hebben soms lange tindraad, niet zo betrouwbaar), en die alleen de pinnen verbindt die nodig zijn.

Maar goed, dan zet je de te-flashen-computer uit met wake-on-lan aan (zorgt ervoor dat de computer zelf de flashchip voedt), zet je de klem op de flashchip, hang je de klem aan de programmer, en de programmer via USB aan de flashende-computer.
En dan zou je er meteen bij moeten kunnen met flashrom (in Linux iig, Windows geen verstand van).
Hoe het _precies_ moet verschilt per machine/programmer, dat kan je ook wel elders vinden, maar dit is iig het boodschappenlijstje.

Dat is het probleem van security by obscurity
Het is niet getest of gecontroleerd door onafhankelijke partijen.

En jij gaat er vanuit dat dat hier voor al niet gebeurde?

Ik heb een System76 laptop en hierin kun je eenvoudig de ME uitschakelen in de BIOS.
Helaas hebben veel fabrikanten die optie niet.

Kan me niet voorstellen dat sourcecode over een (verplichte) backdoor te vinden is op een op internet aangesloten netwerk. Het lijkt me dat dit valt onder nationale veiligheid.

Inderdaad. Normaal wordt dit gewoon in een publieke cloud gezet.

https://securityaffairs.c...s-army-nsa-data-leak.html

Intel vulnerabilities, now on our servers as well! /s

'verry horrible'

horriblest?

Staat vol met tikfouten. Zo ook "Akami CDN" (Akamai), "masqurade" (masquerade), "protected" (protection).

Intel is dan ook een mooi woord voor inlichtingen... alstublaft, doe er iets leuks mee moet de dief hebben gedacht.

volgens mij reageer je op een ander artikel..

Als spionage simpel bewezen kan worden, zouden die spionnen al ontslagen zijn. Dat is het punt niet. Overigens lijkt me de enige link met dit artikel dat er eventueel industriële spionage zou hebben kunnen gebeuren bij intel, door dit lek. Die link lijkt me wat vergezocht om een 50-cent-rant te houden over hoe evil Amerika is en hoe zielig China.

[Reactie gewijzigd door mae-t.net op 7 augustus 2020 14:04]