The Internet is all about Trust
Posted by Clint Davis | 7 May
Authoritative Data and Desktop Application Interception
Recently I was asked why we built an online platform instead of a desktop application to collect financial data for our customers.
The answer like all answers is both simple and complex. Simply put my response was ‘defensive programming‘, abiding by the golden rule ‘never trust the user space‘. The code that runs within in the user space or user environment is directly vulnerable to modification and interception. The user owns and controls the device, they have full access and control to modify and tinker with the code. Think of software that requires CD-Keys and how easily hackers can overcome these controls and pirate software. Even a novice user can jailbrake an iPhone, a proprietary platform and operating system in under 10 minutes. This user space can never be trusted for authoritative data to be transmitted through.
For the complex answer continue reading…
One of the most important design elements in an application development is to never trust the user space. The HTTPS protocol is not only about encryption it’s also about trust.
The encryption part of the protocol will allow secure transmissions between endpoints, these transmissions are unreadable to those who would be ‘sniffing’ the traffic passing between these endpoints. This is beneficial because I don’t want everyone on a public WiFi network to be able to see my usernames and passwords for sites where private and secure data exists.
The trust aspect comes from an inherent requirement for controlling this encryption, if anyone could create SSL certificates then interception is still possible.
Question: How do I know the SSL certificate presented when I visit a site is actually owned by the company and not by the interceptor pretending to be them?
Answer: Certificate Authorities (CA) are the only companies trusted by the operating system to issue certificates. If the CA says its valid, then the operating system accept the certificate.
The list of what companies are valid root Certificate Authorities is held on the device itself, its part of the operating system and because users have complete control of their devices, they also have control over what root CA’s are installed on their device.
Adding a self-signed (self created) certificate for a specific site and having your browser trust that certificate is very trivial, in reality it takes just a few seconds with the likes of software from Fidder 2, Burp Proxy or Charles Proxy.
Proxy software software allows the user to add a valid root certificate and begin intercepting encrypted traffic. The user has the ability to step through Internet requests allowing users to modify the data before it hits the underlying the application. The application never knows the data it received was modified during the request. This is a typical Man in the middle attack scenario.
While there are ways to mitigate this type of risk, mitigation is like ‘upgrading your fence from a picket fence to a wooden fence, yet still leaving your front door wide open when you go out.‘ The problem will still exist mitigation only increases the difficulty of attack. Simply put the software breaks the golden rule being broken, never trust the user space.
SSL Pinning (Mitigation)
In the industry, SSL Pinning is a design concept to save a copy of the sites SSL certificate within the published application. A check to confirm do the certificates match, and have not been replaced by an attempt to intercept the traffic.
This is a good attempt to strengthen the fence, but never fixes the problem. By jailbraking or rooting a device and modifying the app binary allows for creating a bypass to this security mechanism (see iSEC Partners presentation at blackhat USA 2012). iSEC Partners show that while the complexity is increased against your causal interceptor, it’s not a good enough defence against removing fraud and providing authoritative data.
It’s clear that on any platform; Windows, Mac, Andriod, iOS, Windows Phone. These methods are still available to intercept and modify information transmitted through a client application. The rule still applies no matter the technique to overcome the problem. “never trust the user space”. When designing data application flows, architects should make the design decisions to avoid routing sensitive data through the Client endpoint thereby negating the ability for interception.
Incredo follows a 100% authoritative data transmission model. Critical banking information is never exposed for interception by the user space as it’s never passed back through the customers device. Instead we collect banking data from the financial institutions website, generate our report and send that data directly to our Client’s servers.