[HN Gopher] How we handled a recent phishing incident
___________________________________________________________________
How we handled a recent phishing incident
Author : lawgimenez
Score : 58 points
Date : 2022-11-01 13:13 UTC (9 hours ago)
(HTM) web link (dropbox.tech)
(TXT) w3m dump (dropbox.tech)
| rtev wrote:
| 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 wrote:
| 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 wrote:
| computerfriend wrote:
| Storing API keys in Git, nice.
| not2b wrote:
| Apparently this was a private repo, not a public one, but the
| attacker gained access.
| rtev wrote:
| That doesn't matter, best practice is storing them as
| variables that are injected upon deployment from a secret
| manager.
| insanitybit wrote:
| 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
| shkkmo wrote:
| 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.
| [deleted]
| stack_underflow wrote:
| > 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 wrote:
| 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.
| gilbertbw wrote:
| > 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?
| jsty wrote:
| 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
| dannyw wrote:
| Probably an internal prototype that incorrectly stored PII in
| the repo (as a CSV, .sql, etc)
| aliqot wrote:
| That's the real story here.
| blowski wrote:
| Not really. Someone's suggested a possible reason for
| something that was unclear in the original article. That's
| hardly a story.
| sdfhbdf wrote:
| > [...] 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 wrote:
| 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 wrote:
| > 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...
| dotBen wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Manuel_D wrote:
| 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.
| dpifke wrote:
| 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/
| getcrunk wrote:
| Can you give an example of what it means for a subdomain to
| not be walled off?
| kadoban wrote:
| 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
| [deleted]
| chias wrote:
| Why not just use a subdomain? This is, arguably, what
| subdomains are _for_.
| mschuster91 wrote:
| 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).
| cuttysnark wrote:
| 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...
| [deleted]
| rsync wrote:
| 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.
| latortuga wrote:
| Yes this drives me nuts! I was waved off when I tried to
| report it to the bank's security team.
| mdaEyebot wrote:
| 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.
| Semaphor wrote:
| Microsoft and naming issues. That's one iconic duo.
| e40 wrote:
| 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.
| TeMPOraL wrote:
| 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".
| tedunangst wrote:
| 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...
| jakub_g wrote:
| The domains mess at Microsoft is truly hilarious. MS Edge
| browser fetches some updates from something.skype.com IIRC.
___________________________________________________________________
(page generated 2022-11-01 23:01 UTC)