Intel RootCA Fehler (CVE-2019-11095)

Auf dieser Seite beschreibe ich meine Erkenntnisse zu einem Verhalten des "Intel Treiber- und Support-Assistent", der auf meinem PC ohne Rückfrage ein Root-Zertifikat samt privatem Schlüssel installiert hat. Ich habe den Fehler an Intel gemeldet und nach einige Zeit gab es dann auch einen CVS-Eintrag und einen neue Version.

Zeitliche Abfolge

  • 18. Jan 2019 Frank Carius
    Erste Entdeckung des Zertifikats
  • Feb/Mrz 19
    Weitere Untersuchungen, Tests, Analysen, Dokumentation
  • 26. März 19
    Meldung an Intels Security Adresse und BSI
  • 11. Apr 19
    Intel fragt mich, ob ich den Fehler im Bug Bounty Programm einreichen will
  • 9. Mai 19
    Intel hat mir eine erste Zahlung über Hackerone angekündigt und vielleicht noch mal, wenn der CVS-Report veröffentlich wurde.
  • 14. Mai 19
    CVS-Report veröffentlicht. Damit kann ich diese Seite auch veröffentlichen
    https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00252.html

Intel would like to thank Frank Carius from Net at Work GmbH (CVE-2019-11095)
Quelle: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00252.html

Installieren Sie zur Abhilfe die Version "Intel® Driver & Support Assistant 19.4.18" oder höher
https://www.intel.com/content/www/us/en/support/detect.html
https://downloadcenter.intel.com/download/28425/Intel-Driver-Support-Assistant?product=128824

Risikoeinschätzung

Bei der weiteren Analyse der Software und ihrem Verhalten sind einige Dinge aufgefallen, die mich am grundlegenden Design der Software zweifeln lassen.

  • Root-Zertifikat mit Private Key
    Die Software installiert als "LocalSystem" bei jedem Start ein fehlendes Stammzertifikat mit privatem Key und ein Webserver-Zertifikat. Damit dürfte auch eine Malware eigene Zertifikate erstellen und mit dem Private Key signieren können.
  • Der Private Key ist exportierbar
    Schlimm genug, dass er zum Public Key einer RootCA passt, kann das Zertifikat auch noch exportiert werden, was den Zugriff auf den Private Key erleichtert.
  • Auf Localhost erreichbarer Webserver mit Inventardaten
    Eine Malware im User-Kontext kann über diesen Weg Informationen zum System ermitteln, die ein installierter Dienst als "LocalSystem" bereitstellt
  • Inventory, Download und Ausführen von Dateien
    Über die anonyme Webschnittstelle kann der Dienst angewiesen werden, eine Suche nach Updates zu starten, diese aus dem Internet herunter zu laden und deren Installation zu starten. Eine Untersuchung des Webserver-Codes auf Schwachstellen habe ich nicht weiter verfolgt.

Eine saubere Liste der vertrauenswürdigen Stamm-Zertifikate auf einem Client ist die Basis für die Sicherheit von verschlüsselten Verbindungen mit Zertifikaten Beim Verbindungsaufaufbau werden von der Gegenseite übersandte Zertifikate auf ihre Aussteller gegen diese Liste geprüft. Daher ist es kritisch, wenn dieses Vertrauen durch nicht vertrauenswürdige Zertifikate zerstört wird. Daher ist höchste Vorsicht geboten, wenn in der Liste der Stammzertifizierungsstellen ein neues unbekanntes Zertifikat erscheint. Das Zertifikat mit dem Public Key allein ist nur dann kritisch, wenn auch der Datenverkehr über einen Umweg geleitet wird und dort ein zum aufgerufenen Namen passendes Zertifikat dieser CA vorgezeigt wird. Für den Anwender ist dann nicht zu erkennen, dass die Verbindung nicht sicher ist. In diesem Fall wurde aber nicht nur ein Stemmzertifizierungsstellenzertifikat installiert, sondern der dazu passende private Schlüssel gleich mit bereit gestellt. Damit könnte eine Software auf dem Client selbst z.B. die Zugriffe über einen Proxy-Service auf dem gleichen Computer leiten und dynamisch entsprechende Zertifikate erstellen und so jegliche SSL-Verbindung abhören.

