Re: OT: Dropbox authentication: insecure by design

[Ben Scott]

On Wed, Apr 13, 2011 at 6:25 PM, Kurt Buff  wrote:
> I'm not clear on what the Dropbox host_id is either, but Muffett gives
> the classic example: ssh keys. Good analogy, I think.

  Well, that depends.

  If the host_id is a private/secret key, okay, it's a great analogy.
But private keys are, you know -- private.  Using one as a handle for
something makes no sense.  Further, from what I've seen of host IDs,
they appear to be maybe 30-60 bytes in length (depend on exactly what
the ASCII strings I saw were encoding).  240-480 bits.  That's not
private key sized.

  I've seen a few different sample URLs.  One is:

https://www.getdropbox.com/tray_login?host_id=BLAH

but does not actually give an ID.  Another does:

https://www.dropbox.com/cli_link?host_id=7d44a557aa58f285f2da0x67334d02c1

  So it would appear a host ID serves to uniquely identify a host
(shocking ), and is sometimes passed around in URLs as part
of the Dropbox client linking to a Dropbox webserver.  They're
relatively short.

  So as analogies go, they're nothing like SSH keys.  They're more
like IP addresses, or hostnames, or user logon names.  Especially that
last -- since they're provided by the client itself and have no other
association with other systems (e.g., in contrast, you can do things
to check a client's purported hostname againt DNS).

  Now, if the only thing used to authenticate a client is (e.g.) a
64-bit sequentially assigned serial number which is sometimes exposed
in semi-public URLs, that is indeed a very bad security design.

  But some of chatter around this suggests there may be more to it.
We're still in the initial-flurry-of-misinformation phase that usually
surrounds any technical news story.  As I don't have the time to do a
through job researching, I have to wait for some accuracy to
precipitate out of this cloud of confusion.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

RE: OT: Dropbox authentication: insecure by design

[Ziots, Edward]

It’s a common theme with dropbox and services like this. 

Basically it comes down to how much risk that the organization is willing to 
take, especially when it comes to information disclosure ( You are sending your 
internal information (how sensitive? Who knows) to a third party service, which 
you can't verify their controls, or whom else other than you has access to that 
information, when it is sitting on their servers in whatever location on the 
globe they reside, so do you really feel comfortable about this? You are going 
to have to frame it in risk to the higher ups, and either make them accept it 
in writing or advise them in writing of the slippery slope they are going down. 
( Either way you cover your arse, especially if you are dealing with regulatory 
entities that might find a security breach of the dropbox host, and the lack of 
due-diligence/Due-care on your higher up parts to properly protect and security 
the company crown jewels could lead to some serious fines/penalities and even 
jail time in certain countries. 

Z



Edward E. Ziots
CISSP, Network +, Security +
Network Engineer
Lifespan Organization
Email:ezi...@lifespan.org
Cell:401-639-3505

-Original Message-
From: Kurt Buff [mailto:kurt.b...@gmail.com] 
Sent: Wednesday, April 13, 2011 5:35 PM
To: NT System Admin Issues
Subject: Re: OT: Dropbox authentication: insecure by design

On Wed, Apr 13, 2011 at 11:17, Andrew S. Baker  wrote:
>>>The takeaway here: Don't use any remote applications in the cloud  for
>>> anything you wouldn't want to see posted on the front page of the NY Times.
> FTFY

I'll accept that fix.

> This is much ado about nothing.

I don't believe as you do.

> If your box is compromised, and you're
> sharing things remotely, then you have more risks than if you weren't.

That's not the risk I am concerned about. I'm concerned about the risk
where you're sharing a Dropbox account with folks whose machines are
not under your control, which, from my understanding, is one of the
major use cases for this service. Putting aside any concerns about the
security of the Dropbox infrastructure (which is a considerable
question of its own), the security model for this is completely
borked.

> Feel free to suggest an authentication mechanism that would withstand the
> initial premise of "your machine is exposed such that your config.db is
> stolen".

My initial premise that your Dropbox is exposed if your config.db is
stolen - not the same thing.

> Several of the comments, particularly those by alec muffett, provide
> valuable information about the risk.
> I'd welcome the ability to see where else systems are logged on to Dropbox,
> but that's about the extent of my concern at this time.

And, given that some influential staff in my org are using Dropbox,
and started doing so without notifying IT, I'm concerned about that
too, and that I don't have a good way to turn their access to it off.

Kurt

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: OT: Dropbox authentication: insecure by design

[Ben Scott]

On Wed, Apr 13, 2011 at 7:52 PM, Andrew S. Baker  wrote:
> Back to me and my 15% shared storage.  If the full system of one of the
> people who I share a set of folders with becomes compromised, some 3rd party
> could setup a separate machine that would allow them to install DropBox and
> get access to 100% of the victims files, plus 15% of my files ...

  Without knowing where this host_id might be used and what it does,
we're really just guessing.

  As a hypothetical example, suppose the host_id is passed around in
URLs in email for some reason.  Now an attacker just needs to sniff an
email (read a postcard) to get access to the Dropbox share.

  I don't know if Dropbox has reason to email one of these URLs.  This
is just an example of how things can go wrong in ways that aren't
always immediately apparent.

  We have insufficient data for a meaningful answer.

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: OT: Dropbox authentication: insecure by design

[Andrew S. Baker]

Okay, so I happen to have a shared DropBox configuration with a variety of
collaborators.  A few folders are overlapping, but most are not.

Some 15% of my total DropBox storage is shared.

*
*
*>>That's not the risk I am concerned about. I'm concerned about the
risk where you're sharing a Dropbox account with folks whose machines
are not under your control, which, from my understanding, is one of
the major use cases for this service*

Your premise needs validation.  *Most* of the people I know who are using
DropBox are not sharing the folders with anyone else.

Of the people I know using DropBox who *are* sharing folders with others,
80% are only sharing them with me.   So, of the 30-odd people I know using
Dropbox, removing me from the equation results in almost no folder sharing.

But, for argument's sake, let's suppose that my anecdotal stats are
completely off-base.DropBox allows you to share at the subfolder level,
not the root, so a person would have to go to a lot of work to share their
entire DropBox archive.


*>>Putting aside any concerns about the security of the Dropbox
infrastructure (which is a considerable question of its own), the security
model for this is completely borked.*

Just because you say so?  Try presenting something substantive.

Back to me and my 15% shared storage.  If the full system of one of the
people who I share a set of folders with becomes compromised, some 3rd party
could setup a separate machine that would allow them to install DropBox and
get access to 100% of the victims files, plus 15% of my files (actually,
some % less than 15, since that number is my total shared percentage across
different teams).   So, my exposure is very limited.



*>>My initial premise that your Dropbox is exposed if your config.db
is stolen - not the same thing.*

The degree of exposure is limited to the degree of data sharing with the
victimized individual -- IOW, no additional data is exposed above and beyond
that which is already exposed by access to the original machine.

If my DropBox looks like:

DropBox
-- Cool Stuff
-- Secret Stuff
-- Other Stuff
*-- Shared Stuff #1*
-- Shared Stuff #2

...and I am sharing the *"Shared Stuff #1"* folder with the victim whose
machine has been co-opted by BadDude, then the only risk I have is to *"Shared
Stuff #1"*, which is the same read risk as before, but a new delete risk for
me.  However, it should be noted that there is no increase in risk over
controlling the machine and simply deleting the shared files in the first
place.



*ASB *(Professional Bio )
 *Harnessing the Advantages of Technology for the SMB market...

 *



On Wed, Apr 13, 2011 at 5:35 PM, Kurt Buff  wrote:

> On Wed, Apr 13, 2011 at 11:17, Andrew S. Baker  wrote:
> >>>The takeaway here: Don't use any remote applications in the cloud  for
> >>> anything you wouldn't want to see posted on the front page of the NY
> Times.
> > FTFY
>
> I'll accept that fix.
>
> > This is much ado about nothing.
>
> I don't believe as you do.
>
> > If your box is compromised, and you're
> > sharing things remotely, then you have more risks than if you weren't.
>
> That's not the risk I am concerned about. I'm concerned about the risk
> where you're sharing a Dropbox account with folks whose machines are
> not under your control, which, from my understanding, is one of the
> major use cases for this service. Putting aside any concerns about the
> security of the Dropbox infrastructure (which is a considerable
> question of its own), the security model for this is completely
> borked.
>
> > Feel free to suggest an authentication mechanism that would withstand the
> > initial premise of "your machine is exposed such that your config.db is
> > stolen".
>
> My initial premise that your Dropbox is exposed if your config.db is
> stolen - not the same thing.
>
> > Several of the comments, particularly those by alec muffett, provide
> > valuable information about the risk.
> > I'd welcome the ability to see where else systems are logged on to
> Dropbox,
> > but that's about the extent of my concern at this time.
>
> And, given that some influential staff in my org are using Dropbox,
> and started doing so without notifying IT, I'm concerned about that
> too, and that I don't have a good way to turn their access to it off.
>
> Kurt
>
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: OT: Dropbox authentication: insecure by design

[Kurt Buff]

On Wed, Apr 13, 2011 at 11:39, Ben Scott  wrote:
>  I'm not clear on what "host_id" actually *is*.
>
>  Muffett's comments[1][2] make it sound like Is it the private key
> for an asymmetric cipher.  If so, then yes, getting it stolen would of
> course compromise your Dropbox storage.  That's how practically every
> modern cryptosystem works.
>
>  However, the original link[3] gives me the impression "host_id" is
> not intended to be a cryptographic secret.  It sounds more like it's
> just some kind of machine serial number or GUID, and it may appear in
> (semi-)public URLs and the like.  If all you need to access nominally
> private Dropbox storage is that ID number, then that's not good at
> all.  It would be more like authenticating clients solely on their
> login username.
>
> [1] 
> http://blogs.computerworlduk.com/unscrewing-security/2011/04/practical-dropbox-security-advice/index.htm
> [2] Thanks, ASB.
> [3] http://dereknewton.com/2011/04/dropbox-authentication-static-host-ids/

I'm not clear on what the Dropbox host_id is either, but Muffett gives
the classic example: ssh keys. Good analogy, I think.

I share your concern about the host_id implementation, and carry it a
little further - Muffett mentioned the threat but didn't mention the
mitigation: Use both keys and passwords.

This is what should be happening with Dropbox, at least optionally. If
it's not even an option, well, then I can't recommend its use to
anyone, for any data they care about.

Kurt

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: OT: Dropbox authentication: insecure by design

[Kurt Buff]

On Wed, Apr 13, 2011 at 11:17, Andrew S. Baker  wrote:
>>>The takeaway here: Don't use any remote applications in the cloud  for
>>> anything you wouldn't want to see posted on the front page of the NY Times.
> FTFY

I'll accept that fix.

> This is much ado about nothing.

I don't believe as you do.

> If your box is compromised, and you're
> sharing things remotely, then you have more risks than if you weren't.

That's not the risk I am concerned about. I'm concerned about the risk
where you're sharing a Dropbox account with folks whose machines are
not under your control, which, from my understanding, is one of the
major use cases for this service. Putting aside any concerns about the
security of the Dropbox infrastructure (which is a considerable
question of its own), the security model for this is completely
borked.

> Feel free to suggest an authentication mechanism that would withstand the
> initial premise of "your machine is exposed such that your config.db is
> stolen".

My initial premise that your Dropbox is exposed if your config.db is
stolen - not the same thing.

> Several of the comments, particularly those by alec muffett, provide
> valuable information about the risk.
> I'd welcome the ability to see where else systems are logged on to Dropbox,
> but that's about the extent of my concern at this time.

And, given that some influential staff in my org are using Dropbox,
and started doing so without notifying IT, I'm concerned about that
too, and that I don't have a good way to turn their access to it off.

Kurt

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: OT: Dropbox authentication: insecure by design

[Ben Scott]

  I'm not clear on what "host_id" actually *is*.

  Muffett's comments[1][2] make it sound like Is it the private key
for an asymmetric cipher.  If so, then yes, getting it stolen would of
course compromise your Dropbox storage.  That's how practically every
modern cryptosystem works.

  However, the original link[3] gives me the impression "host_id" is
not intended to be a cryptographic secret.  It sounds more like it's
just some kind of machine serial number or GUID, and it may appear in
(semi-)public URLs and the like.  If all you need to access nominally
private Dropbox storage is that ID number, then that's not good at
all.  It would be more like authenticating clients solely on their
login username.

[1] 
http://blogs.computerworlduk.com/unscrewing-security/2011/04/practical-dropbox-security-advice/index.htm
[2] Thanks, ASB.
[3] http://dereknewton.com/2011/04/dropbox-authentication-static-host-ids/

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: OT: Dropbox authentication: insecure by design

[Andrew S. Baker]

>>The takeaway here: Don't use any *remote applications in the cloud*  for
anything you wouldn't want to see posted on the front page of the NY Times.

FTFY

This is much ado about nothing.  If your box is compromised, and you're
sharing things remotely, then you have more risks than if you weren't.

Feel free to suggest an authentication mechanism that would withstand the
initial premise of "your machine is exposed such that your config.db is
stolen".

Several of the comments, particularly those by alec
muffett,
provide valuable information about the risk.

I'd welcome the ability to see where else systems are logged on to Dropbox,
but that's about the extent of my concern at this time.


*ASB *(Professional Bio )
 *Technology Services that Maximize Business Results...

 *



On Wed, Apr 13, 2011 at 1:42 PM, Kurt Buff  wrote:

> On Wed, Apr 13, 2011 at 10:29, S Powell  wrote:
> > again, if someone has access to your config.db  you have MUCH larger
> > problems than access to your dropbox.
>
> The problem is not necessarily *your* machine (although I think that's
> still a consideration), it's everyone else with whom you share the
> dropbox.
>
> Without authentication, any compromised machine can emit the config,
> and you'll have no way of knowing it.
>
> It gets worse when you consider that other clients for it are
> available, including clients that run on hosts for which there are few
> or no effective anti-malware agents (I'm looking at you, Apple.)
>
> The takeaway here: Don't use Dropbox for anything you wouldn't want to
> see posted on the front page of the NY Times.
>
> > -
> > Who'd you rather be, the Beatles or the Rolling Stones?
>
> Led Zepplin, or perhaps the Berlin Philharmonic.
>
> Kurt
>
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: OT: Dropbox authentication: insecure by design

[Kurt Buff]

On Wed, Apr 13, 2011 at 10:29, S Powell  wrote:
> again, if someone has access to your config.db  you have MUCH larger
> problems than access to your dropbox.

The problem is not necessarily *your* machine (although I think that's
still a consideration), it's everyone else with whom you share the
dropbox.

Without authentication, any compromised machine can emit the config,
and you'll have no way of knowing it.

It gets worse when you consider that other clients for it are
available, including clients that run on hosts for which there are few
or no effective anti-malware agents (I'm looking at you, Apple.)

The takeaway here: Don't use Dropbox for anything you wouldn't want to
see posted on the front page of the NY Times.

> -
> Who'd you rather be, the Beatles or the Rolling Stones?

Led Zepplin, or perhaps the Berlin Philharmonic.

Kurt

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: OT: Dropbox authentication: insecure by design

[S Powell]

again, if someone has access to your config.db  you have MUCH larger
problems than access to your dropbox.




-
Who'd you rather be, the Beatles or the Rolling Stones?



On Wed, Apr 13, 2011 at 10:14, Kurt Buff  wrote:
> On Tue, Apr 12, 2011 at 22:39, Angus Scott-Fleming  
> wrote:
>> WTF were they thinking?
>
> You assume facts which are not in evidence.
>
> Kurt
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~   ~
>
> ---
> To manage subscriptions click here: 
> http://lyris.sunbelt-software.com/read/my_forums/
> or send an email to listmana...@lyris.sunbeltsoftware.com
> with the body: unsubscribe ntsysadmin
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: OT: Dropbox authentication: insecure by design

[Kurt Buff]

On Tue, Apr 12, 2011 at 22:39, Angus Scott-Fleming  wrote:
> WTF were they thinking?

You assume facts which are not in evidence.

Kurt

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

Re: OT: Dropbox authentication: insecure by design

[Rene de Haas]

"WTF were they thinking?"

+100
On Wed, Apr 13, 2011 at 7:39 AM, Angus Scott-Fleming wrote:

> Don't know if any of you (or your clients) use Dropbox (I do), but if you
> do,
> you should probably read this and pass it on:
>
> = Included Stuff Follows =
> Dropbox authentication: insecure by design
>
>...
>
>After some testing (modification of data within the config table, etc)
> it
>became clear that the Dropbox client uses only the host_id to
>authenticate. Here´s the problem: the config.db file is completely
>portable and is *not* tied to the system in any way. This means that if
>you gain access to a person´s config.db file (or just the host_id), you
>gain complete access to the person´s Dropbox until such time that the
>person removes the host from the list of linked devices via the Dropbox
>web interface. Taking the config.db file, copying it onto another system
>(you may need to modify the dropbox_path, to a valid path), and then
>starting the Dropbox client immediately joins that system into the
>synchronization group without notifying the authorized user, prompting
> for
>credentials, or even getting added to the list of linked devices within
>your Dropbox account (even though the new system has a completely
>different name) - this appears to be by design.  Additionally, the
> host_id
>is still valid even after the user changes their Dropbox password (thus
> a
>standard remediation step of changing credentials does not resolve this
>issue).
>
>...
>
> = Included Stuff Ends =
> Seen here:
>http://dereknewton.com/2011/04/dropbox-authentication-static-host-ids/
>http://tinyurl.com/3b9xdvv
>
> WTF were they thinking?
>
> Angus
>
> --
> Angus Scott-Fleming
> GeoApps, Tucson, Arizona
> 1-520-895-3270
> Security Blog: http://geoapps.com/
>
>
>
> --
> Angus Scott-Fleming
> GeoApps, Tucson, Arizona
> 1-520-290-5038
> Security Blog: http://geoapps.com/
>
>
>
>
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~   ~
>
> ---
> To manage subscriptions click here:
> http://lyris.sunbelt-software.com/read/my_forums/
> or send an email to listmana...@lyris.sunbeltsoftware.com
> with the body: unsubscribe ntsysadmin
>
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin

OT: Dropbox authentication: insecure by design

[Angus Scott-Fleming]

Don't know if any of you (or your clients) use Dropbox (I do), but if you do, 
you should probably read this and pass it on:  

= Included Stuff Follows =
Dropbox authentication: insecure by design

...

After some testing (modification of data within the config table, etc) it 
became clear that the Dropbox client uses only the host_id to 
authenticate. Here´s the problem: the config.db file is completely 
portable and is *not* tied to the system in any way. This means that if 
you gain access to a person´s config.db file (or just the host_id), you 
gain complete access to the person´s Dropbox until such time that the 
person removes the host from the list of linked devices via the Dropbox 
web interface. Taking the config.db file, copying it onto another system 
(you may need to modify the dropbox_path, to a valid path), and then 
starting the Dropbox client immediately joins that system into the 
synchronization group without notifying the authorized user, prompting for 
credentials, or even getting added to the list of linked devices within 
your Dropbox account (even though the new system has a completely 
different name) - this appears to be by design.  Additionally, the host_id 
is still valid even after the user changes their Dropbox password (thus a 
standard remediation step of changing credentials does not resolve this 
issue).

...

= Included Stuff Ends =
Seen here:
http://dereknewton.com/2011/04/dropbox-authentication-static-host-ids/
http://tinyurl.com/3b9xdvv

WTF were they thinking?

Angus

--
Angus Scott-Fleming
GeoApps, Tucson, Arizona
1-520-895-3270
Security Blog: http://geoapps.com/


  
--
Angus Scott-Fleming
GeoApps, Tucson, Arizona
1-520-290-5038
Security Blog: http://geoapps.com/





~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to listmana...@lyris.sunbeltsoftware.com
with the body: unsubscribe ntsysadmin