{"id":5003,"date":"2018-02-16T09:55:36","date_gmt":"2018-02-16T08:55:36","guid":{"rendered":"http:\/\/159.69.82.204\/win\/?p=5003"},"modified":"2019-11-03T06:59:27","modified_gmt":"2019-11-03T05:59:27","slug":"microsoft-delivers-updates-via-http-more-security-obscurity","status":"publish","type":"post","link":"https:\/\/borncity.com\/win\/2018\/02\/16\/microsoft-delivers-updates-via-http-more-security-obscurity\/","title":{"rendered":"Microsoft delivers updates via HTTP & more security obscurity"},"content":{"rendered":"

[German<\/a>]Microsoft currently fails to deliver updates in a secure way. In a Security by obscurity style, Microsoft offers update downloads via insecure http protocol. This also applies to downloads from the Microsoft Update Catalog. And Microsoft Update Catalog strikes, if it is called from the wrong URL.<\/p>\n

<\/p>\n

Update download via HTTP?<\/h2>\n

\"\"Security researcher Stefan Kanthak has informed me 2 days ago about a security issue with Microsoft's update delivery. He wrote on February 14, 2018 within a private e-mail:<\/p>\n

In your blog you unfortunately also use http: instead of https: not only for the Microsoft Update Catalog.<\/p>\n

Do you check the SHA1 checksum of downloaded updates? Authenticode signature? Do you get the updates from there via http:, if a poehsewicht should block the \"automatic updates\"? Or by https:?<\/p><\/blockquote>\n

What's the beef? Within my blog posts about Microsoft patchday updates, I include links to KB articles from the Microsoft documentation. Microsoft is still using some links to http pages. That wouldn't be to bad.<\/p>\n

\"http-Adresse<\/p>\n

But the story continues. If you visit KB4011715<\/a>, the article about an Office updates is secured via https (that's good). But on the web page, there is a direct download link for the update.<\/p>\n

\"http-Adresse<\/p>\n

I have copied the link into the above screenshot. Just for the records: The kb article is retrieved from the website delivered via https. However, the download is offered via the unsecured http protocol.<\/p>\n

[Addendum:<\/strong> Further tests, executed a few hours after initial post, shows, that a redirect to a https page has been estabilished in case of KB4011715<\/a>\u00a0(and probably for other http download links). Can't verify anymore whether this is new now. But Microsoft Update Catalog still deliver downloads via http.]<\/p><\/blockquote>\n

A man-in-the-middle could therefore manipulate the update.\u00a0To make sure that the download is not manipulated, you have to check it afterwards. That's what Stefan Kanthak suggests in his mail.<\/p>\n

Tested: Windows accepts altered updates …<\/h3>\n

Within my German blog post, a reader did a simple test<\/a>. He downloaded an update package via Microsoft Update Catalog. Then he used Notepad++ to edit some strings within the update package. The saved package is flagged 'as modified' on digital signature property page. But Windows accept this update and install it.<\/p>\n

[Addendum:<\/strong> It seems that it matters, what's changed within a .msu file. I guess, the .cab files within the update installer files are signed and causes an error, if altered – see this comment<\/a> at Askwoody. ]<\/p><\/blockquote>\n

Added to seclist.org<\/h2>\n

Stefan Kanthak has posted this topic (just before our mail exchange) at seclists.org<\/a> (Defense in depth — the Microsoft way (part 52): HTTP used to distribute (security) updates, not HTTPS<\/em>).<\/p>\n

yesterdays \"Security update deployment information: February 13, 2018\" <https:\/\/support.microsoft.com\/en-us\/help\/20180213<\/a>> links the following MSKB articles for the security updates of Microsoft's Office products:<\/p>\n

<https:\/\/support.microsoft.com\/kb\/4011715<\/a>> <https:\/\/support.microsoft.com\/kb\/4011200<\/a>> <https:\/\/support.microsoft.com\/kb\/3114874<\/a>> <https:\/\/support.microsoft.com\/kb\/4011707<\/a>> <https:\/\/support.microsoft.com\/kb\/4011711<\/a>> <https:\/\/support.microsoft.com\/kb\/4011690<\/a>> <https:\/\/support.microsoft.com\/kb\/4011697<\/a>> <https:\/\/support.microsoft.com\/kb\/4011701<\/a>> <https:\/\/support.microsoft.com\/kb\/3172459<\/a>> <https:\/\/support.microsoft.com\/kb\/4011143<\/a>> <https:\/\/support.microsoft.com\/kb\/4011686<\/a>> <https:\/\/support.microsoft.com\/kb\/4011682<\/a>> <https:\/\/support.microsoft.com\/kb\/4011680<\/a>><\/p>\n

Alternatively use yesterdays \"February 2018 updates for Microsoft Office\" <https:\/\/support.microsoft.com\/en-us\/help\/4077965<\/a>> and all the MSKB articles linked there, which are a superset of those named above.<\/p>\n

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>!<\/p>\n

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!<\/p>\n

Microsoft also links all the MSKB articles for their Windows security updates, for example <https:\/\/support.microsoft.com\/kb\/4074595<\/a>>, in their \"Security update deployment information: <month> <day>, <year>\".<\/p>\n

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<\/p>\n

<http:\/\/catalog.update.microsoft.com\/v7\/site\/search.aspx?q=4074595<\/a>><\/p>\n

(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!<\/p>\n

JFTR: even if you browse the \"Microsoft Update Catalog\" via <https:\/\/www.catalog.update.microsoft.com\/Home.aspx<\/a>> [#], ALL download links published there use HTTP, not HTTPS!<\/p>\n

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.<\/p><\/blockquote>\n

Addendum:<\/strong> At Askwoody is a post with links<\/a> pointing to articles for further reading.<\/p>\n

Microsoft Update Catalog broken<\/h2>\n

If you try to reach Microsoft's Update Catalog, using the old address https:\/\/catalog.update.microsoft.com\/<\/a> (still available in Microsoft's kb articled), you will end with the following message.<\/p>\n

\"Chrome<\/p>\n

I've had mentioned within my blog post Trouble reaching Microsoft Update Catalog<\/a>. In the past, there was a redirection, but it seems that that doesn't work at the momenent. To reach the Update Catalog, use<\/p>\n

https:\/\/www.catalog.update.microsoft.com\/Search.aspx?q=KB4074598<\/a><\/p>\n

instead of the old address:<\/p>\n

https:\/\/catalog.update.microsoft.com\/v7\/site\/Search.aspx?q=KB4074598<\/a><\/p>\n

Perhaps it's helpful for you.<\/p>\n","protected":false},"excerpt":{"rendered":"

[German]Microsoft currently fails to deliver updates in a secure way. In a Security by obscurity style, Microsoft offers update downloads via insecure http protocol. This also applies to downloads from the Microsoft Update Catalog. And Microsoft Update Catalog strikes, if … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[580,22,2],"tags":[65,69,195],"class_list":["post-5003","post","type-post","status-publish","format-standard","hentry","category-security","category-update","category-windows","tag-microsoft","tag-security","tag-update"],"_links":{"self":[{"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/posts\/5003","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/comments?post=5003"}],"version-history":[{"count":0,"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/posts\/5003\/revisions"}],"wp:attachment":[{"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/media?parent=5003"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/categories?post=5003"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/tags?post=5003"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}