9
Eigene installierte Zertifikate von anderen Programmen ausnutzbar Sicherheitslücke
Hallo,
Ich habe leider nicht viel Ahnung von Zertifikaten.
Wenn ein Programm wie z.b. Avast beim HTTPS oder Email TLS-Scanning oder Lenovo mit Ihrer Adware Superfish oder auch ganz einfach ich, wenn ich ein Zertifikat von einem Remote Computer den ich ansteuern will installiere, zugriff auf diese Zertifikate hat kann das Programm dann Maninthe Middle ?
Soll ja bei Superfish der Fall sein. Allerdings verstehe ich das nicht ganz.
Ein Zertifikat kommt ja von der Webseite die verschlüsselt. Dieses wird überprüft mit meinem installierten Zertifikaten. Diese wiederum durch die Root of Chain (trust of Chain) via Internet verifiziert.
Wenn nun ein Programm sagen wir mal an das Avast Zertifikat kommt (kommt es ja da es installiert ist) wie kann es dann Man in the Middle machen?
Die Webseite die ich aufrufe und verschlüsselt ist sendet mir ihr Zertifikat, das Programm nun hat das von Avast also ein Root Zertifikat, aber was bringt das? Mein Rechner überprüft das Zerti der Webseite und das hat mit dem Avast Zertifikat nichts zu tun?
Ich habe leider nicht viel Ahnung von Zertifikaten.
Wenn ein Programm wie z.b. Avast beim HTTPS oder Email TLS-Scanning oder Lenovo mit Ihrer Adware Superfish oder auch ganz einfach ich, wenn ich ein Zertifikat von einem Remote Computer den ich ansteuern will installiere, zugriff auf diese Zertifikate hat kann das Programm dann Maninthe Middle ?
Soll ja bei Superfish der Fall sein. Allerdings verstehe ich das nicht ganz.
Ein Zertifikat kommt ja von der Webseite die verschlüsselt. Dieses wird überprüft mit meinem installierten Zertifikaten. Diese wiederum durch die Root of Chain (trust of Chain) via Internet verifiziert.
Wenn nun ein Programm sagen wir mal an das Avast Zertifikat kommt (kommt es ja da es installiert ist) wie kann es dann Man in the Middle machen?
Die Webseite die ich aufrufe und verschlüsselt ist sendet mir ihr Zertifikat, das Programm nun hat das von Avast also ein Root Zertifikat, aber was bringt das? Mein Rechner überprüft das Zerti der Webseite und das hat mit dem Avast Zertifikat nichts zu tun?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 285650
Url: https://administrator.de/contentid/285650
Printed on: April 26, 2024 at 20:04 o'clock
9 Comments
Latest comment
Hallo,
ne, falsch.
Hier einmal ganz kurz.
Du geht auf eine Webseite.
Diese sendet Dir Ihr Zertifikat.
In diesem Zertifikat steht für welche Webseite es gilt und von wem es ausgestellt wurde.
Nun prüft Dein Computer
a) Ob das Zertifikat technisch gültig ist (Ablaufdatum und Webadresse)
b) Ob das Zertifikat von jemanden Vertrauenswürdigen ausgestellt wurde.
Für B hat jeder Browser und jedes Betriebssystem eine Liste von vertrauenswürden Zertifikatstellen.
Sogenannte CAs.
Jeder kann ein Zertifikat für google.com ausstellen an seinem Computer.
Aber es stammt halt nicht von der richtigen CA.
Nun installiert böse Software eine eigene CA in dieser Liste und kann für alle Domains Zertifikate ausstellen.
Dein Browser akzeptiert dann das Zertifikat für google.com ausgestellt von "böse Software" da "böse Software" ja eine vertrauenswürdige CA ist.
Und das führt dann zu einem Man in the middle Angriff.
Viele Grüße
Stefan
ne, falsch.
Hier einmal ganz kurz.
Du geht auf eine Webseite.
Diese sendet Dir Ihr Zertifikat.
In diesem Zertifikat steht für welche Webseite es gilt und von wem es ausgestellt wurde.
Nun prüft Dein Computer
a) Ob das Zertifikat technisch gültig ist (Ablaufdatum und Webadresse)
b) Ob das Zertifikat von jemanden Vertrauenswürdigen ausgestellt wurde.
Für B hat jeder Browser und jedes Betriebssystem eine Liste von vertrauenswürden Zertifikatstellen.
Sogenannte CAs.
Jeder kann ein Zertifikat für google.com ausstellen an seinem Computer.
Aber es stammt halt nicht von der richtigen CA.
Nun installiert böse Software eine eigene CA in dieser Liste und kann für alle Domains Zertifikate ausstellen.
Dein Browser akzeptiert dann das Zertifikat für google.com ausgestellt von "böse Software" da "böse Software" ja eine vertrauenswürdige CA ist.
Und das führt dann zu einem Man in the middle Angriff.
Viele Grüße
Stefan
Hallo Stefan,
Das verstehe ich nicht ganz. Wenn böse Software ein Zertifikat ausstellt, kann es doch gar nicht in der Root of Chain überprüft werden. Oder meinst du das stimmt so nicht? Ich dachte jedes Zertifikat wird überprüft bis hin zum Root, welches ja einmalig sein sollte.
Auch müsste so ja das böse Programm für tausende Webseiten Zertifikate ausstellen oder? Jedenfalls wenn es alle belauschen will, so wie Avast https scanning.
Das verstehe ich nicht ganz. Wenn böse Software ein Zertifikat ausstellt, kann es doch gar nicht in der Root of Chain überprüft werden. Oder meinst du das stimmt so nicht? Ich dachte jedes Zertifikat wird überprüft bis hin zum Root, welches ja einmalig sein sollte.
Auch müsste so ja das böse Programm für tausende Webseiten Zertifikate ausstellen oder? Jedenfalls wenn es alle belauschen will, so wie Avast https scanning.
Hallo,
doch.
Das böse Programm bekommt die Anfrage für google.com.
Dann stellt es ein Zertifikat für google.com und sich selbst als CA aus.
Der Browser überprüft das Zertifikat: OK
CA ist das böse Programm: OK
CA (das böse Programm) ist vertrauenswürdig: OK
Wenn der User sich das Zertifikat mit Chain anschauen würde, würde er das sehen.
Aber das schaut sich ja keiner an.
Und ja, z.B. eine UTM Firewall mit HTTPs Proxy stellt hunderte bis tausende Zertifikate aus.
Stell Dir Firma X vor.
Die hat 1000 Mitarbeiter und die sollen durch eine Firewall von Viren von Websiten geschützt werden.
Zum prüfen von HTTPs Verbindungen muss die Firewall einen ManInTheMiddle-Angriff ausführen.
Diesmal sogar gewünscht.
Stefan
doch.
Das böse Programm bekommt die Anfrage für google.com.
Dann stellt es ein Zertifikat für google.com und sich selbst als CA aus.
Der Browser überprüft das Zertifikat: OK
CA ist das böse Programm: OK
CA (das böse Programm) ist vertrauenswürdig: OK
Wenn der User sich das Zertifikat mit Chain anschauen würde, würde er das sehen.
Aber das schaut sich ja keiner an.
Und ja, z.B. eine UTM Firewall mit HTTPs Proxy stellt hunderte bis tausende Zertifikate aus.
Stell Dir Firma X vor.
Die hat 1000 Mitarbeiter und die sollen durch eine Firewall von Viren von Websiten geschützt werden.
Zum prüfen von HTTPs Verbindungen muss die Firewall einen ManInTheMiddle-Angriff ausführen.
Diesmal sogar gewünscht.
Stefan
1
Ich glaube ich habe es schon mehr verstanden. Ist das so korrekt?
google.com wird aufgerufen
Die Firewall merkt das und sagt dem Browser: Hey, ich bin Google!
Browser sagt: Glaub ich nicht, zeig dein Zertifikat. Firewall sagt klar Mann! Hier: Und zeigt das Zertifikat das zum Root Zertifikat ,welches die Firewall vorher im Browser/Windows Zertifikatsspeicher installiert hat, passt (Hash und privater / Public Key passen).
Browser sagt: Passt zu dem Zertifikat was ich habe, eine nächst höhere CA gibt es auch nicht also bist du google!
Firewall lässt mich nun weiter zu dem echten Google kann aber parallel alles mitschneiden da sie auch Google ist.
Korrekt so? Das gleiche geht dann aber auch mit anderen Seiten und dem gleichen Root Zertifikat, also muss nur eins Installiert werden. Die Firewall muss allerdings für jede Webseite einfach den Namen der Seite ins Zertifikat eintragen.
Richtig?
google.com wird aufgerufen
Die Firewall merkt das und sagt dem Browser: Hey, ich bin Google!
Browser sagt: Glaub ich nicht, zeig dein Zertifikat. Firewall sagt klar Mann! Hier: Und zeigt das Zertifikat das zum Root Zertifikat ,welches die Firewall vorher im Browser/Windows Zertifikatsspeicher installiert hat, passt (Hash und privater / Public Key passen).
Browser sagt: Passt zu dem Zertifikat was ich habe, eine nächst höhere CA gibt es auch nicht also bist du google!
Firewall lässt mich nun weiter zu dem echten Google kann aber parallel alles mitschneiden da sie auch Google ist.
Korrekt so? Das gleiche geht dann aber auch mit anderen Seiten und dem gleichen Root Zertifikat, also muss nur eins Installiert werden. Die Firewall muss allerdings für jede Webseite einfach den Namen der Seite ins Zertifikat eintragen.
Richtig?
Hallo,
im groben: Ja.
Die Firewall erstellt Zertifikate die im Prinzip 2 Informationen enthalten.
1. Die URL/Domäne der Seite
2. Sich selbst als CA
Woher soll der Browser den Unterschied wissen zwischen Symantec-CA und z.B. Gateprotect-Firewall-CA?
Beides sind vertrauenswürdige installierte CAs.
Schau Dir mal das Zertifikat von https://google.de an.
Dort ist GetTrust Global CA die vertrauenswürdige CA.
Der einzige Unterschied bei einer Https-Proxy-Firewall wäre das hier Gateprotect CA steht.
Viele Grüße
Stefan
im groben: Ja.
Die Firewall erstellt Zertifikate die im Prinzip 2 Informationen enthalten.
1. Die URL/Domäne der Seite
2. Sich selbst als CA
Woher soll der Browser den Unterschied wissen zwischen Symantec-CA und z.B. Gateprotect-Firewall-CA?
Beides sind vertrauenswürdige installierte CAs.
Schau Dir mal das Zertifikat von https://google.de an.
Dort ist GetTrust Global CA die vertrauenswürdige CA.
Der einzige Unterschied bei einer Https-Proxy-Firewall wäre das hier Gateprotect CA steht.
Viele Grüße
Stefan
Ok wenn das oben korrekt ist dann habe ich es verstanden. Bei mir kommt allerdings bei google.de kein GetTrust, sondern Avast Webshield 
Wenn ich mir das anschaue steht darunter google. Gutes Beispiel :=
Danke Dir schon mal! Wenn du Lust hast kannst du mal hier drüber lesen. Habe ich geschrieben um es mir zu merken. Falls das im groben korrekt ist sollte ich es verstanden haben:
Zertifikat kommt an. ist verschlüsselt mit dem privatem Key der CA. Kann also nur mit dem öffentlichem entschlüsselt werden. Kam ich es nicht ist es ein Hacker.
Denn nur die CA hat den privaten Key für das Zertifikat und ich den öffentlichen. Der Hacker kann keine passenden privaten der zu meinem öffentlichen passt erstellen.
Auch hier muss der öffentliche wieder stimmen (der kann ja gefälscht sein, wenn ein Hacker auf meinem Rechner ein Zertifikat mit gefälschten öffentlicherem unterschiebt als man in the middle. Ist er auf meinem PC kam er eh alles tun und auch Root Zertifikat erstellen, es geht nur um MitM).
Die nächst höhere CA verschlüsselt mit ihrem privaten Key wieder das Zertifikat welches das vorige Zertifikat, das auch den öffentlichen Key enthält zertifiziert. Auch hier kam man das Zertifikat wieder nur mit dem öffentlichem Key öffnen. Kam ich es öffnen stimmt das vorige Zertifikat mit dem dazugehörigen öffentlichem Key. Usw. Dem Root wird bedingungslos vertraut. Quasi der letzte Öffentliche ..
Die Inhalt eines Zertifikat kann zusätzlich geprüft werden durch den Hashwert:
Ein von einer CA signiertes Zertifikat kann jederzeit auf korrekte Integrität geprüft werden. Dabei wird ein Hashwert über die Payload des Zertifikats gebildet und dann die Digitale Signatur des Zertifikats mit dem öffentlichen Schlüssel der CA entschlüsselt. Anschließend wird der entschlüsselte Hashwert mit dem vorher berechneten verglichen – stimmen beide Werte überein, so ist die Integrität gewährleistet.
Hier wurde natürlich vorher die Chain of Trust geprüft und für gut befunden.
Wenn ein Hacker sein eigenes Zertifikat erstellt ist die Kette unterbrochen. Denn er kann nicht bis hin zum Root Fälschen. Hier Bundesnetzagentur.
Wenn ich mir das anschaue steht darunter google. Gutes Beispiel :=Danke Dir schon mal! Wenn du Lust hast kannst du mal hier drüber lesen. Habe ich geschrieben um es mir zu merken. Falls das im groben korrekt ist sollte ich es verstanden haben:
Zertifikat kommt an. ist verschlüsselt mit dem privatem Key der CA. Kann also nur mit dem öffentlichem entschlüsselt werden. Kam ich es nicht ist es ein Hacker.
Denn nur die CA hat den privaten Key für das Zertifikat und ich den öffentlichen. Der Hacker kann keine passenden privaten der zu meinem öffentlichen passt erstellen.
Auch hier muss der öffentliche wieder stimmen (der kann ja gefälscht sein, wenn ein Hacker auf meinem Rechner ein Zertifikat mit gefälschten öffentlicherem unterschiebt als man in the middle. Ist er auf meinem PC kam er eh alles tun und auch Root Zertifikat erstellen, es geht nur um MitM).
Die nächst höhere CA verschlüsselt mit ihrem privaten Key wieder das Zertifikat welches das vorige Zertifikat, das auch den öffentlichen Key enthält zertifiziert. Auch hier kam man das Zertifikat wieder nur mit dem öffentlichem Key öffnen. Kam ich es öffnen stimmt das vorige Zertifikat mit dem dazugehörigen öffentlichem Key. Usw. Dem Root wird bedingungslos vertraut. Quasi der letzte Öffentliche ..
Die Inhalt eines Zertifikat kann zusätzlich geprüft werden durch den Hashwert:
Ein von einer CA signiertes Zertifikat kann jederzeit auf korrekte Integrität geprüft werden. Dabei wird ein Hashwert über die Payload des Zertifikats gebildet und dann die Digitale Signatur des Zertifikats mit dem öffentlichen Schlüssel der CA entschlüsselt. Anschließend wird der entschlüsselte Hashwert mit dem vorher berechneten verglichen – stimmen beide Werte überein, so ist die Integrität gewährleistet.
Hier wurde natürlich vorher die Chain of Trust geprüft und für gut befunden.
Wenn ein Hacker sein eigenes Zertifikat erstellt ist die Kette unterbrochen. Denn er kann nicht bis hin zum Root Fälschen. Hier Bundesnetzagentur.
Moin,
Dann kann er Zertifikate erstellen die für den Client immer gültig aussehen... solange sie nicht durch die OS oder Browser Hersteller "revoked"(zurückgezogen) werden.
, die oberste CA ist immer die letzte Instanz einer Zertifikatskette, es gibt hier nicht "das" root, sondern mehrere zertifizierte Certificate Authorities.
Ein CA könntest du theroetisch selber ins Leben rufen, nur ... damit deine CA in die gängigen Browser und Betriebsysteme aufgenommen werden müssen jede Menge Auflagen erfüllt werden die eine Stange Geld kosten (physische Sicherung der CA, etc. pp).
Ein Hacker der sich also Zugang zu einer etwas schwächer gesicherten CA verschaffen kann und sich dann mit dem erbeuteten private Key der CA (kann auch eine Intermediate CA sein) Zertifikate erstellt, hat allerbeste Voraussetzungen für MITM Angriffe, die kein Client bemerkt.
Zur praktischen Anwendung einfach das hier mal durchlesen
http://blog.philippheckel.com/2013/07/01/how-to-use-mitmproxy-to-read-a ...
Inzwischen setzen die großen der Branche wie Google etc. Public Key Pinning ein womit sie die von Ihnen verwendeten CAs in einer Liste führen und somit verhindern das von korrumpierten CAs ausgestellte Zertifikate für Ihre Domains beim Zugriff auf Ihre Domains verwendet werden können.
Aber selbst diese Listen welche über den Response-Header an den Client ausgeliefert werden, könnte ein Angreifer fälschen. Es legt die Latte halt nur wieder etwas höher.
Gruß jodel32
Wenn ein Hacker sein eigenes Zertifikat erstellt ist die Kette unterbrochen. Denn er kann nicht bis hin zum Root Fälschen.
Der Hacker muss entweder dem Client ein Stammzertifikat seiner eigenen CA unterschieben oder selber Zugang zu einer CA haben welche in den meisten Browsern der User als gültig ausgewiesen sind. Es gab ja in der Vergangenheit schon mal Fälle bei denen in eine CA eingebrochen und Keys entwendet wurden.Dann kann er Zertifikate erstellen die für den Client immer gültig aussehen... solange sie nicht durch die OS oder Browser Hersteller "revoked"(zurückgezogen) werden.
Hier Bundesnetzagentur.
Nein die hat damit gar nichts am Hut , die oberste CA ist immer die letzte Instanz einer Zertifikatskette, es gibt hier nicht "das" root, sondern mehrere zertifizierte Certificate Authorities.Ein CA könntest du theroetisch selber ins Leben rufen, nur ... damit deine CA in die gängigen Browser und Betriebsysteme aufgenommen werden müssen jede Menge Auflagen erfüllt werden die eine Stange Geld kosten (physische Sicherung der CA, etc. pp).
Ein Hacker der sich also Zugang zu einer etwas schwächer gesicherten CA verschaffen kann und sich dann mit dem erbeuteten private Key der CA (kann auch eine Intermediate CA sein) Zertifikate erstellt, hat allerbeste Voraussetzungen für MITM Angriffe, die kein Client bemerkt.
Zur praktischen Anwendung einfach das hier mal durchlesen
http://blog.philippheckel.com/2013/07/01/how-to-use-mitmproxy-to-read-a ...
Inzwischen setzen die großen der Branche wie Google etc. Public Key Pinning ein womit sie die von Ihnen verwendeten CAs in einer Liste führen und somit verhindern das von korrumpierten CAs ausgestellte Zertifikate für Ihre Domains beim Zugriff auf Ihre Domains verwendet werden können.
Aber selbst diese Listen welche über den Response-Header an den Client ausgeliefert werden, könnte ein Angreifer fälschen. Es legt die Latte halt nur wieder etwas höher.
Gruß jodel32
1
Moin,
ganz frisch zu diesem Thema.
http://www.heise.de/newsticker/meldung/SSL-Zertifizierungsstellen-stell ...
Viele Grüße
Stefan
ganz frisch zu diesem Thema.
http://www.heise.de/newsticker/meldung/SSL-Zertifizierungsstellen-stell ...
Viele Grüße
Stefan
1
Vielen Dank noch mal an jodel32 und Stefan für die weiteren interessanten Infos!