Diese Technik ist Standard bei Programmen wie "Fiddler" oder "Charles Proxy", die über genau diesen Weg Verbindungen zu Diagnosezwecken aufbrechen. Dies passiert aber transparent und erfordert die Zustimmung eines Administrators. Sollte das durch Intel installierte Root-Zertifikat aber durch eine Malware verwendet werden, kann der Anwender dies nicht erkennen und es können sensitive Daten abgegriffen oder bei der Übertragung verändert werden.

Das Risiko ist vergleichbar zur früher bekannten Schwächen wie z.B.

Ermitteln der betroffenen Systeme

Um Systeme zu ermitteln, die durch die Schwäche betroffen sind, sollte sowohl die Existenz des Dienstes als auch das Vorhandensein des Zertifikats geprüft werden.

if (Get-Service DSAService -ErrorAction silentlycontinue) {
   write-warning "Intel DSAService found"
}

if (Get-ChildItem cert:\localmachine\root | where {$_.Subject -eq "CN=DSA Root CA"}){
   write-warning "Intel DSA  Root CA Found"
}

Dies kann sehr einfach auch per Skript erfolgen, so dass eine Verteilung als Paket an verwaltete Geräte möglich ist.

Absicherung

Für die Beseitigung der möglichen Lücke sind zwei Schritte erforderlich:

  • Deinstallation der Software "Intel Treiber- und Support-Assistent"
    Dies ist mit Windows Bordmitteln einfach über die Systemsteuerung/Programme möglich. Damit wird das Programm und vor allem der Dienst deinstalliert, welcher bei jedem Start ein Zertifikat erstellt.
  • Entfernen des Stammzertifikats aus dem Zertifikatsspeicher
    Die Deinstallation beseitigt nicht das vom Dienst eingerichtete Stammzertifikat. Das Root-Zertifikat muss aus dem Zertifikatsspeicher entfernt werden.

Hinweis:
Es reicht nicht das das "Root CA"-Zertifikat zu entfernen, da der Dienst "DSAService" bei jedem Start das Stammzertifikat wieder addiert.

Erst wenn der Dienst dauerhaft deaktiviert oder entfernt wurde, muss das Zertifikat zusätzlich entfernt werden. Dies geht z.B. per PowerShell

Get-ChildItem cert:\localmachine\root `
| where {$_.Subject -eq "CN=DSA Root CA"} `
| remove-item

Zufallsfund

Die Aufdeckung dieses fremden Root-Zertifikats verdanke ich einem Zufall. Im Zusammenhang mit einer Überwachungslösung habe ich das PowerShell-Skript "Test-CertificateStore" geschrieben, welches die Zertifikate im Computer-Speicher auf ihre Stimmigkeit prüft. Programme wie Skype for Business reagieren nämlich seltsam, wenn z.B. Stamm-Zertifikate oder Intermediate-Zertifikate im "My-Store" liegen. Das Skript prüft diverse Fehlkonfigurationen und in dem Zuge ist ein Zertifikat mit privatem Schlüssel im Speicher für Stammzertifikate sofort aufgefallen.

Sie sehen hier schon, dass das Stammzertifikat sogar einen privaten Schlüssel mitbringt. Dies sollte auf einem Client nie der Fall sein.

Quelle

Der Name des Zertifikats selbst liefert noch nicht viele Informationen aber das Gültigkeitsdatum fällt genau mit der Installation einer Software zusammen:

Diese Software wird installiert, wen Sie über die Webseite von Intel ein "Treiber Update" ausgeführt haben und dabei die erforderlichen Komponenten installiert wurden. Der Fehler ist in der Vergangenheit aber schon anderen Firmen passiert: Auf einem älteren PC habe ich noch eine installierte Version 3.1.0.12 vom 14.5.2018 gefunden. Die hatte das Stamm-Zertifikat noch nicht installiert

