[English]Noch ein kleiner Sicherheitssplitter zum Wochenabschluss. Microsoft patzt momentan erheblich bei der Auslieferung von Updates. Der Microsoft Update Catalog hat Ladehemmung, wenn er über die falsche URL aufgerufen wird. Und unter dem Motto 'Security by obscurity' werden Updates per HTTP statt per HTTPS ausgeliefert. Das gilt übrigens auch für Downloads aus dem Microsoft Update Catalog.
Anzeige
Update-Download per HTTP?
Stefan Kanthak hat mir vorgestern eine Mail geschickt, in der er auf eine äußerst unschöne Geschichte hinweist. Hier der Auszug aus seiner Mail vom 14. Februar 2018:
In Deinem Blog verwendest Du dummerweise auch http: statt https: nicht nur fuer den Microsoft Update Catalog.
Pruefst Du die SHA1-Pruefsumme der heruntergeladenen Updates? Die Authenticode-Signatur? Holst Du die Updates von dort per http:, falls (ein Poehsewicht) die "automatischen Updates" blockieren sollte(n)? Oder doch lieber per https:?
Worum es bei diesen Zeilen geht? In meinen Blog-Beiträgen zu den Updates am Microsoft-Patchday übernehme ich die Links zu den KB-Artikeln aus der Microsoft-Dokumentation. Und dort arbeitet Microsoft noch mit Verlinkungen auf http-Seiten. Das wäre noch nicht mal so schlimm.
Aber das Thema geht noch weiter. Ruft man beispielsweise den KB-Artikel KB4011715 zu Office-Updates auf, liegt dieser auf einer https-Webseite (das ist gut). Aber auf der Webseite gibt es einen direkten Download-Link.
Anzeige
Ich habe in obigem Screenshot mal den Link in das Bild kopiert. Mal festgehalten: Der Beschreibungstext wird per https von der Webseite abgerufen. Der Download erfolgt aber ungesichert über das http-Protokoll. Ein Man-in-the-middle könnte also das Update manipulieren. Um sicher zu gehen, dass der Download unmanipuliert ist, müsste man diesen im Anschluss überprüfen. Das ist das, was Stefan Kanthak in seiner Mail andeutet.
Beitrag in seclist.org
Stefan Kanthak hat das Thema bei seclists.org als Defense in depth — the Microsoft way (part 52): HTTP used to distribute (security) updates, not HTTPS eingestellt (danke an Blog-Leser Leon, dem das auch aufgefallen war, für den zusätzlichen Hinweis). Hier der Auszug:
yesterdays "Security update deployment information: February 13, 2018" <https://support.microsoft.com/en-us/help/20180213> links the following MSKB articles for the security updates of Microsoft's Office products:
<https://support.microsoft.com/kb/4011715> <https://support.microsoft.com/kb/4011200> <https://support.microsoft.com/kb/3114874> <https://support.microsoft.com/kb/4011707> <https://support.microsoft.com/kb/4011711> <https://support.microsoft.com/kb/4011690> <https://support.microsoft.com/kb/4011697> <https://support.microsoft.com/kb/4011701> <https://support.microsoft.com/kb/3172459> <https://support.microsoft.com/kb/4011143> <https://support.microsoft.com/kb/4011686> <https://support.microsoft.com/kb/4011682> <https://support.microsoft.com/kb/4011680>
Alternatively use yesterdays "February 2018 updates for Microsoft Office" <https://support.microsoft.com/en-us/help/4077965> and all the MSKB articles linked there, which are a superset of those named above.
Each of these MSKB articles in turn contains one or two links to the download pages for the updates, which except 2 (of 22) are of the form <http://www.microsoft.com/downloads/details.aspx?familyid=GUID> (despite the HTTPS: used for the MSKB articles), ie. they use HTTP instead of HTTPS, inviting to MitM attacks, ALTHOUGH the server www.microsoft.com supports HTTPS and even redirects these requests to <https://www.microsoft.com/downloads/details.aspx?familyid=GUID>!
JFTR: this bad habit is of course present in ALMOST ALL MSKB articles for previous security updates for Microsoft's Office products too … and Microsoft does NOT CARE A B^HSHIT about it!
Microsoft also links all the MSKB articles for their Windows security updates, for example <https://support.microsoft.com/kb/4074595>, in their "Security update deployment information: <month> <day>, <year>".
Allmost all of these MSKB articles as well as those for Microsoft's Office products (see above) in turn contain a link to Microsoft's "Update Catalog", which ALL are of the form
<http://catalog.update.microsoft.com/v7/site/search.aspx?q=4074595>
(despite the HTTPS: used for the MSKB articles), ie. they use HTTP instead of HTTPS, inviting to MitM attacks, ALTHOUGH the server catalog.update.microsoft.com [*] supports HTTPS!
JFTR: even if you browse the "Microsoft Update Catalog" via <https://www.catalog.update.microsoft.com/Home.aspx> [#], ALL download links published there use HTTP, not HTTPS!
That's trustworthy computing … the Microsoft way! Despite numerous mails sent to <secure () microsoft com> in the last years, and numerous replies "we'll forward this to the product groups", nothing happens at all.
Also in kurz: Microsoft kann https, mixt auf seinen Webseiten aber fleißig http-Downloads ins Angebot. Selbst wenn man den Microsoft Update Catalog aufruft, wird der Download per http-Protokoll bereitgestellt. Ich habe es gerade überprüft, weil ich es kaum glauben konnte. Aber mir wurde gerade die Adresse http: // download.windowsupdate[.]com/ angeboten. Stefan schreibt, dass er Microsoft häufiger auf das Problem hingewiesen habe, aber nix ist passiert.
Microsoft Update Catalog kaputt
Wer versucht, die (alte) Adresse https://catalog.update.microsoft.com/ aufzurufen, erhält im Browser die folgende Anzeige.
Die Links werden teilweise noch auf Microsofts Webseiten angegeben. Das Ganze wurde die Tage hier bemängelt. Ich hatte das Thema vor einiger Zeit im Blog-Beitrag Probleme mit dem Microsoft Update Catalog angesprochen. Vor einiger Zeit fand noch eine automatische Umleitung statt, die aber nicht immer funktionierte. Aktuell scheint die Weiterleitung ausgefallen zu sein. Klaus Pit hat es im Kommentar angerissen:
Microsoft bedient uns mit zweierlei Links:
Aus dem Security TechCenter läuft der veraltete
https://catalog.update.microsoft.com/v7/site/Search.aspx?q=KB4074598
mit "/v7/site/ im Link, der zum Seitenfehler führt.Korrekt:
https://www.catalog.update.microsoft.com/Search.aspx?q=KB4074598
Man muss also die https://www.catalog.update.microsoft.com/Home.aspx Variante verwenden, um eine Anzeige zu bekommen. Falls also die obige Anzeige erscheint, ergänzt einfach das www vor catalog – dann wird zumindest die Seite des Microsoft Update Catalog (aber mit einem Fehler, dass der Link nicht korrekt ist) angezeigt. Vielleicht hilft es euch weiter.
PS: Für mich würde es bedeuteten, dass ich alle fehlerhaften MS-URLs in den Blog-Beiträgen umsetzen müsste. Ob ich das leisten kann, weiß ich noch nicht. Das Ganze ist Thema 'Information durch Microsoft' ist momentan ziemlich kaputt. KB-Artikel, die veraltet sind, falsche oder unvollständige Informationen – mir sieht es so aus, als ob die Entlassungen der letzten Jahre nun (negative) Früchte tragen.
Anzeige
auch unser WSUS (Server 2016) lädt Updates von Microsoft per HTTP runter. Intern kann man dem WSUS und die Clients auf HTTPS konfigurieren um ein Man-in-the-middle in der Firma zu verhindern, aber die Updates könnten schon verändert am WSUS ankommen.
Die Pakete sind doch signiert….
Worauf soll man nicht alles achten? – Stimmt, ich habe die msu-Pakte (SecurityOnly & IE) für diesen Patchday via http bezogen. Warum? Weil ich vor längerer Zeit die Ergebnisseite eines Suchstrings im Update-Catalog als Lesezeichen abgespeichert habe. Gut, weil man dann nichts mehr eingeben und suchen muss: Man klickt das Lesezeichen an und hat Zugriff auf die aktuellen Updates. Schlecht, weil das Lesezeichen eine http-Verbindung aufruft und die Downloads dann tatsächlich via http kommen. Ist mir nicht aufgefallen.
Beide msu-Pakte des Februar-Patchdays erneut heruntergeladen, diesmal via https, und anschließend mit den http-Downloads verglichen: Die Prüfsummen sind identisch und entsprechen denen, die Microsoft für die msu-Pakte veröffentlicht hat. Außerdem die http-Downloads bei Virustotal überprüfen lassen: Ohne Befund. Wenn http-Downloads eine Sicherheitslücke im Update-System sind, ausgenutzt wurde die Sicherheitslücke in meinem Fall aktuell nicht.
AUTSCH!
Die 40 Hexadezimalzeichen am Ende des Dateinamens sind die SHA1-Prüfsumme: die auf Deinem System ermittelte muss mit der übereinstimmen, die im über HTTPS angesurften Microsoft Update Catalog angezeigt wird (es sei denn, Dein Browser ist infiziert und belügt Dich). Ebenfalls übereinstimmen muss die Authenticode-Signatur (die verwendet SHA256, für das noch kein Preimage-Angriff existiert).
Nochmaliges Herunterladen und gar "prüfen" mit den Virenrateprogrammen von Virustotal ist völlig überflüssig.
Ich kann es wirklich nur immer wieder wiederholen:
Liebe MS-Devs, schaut euch doch mal endlich das Update-Management von Linux an.
Und beendet eure Frickel-Updates endlich! Wenn "Ihr" schon das QA gestrichen habt (stattdessen insider u.ä.), dann wenigstens auf bewährtes wie "apt" zugreifen!!
Wird schlecht funktionieren, da Windows NICHT modular aufgebaut ist…
Alles ist so miteinander verschachtelt, dass die monatlichen Updates größer sind als manch komplette Linux-Distribution inklusive umfangreicher Software.
Mal gucken, ob MS das mit der nächsten Idee Windows Core hin bekommt… eher nicht.
Blödsinn!
Windows Update selbst ist keinen Deut (un)sicherer als irgendein *x-Gefrickel!
Wenn bei letzterem ein Paket auf der Leitung verfälscht wird, dann verwirft es der Paketmanager, und versucht ggf., es von einem anderen Server/Repository zu holen.
Wenn bei ersterem ein Paket auf der Leitung verfälscht wird, dann verwirft es Windows Update; beim nächsten Lauf versucht es Windows Update erneut, und kann dabei an einen anderen Server des CDN geraten, und Alles ist gut.
Schlimm wird's erst, wenn ein hyperaktiver Administrator das fehlgeschlagene Update aus dem Microsoft Update Katalog^WRepository holt … und ihm dabei statt eines .msu oder .cab^W^W^W.rpm oder .deb irgendwas Ausführbares untergeschoben wird, er die Fälschung nicht bemerkt und den Schädling ausführt.
Dank HTTP ist das Unterschieben beim Microsoft Update Katalog etwas einfacher.
Nur mal in den Wind gesprochen:
HTTPS-Seiten mit nachladbaren HTTP-Subdomains, ergibt für jeden Besucher
ein uniquer Fingerprint.
Ich biete Dir Updates und bekomme von Dir Informationen. ;)
Im Edge-Browser ist das kein Problem bei der Eingabe von: https://www.catalog.update.microsoft.com , der vervollständigt automatisch auf: https://www.catalog.update.microsoft.com/Home.aspx .
Der "IE" vervollständigt automatisch auf: https://catalog.update.microsoft.com/v7/site/Install.aspx . Beim zweiten Versuch hat auch der "IE" auf: https://www.catalog.update.microsoft.com/Home.aspx Vervollständigt
Der "Firefox" vervollständigt automatisch auch auf: https://www.catalog.update.microsoft.com/Home.aspx
Warum der "Chrom" das nicht kann oder nicht will weis keiner.
Ich habe es gerade noch im FF mit https://catalog.update.microsoft.com/v7/site/Install.aspx probiert. Ergebnis:
Diese Verbindung ist nicht sicher
Die Website versuchte, ein inakzeptables Verbindungssicherheitsniveau auszuhandeln.
catalog.update.microsoft.com verwendet Sicherheitstechnologie, welche veraltet und verwundbar ist. Ein Angreifer könnte leicht Informationen entschlüsseln, welche Sie für sicher hielten. Der Website-Administrator muss dieses Problem auf dem Server beheben, bevor Sie die Seite aufrufen können.
Fehlercode: NS_ERROR_NET_INADEQUATE_SECURITY
Imho ist da was bei den Servern fehlkonfiguriert. Früher (Dez. 2017) klappte die Umleitung auch in diesem Browsern.
Bei diesem Link musste früher im "IE"doch ein Plug-in installiert sein oder?
Der "IE" zeigt jetzt den Katalog ohne Eingabefeld mit dieser Adresse an: https://catalog.update.microsoft.com/v7/site/Install.aspx
Da kann der "FF" natürlich nicht mit umgehen oder umstellen, ist wohl die Seite auf der die Installation des Plug-in für den "IE" angeboten wurde.
Nimmt man diesen: https://www.catalog.update.microsoft.com/Home.aspx
geht's auch im "FF".
Welchen Teil von Feuerfuxens "Fehlercode: NS_ERROR_NET_INADEQUATE_SECURITY" oder von Chromes"ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY" willst Du partout nicht kapieren?
Wie wär's mit Lesen von
https://www.ssllabs.com/ssltest/analyze.html?d=catalog.update.microsoft.com
Die ActiveX-Geschichte sollte eigentlich entfallen sein, da der Update Catalog in allen Browsern funktionieren sollte. Wie bereits geschrieben – ich erinnere mich, dass es vor einigen Wochen noch funktionierte.
Die ActiveX Geschichte ist weiterhin aktiv, wenn man den IE nutzt. Und dein Link mit "v7" ist genau der Link zur ActiveX Seite. Die kann in Chrome nicht laufen.
Wenn man direkt über https://catalog.update.microsoft.com/ zugreift, klappts mit allen Browsern und man landet automatisch auf der jeweils passenden Seite.
Du rufst also nur einen nicht mehr funktionierenden Deep-Link auf.
@Ingo: 'Wenn man direkt über https://catalog.update.microsoft.com/ zugreift, klappts mit allen Browsern und man landet automatisch auf der jeweils passenden Seite.'
Gerade nochmals im Google Chrome überprüft – genau das passiert aktuell bei mir leider nicht.
Das HTTPS Handshake der Browser mit dem zu verbindenden Servern erfolgt gegebenen Falls mittels TLS 1.0, TLS 1.1 TLS 1.2 (TLS 1.3 naht).
Das Entscheidende ist eine korrekte Konfiguration der "Server" damit die aktuell sicherste Version auch verwendet wird. Leider scheitert das ganze Thema oftmals an Unwissenheit oder "Ignoranz" der Server-Administratoren!
Im Ideal-Fall sind auf dem Server alle Varianten verfügbar. Bei falscher Konfiguration funktioniert der Handshake auf das sicherste, neueste TLS aber nicht. Oder die neueren Versionen sind auf dem Server noch nicht eingepflegt.
Teilweise wird nur das als unsicher geltende TLS 1.0 verwendet.
Wer als Benutzer immer die sicherste Version beim Browsen mit HTTPS erwarten will, sollte die älteren Versionen(als unsicher geltenden) im Browser deaktivieren. Man muss sich dann aber auch bewusst sein wenn eine Seite nicht funktioniert – woran es liegt und die Alten kurz wieder einschalten!
Im IE lassen sich, als Beispiel, die Versionen SSL, TLS1.0, TLS1.1 in der "erweiterten Konfiguration" deaktivieren.
Es geht darum das, während des HTTPS Handshake, keine "Man-in-the-Middle" Angriffe initiiert werden können. Das ist mit TLS 1.0 möglich.
———————————————————————
Als negatives Beispiel zeige ich da einmal "T-Online Freemail" auf!
Bei der "Webmail-Anmeldung" sind 3 Server involviert. Der zweite erwartet aber nur TLS1.0 und das während der Passwort-Übergabe.
Die T-Online Administration ignoriert es seit einem Jahr, trotz wiederholten Hinweis auf diesen Zustand. Das sieht für mich nach Vorsatz aus, um einen Nutzen aus diesem Zustand, für wen auch immer, bereit zu stellen.
Wenn man oben zitierten Link zum Artikel "KB4011715" zB. mit dem "Firefox" aufruft und dann mit der Maus über den Link geht wird diese Seite angezeigt: http://www.microsoft.com/downloads/details.aspx?familyid=22136692-a729-4512-8c12-7d11a786a0ce .
Dann aber den Link zu dem Download anklickt wird man zu dieser Seite geleitet: https://www.microsoft.com/downloads/details.aspx?familyid=22136692-a729-4512-8c12-7d11a786a0ce .
Wird in "https://" umgewandelt.
Hab ich grad mal ausprobiert.
Stimmt, im Moment funktioniert die Umleitung. Beim Update Catalog scheint der Download aber ohne https zu laufen – dummerweise zeigen die Browser das nicht an.
Ich habe hier permanent TCPView(Sysinternals Tool) laufen – damit kann man schnell sehen ob etwas über Port 80/http oder Port 443/https läuft – klein und nützlich.
https : // technet . microsoft . com / de-de / sysinternals / bb897437
Zu dumm, dass mit Anklicken des unsicheren Links ein Mittelsmann beliebigen Mist zurückschicken und den Browser auf jede beliebige Seite entführen kann!
Nur mal so eine dumme Frage. Müsste nicht jedes Updatepaket entsprechend digital signiert sein? Und es damit ziemlich schwierig, dem Updateservice ein Update unterzuschieben?
Durch die Übermittlungsoptimierung des Windows-Updates können doch sogar Downloads von anderen PCs zugelassen werden. Damit muss doch die Integrität des Updatepaketes ohnehin am Ziel, nicht an der Quelle, sichergestellt werden.
Das ist bei Linux vom Verfahren doch auch nicht anders. Dort kann man in der Regel die Updates von vielen verschiedenen Mirrorservern herunterladen. Ob ein solcher Mirror vertrauenswürdig ist, ist im aktuellen Moment auch nicht sichergestellt. Die Prüfung muss in dem Moment erfolgen, in dem das Update installiert werden soll.
Insoweit vermute ich, dass hier die Bedeutung der verschlüsselten Datenübertragung per HTTPS ein wenig überbewertet wird. Die HTTPS-Verbindung sichert die Verbidung an sich, sagt aber eigentlich nichts über die Vertrauenswürdigkeit der übertragenen Daten aus. Man wiegt z. B. die Anwender immer in falscher Sicherheit, da diese dann glauben, das mit der Anzeige des HTTPS in der Browser-Adresszeile nun alles ok sei. Aber am anderen Ende kann dann immer noch ein Fakeshop oder eine Fake-Bankenseite sein. Oder ein verbogener DNS-Eintrag, der einen auf eine falsche Microsoft-Update-Seite führt.
Der Gedanke ging mir auch durch den Kopf – und man kann das alles ja überprüfen. Aber: Theoretisch könnte man, wenn die Leute auf Download-Links klicken und eine http-Übertragung anstoßen, beliebige Dateien übermitteln. Viele würde dann diese ausführen und könnte so ausgetrickst werden.
Da hast Du natürlich recht. Insoweit ist es vielleicht wirklich am Besten, die Updates tatsächlich über den Updateservice (oder WSUS) ausführen zu lassen, da dieser dann gleich die Digitale Signatur prüft und ggfs. den Vorgang mit einem Fehlercode abbricht. Den Download der Updatepakete sollte man dann erst einmal nur dann machen, wenn es wirklich gute Gründe dafür gibt. Denn wirklich schützen kann einen die HTTPS-Verbindung nicht. Denn diese baut eine geschützte Verbindung zu der IP-Adresse auf, die über DNS aufgelöst wird. Und diese lässt sich manipulieren, sicher nicht im einzelnen privaten Bereich, aber im speziellen Fall auf jeden Fall.
Was alles nichts daran ändert, dass Microsoft seine Hauscleaning-Arbeiten machen muss.
Übrigens: Auch der Offline WSUS (http://wsusoffline.net) lädt alle Windows-Updates über http. Man könnte aber vermutlich die Skripte, die er dafür nutzt, auf https anpassen.
Das mit dem Fake wäre schon grundsätzlich möglich.
Deshalb gab es ja Ansätze zum Zertifikat-Pinning. Was allerdings jetzt aufgrund von Problemen und Aufwand nicht mehr als praktikabel angesehen wird.
Ich verwende schon lange Zeit Microsoft EMET 5.2 unter Windows 7. Dort kann ich das Zertifikat-Pinning für HTTPS-Seiten und dem IE konfigurieren, auf denen ich mich anmelde oder sensitive Daten übertrage. Banking oder ähnliches – und den Microsoft Update-Catalog. Stimmt das Zertifikat nicht mit der URL Originalseite zusammen oder ist zeitlich abgelaufen – meldet EMET und untersagt das Laden der Seite. Zugegeben – die Konfiguration überfordert einen normalen Benutzer.
Außerdem härte ich damit sämtliche Programme die auf das Internet zugreifen, wie Update-Module und Sonstiges gegen weitere EMET bekannte Exploit-Gefahren für Windows. Im Rahmen der jeweiligen Programm-Kompatibilität.
Man ist zusätzlich gut damit beraten, soweit möglich, die gemischte Anzeige von HTTPS mit HTTP im "Browser" zu deaktivieren – sowie die Anzeige von ungesicherten Bildern/Videos innerhalb einer HTTPS-Seite.
Installationspakete sowohl für richtiges SVR4-UNIX, also .pkg, neumodisches Zeux wie Linux oder Android etc., also .rpm, .deb, .apk etc., angebissene Äpfel, also .dmg, oder Windows, also .msu und .cab, werden von den jeweiligen Paketmanagern auf Integrität geprüft.
Auch der unter Windows im Hintergrund werkelnde "Windows Update Agent" prüft die heruntergeladenen Dateien gegen die über einen sicheren Kanal erhaltenen Metadaten.
Dummerweise beglückt eine kleine Klitsche aus Redmond ihre nicht Böses argwöhnenden "Kunden" aber auch mit ausführbaren Installationsdateien … die von Lemmingen ohne Windows Update (in seiner Rolle als Paketmanager) heruntergeladen und bereitwillig per Doppelklick gestartet werden.
Welcher Lemming prüft .exe vor dem Doppelklick?
.exe gleichgestellt sind auch .msi sowie .msp: alle können nach dem Doppelklick und ggf. einem "Ja, ich will" zum Ruhigstellen der störenden Benutzerkontensteuerung beliebige Aktionen mit Administratorrechten ausführen, ohne Integritätsprüfung.
Dazu dann mal eine Möglichkeit wie man es manuell schnell einsehen kann:
"7-Zip" installieren(Windows):
http : / / www . 7-zip . org /
– unter Extras / Optionen/ Einstellungen
– Option "System-Kontextmenü im Dateimenü anzeigen" aktivieren.
und
unter Extras / Optionen/ 7-Zip
– Option / -Zip im Kontextmenü integrieren
Dann hat man im Kontextmenü(rechte Maustaste auf Datei) im Windows-Explorer die Auswahl-Option "CRC SHA"
Die Download-Dateien aus dem Microsoft "Update-Katalog" enthalten eine "SHA-1" Prüfsumme "im Dateinamen"!
Beispiel:
AMD64-all-windows6.1-kb4019990-x64_35cc310e81ef23439ba0ec1f11d7b71dd34adfe5.msu
"35cc310e81ef23439ba0ec1f11d7b71dd34adfe5" ist für diese Datei die "SHA-1" Prüfsumme.
7-Zip zeigt den Dateinamen und darunter die "gewählte" SHA Prüfsumme der Datei in einen Fenster an. Diese "müssen" übereinstimmen um eine Manipulation der Original-Datei auszuschließen. (Auf dem Server oder dem Übertragungsweg)
——————————————————————-
Das sollte man heutzutage für jede ausführbare Datei tun. Auf den original Seiten der Programmanbieter findet man meist einen Link auf eine Textdatei mit den Prüfsummen zu den jeweiligen Downloads – oder ähnlich…
Mit kaputtem und unsicherem Zeux wie 7-zip kann man nichts Sinnvolles machen … ausser DEINSTALLIEREN und vergessen!
Lemminge kapieren das wohl nie!
https://support.microsoft.com/en-us/kb/913111
Nicht immer nur meckern, auch mal was sinnvolles beitragen…
Ich schreibe da noch was zu – Ergänzung: Einfach den Artikel Warnung: Auf 7-Zip verzichten lesen.
Es gibt Programm-Pakete die 7-Zip als zusätzliches Tool verwenden. Beispielsweise im Verlauf der Produktaktualisierung(automatisches Update).
Auch wenn das aktuellste Z-Zip installiert ist, besteht die Gefahr das veraltete Versionen dieses Tools, in den Programmverzeichnissen des Rechners, vorhanden sind.
Die Standalone-Console "7za.exe" sollte dann mittels des aktuellen Update-Paketes auch in diesen Programmverzeichnissen ersetzt werden. Eigentlich Aufgabe der Programm-Pakete Vertreiber – aber die sind meist ahnungslos oder ignorant.
http : / / www . 7-zip . org / a / 7z1801-extra.7z
(Aktuell 2018-02)
"7za.exe" beispielsweise im Windows-Explorer an den "Orten installierter Programme" suchen und alle veralteten Versionen durch die derzeit verfügbare Version ersetzen.
Das ist leider keine Endgültige Maßnahme!
Die Programm-Pakete installieren immer wieder ältere Versionen des "7za.exe", bei einen Programm-Update, in ihren Verzeichnissen – bis sie das Sicherheits-Problem möglicherweise auch registrieren.
Welchen Teil von "7-zip ist übelster Schrott, sein Autor ein merkbefreiter Trottel, der die von Microsofts Entwicklungswerkzeugen seit 15 Jahren bereitgestellten Abwehrmassnahmen nicht nutzt" willst Du nicht kapieren?
Apropos ignorant: seit mindestens Vista
kennt Windows "CERTUTIL.exe /HashFile datei"
Die interessante Frage ist eigentlich nur, ob Windows bei der Installation von Updates die digitalen Signaturen vorher prüft und im Fehlerfall die Installation des Updates ablehnt. Und das auch, wenn die Signatur zwar gültig, aber gar nicht von Microsoft selber ist. Die Leute laden schließlich alle möglichen "Update Pakete" bei Drittanbietern herunter. Müsste man eigentlich mal ausprobieren, ob ein Paket nach einer kleinen Manipulation von ein paar Bytes per Editor immer noch sauber installiert.
Was nicht heißen soll, dass Microsoft an den Stellen nicht durchweg auf https setzen sollte. An sich sollte das eine Selbstverständlichkeit sein.
Und ich habs mal spontan geprüft. Die erschreckende Antwort: ja, leider installiert Windows problemlos Update Pakete, deren Inhalt verändert wurde.
Zum Nachvollziehen: ich habe mir KB4074595 heruntergeladen. Dann per Notepad++ am Dateiende geschaut. Dort kann man die Texte der Zertifikate im Klartext zwischen den Daten lesen. Einfach ein paar Mal einzelne Buchstaben im Text ersetzt, gespeichert.
Schaut man jetzt in die Eigenschaften der Datei unter "Digitale Signaturen", wird die Datei als "möglicherweise geändert" angezeigt. Das SHA256 Zertifikat hab ich sogar komplett kaputt gemacht mit meinen Edits.
Ich konnte dieses Paket danach problemlos installieren.
Und ja: DAS ist peinlich!
Danke für den Test. Bin momentan mal wieder geerdet, da mir eben in WordPress ein aktualisiertes Plugin um die Ohren geflogen ist. Da muss jetzt erst einmal basteln, um das in 5 Blogs mit einem alternative Plugin hinzubiegen.
Ergänzung 1: Es scheint wohl nicht egal, wo und was man ändert. Ich vermute, dass die .cab-Dateien im Paket gesichert sind und einen Fehler auslösen. Darauf deutet auch der Kommentar bei Askwoody hin.
Ergänzung 2: Bei Askwoody gibt es einen zweiten Post mit Links zu Artikeln, die das Thema Sicherheit von Updates thematisieren.
@Herr Born,
ihr Freund Woody Leonhard, sollte interessehalber mal einen Blick auf " HSTS (HTTP Strict Transport Security)" werfen.
Das HTTPS und HTTP Prozedere ist ein interessantes
Thema
Da werfe ich gleich ein weiteres wichtiges Thema hinterher – "Secure DNS".
Verschlüsselte DNS anfragen – auch die derzeit normalen, haufenweisen DNS Anfragen der Clients im Internet bringen die Gefahr der (man-in-the-middle) Angriffe mit.
haette ich in meinen wildesten traeumen nicht gedacht.
danke fuer die info.
Was soll "installiert Windows" bedeuten?
Dass WUSA.exe beim Doppelklick auf eine veränderte .MSU aufgerufen wird, den Inhalt der .MSU (das sind stinknormale .CAB, sie haben nur eine andere Endung) auspackt, obwohl die Signatur nicht stimmt?
Dass das von WUSA.exe aufgerufene"component based servicing" die unveränderte und weiterhin korrekt signierte ausgepackte Nutzlast, d.h. das eigentliche Update, klaglos verifiziert und installiert?
Ja, WUSA.exe sollte die Signatur prüfen, aber mit dieser harmlosen Änderung der Verpackung bleibt die Nutzlast weiterhin gültig!
Mach' die Gegenprobe: lass' dieses Update über Windows Update installieren, und modifiziere es auf der Leitung (da der Windows Update Agent die Dateien selbst per HTTP übertragen lässt geht das mit einem einfachen Proxy).
Installiert Windows Update das modifizierte Update?
NEIN!
Windows Update verwirft es, ohne es an CBS (bzw. MSIExec oder SetupAPI) zu übergeben.
Wenn ich mir http://wu.krelay.de/monthly.htm so ansehe …
https://support.microsoft.com/en-us/kb/4074587
http://www.catalog.update.microsoft.com/Search.aspx?q=KB4074587+x64
http://www.catalog.update.microsoft.com/Search.aspx?q=KB4074587+x86
Monat für Monat bis 2016 retour sieht das so aus, hmh.
Zum Browser-Problem – wenn ich es richtig interpretiere (ist so nicht meine originäre Baustelle), sind die Microsoft-Server nicht richtig konfiguriert. Je nachdem welche URL man zum Zugriff auf den Microsoft Update Catalog verwendet, kommt es beim Handshake zu einem Fehler in der ausgehandelten TLS-Variante. Hier zwei Tests mit unterschiedlichen URLs zum Aufruf des Catalogs.
http://www.catalog.update.microsoft.com
catalog.update.microsoft.com
Beim letzten Link kommt bei bestimmten Browsern der Hinweis 'Server negotiated HTTP/2 with blacklisted suite'. Witzigerweise sind auch IE 11 und Edge unter Windows 10 dabei.
Ein paar Hinweise zum Thema blacklisted suite finden sich z.B. in diesem Beitrag.
Auszug daraus….
SSl Server Test:
https://www.ssllabs.com/ssltest/index.html
SSL Server Rating Guide:
https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide
SSL Client Test:
https://www.ssllabs.com/ssltest/viewMyClient.html
Well done, borncity…
Zum ersten Link: Da habe ich kaum Einflussmöglichkeiten meinerseits, außer das SSL-Zertifikat bereitzustellen. Offenbar haben die Jungs und Mädels von HostEurope die Sache aber gut gemacht ;-).
A ;-)
Im ersten Link ist der Server eigentlich korrekt konfiguriert.
max-age=31536000; includeSubDomains
Nach meiner Meinung fehlt aber der Parameter -preload-
Der IE 11 und Edge holt die Informationen von der Crome-Preloadliste.
max-age=31536000; includeSubDomains;preload
Der zweite Link dürfte eine Konfiguration für ältere Browser sein, die
HSTS nicht beherrschen.
https://blogs.windows.com/msedgedev/2015/06/09/http-strict-transport-security-comes-to-internet-explorer-11-on-windows-8-1-and-windows-7/#4ekEgsZqW8LPISpm.97
https://hstspreload.org/
war das in der Zwischenzeit mal anders und ist aktuell wieder so, oder ist es in diesem Status die letzten 3 Jahre geblieben? Wollte gerade vom catalog das neuste LCU vom Oktober laden und der download zog von einer http Quelle.