LogMeIn Security White Paper
2 likes1,463 views
This document provides an in-depth overview of the security features of LogMeIn's remote access product. It describes LogMeIn's architecture with three key components - the client, host, and LogMeIn gateway. It then details LogMeIn's security mechanisms, which include authentication of users and systems, data encryption, and intrusion detection methods like IP filtering and login attempts limiting. The purpose is to explain how LogMeIn ensures secure remote access over untrusted networks.
![4 LogMeIn Security: an In-Depth Look
Worms like MSBlaster or Slammer were poorly written, their spread rate was far from optimal, and did not cause data loss
or theft. Their creators exploited a widely known vulnerability in Microsoft SQL Server – a fix was available for several weeks
before the first worm attack struck. In other words, they qualify as a very tasteless joke – one that undoubtedly caused many
problems, but whose effect was nowhere near as disastrous as it could have been.
One can only imagine what real hackers with malicious intent are capable of when they have a lucrative target.
Compromised Resources Are Weapons
Many systems on the Internet are prime targets for hacker attacks. These attacks are usually committed for financial gain, but
sometimes their sole purpose is to entertain the perpetrator.
In the fall of 2003, Valve Software had one of their computers compromised. [WRD20041004] The hacker gained access to one
system at first, reportedly via an unpatched Microsoft Outlook vulnerability, then proceeded to install a keystroke logger that
allowed him to capture network passwords entered on that computer. From then on it was smooth sailing; he made off with
the source code for Valve’s highly anticipated computer game, Half Life 2, which was in the final stages of development.
In February 2003, millions of credit card numbers were stolen [CNN20030218] from an unnamed Internet site, most likely
a credit card processor, possibly resulting in subsequent fraudulent transactions worth several million dollars. The affected
parties are understandably very tight-lipped about the event, so no further details are available.
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.
Many operating systems include some sort of remote access solution by default. Windows 2000 and 2003 Server, for example,
ship 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 does not carry any additional risks. If a network
manager can keep a network secure using a reliable remote access software package, such as RemotelyAnywhere or LogMeIn,
productivity can be increased and costs reduced without any adverse effects on network security.
©2009 LogMeIn Inc.](https://image.slidesharecdn.com/wplmisecurity-091116112613-phpapp01/85/LogMeIn-Security-White-Paper-4-320.jpg)
![6 LogMeIn Security: an In-Depth Look
The obvious benefit of utilizing the gateway, instead of establishing a direct link between the client and the host, is that either
one, or both, of the latter entities can be firewalled. By utilizing the gateway, LogMeIn ensures that users do not need to worry
about firewall configuration.
LogMeIn 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 five main goals set forth by the designers of LogMeIn.
Authentication of the Target Resource to Users
First and foremost, when a user connects to a LogMeIn installation – the “Server” – they need to be 100% positive that the
computer they’re about to exchange data with is really the one they intended to connect to.
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.
LogMeIn 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 hostname 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 the use of public key cryptography,
only the Server that 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.
For further details on the subject, see [SSL].
©2009 LogMeIn Inc.](https://image.slidesharecdn.com/wplmisecurity-091116112613-phpapp01/85/LogMeIn-Security-White-Paper-6-320.jpg)
![9 LogMeIn Security: an In-Depth Look
Data Encryption
The SSL/TLS standard defines a wide choice of cipher suites such as RC4 and 3DES, and some implementations offer more
advanced suites that include AES as well. RC4 operates on 128 bit keys, 3DES uses 168 bit keys. AES can utilize 128 or 256 bit
keys. The User and the Server will agree on the strongest cipher possible. This is done by the User sending the Server a list of
ciphers it is willing to use, and the Server choosing the one it prefers from this list.
The SSL/TLS standard does not define how the Server should choose the final cipher. In LogMeIn, the Server simply selects the
strongest available cipher suite that the Client has offered.
This method allows both the Client and the Server to decline the use of specific data-encryption algorithms without the need
of updating both components, should an algorithm be deemed as broken or insecure by research.
Intrusion Detection
LogMeIn provides two layers to detect intrusion attempts. The first layer is provided by SSL/TLS to ensure that the data have
not changed in transit. This is achieved via various techniques:
Record Sequence Numbering means that SSL/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 (MACs) are appended to every SSL/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. The cipher suites preferred by LogMeIn also utilize Cipher Block Chaining (CBC mode);
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.
For more details about SSL/TLS intrusion detection, see [SSL].
The second layer is provided by LogMeIn itself, and is comprised of three filters.
IP Address Filter
When LogMeIn receives a connection request from a User, it first checks its list of trusted or untrusted IP addresses and possibly
denies the connection.
©2009 LogMeIn Inc.](https://image.slidesharecdn.com/wplmisecurity-091116112613-phpapp01/85/LogMeIn-Security-White-Paper-9-320.jpg)
![10 LogMeIn Security: an In-Depth Look
An administrator can set up a list of known good or known bad IP addresses within LogMeIn. For example, he can designate
the internal network and another administrator’s home IP address as known good ones.
Denial of Service Filter
A Denial of Service Filter will reject 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.
Authentication Filter
If the user has made an excessive number of failed login attempts, the Authentication Filter will reject the connection. The
Authentication Filter is in place to prevent a potential intruder from guessing an account name and password.
Authentication and Authorization of Users to the Host
After the user has been granted access by the previous layers, it is time for him to prove his identity to the Server. This is
achieved by a mandatory Windows authentication step.
Windows authentication - for further information see [WINAUTH] - requires that the user authenticates himself to the Server
using his standard Windows username and password. The Server 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 can
log in to a specific Server and when.
To add an extra layer of security over the simple username / password authentication required by Windows, system administrators
can configure LogMeIn to also require RSA SecurID authentication. SecurID is a two-factor authentication method, requiring
that users provide a secret that only they and the ACE authenticator server share a knowledge of, and prove that they possess
a proprietary device called an authenticator.
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, LogMeIn has continued to maintain the high level of security consistent with RSA
technology. For more information on the RSA SecurID product see [RSASECURID].
Another optional security measure in the LogMeIn Host is a Personal Password. The user can assign a Personal Password to the
Host. This password, much like the Windows password, is not stored or verified by the Gateway – but an interesting difference
between the Windows password and the Personal Password is that the Host never asks for the complete Personal Password so
it is never input by the user in its entirety in any single authentication session. The user is usually prompted for three random
digits of this Personal Password by the Host after Windows authentication has succeeded. If the user enters the correct digits
(for example, the first, the fourth and the seventh) he is granted access.
©2009 LogMeIn Inc.](https://image.slidesharecdn.com/wplmisecurity-091116112613-phpapp01/85/LogMeIn-Security-White-Paper-10-320.jpg)
LogMeIn Security White Paper
- 1. LogMeIn Security: an In-Depth Look
- 2. 2 LogMeIn Security: an In-Depth Look Table of Contents Remote Access Axioms 3 LogMeIn Architecture 5 LogMeIn Security Mechanisms 6 Intrusion Detection 9 Data Forwarding 12 UDP NAT Traversal 12 Software Updates and Gateway Security 13 Conclusion 14 References 14 Author Márton Anka, Chief Technical Officer of LogMeIn, Inc., is the primary author of this paper. Abstract This paper provides an in-depth look at the security features of LogMeIn.com’s remote access product, LogMeIn. We at LogMeIn.com do not believe in security through obscurity, nor do we expect our customers to blindly accept our claims to important security features, such as end-to-end encryption. By publishing the details on how the security mechanisms work and interoperate in our products, we are also inviting the public to scrutinize our efforts. Product Information: info@LogMeIn.com Sales Inquiries: sales@LogMeIn.com (800) 993-1790 Press: press@LogMeIn.com Address: 500 Unicorn Park Drive, Woburn, MA 01801 www.LogMeIn.com ©2009 LogMeIn Inc.
- 3. 3 LogMeIn Security: an In-Depth Look Audience This document is technical in nature and is aimed at network engineers or network designers. The audience, after reading this white paper and combining the information contained herein with existing knowledge of their own network, can perform the necessary threat analysis before deploying our product. Terminology In the LogMeIn architecture, there are three entities that take part in every remote access session. The “Client” or the “User” is the person or software accessing a remote resource. The “Host” or the “Server” is the computer being accessed, or the LogMeIn host software on this computer. The “Gateway” is the LogMeIn service that mediates traffic between the Client and the Host. Design Fundamentals LogMeIn was designed to allow secure remote access to critical resources over an untrusted network. During the development of the software, security considerations always prevailed over usability concerns. The following security design objectives, listed in order of priority, guided the decision-making process: Remote Access Axioms Everything Is a Target As the penetration of broadband Internet connections increases, 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. Nothing illustrates better the sheer lack of security-consciousness and gullible nature of most Internet users than the extremely quick penetration of the so-called email viruses. These email attachments are actually better classified as trojan horses, and they spread so fast because users are surprisingly willing to violate one of the primary rules for 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 a worst case scenario, can allow attackers to run arbitrary code on the affected systems. Nothing demonstrates this better than the rapid spread of the Microsoft SQL Server worms in 2003. Both MSBlaster and Slammer infected a great number of computers, and generated such excessive amounts of network traffic - with the help of the exponentially growing number of infected hosts - that users could perceive a slowdown in Internet access even on uncompromised networks. ©2009 LogMeIn Inc.
- 4. 4 LogMeIn Security: an In-Depth Look Worms like MSBlaster or Slammer were poorly written, their spread rate was far from optimal, and did not cause data loss or theft. Their creators exploited a widely known vulnerability in Microsoft SQL Server – a fix was available for several weeks before the first worm attack struck. In other words, they qualify as a very tasteless joke – one that undoubtedly caused many problems, but whose effect was nowhere near as disastrous as it could have been. One can only imagine what real hackers with malicious intent are capable of when they have a lucrative target. Compromised Resources Are Weapons Many systems on the Internet are prime targets for hacker attacks. These attacks are usually committed for financial gain, but sometimes their sole purpose is to entertain the perpetrator. In the fall of 2003, Valve Software had one of their computers compromised. [WRD20041004] The hacker gained access to one system at first, reportedly via an unpatched Microsoft Outlook vulnerability, then proceeded to install a keystroke logger that allowed him to capture network passwords entered on that computer. From then on it was smooth sailing; he made off with the source code for Valve’s highly anticipated computer game, Half Life 2, which was in the final stages of development. In February 2003, millions of credit card numbers were stolen [CNN20030218] from an unnamed Internet site, most likely a credit card processor, possibly resulting in subsequent fraudulent transactions worth several million dollars. The affected parties are understandably very tight-lipped about the event, so no further details are available. 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. Many operating systems include some sort of remote access solution by default. Windows 2000 and 2003 Server, for example, ship 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 does not carry any additional risks. If a network manager can keep a network secure using a reliable remote access software package, such as RemotelyAnywhere or LogMeIn, productivity can be increased and costs reduced without any adverse effects on network security. ©2009 LogMeIn Inc.
- 5. 5 LogMeIn Security: an In-Depth Look LogMeIn Architecture Before explaining the exact security mechanisms employed by LogMeIn, it is necessary to give a quick introduction to the network architecture designed by LogMeIn. There are three key components to any remote access session. The roles of the client and the host should be straightforward – the third component is the LogMeIn gateway. The LogMeIn host in the illustration above maintains a constant SSL-secured connection with one of the LogMeIn gateway servers in our physically secure datacenter. This link is initiated by the host and firewalls treat it as an outgoing connection, not unlike secure web-browsing traffic. The client browser establishes a connection to www.logmein.com and authenticates itself. The gateway then forwards the subsequent encrypted traffic between the client and the host. It is worth noting that the client will still need to authenticate itself to the host – the gateway mediates the traffic between the two entities, but it does not require that the host implicitly trust the client. Client Browser LogMeIn Host Figure 1: LogMeIn Architecture ©2009 LogMeIn Inc.
- 6. 6 LogMeIn Security: an In-Depth Look The obvious benefit of utilizing the gateway, instead of establishing a direct link between the client and the host, is that either one, or both, of the latter entities can be firewalled. By utilizing the gateway, LogMeIn ensures that users do not need to worry about firewall configuration. LogMeIn 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 five main goals set forth by the designers of LogMeIn. Authentication of the Target Resource to Users First and foremost, when a user connects to a LogMeIn installation – the “Server” – they need to be 100% positive that the computer they’re about to exchange data with is really the one they intended to connect to. 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. LogMeIn 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 hostname 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 the use of public key cryptography, only the Server that 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. For further details on the subject, see [SSL]. ©2009 LogMeIn Inc.
- 7. 7 LogMeIn Security: an In-Depth Look Authentication of Users to the Gateway Clients must be authenticated by both the Gateway and the Host. When a client logs on to the LogMeIn website a simple email address / password verification is performed. Users are advised to enable one or more of the extra security options that LogMeIn provides. One of these options is a sheet of printed One-Time-Passwords (OTPs). When the user enables the OTP option, he is required to print out a list of 9-character random passwords generated by the Gateway. Once this is done, subsequent logins to the LogMeIn.com site will require the entry of any one of the passwords on the sheet that has not been used before. Before the user runs out of OTPs, he is required to print another sheet – at which point in time any unused passwords on the previous sheet are invalidated. The other, easier, method is to make use of LogMeIn’s Wireless Password technology. When this option is enabled, the user is required to enter a wireless email address – messages sent to this address will contain a short-lived single-use password. To make use of this technology, the receiver of the emails should be a wireless device such as a cell phone or pager – the only requirement is that the receipt of emails on this device should be near real-time. When this feature is turned on and the user authenticates successfully with his email address and password to the LogMeIn Gateway, a password is generated and sent to the wireless email address. The user will have to receive this email and enter the code contained within into the form provided by the Gateway - thus proving that he is in possession of the device. This password expires a few minutes after it has been generated – or after it is used, whichever comes first. Figure 2: Authentication between Users and the Gateway ©2009 LogMeIn Inc.
- 8. 8 LogMeIn Security: an In-Depth Look Authentication of the Gateway to the Host The Gateway needs to prove its identity to the Host before it can be trusted with access codes. The Host, when making a connection to the Gateway, will check its SSL certificate to make sure it is indeed connecting to one of the LogMeIn servers. The exact details of this process are very similar to the steps described above. Authentication of the Host to the Gateway The Gateway verifies the Host’s identity when it accepts an incoming connection using a long unique identifier string which is a shared secret between the two entities and is issued by the Gateway when the Host makes its first connection. This unique identifier is only communicated over an SSL-secured channel, and only after the Host has verified the Gateway’s identity. Figure 3: Host and Gateway Authentication The above diagram illustrates how the host and the gateway authenticate each other before a host is made accessible to the user. ©2009 LogMeIn Inc.
- 9. 9 LogMeIn Security: an In-Depth Look Data Encryption The SSL/TLS standard defines a wide choice of cipher suites such as RC4 and 3DES, and some implementations offer more advanced suites that include AES as well. RC4 operates on 128 bit keys, 3DES uses 168 bit keys. AES can utilize 128 or 256 bit keys. The User and the Server will agree on the strongest cipher possible. This is done by the User sending the Server a list of ciphers it is willing to use, and the Server choosing the one it prefers from this list. The SSL/TLS standard does not define how the Server should choose the final cipher. In LogMeIn, the Server simply selects the strongest available cipher suite that the Client has offered. This method allows both the Client and the Server to decline the use of specific data-encryption algorithms without the need of updating both components, should an algorithm be deemed as broken or insecure by research. Intrusion Detection LogMeIn provides two layers to detect intrusion attempts. The first layer is provided by SSL/TLS to ensure that the data have not changed in transit. This is achieved via various techniques: Record Sequence Numbering means that SSL/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 (MACs) are appended to every SSL/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. The cipher suites preferred by LogMeIn also utilize Cipher Block Chaining (CBC mode); 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. For more details about SSL/TLS intrusion detection, see [SSL]. The second layer is provided by LogMeIn itself, and is comprised of three filters. IP Address Filter When LogMeIn receives a connection request from a User, it first checks its list of trusted or untrusted IP addresses and possibly denies the connection. ©2009 LogMeIn Inc.
- 10. 10 LogMeIn Security: an In-Depth Look An administrator can set up a list of known good or known bad IP addresses within LogMeIn. For example, he can designate the internal network and another administrator’s home IP address as known good ones. Denial of Service Filter A Denial of Service Filter will reject 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. Authentication Filter If the user has made an excessive number of failed login attempts, the Authentication Filter will reject the connection. The Authentication Filter is in place to prevent a potential intruder from guessing an account name and password. Authentication and Authorization of Users to the Host After the user has been granted access by the previous layers, it is time for him to prove his identity to the Server. This is achieved by a mandatory Windows authentication step. Windows authentication - for further information see [WINAUTH] - requires that the user authenticates himself to the Server using his standard Windows username and password. The Server 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 can log in to a specific Server and when. To add an extra layer of security over the simple username / password authentication required by Windows, system administrators can configure LogMeIn to also require RSA SecurID authentication. SecurID is a two-factor authentication method, requiring that users provide a secret that only they and the ACE authenticator server share a knowledge of, and prove that they possess a proprietary device called an authenticator. 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, LogMeIn has continued to maintain the high level of security consistent with RSA technology. For more information on the RSA SecurID product see [RSASECURID]. Another optional security measure in the LogMeIn Host is a Personal Password. The user can assign a Personal Password to the Host. This password, much like the Windows password, is not stored or verified by the Gateway – but an interesting difference between the Windows password and the Personal Password is that the Host never asks for the complete Personal Password so it is never input by the user in its entirety in any single authentication session. The user is usually prompted for three random digits of this Personal Password by the Host after Windows authentication has succeeded. If the user enters the correct digits (for example, the first, the fourth and the seventh) he is granted access. ©2009 LogMeIn Inc.
- 11. 11 LogMeIn Security: an In-Depth Look Authentication and Authorization of Users within the Host LogMeIn, once it has verified the user’s identity using the above methods, will check 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. Figure 4: Authentication between Users and the Host Using the Windows 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 Windows 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 will remain unavailable via LogMeIn. ©2009 LogMeIn Inc.
- 12. 12 LogMeIn Security: an In-Depth Look Auditing and Logging LogMeIn provides extensive logging capabilities. A very detailed log of the events that occur within the software is kept in the installation directory. The most important events are also placed in the Windows NT application event log – these events include, for example, logon and logoff actions. The detailed log can also be sent to a central SYSLOG server or to a relational database over a pre-defined ODBC link. Data Forwarding The Gateway forwards encrypted data between the Host and the Client, thus providing end-to-end encryption. If the reader is familiar with how SSL works, this might sound impossible; after all, the logical assumption is that since the Client is confident that it is communicating with the Gateway it is only the Gateway that can decrypt the data sent by the Client. This is a valid point, but LogMeIn made a few important changes to how SSL sessions are handled between the Host and the Gateway. Effectively, the first part of the SSL negotiation is in fact performed between the Gateway and the Client – but the Gateway then passes the exchange down to the Host which re-negotiates the SSL session and agrees on a new session keys with the Client, thereby providing true end-to-end encryption. The fact that the Client has verified the Gateway’s certificate – and actually used its RSA public key to encrypt bits of information used to generate the Pre-Master Secret – and the fact that the Host has done the same with the Gateway’s certificate effectively renders a man-in-the-middle attack impossible. UDP NAT Traversal It is important to explain how UDP NAT Traversal fits into the big picture, especially since UDP itself is regarded as notoriously insecure. This is not entirely a misconception: if UDP is used as a communications medium, then security can be a serious problem, as UDP datagrams are easy to forge and the sender’s IP address can easily be spoofed. To counter this, with UDP NAT Traversal connections, LogMeIn.com do not use UDP as the communications medium itself. UDP is relegated to the network layer, as defined by the ISO/OSI Network Model, with a TCP-like transport layer built on top of it, complete with flow control, dynamic bandwidth scaling and packet sequence numbering. The reason LogMeIn.com resorted to using UDP instead of IP packets (and therefore effectively re-implemented a TCP-like transport layer) is because most firewalls and NAT devices allow seamless two-way communication over a UDP transport as long as it is initiated from within the security perimeter, but they require significant reconfiguration for TCP and IP packets. After a reliable TCP-like stream is constructed from unreliable UDP packets, the stream is further protected by an SSL layer, providing full encryption, integrity protection and endpoint verification capabilities. ©2009 LogMeIn Inc.
- 13. 13 LogMeIn Security: an In-Depth Look To set up a UDP NAT Traversal connection, both the Client and the Host send several encrypted UDP packets to the Gateway. These packets are encrypted using a secret shared by Gateway and the respective peer, communicated over a pre-existing SSL connection; therefore they are impossible to spoof. The Gateway uses these packets to determine the external (Internet) IP addresses of the two entities and it also tries to predict which firewall port will be used for communication when a new UDP packet is sent. It passes its findings down to the peers which will then attempt to set up a direct connection. If the gateway was successful in determining the port order, the connection will succeed and the peers, after verifying each other using another shared secret obtained from the Gateway and establishing an SSL session, will communicate directly. If a direct connection is impossible to set up, the peers will connect back to the Gateway over TCP and request that a forwarded, end-to-end encrypted session be used. This whole process takes only a few seconds and is transparent to the user. The only noticeable difference is the improved performance and low latency when a direct connection is in use. Software Updates and Gateway Security The LogMeIn Host can semi-automatically or automatically update itself on the user’s computer. The Host software periodically checks the LogMeIn.com website for newer versions of the software. If such a new version is found, it is automatically downloaded (while making sure that the download process only uses at most 50% of the available bandwidth, therefore never interfering with any networking application) and when the user is physically in front of the computer, a message is presented and the customer can allow the update to take place. These software updates are digitally signed by LogMeIn.com with a certificate that is not found on any of our Internet-connected systems. Therefore, even if our datacenters were physically compromised by attackers who then gained complete control over our servers, they would not be able to introduce a rogue update and run arbitrary code on our users’ computers. The most such a highly unlikely attack could accomplish is access to the LogMeIn logon screen on the customer’s computer, which, even though it effectively bypasses the Gateway security mechanisms, would still require that they enter a valid Windows username and password combination to gain access to the computer. Brute-forcing the password is unfeasible, as the Authentication filter, by default, kicks in after a few mistyped passwords. In the event that our customers use the same password for the LogMeIn Gateway and their Windows computer, we do not store the actual LogMeIn passwords in our database; rather, we employ a one-way cryptographic hash and a salt value to ensure that brute-forcing is infeasible given the computing resources available today. ©2009 LogMeIn Inc.
- 14. 14 LogMeIn Security: an In-Depth Look Conclusion A well-designed remote access solution can greatly increase productivity and provide a rapid return on investment. When deployment is done with care and LogMeIn’s optional security features are utilized, the benefits greatly outweigh the risks. References SSL Eric A. Rescorla: SSL and TLS: Designing and Building Secure Systems Addison-Wesley Pub Co, October 13, 2000 ISBN: 0201615983 SSH D. J. Barrett, SSH, The Secure Shell: R. Silverman: The Definitive Guide O’Reilly & Associates, February 15, 2001 ISBN: 0596000111 WINAUTH Windows 2000 Security Technical Overview http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/sectech.mspx RSASECURID RSA Security’s SecurID Product http://www.rsa.com/node.aspx?id=1156 CNN20030218 Hacker accesses 5.6 million credit cards. http://www.cnn.com/2003/TECH/02/17/creditcard.hack/ WRD20031004 Game Biz Mystified by Code Theft http://www.wired.com/news/games/0,2101,60701,00.html ©2009 LogMeIn Inc.