Eerder afgelopen week was er al de "Intel SCS System Discovery Utility", waarmee de output naar registry en/of naar een xml-file te schrijven was. Ik heb daarmee die optie de output naar een xml-file te schrijven gebruikt. De resultaten waren met behulp van de Detection Guide (pdf) correct te interpreteren, maar handig was het niet.

Gisteren heb ik de nieuwe "INTEL-SA-00075 Discovery Tool" gebruikt, daarvan de "Intel-SA-00075-GUI.exe". Dat werkte heel handig en heel duidelijk.
Voor wie nog twijfelt of de betreffende kwetsbaarheid aanwezig is op zijn/haar systeem, kan ik beslist het gebruik van de "INTEL-SA-00075 Discovery Tool" en daarvan de "Intel-SA-00075-GUI.exe" aanraden.
Zoals ook gelinkt door de redactie: https://downloadcenter.intel.com/download/26755

Easy remedy:
https://github.com/bartblaze/Disable-Intel-AMT

@Spiff,

Zoals gebruikelijk van je: weer goed leesbare en nuttige informatie. Dank!

Wel intel processoren maar geen windows? Geen hulp. Bedankt, intel.

@Spiff

Draait deze tool eenmalig of is het software die op je pc geïnstalleerd wordt?

Geinig dat ze mijn uitgeschakelde computer over kunnen nemen... als ik mijn computer uit schakel is de stroom er namelijk af. Dit is dan het eerste lek dat draadloos stroom kan inschakelen? (*_*)

Niet iedereen bedoelt hetzelfde met uitschakelen.
Sommigen vinden een computer al uitgeschakeld zodra die in slaapstand is,
anderen wanneer afgesloten via het besturingssysteem,
en anderen pas wanneer het systeem van de netspanning is (notebook tevens zonder accu).

De redactie schreef dan ook, "Een aanvaller kan zo volledige controle over bedrijfscomputers krijgen, zelfs als ze zijn uitgeschakeld maar er nog wel stroom op staat".
Is een systeem uitgeschakeld én tevens afgesloten van netspanning (notebook tevens zonder accu), dan geldt dat niet meer.

Probleem: enorme executables op een code sharing site zonder broncode, geen signing, geen verifieerbare uitleg over wie precies de auteur is.

Intel stelt alleen een tool beschikbaar voor Windows. Betekent dit dat Linux computers niet geïnfecteerd kunnen worden? Of laat Intel Linux-gebruikers stikken?

Ach, WOL doet dat ook.

Ik kan nergens vinden of Mac's ook last van dit probleem kunnen hebben of maakt Apple geen gebruik van het type vPro processoren? Ook de site van Intel meldt daar niks over.

Naast wat Anoniem 17:05 uur al aangaf,
realiseer je tevens dat die bartblaze "Disable Intel AMT" tool alleen aanpassingen in Windows maakt, en geen aanpassing in BIOS en/of van firmware.
Mijns inziens is de verstandigste aanpak als volgt:
1.
Eerst bepalen of je systeem of systemen kwetsbaar zijn, door middel van de INTEL-SA-00075 Detection Guide en Discovery Tool (daarvan is uitvoeren van "Intel-SA-00075-GUI.exe" erg handig voor gebruik op een enkel systeem).
Blijkt daaruit dat je systeem of systemen niet kwetsbaar zijn, dan ben je klaar.
2.
Blijkt uit 1. dat je systeem kwetsbaar is, dan is het zaak om te bepalen hoe de kwetsbaarheid te verhelpen is.
Is een aanpassing in het BIOS te maken, of zijn op een gegeven moment firmware updates beschikbaar, dan zijn dat aanpassingen die mijns inziens het belangrijkst zijn, omdat ze de kwetsbaarheid buiten het besturingssysteem verhelpen.
Zijn dergelijke opties niet beschikbaar, dan zijn aanpassingen binnen het besturingssysteem uit te voeren, zoals beschreven in de INTEL-SA-00075 Mitigation Guide - of eventueel door middel van de door Anoniem 12:44 uur getipte bartblaze "Disable Intel AMT" tool. Ikzelf zou er, net als Anoniem 17:05 uur, echter huiverig voor zijn zomaar die bartblaze "Disable Intel AMT" tool te gebruiken. Zou ik die per se willen gebruiken, dan zou ik die tool eerst volledig willen analyseren. Zelf handmatig uitvoeren wat Intel beschrijft in de INTEL-SA-00075 Mitigation Guide is dan mogelijk minder werk.

