Dropbox inspects uploaded documents

Last week, a researcher at WNCInfosec discovered that Dropbox is opening files with .doc extensions. The reason for the files being opened is apparently to perform conversions so the files can be opened in a web browser (with no plugins required).

Everyone seemed up in arms about this for the first 24 hours or so.  There were questions about what Dropbox was doing with user's private data. But then reality set in and folks realized that this is just part of the formatting conversion process.

I'm not as worried about data privacy in the sense that Dropbox might maliciously view my "private" data.  What precisely we even mean by "private" when we upload data to the cloud is a mystery to me anyway (but that's another discussion for another day).  I am however concerned that a vulnerability in the document converter/parser may threaten to disclose private data of many customers.  The software used to open the documents for conversion is LibreOffice.  It's worth noting that LibreOffice has had vulnerabilities reported as recently as 26JUL13.

A hypothetical attack would look like this:

1. A user uploads a document that exploits a zero day vulnerability in LibreOffice.
2. Dropbox opens the document to create the preview.
3. The exploit results in arbitrary code execution on the server (which appear to be AWS instances).
4. Profit!

Is this feasible?
Because we don't know how Dropbox works internally, it's impossible to know how much data an attacker would be able to obtain in this scenario.  It is unlikely that Dropbox spawns a new server for each user's files.  What is more likely is that each new document that needs a preview is loaded into a queue for processing.  A server then retrieves files for conversion from that queue.  The results are likely stored in a database of some sort, meaning that a successful exploit might also compromise this database (if one is used, remember we don't know what Dropbox internals look like).  In any case, successful code execution would very likely compromise the contents of many (if not all) user's uploaded documents.

Of course this sort of attack is hypothetical and would initially have to be exploited blind.  But it's still given me pause to think about the possibilities.  The black hat in me wants to open up a debugger and find a vuln in LibreOffice. The white hat in me remembers the CFAA, and I'm too pretty for jail.

Original blog post on Dropbox opening files:
http://www.wncinfosec.com/dropbox-opening-my-docs/

Want to buy some Instagram followers?

Want to buy some Instagram followers?  Nope? Me neither.  But in case you were thinking about it, there are a couple of blog articles out there that warn you that this is a good idea.  Now I hate blog aggregators that steal my content, screw up the formatting and give me minimal or no credit.  Here's a great example of fixya doing just that in this post.

Can you find anything below that might scare you a little?

Yep, that's right, these clowns actually recommend you visit the offending URL (mistaking it for the FTC's website).  I checked the link and found out that apparently the account has been suspended.

Good, so at least fixya.com isn't directing people to what may be an identity theft site (but not because they are competent).

Let's talk about the meat of the article in the first place.  They claim researchers discovered that buying Instagram followers could result in identify theft.  This conclusion was largely based on the fact that people who purchased this "service" revealed their phone numbers, email addresses, and payment information.  The author determined that this "is essentially all that is needed to begin a full-fledged phishing attack."

Seriously???
Right.  When you have that information, you have their identity.  Later the article mentions that it's a bad idea to provide payment information to any untrusted site.  Next time lead off with that sagely wisdom and avoid putting direct links to scam sites in your blog articles.

Dropbox - ASLR = easier exploits

So my love/hate relationship with Enterprise File Sharing Services (EFSS, e.g. Dropbox) continues.   This week a researcher examining Dropbox discovered that Dropbox DLLs aren’t compiled to use ASLR.  My only question is why the heck not?

What is ASLR?

ASLR is address space layout randomization.  There was a time when an attacker would know the memory addresses where critical API functions (GetProcAddress, LoadLibrary) were located in memory for a given operating system.  This makes exploits easier (much easier) to write since you have predictable landing zones in memory.  When ASLR came along, these addresses were randomized at every reboot.  Attackers can still find the addresses of APIs in memory, but they have to work for it. That makes shellcode larger and as a result some buffers can no longer hold exploit code for certain exploits.  Even when a vulnerability is still exploitable, the attacker has to work harder to gain reliable code execution.

Why do we care?

Well, for this whole ASLR scheme to work, it has to be implemented every time.  When it isn’t implemented every time, the whole system starts to fall apart.  Just one non-ASLR DLL in a process gives the attacker an anchor point so they no longer need to search for their APIs in shellcode.

Note: I’m intentionally glossing over some details here, so if you’re a die-hard exploit dev, don’t flame me.  My goal here is to make this digestible so I stop hearing calls of “so what” from the masses.

So back to Dropbox…

Dropbox decided not to compile with ASLR. There are a stunning number of 3^rd party Windows applications that don’t use ASLR, but this usually doesn’t create a problem for other applications.  Dropbox is different though because it loads code into many different processes started by the user, including the desktop (explorer.exe).  Now if one of these applications has a vulnerability and the target user is running Dropbox, the attacker can deliver much more trivial shellcode to exploit the vulnerability because they know some static addresses.

Dropbox has apparently fixed this for x64 but not the x86 versions of their DLLs.  For those who may not be aware, you can’t inject an x64 DLL into x86 code (or vice versa).  This means that even if you are running an x64 operating system you are probably still running x86 applications (which will load the x86 DLL).

But can this really be exploited?

Under the right conditions, yes.  It requires a vulnerability in another service that loads the x86 Dropbox DLL first.  Then, the attacker must know that the victim is using Dropbox.  If they are on the same LAN this is pretty easy due to LANSync.  In any case, Dropbox should know better and should be built with ASLR enabled.

Thanks to Graham Sutherland for posting the results of his research.

http://codeinsecurity.wordpress.com/2013/09/09/installing-dropbox-prepare-to-lose-aslr/

EFSS (e.g. Dropbox) helps bring home the bacon!

First, sorry it has been so long since I posted.  It has been a rough month, and I've been on the road a LOT.  I'll try to do better and make up for it over the coming weeks.

Mmm, bacon.  When I'm doing a penetration test, bacon is what I'm looking for. And while I like the crispy, tasty kind as much as the next guy (everything is better with bacon), I'm really looking for the security insights that help a client "get it."  We've all been there: we say something like "we totally owned your domain controller!"  But all the client can muster is a blank stare while they try to understand the gravity of the situation.  My countermeasure for this is to hit them where it hurts and express the threat in ways that business people understand.  To do that, I need to show the client the impact a vulnerability has on their "pork gathering" opportunities (i.e. bringing home the bacon).  The cool thing is that by demonstrating how their bacon quotient (I should trademark that) is impacted negatively, I simultaneously impact my bacon quotient in a positive way. 

As some of you know, I have a love/hate relationship with Dropbox and other enterprise file sharing services (EFSS).  As a network defender, given the lack of software to properly control data loss via an HTTPS encrypted channel, I don't really think EFSS belongs in most business environments. As a penetration tester, I love to see EFSS.  Why (other than the obvious: DropSmack)? Well, read on.

Want to find the juicy nuggets for your out brief?  Want to see what the target references the most?  It's in their EFSS sync folder. This has become especially useful since access time stamps were turned off in later versions of Windows.  If for instance a target uses a document but doesn't modify it, we have to resort to MRU or some other artifact to identify the files the target is using.

When EFSS is installed, you already know the files the target uses. They are the files synchronized between sites.  The fact that a target synchronizes files between sites implies that they need them in multiple locations.  This means they are the "important" files.  All things being equal, these are the files I'm going after.

Stay tuned for more insights on EFSS and network defense/penetration testing.