6 ms·

How we handled a recent phishing incident

71 points by lawgimenez 4y ago

mcdwayne 4y ago
Another take: https://blog.gitguardian.com/dropbox-breach-hack-github-circleci/ https://blog.gitguardian.com/dropbox-breach-hack-github-circ...
nokya 4y ago
Is there a version of this report somewhere without all the PR BS?
gilbertbw 4y ago
> The code and the data around it also included a few thousand names and email addresses belonging to Dropbox employees, current and past customers, sales leads, and vendors There isn't an explanation as to why customer, lead and vendor data is stored in GitHub? Or (less likely?) they allowed GitHub OAuth to log into other Dropbox internal services?
- dannyw 4y ago
  Probably an internal prototype that incorrectly stored PII in the repo (as a CSV, .sql, etc)
  - aliqot 4y ago
    That's the real story here.
    - blowski 4y ago
      Not really. Someone’s suggested a possible reason for something that was unclear in the original article. That’s hardly a story.
      - aliqot 4y ago
        It's a full story.
- jsty 4y ago
  My guess - issues tied to requested features from current & prospective customers, and bugs associated with specific vendors - all of which could plausibly lead to a bunch of (name, email) data points stored on GitHub
sdfhbdf 4y ago
> […] use their hardware authentication key to pass a One Time Password (OTP) to the malicious site. This eventually succeeded, […] It’s interesting that it succeeded, I was under the impression, making some assumptions that using a Hardware key like Yubikey would prevent such attack since the challenge-response in the browser communication with the key contains the domain (which I assume was different) and hence would fail to generate proper OTP for wrong domain. I assume they, or their vendor - CircleCI (which i haven’t used), had some older implementation of the standard that maybe relied just on the string generated by the hardware key without challenge-response. I’m glad they caught it and they immediately see WebAuthn as a good successor. This should definitely prevent such attack vector. Nice.
- jaywalk 4y ago
  I have to assume by "hardware authentication key" they're referring to RSA SecurID. Yubikey would indeed prevent an attack like this from working. Although I wouldn't expect a company like Dropbox to be using RSA SecurID.
  - jsty 4y ago
    > Yubikey would indeed prevent an attack like this from working. It would using U2F / WebAuthn. Some Yubikeys support generating TOTP codes [0], which would be vulnerable to phishing attacks [0] https://support.yubico.com/hc/en-us/articles/360013789259-Using-Your-YubiKey-with-Authenticator-Codes https://support.yubico.com/hc/en-us/articles/360013789259-Us...
computerfriend 4y ago
Storing API keys in Git, nice.
- not2b 4y ago
  Apparently this was a private repo, not a public one, but the attacker gained access.
  - shkkmo 4y ago
    It is still a very bad idea to store unencrypted keys in a private repository. You've now equated read access of your repository will whatever access that key has.
  - rtev 4y ago
    That doesn’t matter, best practice is storing them as variables that are injected upon deployment from a secret manager.
    - insanitybit 4y ago
      FWIW Dropbox had robust infrastructure to do exactly that when I was there as well as scanning for API keys in the main repository. Certainly product code is going to conform to the pattern you've described, this sounds to me like some of the random non-product projects that may hit some external non-dbx API were not doing things properly and it flew under the radar for whatever reason. I highly doubt these API keys could have been used for much. So yes, I agree with you, but here's some context. Disclaimer: I haven't worked there since 2019
- deleted 4y ago
  [deleted]
- bastawhiz 4y ago
  If it was GitHub and they were using GitHub auth for circleci, they could have gotten access to injected secrets. Or, if they used GitHub actions, it could have been actions environment variables. It isn't clear that keys were checked into source control.
dotBen 4y ago
Side note - proliferating the use of other top-level domains for official use (as they have done here for their tech blog) certainly doesn't help Dropbox's security envelope when it comes to phishing. "Access your new employee bonus plan here at HR's portal: dropbox.hr/phishinglink" etc... I don't know why big companies, especially, allow other domains to be used for official business.
- not2b 4y ago
  Yes, that's a big problem at my employer. So many functions have been contracted out that I have to deal with official functions via sites belonging to at least 15 outside companies, many for sensitive HR-related functions, expense reports, and purchasing. It's hard to keep track of all that, and makes it more likely that some employee will make a mistake.
  - dotBen 4y ago
    But it's just as easy to point a DNS record from hr.internal.dropbox.com or techblog.dropbox.com to trusted third party vendors as it is to set up a new domain, but the use of subdomains maintains the security model.
    - jefftk 4y ago
      In the standard way of configuring cookies, allowing third parties to use a subdomain of your domain lets them collect your HTTP_ONLY SECURE cookies and impersonate your users. The security policy at the FAANG I used to work at required third party vendor code to run on other domains for this reason.