"Intel-SA-00075-GUI.exe", als onderdeel van de "INTEL-SA-00075 Discovery Tool" wordt enkel uitgevoerd, niet geïnstalleerd.
Je kunt "INTEL-SA-00075 Discovery Tool" downloaden, en opslaan waar je maar wilt, ook op bijvoorbeeld USB-stick, en vanaf die locatie uitvoeren. De "INTEL-SA-00075 Discovery Tool" is dus portable.
In de gedownloade en uitgepakte INTEL-SA-00075 Discovery Tool, vind je de eerder genoemde "Intel-SA-00075-GUI.exe" in de submap "Windows". Na uitvoeren van "Intel-SA-00075-GUI.exe" en bekijken van het resultaat, kun je naar wens de INTEL-SA-00075 Discovery Tool simpel weer verwijderen, er wordt niets geïnstalleerd.

Als ik hoofdstuk 5 lees, dan is dat remote web access onafhankelijkvan het gebruikte OS.
https://software.intel.com/sites/default/files/article/393789/amt-9-start-here-guide.pdf

De architectuur van AMT is in het plaatje onder 2.1 weergegeven.
Het OS komt pas aan de beurt na het hele AMT gebeuren. Dat maakt het verhaal logisch want als er een standby is functioneert er niets meer van het OS.
In dat conceptplaatje staat het OS met drivers getekend.

Doorlezend na dat hoofstuk 5 komt 6.1 met:
In addition to having the BIOS and ME extensions set up correctly, there are also drivers and services to be installed and running in order to fully utilize Intel AMT once it has been properly configured. To verify that the Intel AMT drivers and services are loaded correctly, look for them in the host operating systems’ Device Manger and Services. Note that every Intel AMT system should have a CD that includes all of the required firmware and drivers. Be sure to check the OEM’s download site frequently for upgraded versions of the BIOS, firmware, and drivers.
Here is a list of drivers and services that should appear in the host operating system:
Intel® Ethernet Network Connection i217-LMç
Intel® Centrino® Advanced-N 6205 AGN# ?
Intel Management Engine Interface# ?
Serial-Over-LAN (SOL) Driver ?
Intel® AMT LMS Service ?
Intel® AMT Management and Security Status Service
#Network controller and wireless interface versions will vary depending on the generation of Intel vPro platform.

6.4
The Local Manageability Service (LMS) runs locally in an Intel AMT device and enables local management applications to send requests and receive responses to and from the device. The LMS listens for and intercepts requests directed to the Intel AMT local host and routes them to the Intel ME via the Intel ME Interface driver.

Ik lees:
- je moet het zelf installeren.
- lms doet een MITM voor het AMT verkeer.

Klopt dat?

Update https://www.golem.de/news/bios-sicherheitsluecke-intel-patzt-mit-anfaengerfehler-in-amt-1705-127671.html
Leesbaar artikel het is de webinterface waar het password hash ingekort kan worden., uiteindelijk is er geen beveiliging.

And what about AMD PSP? Die heeft vergelijkbare functionaliteiten en biedt ook toegang tot netwerk en alles wat op PCIE is aangesloten incl. harde schijven. PSP zit ook in Ryzen cpu's en diens voorgangers?
Dit soort verborgen en ongedocumenteerde management interfaces zijn een heel slecht idee als de beveiliging ervan niet goed geregeld is. Dan wordt het ineens een achterdeur in alle systemen waar deze interfaces inzitten terwijl zowel Intel als AMD geen inzage willen geven in de beveiliging of het mogelijk maken om de interface via het BIOS geheel uit te schakelen.
Daar kan alleen maar ellende van komen, wat nu blijkt.

