Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Researchers Reverse-Engineer Dropbox, Cracking Heavily Obfuscated Python App

Soulskill posted 1 year,5 days | from the turns-out-it's-just-23,000-nested-if-statements dept.

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

cancel ×

242 comments

Sorry! There are no comments related to the filter you selected.

Where is your god now? (0, Funny)

Anonymous Coward | 1 year,5 days | (#44694127)

/popcorn

Re:Where is your god now? (0)

Anonymous Coward | 1 year,5 days | (#44694177)

Sitting on a computer... /cornpop

Re:Where is your god now? (5, Funny)

Anonymous Coward | 1 year,5 days | (#44694203)

Better delete your dropbox-hosted /copporn

Python? Really? (-1)

Anonymous Coward | 1 year,5 days | (#44694161)

Use a non-compiled language, get what you deserve...

Re:Python? Really? (5, Informative)

epyT-R (613989) | 1 year,5 days | (#44694189)

even then, all it takes is someone versed in the assembly language of the platform your application runs on, a copy of IDA pro or something similar, and a few hours of his time. I know this is a bit of a lost art in today's world of python and javascript, but it's still valid.

Re:Python? Really? (1, Interesting)

StripedCow (776465) | 1 year,5 days | (#44694643)

Python and javascript are syntactically much more difficult to master than assembly language.
Plus, there are way more privitives to learn...

Re:Python? Really? (2)

StripedCow (776465) | 1 year,5 days | (#44694649)

Privitives -> primitives

Re:Python? Really? (-1)

HetMes (1074585) | 1 year,5 days | (#44695105)

Assembly is art in programming like chiseling in stone is in writing books.

Re:Python? Really? (1)

loufoque (1400831) | 1 year,5 days | (#44695183)

That only works reliably for C-like code though.

Re:Python? Really? (2)

aliquis (678370) | 1 year,5 days | (#44694217)

Clever of you to post as AC.

Because no compiled (or assembled) code has ever been cracked.

Re:Python? Really? (1)

ThatAblaze (1723456) | 1 year,5 days | (#44694251)

Rediculous! [youtube.com]

Re:Python? Really? (2)

You're All Wrong (573825) | 1 year,5 days | (#44694287)

Fuck, that woooosh just blew my wig off!

Re:Python? Really? (-1)

Anonymous Coward | 1 year,5 days | (#44694373)

Is it that hard to spell "ridiculous" correctly?

Re:Python? Really? (0)

ciderbrew (1860166) | 1 year,5 days | (#44694579)

Is it that hard to understand what dixlecia is?

Re:Python? Really? (-1)

Anonymous Coward | 1 year,5 days | (#44695079)

WTF is dixlecia? Use a spelling checker, fucktard.

Re:Python? Really? (-1)

Anonymous Coward | 1 year,5 days | (#44695131)

Is dixlecia when you have a hard time talking because you have two dicks in your mouth?

Re:Python? Really? (4, Informative)

You're All Wrong (573825) | 1 year,5 days | (#44694279)

I hope your sarcasm is understood, it's a dangerous technique to use on the internet.

However, there's an interesting twist to the pcode vs. native code dichotomy, from reverse engineering standpoint, as anyone who's well versed in the brain-mangling line noise that calls itself the IOCCC will know. One of the best obfuscations is to embed an interpreter into your code, and then do all the hard work in the bytecode.

Re:Python? Really? (4, Informative)

davester666 (731373) | 1 year,5 days | (#44694443)

Been there. Done that.

I believe it was EA that was doing that way back as part of their DRM for their Commodore 64 disk-based games. It would load the interpreter and a script, then execute the script [drawing it's fancy startup screens, checking for various bad sectors on their disk, over-writing parts of the script and interpreter, loading the game from various parts of the disk].

Re:Python? Really? (3, Informative)

buchner.johannes (1139593) | 1 year,5 days | (#44694631)

Use a non-compiled language, get what you deserve...

Python is compiled, if you distribute *.pyc files only.

Well, there goes Eve Online (3, Interesting)

Anonymous Coward | 1 year,5 days | (#44694169)

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

Re:Well, there goes Eve Online (0)

Anonymous Coward | 1 year,5 days | (#44694243)

Wait, why?

Re:Well, there goes Eve Online (0)

thatkid_2002 (1529917) | 1 year,5 days | (#44694265)

EVE uses IronPython which compiles down to the CIL (like other Microsoft languages, like C#) so it is not a frozen Python application. Similarly, if there was a Python implementation for LLVM it would be the same situation. AFAIK.

Re:Well, there goes Eve Online (4, Informative)

marcansoft (727665) | 1 year,5 days | (#44694385)

EVE doesn't use IronPython. It uses Stackless Python. And yes, it is possible to decompile the code, and it has been done in the past.

http://evesupernerf.blogspot.co.uk/2012/05/decompiling-eve-client.html [blogspot.co.uk]
https://github.com/wibiti/evedec/blob/master/evedec.py [github.com]

Re:Well, there goes Eve Online (5, Funny)

MBGMorden (803437) | 1 year,5 days | (#44694417)

And yes, it is possible to decompile the code, and it has been done in the past.

Awesome. With any luck they'll get an alternative client working. Shouldn't be too hard to set it up as a plugin to Microsoft Excel.

Re:Well, there goes Eve Online (5, Funny)

Anonymous Coward | 1 year,5 days | (#44694489)

Awesome. With any luck they'll get an alternative client working. Shouldn't be too hard to set it up as a plugin to Microsoft Excel.

You've already got a flight simulator, what more do you want??

Re:Well, there goes Eve Online (5, Funny)

Anonymous Coward | 1 year,5 days | (#44694503)

A spreadsheet simulat.... wait...

Re:Well, there goes Eve Online (0)

Anonymous Coward | 1 year,5 days | (#44695207)

Excel 97 included a flight simulator as an easter egg (95 had a Hall of tortured souls, and 2000 had a driving minigame).

Re:Well, there goes Eve Online (1)

h4nk (1236654) | 1 year,5 days | (#44694497)

ha

Re:Well, there goes Eve Online (1)

thatkid_2002 (1529917) | 1 year,5 days | (#44694863)

Oops. Got mixed up.

Re:Well, there goes Eve Online (-1)

Anonymous Coward | 1 year,5 days | (#44694583)

Not really, i have done code injection into EVE's client back in 2009 and disassembling all their python code from the inside is trivial. Hell they even have dis in there :P

Obfuscated python code? (5, Insightful)

You're All Wrong (573825) | 1 year,5 days | (#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

Re:Obfuscated python code? (4, Insightful)

odie5533 (989896) | 1 year,5 days | (#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.

Re:Obfuscated python code? (4, Insightful)

epyT-R (613989) | 1 year,5 days | (#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.

Re:Obfuscated python code? (5, Informative)

You're All Wrong (573825) | 1 year,5 days | (#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

Re:Obfuscated python code? (4, Interesting)

six025 (714064) | 1 year,5 days | (#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.

Re:Obfuscated python code? (1)

loufoque (1400831) | 1 year,5 days | (#44695245)

How do you know the machine building your CPU will not inject a backdoor in it?

Re:Obfuscated python code? (0)

Anonymous Coward | 1 year,5 days | (#44694451)

Re:Obfuscated python code? (5, Insightful)

black3d (1648913) | 1 year,5 days | (#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.

Re:Obfuscated python code? (5, Insightful)

aaaaaaargh! (1150173) | 1 year,5 days | (#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).

Doesn't the Dropbox EULA... (0)

Anonymous Coward | 1 year,5 days | (#44694191)

...have a no-reverse-engineering clause?

Re:Doesn't the Dropbox EULA... (4, Insightful)

epyT-R (613989) | 1 year,5 days | (#44694211)

Lawyers have trouble understanding that law doesn't dictate the limits of curiosity, greed, mathematics, or physics. If there is sufficient incentive, it WILL be cracked. In this case, I think they wanted to demonstrate that drop box is not secure. This should be a 'duh' experience for anyone in IT worth their salt.

Re:Doesn't the Dropbox EULA... (1)

phantomfive (622387) | 1 year,5 days | (#44694235)

To me, the fascinating thing is that someone wanted to do that.

Re:Doesn't the Dropbox EULA... (5, Interesting)

epyT-R (613989) | 1 year,5 days | (#44694299)

Why? If you're looking for the selfish angle, maybe he/they just wanted the notoriety. However, he/they might've just wanted to do a public service. Most people trust dropbox to be secure. Of course, slashdot users should all know better than to trust the 'cloud' for anything sensitive, but a way to get this info to people who would not otherwise know this is to make a splash about a successful pen-test.

Lots of guys see it as a challenge; the digital equivalent of saying 'you can't have this.' Well, challenge accepted.

Re:Doesn't the Dropbox EULA... (0)

Full of shit (2908417) | 1 year,5 days | (#44694435)

That assumes they got their hands on you compiler too. Any company shipping their open source code and a closed source compiler for it would invite suspicion.

Re:Doesn't the Dropbox EULA... (5, Insightful)

black3d (1648913) | 1 year,5 days | (#44694619)

How is Dropbox not secure? Do you mean the client you have control of isn't secure? That's all the article is speaking of - they haven't found a way to steal your data from Dropbox unless they already have a secret from your PC.

In order to access your account, they need the secret host_id (which is generated per device and unique to that device) and host_int from your computer (although, if they already have host_id, they can get host_int from the server - so really, they only need host_id). Presuming they have access to your computer, they can use these keys to access your account. (ie, without actually having your password). If they already have access to your computer however - well, at this stage we're splitting hairs. Any software which stores your login credentials on your own computer is at best hiding an access method through obscurity.

The only way to avoid this is to require you to enter your password each time you want to sync your files. Same with Google Drive. Same with .. every piece of software that stores login credentials on the client. Calling DropBox "insecure" when you actually mean "as secure as any client-side auto-login software can be" is a misnomer.

Re:Doesn't the Dropbox EULA... (1)

buchner.johannes (1139593) | 1 year,5 days | (#44694669)

Lawyers have trouble understanding that law doesn't dictate the limits of curiosity, greed, mathematics, or physics. If there is sufficient incentive, it WILL be cracked.

Non sequitur. Law also dictates that you can not steal and break into someone elses vault (limiting physics arguably). There will be sufficient incentive that people will do it nevertheless, thereby breaking the law. That does not mean it is an invalid law.

Re:Doesn't the Dropbox EULA... (0)

Anonymous Coward | 1 year,5 days | (#44694943)

Non sequitur.

How is that a non sequitur? That logic is absolutely correct even if it applies to other things as well.

That does not mean it is an invalid law.

Where did he say that it is?

Re:Doesn't the Dropbox EULA... (1)

Anonymous Coward | 1 year,5 days | (#44694231)

Wouldn't that only be applicable if:

a> these people were "End users"
b> it was enforceable in their jurisdiction

Re:Doesn't the Dropbox EULA... (2)

Dahamma (304068) | 1 year,5 days | (#44694269)

Wouldn't that only be applicable if:

a> these people were "End users"
b> it was enforceable in their jurisdiction

Actually, yes, but if they *aren't* it falls under the DMCA, which is much, MUCH worse...

And jurisdiction... well... http://www.youtube.com/watch?v=EOJNs5YPR4g [youtube.com]

Re:Doesn't the Dropbox EULA... (1)

Anonymous Coward | 1 year,5 days | (#44694645)

Actually, yes, but if they *aren't* it falls under the DMCA, which is much, MUCH worse...

And jurisdiction... well... http://www.youtube.com/watch?v=EOJNs5YPR4g [youtube.com]

*if* they live in murica... but they could just as well live somewhere in the *rest* of the world.

Re:Doesn't the Dropbox EULA... (1)

Barefoot Monkey (1657313) | 1 year,5 days | (#44695123)

The link in TFA says that Przemyslaw Wegrzyn is from Poland. No idea about Dhiru Kholia but that's not a typical name for the US.

Re:Doesn't the Dropbox EULA... (1)

gnupun (752725) | 1 year,5 days | (#44694513)

See yesterday's slashdot article where the article author claims that no one will steal your ideas [slashdot.org] . No-reverse-engineering clauses in EULAs exist to prevent competitors from cloning software by disassembling and studying its internals. Did the researchers break a (valid) contract?

Wow, amazing. (5, Funny)

RightSaidFred99 (874576) | 1 year,5 days | (#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:Wow, amazing. (0)

Anonymous Coward | 1 year,5 days | (#44694679)

Apparently they used a sophisticated web hacking process to discover a site where they can view and download the entire source code IN PLAIN TEXT!

Re:Wow, amazing. (2, Informative)

Anonymous Coward | 1 year,5 days | (#44694947)

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

Trying to obfuscate python was never going to work (5, Funny)

Anonymous Coward | 1 year,5 days | (#44694283)

They should have written it in perl.

Re:Trying to obfuscate python was never going to w (2, Funny)

Anonymous Coward | 1 year,5 days | (#44694457)

They should have written it in perl.

They would have missed the fun of seeing how obfuscation made the code harder to read.

Re:Trying to obfuscate python was never going to w (5, Funny)

Buchenskjoll (762354) | 1 year,5 days | (#44694875)

Yes, only with Perl would they be able to implement security through obscurity and open-source it at the same time.

Re:Trying to obfuscate python was never going to w (0)

Anonymous Coward | 1 year,5 days | (#44695103)

I remember an old co-worker referring to perl as "a write only language". I was young and dumb and didn't get what he meant. Until 1 year later when I tried to add a new feature to my perl script.

Waste of resources (4, Insightful)

xenobyte (446878) | 1 year,5 days | (#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.

Re:Waste of resources (4, Interesting)

cerberusss (660701) | 1 year,5 days | (#44694317)

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.

Re:Waste of resources (2)

wonkey_monkey (2592601) | 1 year,5 days | (#44694329)

Why do you lock your front door when you leave the house?

Re:Waste of resources (5, Funny)

Anonymous Coward | 1 year,5 days | (#44694397)

To lock the crazy people inside.

Re:Waste of resources (0)

Anonymous Coward | 1 year,5 days | (#44694427)

I'm in an apartment with a self-locking door, you insensitive clod!

Re:Waste of resources (5, Insightful)

SJ (13711) | 1 year,5 days | (#44694449)

Bad analogy.

Code obfuscation is more akin to locking your door, and then hiding the key behind the pot plant.

Re:Waste of resources (0)

Anonymous Coward | 1 year,5 days | (#44694493)

Code obfuscation is more akin to locking your door, and then hiding the key behind the pot plant.

OK, OK. You are one of those folks who *need* code obfuscation.

Re:Waste of resources (0)

Anonymous Coward | 1 year,5 days | (#44694637)

Worse analogy.

Code obfuscation is akin to locking your door and then hiding the key behind the pot plant ONLY when lack of code obfuscation is akin to locking your door and then hanging the key from the handle.

Re:Waste of resources (1)

neonsignal (890658) | 1 year,5 days | (#44694673)

Actually, it's more like not locking it at all, and putting a big potplant in front of the door to hide it...

Re:Waste of resources (0)

Anonymous Coward | 1 year,5 days | (#44694703)

Bad move. That's the first place Leo (aka Tommy Chong) will look, and then he'll go in and eat everything in your fridge, man.

Re:Waste of resources (0)

Anonymous Coward | 1 year,5 days | (#44695263)

Do you mean the pot plant or the potted plant? Or the planted pot, for that matter.

Re:Waste of resources (3, Interesting)

Errol backfiring (1280012) | 1 year,5 days | (#44694567)

Why do you paint bricks and fake keyholes on your door when you leave the house?

There, fixed that for you. Obfuscation is more like dazzle painting [wikipedia.org] . It works somewhat, but don't expect it to work well.

Re:Waste of resources (0)

Anonymous Coward | 1 year,5 days | (#44695025)

Why do you paint bricks and fake keyholes on your door when you leave the house?

There, fixed that for you. Obfuscation is more like dazzle painting [wikipedia.org] . It works somewhat, but don't expect it to work well.

No. It's much more like Vajazzling [gawker.com] and less useful.

Re:Waste of resources (0)

Anonymous Coward | 1 year,5 days | (#44694953)

Code obfuscation is like giving someone something and telling them it performs function X, but purposefully making it difficult for them to verify that that's what it actually does for themselves; it could do something completely different, which could even be something harmful. It's immoral, in other words.

Wake me up when my locking the front door harms other people; it's my property, and it damn well isn't code running on someone else's system.

Re:Waste of resources (1)

lorinc (2470890) | 1 year,5 days | (#44694341)

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:Waste of resources (2, Insightful)

Anonymous Coward | 1 year,5 days | (#44694353)

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

Re:Waste of resources (1)

Anonymous Coward | 1 year,5 days | (#44694521)

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

Still cracks me up talking about how they "established" themselves as THE free cloud space provider above all other free cloud space providers, as if their clouds were somehow whiter and brighter than everyone else's.

Boy, how I love me some Dropbox flavored ones and zeros in the morning! All the others taste like generic binary shit, but those Dropbox-flavored bits with the marshmallow IP stack...mmmmm

Re:Waste of resources (0)

Anonymous Coward | 1 year,5 days | (#44694569)

I think their business idea was to market and sell a "secure" (not secure in our ears but in the public's) service that is easy to use. A much better idea would have been to market and sell a secure (in everybody's ears) service with an open protocol. They would possibly have had more competition and it may have been harder but they could have made it in the long run. Now it's just a lousy service with a lot of problems that will get consumed by a better one soon.

I have only tried it once to see what it was and I always recommend people not to use it because of the broken security model. By that I mean that they see what you store.

Re:Waste of resources (1)

cheekyjohnson (1873388) | 1 year,5 days | (#44694957)

and someone will steal you code whatever you do

I doubt anyone will steal anyone's code.

Re:Waste of resources (4, Informative)

smash (1351) | 1 year,5 days | (#44694523)

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.

Re:Waste of resources (1)

jrumney (197329) | 1 year,5 days | (#44694605)

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.

Re:Waste of resources (2)

Ash Vince (602485) | 1 year,5 days | (#44694763)

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 was dynamically generated JS so I had to then go away and incorporate obfuscation into my server side code. I tried to do the best I could and make the result really hard to understand (once I am given a task I hate doing a poor job, even if it is a waste of time) but one of our competitors he gave access to the end result still reverse engineered it and copied it in a few months.

Now it is back on my task list again to go and revisit it and make the end result more cryptic using the stuff I learned by looking at our competitors similar solution. 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.

Re:Waste of resources (1)

jones_supa (887896) | 1 year,5 days | (#44695101)

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.

Tronfuzzled (0)

Anonymous Coward | 1 year,5 days | (#44694357)

It took two developers to scrape Dropbox?

Obfuscated Python isn't the point here... (0)

Anonymous Coward | 1 year,5 days | (#44694471)

The point is that with this knowledge, they were able to bypass everything else which shouldn't have been the case -- namely they were able to workaround 2FA and "intercept" ssl traffic meaning they tricked the server into communicating with them. These things go well beyond python -- that python client could have been in the clear/open-source from the beginning but you shouldn't be able to bypass 2FA and get in un-authenticated.

This is the real problem here; their implementation of 2FA and ssl basically depended on a 'proper' client which shouldn't have been the case.

Insecure by design (5, Insightful)

nomaddamon (1783058) | 1 year,5 days | (#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....

Re:Insecure by design (2)

smash (1351) | 1 year,5 days | (#44694543)

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:Insecure by design (1, Interesting)

Inda (580031) | 1 year,5 days | (#44694563)

"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

Re:Insecure by design (-1)

Anonymous Coward | 1 year,5 days | (#44694581)

Is this a technical forum or Urban Dictionary affiliate?

Here, let me help you [lmgtfy.com] .

Re:Insecure by design (5, Informative)

Anonymous Coward | 1 year,5 days | (#44694687)

http://en.wikipedia.org/wiki/Cryptographic_nonce

It is a crypto term.

Re:Insecure by design (0)

Anonymous Coward | 1 year,5 days | (#44695169)

So Alan Turing is a crypto nonce? Sorry I will see myself out.

Re:Insecure by design (1)

buchner.johannes (1139593) | 1 year,5 days | (#44694815)

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.

Re:Insecure by design (0)

Anonymous Coward | 1 year,5 days | (#44695053)

I'm not sure how being able to steal Dropbox credentials is a big deal. If you're in the position to steal the credentials, you're already running code on the machine, or at least reading arbitrary files or memory. At that point it is game over. If you want to steal the files of dropbox, why not copy them right out of the local Dropbox folder? If you want to delete and cause havoc for them, you could just delete the files from the dropbox folder and have the software do its intended behaviour and also delete the serverside copies. If you are hell bent on actually getting into the dropbox account for whatever reason, this might be helpful.

But to say "OMG if we take over this PC we can also take over the Dropbox!" is useless sensationalism.

Re:Insecure by design (0)

Anonymous Coward | 1 year,5 days | (#44695209)

Everything is insecure, so talking about insecure by design is a bit wrong in this context. Let's say that dropbox didn't store any easy method of logging in, which means you have to type the password each time. Only a keylogger is needed to crack that. Insecure? sure. Ah, 2FA, giving you a sms each time you want to load the webpage - we don't trust cookies, they're insecure by design - would be enough? No, setting up a celltower outside your house and picking up the sms would solve that security measure. Hard, sure. Secure? no.

Nothing is secure. Everything is insecure, by design. As long as it's stored, disk, memory, your brain, it's insecure.

Ugh (1)

JTD121 (950855) | 1 year,5 days | (#44694591)

Neat, I finally submit to the cloud, and there we go with the security shenanigans!

Re:Ugh (0)

Anonymous Coward | 1 year,5 days | (#44694833)

It already had security problems.

There's a FBI backdoor in Dropbox, and, well, PRISM?

The problem here is the technical deficit amongst web developers.

Minecraft?? (0)

Anonymous Coward | 1 year,5 days | (#44694665)

"with any of the countless other sites, programs and applications written in Python: NASA, Minecraft, Django, OpenStack and a host of Google products, to name just a few."

Minecraft??

Re:Minecraft?? (0)

Anonymous Coward | 1 year,5 days | (#44694741)

They're also going to force open Django and OpenStack sources and NASA is apparently an app, not an aerospace agency. /. journalism at its highest!

Re:Minecraft?? (1)

MichaelSmith (789609) | 1 year,5 days | (#44694885)

Minecraft is written in java.

What two-factor ? (0)

HuguesT (84078) | 1 year,5 days | (#44695043)

I never knew that Dropbox had two-factor authentication. They only ask for a single password.

openstack? (0)

Anonymous Coward | 1 year,5 days | (#44695113)

why would you need to reverse-engineer openstack when you can just grab the code since it's like open

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>