Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Python Security Software

Researchers Reverse-Engineer Dropbox, Cracking Heavily Obfuscated Python App 242

rjmarvin writes "Two developers were able to successfully reverse-engineer Dropbox to intercept SSL traffic, bypass two-factor authentication and create open-source clients. They presented their paper, 'Looking inside the (Drop) box' (PDF) at USENIX 2013, explaining step-by-step how they were able to succeed where others failed in reverse-engineering a heavily obfuscated application written in Python. They also claimed the generic techniques they used could be applied to reverse-engineer other Frozen python applications: OpenStack, NASA, and a host of Google apps, just to name a few..."
This discussion has been archived. No new comments can be posted.

Researchers Reverse-Engineer Dropbox, Cracking Heavily Obfuscated Python App

Comments Filter:
  • by Anonymous Coward on Wednesday August 28, 2013 @01:25AM (#44694169)

    Good thing I stopped playing the game.
    It's hosed now.

  • by You're All Wrong ( 573825 ) on Wednesday August 28, 2013 @01:27AM (#44694179)
    Sounds remarkably like security through obscurity to me. With the predictable outcome.

    You have no right to feel secure if you only think you're secure assuming noone else examines your source code.
    http://en.wikipedia.org/wiki/Kerckhoffs%27s_principle
    • by odie5533 ( 989896 ) on Wednesday August 28, 2013 @01:44AM (#44694247)
      This sounds remarkably like security + obfuscation to me. The two are not necessarily mutually exclusive. If they had released it open source, one could argue that with more eyes reading the code they would be able to find and eliminate bugs or security issues. But this is not necessarily true. And they clearly did not want to release the software open source.
      • by epyT-R ( 613989 ) on Wednesday August 28, 2013 @01:58AM (#44694291)

        Actually, it's not dependent on whether the code is open or not. It's dependent on the design. If the design requires secret bits to stay hidden in the client, then open sourcing it would make it even more trivial to break, but with such designs, it would not matter whether it was open source or not. The huge library of cracked software out there speaks volumes to this.

    • by You're All Wrong ( 573825 ) on Wednesday August 28, 2013 @01:46AM (#44694255)
      Reading the paper, googling for the debug hash, lead to this from 2012 which covers a lot of the same ground:

      http://archive.hack.lu/2012/Dropbox%20security.pptx
      "A critical analysis of Dropbox software security", Florian LEDOUX
    • by six025 ( 714064 ) on Wednesday August 28, 2013 @02:41AM (#44694399)

      Sounds remarkably like security through obscurity to me. With the predictable outcome.

      You have no right to feel secure if you only think you're secure assuming noone else examines your source code.

      To what level do you take the paranoia, though?

      As early as 1984 (hah!) it has been known that a compiler could be developed in such a way as to produce binaries containing a back door:

      http://c2.com/cgi/wiki?TheKenThompsonHack [c2.com]

      The next level is CPU microcode. Where does it end? One day we can fab our own CPUs from Open Source designs ... but will that be enough?

      Peace,
      Andy.

    • by black3d ( 1648913 ) on Wednesday August 28, 2013 @03:53AM (#44694577)

      A lot of the commentators in this article are mentioning "security through obscurity" as if the fact it doesn't work long-term should be some revelation to the Dropbox team, or that Dropbox has somehow dropped the ball through using this method. It's an unfair stance to take, considering that outside of hardware based platforms like TPM, *ALL* client-side software security is at best security through obscurity.

      The only news here is that Dropbox is the latest fairly major player to have their client reverse-engineered. Obfuscation is merely a means of delaying the inevitable, and for all we know it has done it's job wonderfully. Plenty of other people may have tried to reverse-engineer the code before but gave up because of the complexity of the obfuscation. The fact that an 'adversary' has dedicated sufficient time and commitment to the effort is news to be sure, but the news shouldn't be turned into "Dropbox did a bad". Anyone with any reasonable experience in IT (which I'd hope most readers here have) should know by now that there are no means to secure software on a computer which someone has control of.

      • by aaaaaaargh! ( 1150173 ) on Wednesday August 28, 2013 @05:52AM (#44694923)

        You're missing the point, which is that Dropbox did bad by obfuscating the code, because they should have made it Open Source right from the start and focus on selling their server-side hosting services. Keeping client code proprietary when it involves security and encryption of possibly confidential data is virtually always bad practise (outside the realm of embedded military applications using tamper-proof chips, perhaps).

        • You're missing the point, which is that Dropbox did bad by obfuscating the code, because they should have made it Open Source right from the start and focus on selling their server-side hosting services. Keeping client code proprietary when it involves security and encryption of possibly confidential data is virtually always bad practise (outside the realm of embedded military applications using tamper-proof chips, perhaps).

          "Always" is a strong word to use and speaks more of ideology than of reality.

          • "Always" is a strong word to use and speaks more of ideology than of reality.

            It's always bad security practice, but it's fine practice if all you want to do is get money and don't care about people's security. Presumably they've indemnified themselves for anything that might happen to your data in the ToS, so they don't have to care.

          • by Millennium ( 2451 ) on Wednesday August 28, 2013 @08:28AM (#44695761)

            "Always" is a strong word to use and speaks more of ideology than of reality.

            Not always.

          • When the options are "only your hired staff reviews the security features" and "your staff plus outside researchers review the security features", the latter is always better. And releasing the source code is the easiest way to facilitate useful outside review.

        • by Yaur ( 1069446 ) on Wednesday August 28, 2013 @11:41AM (#44697671)
          The advantage of keeping client code closed is that you can make breaking API changes much more easily. If you have an open client and an open API you are stuck with them and you need to spend a lot more time making sure that they are correct and complete. With a client based on reverse engineering you have no right to be surprised when it suddenly breaks.
        • by DigitAl56K ( 805623 ) on Wednesday August 28, 2013 @01:45PM (#44698679)

          You're missing the point, which is that Dropbox did bad by obfuscating the code, because they should have made it Open Source right from the start and focus on selling their server-side hosting services.

          Wrong.

          Sure, that's easy to say in hindsight, now that they have built an extremely well established business out of it and are the premiere brand in the space. If they had open sourced it right from the start then they would have all the client and client-server development costs on their plate, meanwhile Joe Shmoe could have come along and copied it, pointed it at his own servers, and took a substantial chunk of the business opportunity with much less investment overhead.

          In business you have to find a compromise between your ideals and reality. "Your ideals" perhaps not being the same as their ideals, either.

    • by robmv ( 855035 )

      How do you propose to write it? you need a stable API (private if you don't want anyone using it) and an application that runs on your customers machine. Please tell me how you can secure the use of your private API more than obfuscating the client code. I can tell you the answer, It isn't possible unless you start using TPMs and only run on hardware and OSs that force the usage of it, and that can be hacked too

      There are only two outcomes of this:

      1- Dropbox learns that it is good to have an open API, and ge

    • It's "Unmaintainability Through Obscurity." There never was any (even falsely-justified) security component to it. Nobody is going to say this has somehow made Dropbox less safe.

  • by RightSaidFred99 ( 874576 ) on Wednesday August 28, 2013 @01:36AM (#44694213)

    They also claimed the generic techniques they used could be applied to reverse-engineer other Frozen python applications: OpenStack...

    Wow, they can reverse engineer OpenStack? That's amazing - what do they use, an obscure set of commands called "wget", "git", and "tar"?

    • Re: (Score:2, Informative)

      by Anonymous Coward

      Andrew Tridgell was accused of "hacking" BitKeeper because he telnetted in and typed "HELP".

  • by Anonymous Coward on Wednesday August 28, 2013 @01:54AM (#44694283)

    They should have written it in perl.

  • Waste of resources (Score:5, Insightful)

    by xenobyte ( 446878 ) on Wednesday August 28, 2013 @01:58AM (#44694289)

    Why do so many developers waste time on obfuscation and other ways of hiding the source in scripting languages?

    Using utilities like IonCube to 'protect' PHP-code will never stop the dedicated people from reverse engineering the application or re-engineering it. I've seen that countless times. It is security-through-obscurity at best and it will prevent people from both fixing bugs and re-submitting the fixed code to the developers, and finding security issues from simple code reviewing.

    If developers of competing applications needs to steal code they're really crappy developers and whatever that makes their application unique will be equally crappy and thus not a threat.

    • by cerberusss ( 660701 ) on Wednesday August 28, 2013 @02:08AM (#44694317) Journal

      Using utilities like IonCube to 'protect' PHP-code will never stop the dedicated people from reverse engineering the application or re-engineering it.

      No, but it will stop support calls from clients that are the result of messing with the code.

      • Wouldn't file checksums do a good enough job of identifying tampered code?
        • by jandrese ( 485 )
          If your code is open source, file checksums are no hurdle at all. I mean if someone is modifying your code, what's going to stop them from modifying the stored checksum as well?
    • Why do you lock your front door when you leave the house?
    • by lorinc ( 2470890 )

      Why do so many developers waste time on obfuscation and other ways of hiding the source in scripting languages?

      Using utilities like IonCube to 'protect' PHP-code will never stop the dedicated people from reverse engineering the application or re-engineering it. I've seen that countless times. It is security-through-obscurity at best and it will prevent people from both fixing bugs and re-submitting the fixed code to the developers, and finding security issues from simple code reviewing.

      If developers of competing applications needs to steal code they're really crappy developers and whatever that makes their application unique will be equally crappy and thus not a threat.

      Which brings us to the next point: If obfuscation is worthless and someone will steal you code whatever you do, just release it with an open source license in the first place.

      My guess is that the short amount of time between the release and the cracking is where the management expects to make profit, and even more profit than if it was FLOSS in the first place. This highlights greatly the short-term objectives of today's business.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        "Short" amount of time? Dropbox has been around for years, during which they've established themselves as the top brand in this space, even ahead of companies like Google or Microsoft.

        Only in autistic/retard world is "In 5 years someone might get around to reversing this" the same as "a waste of time".

      • and someone will steal you code whatever you do

        I doubt anyone will steal anyone's code.

    • by smash ( 1351 ) on Wednesday August 28, 2013 @03:35AM (#44694523) Homepage Journal
      Because if you can raise the bar in terms of effort required to be equal to, or more than just writing your own damn product, then you'll get less people freeloading off your development.
      • Writing one's own product doesn't really help to interoperate with the service in which your potential customers are already storing their data.
    • by jrumney ( 197329 )

      Obfuscation also helps with code size, which is especially important for code that is downloaded, like Javascript and CSS, since one of the first things that obfuscators do is change all the symbols in your program to short names (duplicating where possible), starting from a, working up to z then aa...az etc.

    • Why do so many developers waste time on obfuscation and other ways of hiding the source in scripting languages?

      Because the boss tells us to.

      This is spoken as someone who has been asked to obfuscate javascript. I spent a few minutes trying to explain why this was an utter waste of time and such but the problem is that the boss knows a bit of JS code so looked at it and could understand it. He then googled "javascript obfuscation" and found a product that made the code so he could no longer understand it. The fact that I said I could still understand it he just blamed on me having created it.

      The problem was that this

      • I have long since given up trying to explain why trying to hide what is ostensibly an open technology does is a complete waste of time.

        It's not necessarily complete waste. All scrambled JavaScript code can be returned into an understandable form, that's for sure. But by obfuscating the code, you're always adding some extra puzzle to those who want to steal your code. And if they come across someone else's code which isn't scrambled, they might decide it's easier grab than yours and leave you alone. So by obfuscating, you assure that at least you're not the easiest target out there.

        • It's not necessarily complete waste. All scrambled JavaScript code can be returned into an understandable form, that's for sure. But by obfuscating the code, you're always adding some extra puzzle to those who want to steal your code.

          Steal your code? Will they be deleting it from your servers?

          The right way to handle this situation is to not do a bunch of client-side js yourself. And why would you?

          • It's not necessarily complete waste. All scrambled JavaScript code can be returned into an understandable form, that's for sure. But by obfuscating the code, you're always adding some extra puzzle to those who want to steal your code.

            Steal your code? Will they be deleting it from your servers?

            The right way to handle this situation is to not do a bunch of client-side js yourself. And why would you?

            In my case it was because I had to produce something that was scorm 1.2 compatible (http://en.wikipedia.org/wiki/Sharable_Content_Object_Reference_Model). That meant I had to use javascript as to produce a scorm compatible course there has to be no server side code (Only flash or JS). I should have used flash but that would have meant me spending 6 months learning actionscript before having anything to show for it.

  • Insecure by design (Score:5, Insightful)

    by nomaddamon ( 1783058 ) on Wednesday August 28, 2013 @03:19AM (#44694487)
    The point of the article wasn't to crack it, it was to show that if something sounds insecure by design, it is insecure...

    DropBox allows you to "log in" to it's website via click in the application -> no credentials required. Therefore it must either store user credentials or some other secret(s) on client side (host_id and host_int in this case).

    Any process running under privileges accessible to you can be cracked (albeit sand-boxing, in which case you need system privileges) and it can't hide data from end-user / other processes in same privilege space (albeit sand-boxing....).
    They can make it more difficult though (extracting Bluray key from windows media player will take anyone at least a few days)

    More and more big companies think they can hide data on client side and be secure. Dropbox, Windows Live (LiveConnect) and numerous others are now relying on fast exchange of nonces in addition to client-side secret storing to make it secure "enough".. But breaking the nonce handshake and authenticating in programmatic fashion will add maybe 10% more cracking/programming effort on top of the regular cracking effort.

    TLDR: If it is insecure by design, it is insecure and no amount of obfuscation will help you....
    • by smash ( 1351 )

      TLDR: If it is insecure by design, it is insecure and no amount of obfuscation will help you....

      Newsflash: encryption delcared to be pointless on slashdot!

      More seriously, if you're (not the poster above) storing unencrypted data on dropbox, joke's on you...

    • Re: (Score:2, Interesting)

      by Inda ( 580031 )
      "others are now relying on fast exchange of nonces"

      Is that a typo or a new word in programming?

      1. nonce. (UK) Slang for paedophile or sex offender
    • DropBox allows you to "log in" to it's website via click in the application -> no credentials required. Therefore it must either store user credentials or some other secret(s) on client side (host_id and host_int in this case).

      This could in principle be secure, e.g. if the app requests a new session ID, and launches the web browser with that session ID in a GET parameter. No secret needs to be stored, you just need to be logged in with the app already.

  • Presentation slides (view online or download PDF), and links to the paper (PDF) and "dedrop" source code (GitHub):
    http://www.openwall.com/presentations/WOOT13-Security-Analysis-of-Dropbox/ [openwall.com]

    USENIX WOOT '13 web page dedicated to this talk, including video and audio (view/listen online or download the video .mp4 via a direct link from there):
    https://www.usenix.org/looking-inside-drop-box [usenix.org]

    (Somehow the Slashdot story only links to a third-party article and to the paper PDF, but not to any of the authors' and the c

  • What happens when Dropbox changes how everything works. How long before it is reverse engineered again. That's why I wouldn't want to depend on this kind of hack for anything.

  • I wonder if the developers promised that it was "basically impossible" to decompile the code. Or did the developers more honestly say, "this will buy us a bunch of time."
    • I wonder if the developers promised that it was "basically impossible" to decompile the code. Or did the developers more honestly say, "this will buy us a bunch of time."

      Management: Make sure people don't steal our stuff!
      Developers: Okay, uhhh . . . it's obsfucated now, is that good?
      Management: Don't give me any of your technical mumbo-jumbo, is our IP secure? We can't monetize it without keeping our secret sauce.
      Developers: ...yeah, sure.
      Management: Good enough for me! I'm going on a business lunch,

      • I wonder how many HTML/Javascript developers have been instructed to make it "impossible" to steal the site's forward facing code?

        "OK I'll use the META tag IMPOSSIBLE=true."
  • There are already a lot of dropbox alternatives that have open source clients and even ones that do encryption. But there isn't a good Skype alternative I've seen that lets me participate in Skype group chats. I don't even care about video/audio chat. Can someone reverse engineer the Skype client next?

  • by Orp ( 6583 ) on Wednesday August 28, 2013 @12:27PM (#44698011) Homepage
    I've always assumed that data on Dropbox wasn't very secure, which is why I was happy to find that ecryptfs works well with dropbox across multiple machines (assuming they are all running Linux). To wit:

    chinook: ~orp df /home/orp/e
    Filesystem          1K-blocks      Used Available Use% Mounted on
    /home/orp/Dropbox/e 491451392 129077764 361240528  27% /home/orp/e
    chinook: ~orp ls Dropbox/e
    ./
    ../
    ECRYPTFS_FNEK_ENCRYPTED.FWZS4gY2TLKRZUavoct.ewyb3LhUsTmtMCkw6-7kc4NR3-58yIKIxSsrgk--
    ECRYPTFS_FNEK_ENCRYPTED.FWZS4gY2TLKRZUavoct.ewyb3LhUsTmtMCkw9VkRKmwOO95LV0W1qwwNHk--/
    ECRYPTFS_FNEK_ENCRYPTED.FWZS4gY2TLKRZUavoct.ewyb3LhUsTmtMCkwKsqUWInaV2aVwzvhw6CcW---
    ECRYPTFS_FNEK_ENCRYPTED.FWZS4gY2TLKRZUavoct.ewyb3LhUsTmtMCkwOggoYf2PUQpQQmgJLHwIaU--/
    ECRYPTFS_FNEK_ENCRYPTED.FWZS4gY2TLKRZUavoct.ewyb3LhUsTmtMCkwQEdvushvgMYZ2uRpeRJ9EU--
    [etc]

    This works with the same partition mounted across multiple machines. Save a file to /home/orp/e, and it "magically" appears in its unencrypted form (name, content) on any other machine that was updated on Dropbox that has the encrypted partition mounted the same way. All dropbox ever sees is the encrypted stuff.

    The main disadvantage to this approach is that if you are trying to access files on a non-linux machine you are hosed; Lastpass and other password managers that have file encryption functionality can give you cross-platform encryption but not with the nice filesystem access that Dropbox provides.

It's currently a problem of access to gigabits through punybaud. -- J. C. R. Licklider

Working...