Ja en nee. Intel AMT bestaat uit verschillende features in de meeste Intel chipsets. Gebruikelijk is dat de volledige AMT functionaliteit beschikbaar is zodra de chipset de aanwezigheid van een (duurdere) vPro CPU detecteert, zonder dat die CPU zelf een rol speelt.

In https://software.intel.com/en-us/blogs/2011/03/21/intel-vpro-technology-with-intel-amt-what-to-look-for staat namelijk onder meer:
Een anonieme commentaargever (helemaal onderaan die pagina) haalt die tekst aan en stelt dat dit niet waar is, verwijzend naar http://communities.intel.com/thread/21554 waarin iemand laat zien dat als je, met de "slaap" spanning op het moederboerd, de CPU wisselt naar een ander type, de chipset dit herkent en AMT functionaliteit uit of inschakelt.
Vervolgens wordt dit bevestigd door Gael H. (Intel):
Met andere woorden, de functionaliteit zit in de chipset en het is puur een geldkwestie (duurdere vPro CPU) of die functionaliteit beschikbaar is.

Uit deze plaatjes (waarvan ik niet 100% zeker weet of ze kloppen) blijkt dat AMT en ME volledig losstaan van het OS en DUS van de CPU (want ook de CPU staat (grotendeels of geheel?) "uit" als de PC in slaapstand is):
- https://www.heise.de/ct/imgs/04/2/1/9/5/7/5/1/ciw_ManagementEngine_aak_IG-c431e78ea4334a39.jpeg
- https://www.heise.de/ct/imgs/04/2/1/9/5/7/5/1/7254-f-4-bc8a6355cce759c3-b9b968a6e01065d1.png
(bron: https://www.heise.de/ct/artikel/Tipps-zur-Intel-ME-Sicherheitsluecke-SA-00075-3704454.html)

Wat ook niet klopt is dat uitsluitend "business" computers hier last van zouden hebben. In elk geval ook kwetsbaar zijn:
- Sommige HP "Consumer Notebooks and Desktops": http://www8.hp.com/us/en/intelmanageabilityissue.html#Consumer_Notebooks
- Intel Compute Stick STK2mv64CC https://communities.intel.com/thread/114092
- Intel barebone boards https://communities.intel.com/thread/114093
- Intel desktop boards https://communities.intel.com/thread/114071
(bron: https://www.heise.de/security/meldung/Intel-ME-Sicherheitsluecke-Erste-Produktliste-noch-keine-Updates-3703356.html)

Doordat Intel niet weet of je een vPro CPU in hun moerderborden stopt of niet, moeten ze ervan uitgaan dat deze borden kwetsbaar zijn. Waarom zoiets als een compute stick AMT ondersteunt, is me een raadsel. Misschien was dit wel helemaal niet de bedoeling maar is het er per ongeluk ingeslopen (of de NSA/filmindustrie heeft de licentiekosten daarvoor betaald).


De ellende is dat het extreem lastig is om met zekerheid vast te stellen dat een PC niet kwetsbaar is:

1) Intel's SCSDiscovery.exe geeft andere resultaten afhankelijk van of je een netwerkkabel aansluit (en de PC via DHCP een adres gekregen heeft). Uit de logfiles kun je opmaken dat e.e.a. ook van BIOS instellingen afhangt - die lang niet altijd even eenvoudig bereikbaar zijn.

2) AMT probeert het DHCP antwoord te "sniffen" en bepaalt zo het IP-adres waarop de PC bereikbaar is. Maar AMT probeert ook te bepalen of de PC zich in een vertrouwd bedrijfsnetwerk bevindt; zo niet (notebooks buiten de deur) probeert deze de mogelijkheden voor remote management uit te schakelen. De citeria hiervoor zijn mij niet duidelijk.