- mdaEyebot 4y ago
  Microsoft is the worst about this. So many official domains containing at least one of "windows", "microsoft", "azure". I also regularly get XSS warning from the myriad login domains that they pass credentials through in their web portals. Sometimes I wonder how their services are set up to talk to each other, I'm sure it's a terrifying Gordian knot.
stack_underflow 4y ago
> This eventually succeeded, giving the threat actor access to one of our GitHub organizations where they proceeded to copy 130 of our code repositories. When I was at dropbox I saw quite a few devs provisioning non-mac laptops with their linux distro of choice. Always wondered what was stopping those people from just making a copy of rserver/rclient without IT/security noticing.
- insanitybit 4y ago
  There was an attempt to improve this situation but it got canned. That said, there actually weren't a ton of Linux laptops when I was there - relatively speaking, at least. We knew of them though. If you wanted linux on your laptop you'd have to do a bit more than just provision the laptop with it, I don't want to get too detailed but it ends up giving the security more insight into the device than you may imagine. Indeed, at the time I worked there, we likely would have been able to piece things together to see that between the 2FA logs, Github logs, netflow, etc. If you were in an office we could likely track down exactly where you were sitting based on that - we definitely had done so before during a red team exercise. Security has changed radically since my time there so I couldn't speak to what's possible now.
rtev 4y ago
Is it just me or does this kind of thing reek of a nation state? This feels like the Twilio breach where the suspected goal was access to Signal MFA codes for 15 minutes or whatever that was. Feels like it’s hyper-targeted as some kind of military operation.
- blaser-waffle 4y ago
  My thought was more like gmail getting hit by (likely) the Chinese in an attempt to get David Petraeus' email accounts, esp. the emails where he was sharing things he shouldn't w/ his mistress. Honestly if he kept it in his pants he probably could have been President.
sitereliability 4y ago
jbverschoor 4y ago
Can’t say I believe anything Dropbox says

71 points by lawgimenez 4y ago

Another take: https://blog.gitguardian.com/dropbox-breach-hack-github-circleci/ https://blog.gitguardian.com/dropbox-breach-hack-github-circ...

nokya 4y ago

Is there a version of this report somewhere without all the PR BS?

gilbertbw 4y ago

> The code and the data around it also included a few thousand names and email addresses belonging to Dropbox employees, current and past customers, sales leads, and vendors There isn't an explanation as to why customer, lead and vendor data is stored in GitHub? Or (less likely?) they allowed GitHub OAuth to log into other Dropbox internal services?

dannyw 4y ago
Probably an internal prototype that incorrectly stored PII in the repo (as a CSV, .sql, etc)
- aliqot 4y ago
  That's the real story here.
  - blowski 4y ago
    Not really. Someone’s suggested a possible reason for something that was unclear in the original article. That’s hardly a story.
    - aliqot 4y ago
      It's a full story.
jsty 4y ago
My guess - issues tied to requested features from current & prospective customers, and bugs associated with specific vendors - all of which could plausibly lead to a bunch of (name, email) data points stored on GitHub

sdfhbdf 4y ago

> […] use their hardware authentication key to pass a One Time Password (OTP) to the malicious site. This eventually succeeded, […] It’s interesting that it succeeded, I was under the impression, making some assumptions that using a Hardware key like Yubikey would prevent such attack since the challenge-response in the browser communication with the key contains the domain (which I assume was different) and hence would fail to generate proper OTP for wrong domain. I assume they, or their vendor - CircleCI (which i haven’t used), had some older implementation of the standard that maybe relied just on the string generated by the hardware key without challenge-response. I’m glad they caught it and they immediately see WebAuthn as a good successor. This should definitely prevent such attack vector. Nice.

jaywalk 4y ago
I have to assume by "hardware authentication key" they're referring to RSA SecurID. Yubikey would indeed prevent an attack like this from working. Although I wouldn't expect a company like Dropbox to be using RSA SecurID.
- jsty 4y ago
  > Yubikey would indeed prevent an attack like this from working. It would using U2F / WebAuthn. Some Yubikeys support generating TOTP codes [0], which would be vulnerable to phishing attacks [0] https://support.yubico.com/hc/en-us/articles/360013789259-Using-Your-YubiKey-with-Authenticator-Codes https://support.yubico.com/hc/en-us/articles/360013789259-Us...

