[HN Gopher] A recent security incident involving Dropbox Sign
___________________________________________________________________
A recent security incident involving Dropbox Sign
Author : JonoBB
Score : 195 points
Date : 2024-05-02 07:52 UTC (15 hours ago)
(HTM) web link (sign.dropbox.com)
(TXT) w3m dump (sign.dropbox.com)
| artdigital wrote:
| I love Dropbox but stuff like this is a good reminder to re-
| evaluate using any service that store large amount of personal
| data without e2ee. I understand that partly because of block-
| level diffing and syncing, it's hard to provide true e2ee for
| Dropbox, but it's still a big reason why I'm having most of my
| stuff in iCloud Drive (with Advanced Data Protection), despite
| liking Dropbox much more.
|
| Hope they'll come around and add it at some point, and not just
| for businesses as hinted at when they acquired boxcryptor.
|
| (Cryptomator and encrypted sparsebundles work great on Dropbox.
| Just annoying to manage)
| reddalo wrote:
| I use Proton Drive [1], they offer e2ee but I agree with you:
| the Dropbox app experience is probably still the best.
|
| [1] https://proton.me/drive
| amelius wrote:
| OK, so there is no fundamental obstacle for providing true
| e2ee.
| nicce wrote:
| Of course there isn't, but it limits efficiency and
| features. For example, you will miss all the fancy features
| Google Images does in cloud and user experience might be
| slower, since everything must be processed and downloaded
| on client side. Some level of metadata is always
| unencrypted.
| amelius wrote:
| That's trading one feature for a bunch of others. Users
| should have the choice of what features they think are
| important.
| macintux wrote:
| They typically do, by picking the product they wish to
| use.
| basil-rash wrote:
| Of course not. It's just storing bits at the end of the
| day. But storing seemingly random bits will always be more
| expensive than storing predictable bits, and this case is
| no exception: Proton is roughly 4x more expensive per bit
| than Dropbox.
| repelsteeltje wrote:
| What I'd really like is for the encryption to be plugable
| and orthogonal to file syncing.
|
| Ie: authentication with dropbox/proton/bittorrent concerns
| only that you pay your storage/ingest/egress bill, but is
| otherwise unprotected and in the clear. Encryption of the
| file payload and metadata as a "bring-your-own" -- on
| device -- stream cypher (and key derivation, key
| management). Key exchange and sharing among devices or
| users might then use yet another service or mechanism.
|
| Pretty sure presenting all that in a slick easy to
| understand way has significant challenges, but it would be
| great to alleviate some of the dropbox as a single point of
| failure.
| cyberpunk wrote:
| So kinda like how rclone does encrypted backends?
| cqqxo4zV46cp wrote:
| Was the question whether or not it is hypothetically
| possible to provide an E2EE storage service? Surely you can
| apply your engineering chops here. Of course it isn't. But
| there are trade-offs, as with literally any engineering
| choice.
| whatevaa wrote:
| It is very complicated to get this right from development
| standpoint. In true E2E, client must be "fat", kitchen sink
| and everything. Pretty sure Dropbox isn't like that right
| now. E2E is not a "feature", it is like a different
| paradigm of problem solving.
| Flimm wrote:
| Dropbox offers end-to-end encryption now (for business teams):
|
| https://blog.dropbox.com/topics/company/new-solutions-to-sec...
| artdigital wrote:
| I'm not a business, I'm a paying customer on the most
| expensive personal tier. It's silly that they don't offer
| this feature for me. I also can't upgrade to a business plan
| because those require at least 3 users.
|
| It just feels like feature gatekeeping to me, but no way for
| me to pay more to get this feature. But I also understand
| that personal users are not Dropbox's main focus.
| jbverschoor wrote:
| Apple does offer this
| ghusbands wrote:
| If you want encryption enough, you can probably pay for a
| three-person business plan and just not set up the extra
| users. Looks like it would double your monthly subscription
| over the most expensive personal plan.
| aborsy wrote:
| A Synology/QNAP/TrueNAS NAS is a far better solution, with
| no restriction.
| redserk wrote:
| I'm a big advocate for running a NAS, but using a service
| like Dropbox means there's one fewer personal device that
| needs babysitting.
| oger wrote:
| We all are probably guilty of falling for the convenience
| trap here or there. But setting up the sync between
| Dropbox and the NAS (Synology user here) with a one-way,
| don't delete, don't overwrite policy is a good lifeline
| to have - you know, just in case...
| msh wrote:
| You would still need somewhere to do off site backups to.
|
| (Edit: changed offline to offsite)
| lostlogin wrote:
| Isn't that what a Synology offers? An offline backup?
| msh wrote:
| Sorry, I wrote it wrong. I meant offsite.
| msh wrote:
| Its says: The latest security features will be available to
| all Dropbox Advanced, Business Plus, and Enterprise
| customers starting today.
|
| Is dropbox advanced a business plan?
| jimmaswell wrote:
| I used to love Dropbox, then they limited devices and storage
| so much it was barely worth it, and spamming me with nag popups
| all day to upgrade because my storage was near full sealed the
| deal and I just started using OneDrive (not much better but
| it's integeated and convenient, probably going to just go foss
| with a home server eventually). Another sad downfall of a once
| good company.
| jrgoff wrote:
| They only limited devices for free accounts.
| aborsy wrote:
| Dropbox was breached also around 2012.
| sorbusherra wrote:
| I remember that day. It was the day I stopped using dropbox.
| 8fingerlouie wrote:
| That was when i stopped using the cloud for storing personal
| stuff.
|
| Fast forward a decade and i've more than had my fill of self
| hosting stuff, so a couple of years ago i went all in on the
| cloud again, though with a bit of a different approach.
|
| Stuff that is not really sensitive is uploaded "as is". Yes,
| that includes our photos. While i don't want our photo library
| to be "public domain", there is nothing there of particular
| interest to anybody but my family and I.
|
| For sensitive stuff i use Cryptomator to end to end encrypt
| data before uploading them to the cloud. It has desktop and
| mobile clients that allows me transparent access to my
| encrypted files on the go.
| EduardoBautista wrote:
| For this reason, I enabled E2E encryption for iCloud. Sure,
| if you are very paranoid, you can choose not to trust Apple,
| but E2E encryption on iCloud is seamless, and I haven't
| noticed a difference since enabling it.
| 8fingerlouie wrote:
| I did the same, but i still use Cryptomator for stuff like
| sensitive documents and the sorts, much like i would have
| used an encrypted image before using cryptomator.
|
| iCloud works great, and even if you trust Apple (which i do
| to some extent), your data is still only safe as long as
| nobody gains access to your devices. Once somebody has
| access to your devices, files are no longer encrypted.
|
| The choice of Cryptomator was a convenience choice. I could
| have just as easliy encrypted files using GPG, LUKS,
| encrypted disk images or similar, but i would not have been
| able to access those directly from my phone/tablet in their
| cloud location, which is something i can do with
| Cryptomator.
|
| For reference, i have about 4TB data in the cloud (~3.5TB
| photo library), and a 2GB Cryptomator vault, so it's not
| exactly the main driver of the operation :)
| aborsy wrote:
| How do you sync the cryptomator vault safely, properly
| handling conflicts?
| 8fingerlouie wrote:
| I use the regular iCloud sync method.
|
| The Crytomator vault is personal, so i'm the only user,
| which means that conflicts are rather rare.
|
| I've yet to experience synchronization conflicts with
| iCloud in my day to day usage, and i've been using iCloud
| since it was called MobileMe. I even ran with a local
| cache for a few years, and that never caused a problem
| either.
| gregoriol wrote:
| That was 12 years ago, react didn't exit, Windows was "8",
| Chrome was version 18, ...
| thrdbndndn wrote:
| > Based on our investigation, a third party gained access to a
| Dropbox Sign automated system configuration tool. The actor
| compromised a service account that was part of Sign's back-end,
| which is a type of non-human account used to execute applications
| and run automated services. As such, this account had privileges
| to take a variety of actions within Sign's production
| environment. The threat actor then used this access to the
| production environment to access our customer database.
|
| Not familiar with this area, how usually does it happen? Social
| engineering or some more "technical" ways?
|
| Also, under normal (not hacked) circumstance, who usually would
| have access to these service accounts?
| l33tman wrote:
| I really recommend listening to the Darknet Diaries podcast
| (available on Spotify at least). Really high-quality interviews
| with both ex and current hackers, cybersecurity professionals
| etc.
| couchand wrote:
| The credentials for service accounts are generally available to
| a system admin but I think in most cases it would be a strange
| request to ask for them, so not a strong vector for social
| engineering.
|
| A service account is used to give limited permissions on one
| system to another system. Normally only that system would need
| access to them, not any human.
|
| Their main benefit is that, since no person is trying to do
| their day job here, the account can be locked down to precisely
| the permissions it needs. The reality is that service accounts
| are usually given extremely permissive access initially and
| then forgotten about. This makes them juicy targets for
| attackers.
| chenxi9649 wrote:
| "Upon further investigation, we discovered that a threat actor
| had accessed data including Dropbox Sign customer information
| such as emails, usernames, phone numbers and hashed passwords, in
| addition to general account settings and certain authentication
| information such as API keys, OAuth tokens, and multi-factor
| authentication."
|
| hashed passwords, API keys, OAuth tokens, MFA...
|
| Oh no.
| meindnoch wrote:
| Hashed passwords? Surely they mean hashed and salted passwords.
| Right? Right???
| rvnx wrote:
| They were using SHA1, then they migrated.
|
| 68 million accounts dumped: https://www.theguardian.com/techn
| ology/2016/aug/31/dropbox-h...
|
| https://www.troyhunt.com/the-dropbox-hack-is-real/
|
| now they first hash the password using SHA512 (with a per-
| account salt)
|
| then they hash the password with bcrypt (with the default
| strength)
|
| then they encrypt the password with a key that the
| application server runs with, but that is not stored in the
| database.
|
| So yes, hashed and salted.
| dkyc wrote:
| This hack seems to affect the Dropbox Sign application,
| which is based on HelloSign which they acquired a few years
| ago. It's still running on the hellosign.com domain and
| seems mostly separate, so it wouldn't surprise me if they
| also store passwords differently.
| xrisk wrote:
| That... seems excessive. Is it just security theater or
| actually useful somehow?
| zsims wrote:
| Useful because you can support existing passwords without
| requiring everyone to login or reset their password.
| Still has flaws though, like password shucking.
| SoftTalker wrote:
| They encrypt the salted password hash?
| tyrelb wrote:
| I use Dropbox Sign API, so a little fearful our private data
| was accessed. API keys were leaked as part of this hack. It's
| unclear from press release if hackers used the API keys to
| access data/documents of customers.
|
| April 24th they became aware of issue, reporting it over a week
| later. I'd also be curious on how long this problem went on
| before being detected on April 24?
|
| I suppose more will come out in the coming days..
| rvnx wrote:
| At least it's a hack this time, it's not like when they forgot to
| enable authentication and you could sign-in to any Dropbox just
| by entering the e-mail.
|
| https://techcrunch.com/2011/06/20/dropbox-security-bug-made-...
| belter wrote:
| It seems most billion dollar companies, are just Dave, hacking
| away on Node and dropping directly to production... :-)
| jwilk wrote:
| Discussed on HN:
|
| https://news.ycombinator.com/item?id=2678576 (46 comments)
| renegade-otter wrote:
| And here I am, thinking that pushing bad CSS is going to end it
| all for me.
| chrisjj wrote:
| So, Dropbox failed to inform the affected customers?
| virtue3 wrote:
| good reminder to enable 2fa on my dropbox account. Whoops.
| vertis wrote:
| Seems like they got the 2FA keys as well[0], so I'm not sure
| how useful this is in this context. 2FA seems it might be more
| useful where it's a different site and you've reused the
| password or had it phished, than in this case where the site is
| compromised.
|
| I'm still unclear how much I'm impacted. I've used Dropbox Sign
| / HelloSign but always with my dropbox account. Resetting
| password and 2FA anyway, because why not.
|
| [0]: They're asking people to reset the 2FA.
| bilekas wrote:
| > We didn't live up to that standard here, and we're deeply sorry
| for the impact it caused our customers.
|
| This might be the first time a large company has actually
| apologised and admitted some fault. Colour me shocked.
| dml2135 wrote:
| This is Dropbox Sign, not Dropbox. It's a document signing
| product akin to Docusign, and was called Hellosign before Dropbox
| acquired them.
|
| We are a customer of theirs at my startup, and as far as I can
| tell Dropbox has made very few changes since the acquisition
| beyond changing the branding. So I wouldn't take this incident to
| be an indicator of much on the cloud-storage side of the company.
| jrochkind1 wrote:
| It should also be a reminder for Dropbox that acquiring a
| product then allowing it to languish risking security
| vulnerabilities -- will, appropriately, have negative brand
| perception implications that affect your main product too.
| EE84M3i wrote:
| Acquired in 2022? IMO that's enough time to bring their service
| up to the same security standard as the rest of their services,
| assuming it's a priority.
|
| Google and others normally have a 6 month grace period for bug
| bounty reports in acquisitions.
| MichaelZuo wrote:
| Yeah after nearly 2 years it probably isn't a credible excuse
| in any way.
| Neener54 wrote:
| We've been with hellosign for years and Dropbox has done a
| great job of stabilizing them. I will tell you that they have
| put in a ton of ops work to keep the platform up more
| consistently.
| dml2135 wrote:
| True, they have been more stable since the acquisition now
| that you mention it.
|
| Our implementation of their API was a bit of a mess so it can
| be hard to see through our own crap sometimes to give credit
| where its due haha.
| latexr wrote:
| > For those who received or signed a document through Dropbox
| Sign, but never created an account, email addresses and names
| were also exposed.
|
| So they also leaked data of people who are not their customers,
| and who never agreed to have their information collected.
|
| I doubt that flies under the GDPR.
| SoftTalker wrote:
| In the grand scheme of things, expecting your name and email
| address to really stay private is not all that reasonable. You
| probably gave them to the person who then used Dropbox Sign to
| send you a document. If you were really worried you could have
| used a throwaway account. The old saying is, once you tell
| someone, it's no longer a secret.
| latexr wrote:
| > In the grand scheme of things, expecting your name and
| email address to really stay private is not all that
| reasonable.
|
| In the grand scheme of things, nothing matters and we're all
| going to die. It's been a while since I read the GDPR, but I
| don't remember a section titled "personal data which is OK to
| leak because it doesn't matter in the grand scheme of things
| *shrug emoji*".
|
| > You probably gave them to the person who then used Dropbox
| Sign to send you a document. If you were really worried you
| could have used a throwaway account.
|
| Yes, you probably did. And that's irrelevant. That data
| should've been deleted once it was no longer relevant. Almost
| no one goes around giving throwaway email accounts to
| acquaintances. Do you also suggest people have a throwaway
| phone number they give to friends and family, for when they
| upload it to a service like WhatsApp?
| fileseeder wrote:
| That's why e2ee is key, decentralised tooling for these types of
| applications is the way (even if the UX is not as good yet)
| polski-g wrote:
| I am confused about Dropbox Sign's pricing model.
|
| Why are they charging per-user? What exactly does that mean? A
| company will have one singular account and send documents to non-
| Dropbox affiliated entities, who aren't classified as users.
| btown wrote:
| Trying to understand some of the interplay here:
|
| > threat actor had accessed data including ... certain
| authentication information such as API keys, OAuth tokens, and
| multi-factor authentication.
|
| > If I have a Sign account linked to my Dropbox account, is my
| Dropbox account affected? No. Based on our investigation to date,
| we believe this incident was isolated to Dropbox Sign
| infrastructure, and did not impact any other Dropbox products.
|
| If you linked your Dropbox account to a Sign account, wouldn't
| Sign have had an OAuth token (or similar) with permissions to
| access documents in Dropbox accounts? One imagines that leaked,
| if everything else did. Would they have been able to detect this
| as a distinct access pattern from someone, say, choosing a file
| to sign via the Sign interface?
___________________________________________________________________
(page generated 2024-05-02 23:01 UTC)