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