Send to Kindle

Researchers have cracked open cloud storage service Dropbox, reverse engineering the encryption protecting the client in order to open it up to further security analysis.

The engineers, Dhiru Kholia of Openwall and Przemyslaw Wegrzyn of CodePainters, also managed to demonstrate how to use code-injection techniques to intercept SSL data, essentially hijacking Dropbox communication, as well as bypass two-factor authentication used to protect accounts. The two researchers presented a paper on their work at the recent USENIX Security Symposium.

“Reversing Dropbox is the main focus of our paper,” Kholia told Threatpost. “The attacks are just side-effects.”

A Dropbox spokesperson said in an email to Threatpost that the duo’s findings do not represent a vulnerability in Dropbox. “In the case outlined here, the user’s computer would first need to have been compromised in such a way that it would leave the entire computer, not just the user’s Dropbox, open to attacks across the board,” the spokesman said.

Kholia concurred that hijacking a Dropbox client first requires hacking an existing vulnerability on the target user’s machine, which can be executed remotely.

“We believe that our biggest contribution is to open up the Dropbox platform to further security analysis and research,” the researchers wrote in their paper. “Dropbox will/should no longer be a black box.”

The research reveals how the internal API used by the Dropbox client works. Using a number of techniques, Kholia and Wegrzyn were able to decompile the Dropbox client source code and examine it. While previous work exists in this field, it’s applicable only to older versions of Dropbox, the researchers said. Patches have been applied by the Dropbox team that prevented them from applying previously successful research in this case.

In addition, they were able to use Reflective DLL injection and LD_PRELOAD on Windows and Linux respectively to intercept SSL traffic.

“Once we are able to execute arbitrary code in Dropbox client context, we patch all SSL objects and are able to snoop on the data before it has been encrypted (on sending side) and after it has been decrypted (on receiving side),” the paper said. “This is how we intercept SSL data. We have successfully used the same technique on multiple commercial Python applications.”

They also learned that the two-factor authentication used to access Dropbox on the Web isn’t supported on the client and the client can be accessed with a  value known as host_ID, which they were able to gain.

While the team plans further research into Dropbox security and encourages the security community to take its shots, they acknowledge the client’s security is a constantly moving target, one that has remained fairly safe.

“Overall, Dropbox is just fine,” Kholia said. “There is nothing to worry about. We are still using and loving it.”

Image courtesy JeanbaptisteM.

Send to Kindle
Categories: Hacks

Comments (4)

  1. illwill
    1

    hey we have access to your machine, which also has your unencrypted dropbox contents, so we’re going to inject into your dropbox program instead and intercept traffic from it. makes sense.

    • noclue
      2

      Clearly you have never attacked a system before in your life. You do not already need to have access to the target to pull off a DLL injection attack. There are scenarios, that I won’t bother explaining as you will more than likely not get it anyways, where you do not want or cannot get full access to the system and may wish to only target encrypted Dropbox connections.

      • secular
        3

        Oh, please enlighten us, how you would inject code without having access to the target. Because if you can overwrite arbitrary memory (or can execute code, which is closely related), you DO have access to the system.

  2. wac
    4

    Well interception of traffic is done to analyze protocol because when encrypted by SSL/TLS is not possible. Now understand? Also is a way to intercept authentication data normally you don’t have even with a compromised machine cause it is held in memory or encrypted somewhere in the hardrive. Menas yes you could access the unencrypted files in that computer but you don’t have a way to know credentials unless for instance you use a keylogger or something and make the user type the password again. In any case this proves all of that encryption is nothing but a waste of time and in no way security by obscurity is going to keep you safer.

Comments are closed.