CyberInsecure.com

Archive for the ‘XSS’ Category

Hackers and pranksters began exploiting a newly discovered scripting flaw on YouTube on Sunday, provoking rumours that a virus was spreading on the site.

The cross-site scripting flaw (XSS) on the video-sharing website created a means for hackers to post JavaScript code in the comments sections of videos. The flaw meant that this JavaScript code was run on the machines of surfers viewing the same video clip.

Predictable enough, pranksters at 4Chan have begun using the vulnerability to redirect surfers looking for Justin Bieber video clips to goatse or false reports that the irksomely clean-cut Canadian singer had died in a car crash. Denizens of 4Chan are separately trying to rig an online poll to encourage Beiber to play North Korea in an upcoming tour.

In other cases the flaw has become the fodder of comment spam. Google iced the problem hours after it first appeared, techie-buzz.com reports.

“We took swift action to fix a cross-site scripting (XSS) vulnerability on youtube.com that was discovered several hours ago,” said Google. “Comments were temporarily hidden by default within an hour, and we released a complete fix for the issue in about two hours. We’re continuing to study the vulnerability to help prevent similar issues in the future.”

The appearance of the vulnerability sparked rumours on Twitter and elsewhere that a virus was spreading across YouTube. A blog post by Chris Boyd of Sunbelt charts the genesis of this rumour, which is just the sort of thing that’s likely be used in new anti-virus (scareware) scams.

Security watchers at the Internet Storm Centre note that the vulnerability on YouTube might potentially have been used for all manner of hacking attacks, including password stealing scams.

“They [hackers] could steal your YouTube cookies, which probably doesn’t mean much to them, but they could also post various JavaScript code that will execute in your browser, in the context of YouTube,” an ISC handler writes. “I’ve seen nasty XSS attacks that are used to fake whole login screens and we know how many people use [the] same passwords for multiple accounts.”

Credit: The Register

The Apache Software Foundation (ASF) announces that several of its services were targeted in a complex attack that led to a server being completely hacked and another partially compromised. A considerable number of possibly insecure password hashes have also been lifted from the organization’s systems.

The attack started on April 5 when someone created a fake error report in JIRA, a proprietary project management solution developed by a company called Atlassian and used by the ASF. The rogue entry contained a TinyURL-shortened link, which, if opened, exploited an undisclosed JIRA cross-site scripting (XSS) vulnerability to steal session cookies for logged in users.

“When this issue was opened against the Infrastructure team, several of our administrators clicked on the link. This compromised their sessions, including their JIRA administrator rights,” Philip Gollucci, the foundation’s vice president in charge of infrastructure, explained. He also noted that, at the same time, the JIRA login page was subjected to a brute force password guessing attack.

After obtaining a set of valid administrative credentials for the project management system, the attackers located a writable directory on the server and used it to execute malicious scripts. This allowed them to install a password logging component and capture additional JIRA logins.

“One of these passwords happened to be the same as the password to a local user account on brutus.apache.org, and this local user account had full sudo access. The attackers were thereby able to login to brutus.apache.org, and gain full root access to the machine. This machine hosted the Apache installs of JIRA, Confluence, and Bugzilla,” Mr. Gollucci said.

Furthermore, using cached SVN passwords found on the “rooted” server, the attackers managed to log into several limited shell accounts on minotaur.apache.org. This server, which is also known as people.apache.org, hosts accounts for all Apache developers and was the target of a different attack in August last year. Fortunately, the attackers did not manage to escalate the privileges on this machine as well.

Users of Apache Foundation’s JIRA, Bugzilla and Confluence (wiki) systems, all running on the compromised server, are advised that their passwords could be recovered from the stolen hashes. JIRA users in particular, who logged in between April 6 and April 9, should consider their passwords already compromised as they were logged via the login form.

Apache.org’s infrastructure team has already taken several steps to prevent similar attacks in the future and the response received from the community so far is overwhelmingly positive. The majority of users congratulate the organization for its openness when dealing with incidents such as this one.

Credit: Softpedia.com News

A security researcher has identified more than 8 million Adobe Flash files that make the websites hosting them vulnerable to attacks that target visitors with malicious code.

The Flash files are contained on a wide variety of sites operated by online casinos, news organizations, banks, and professional sports teams. They make the pages where they reside susceptible to XSS, or cross-site scripting, attacks that have the potential to inject malicious code and content into a visitor’s browser and in some cases steal credentials used to authenticate user accounts.

