GoTo - LogmeIn - Hamachi Security Update

[AGTDenton]

You may want to read the following Blog post for information on the breach as well as an update posted on the 23rd Jan
https://www.goto.com/blog/our-respon...urity-incident

However, an Email came through today which similar to the blog post has better information, as far as I could tell this wasn't on the website.

Dear Customer,

I am writing to update you on our ongoing investigation about the security incident we told you about in November 2022.

Our investigation to date has determined that a threat actor exfiltrated encrypted backups related to Hamachi from a third-party cloud storage facility. In addition, we have evidence that a threat actor also exfiltrated an encryption key for a portion of the encrypted data. However, as part of our security protocols, we salt and hash Hamachi account passwords. This provides an additional layer of security within the encrypted backups.

Recommended Actions
Out of an abundance of caution, we are resetting your Hamachi password. If you use Multi-Factor Authentication to sign into your Hamachi account, you may be prompted to update your Multi-Factor Authentication settings during this process.

As an additional step to protect you, your account will automatically be migrated to GoTo’s enhanced Identity Management Platform as part of your password reset. This platform provides additional security for your users with more robust authentication and login-based security options, including enhanced controls, stronger password requirements, and a Single Sign-On option to access multiple GoTo (LogMeIn) products. Note: all users who have reset their password since December 12 have already been moved to the new platform and do not need to take this action. Additional guidance can be found here.

What information was affected
The information in the affected backups include your Hamachi account usernames and salted and hashed passwords. It also includes your deployment and provisioning information, some Multi-Factor Authentication information, licensing and purchasing data such as user emails, phone numbers, billing addresses, and the last four digits of credit card numbers (we do not store full credit card or bank details).

Based on our investigation to date, we continue to believe that the threat actor did not have access to GoTo’s production systems. Furthermore, Hamachi’s peer-to-peer technology and end-to-end encryption provide security against interception and eavesdropping of data transferred during remote sessions. Your session data in transit is always protected by Transport Layer Security (TLS) 1.2.

While the investigation is ongoing, we wanted to provide this important update to you, and recommend clear and actionable steps in response to what we have learned. We are committed to protecting you, your information, and the security of our products and will continue to update you. If you have any additional questions, please contact customer support.

Paddy Srinivasan
CEO, GoTo (formerly LogMeIn)

[Saracen999]

Our investigation to date has determined that a threat actor exfiltrated encrypted backups related to Hamachi from a third-party cloud storage facility. In addition, we have evidence that a threat actor also exfiltrated an encryption key for a portion of the encrypted data. ...

Hmmm.

Is it just me, or is the "third-party cloud storage facility" thing a bit of a worry?

I mean, I entrust my data to company A and, never mind their "layers" is isn't with the expectation that they promptly farm it off somewehere else. Who then get turned over.

Nothing nvolving computers is ever or can be 100% risk-free and, to my mind, it's rather a case of picking your risk. For example :-

- "Expert" hosting => they know hw to set stuff up properly, but also provide a tempting juicy target

- DIY hosting => you probably aren't as god at settng up security, but also, are a far less tempting target that most "treat actors" won't even know exists, and wouldn't bother with anyway.

That's simplistic, but you'll get my drift.

It's incidents like that, cumulating in that one, that led me to decide to go entirely home-brew and dump online password managers ... which fortunately (IMHO) I had only dipped my toes into temtatively (with LogMeIn) and nothing on there much mattered. The upshot was, I went DIY with an apparently good but 100% local solution, the biggest layer of protection being that "threat actors" have to find it to compromise it.

Not risk free, I agree, but the risk profile suits me much better, especially given that I don't want or need multi-person or multi-device access from any remote locations.

[DanceswithUnix]

Hmmm.

Is it just me, or is the "third-party cloud storage facility" thing a bit of a worry?

The storage, not really. The key escaping is the problem.

If the backups are encrypted, then all the attacker should have is a lot of random bytes to look at. That seems like a much harder target that the usual hashed password list, where you known plenty about the properties of the original data (plaintext password) and the sort of operations involved, and the size of the data is small enough that you can have thousands of copies in a GPU for parallel attacks.

So in this case, say you grab the first block of data, come up with something which you feel will detect a successful decrypt, and then start running keys against it. You guess it is encrypted with AES256, so you have 2^256 keys to try. If you can run a million attempts per second, I make that about 3x10^64 years worst case, half that time on average. But your success detector might be wrong, and you might have guessed the wrong encryption standard. You wouldn't even try.

But they leaked a key, which is unfortunate, and at that point it doesn't matter if the data was in cloud or on prem it's toast. At least it sounds like they followed the golden rule of "one key for one use" so only that one lump of data is compromised.

[Saracen999]

Well, if I were a cloud storage user (and as you probaby remember, I'm not), one of my criteria for selecting a 'provider' would be "Do I trust XYZ Ltd?"

I might decide (random choices, as an example) -

- Backblaze = Yes
- Google = No.

I'd then be more than a tad miffed if I found Backblaze had shipped the data out to, in that example, Google, to actually house. I suppose a lot depends on what they mean by "third party". Hell, I could rent a £10/month virtual server and become a third-party storage provider. We all gotta start somewhere. Better yet, stick an external HD on the USB port on my router, and save the £10/month.

Also, personally (and I assume anyone else with an IQ about a cactus) would personally encrypt the wotsit out of any sensitive data and only upload that encrypted version to the cloud in the first place. What an individual defines as "sensitive data", is, of course, subjective. But half the point of uploading to the cloud (fr me, if I did it) is as a quick and easy (even automatic) backup for data that you really can't afford to lose, so is likely to be sensitive.

Then again, some people seem to think the world is fascinated by phots of their cat napping, or the pizza they had fr dinner last Thursday, so there's that, of course.

Yeah, okay, I'm citing an .... erm .... ridiculous extreme or two BUT, the point remains the same - I entrusted my data to XYZ Limited, not some random and unknown-to-me third party.

If I were to uplad to the cloud, it would certainly be encrypted HERE, with a key not in the dir to be uploaded, and a complex key too. But even I'm not totally sure I wouldn't make some basic goof in encrypting stuff securely, and I'm reasonaby technical - technical enough to have been usig PGP encryption on email about, oh 30 years ago, and managed to get my own security certificates into Windows on my machines. But I'm also no security expert. I wonder how a non-technical user would do ensuring their own data was encrypted before upload?