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.
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.
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
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.
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
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.
"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
[... 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.
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.
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