Um die Zusammenhänge besser zu verstehen, habe ich eine frisch aufgesetzte VM genutzt, auf der das Zertifikat noch nicht installiert ist und folgende Schritte ausgeführt:

Download und Installation des "Intel Support Assistent"

Ich habe mir von der Webseite die aktuelle Version 9.3.12.3 des Intel Support Assistent heruntergeladen und installiert.

Quelle: https://www.intel.de/content/www/de/de/support/detect.html 14MB

  • Installiert Windows Dienste in "C:\Program Files (x86)\Intel Driver and Support Assistant\DSAService.exe", der sich als "LocalSystem" anmeldet
    Im Verzeichnis gibt es auch das Programm Makecert.exe Version 10.0.14393.795 (von Microsoft)

    Diese zwei Dienste laufen automatisch an, auch wenn Sie nicht aktiv benutzt werden. Sie belegen entsprechende Ressourcen

    Wenngleich die CPU-Last nicht auffällt

    Allerdings öffnet der DSAService.exe auch zwei TCP-Ports auf Localhost, auf die ich später noch weiter eingehe
  • Neu geschrieben wurde eine "DSAService.exe.Config"
<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <appSettings>
        <add key="AutoCheckScanNextScan" value="636856726636238611" />
    </appSettings>
    <startup>
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5"/>
    </startup>

    <system.serviceModel>
        <services>
            <service name="DSACommunicationService.Dsa">
                <host>
                    <baseAddresses>
                        <add baseAddress="net.pipe://localhost/dsa"/>
                    </baseAddresses>
                </host>
                <endpoint address="net.pipe://localhost/dsa/dsa" binding="netNamedPipeBinding" bindingConfiguration="DsaBinding" contract="DSACommunicationService.IDsa"></endpoint>
            </service>
            <service name="DSAExternalService.External">
                <host>
                    <baseAddresses>
                        <add baseAddress="net.pipe://localhost/dsa"/>
                    </baseAddresses>
                </host>
                <endpoint address="net.pipe://localhost/dsa/external" binding="netNamedPipeBinding" bindingConfiguration="DsaExternalBinding" contract="DSAExternalService.IExternal"></endpoint>
            </service>
        </services>
        <bindings>
            <netNamedPipeBinding>
                <binding name="DsaBinding" maxReceivedMessageSize="512000" sendTimeout="00:05:00">
                    <security mode="Transport">
                        <transport protectionLevel="EncryptAndSign"/>
                    </security>
                </binding>
                <binding name="DsaExternalBinding" maxReceivedMessageSize="512000" sendTimeout="00:05:00">
                    <security mode="Transport">
                        <transport protectionLevel="EncryptAndSign"/>
                    </security>
                </binding>
            </netNamedPipeBinding>
        </bindings>
    </system.serviceModel>
</configuration>
  • Die Installation hat das Root-Zertifikate samt Private Key installiert
