5 ms·

Robinhood announces data security incident

137 points by marc__1 5y ago

emreb 5y ago
"The unauthorized party socially engineered a customer support employee by phone and obtained access to certain customer support systems." I guess the customer support system was open to the internet. In this day an age, how do you properly do perimeter fencing (as well as zero trust) for SaaS software?
- bink 5y ago
  I'm not sure this is saying they stole credentials and used them from outside the customer support rep's computer. It could be that they tricked the support rep into installing malware and followed them into the systems.
- nyxaiur 5y ago
  You can't move fast and break things with fences around.
- nijave 5y ago
  2FA with hard tokens seems common. There's also authenticating gateways/proxies and SASE products
  - jimmydorry 5y ago
    2FA doesn't seem like a golden bullet here, where if I understand the attack vector correctly, the malicious party convinced support to grant them access (presumably since they claimed to be working from home). If they issued 2FA hard tokens, the attacker would have to wait a few days for them to arrive, but they would be allowed in all the same.
    - doubled112 5y ago
      I'm mostly playing devil's advocate, but there could definitely be a process around that 2FA token that isn't there for a password reset. Verifying the employee's mailing address vs just replying to them over the phone or email sounds like a hurdle. Might not be the same person shipping out the token, so now you have to prove it to two people. Blockers like that.
    - omegalulw 5y ago
      > If they issued 2FA hard tokens, the attacker would have to wait a few days for them to arrive, but they would be allowed in all the same. Nope. You won't ship keys to some random address - you will do it to the address on file. Presumably, changing address on file would be guarded by rigorous processes.
      - jimmydorry 5y ago
        Much like giving keys to the kingdom (access to internal systems) was guarded by a rigorous process. xD
- jimmydorry 5y ago
  Good question. In the COVID-19 age and WFH era, companies should consider adding support policies that require visual identification (video call with photo ID on company file to compare against) as a bare minimum for giving someone remote access via support ticket.
  - mam4 5y ago
    and then, the deepfakes
  - ljm 5y ago
    Companies should keep their critical infra behind their own VPN as much as they possibly can and for the things that can't be VPN'd, use an SSO with strong MFA support. Especially for remote work - any critical or internal infra should be behind a company-operated VPN, with the VPN-access gated by MFA. It's obviously not foolproof because the more SaaS you add, the more vulnerable you are, especially because security in HN-land is something you only worry about after-the-fact because it's not MVP or quick to market. But asking for more personal info is perhaps the worst possible conclusion you could take from this. At some point you have to stop asking your users to take responsibility for your own shoddy security.
    - wil421 5y ago
      Bingo. The company I work for even gives certain locales, that are prone to IP theft, VDI only access to company systems. They are given a laptop with nothing on it except tools to access the VPN and VDI.
      - niros_valtos 5y ago
        When security impacts productivity it becomes a difficult battle. Zero trust tries to solve the VPN requirement, but as we all know, the devil is in the implementation details…
    - sofixa 5y ago
      Zero trust has been gaining more and more popularity over the traditional hiding behind a VPN and trusting everything behind it. A VPN, if there's one ( it's still useful and avoids unauthenticated exploits on software), should be the first line of defence.
- api 5y ago
  Defense in depth. Put it on something like ZeroTier, but still secure it with hard key 2FA as if it's on the open Internet. The key is always to make an attacker jump over more than one hurdle to get to anything. It's preferable if those hurdles are as isolated from one another as possible: different systems, different vendors, administrated by different people (multiple social engineering points), etc. BTW I personally dislike this trend of trusting a single third party 2FA provider for access control to every system. It's incredibly convenient but it gives me the wim-wams. I'm waiting for a story like "Okta announces compromise, tens of thousands of sites may be at risk..." Never trust just one thing no matter what that one thing is.
- wil421 5y ago
  The customer support systems we run do not have local logins and we use SSO and an identity provider that is only accessible on our company VPN. Other safeguards apply as well. Since the company sells banking software and payment systems account numbers, cc numbers, and other identifiers are put into “sensitive” fields that are encrypted on our SaaS providers servers. We have a proxy server that decrypts the data in transit at our networks edge. Even the SaaS provider doesn’t have the keys to see these types of fields.
- ryanar 5y ago
  One solution is to integrate with one of the up-and-coming zero trust products. This is a new space that was started by the company I work for strongDM, and there are a number of startups competing in this space. I would highly recommend looking into it if you want to be more secure than a VPN's model of once you are inside the wall you are trusted.
dzader 5y ago
robinhood continues to show their utter incompetence
twirlock 5y ago
I have no faith whatsoever that they would be forthcoming about the extent of any breach.
toomuchtodo 5y ago
“At this time, we understand that the unauthorized party obtained a list of email addresses for approximately five million people, and full names for a different group of approximately two million people. We also believe that for a more limited number of people—approximately 310 in total—additional personal information, including name, date of birth, and zip code, was exposed, with a subset of approximately 10 customers having more extensive account details revealed. We are in the process of making appropriate disclosures to affected people.”
- potamic 5y ago
  Looks like this is a very rudimentary miss in the processes. I wonder, wouldn't these guys be audited before they are allowed to operate? And if so, would the auditors be liable for anything for not catching such a trivial thing in the process?