3) De default username/password combinatie is admin/admin (in een aantal gevallen krijg je dat terug na een lege moederbordbatterij, meestal CR2032). Volgens de documentatie zou je met dat wachtwoord niet via het netwerk kunnen inloggen (wel stuurt zo'n PC kennelijk enkele uren na aanzetten "Hello" packets, maar of AMT op dat moment wel open staat, weet ik niet). Onduidelijk is in elk geval of AMT dan luistert op de hieronder genoemde poorten maar dat wachtwoord niet accepteert of geheel niet luistert (geen antwoord op een SYN pakketje geeft).

4) Als AMT voor TLS is geconfigureerd, is deze te bereiken via https://IP_adres:16993/ en anders via http://IP_adres:16992/. Waarschijnlijk werkt dat niet vanaf de PC zelf (test voor de zekerheid vanaf een andere PC aan hetzelfde subnet), want dan zou malware op de PC ook AMT kunnen proberen te beïnvloeden. Zeker is dat 127.0.0.1 niet werkt (want dat verkeer verlaat jouw OS niet).

5) Bij 4) zou je een password prompt moeten krijgen - maar wellicht alleen als jij (of een eerdere eigenaar of een beheerder) een ander wachtwoord dan "admin" heeft ingevuld (zie punt 3).

6) AMT kan ook als packet filter werken, waarbij ingesteld kan worden welke netwerkpakketjes het OS niet mogen bereiken. Maar ook de andere kant op kan gefilterd worden.

7) Ik weet niet zeker of AMT ook via WiFi bereikbaar is, maar ik vermoed van wel (anders zou zo'n firewall maar beperkt zin hebben).

8) Ik sluit niet uit dat AMT onder bepaalde omstandigheden alsnog wordt aangezet zodat beheer op afstand mogelijk is (hangende CPU, langdurige slaapstand etc).

9) Op minstens 1 Dell notebook zie ik in de door SCSDiscovery.exe geproduceerde XML file het woord "AMTSKU" niet voorkomen, maar wel heel veel andere aanwijzingen dat AMT wel degelijk aanwezig is, zoals:
maar ook certificate hashes. Ik vermoed dat "AMTSKU" erin voorkomt als er een vPro CPU in het bord zit.


Kortom, heel veel onduidelijkheden waardoor je het misschien wel betrouwbaar kunt vaststellen als jouw PC zeker kwetsbaar is, maar niet met zekerheid dat deze niet kwetsbaar is en dat nooit zal worden.


Voorbeeld: zelf heb ik een Toshiba Tecra notebook die, voor zover ik weet, geen vPro CPU heeft. Maar daarop draaiden wel o.a. de volgende Intel services (W7 Pro):

Service name: LMS
Display name: Intel(R) Management and Security Application Local Management Service
Description: Intel(R) Management and Security Application Local Management Service - Provides OS-related Intel(R) ME functionality.

Service name: Intel(R) ME Service
Display name: Intel(R) ME Service
Description: Intel® Manageability Engine Service (Intel® ME Service)

Service name: cphs
Display name: Intel(R) Content Protection HECI Service
Description: Intel(R) Content Protection HECI Service - enables communication with the Content Protection FW

M.b.t. die laatste, uit https://software.intel.com/en-us/blogs/2007/01/24/let-us-talk-about-heci-and-lms:
Voor zover ik kon achterhalen luisterden deze services op mijn notebook niet op TCP of UDP poorten (gebruikelijk zouden de TCP poorten 623 en 664 zijn).

In de BIOS kan ik aanzetten: "Intel(R) AT" (ik neem aan "Anti Theft"). Dit heeft geen invloed op bovengenoemde poorten. In de BIOS is niets te vinden over AMT. Er zijn echter Toshiba Tecra varianten waarbij je in de BIOS aan kunt zetten "AMT Setup Prompt" (waarschijnlijk moet je dan Ctrl-P drukken om AMT instellingen te kunnen wijzigen), maar in de BIOS in mijn notebook zie ik dat niet - wellicht omdat er geen vPro CPU in zit. Misschien dat Toshiba 1 image heeft voor Tecra's met en zonder vPro CPU, en gemakshalve altijd de drivers installeert (ook als je er, zoals vermoedelijk in mijn geval, niets aan hebt).