Fingerprint: ace87a88ca920671b99391fc0d153afbfa0058ac 
PubliKey
30 82 01 0a 02 82 01 01 00 c4 ee 34 05 e2 e2 d4 a6 3b 9b d5 98 db 6c 15 b0 f5 14 51 95 5e 17 fe 
e5 07 17 93 bd ab 6b 3b b3 ae fc 63 7c 23 78 b0 ec 1a 08 ed c5 01 6d 2a 70 62 43 cd c6 a0 79 03 
33 cf 6e 8d 7b 4f 5e 20 a9 b6 93 e1 11 f8 04 df 21 4b 41 a4 00 01 f4 ec 46 fd 96 f8 44 92 94 f7 
d3 80 fd 3e bd 63 01 9b 6e 1f 08 e0 61 01 bf a5 12 b4 f5 80 0b 79 ba bd ea 9c 5f f9 e3 ed d3 76 
55 b5 c0 45 d1 c3 b5 95 21 b3 e6 9e 0f 6e 2b 5f f2 b6 1e 84 2a af 17 c9 c3 e5 3e b8 92 7d 11 c9 
2f 64 7f 15 8b a2 96 cd dd ee 0d a6 11 da 49 75 e9 15 32 87 51 20 ad f3 67 a4 9f 36 32 24 5f dd 
de 43 2a 66 ef ab 25 b1 49 2c 4d 48 e3 e8 cb cd dc 86 1c bb e3 4f 33 e3 45 f8 bd 28 77 07 1e 88 
45 38 f3 7a 2c 9a 3f d1 3b 4e bc 07 e1 95 a5 0b ad 6f ea dd 5b 9e 95 b5 ce 59 ea 36 1a 83 77 93 
33 8d e9 3c 55 64 be 36 0d 02 03 01 00 01

Das Zertifikat habe ich manuell exportiert um einen Vergleichswert zu haben.

Löschen und Dienst Neustart

Zuerst habe ich das unerwünschte Zertifikat entfernt aber nach dem Neustart des Diensts war es wieder da.

restart-service DSAService

Es hat zwar einen anderen Fingerprint aber den gleichen Public Key.

Fingerprint: dbf88dc92d7f8ce5b02863b540c3ff9503d78cdf
PubliKey
30 82 01 0a 02 82 01 01 00 c4 ee 34 05 e2 e2 d4 a6 3b 9b d5 98 db 6c 15 b0 f5 14 51 95 5e 17 fe 
e5 07 17 93 bd ab 6b 3b b3 ae fc 63 7c 23 78 b0 ec 1a 08 ed c5 01 6d 2a 70 62 43 cd c6 a0 79 03 
33 cf 6e 8d 7b 4f 5e 20 a9 b6 93 e1 11 f8 04 df 21 4b 41 a4 00 01 f4 ec 46 fd 96 f8 44 92 94 f7 
d3 80 fd 3e bd 63 01 9b 6e 1f 08 e0 61 01 bf a5 12 b4 f5 80 0b 79 ba bd ea 9c 5f f9 e3 ed d3 76 
55 b5 c0 45 d1 c3 b5 95 21 b3 e6 9e 0f 6e 2b 5f f2 b6 1e 84 2a af 17 c9 c3 e5 3e b8 92 7d 11 c9 
2f 64 7f 15 8b a2 96 cd dd ee 0d a6 11 da 49 75 e9 15 32 87 51 20 ad f3 67 a4 9f 36 32 24 5f dd 
de 43 2a 66 ef ab 25 b1 49 2c 4d 48 e3 e8 cb cd dc 86 1c bb e3 4f 33 e3 45 f8 bd 28 77 07 1e 88 
45 38 f3 7a 2c 9a 3f d1 3b 4e bc 07 e1 95 a5 0b ad 6f ea dd 5b 9e 95 b5 ce 59 ea 36 1a 83 77 93 
33 8d e9 3c 55 64 be 36 0d 02 03 01 00 01

Damit dürfte hier auch der gleiche private Key genutzt werden.

Komplette Deinstallation

Das Zertifikat habe ich nun nicht mehr entfernt, sondern die Software klassisch über die Systemsteuerung deinstalliert.

  • Software deinstalliert sich ohne Fehler
    In der Systemsteuerung wird der Eintrag entfernt
    Die Windows Dienste werden deinstalliert
  • Keine Dateien mehr im Programm-Verzeichnis C:\Program Files (x86)\Intel Driver and Support Assistant\
  • Logdateien in C:\ProgramData\Intel\DSA
    Diese lösche ich dann von Hand
  • Das Zertifikat verbleibt im Store
    Die Deinstallationsroutine vergisst her das Löschen des Zertifikats. Ich habe das Zertifikat exportiert und gelöscht, ehe eine Neuinstallation erfolgt ist