The researcher, who goes by the moniker MustLive, said the Flash files contain poorly written ActionScript used to count the number of times a banner has been clicked and typically contain the clickTAG or url parameters. Google searches identified a total more than 8.3 million of them on sites hosted by the New York Giants football team, Praguepost.com and ParadaisPoker.com. Because Google results are often abbreviated, the actual number is probably higher.

MustLive said websites that host the buggy content aren’t automatically vulnerable to XSS exploits. Indeed, even though the pages on the official Citibank website included such content, XSS attacks that tried to exploit them failed.

But the researcher provided a wealth of examples of websites that were made vulnerable by the Adobe files, which provide graphics that move and are often referred to as SWFs, because of the three-letter suffix their file names carry.

It’s by no means the first time someone has identified a sprawling body of SWF files that threaten the security of the sites hosting them. Two years ago, researchers documented serious vulnerabilities in Adobe-based content that exposed more than 10,000 sites to attack.

The threat was particularly difficult to eradicate because webmasters had to patch their content-generation software and then render the animation scripts all over again. Months after the problem was identified, many websites still hadn’t bothered to take action.

Last year, MustLive reported 215,000 vulnerable Flash files, a number he later raised to the millions. That content was also made vulnerable by buggy ActionScript.

It should be said that the vulnerabilities exposed in the latest discovery are the result of bugs introduced by sloppy rendering, rather than vulnerable Adobe software. Adobe provides security guidance for designing banners with tracking capabilities.

Credit: The Register

Malware purveyors are exploiting web vulnerabilities in appleinsider.com, lawyer.com, news.com.au and a dozen other sites to foist rogue anti-virus on unsuspecting netizens.

The ongoing attacks are notable because they use exploits based on XSS, or cross-site scripting, to hide malware links inside the URLs of trusted sites. That’s something application security expert Mike Geide doesn’t see often. As a result, people who expect to visit sites they know and trust are connected to a page that tries to trick them into thinking their computer is infected.

“What’s interesting … is the fact that it’s embedding iframes to redirect people,” said Geide, who is a senior security researcher at Zscaler. “Typically, cross-site scripting is just that - it embeds script tags so it will embed javascript to run.”

The malicious links are blasted out on web forums and typically look something like:

hxxp://lawyers.com/find_a_lawyer/content_search/results.php?sCHRISTINA%AGUILERA%20ANOREXIC%20PICS%3C%2F%74%69%74%6C%65%3E%3C%69%66%72%61%6D%65%20%73%72%63%3D%2F%2F%61%73%6B%35%2E%65%75%3E

The last chunk of test is hexadecimal-encoded HTML that redirects users to ask5.eu (do not visit). A series of redirect links ultimately leads to a site that looks similar to a Microsoft Windows screen with a popup claiming the PC is overrun with malware. The user is prompted to download rogue anti-virus to fix the imaginary problem.

While it’s not the most convincing attack we’ve ever seen, there’s nothing to stop attackers from using the same technique to push web-based exploits, say the Adobe Reader zero-day attack that’s now circulating in the wild.

The links work because appleinsider.com and the rest of the sites being abused fail to filter out harmful characters used in XSS attacks. Here are a few examples with some of the malicious XSS advertisements (do not follow these or other “hxxp” URLs below):

Credit: The Register, Zscaler.com

The attack began when a victim encountered the image of the near-naked woman on a friend’s profile page along with the words “Want 2 C something hot? Click da button, baby!” Facebookers who took the bait - and were logged in to their accounts at the time - found their profile pages were updated to include the same image. The more people who fell for the come-on, the more the come-on was presented to new potential victims, giving the attack a viral quality.

Researchers who first spotted the ruse attributed it to a CSRF, or cross-site request forgery, vulnerability on Facebook’s site. A spokesman for the social networking site disputed that explanation, saying the attack was really the result of clickjacking.

“This problem isn’t specific to Facebook, but we’re always working to improve our systems and are building additional protections against this type of behavior,” Facebook spokesman Simon Axten wrote in an email. “We’ve blocked the URL associated with this site, and we’re cleaning up the relatively few cases where it was posted (something email providers, for example, can’t do).”

Clickjacking is a vulnerability at the core of the web that allows webmasters to trick users into clicking on a link they didn’t intend to. The exploits are pulled off by superimposing an invisible iframe over a button or link. Virtually every website and browser is susceptible to the technique. Websites that accept user-generated content make especially potent launch pads for such attacks.

This latest attack is a reminder that it’s often impossible to know where a given link will lead, even for careful users. Indeed, Gadi Evron, one of the security researchers who first spotted the exploit, confessed to having his Facebook page briefly display the image after first encountering it on a friend’s page.

“This shows that even experts can become complacent and trust systems when they really shouldn’t,” he wrote.

