Es gibt mehrere Gründe, wieso Microsoft, sich bis letzten Sommer, überhaupt nicht um diese CVE geschert hatte…weil es nämlich eigentlich nicht nötig ist! In den 14 Jahren der bekannten MD5-Kollisionen, wurde:
- kaum versucht diese Kollisionen auszunutzen
- da, wo es versucht wurde, kamen aber kaum nennenswerte Zugriffe zu Stande
Seitdem MS der RFC6151 bekannt ist, wurde eigentlich bis dato immer mit zwei unabhängig voneinander laufenden Zertifikaten pro z.B. einer Webanwendung gearbeitet. Man benutzte ein Maschinenzertifikat und ein Userzertifikat parallel.
Somit läuft die Wahrscheinlichkeit, dass beide Zertis zur „cached Collision“ gebracht werden, fast gegen Null…
Gehen wir nun von dem Theoriebeispiel hier aus, mit nur einem Zertifikat, und man schafft es tatsächlich, die MD5-Kollision auszulösen und hat danach ein good und ein bad Zertifikat. Dann fangen nämlich erst die großen Probleme an, beginnend bei der Zustellung des bad ass !!
Es blieb damals nicht viel übrig, außer, dass man für die Zustellung Chrome v48 nutzen musste. Und um die CVE ausnutzen zu können, musste das besagte Zertifikat in den Cache des besagten Chrome v48 einzufügen.
Dies war nicht nur schwierig, sondern fast aussichtslos, da es unmöglich ist, ein Zertifikat zuzustellen, ohne seinen privaten Schlüssel zu kennen.
Dieser Schlüssel musste also ERSTMAL durch einen Evil Proxy (MiTM) herausgefunden werden, ansonsten konnte man die komplette Aktion an dieser Stelle abbrechen!!
Das generierte Zertifikat wird dann von Windows ohne Probleme als gültig akzeptiert. Bei dieser Methode handelt es sich um ein extrem mächtiges Werkzeug für MITM Angriffe, vor denen beispielsweise ein VPN euch schützen kann. (Quelle : TK-Artikel)
Diese Aussagen aus dem Artikel sind also faktisch falsch, da das Zertifikat, wie oben beschrieben, überhaupt nicht problemlos untergeschoben werden kann 
Deine genannte Methode ist auch nicht der eigentliche MiTM-Angriff als Ergebnis der Bemühungen! Wie gesagt, wird der Proxy genutzt, um an die nicht vorhandenen privaten Schlüssel zu gelangen (ohne Keys auch KEINE Zustellung des gefälschten Zertifikats!!)
Wenn man sich alle diese Problematiken PLUS der internen Sache, mit zwei unabhängigen Zertis zu arbeiten mal vor Augen führt, verstehrt man ruckizucki, wieso genau diese CVE Microsoft eigentlich immer schon am Poppes vorbei geht…
Nachtrag:
Was ebenfalls noch erschwerend hinzu kommt → BEVOR es überhaupt zu dem Szenario kommen kann, müsste die Webanwendung (what ever) erstmal per VPN (bei über 98% der fälle) ins Firmennetz gelangen können und AUCH noch an der vorgeschalteten Firewall-Appliance mit eigenem (funktionierenden) Zertifikatssystem, „vorbeihuschen“!! EHER NÖÖÖÖ!!