

How I stumbled onto a security flaw in Box Sync for Mac - zdw
http://enterprisemac.bruienne.com/2015/02/07/box-cutting-how-i-stumbled-onto-a-serious-security-flaw-in-box-sync-for-mac/

======
dperfect
> ... heads up to fellow Mac Admins and anyone else who uses or deploys Box
> Sync to ensure that the 4.0.6035 update is applied ASAP. There is no way of
> knowing who else has been aware of the exposed information before me and
> whether or not it may have been used to access Box customer data. This is
> especially important in environments that use a managed software update
> workflow which may be holding back automatic updates until specific action
> is taken by an admin.

Looks like that second-to-last sentence was inserted after an initial writing,
since the last line refers again to the urgency to update. In my opinion,
there's far too little discussion (just the one line) about the implications
of what might have been exposed here. In other words, this sounds much more
like evidence of a possible data breach than just a client security bug that
is fixed with an updated version. Of course, that discussion/clarification
should come directly from Box.

If information like S3 credentials was exposed, I assume Box's response was to
immediately change all the relevant credentials (and be sure the new ones
aren't exposed in later versions). If that's the case, then the client update
itself probably isn't the critical thing to worry about at this point, right?

It's a bit like saying "oops, we accidentally pushed secrets to our public
GitHub repo and didn't know about it until someone else pointed it out" and
that person saying "quick, everyone pull down the latest revision that doesn't
include the credentials."

~~~
zaroth
Wish the blog would have started with "As it turns out, the development team
at Box embedded a lot of rather sensitive information in the files belonging
to the conf module..." and then gone one to explain exactly how and why the
information is sensitive.

A configured client (Box, DropBox, whatever) must by definition have access to
all the files that are being sync'd. I recall DropBox having exactly the same
kind of token which can be stolen. How is this different?

~~~
dperfect
The location and context of these credentials seems to suggest that they were
intended for mostly internal use. Another comment here mentions that the
updated client contains just an api_key and client_secret (makes sense),
implying that for normal user operations (syncing a user's files) the client
probably just communicates with Box's servers, not directly with S3. I guess
it would be possible to use a single set of S3 credentials and still lock down
per-user access with other means, but I have a hard time believing that's how
Box syncs your files.

In any case, this really doesn't seem like the place you'd store user-specific
storage credentials (if Box were to use S3 directly in that way). Remember,
this was found in a _pre-compiled_ .pyo file, within site-packages.zip.

------
kartikkumar
I removed Box Sync because the client was so annoying. Every time I booted up
without internet, it logged me out and required me to log back in. This
security flaw only adds to my view that they have a poor product, at least for
Mac.

------
Nexxxeh
Well that doesn't inspire confidence. I'm not a Box user; is data usually
encrypted with a user-supplied key as well before transmission to Box's
systems? Is access to Box's "internal" S3 storage going to potentially yield
unencrypted (or encrypted with a known key) user data?

------
dsacco
The tl;dr of the vulnerability is this: the Box sync application had sensitive
information (e.g. application secret keys) exposed.

Fairly widespread problem, which is almost inevitable given enough binary
digging and reverse engineering work, unless you do real work to segregate the
authentication process to a serverside PKI or something similar.

If the author comes across this, good work, nice writeup! However, if you're
going to have a _tl;dr_ section at all, you should put a brief description of
the vulnerability in it. In this case, the vulnerability is simple enough that
it can be briefly expressed in a tl;dr.

------
Someone
_" On February 6th I was notified that an updated version 4.0.6035 had been
released which is supposed to resolve the issue."_

It would have been useful to check whether that 'supposed' is true and if so,
how they fixed this. Worst-case, they did the easy thing and obfuscated the
strings.

~~~
mbreese
I supposedly have the updated version (according to Box's about screen) and I
still see values for api_key and client_secret in these files.

I can't say what they do or if it's a real issue, but it's troubling to still
see values there. There are also a few other keys that don't look like they
should be there...