computerfriend 4y ago

Storing API keys in Git, nice.

not2b 4y ago
Apparently this was a private repo, not a public one, but the attacker gained access.
- shkkmo 4y ago
  It is still a very bad idea to store unencrypted keys in a private repository. You've now equated read access of your repository will whatever access that key has.
- rtev 4y ago
  That doesn’t matter, best practice is storing them as variables that are injected upon deployment from a secret manager.
  - insanitybit 4y ago
    FWIW Dropbox had robust infrastructure to do exactly that when I was there as well as scanning for API keys in the main repository. Certainly product code is going to conform to the pattern you've described, this sounds to me like some of the random non-product projects that may hit some external non-dbx API were not doing things properly and it flew under the radar for whatever reason. I highly doubt these API keys could have been used for much. So yes, I agree with you, but here's some context. Disclaimer: I haven't worked there since 2019
deleted 4y ago
[deleted]
bastawhiz 4y ago
If it was GitHub and they were using GitHub auth for circleci, they could have gotten access to injected secrets. Or, if they used GitHub actions, it could have been actions environment variables. It isn't clear that keys were checked into source control.

dotBen 4y ago

Side note - proliferating the use of other top-level domains for official use (as they have done here for their tech blog) certainly doesn't help Dropbox's security envelope when it comes to phishing. "Access your new employee bonus plan here at HR's portal: dropbox.hr/phishinglink" etc... I don't know why big companies, especially, allow other domains to be used for official business.

not2b 4y ago
Yes, that's a big problem at my employer. So many functions have been contracted out that I have to deal with official functions via sites belonging to at least 15 outside companies, many for sensitive HR-related functions, expense reports, and purchasing. It's hard to keep track of all that, and makes it more likely that some employee will make a mistake.
- dotBen 4y ago
  But it's just as easy to point a DNS record from hr.internal.dropbox.com or techblog.dropbox.com to trusted third party vendors as it is to set up a new domain, but the use of subdomains maintains the security model.
  - jefftk 4y ago
    In the standard way of configuring cookies, allowing third parties to use a subdomain of your domain lets them collect your HTTP_ONLY SECURE cookies and impersonate your users. The security policy at the FAANG I used to work at required third party vendor code to run on other domains for this reason.
mdaEyebot 4y ago
Microsoft is the worst about this. So many official domains containing at least one of "windows", "microsoft", "azure". I also regularly get XSS warning from the myriad login domains that they pass credentials through in their web portals. Sometimes I wonder how their services are set up to talk to each other, I'm sure it's a terrifying Gordian knot.

stack_underflow 4y ago

> This eventually succeeded, giving the threat actor access to one of our GitHub organizations where they proceeded to copy 130 of our code repositories. When I was at dropbox I saw quite a few devs provisioning non-mac laptops with their linux distro of choice. Always wondered what was stopping those people from just making a copy of rserver/rclient without IT/security noticing.

insanitybit 4y ago
There was an attempt to improve this situation but it got canned. That said, there actually weren't a ton of Linux laptops when I was there - relatively speaking, at least. We knew of them though. If you wanted linux on your laptop you'd have to do a bit more than just provision the laptop with it, I don't want to get too detailed but it ends up giving the security more insight into the device than you may imagine. Indeed, at the time I worked there, we likely would have been able to piece things together to see that between the 2FA logs, Github logs, netflow, etc. If you were in an office we could likely track down exactly where you were sitting based on that - we definitely had done so before during a red team exercise. Security has changed radically since my time there so I couldn't speak to what's possible now.

rtev 4y ago

Is it just me or does this kind of thing reek of a nation state? This feels like the Twilio breach where the suspected goal was access to Signal MFA codes for 15 minutes or whatever that was. Feels like it’s hyper-targeted as some kind of military operation.

blaser-waffle 4y ago
My thought was more like gmail getting hit by (likely) the Chinese in an attempt to get David Petraeus' email accounts, esp. the emails where he was sharing things he shouldn't w/ his mistress. Honestly if he kept it in his pants he probably could have been President.

sitereliability 4y ago

jbverschoor 4y ago

Can’t say I believe anything Dropbox says