Facebook administrators have already blocked the clickjacking exploit.

Credit: The Register, AVG Blogs

A security researcher has discovered a weakness in a core browser protocol that compromises the security of Google, Facebook, and other websites by allowing an attacker to tamper with the cookies they set.

The weakness stems from RFC 2965, which dictates that browsers must allow subdomains (think www.google.com) to set and read cookies for their parent (google.com). The specification also states that if a cookie for a subdomain doesn’t already exist, the browser should use the cookie belonging to the parent instead.

The arrangement makes it possible for attackers to steal or even alter the cookies that websites use to authenticate their users. Attackers would first have to identify an XSS, or cross-site scripting, bug in some part of the site they are targeting. But because virtually any subdomain will suffice, the scenario isn’t unrealistic, two web security experts said.

“Most websites actually will store session IDs in a cookie and that’s actually how they keep track of users throughout the use of their website,” said Mike Bailey, a senior researcher for Foreground Security who first documented the flaw at last month’s Toorcon hacker conference. “Using the same techniques to attack those cookies, I can really damage sessions and cause some problems.”

Bailey’s paper goes on to demonstrate how he used the technique to bypass a feature Google recently implemented to beef up security on Gmail and other properties. By exploiting a minor vulnerability in sites.google.com, he was able to falsify the contents of his global Google cookie. Google has since fixed the XSS hole in the subdomain.

In turn, that allowed him fool the Google protection, which checks to make sure the value in the cookie matches a hidden parameter of the login page.

Bailey lists several other sites that have been known to be vulnerable to similar attack techniques. Using an XSS hole on www.advertising.expedia.com, he found it was possible to poison the global cookies for the entire expedia.com domain. Because the site didn’t set the cookies with proper escaping, an attacker could have used the weakness to inject malicious javascript into expedia pages.

Chase.com, capitalone.com and chasevisasignature.com either are or were vulnerable to similar attacks because they shared code with images.bigfootinteractive.com, which was vulnerable to XSS exploits.

Bailey said it’s not hard to imagine university websites would be vulnerable to such attacks because the domain names frequently use names such as psychology.school.edu, geography.school.edu and so forth. A single bug in a student-maintained computer science project might be enough to compromise personal data stored on the college’s student enrollment server, he said.

Websites can guard against attacks by regularly checking their pages for bugs, but because the attack exploits the way browsers are supposed to handle cookies, a more comprehensive fix will probably require a change to the underlying protocols. Which means this attack will probably be around for a while to come.

Credit: The Register

MI5 has closed up a flaw on its website that could have opened up visitors to malicious attacks, the UK intelligence agency said. The website suffered a cross-site scripting vulnerability that could have allowed hackers to inject code into the site and redirect users to malicious pages, MI5 admitted on Wednesday.

However, the government service insisted the website had been secured quickly, and that at no time had any intelligence operatives been exposed by the hack. “MI5 takes security very seriously,” the intelligence agency told ZDNet UK. “The website is secure and hosted in a high-security environment.”

Last week, a hacker with the handle ‘[-TE-]-Neo’ wrote that the MI5 website was vulnerable to cross-site scripting and Iframe injection. The hacker put the post on the Team Elite hacker forum last Tuesday, claiming the site was breachable through the search engine.

The MI5 site uses an embedded Google search engine, said a spokesperson for the agency, who also confirmed that the site had been vulnerable through the search tool. However, the website is hosted separately from MI5’s back-end systems and is not connected to sensitive data, the spokesperson added.

Once MI5 was informed of the vulnerability, it took action to remedy the situation, said the spokesperson. The flaw was not maliciously exploited and had been limited to that search engine.

Credit: ZDNet.co.uk Security News

Cross-site scripting flaw on the web sites of the Motion Picture Association of America (MPAA) has been abused to inject listings from controversial torrent links site The Pirate Bay.

Vektor, a member of the Team Elite group of hackers, smuggled links culled from the The Pirate Bay into content served up when surfers visited the MPAA’s recommended list of sites. The MPAA’s legal action against The Pirate makes the supposed endorsement ironic and embarrassing, if not completely unexpected.

Cross-site scripting (XSS) security flaws on websites are all too commonplace and the MPAA is a high-profile target, especially after the four defendants in The Pirate Bay trial were found guilty in a recent high-profile trial. So it was only really a question of time until hackers managed to find a chink in its armor to exploit.

Earlier denial of service attacks against entertainment industry websites scored limited successes in the aftermath of The Pirate Bay verdict on 17 April.

