For the uninitiated, Droplr is a web service that allows you to easily
drop a file onto the Internet. Drag the file to the Droplr icon, it
uploads the file onto the Droplr servers, then gives you a shortened URL to
paste into email, chat, Facebook or whatever.
Droplr is clearly not a service that grew popular because of security.
Regardless, its combination of the two following features bring about a false
sense of security (through perceived obscurity). Which leads its users into a
sort of self-inflicted social engineering hack, as you will see.
First, it's simple and easy to send content out to the publicly addressible
Internet. Need to send someone a screen grab? Easy. Drag, then paste the url
into an email. Done.
Second, it provides a shortened URL. Also convenient, because who needs
long URLs that get distorted in chat windows?
While I've never used the service myself to send anything, I've received
any number of links from coworkers and friends. It's easy to recognize the
value provided, and like most who use it (I'd guess), I didn't give the
security ramifications much thought. Just went with the general impression.
Obviously, uploading anything to a third party poses the risk that the third
party will snoop your data. This isn't really any different than using email to
send sensitive attachments, however.
It was the shortened URLs that finally caught my attention. They appear
randomized, and unintelligible, i.e.
http://d.pr/B0tw. So it's easy
to land on the idea that they are more or less "out of band" URLs. Similar to
what you get when you share a Dropbox file – a long random string that is
basically unguessable. Except they're not, because of the desire for Droplr to
shorten the URLs to make them copy-paste friendly.
The URLs are unassociated, certainly, but that just means that for a random
file X, there is no direct association to the person who posted it.
Unless the content of X implies something about the user. Or,
X gives something away that the user would rather it didn't. Either way.
A friend sent me a link via Skype, and after clicking it, the implication
of the short
d.pr domain finally dawned on me. If the intention is
to provide short URLs, it's implied that you will start at a small index and
grow outward. Meaning it's easy to discover links that result in some kind of
payload. To create an "out of band" URL you must use a sequence large and random
enough so that guessing it is improbable.
(This has been true since tinyURL made URL
shortening a thing. However, that service didn't also combine the ability to
upload content at the same time, which is the bad mix, in my opinion.)
So I deleted one character from the URL my friend sent me, and sure enough I got
someone else's drop.
After only a little time manually appending random alphanumeric paths to
http://d.pr/, I came upon someone's order from Sears. Complete with
two phone numbers, address, order number, and email. Someone was upgrading their
sleeping experience, apparently –
A few other things I discovered in under thirty minutes of hand entered
"Droplr drive-bys" –
And finally, a smoking gun, so to speak. I found a screenshot of a
bank account with all sorts of account information and digits. It was a European
account, but Google Translate helped me figure out what the labels meant. It was
probably enough information to get someone in trouble.
So it's clear to me that the impression I had about the relative safety of
Droplr is not uncommon. That since the shortened URLs are basically meaningless
with regard to the content, it's an easy jump to make that somehow they are not
going to be discovered easily. That they are "out of band". But that's simply
not the case.
Discovering drops is trivial. And if I am capable enough, I can write a
script that automates it for me. Which I did. And include below. And someone
else has most likely done too, but isn't sharing, and is instead using for who
knows what purpose.
The simple "drive-by" Droplr Perl script. It randomly tries a Droplr
URL and opens it in your browser if it exists.
A candid photo of some Indian youths in a hotel. Nothing scandalous, but
it was definitely an intimate picture meant to be shared with someone they knew,
An Excel file with some kind of financial business data, in Chinese. I
don't know if it was important or not, but it looked like it could have been.
Serial numbers for Microsoft Office.
An iPhone video.
[Code redacted] Note: While this code is trivial to write, I felt it prudent to
remove it from the article. Seriously, it was 24 lines of Perl.
Finally, it seems clear that Droplr understood these issues when they
designed their service, or at least grokked them soon enough. A couple snippets
from their Terms & Conditions:
Your Droplr.com Account and Site. If you create an account on the Website, you
are responsible for maintaining the security of your account, and you are
fully responsible for all activities that occur under the account and any other
actions taken in connection with the account.
Responsibility of Website Visitors. ... The Website may also contain material
that violates the privacy or publicity rights, or infringes the intellectual
property and other proprietary rights, of third parties, or the downloading,
copying or use of which is subject to additional terms and conditions, stated or
unstated. Droplr disclaims any responsibility for any harm resulting from the
use by visitors of the Website, or from any downloading by those visitors of
content there posted.
And so on. This is a pretty familiar attitude in the cloud. If you can achieve simplicity and
convenience, everything else is negligible.