klee0102 5y ago
How exactly can a customer support be tricked and then hown did a support can give out access to the customers data? The fancy language used add more questions than answers.
- iso1210 5y ago
  How exactly can anyone, no matter what the credentials, access 5 million records?
  - toomuchtodo 5y ago
    Lax controls and incentives. There will be no repercussions to Robinhood from this event, so there is no incentive to build robust controls in their systems.
argsv 5y ago
I don't trust the first release or the first disclosure. I expect Robinhood in the next few days to disclose that the exposure was wider and more serious than initially thought. It also seems that they don't encrypt social security numbers and other sensitive data; I imagine if they did they would have mentioned it. Their track record isn't that of a company to be trusted.
- throwawaysea 5y ago
  > It also seems that they don't encrypt social security numbers and other sensitive data; I imagine if they did they would have mentioned it. That's really scary and feels like it is more than basic in 2021. I really wish we had legislation to protect users against this type of stuff, or at least to grant them some avenue for compensation.
- runnerup 5y ago
  What's the point of encrypting SSN's? There's only a billion naive permutations..much less if you eliminate "impossible" ones like the SSN prefixes reserved for children of railroad workers. Even if you add a unique salt for each account, brute forcing the hashes wouldn't take very long, assuming the salt was leaked (and most of the time the salt for each account would be in these dumps). Brute forcing this order of difficulty was considered "done" around 2014 for SHA-1. I suppose you could add enormous number of recursive hashes or an immensely expensive parameter selection for bcrypt. But I feel most realworld implementations of hashed SSN would be only little better than plaintext.
  - iso1210 5y ago
    Hashing SSN (or credit card info) is pretty pointless. Encrypting it however is important. Obviously if you lose the key you're stuck, but then people don't need to know the key, it should be behind an API. The service which provides the decoding for a given encrypted record to an authenticated user should provide it, and audit it, and have rate limits. Even if the database leaks, it's encrypted, if the credentials to someone who needs access to that SSN are stolen, you could only use it a few times a day to avoid flagging up as unusual activity.
twalla 5y ago
For anyone still using Robinhood: it's incredibly easy to file an ACATS with another, more reputable broker - depending on the broker and how much you're transferring, the 70 dollar fee is often waived. I've been very happy with Fidelity since the whole GME debacle.

137 points by marc__1 5y ago

"The unauthorized party socially engineered a customer support employee by phone and obtained access to certain customer support systems." I guess the customer support system was open to the internet. In this day an age, how do you properly do perimeter fencing (as well as zero trust) for SaaS software?

bink 5y ago
I'm not sure this is saying they stole credentials and used them from outside the customer support rep's computer. It could be that they tricked the support rep into installing malware and followed them into the systems.
nyxaiur 5y ago
You can't move fast and break things with fences around.
nijave 5y ago
2FA with hard tokens seems common. There's also authenticating gateways/proxies and SASE products
- jimmydorry 5y ago
  2FA doesn't seem like a golden bullet here, where if I understand the attack vector correctly, the malicious party convinced support to grant them access (presumably since they claimed to be working from home). If they issued 2FA hard tokens, the attacker would have to wait a few days for them to arrive, but they would be allowed in all the same.
  - doubled112 5y ago
    I'm mostly playing devil's advocate, but there could definitely be a process around that 2FA token that isn't there for a password reset. Verifying the employee's mailing address vs just replying to them over the phone or email sounds like a hurdle. Might not be the same person shipping out the token, so now you have to prove it to two people. Blockers like that.
  - omegalulw 5y ago
    > If they issued 2FA hard tokens, the attacker would have to wait a few days for them to arrive, but they would be allowed in all the same. Nope. You won't ship keys to some random address - you will do it to the address on file. Presumably, changing address on file would be guarded by rigorous processes.
    - jimmydorry 5y ago
      Much like giving keys to the kingdom (access to internal systems) was guarded by a rigorous process. xD
jimmydorry 5y ago
Good question. In the COVID-19 age and WFH era, companies should consider adding support policies that require visual identification (video call with photo ID on company file to compare against) as a bare minimum for giving someone remote access via support ticket.
- mam4 5y ago
  and then, the deepfakes
