Remote access has a venerable history. According to that infallible source Wikipedia, the Telnet protocol was first developed in 1969. Twenty years later, Citrix was founded to provide remote access solutions for Windows platforms. Today’s options include RDP, PCoIP, VNC, SSH, XWindows (OK, not really – but NX counts!) and others.
Some uses of remote access are all about convenience. VDI promises a reduction in management costs. High Performance Computing environments use remote access because it’s impractical to put a supercomputer on every desktop.
Remote access as a security tool
But in other cases, remote access is used as a security tool. We don’t want people working with sensitive data on their insecure home PCs – but we use remote access to allow them to use their home PC to remotely control a more secure computer where they can work with that sensitive data.
Home working is a well-known use case. But there are others. For example, organisations that have critical operational systems sometimes isolate these from their main corporate network – they might be able to afford a compromise of their corporate systems but they can’t afford a compromise of their operational systems. And when employees – administrators, usually – need access to the operational systems, they use remote access. Often, they call the remote access platform that provides this a “jump box”.
It’s a great idea. Don’t worry about the security of the end user’s machine – just use remote access to let them drive a system where the security is much more easily controlled.
But how well does the idea stand up to scrutiny?
The vulnerability in remote access
The challenge with remote access is that in principle, if an attacker manages to take control of the end user’s machine (using their own covert and malicious form of remote access) then they can do anything that the user can do.
They can certainly read any confidential information that is available on the secure system. And beyond reading it, they can scrape it and use OCR to recover the raw information.
What about the other way round – rather than stealing information, can the attacker damage or modify the secure systems? Well, by definition, anything the administrator can do to the secure system, the attacker can do – and ultimately, administrators can do absolutely anything. And there might be other, unexpected things that an attacker could do too: for example, might they be able to “type” Base64 encoded data and a script to decode it into a secure system, in order to transfer binary malware onto it?
Of course, it’s not quite as simple as that. Remote access will involve an authentication and authorisation step where the user will need to enter a password and a two-factor authentication code. (Obviously if you don’t use two-factor authentication then it really is trivial – just keylog the password and initiate remote access at any time).
With two-factor authentication, the attacker does need to wait for the legitimate user to log on. Their job then is to hijack the legitimate session and use it to do whatever they want. It’s the same principle as the “man in the browser” attacks that have been used successfully against online banking services.
Remote access vs remote browsing
There are many attractions to remote access – but as we’ve seen, there are vulnerabilities that really can’t be mitigated. What’s the alternative?
The alternative is to accept that any system is only as secure as the endpoint that’s using it. That means that secure systems should only be accessed using endpoint machines that are as secure as they are. And the problem with that is that some users might rapidly find themselves needing several different endpoint machines – one to access the most secure systems, one to access mainstream corporate systems, and one to access untrusted Internet systems…
That’s not a very attractive working model.
Remote browsing turns the remote access model on its head. Rather than accessing a secure system from an insecure endpoint machine, remote browsing allows a secure endpoint machine to access insecure systems. That’s fundamentally better from security perspective – because done right, remote browsing can make it near-impossible for an attacker to compromise the endpoint machine, and thus give them no way of getting at any secure systems.
“Done right” in this case means that communications from less secure systems are converted into raw bitmaps (and the equivalent for sound) – a format that eliminates potential attacks. A raw bitmap is a fixed size memory buffer, so any data an attacker might write into it constitutes a valid, if potentially weird, image – meaning there is essentially no attack surface.
The secure endpoint stays secure, protecting the secure systems that it can access. But the user of the secure endpoint has access to everything, including potentially high risk systems such as random unknown websites.
The winner
In our opinion, remote browsing wins the showdown. Remote access is an in-principle insecure architecture. Remote browsing is in-principle secure.
But let’s not pretend it’s a trivial win. Firstly, making sure that a secure endpoint machine only connects to equivalently secure systems is undoubtedly hard in an era of ubiquitous Internet connections. I fear that pain is just unavoidable if you’re serious about security.
And secondly, as with any security solution, it’s all very well being secure in principle: the implementation needs to be secure in practice as well. That’s much more challenging for a remote browsing technology than it is for a remote access technology – have a look how Garrison SAVI® works if you want to know more about why that is.