August 2016 Incident

#1

Post by marcins » Tue, Aug 30, 2016, 11:07 PM UTC

August 2016 Incident
onelogin.com

Re: August 2016 Incident

#2

Post by tinco » Tue, Aug 30, 2016, 11:36 PM UTC

So.. they send data to their servers unencrypted? That's a serious design flaw right there. That they do any encryption (besides HTTPS) server side should be a red flag for any secrets store.

Re: August 2016 Incident

#3

Post by runesoerensen » Tue, Aug 30, 2016, 11:41 PM UTC

tinco wrote: post #2

So.. they send data to their servers unencrypted? That's a serious design flaw right there. That they do any encryption (besides HTTPS) server side should be a red flag for any secrets store.

Seems more likely that they use HTTPS and this is "just" an issue with cleartext logging (i.e. some server component logs unencrypted data after TLS termination).

Re: August 2016 Incident

#4

Post by tomschlick » Tue, Aug 30, 2016, 11:43 PM UTC

runesoerensen wrote: post #3

tinco wrote: post #2

So.. they send data to their servers unencrypted? That's a serious design flaw right there. That they do any encryption (besides HTTPS) server side should be a red flag for any secrets store.

Seems more likely that they use HTTPS and this is "just" an issue with cleartext logging (i.e. some server component logs unencrypted data after TLS termination).

I think OP is referring to client side encryption instead of encrypting it on the server for storage.

Re: August 2016 Incident

#5

Post by cheeze » Tue, Aug 30, 2016, 11:43 PM UTC

tinco wrote: post #2

So.. they send data to their servers unencrypted? That's a serious design flaw right there. That they do any encryption (besides HTTPS) server side should be a red flag for any secrets store.

Agreed 100%. With something like LastPass, they never actually have your enencrypted data at any point. So a logging bug (probably somebody logging the payload, etc. accidentally) wouldn't matter.

This is really concerning for a company that offers IAM as a service. IMO this is straight up incompetence.

Re: August 2016 Incident

#6

Post by runesoerensen » Tue, Aug 30, 2016, 11:47 PM UTC

tomschlick wrote: post #4

runesoerensen wrote: post #3

Earlier quoted context omitted.

Seems more likely that they use HTTPS and this is "just" an issue with cleartext logging (i.e. some server component logs unencrypted data after TLS termination).

I think OP is referring to client side encryption instead of encrypting it on the server for storage.

You're right, that makes more sense

Re: August 2016 Incident

#7

Post by bsamuels » Tue, Aug 30, 2016, 11:55 PM UTC

> multiple levels of AES-256 encryption.

crypto cringe - this instills just as much confidence as saying "WE USE MILITARY GRADE ENCRYPTION PROTOCOLS"

Re: August 2016 Incident

#8

Post by mattvot » Tue, Aug 30, 2016, 11:59 PM UTC

Pet peeve of the day.

Tried to right click on the header logo so I can check out their main site in a new tab.

Instead I'm blocked and get prompted to download their brand assets...

Please don't mess with established interactions.

Re: August 2016 Incident

#9

Post by voxio » Wed, Aug 31, 2016, 12:04 AM UTC

I'd love to know which logging server they had exposed to the internet. Putting all infrastructure on a private network is security 101.

Re: August 2016 Incident

#10

Post by cyberferret » Wed, Aug 31, 2016, 12:09 AM UTC

voxio wrote: post #9

I'd love to know which logging server they had exposed to the internet. Putting all infrastructure on a private network is security 101.

That is my question too - how was an internal logging server not set for restricted login only from the internal subnet?

Also - they mentioned the perp got in via a compromised employee login. No clarification if it was a former disgruntled employee, or that a current employee had a weak password, or was social engineered into divulging it.

In any case, it points to bad internal policies and procedures around isolating servers and employee password management.