Stop Exposing Your Front Door!
Another remote access service has been “popped” and used for malicious things.
During 2019 and the start of 2020 we have seen the following major security issues within popular remote access services:
Microsoft RDP — CVE-2019–1181/1182 (https://msrc-blog.microsoft.com/2019/08/13/patch-new-wormable-vulnerabilities-in-remote-desktop-services-cve-2019-1181-1182/)
CISCO AnyConnect — CVE-2019–1853 (https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190515-anyconnectclient-oob-read
Pulse Secure — CVE-2019–11510 (https://kb.pulsesecure.net/articles/Pulse_Security_Advisories/SA44101/
Citrix Gateways — CVE-2019–19781 (https://www.citrix.com/blogs/2020/01/11/citrix-provides-update-on-citrix-adc-citrix-gateway-vulnerability/)
Across the #infosec industry, we are seeing these vulnerable services being exploited for malicous gains, e.g. the recent Travelex issue (https://doublepulsar.com/big-game-ransomware-being-delivered-to-organisations-via-pulse-secure-vpn-bd01b791aad9).
This is a regretful, but common theme
Sadly the entire set of issues here is related to the foundation of the Internet: Users must share the network context with the Application.
Put simply, to consumer your applications, you have to expose them to the user, who is on the Internet, thus you are opening up a path from the Internet to your company.
The underlying nature of the TCP/IP network connections defines the ability to send data from a client — across a network — to a server. This server must be listening for that connection, thus exposing itself. Doing this on the open Internet has always been a challenge, thus the need for a secure gateway to connect users to the trusted network.
VPNs or remote access services may encapsulate the application data. However the VPN gateway must still listen to the Internet. The nature of a VPN or Remote Desktop service in itself is still a fundamental client-server model that requires the client to setup a communication link over a network to the Remote Access server.
In an article that I previously published for my employer (https://www.zscaler.com/blogs/corporate/why-darknet-good-enterprise-and-your-private-apps) I provided the example of stating on a street and seeing every single door, window and gate of all the buildings on the street.
This is TCP/IP. You can go up to and building (host) and test the door/window/gate (service) to see if it will allow you access. Of course if these doors are not secured, then anyone can walk right in off the street.
It is this consideration; standing on the street and being able to test each door that has allowed the expanse of the Internet, but enabled the risks posed by the above security vulnerabilities to not only occur, but to be exploited.
We all need a new way of enabling secure access to applications without the risk exposure to the “anyone on my street” threat.
Lets talk a bout Zero Trust Architecture (ZTA):
Unlike normal network connections, Zero Trust Architecture leverages TCP as an underlay path and forces all access to first be validated before enabling any communication. Put simply unlike standing on the street with ability to test and door, etc.; Zero Trust Architecture first validates:
- Who the user is — are they allowed to use Zero Trust service
- What device the user is coming from — e.g. is the device trusted
- What application — Is the user in question allowed to even know that the application exists
If any of these factors are NOT matched, then there is no connection — nothing. The user cant even “knock on the door”.
If these criteria are correctly, matched, then the user will be able to see the allowed application.
Remember in a Zero Trust World, there is no network access. The authorised user, with the valid device, going to the correct application; will only have access to that requested application and not the network where the app lives. Meaning that when user wants to access another application, the same authorisation process must occur.
Zero Trust > Remote Access
Zero Trust Architecture removes the need of service exposure to the open internet. Thus, put simply, with a Zero Trust Architecture — none of the application or gateways would ever be exposed to the open internet, in fact the applications and gateways would be completely dark to any non-valid sessions.
This brings improved security and risk management by “going dark”. A Zero Trust Architecture allows you to be prescriptive who gets access to what by enforcing the mantra — you cant attack what you cant see.
Note: you still need to patch
Never presume that just because your services are dark, that you wont have to patch. Always patch — just be smart about how you expose your firm to the Internet & don't expose it with Zero Trust Architecture.
Small update: Yes the images are hand drawn — thank for the question Stu.
