Posts tagged: XSS

Yahoo is investigating the claims of a hacker who is selling an exploit that apparently hijacks Yahoo mail accounts.

The exploit, being sold for $700 by an Egyptian hacker on an exclusive cybercrime forum, targets a cross-site scripting (XSS) weakness in yahoo.com that lets attackers steal cookies from Yahoo! Webmail users.

Such a flaw would let attackers send or read email from the victim’s account. In a typical XSS attack, an attacker sends a malicious link to an unsuspecting user; if the user clicks the link, the script is executed, and can access cookies, session tokens or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.

Demonstrating an apparent flair for marketing, the hacker, under the alias “TheHell” also posted a video on YouTube, providing a demo for potential customers. He claims it works with all browsers and does not require a bypass of XSS filters in either Chrome or Internet Explorer. He also says the exploit will be sold only to trusted individuals who are not likely to turn it over to Yahoo, which would undoubtedly develop a patch that will foil the attack.

“TheHell” claims that his exploit attacks a “stored” XSS flaw. This type of attack injects a code that is permanently stored on targeted servers until it is found and deleted. The malicious code is then passed to the victim’s machine when that particular server is accessed for legitimate download.

A standard phishing attempt is used to access the user’s cookies, from which the attacker can access the person’s email, or take full control of the account.

As of Tuesday morning, Yahoo was in the process of trying to identify the infected URL. Once the identification is successful, the malicious portion of code will be deleted.

Here is a script to automate testing of webmail systems for cross-site scripting. It uses XSS Cheat Sheet to generate the injection strings. Compared to the previous version this version downloads XSS cheat sheet on the fly (instead of having it hard-coded) and supports SMTP authentication.

Description:
This script sends a number of HTML-formatted email messages to a specified email address. In order to test a webmail system you need to have an email account on the system, run this script to send messages to that account, and then view the received messages through the webmail interface. If you get a popup box saying “XSS!” it means that your webmail system failed to block the attack.

Try viewing the messages in several different browsers, including Internet Explorer and Mozilla Firefox. Some attacks work in one browser, but don’t work in another.

The script downloads RSnake’s XSS Cheat sheet from http://ha.ckers.org/xssAttacks.xml. This way we always have the latest and greatest XSS attacks. Thanks, RSnake.

Reddit (reddit.com) is a social news website, and it’s much better than Digg or Slashdot. However, it got hit today by a XSS worm that was spreading via comments on the site.

It all started with a user called, suitably enough, xssfinder. His account has already been deleted. This user posted some test comments exploiting the fact that Reddit wasn’t filtering out JavaScript in certain instances when you were hovering your mouse over text.

When xssfinder got his script working, he tested it by posting one comment to a popular link called “Guy on a bike in New York ‘high fives’ people hailing cabs”.

After this, things happened quickly.

People reading comments ended up sending massive amounts of new comments to Reddit threads.

Right now things have calmed down. Reddit was never down, and Reddit administrators have closed this vulnerability. Malicious comments are being mass deleted right now.

How I cross-site scripted Twitter in 15 minutes, and why you shouldn’t store important data on 37signals’ applications“Today the Ruby on Rails security team released a patch for a cross-site scripting issue which affected multiple high-profile applications, including Twitter and Basecamp. If you’re concerned about the issue and would like to see the patch, please read the advisory from the Rails security team. In this post, I discuss the overall process of finding the issue, and the reason why I’d suggest that no important information be stored on the 37signals applications (Basecamp, Highrise, Backpack, and Campfire).

After seeing a bug in Unicode handling in an unrelated program a few weeks ago, I suddenly had an idea: “I wonder if there are any web applications which have Unicode handling problems that might be security issues?”

My attention quickly turned to Twitter, the only web application I had open at that moment. A few minutes later, I had JavaScript from a URL query parameter falling through the escaping routines and running in the main body of twitter.com. Bingo! Cross-site scripting, the stuff that Twitter worms are made of. But was this a Twitter-specific issue, or did it affect other sites too?”- Brian Mastenbrook

Twitter, the 3rd biggest social network after Facebook and Myspace was hit over the weekend by powerful, self-replicating attacks that caused people to flood the micro-blogging site with tens of thousands of messages simply by viewing booby trapped user profiles.

The worm attacks began early Saturday morning and were the result of XSS, or cross-site scripting, bugs in the Twitter service. They caused those who viewed the profiles of infected users to post tweets promoting a site called StalkDaily.com. Victim profiles were then altered to include malicious javascript that infected new marks. Over the next 36 hours, at least three similar worms made the rounds, causing Twitter administrators to delete more than 10,000 tweets.

Twitter’s inability to quickly contain the mess prompted some security watchers to criticize Twitter for not being more on top of it. According to this postmortem from the Dcortesi blog, the attacks exploited gaping holes that allowed users to insert tags in the URLs of Twitter users’ profile pages that called malicious javascript from third-party web servers.

As is frequently the case with XSS-based attacks, the worm was unable to prey on those using the NoScript add-on for the Firefox browser.

Twitter’s security team was able to block the attack for a while, but a new assault that made use of “mildly obfuscated” code soon defeated the countermeasure, raising the possibility that it was based on the detection of attack signatures rather than fixing the underlying bug that allowed the XSS vulnerability in the first place.