In elk geval blijf ik met het ongemakkelijke gevoel zitten dat ik een PC heb met een backdoor die waarschijnlijk onbereikbaar is, maar waarvan ik niet weet of er misschien omstandigheden zijn waarbij deze toch wordt ingeschakeld.

Los van het nu bekendgemaakte lek en wat de blunder met strcmp/memcmp betekent voor de kwaliteit van de rest van de code: in https://software.intel.com/sites/manageability/HLAPI_Documentation/default.htm?turl=Documents%2Fopenssllicense.htm staat:
Als AMT van een oude OpenSSL library gebruik maakt, zou de TLS variant wel eens veel minder betrouwbaar dan verwacht kunnen zijn. Het zou mij niet verbazen als er chipsets met ongepatchte firmware met daarin Heartbleed in omloop zijn...

PS zie https://software.intel.com/sites/manageability/HLAPI_Documentation/default.htm?turl=Documents%2Fsupportedintelamtfeatures.htm voor de diverse AMT feautures.

Kijken wanneer het ingevoerd is. Min of meer alle chipsets sinds 2009 (intel) en 2011 (amd) zijn in principe besmet te achten. Er zijn een paar uitzonderingen, maar dat is detailwerk. In eerste aanleg is dit de stelregel.

Dit betekent een redelijk groot probleem voor iedereen, want alle computertjes die niet afgeschreven zijn blijken niet vertrouwenswaardig, en dus [x] ongeschikt om met gevoelige informatie om te gaan. Dat betekent eigenlijk dat alle CISOs al bij hun CxO vriendjes hadden moeten aankloppen met "er, jongens, we hebben een probleem, het is acuut en oplossen gaat heel erg duur worden." Maarja, zo consequent zijn de meeste security mensen dan ook weer niet.

Het zat er namelijk gewoon aan te komen, wegens inherent in de opzet, dat AMT en PSP problemen gingen opleveren, en verrekte weinig mensen, ook in het security wereldje, hebben de correcte conclusie getrokken voordat dit dingetje bekend werd. Waarom zouden ze het dan nu wel doen? Hun job is namelijk niet beveiligen. Het gaat om "risicos afwegen" en dat is een soortement van inflatiemeten: Je kan arbitrair vanalles negeren of meetellen om maar een rooskleurig plaatje te verzinnen, dan heb je "plausible deniability" en dat is op het eerste gezicht een stuk goedkoper dan werkelijk een solide security structuur bouwen.

Yup.

Dat is een gegeven, verzin maar waarom. Belangrijker, ook als je zeker zou kunnen weten dat als er "verborgen en ongedocumenteerd" spul aanwezig zou zijn dan is het ook veilig want [...], dan nog is het geen goed idee om "verborgen en ongedocumenteerd" wat-dan-ook in je computertje te hebben. Die qualificatie is dus niet zo heel verstandig om toe te voegen. De kortere versie is dus beter.

Het is super simpel. Heb je een Intel processor geproduceerd na 2008? Ja? Dan heb je een probleem, nee dan geldt het Neurenberg "we wisten het niet" nog.

Nagenoeg alle Intel gebaseerde computers hebben vPro en AMT of ME aan boord. Sowieso alle servers, zeker op basis van Xeon.

Patchen is nog nauwelijks mogelijk omdat de nieuwe BIOS firmware van de leveranciers van de moederborden nog niet af is. Hoe dit gaat lopen met alle embedded systemen en industriele controllers is nog de vraag. Kan dus goed zijn dat men niet alleen via de SAP Oracle machine binnenkomt maar juist via de printer of gebouwen airconditioning.

Iemand?

Ligt hier een taak voor de isp's? Dat de KPN's en Ziggo's van deze wereld op hun aan de klant geleverde routers standaard de poorten 16992 en16993 dichtzetten?