Zweite Neuinstallation

Um das Verhalten nachzustellen, habe ich die Software ein weiteres Mal installiert. Auch diesmal wurde ein Root Zertifikat mit privatem Schlüssel installiert. Der Finderabdruck ist wieder anders aber der öffentliche Schlüssel zur vorherigen Installation identisch:

Fingerprint: 16fb2aa33c3d58350333d3e5d63eea746cebe885
PubliKey
30 82 01 0a 02 82 01 01 00 c4 ee 34 05 e2 e2 d4 a6 3b 9b d5 98 db 6c 15 b0 f5 14 51 95 5e 17 fe 
e5 07 17 93 bd ab 6b 3b b3 ae fc 63 7c 23 78 b0 ec 1a 08 ed c5 01 6d 2a 70 62 43 cd c6 a0 79 03 
33 cf 6e 8d 7b 4f 5e 20 a9 b6 93 e1 11 f8 04 df 21 4b 41 a4 00 01 f4 ec 46 fd 96 f8 44 92 94 f7 
d3 80 fd 3e bd 63 01 9b 6e 1f 08 e0 61 01 bf a5 12 b4 f5 80 0b 79 ba bd ea 9c 5f f9 e3 ed d3 76 
55 b5 c0 45 d1 c3 b5 95 21 b3 e6 9e 0f 6e 2b 5f f2 b6 1e 84 2a af 17 c9 c3 e5 3e b8 92 7d 11 c9 
2f 64 7f 15 8b a2 96 cd dd ee 0d a6 11 da 49 75 e9 15 32 87 51 20 ad f3 67 a4 9f 36 32 24 5f dd 
de 43 2a 66 ef ab 25 b1 49 2c 4d 48 e3 e8 cb cd dc 86 1c bb e3 4f 33 e3 45 f8 bd 28 77 07 1e 88 
45 38 f3 7a 2c 9a 3f d1 3b 4e bc 07 e1 95 a5 0b ad 6f ea dd 5b 9e 95 b5 ce 59 ea 36 1a 83 77 93 
33 8d e9 3c 55 64 be 36 0d 02 03 01 00 01

Es stehen also weitere Untersuchungen an, wie "zufällig" die Generierung des Zertifikats ist oder ob sich das Programm an lokalen Kriterien orientiert.

Neuinstallation auf anderem PC

Daher habe ich die Software auf einem anderen PC installiert. Auch hier wird wieder ein Root Zertifikat samt privatem Schlüssel installiert. Diesmal aber ist der Public Key abweichend. Das macht Hoffnung, dass auf unterschiedlichen Computern daher nicht der gleiche private Schlüssel genutzt wird.

Analyse mit Filemon

Nun war natürlich eine weitergehende Analyse angesagt. Mit Sysinternals Filemon konnte ich dann auch den Aufruf von "MakeCert" beim Start des Dienstes finden:

Die Parameter wurden zur besseren Lesbarkeit umgebrochen.

"C:\Program Files (x86)\Intel\Driver and Support Assistant\makecert.exe" 
   -pe 
   -n "CN=DSA Root CA" 
   -r 
   -sk "DSA Root CA" 
   -sr LocalMachine 
   -ss Root "C:\ProgramData\Intel\DSA\DSA_Root_CA.cer"

Die Parameter bedeuten:

  • -pe
    Private Key exportierbar
  • -n
    Name des Zertifikats
  • -r
    Selbst signiertes Zertifikat anlegen
  • -sk
    Speicher für den privaten Schlüssel
  • -sr
    Speichere Zertifikat im Computerstore
  • -ss
    Speichere Zertifikat als Datei

Die Parameter sind so nichts Besonderes aber warum der private Schlüssel exportierbar sein muss, wissen vermutlich nur die Intel-Entwickler. Kurz darauf ist dann der Aufruf zur Erstellung eines davon abgeleiteten Zertifikats zu sehen:

"C:\Program Files (x86)\Intel\Driver and Support Assistant\makecert.exe" 
-pe 
-n "CN=dsalocal.intel.com" 
-ir LocalMachine 
-is Root 
-ic "C:\ProgramData\Intel\DSA\DSA_Root_CA.cer" 
-sk "dsalocal.intel.com" 
-sr LocalMachine 
-ss TrustedPeople "C:\ProgramData\Intel\DSA\DSA_Local.cer"

Passend dazu gibt es auch eine Logdatei C:\ProgramData\Intel\DSA\Service.log, welche die Anlage des Zertifikats sogar protokolliert:

Date/Time            Severity      Class                                    Method          Data    Message
25.03.2019 21:07:16  Information   DSAService.Service                       OnStart     ()     Starting version 19.3.12.3
25.03.2019 21:07:16  Information   DSACore.SettingsController               LogSettings     ()     IsDevVersion: False
25.03.2019 21:07:16  Information   DSACore.SettingsController               LogSettings     ()     IsBetaVersion: False
25.03.2019 21:07:16  Information   DSACore.SettingsController               LogSettings     ()     LanguageSetting: SystemDefault
25.03.2019 21:07:16  Information   DSACore.SettingsController               LogSettings     ()     SourceEnvironment: Production
25.03.2019 21:07:16  Information   DSACore.SettingsController               LogSettings     ()     OverrideIntelDetection: False
25.03.2019 21:07:16  Information   DSACore.SettingsController               LogSettings     ()     LogDirectory: C:\ProgramData\Intel\DSA
25.03.2019 21:07:16  Information   DSACore.SettingsController               LogSettings     ()     DownloadDirectory: 
25.03.2019 21:07:16  Information   DSACore.SettingsController               LogSettings     ()     ConcurrentDownloads: 3
25.03.2019 21:07:16  Information   DSACore.SettingsController               LogSettings     ()     AutoCheckScanFrequency: Weekly
25.03.2019 21:07:16  Information   DSAService.Service                       StartDsaCommunicationService     ()     WCF service started
25.03.2019 21:07:16  Information   DSARestService.RestHttpListener          StartListening     ()     Start
25.03.2019 21:07:16  Information   DSARestService.RestHttpListener          StartListening     (httpsPort: 28380, httpPort: 28385)     Start
25.03.2019 21:07:16  Information   DSARestService.RestHttpListener          StartListening     ()     Started listening on ports 28380, 28385
25.03.2019 21:07:16  Information   DSARestService.RestHttpListener          StartListening     (True)     End
25.03.2019 21:07:16  Information   DSARestService.SslCertificateController  ConfigureSsl     (httpsPort: 28380, appGuid: 95dd58d0-9a33-4ad8-a8e6-2b9bf177e8c8)     Start
25.03.2019 21:07:16  Information   DSARestService.SslCertificateController  RemoveCertificates     ()     Start
25.03.2019 21:07:16  Information   DSARestService.SslCertificateController  RemoveSslCertificate     ()     Removing certificate 
25.03.2019 21:07:16  Information   DSARestService.SslCertificateController  RemoveCertificates     ()     End
25.03.2019 21:07:16  Information   DSARestService.SslCertificateController  InstallCertificates     ()     Start
25.03.2019 21:07:16  Information   DSARestService.SslCertificateController  InstallCertificates     ()     End
25.03.2019 21:07:16  Information   DSARestService.SslCertificateController  UpdateCertificateBinding     ()     Bound SSL certificate D705B7C992806CFC935B1C99D15D357D3339FB1A to port 28380
25.03.2019 21:07:16  Information   DSARestService.SslCertificateController  ConfigureSsl     (True)     End
25.03.2019 21:07:16  Information   DSARestService.RestHttpListener          StartListening     (True)     End
25.03.2019 21:07:16  Information   DSAService.Service                       StartRestService     ()     REST service started
25.03.2019 21:07:16  Information   DSAService.Service                       StartExternalService     ()     WCF external service started
25.03.2019 21:07:16  Information   DSAService.Service                       InitializeAutoScan     ()     Auto-scan started
25.03.2019 21:07:16  Information   DSAService.Service                       StartUpdateService     ()     Started DSAUpdateService
25.03.2019 21:07:16  Information   DSAService.Service                       OnStart     ()     Successful startup
25.03.2019 21:07:16  Information   DSAService.Service                       StartTray     ()     Started Tray (C:\Program Files (x86)\Intel\Driver and Support Assistant\DSATray.exe)

