TinyURL - the site that converts unwieldy web addresses into short, manageable URLs - has been caught running a server so poorly configured it represents a serious risk to its millions of trusting users, a security expert is warning. At time of writing, the site's PHP module was actively broadcasting dozens of sensitive …
You get what you pay for.
Or in this case, far more than what you pay for as it's an incredibly useful service. Tinyurl started out as a way for people to reliably post links to a unicycling newsgroup and was created by one of the unicycling readers/posters. I'm not sure why people get so wound up when a hobby project that states "This service is provided without warranty of any kind" on it's main (only?) page does not conform to best practices. Unless, of course, "security consultant Rafal Los" is using this purely as a way to advertise his services. Way to go Rafal, pick the easy targets first.
Can I ask why the screenshot posted by el Reg isn't the tinyURL config page?
Paris - for her experience riding narrow rigid things.
They're still showing too.
Normally when something goes public, the website concerned suddenly leap into action but I still see TinyURLs underpants. It's not like this would be a tricky one to solve.
You'd think that if they insist on giving themselves access to phpinfo() like that they'd stick it in a deep and password protected directory, huh?
A quick scan down the page for obvious stupidity reveals they've got register_globals enabled. Silly.
"Because TinyURL significantly shortens long URLs, it's impossible for an end user to know where one of the site's links leads until she clicks on it."
It's not impossible. It not widely known, but it's possible to see where a tinyURL link leads by appending the subdomain "preview" to the link.
instead of clicking on http://tinyurl.com/xyz
you could visit http://preview.tinyurl.com/xyz
which will inform you which website you're redirecting to.
On the preview page, there's an option to enable preview for all links. This will force tinyurl to bring you to the preview page for all links, circumventing the trick of visiting urls which you might not actually want to visit. This setting has been buggy in my experience however.
Speaking of sloppy
It's not impossible for an end user to know where one of the site's links leads until she clicks on it; all she has to do is use one of the many bookmarklets available, on the 'net, to show the actual URL or use showtinyurl.com.
Also, not all end users are female.
I Stand corrected
Thanks to Jack and AC for setting me straight. Story has been corrected.
I never have clicked on a TinyURL link it my web life. There is something inherently absurd about following a link that you can't see the full path of. Also, it smacks of bad practice and terrible user education. Things like this just perpetuate the malware and spam problems. Bah. Where's my porch and rocking chair....
Security consultant? Doesn't seem to know much about security.
SERVER settings showing root is entirely normal. All webservers in unix, because they bind to port 80, need to be launched as the root user after which the application (web server software) switches to a less privileged user (such as apache, nobody or httpd).
Try it yourself - check your own phpinfo() - your own server shows much the same.
In other words - the security claims are without foundation.
To tinyurl's credit they are running Suhosin - a PHP hardening patch/module.
From my observations, most tinyurls point to Rick Astley...
Just a few environment variables
It looks to me like they have just had a dew environment variables leak though from restarting their server from the command line. They certainly don't tell us what user the web server is actually running as, only who started it. Looking at the page now it looks like it was started normally (possibly part of a system reboot). No sign of the bogus environment variables, and certainly no other sign of what user the server is running under.
Since this appears to be package install of the web server on FreeBSD I'd have to guess that the user and group are both "www" since they are the defaults.
The real mistake would have to be exposing the phpinfo() function to let people see this. Actually, I take that back - the real security mistake would have to be using php.
Natural Selection at work folks...
Nothing to see, move along... Evolution at work...
Still wide open!
ROFL still wide open through other vhosts on the same site:
gives you a page with a single link, to
I really don't like the look of some of these settings:
Directive Local Value Master Value
allow_url_fopen On On
allow_url_include On On
magic_quotes_gpc Off Off
magic_quotes_runtime Off Off
Screenshots available here if they take it down:
love that one
i don't want to be their admin :)
PDF Support enabled - PDFlib GmbH Version - if they have paid...?
SNMP libs are activated, too.. hm
If you type in http://tinyurl.com/admin/ you get a never ending redirect with this link in the url!
<img src="http:/i6.photobucket.com/albums/y241/dana-abel/hearts.jpg" alt="Image hosted by Photobucket.com">
What the Hell!!!
A theoretical weakness in a non-critical server gets front-page billing. Even if tinyurl (which I use, myself: how's that for handing out personal information? I suppose I should be shipped off to Guanotanamo Bay for that transgression) did get hacked, so what? It would be back up in a short time and there are other URL shortening sites out there. Any talk of risk to it's "users" is pure bull.
The big lesson to learn from this is that even with this misconfiguration being made public, the site is still running. That either tells us that no-one's much interested in hacking it or (more likely) that the risks presented by this minor issue are nowhere near as exploitable as the article would have us believe.
Preview is irrelevant
The existence of the preview feature is completely irrelevant. If the server is rooted then the preview isn't magically going to be immune. Browser plugins which request the page and don't actually do the redirect are safe.
The variable you actually want to look at is "User/Group" under "apache2handler".
This will tell you who the child threads are running as /after/ privsep.
Just an honeyPot ?
I thnik that is just an honeyPot... because it's too big.
"The information, which includes the web server's IP address"
Oh what amateurs, they're revealing the server's IP address! Don't they realise that makes it THOUSANDS of times easier to hack.
I'm sure they'll want to fix this problem immediately!
They appear to be running *nix. That means they are 100% secure and have nothing to fear. Their system is a fortress, No unsavoury character can get in.
Isn't that what the fanbois are telling us?
What's wrong with...
"TinyURL was created as a free service to make posting long URLs easier... This service is provided without warranty of any kind."
Who cares if they're displaying their phpinfo() information... Even if someone did hack the server there is no user/password etc information held and if they put malicious stuff on there it's not much different to just creating a tinyurl link to a malicious site... 90% of the idiots who use the site would still click it
Major security hole
"which includes the web server's IP address"
Yup, real danger there, telling people the IP address of the server they've just connected to using the, err, IP address.
@overblown and @So?
[... afterthought ... ]
And the problem is not revealing the IP address, no, nor is it the user/group that the server threads are running under. Reveal that your PHP config is vulnerable to every kind of injection under the sun, however, and you'd better pray there isn't a single input-validation bug *anywhere* in your code.
@overblown and @So?
So what if it gets hacked? I'll tell you so what: so what if someone simultaneously replaces every tinyurl in the entire database with a redirect to their 0-day browser drive-by sploit? How many millions of tinyurls get clicked on every day? *That* is how it puts end-users of tinyurl's service at risk.
There's a world of difference between some tinyurls being bad, and every single one in the world including those that were safe yesterday suddenly turning bad today. Sure, it's not different in *quality* from making just one bad tinyurl and posting it somewhere and just /hoping/ that people will click on it, but it's many many many orders of magnitude different in *quantity*. It would be comparable to managing to slip an iframe into google's front-page in terms of the damage it did.
This, incidentally, is one of the main reasons why I would much rather see a server coded in Perl over PHP. Automatic taint checking with -T is another very good reason... never trust user-supplied data.
Oh please... just stop already.
Most of the commenters show the same level of intellectual awareness as the original story's author. Perl isn't a magic wand here - if you had looked, the server runs Suhosin which will take care of variable injections and other potential exploits.
I posted a rebuttal to the story 2 hours after this article was posted (not sure why the main story claims Gilbertson responded) unless he emailed and they El Reg doesn't read comments.
Paris, because she is smarter than several commenters.
OH DEAR. I KNOW YOUR OS!!!! H4X
Hasnt anybody heard of software that can be used to query the OS and other info from remote servers.
My brain has completley left me today so i cant remember name
But grow up kids. No "secret" info here
8 whole hours!
So the security expert gave Tiny 8 hour hours to respond to his email before going public?
What a saint. Doesn't smack of someone who is in it for the glory in the slightest.
You're right about the root thing of course but the contents of the phpinfo() output still reveal some potential weaknesses in their system and 'potential' weaknesses are the starting points of all website attacks.
As I pointed out, register_globals is on for starters. Of course, lots of people are now screaming at me that it's not a security risk per se and you're right to an extent but it sure is a real big pointer that secure coding best practices are not being properly followed. Slapping Suhosin on the server and relying on that to protect the contents of your super globals just don't cut it these days.
If your code doesn't stick to the golden rules, sooner or later someone will get into it. On a service so widely used and (perhaps unwisely) trusted as TinyURL, that could cause all manner of problems...
Congrats on the scoop
Wow. A thrilling expose of a website where you can see the phpinfo() output, and then some amateurish, unfounded conjecture that this "might" leave the site open to some "possible" security exploits.
The fact of the matter is that one phpinfo() output does not give you any sort of insight into whether a site is secure or not.
Well done. A tabloid version of an El Reg story.
Security through obscurity may be useless, but all targeted hacks begin with reconaissance, and security in depth says you should not reveal any information you don't have to, particularly about your internal network structure and configuration.
Agreed with the AC above, while it might seem inocent being able to get info like this means i dont have to portscan it to find out what it is. one less trail to worry about.
Re: So? @19th, 10:30 GMT
Now all you have to do is wait for one of these fanbois to come along and prove that you're not imagining it.
- Leaked screenshots show next Windows kernel to be a perfect 10
- Amazon warming up 'cheapo web video' cannon to SINK Netflix
- Something for the Weekend, Sir? I need a password to BRAKE? What? No! STOP! Aaaargh!
- Episode 13 BOFH: WHERE did this 'fax-enabled' printer UPGRADE come from?
- Product round-up Coming clean: Ten cordless vacuum cleaners