According to Vektor, the Recording Industry Association of America (RIAA) website is vulnerable to similar flaws as those he exploited to embarrass the MPAA earlier this week, Softpedia reports. Vektor used this flaw to inject a listings from Mininova, another well known torrent tracker, into pop-up windows displayed when users visited portions of the RIAA website.

Although the MPAA has reportedly addressed the flaws on its main website following the attack, other MPAA-controlled websites involved in movie ratings remain vulnerable to much the same type of exploit.

The vulnerabilities create a means for rogue iFrames from third-party servers to be presented to surfers as if they came from the site they are visiting, when in reality they come from locations determined by hackers.

XSS flaws on both the MPAA and RIAA websites have cropped up from time to time in the past, a quick search of security website XSSed reveals. Security suppliers, such as application security firm Fortify, said that Vector’s attacks against the RIAA and MPAA were each effectively accidents waiting to happen.

“That such sites are open to XSS-driven incursions and alterations comes as no surprise, given the fact that so many sites are poorly programmed and therefore open to such attacks,” said Richard Kirk, a director at Fortify. “The MPAA is lucky that Vektor’s attack was a proof-of-concept one, and intended as something of a joke. The next time they - and other organizations whose sites are vulnerable to XSS-driven attacks, may not be so lucky,” he added.

Credit: The Register
Credit: Softpedia

A cross-site scripting worm was spreading in Twitter profiles for several hours during April 12. People started reporting that their profile had sent Twitter messages without their knowledge. Messages looked like this:

Later on the messages morphed several times:

Many people followed the links to promoted website, as they believed the messages to be genuine Tweets from their friends. A cross-site script on the site then caused new users to start to Tweet the same messages.

It is unclear if the spammed site was actually associated with the worm.

According to an explanation on DCortesi blog:

What’s happening here is that it looks like somebody realized they could save url encoded data to the profile URL field that would not be properly escaped when re-displayed. This is particularly nasty because you could get infected simply by viewing somebody’s profile page on Twitter that was already infected. If you visited an infected profile, the JavaScript in the profile would execute and by doing so tweet the mis-leading link, and update your profile with the same malicious JavaScript thereby infecting anybody that then visits your profile on twitter.com.

It looked like Twitter fixed the issue but another round of the worm hit Twitter on Sunday morning. It was effectively the same thing, but attacked a different field. Here’s of the current variants:

Besides the “original” worm that was supposedly written by a teenager, there are some copycats out. The code had also been run through an obfuscator. The copycat Twitter XSS worms exploit the same vulnerability and actually most of the code remains the same. The new version got obfuscated to make analysis a bit harder.

It looks like the folks from Twitter are still fixing all the vulnerabilities so seems that there’s going to be quite a few modified Twitter worms for a day or two. Twitter stats blog said that they are currently addressing a new manifestation of the worm attack.

No passwords, phone numbers, or other sensitive information were compromised as part of this renewed attack, according to Twitter.

All these attacks are Javascript-based so it is possible to turn Javascript off if you’re worried or use a NoScript Firefox add-on.

F-Secure detects the script file as Worm:JS/Twettir.A.

Credit and screenshots: Mikko, F-Secure Weblog
Credit: DCortesi.com Blog
Credit: SANS Internet Storm Center

A webmail application vulnerability seriously compromised the security of 40 million accounts until it was fixed early last month, independent researchers said.

The flaw, in the Memova messaging application sold by a company known as Critical Path, is yet another testament to the power of cross site scripting vulnerabilities. Combined with another bug, it allowed attackers to surreptitiously forward the email of millions of end-users from some of Europe’s biggest internet service providers.

“The attacker only needs to send a specially crafted email to his victim,” independent researchers Rosario Valotta and Matteo Carli wrote in an advisory. “As soon as the victim opens the mail (no further interaction required) the forwarding settings of his webmail account of silently modified.”

The researchers tested a proof-of-concept attack on Italian ISPs Tiscali, Libero (also known as Wind) and Virgilio (aka Telecom) and found all three to be vulnerable. Using Critical Path press releases announcing customer deployments, they say about a dozen other large ISPs also used Memova, including Vodafone, Virgin, T-Mobile, and Telefonica.

Critical Path issued an update patching the vulnerability shortly after it was brought to their attention. “They answered immediately to our advisory,” researcher said. By last week, all of Critical Path’s customers had installed it, he added.

What’s notable here is that two of the three sites Valotta and Carli tested had implemented protections designed to mitigate the exploitation of XSS vulnerabilities. Specifically, the providers designated one domain for webmail and a separate domain for iframes that display the mail content. Even still, the researchers found a way to bypass the protection using a technique known as reflected XSS.

Currently there are no reports the vulnerability was exploited in the wild.

Credit: The Register