TinyURL, your configs are showing
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 …
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.
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.
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.
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....
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.
Paul Gregg
From my observations, most tinyurls point to Rick Astley...
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.
Nothing to see, move along... Evolution at work...
ROFL still wide open through other vhosts on the same site:
http://www.coolwhois.com/php.php
gives you a page with a single link, to
http://www.coolwhois.com/php.php?123
I really don't like the look of some of these settings:
Configuration
PHP Core
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:
http://img9.imageshack.us/img9/439/gilby5n.png
http://img10.imageshack.us/img10/5936/gilby2oopsu.png
http://img11.imageshack.us/img11/438/gilby3doubleoopso.png
http://img12.imageshack.us/img12/6623/gilby4o.png
http://img18.imageshack.us/img18/2076/gilby1r.png
SERVER_ADMIN you@example.com
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!!!
Oh no!
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.
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.
I thnik that is just an honeyPot... because it's too big.
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!
Jolyon
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?
"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
"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.
[... 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.
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.
/facepalm
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.
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.
http://pgregg.com/blog/2009/03/tinyurl-php-flaw.html
Paris, because she is smarter than several commenters.
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
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...
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.
Now all you have to do is wait for one of these fanbois to come along and prove that you're not imagining it.
Sign up, sign up for The Register's weekly IT security newsletter - click here
