How we handled a recent phishing incident | Hacker News Reader

How we handled a recent phishing incident

dropbox.tech

71 pointslawgimenez42 comments

> 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?

Probably an internal prototype that incorrectly stored PII in the repo (as a CSV, .sql, etc)

That's the real story here.

Not really. Someone’s suggested a possible reason for something that was unclear in the original article. That’s hardly a story.

It's a full story.

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

> […] 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.

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.

> 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-Us...

Storing API keys in Git, nice.

Apparently this was a private repo, not a public one, but the attacker gained access.

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.

That doesn’t matter, best practice is storing them as variables that are injected upon deployment from a secret manager.

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

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.

> 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.

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.

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.

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.

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

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

Can’t say I believe anything Dropbox says

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.

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.

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.

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.

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.

The domains mess at Microsoft is truly hilarious. MS Edge browser fetches some updates from something.skype.com IIRC.

And the crazy part are all the redirects that happen, and with delays (often evident) you can watch them happen in real time. Why is this a problem? Because it completely confuses password managers and whitelisting in uBlock Origin, et al.

A complete shitshow.

And then, after 30 seconds of watching the redirects, you finally reach a page that says... "your tenant ${uuid} cannot access resource ${uuid} on realm ${uuid}, sorry".

Microsoft and naming issues. That's one iconic duo.

Sometimes their services don't talk to each other, but you can step in and fill the gap!

https://www.ghacks.net/2019/04/17/microsoft-lost-control-ove...

A much better approach IMO is redirect links when browsing on company network. The company network is configured to make drl/... redirect to a url - I think google also does this with g/...

Dropbox already had this when I joined in 2015 drl/X "dropbox redirect link" would direct you to various internal sites and documentation.

You really don't want to give some random SaaS tool full permission on your production web origin.

If I'm Example Ltd. and my customers are trusting me to keep their data on example.com safe, and I use example.blog for my blog hosted by Jimbo's Blogging Service, I don't need to worry about Jimbo or his employees or hackers targeting my blog getting access to example.com's cookies, local storage, etc.

Cf. It's really hard—in some cases impossible, without use of the Public Suffix List[0]—to completely wall off blog.example.com from example.com.

[0] https://publicsuffix.org/

Why not just use a subdomain? This is, arguably, what subdomains are for.

Subdomains usually get all the cookies from the main domain (or at least they used to, didn't follow up on that issue for some years).

It's the opposite. Set-Cookie takes the optional Domain attribute and "If omitted, this attribute defaults to the host of the current document URL, not including subdomains." However, perhaps you're remembering "Multiple host/domain values are not allowed, but if a domain is specified, then subdomains are always included." [0]

[0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Se...

Can you give an example of what it means for a subdomain to not be walled off?

One thing you'd really want to do in particular is stop blog.example.com from either setting or reading any cookies from example.com

Isn't that why we have subdomains?

US banks are training their customers to get phished.

Many large US banks bounce the customer through several totally different and unrecognizable top level domains as part of routine web access.

Yes this drives me nuts! I was waved off when I tried to report it to the bank's security team.

Reply on news.ycombinator.com