Customer cloud backups stolen together with decryption key – Naked Security

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 administration and support), or LastPass (a password management service), you’ve used a product from the GoTo stable.

You probably haven’t forgotten the big cybersecurity story over the Christmas 2022 holiday, when LastPass admitted 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 after a breach in the LastPass development network, but not customer data.

But the data seized in that source code heist turned out to include enough information for attackers to follow up with a breach of a LastPass cloud storage service where customer data was actually stolen, ironically including encrypted password vaults.

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

Security incident

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

Based on the investigation so far, we have detected unusual activity in 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 brief at the time, sounds strangely similar to the one that unfolded from August 2022 to December 2022 at LastPass: development network breached; customer storage broken; investigation underway.

Nevertheless, given that the statement expressly notes that the cloud service was shared between LastPass and GoTo, while implying that the development network mentioned here was not, we must assume that this breach did not start months earlier in LastPass’s development system.

The suggestion seems to be that in the GoTo breach, the development network and the cloud service were breached at the same time, as if this was a single breach that yielded two targets at once, unlike the LastPass scenario where the cloudburst was a later consequence of the first.

Event Update

Two months later, GoTo is 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,, 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, part of the Multi-Factor Authentication (MFA) settings, and some product settings and license information.

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

Two things are confusingly unclear here: first, why were MFA settings stored encrypted for one set of clients but not for others; and secondly, what do the words “MFA settings” even include?

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

  • Telephone numbers used to send 2FA codes.
  • Starting seeds for app-based 2FA code sequences.
  • Stored recovery codes for use in an emergency.

SIM exchange and start seeds

Obviously, leaked phone numbers directly linked to the 2FA process represent convenient targets for crooks who already know your username and password but can’t get past your 2FA protection.

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

If that happens, not only will they receive the 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’ll likely miss out on any . warnings or indicators that might otherwise have led you to the attack.

Starter seeds for app-based 2FA code generators are even more useful to attackers because the seed alone determines the sequence of numbers displayed on your phone.

These magic six-digit numbers (they can be longer, but six is ​​normal) are calculated by hashing the current Unix epoch time, rounded down to the start of the most recent 30-second window, using the starting value, typically a randomly-chosen 160 -bit (20-byte) number, as a cryptographic key.

Anyone with a cell phone or a GPS receiver can reliably determine the current time within milliseconds, let alone to the nearest 30 seconds, so the seed seed is all that stands between a crook and your own personal code stream.

Lua code showing how to generate a TOTP (time-based one-time password) code from a 160-bit sequence seed.

Likewise, stored recovery codes (most services only let you keep a few valid at a time, typically five or ten, but one might be enough) will also almost certainly get an attacker past your 2FA defenses.

Of course, we can’t be sure that any of this data was included in the missing “MFA settings” the crooks stole, but we wish GoTo had been more forthcoming about what was involved in that part of the breach.

How much salting and stretching?

Another detail we recommend you include if you are ever caught in a data breach of this nature is exactly how any salted and hashed passwords were actually created.

This will help your customers assess how quickly they need to get through all the now-inevitable password changes they have to make, because the strength of the hash-and-salt process (more precisely, we hope, salt-hash -and -stretch process) determines how quickly the attackers can figure out your passwords from the stolen data.

Technically, hash passwords are generally not cracked by any cryptographic trick that “reverses” the hash. A decently chosen hashing algorithm cannot be run backwards to reveal anything about its input. In practice, attackers simply try out an enormously long list of possible passwords, with the aim of trying very likely ones in advance (e.g. pa55word), to select moderately likely next (e.g strAT0spher1C), and to leave the least likely as long as possible (e.g 44y3VL7C5%TJCF-KGJP3qLL5). When choosing a password hashing system, don’t invent your own. Look at well-known algorithms like PBKDF2, bcrypt, scrypt and Argon2. Follow the algorithm’s own guidelines for salting and stretching parameters that provide good resistance to password-list attacks. Consult with Serious security article above for expert advice.

What to do?

GoTo has admitted that the crooks have had at least some users’ account names, password hashes and an unknown set of “MFA settings” since at least late November 2022, close to two months ago.

There is also the possibility, despite our assumption above that this was a brand new breach, that this attack may turn out to have a common antecedent going back to the original LastPass breach in August 2022, so the attackers may have been in the network for even longer than two months before this latest breach announcement was made public.

So we suggest:

  • Change all passwords in your company that relate to the above services. If you’ve taken password risks in the past, such as choosing short and guessable words or sharing passwords between accounts, stop.
  • Reset all app-based 2FA passcodes that you use on your accounts. Doing this means that if any of your 2FA seeds were stolen, they become useless to the bad guys.
  • Regenerates new backup codes, if you have any. Previously issued codes should be automatically invalidated at the same time.
  • Consider switching to app-based 2FA codes if you can, provided you are currently using text message (SMS) authentication. It’s easier to revisit a code-based 2FA sequence if needed than it is to get a new phone number.


Leave a Reply

Your email address will not be published. Required fields are marked *