Exploiting LogMeIn.com Authentication Issues

 

This week I discovered two interesting vulnerabilities in regards to the logmein.com website.

Vulnerability 1: Registration and full login allowed without email validation (for 7 days)
Severity: Medium
Impact: Preemptive account compromise
Prerequisite: The attacker must know that a user with a specific email address is about to sign up for logmein.com

Vulnerability 2: Inability to evict an attacker from a compromised account by logging out all other sessions (reference Facebook, Google, etc.)
Severity: Medium
Impact: Attacker persistence
Prerequisite: The attacker must already have compromised the account (via Vulnerability 1, or another method) and have a valid login session

I made the decision to post the exploits prior to contacting logmein.com's security team for two reasons:

A. These are basic design flaws. The application seems to have be coded in this manner intentionally. Best practices for authentication have been publicly published by OWASP for quite some time.

B. These vulnerabilities have narrow prerequisites. Under the right circumstances (especially when combined) these could be very serious security issues, but if the circumstances don't exist, the attacks are useless. This makes them medium-level severity vulnerabilities perhaps, but sometimes medium vulns are all an attacker needs.

The video above shows two attack variants in detail. The video is long, so I've documented a more straightforward PoC exploit-chain below.


Attack Steps:

1. The attacker preemptively targets a potential future LMI user using dorks, etc.: inurl:community.spiceworks.com recommend logmein -alternative

2. The attacker uses OSINT to determine the victim's existing email address.

3. The attacker signs up for LMI with the victim's email address. (You can login fully without verifying the email address, for 7 days.)

4. The attacker automates login detection
a) Settings>Account Settings>Audit log
b) watch -n 20 -x curl -s <CURL-REQUEST-FOR-/AUDITLOG-COPIED-FROM-CHROME> -o lmi-login-detection.txt
c) watch -n 3 -x grep -c '<td>Login successful' lmi-login-detection.txt

(could be automated further to email the attacker upon victim login, etc.)

5. The victim either: 

Scenario A) receives the unsolicited registration email and doesn't click because they were not expecting it and view it as spam. (EDIT: I just tried registering with an Office365 email account and discovered that the registration email goes to Junk Mail, which is of interest because they may have no idea an account was created with their email address.) At a later time (within 7 days) they try to sign up but discover they already have an account and must password reset to gain access.
Scenario B) clicks the registration link immediately and gains access to the account.

6. The victim attempts to lock down the account (or maybe not!) with:
    i) Account Settings>Audit log>See something suspicious?>Change password
    ii) Account Settings>Trusted devices

7. The victim believes the account to be secured and begins normal usage of the account.

8. Despite the victim's lockdown efforts, attacker still has access because their session remains valid.

I've contacted LogMeIn and will be updating this post with the disclosure timeline at a later time.

 

UPDATE:

Below is the full timeline of disclosure communication.

Sep 17, 2020 - I sent a twitter DM to @logmein but they never replied.

Sep 18, 2020 - I sent another twitter DM to @logmein but they never replied.

Sep 18, 2020 - I sent a Facebook message to LogMeIn who replied the same day telling me to email Security@logmein.com.

Sep 18, 2020 - I sent an email to Security@logmein.com but they never replied.

Sep 24, 2020 - I sent a twitter DM to @beuchelt (Gerald Beuchelt), CISO of LogMeIn, who asked me for my email address so his team could reach out but they never did.

Sep 29, 2020 - I still haven't received any meaningful communication from LogMeIn regarding these vulnerabilities. I just retested, and the email registration issue still exists. I haven't retested the other vulnerability.

Sep 30, 2020 - I received communication from LogMeIn essentially stating these are features, not bugs.

Oct 3, 2020 - I did some further testing/research and sent a reply to LogMeIn appealing the position they voiced on Sep 30.

Oct 13, 2020 - LogMeIn still hasn't replied to my Oct 3 email.