- ljm 5y ago
  Companies should keep their critical infra behind their own VPN as much as they possibly can and for the things that can't be VPN'd, use an SSO with strong MFA support. Especially for remote work - any critical or internal infra should be behind a company-operated VPN, with the VPN-access gated by MFA. It's obviously not foolproof because the more SaaS you add, the more vulnerable you are, especially because security in HN-land is something you only worry about after-the-fact because it's not MVP or quick to market. But asking for more personal info is perhaps the worst possible conclusion you could take from this. At some point you have to stop asking your users to take responsibility for your own shoddy security.
  - wil421 5y ago
    Bingo. The company I work for even gives certain locales, that are prone to IP theft, VDI only access to company systems. They are given a laptop with nothing on it except tools to access the VPN and VDI.
    - niros_valtos 5y ago
      When security impacts productivity it becomes a difficult battle. Zero trust tries to solve the VPN requirement, but as we all know, the devil is in the implementation details…
  - sofixa 5y ago
    Zero trust has been gaining more and more popularity over the traditional hiding behind a VPN and trusting everything behind it. A VPN, if there's one ( it's still useful and avoids unauthenticated exploits on software), should be the first line of defence.
api 5y ago
Defense in depth. Put it on something like ZeroTier, but still secure it with hard key 2FA as if it's on the open Internet. The key is always to make an attacker jump over more than one hurdle to get to anything. It's preferable if those hurdles are as isolated from one another as possible: different systems, different vendors, administrated by different people (multiple social engineering points), etc. BTW I personally dislike this trend of trusting a single third party 2FA provider for access control to every system. It's incredibly convenient but it gives me the wim-wams. I'm waiting for a story like "Okta announces compromise, tens of thousands of sites may be at risk..." Never trust just one thing no matter what that one thing is.
wil421 5y ago
The customer support systems we run do not have local logins and we use SSO and an identity provider that is only accessible on our company VPN. Other safeguards apply as well. Since the company sells banking software and payment systems account numbers, cc numbers, and other identifiers are put into “sensitive” fields that are encrypted on our SaaS providers servers. We have a proxy server that decrypts the data in transit at our networks edge. Even the SaaS provider doesn’t have the keys to see these types of fields.
ryanar 5y ago
One solution is to integrate with one of the up-and-coming zero trust products. This is a new space that was started by the company I work for strongDM, and there are a number of startups competing in this space. I would highly recommend looking into it if you want to be more secure than a VPN's model of once you are inside the wall you are trusted.

dzader 5y ago

robinhood continues to show their utter incompetence

twirlock 5y ago

I have no faith whatsoever that they would be forthcoming about the extent of any breach.

toomuchtodo 5y ago

“At this time, we understand that the unauthorized party obtained a list of email addresses for approximately five million people, and full names for a different group of approximately two million people. We also believe that for a more limited number of people—approximately 310 in total—additional personal information, including name, date of birth, and zip code, was exposed, with a subset of approximately 10 customers having more extensive account details revealed. We are in the process of making appropriate disclosures to affected people.”

potamic 5y ago
Looks like this is a very rudimentary miss in the processes. I wonder, wouldn't these guys be audited before they are allowed to operate? And if so, would the auditors be liable for anything for not catching such a trivial thing in the process?

klee0102 5y ago

How exactly can a customer support be tricked and then hown did a support can give out access to the customers data? The fancy language used add more questions than answers.

iso1210 5y ago
How exactly can anyone, no matter what the credentials, access 5 million records?
- toomuchtodo 5y ago
  Lax controls and incentives. There will be no repercussions to Robinhood from this event, so there is no incentive to build robust controls in their systems.

argsv 5y ago

I don't trust the first release or the first disclosure. I expect Robinhood in the next few days to disclose that the exposure was wider and more serious than initially thought. It also seems that they don't encrypt social security numbers and other sensitive data; I imagine if they did they would have mentioned it. Their track record isn't that of a company to be trusted.

throwawaysea 5y ago
> It also seems that they don't encrypt social security numbers and other sensitive data; I imagine if they did they would have mentioned it. That's really scary and feels like it is more than basic in 2021. I really wish we had legislation to protect users against this type of stuff, or at least to grant them some avenue for compensation.
runnerup 5y ago
What's the point of encrypting SSN's? There's only a billion naive permutations..much less if you eliminate "impossible" ones like the SSN prefixes reserved for children of railroad workers. Even if you add a unique salt for each account, brute forcing the hashes wouldn't take very long, assuming the salt was leaked (and most of the time the salt for each account would be in these dumps). Brute forcing this order of difficulty was considered "done" around 2014 for SHA-1. I suppose you could add enormous number of recursive hashes or an immensely expensive parameter selection for bcrypt. But I feel most realworld implementations of hashed SSN would be only little better than plaintext.
- iso1210 5y ago
  Hashing SSN (or credit card info) is pretty pointless. Encrypting it however is important. Obviously if you lose the key you're stuck, but then people don't need to know the key, it should be behind an API. The service which provides the decoding for a given encrypted record to an authenticated user should provide it, and audit it, and have rate limits. Even if the database leaks, it's encrypted, if the credentials to someone who needs access to that SSN are stolen, you could only use it a few times a day to avoid flagging up as unusual activity.

twalla 5y ago

For anyone still using Robinhood: it's incredibly easy to file an ACATS with another, more reputable broker - depending on the broker and how much you're transferring, the 70 dollar fee is often waived. I've been very happy with Fidelity since the whole GME debacle.