Ich interpretiere die Zeilen dahingehend, dass lokal ein kleiner HTTP-Service gestartet wird, der sich selbst ein Zertifikat ausstellt, welches von der vorher installierten RootCA signiert wurde. Im Ressourcen Manager ist die Bindung auch zu sehen:

Auf dem Port 28385 lauscht ein Webserver ohne Verschlüsselung.

Auf Port 28380 hingegen wird folgendes Zertifikat ausgeliefert:

Damit der Client den Weg zu diesem Server findet, löst Intel den Namen im Internet auf Loopback auf.

C:\>nslookup dsalocal.intel.com
Server:  fritz.box
Address:  192.168.178.1

Nicht autorisierende Antwort:
Name:    dsalocal.intel.com
Addresses:  ::1
          127.0.0.1

Analyse mit Fiddler

Die Implementierung als kleiner Webserver erleichtert es natürlich der Webseite https://www.intel.de/content/www/de/de/support/intel-driver-support-assistant.html die lokalen Daten per JavaScript und HTTP abzurufen. Der Request ist mit Fiddler einfach zu ermitteln, wenn der Button "Erneut scannen" gedrückt wird:

Die Webseite startet dann einen einzigen HTTP-GET Request auf die URL:

http://127.0.0.1:28385/intel/v1.0/detect/getproductsanddownloads?language=de&country=de&jsver=2019.1.4.1

Interessanterweise nutzt die Webseite hier HTTP und nicht HTTPS.

Der Aufruf liefert bei mir eine fast 40kbyte große JSON Datei. Eine direkte Eingabe der URL per Browser wird aber nicht ausgeführt. Der kleine Webserver prüft den Origin, der aber per PowerShell einzufügen ist.

Beim Versuch auf dem gleichen Computer über die IP-Adresse der Netzwerkkarte zuzugreifen, kommt keine Verbindung zustande. Ein Zugriff von einem Remote System ist aber nicht direkt möglich, da keine Regel in der Windows Firewall diese eingehenden Verbindungen erlaubt. Mit deaktivierter Firewall hat der Dienst keine Verbindung angenommen.

Hier hat Intel es zumindest besser gemacht, dass der Service nur auf dem Loopback-Adapter gebunden ist. Dennoch könnte auch ein Angreifer auf dem Computer selbst so ein umfangreiches Inventory ohne besondere Rechte erhalten.

Download von Updates

Interessant wird es natürlich wieder bei dem Download von Updates. Ein Druck auf den entsprechenden Button weist den Dienst ohne weitere Authentifizierung an, die Software zu laden.

In der folge prüft der Client den Fortschritt durch sehr schnelle Abfragen um den Status in der Webseite anzuzeigen

Nach dem Druck auf "Installieren" wird auch diese Aktion per HTTP ohne Authentifizierung dem Dienst mitgeteilt, der dann die Installation startet. Die Webseite fragt weiter den Status ab.

Ich hoffe nun mal, dass hier keine offenen Türen sind, um fremde Programme zur Installation unterzuschieben. Er läuft immerhin als "LocalSystem". Für die vom Dienst gestartete Installation zeigt Windows bei mir einen UAC-Dialog an.

Zwischenstand

