> 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?
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.
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.
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.
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.
> 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.
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.
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.
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".
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.
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]
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.
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.
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?