Forget short URLs, it’s just a bad idea to have any url point to anything you want to keep secret, isn’t it?
Oh sure, blame the victim! /s
It seems like there’s a catch. Suppose you try aaaa.com and aaab.com and get a hit on aaac.com, and it’s got some middle school term papers and dirty pictures of Sailor Moon. Way to go, sport. Only about 10^14 more combinations to go!
As in many things, human labor is the bottleneck, and there’s no way around. Cf: YouTube.
Well, yeah, only, there’s no human labor involved in making the http requests—that’s automated. The humans just have to investigate what was returned from the urls that responded.
I was expecting to hear about malware being hosted on some of the popular URL shortening sites given the headline. Shortening the namespace makes brute forcing faster you say? I am shocked! It probably should read URL shortening and not URL shorteners.
Something like this: https://tinyurl.com/2fcpre6 isn’t likely to create a path to your harddrive.
Maybe it’s just the developer in me, but this seems completely obvious. URL shorteners are a convenience feature – and to my knowledge have never claimed to be anonymous or secure. You should never use a URL shortener on anything that you wouldn’t want somebody else to stumble across.
Using URL shorteners as described in the paper to mask private information is definitely not a well thought out design. If you RTFP, at the end they note that the vulnerabilities they found in OneDrive and Google Maps have both since been mitigated.
While I haven’t read the paper, I would assume the major URL shorteners would have rate limiters in place to prevent scanning. All it takes is putting a 1-request-per-second rate limiter on any IP requesting more than X urls in time period Y to make brute forcing effectively worthless.
I haven’t read the original article yet but I think the path to your hard drive results from that tinyurl pointing to your Google Drive/Microsoft OneDrive/Dropbox/etc. which may be getting synced to your home computer (if you use that feature).
I used Google’s link shortener (goo.gl) many times to share non-sensitive files stored in my Google Drive with customers. I always kept those files stored in a folder structure separate from the rest of my Drive that I only used for stuff I considered “public” so I don’t think I was ever at risk (although I guess my customers were). The whole exercise want about security through obscurity – it was about being able to share large files with people while working at a company that didn’t offer their own means to do this.
Well, not to give anyone any ideas but that could be distributed fairly easily (and was for the purposes of this research).
At six characters, upper case and lower case from the English alphabet, numbers and nuffin else, my napkin estimate is close to 62 billion possible URLs (assuming every combination is allowed … so I’m guessing more like 59 billion).
They do discuss rate limiting in the paper but they had 189 computers to throw at bitly. For bitly, the total rate limits aren’t published but you can have 5 concurrent requests per computer. Assuming they could make 2 sets of requests per minute for an hour against that entire pool of computers, that’s about 100K requests (accounting for a 10% failure rate). Based on what’s described in the paper, I’m guessing that’s an extremely conservative estimate.
From the paper:
At the time we were conducting our scanning experiments, Amazon EC2 Spot Instances cost $0.003 per (compute) hour , thus scanning the entire bit.ly URL space would have cost approximately $36,700. This price will drop in the future as computing resources are constantly becoming cheaper.
They don’t even need a pile of computers if they want to scan the whole thing.
But probably most important … you don’t have to scan the entire namespace to cause significant issues. Simply pull a sample, find out which of the sample (programmatically, no less) are writable, and unleash heck.
this just in: security through obscurity is still shit
Some interesting stuff here, but:
By brute-forcing all Google Maps shorteners, you can discover peoples’ private addresses
You can also “brute-force” private street addresses by, for example, driving around in a car. Or just using google maps normally.
Reminds me of “your computer is broadcasting an IP address!”
Driving and normal use have associated costs. Finding every non-journalist traveling to a Carrot Top show and using their gym privileges while they’re away…or something less personal, say, that’s feeling farther off.
Here’s where I go buy Anne McCaffrey novels changed so the protagonists’ evacuation pods are full of unbidden interlopers…probably change them back. S’probably in the foreword.
This topic was automatically closed after 5 days. New replies are no longer allowed.