GoTo admits: Customer cloud backups stolen together with decryption key

[Firefox]

Source: GoTo admits: Customer cloud backups stolen together with decryption key

 

Quote

GoTo is a well-known brand that owns a range of products, including technologies for teleconferencing and webinars, remote access, and password management.

If you’ve ever used GoTo Webinar (online meetings and seminars), GoToMyPC (connect and control someone else’s computer for management and support), or LastPass (a password manangement service), you’ve used a product from the GoTo stable.

You’ve probably not forgotten the big cybersecurity story over the 2022 Christmas holiday season, when LastPass admitted that it had suffered a breach that was much more serious than it had first thought.

The company first reported, back in August 2022, that crooks had stolen proprietary source code, following a break-in into the LastPass development network, but not customer data.

But the data grabbed in that source code robbery turned out to include enough information for attackers to follow up with a break-in at a LastPass cloud storage service, where customer data was indeed stolen, ironically including encrypted password vaults.

Now, unfortunately, it’s parent company GoTo’s turn to admit to a breach of its own – and this one also involves a development network break-in.

Security incident

On 2022-11-30, GoTo informed customers that it had suffered “a security incident”, summarising the situation as follows:

Based on the investigation to date, we have detected unusual activity within our development environment and third-party cloud storage service. The third-party cloud storage service is currently shared by both GoTo and its affiliate, LastPass.

This story, so briefly told at the time, sounds curiously similar to the one that unfolded from August 2022 to December 2022 at LastPass: development network breached; customer storage breached; investigation ongoing.

Nevertheless, we have to assume, given that the statement explicitly notes that the cloud service was shared between LastPass and GoTo, while implying that the development network mentioned here wasn’t, that this breach didn’t start months earlier in LastPass’s development system.

The suggestion seems to be that, in the GoTo breach, the development network and cloud service intrusions happened at the same time, as though this was a single break-in that yielded two targets right away, unlike the LastPass scenario, where the cloud breach was a later consequence of the first.

Incident update

Two months later, GoTo has come back with an update, and the news isn’t great:

[A] threat actor exfiltrated encrypted backups from a third-party cloud storage service related to the following products: Central, Pro, join.me, Hamachi, and RemotelyAnywhere. We also have evidence that a threat actor exfiltrated an encryption key for a portion of the encrypted backups. The affected information, which varies by product, may include account usernames, salted and hashed passwords, a portion of Multi-Factor Authentication (MFA) settings, as well as some product settings and licensing information.

The company also noted that although MFA settings for some Rescue and GoToMyPC customers were stolen, their encrypted databases were not.

Two things are confusingly unclear here: firstly, why were MFA settings stored encrypted for one set of customers, but not for others; and secondly, what do the words “MFA settings” encompass anyway?

Several possible important “MFA settings” come to mind, including one or more of:

• Phone numbers used for sending 2FA codes.
• Starting seeds for app-based 2FA code sequences.
• Stored recovery codes for use in emergencies.

SIM swaps and starting seeds

Clearly, leaked telephone numbers that are directly linked to the 2FA process represent handy targets for crooks who already know your username and password, but can’t get past your 2FA protection.

If the crooks are certain of the number to which your 2FA codes are being sent, they may be inclined to try for a SIM swap, where they trick, cajole or bribe a mobile phone company staffer into issuing them a “replacement” SIM card that has your number assigned to it.

If that happens, not only will they receive the very next 2FA code for your account on their phone, but your phone will go dead (because a number can only be assigned to one SIM at a time), so you are likely to miss any alerts or telltales that might otherwise have clued you in to the attack

 

Edited January 27, 2023 by Firefox