Threat analysis of ‘Virtual Host Confusion’ on TLS

Abstract

As CDNs and co-located domains became more common, the threat of VHC became more evident. In this study, VHC was analysed and studied to understand the fundamental aspects that cause it. In addition, an investigation was carried out to determine what an attacker might get access to, when confusion is successful. Nginx and Apache were selected to for testing to obtain a better understanding of VHC on the most prominent web server. It was found that both web servers can be configured in a way that allows such vulnerabilities to happen. It was found that the fall-back mechanism of the HTTPS multiplexer plays an important role during all of the three confusion methods. Additionally, it is understood that multiple virtual hosts on the same IP:port, need to be on the same SSL context, but how this context ID is generated is the main reason VHC occurs when shared caches or ticket keys are involved. When VHC is exploitable, only client based data is vulnerable. XSS or SQL injection leading to JavaScript injection on a domain, can be used to steal the browser data of the confused domain, even though this data is supposedly protected by SOP. Redirections to HTTP can also be exploited to expose the arguments in the URI field for the domain being confused. This, in conjunction with how OAuth, works can become a huge vulnerability when implicit authentication takes place, as the token will be exposed in plain text. From the perspective of an incident responder, memory analysis can be used to to find out if VHC attacks have been carried out, but the volatility of the request makes for a very limited view of what is happening. The default logs, when enabled, can also provide hints as to whether or not confusion has been attempted. Network analysis was also carried out, to determine the level of information an attacker can obtain by simply analysing the data on the network. It was found that an attacker can easily determine the fall-back certificates and response for an IP:port. Additionally, using network analysis, one can determine with a high probability, that two IP:ports are sharing the same ticket key. On the other hand, no information as to whether two IP:ports are sharing the same cache can be obtained using network and packet analysis.