Wie anfangs geschrieben habe ich das Root-Zertifikat und den privaten Schlüssel relativ einfach exportieren können. Das Zertifikat scheint auf unterschiedlichen Systemen auch unterschiedliche private Schlüssel zu erstellen. Insofern ist es wenig wahrscheinlich, dass mit so einem Zertifikat eine "Man in the Middle"-Attacke auf dem Netzwerk gefahren werden kann. Allerdings ist so ein Zertifikat natürlich eine Steilvorlage für eine Malware, die sich nicht mehr selbst um die Hinterlegung eines Stammzertifikats kümmern muss. Selbst wenn das Risiko gering erscheint sollte jeder Entwickler um die Thematik Bescheid wissen, so dass so ein grober Fehler nicht passieren kann.

Ich habe mich dahingehen mit den Experten aus dem NoSpamProxy Team und Entwicklung bei Net at Work abgestimmt und nach einhelliger Meinung entschieden, diesen Sachverhalt sowohl an Intel als auch das BSI zu melden.

Intel Kommunikation / Bug Bounty

Ich habe nun eigentlich gedacht, dass ich den Hersteller (Intel) und das BSI erst einmal über meine "Entdeckung" informiere und das weitere Vorgehen abspreche. Ich bin ja kein "Vollzeit-Hacker" und ich habe weder Zeit noch das Wissen die Tragweite der Entdeckung tiefgreifend zu analysieren und ein Gefährdungsrating abzugeben. Es sollte doch auf der "anderen Seite" sehr einfach möglich sein, durch eine Rücksprache mit den Entwicklern oder Sicherheitsleuten so eine Einschätzung selbst zu erstellen. Aber die Realität sieht wohl anders aus

  • BSI
    Das BSI hat sich über die Rückmeldung bedankt aber hat mich zuerst darum gebeten, die Erkenntnisse an den Hersteller zu melden. Sollte sich der Hersteller allerdings nicht weiter drum kümmern, könnte ich gerne noch mal auf das BSI zurück kommen, damit das BSI noch mal den Kontakt zum Hersteller suche.
  • Intel
    Noch irritierender war die Kommunikation mit Intel. Ich habe zwar eine Adresse zur Meldung gefunden aber die weitre Kommunikation ist sehr zäh. Zum einen ist eine verschlüsselte Meldung per Mail gefordert. Ein HTTPS-Formular" ist wohl zu modern. Aber gruselig wurde es dann beim Thema "Bug Bounty". Intel erfordert dabei nicht nur eine Zusicherung alle Vorbedingungen zu erfüllen sondern auch eine sehr umfangreiche Selbsteinschätzung der Lücke, ehe Sie im Bug Bounty-Programm aufgenommen wird. Das Bug Bounty-Programm läuft auf https://hackerone.com/intel/. Den Link habe ich per unverschlüsselter und unsignierter Mail erhalten.

    Weiter unten, wo man den Report einstellen kann, steht wieder deutlich, dass man alles mit dem PGP-Key verschlüsseln muss.

Ich wurde den Eindruck nicht los, dass Intel gar kein Interesse an einer offenen Kommunikation hat. Erst als ich letztlich meine Unzufriedenheit erklärt, meinen Verzicht auf "Bug Bounty" in Aussicht gestellt und eine direkte Veröffentlichung vorgeschlagen habe, kam Bewegung in den Vorgang. Auf einmal meldet sich dann auch ein Mensch, zeigt Verständnis für meine Sichtweise und versprach Abhilfe. Das ist dann auch tatsächlich passiert.

Danach gibt es erfreulich schnell, wie ich ganz am Anfang auf der Zeitskala angegeben habe. In weniger als einem Monat hat Intel eine neue Version entwickelt und bereitgestellt, einen CVS-Report veröffentlicht und die Bug Bountry Transaktionen über HackerOne abgeschlossen.

Interessant finde ich nur, dass sich nun sehr viele Einladungen anderer Firmen bekomme, die für ihre Produkte über HackerOne nach Personen suchen, die diese unter die Lupe nehmen. Da gibt es wohl einen regen Markt. Allerdings werde ich hier eher nicht weiter aktiv werden können.

Weitere Links