RemotelyAnywhere Security Whitepaper
This guide provides an in-depth look at the security features of GoTo's (f.k.a. LogMeIn) remote access and management product, RemotelyAnywhere. At GoTo we believe in security through transparency. We do not expect our customers to blindly accept our claims. By publishing details on how security mechanisms work and inter-operate in our products, we are also inviting the public to scrutinize our efforts.
Audience
This document is technical in nature and is aimed at network engineers or network designers. Reading this paper can help the reader perform the necessary threat analysis before deploying our product.
Terminology
Regarding RemotelyAnywhere's architecture, there are three entities that take part in every remote access session. The “client” or the “user” is the person or software (browser, native app, mobile app) accessing a remote resource. The “host” or the “server” is the computer being accessed, or the product's host software on this computer. The “gateway” is the service that mediates traffic between the client and the host.
Design Fundamentals
RemotelyAnywhere is designed to allow secure remote access to critical resources over an untrusted network. During development, security considerations always prevail over usability concerns.
Remote Access Axioms
Everything Is a Target
More and more computers are online 24/7. Most of these computers are operated by home users and have gaping security holes, such as unpatched vulnerabilities and a lack of proper passwords.
The greatest weakness is, however, the user himself. The extremely quick penetration of so-called email viruses illustrates the lack of security-consciousness and the gullible nature of most Internet users. Email viruses, of course, are email attachments that are better classified as Trojan horses. They spread so quickly because users are surprisingly willing to violate fundamental rules when handling untrusted content. If the users themselves are responsible for infecting their computers with Trojans, how can you trust them to properly secure their systems against direct attacks?
Even competent network administrators can slip up and forget to install a patch or two, which, in the worst-case scenario, can allow attackers to run arbitrary code on the affected systems.
Cyber-attacks are nothing new, but recently there have been significant changes in who is capable of conducting them. What was once an illicit profession restricted to a highly skilled, knowledgeable and well-connected few has morphed into an endeavor that nearly anyone can undertake, owing in large part to automated exploit kits that can abuse thousands of known vulnerabilities out of the box.
Remote Access and Security
It is easy to see that many computers connected to the Internet are extremely vulnerable, even without installing a remote access product. Remote access products are perceived as high risk factors, but mainly for psychological reasons. When a user first sees a remote access solution in action, their first negative reaction is usually with regard to the security implications. This is perfectly normal, and, in fact, desirable. The real problem is that users do not immediately see the threat inherent in other network-enabled applications, such as an email client, a web server or the operating system itself.
All modern operating systems include some sort of remote access solution by default. Windows, for example, ships with Microsoft’s Remote Desktop as a simple remote administration interface. Even OpenBSD, the Unix variant which is usually regarded as the most secure operating system available, includes SSH, which, again, is a simple and secure application that allows command-line access over a network connection to the remote computer.
In essence, a well-chosen and well-configured remote access solution reduces the number of security incidents to a minimal level. If a network manager can keep a network secure using a reliable remote access software package, such as RemotelyAnywhere, productivity can be increased and costs may be reduced without any adverse effects on network security.
Security Mechanisms
When users think of Internet data security, they are usually concerned about data encryption – to the point where security is measured in the length of the encryption key used. However, encryption and decryption, while being very important, are fairly trivial tasks compared to the other challenges faced by designers of secure systems. As you will see, data encryption is just one of the main goals set forth by the designers of RemotelyAnywhere.
Authentication of the Target Resource to Users
RemotelyAnywhere offers several layers of authentication during an access process. These authentication methods may be User authentication or Resource authentication. Through the access session, data encryption is enabled for maximum security.
First and foremost, when a user connects to a RemotelyAnywhere installation – the “server” – they need to be 100% positive that the computer they are about to exchange data with is really the one to which they intended to connect.
Suppose that an attacker poses as the server towards the user, and it poses as the user towards the server. The attacker, in this case, can sit between the two parties while reading, or possibly modifying, the data in transit. This is known as a “Man in the Middle”, or MITM attack and is especially hard to protect against. RemotelyAnywhere utilizes SSL/TLS certificates to verify Server identities and thus protect against MITM attacks. When a connection is made, the Server’s certificate is verified. If the certificate was not issued by a certifying authority the user has chosen to trust, a warning will be presented. If the certificate was issued by a trusted certifying authority, but the host-name in the URL does not match the hostname included in the certificate, a different warning will be presented.
If the Server passes these verifications, then the User’s browser generates a “Pre-Master Secret” or PMS, encrypts it with the Server’s public key contained within its certificate, and sends it to the Server. As ensured by public key cryptography, only the Server who holds the corresponding private key can decrypt the PMS. The PMS is then used to derive the Master Secret by both the User and the Server, which, in turn, will be used to derive initialization vectors and session keys for the duration of the secure session.
In short, the above ensures that the User is establishing the connection with the Server, and not with a third entity. Should a MITM attack be attempted, either one of the security warnings will be triggered or the PMS will be unknown to the MITM, effectively rendering the attack impossible.
RemotelyAnywhere supports different implementations of SSL certificates.
- Self-signed SSL certificates for Server verification are generated with pre-existing or newly created CA certificate and can be assigned to a RemotelyAnywhere host.
- You can also utilize existing Certificate Services and CA certificates to generate a Server certificate for your RemotelyAnywhere installation.
Both types can be created, configured, and applied in the browser certificate store under . In addition to web interface management of SSL certificates, RemotelyAnywhere also offers Command line parameters for SSL certificate management. For more information on Certificate related command line options, type remotelyanywhere.exe cert into a command prompt.
Data Encryption
The TLS standard defines a wide choice of cipher suites, mostly based on AES-based encryption for compatibility reasons. AES can utilize 128 or 256 bit keys. The client and the server agree on the strongest cipher possible. The client sends the server a list of ciphers it is willing to use, and the server chooses the one it prefers.
The TLS standard does not define how the server should choose the final cipher. In our case, the server simply selects the strongest shared cipher suite that the client has offered.
This method allows both the client and the server to decline the use of specific data protection algorithms without the need of updating both components, should an algorithm be deemed broken or insecure. The available cipher suites are determined by the local environment; most recent versions include SSLv3 RSA AES(256), SSLv3 RSA 3DES(168) or SSLv3 DSS Camellia(256) ciphers.
Intrusion Detection
RemotelyAnywhere provides two layers to detect intrusion attempts: TLS and LogMeIn Intrusion Filters.
TLS
For the first layer of intrusion detection, LogMeIn utilizes TLS 1.2 and 1.3 certificate based authentication to ensure that the data has not changed in transit. This is achieved by the following techniques:
- Record Sequence Numbering
- Record Sequence Numbering means that TLS records are numbered by the sender and the order is checked by the receiver. This ensures that an attacker cannot remove or insert arbitrary records into the data stream.
- Message Authentication Codes
- Message Authentication Codes (MACs) are appended to every TLS record. This is derived from the session key (known only to the two communicating parties) and the data contained within the record. If MAC verification fails it is assumed that the data were modified in transit.
- Cipher Block Chaining (CBC mode)
- The cipher suites preferred by RemotelyAnywhere utilize Cipher Block Chaining, meaning that every SSL/TLS record will depend on the contents of the previous record. In this mode, the input to the cipher is not only the current plaintext record but the previous one as well. This again ensures that packets cannot be inserted or removed from the data stream.
RemotelyAnywhere Intrusion Filters
The second layer is provided by RemotelyAnywhere itself, and is comprised of three intrusion filters.
IP Address Filter
When RemotelyAnywhere receives a connection request from a client, it first checks its list of trusted and untrusted IP addresses and possibly denies the connection. An administrator can set up a list of IP addresses within RemotelyAnywhere that are either allowed or denied to establish a connection to the selected host (for example, designate the internal network and another administrator’s home IP address as allowed). IP Address filters can be set under . You can also set filter profiles for the network adapters available on the Server under .
Denial of Service Filter
A Denial of Service Filter rejects connections if the IP address the request is coming from has made an excessive number of requests without authentication within the observation time window. This is done to protect against someone overloading the host computer by, for example, automatically and very quickly requesting the login page over and over again. You can customize the DoS filter behavior under .
Authentication Filter
If the user made an excessive number of failed login attempts, the Authentication Filter rejects the connection. The Authentication Filter is in place to prevent a potential intruder from guessing an account name and password. You can customize the authentication attack filter behavior under .
Authentication and Authorization of Users to the Host
After being granted access by the previous layers, the user must prove his identity to the host. This is achieved by a mandatory OS-level authentication step.
The user must authenticate himself to the host using his standard Windows or Mac username and password. The host will usually pass this request on to the relevant domain controller. This step not only validates the user’s identity, but also ensures that network administrators can control who is able to log in to a specific host.
Personal Password
Personal Password is another optional security measure that can be set up on the LogMeIn host. The user can assign a Personal Password to the host, which, like the OS-level password, is not stored or verified by the gateway. A difference between the operating system password and the Personal Password is that the host never asks for the complete Personal Password so the user never enters it in its entirety in any single authentication session. The user is usually prompted for three random digits of the Personal Password by the host after OS-level authentication has succeeded. If the user enters the correct characters (for example, the first, the fourth and the seventh) he is granted access.
Here's how to set up a Personal Password:
- Access the host preferences from either the host or the client:
-
- If you are at the host, open the LogMeIn Control Panel and follow this path:
- If you are at the client, connect to the host Main Menu and follow this path:
- Under Personal Password, enter your personal password and then enter it again to confirm.
- Click Apply.
-
GoTo and RSA SecurID
To add an extra layer of security over the simple username/password authentication, you can configure LogMeIn to require RSA SecurID authentication. RemotelyAnywhere, the product that pioneered the technology in use by LogMeIn, was officially certified by RSA Security as SecureID Ready in 2003. Since that time, GoTo has continued to maintain the high level of security consistent with RSA technology.
For information on the RSA SecurID product, visit the RSA website. For information on setting up this feature on a LogMeIn host, visit https://support.logmeininc.com/pro.
Authentication between Users and the Host
Authentication and Authorization of Users within the Host
Once LogMeIn has verified the user’s identity using the above methods, it checks its own internal user database to see which internal modules the user is allowed to access.
System administrators can configure LogMeIn so that users with certain roles have access only to a subset of tools offered by LogMeIn; for example, the Helpdesk department can be configured to only view a computer’s screen and performance data, but not actually take over the mouse and the keyboard or make any changes to the system configuration. Alternatively, the Sales department might be given full remote control access to their respective computers, but features such as performance monitoring and remote administration would be made unavailable to them.
Using the operating system access token obtained when the user was authenticated, LogMeIn impersonates the user towards the operating system while performing actions on their behalf. This ensures that LogMeIn adheres to the operating system's security model, and users have access to the same files and network resources as if they were sitting in front of their computer. Resources unavailable to users in Windows or OS X also remain unavailable via LogMeIn.
See “Controlling Who Can Access Your Host Computers” in the Pro or Central support site.
Auditing and Logging
LogMeIn provides extensive logging capabilities. A very detailed log of the events that occur within the software is kept in the LogMeIn data log directory. The most important events are also placed in the Windows application event log – these events include, for example, logon and logoff actions. The detailed log can also be sent to a custom SYSLOG server of the customer's choice.
RemotelyAnywhere provides extensive logging capabilities. These audit features are explained in the table below.
| Default text log | By default a very detailed log of the events that occur within the software is kept in the installation directory. These text based logs are kept for 90 days by default. The active log file is named RemotelyAnywhere.log. Older logs are stored with the naming convention RAYYYYMMDD.log. For example, the RemotelyAnywhere log file for June 1, 2012, would be called RA20120601.log. The text based log mechanisms will include every action performed via the Web interface of RemotelyAnywhere including any Chat content, files transferred, remote screen control sessions. You can modify the setting for these logs under . |
| SYSLOG Server Storage | The text-based detailed log can also be sent to a central SYSLOG server. |
| ODBC Logging | The text-based detailed log can be sent to a relational database over a pre-defined ODBC link. |
| Windows Event log | The most important events are also placed in the Windows application event log. Windows Event Log can only be accessed and cleared with appropriate, previously granted privileges. RemotelyAnywhere will always log the following events to the Windows Application Log: Service Start/Stop, LogIn/Logout, Remote Control Start/Stop. |
See How to View Host Event Log Files for details.
Remote Control Screen Recording
The text based logs above do not include events which were performed using interactive mouse and keyboard operations using the Remote Control feature. To provide full logging and audit track, RemotelyAnywhere also offers Session recording. The recording will be saved in a specified directory, in proprietary RemotelyAnywhere codec format, and can be played back after conversion. Session recording videos will be stored by a standard file naming convention, with the following file name: RCREC[HOSTNAME][YYYY-MM-DD_HHhMMmSSs][USERNAME].RCREC
RemotelyAnywhere Access
Default Configuration
- Accepts Web and Console connections on port 2000 on all network adapters
- Accepts SSH connections on port 22 on all network adapters
- Accepts Telnet connections on port 23 on all network adapters
- All above connections must be authenticated with a username/password pair that identifies a user with Administrator rights
- Connections are accepted from any Internet address
Unused Services
Decide which RemotelyAnywhere services you want to use on the computer, and disable the rest. We recommend disabling Telnet and SSH if you do not need access to a command prompt. If you do, disable Telnet and leave SSH running.
Incoming Connections
You can change the IP address on which RemotelyAnywhere listens to incoming connections. Assume you have a web server on the Internet named www.MyWebServer.com and RemotelyAnywhere is installed on your web server on port 2000. The web server can now be remotely managed by typing http://www.mywebserver.com:2000 in any web browser. However, by adding another IP address to the server for remote administration purposes and restricting RemotelyAnywhere to listen only to that particular address the server can only be accessed from this address. For example, if you add the address 177.246.27.91, the server can only be accessed by typing http://177.246.27.91:2000; any attempt to access RemotelyAnywhere using the original address (http://www.mywebserver.com:2000) will fail.
If possible, try to use an IP address that is on a different subnet than the IP addresses of the website or websites hosted on the computer. Most attacks begin with a port scan on the target computer. If the attacker sees port 2000 open on www.MyWebServer.com they will know that RemotelyAnywhere is installed on the computer. Using a different administrative IP address will hide this fact.
Default Port Numbers
Unlike the default Windows services, such as file sharing, the ports providing access to RemotelyAnywhere services can be changed to thwart potential intruders. You should, however, choose a port that is easy to remember.
SSH, Telnet, and FTP port numbers can all be configured under the relevant Preferences section of these services. The RemotelyAnywhere Service must be restarted for port changes to take effect, and you should take care to avoid port conflicts with other services when choosing new RemotelyAnywhere ports. Port conflicts may cause failure when starting the RemotelyAnywhere System service.
Local Software Firewall Protection
Local software firewalls, such as Windows Firewall, ZoneAlarm, or Norton 360, will filter applications from accessing local ports. For operation of RemotelyAnywhere access, these tools will need to be configured to allow communication over the RemotelyAnywhere service ports. By implementing additional controls in these third party tools, you can further restrict the access process to RemotelyAnywhere installations.
Network Access Mapping
By default, RemotelyAnywhere is implemented in a LAN or WAN environment, allowing access only to internal resources. Typically there is no firewall between two LAN devices, so access to RemotelyAnywhere’s management port is not blocked or restricted.
A user must be present in the LAN and behind the Internet facing firewalls to attempt access to a RemotelyAnywhere server. To gain access to a server from outside the company environment over highly untrusted networks such as the Internet, network engineers usually have to deal with one or more firewalls. Allowing access to RemotelyAnywhere installations from an outside network is slightly more complicated.
Firewall Port Mapping
The figure above describes the basic case of several RemotelyAnywhere installations behind a firewall. System administrators can choose which computers should be available from the Internet and map a port on the firewall to each computer that needs to be accessed from outside the corporate security perimeter. In the above example, assuming that the firewall’s external IP address is 123.456.789.012, Host 01 can be accessed by going to 123.456.789.012:X, Host 02 can be accessed at 123.456.789.012:X+1, etc. This scenario is very workable for a small number of hosts, but presents several issues when a large number of computers need to be made accessible. Most notably, the system administrator will need to keep track of and manage a number of port mappings, therefore introducing a human factor which is always a risk factor. Furthermore each computer that is accessible over the Internet will need to be kept secure, which can be a daunting task.
SSH Tunneling
The figure above shows another scenario wherein a single port needs to be opened on the firewall. This requires the use of an SSH gateway. RemotelyAnywhere’s Server edition includes a feature-complete SSH server, so a single Windows computer running RemotelyAnywhere can take this role. The administrator will need to open a single port on the firewall and map it to the SSH port of the gateway. The client computers need to run SSH client software and establish an SSH2 session to the SSH gateway (there are many SSH client software implementations available, ranging from free to commercially supported ones, but RemotelyAnywhere’s Server edition also includes an SSH Server module). Then the client’s user will need to configure the SSH client to map a certain local port (x) to the RemotelyAnywhere port of the desired host on the internal network. Then the client can launch a browser and go to
localhost:x to gain access to the RemotelyAnywhere login screen on the target computer. This temporary tunnel is available while the SSH client is running and connected to the SSH gateway. The advantages of implementing this scenario are obvious: there’s a single point of entry to the network and this is where the system administrator needs to concentrate his efforts. The disadvantage is that users will need to be educated on using an SSH client. To use RemotelyAnywhere’s built-in SSH server and SSH Port forwarding features, go to
and
.
Conclusion
A well-designed remote access solution can greatly increase productivity and provide a rapid return on investment. When deployed with care and RemotelyAnywhere's optional security features are utilized, the benefits greatly outweigh the risks.