Strategies for Ensuring Transport Security in Fior...

gary_prewett · ‎2015 Jul 14

First of all, let’s have a few moments of silence in remembrance of SSL now that SSL is officially dead.

Long live TLS!

That said, even though a lot of SAP customers are relying on HTTPS (TLS) to ensure the confidentiality of data in motion in their Fiori applications over public networks, there are still fundamental weaknesses in even TLS that make data disclosure possible in a man in the middle attack. Consider the attack scenario in the next section.

Man in the Middle TLS Attack Scenario

The conversation in a well-behaved man in the middle conversation to your Fiori Gateway Server (with, say, your local Starbucks WiFi hotspot as the man in the middle) should look something like the following:

The well-behaved man in the middle simply routes all requests to the server, without inspecting or modifying that traffic, and routes responses from the server back to the client.

Now, an attacker seeking to inspect that traffic could simply drop the request on the floor and forge a redirect – which would look something like the following:

This has the effect of forcing future communication to the Fiori Gateway Server to the unencrypted HTTP protocol, allowing the attacker to inspect all traffic to the NetWeaver Gateway unencrypted. An attacker would have the luxury of viewing payment details and other types of confidential data in clear text.

Most supported Fiori web browsers and the Fiori client will not warn the user of the change from HTTPS to HTTP – the user would need to pay close attention to the browser's encryption "lock" icons. Some browsers (think Chrome) will issue strong warnings that alert the user to the fact that the session is being downgraded to an HTTP session, but even then many users may err on the side of “getting things done” and ignoring any warning messages.

Likelihood of this Scenario

When measuring risk, it helps to remember that Risk = Impact * Likelihood. In the past, man-in-the-middle attack scenarios were considered esoteric or difficult to pull off - a low-likelihood scenario. Today, with the ubiquity of WiFi, this is no longer the case. In fact, an attacker with limited technical knowledge can buy a $100 Pineapple device to take advantage of this particular vulnerability. Given these attacks can be pulled off by unsophisticated users with minimal investment, the likelihood of this type of man-in-the-middle attack is orders of magnitude higher than it was even 5 years ago.

Strategies for SAP Customers to Secure Data in Motion in Fiori Applications

This said, there are several approaches SAP customers can take to address this risk when rolling out Fiori to devices on public networks to address this specific risk. These include:

Blocking access to the HTTP port on your NetWeaver Gateway server at the firewall. This is possibly the cheapest alternative available to SAP customers.
Implementing HTTP Strict Transport Security. This requires some modification to standard Fiori to implement and requires browsers that support HSTS. Unfortunately, not all browsers support HSTS and so this option may not be effective in BYOD-scenarios
Requiring that remote devices access your Fiori Launchpad over VPN. VPN tunnels can’t be negotiated down to an “unencrypted” version. Currently, the only known way attackers can attack VPN connections is to forge reset packets to drop the tunnel, in the hope that a user will give up using VPN and will try a less secure option. On the negative side, VPN tunnels add to authentication complexity.
Implementing SAP Application Protection by Mocana. This is a great offering that handles a host of security issues, including the specific man-in-the-middle attack scenario discussed here. This solution was designed to run applications securely on untrusted devices, protecting data at rest and in motion. A key feature of SAP Application Protection by Mocana is VPNs initiated from the application, so that an attacker doesn’t have the opportunity to inspect unencrypted data in motion even if they have control of the device. And, Mocana-wrapped applications can take advantage of certificate-based authentication to reduce authentication complexity to both the Gateway and the Atlas VPN appliance.
SAP Customers running the Afaria MDM solution have the ability to implement policies on devices to ensure WiFi connections are only to trusted networks, or can disable WiFi altogether (controlled by the policies “Connect to Specific APs” or “Get current WiFi AP’s SSID”). Many other MDM tools have similar capabilities. Again, this is not always possible to enforce in a BYOD scenario.
Implementing HTTPS Everywhere plugins for all clients. Unfortunately, as of this writing this is not a viable option in a mobile device scenario.

Industry Initiatives to Address this Risk

There are several initiatives underway to address this scenario, all in various stages of adoption.

HTTPS Everywhere – this is a browser plugin that always attempts to connect to the web server/service via HTTPS, regardless of the link or redirect information presented.
HTTPS Transport Security Protocol (HSTS)
Deprecate HTTP altogether and encrypt all web traffic

Unfortunately given the sheer number of internet-enabled servers and clients, I don’t see any of these making significant headway to addressing this issue internet-wide in a timely manner.