Heel fijn, maar ik zie geen source code voor DisableAMT.exe en ook de ZIP bevat alleen de exe. In de src map staat naast een bat file nog eens twee binary executables. Van programmatuur die gebruikt wordt om systeeminstellingen te wijzigen verwacht ik ten minste de broncode, broncode en nog eens de broncode (en zo nodig build instructies).

Op deze wijze wordt github als media server gebruikt (misbruikt ?).
Dit "gemak" dient geen veiligheid maar onveiligheid; ook als het goed is bedoeld en alleen doet wat het pretendeert te doen, dan nog geeft het blijk van een inherent gevaarlijke wijze van handelen en denken, van de onveilige cultuur die MS Windows gebruikers zo eigen is.

Overigens is het blog van bartblaze de moeite waard; dat hij kennis van hacken heeft staat buiten kijf.

Lezen? Uit https://github.com/bartblaze/Disable-Intel-AMT:

Het AMT lek is OS onafhankelijk.

Is dat een verrassing dan?

Tenzij jouw ISP jou IPv6 connectiviteit biedt, is dat niet nodig (NAT verhindert dat je vanaf internet verbindingen naar poorten achter een IPv4 NAT router kunt initiëren). Ik zou me eerder zorgen maken over alle IoT meuk in je woning.

Het is een hardware issue met daarvoor speciale chips op je moederbord. Er is geen sprake van een os infectie elk os op de hardware is potentieel geraakt.

Ik zou me de meeste zorgen maken over wat er in datacenters gebeurt. Op servers bij bijvoorbeeld AWS draait meestal ...
Het voordeel van verkeer binnen een datacenter is weer wel dat je daar goed kan gaan monitoren.
Echter als je de kaart kan overnemen en al dat verkeer kan zien hoe zou dat virtualisatiescheiding opheffen?

Daarmee moet je het remote beheer op machine niveau er uit krijgen als het al ongewenst aan gezet is.

Voor dit is er ook een sectie 'Details about the tool' waar uitleg staat over hoe de tool is gemaakt, en met broncode in de scr folder. Voor gebruik in een grotere Windows omgeving is de batch file met Intel files in dezelfde source folder mogelijk makkelijker.

Okay, seems I was a little (to) hasty to make my point.

OTOH:
Why would one compile a batch file that is only to be run once (or twice ...) ?
And Intel does not provide sources for their binaries. Being open on this technology seems something that does not fit Intel (and Microsoft ?), but that's outside of bartblaze's realm.

Ik vind dit lek schandalig. Zo slordig als met onze veiligheid eb privacy word omgesprongen. Ik vind dat consumentenorganisaties in het geweer moeten komen. Intel moet evt. i.s.m. de pc fabrikanten,microsoft en de antivirusbedrijven een patch doen,bijv.via windows update. Kan dit niet dan moeten de kosten voor pc leken die een pc technicus te hulp moeten roepen om hetzij de nodige omzettingen in het systeem te plegen danwel om de Intel processor door een AMD-processor te laten vervangen. De kosten moeten door Intel zelf en deels door pc fabrikant worden opgebracht. Je koopt een (nieuwe) pc in de verwachting dat ie veilig is Het valt me ook op dat er telkens problemen met Intel processors zijn en vrijwel nooit met AMD processors. Volgende pc word er 1 met AMD processor,ik ben wel klaar met Intel. Die pc's met processors zoals de Intel Core i3 zijn ook nog eens duurder dan die met een AMD processor. Laat de pc fabrikanten die Intel meuk gauw van hun nieuwe pc's gaan weren.

Dus: zet je computer uit, en haal de prik eraf. Low-tech-oplossing: stekkerblok met schakelaar.

Disable Intel AMT - Intel Active Management Technology (AMT)

Bedankt voor de tip Anoniem. (07-05-2017, 12:44 door Anoniem)
- Easy remedy:
https://github.com/bartblaze/Disable-Intel-AMT

Download - 7.2 Mb / Meer info via:
http://www.majorgeeks.com/files/details/disable_intel_amt.html

Youtube:
https://www.youtube.com/watch?v=gyv5_n4HpMY