Security Hole Lets Lycos Run Arbitrary JavaScript

JibbaJabba writes "Securiteam is reporting that a "security vulnerability has been confirmed in Lycos's Search Engine" which "allows malicious web site owners to cause JavaScript code (or any other HTML code) to get included in the search results displayed to the end user by Lycos". They also state that "other engines are suspected to be vulnerable as well". Anyone tried google yet? The original bugtraq report by Sentry Labs is available here." Proof once again that the jerks have more spare time then the people who actually do something worthwhile.

Comments

Re:What Kinds of Malicious Code?

[Tim Macinta]

JavaScript is a relatively harmless language. While it could do something dramatic redirect the user to a porn site or display something obnoxious on the screen, I doubt that it would do anything like delete user's harddrives or give h@x0rs access to user's computers.

Redirection could be used for more than just annoying purposes. The thought can comes to my mind right away is that it could be used for deceptive purposes:

• Users could be automatically whisked away to one of the results without seeing any of the other results in the list. So as long as you can get your page in the top ten results for a particular keyword, you can force the user to choose your page.
• Users are (understandably) expecting a Lycos page, so if the Javascript were to redirect the user to a page that masqueraded as a search-results page the user would be likely to assume that the page was legitimate and not biased. As an example, the "Church" of Scientology could use this bug to redirect users to an apparent Lycos results page for a search on "scientology" and they could change all of the results to be pro-scientology. Worse yet, they could change the links to anti-scientology sites to copies of the original sites which have been changed to something along the lines of "We've changed our minds. We were wrong. Scientology is not evil. All hail L Ron."
• For users of other Lycos services, such as Lycos mail, the user could be redirected to an imposter Lycos page which would ask for a username and password. Users would be much less likely to be suspicious because they were expecting a Lycos page.

google is safe. Some WebMail sites affected

[valmont]

Some prominent web-based email sites like hotmail had a similar security-hole in their "dictionary" feature, which would allow a malicious user to paste an apparently harmless link in an email, because the link would be within the hotmail domain.

Once the user would click on that link, it would take them to the spell-checker interface of hotmail, but the 'word' passed to that CGI is actually HTMLcode that gets "echo'ed" as part of the "result page", just like any dictionary interface would do. That HTML code could be a SCRIPT tag downloading a .js javascript file from the perpetrator's server (to keep it clean) which could very well sniff a user's document.cookie and change the location of some hidden image on the page or pop a window by making an HTTP request to some evil CGI and passing the value of that document.cookie string as a parameter and store it in some text file.

The victim's cookie string most likely contains information that tells the server "hey i'm authenticated" so all it takes is for the evil person to reproduce that cookie.

As I browse the web, I find such vulnerabilities on member-driven sites all the time, some times I warn the webmaster, some times I don't bother, but it can potentially be pretty nasty. I even got a t-shirt from some mildly popular online community fedexed to me once after I rode their asses likes a madman so they'd finally plug a really *really* bad similar hole.

I found one in some remote feature of yahoo a few weeks ago, but its very small and I doubt anyone else would find it.

The rule of thumb to always follow as you design your web application, is "what is that HTML i'm sending to the user made of?". "is there any content in there that is taken from any kind of user input?". "if yes, am I filtering out all angled brackets?". "if i am allowing for user-input HTML content, am i filtering all unnecessary tags and among the tags i'm allowing am i filtering all unnecessary attributes (onload,onmouseover,onclick)?"

Re:So?

[ewhac]

Anyone who enables javascript is asking for trouble.

That's a bit disingenuous. JavasCrypt is enabled by default in all graphical browsers. 90% of people out there don't even know what it is, much less how to turn it off (turning it off in Netscape is fairly easy, but turning it off in IE is extremely non-obvious, even if you know you're looking to kill JavaScript).

Schwab

I checked google

[Nastard]

The javascript hole doesn't work on google, but I found an even worse bug that allows you to pass along ASM in a search string!

We love you anyway CT

[Zero__Kelvin]

"Proof once again that the jerks have more spare time then the people who actually do something worthwhile."

Don't be so hard on yourself there CmdrTaco! We read your drivelous comments just the same 8^}
And BTW - it's 'than' the people, not 'then' the people.

Re:What Kinds of Malicious Code?

[Dr. Prakash Kothari]

Windows boxen don't have root access. But I guess it doesn't sound as leet to say "You can 4Dm1n157r470r a Windows box!"

This is an incredibly common problem

[skunkeh]

This one's been around for years, and is present on literally millions of sites. I read somewhere certain both AltaVista and Amazon have both suffered from this in the past. Here's how it works:

You have some kind of form input, with the next page displaying whatever the user typed into that form field (for a search engine this would be in the form of "You searched for..."). the golden rule of web development is NEVER TRUST input from your users. Most developers take great lengths to check anything that's going into a file or database, or erspecially code that will be executed on the command line.

However, if you're just going to display something to the user that typed it why bother checking the content? Surely only the user who typed the thing is going to see it again, and it's not like they're going to be able to affect any of your systems?

Therein lies the problem. If you allow a user to type anything into a form and then have it re-displayed, they can include HTML tags. And if they can include HTML tags, they can include <script> tags. And script tags can do weird stuff.

Still think it's not a problem thanks to the fact that only the user will see it? Think again - seeing as most applications like search engines use GET to pass parameters, you can fill in the form for the user by offering them a link to click:

http://yoursite.com/search?<b>Oooh+Bold+Text </b><script>alert('Ew ww nasty popup')</script>

All of a sudden you can cause your weird popup messages to appear on someone elses site.<p>

The biggest security problem is the fact that javascript can access cookies. Imagine sending someone to a website via a link containing javascript that reads their username/password cookie for that site then pops up a window feeding that username/password to a script page con your server (in the query string) - BANG, you've got their password.

How do you stop this happening? Simple - deactivate HTML tags from user input by replacing < with &lt; and > with &gt; - problem solved :)