############################################################################################################## / _____/____ _______ ____ __| _/ |__| \_____ \\__ \\_ __ \/ _ \ / __ | | | / \/ __ \| | \( (O) ) /_/ | | | /_______ (____ /__| \____/\____ |/\__| | \/ \/ \/\______| ############################################ Hossel die smatje ############################################### #### Subject: Office365 sslstrip attack vector #### Date: 16/10/2015 #### Author: Wesley de Ruijter ############################################################################################################## #### What did you find? Staring at my HTTP GET requests while loading the webmail.office365.com enviroment I noticed multiple JS files being loaded. I got curious and checked out what server was hosting these files. After a quick scan I found out that both port 80 and 443 are open. To make matters worse: port 80 is not automaticly redirected to port 443, meaning that content is served over port 80 (in 2015) when http is used. Oh and yeah, I also found out that the access-control-allow-origin was set to *. I reported the lack of redirect as case #1 and the misconfiguration on the acces-controll-allow-origin as #2. #### What is the impact of this find? Now we have a few misconfigurations, who cares? Well hackers do, lets look at the following scenario: When webmail.office365.com is requested, the following javascript file is loaded: https://r1.res.office365.com/owa/prem/16.925.12.1810981/scripts/microsoft.owa.options.core.models.js When sslstrip is applied the url is rewritten to http, contacting the server over http instead of https. Now, sslstrip is a MiTM attack, we can combine this with for example a ethercap filter, a quick example of a ethercap filter that could be used: if (ip.proto == TCP && tcp.src == 80) { replace("try { window.scriptsLoaded", "try { alert('hax'); window.scriptsLoaded"); msg("Javacript injected.\n"); } This is possible because the traffic runs over http, it allows us to inject certain pieces of javascript into the browser. Injecting an alert() function is harmless, but what if you start stealing sessions, remember the access-control-allow-origin? Cookie stealers can be injected. Now, wouldn't it be a big trol if you MiTM key Microsoft personal during a Microsoft conference and jack their sessions. Or what about pwning an enterprise webproxy and MiTM the traffic to steal all sessions? These are realistic scenarios. #### How did Microsoft respond? 13/10/2015: Reported to Microsoft 13/10/2015: Microsoft forwarded to analyst 15/10/2015: Microsoft requested clear instructions on how to reproduce 15/10/2015: Send clear instructions to Microsoft 16/10/2015: "Thank you for contacting the Microsoft Security Response Center (MSRC). Upon investigation we have determined that these do not meet the bar. When you go to OWA in O365 https://outlook.office.com/owa it loads bunch of script files and the one pointed out can be loaded over HTTP. Normally all scripts are loaded over HTTPS, so in order to do something with this the attacker would first have to be able to get OWA load it over HTTP. This is technically feasible, whoever, it would require hacking the heck out of the network so it doesn't meet the bar. For #2, same thing. By it self it is not really harmful. Please let me know if you feel we have misinterpreted your report! For an in-depth discussion of what constitutes a product vulnerability please see the following: "Definition of a Security Vulnerability" Again, we appreciate your report." #### Why do you make it public? Because 1988 called, they want their misconfiguration back. This needs to be fixed and Microsoft is not taking this serious enough. ##############################################################################################################