CyberInsecure.com

Archive for the ‘XSS’ Category

Hadopi, the French agency charged with handling file-sharers’ copyright digressions, has once again been shamed by a copyright-related blunder. The agency which mandates that all citizens secure their networks to keep out freeloading pirates, has a surprisingly insecure site itself. Ironically enough, the vulnerability allowed outsiders to change the search engine of the Hadopi site into that of The Pirate Bay.

Hadopi has had its fair share of troubles since it came into effect last year. One of the most shameful missteps occurred when the agency unveiled its logo to the public, as it turned out that they had forgotten to secure a proper license to actually use the font type.

In what could easily be an April fools joke, but isn’t, the President of the French Pirate Party Paul Da Silva has revealed an interesting exploit he discovered on the Hadopi site. To assist the public in finding authorized sources to download movies and music on the Internet, the Hadopi agency launched a new search engine on its site earlier this week. A useful feature, but also one that turned out to be very easy to exploit, Da Silva told TorrentFreak. It took the Pirate Party President just 10 minutes to find an XSS vulnerability that replaced the Hadopi search engine with that of The Pirate Bay. As can be seen in the picture below the Hadopi site even featured Pirate Bay’s logo, the most recognizable pirate icon on the Internet.

“For a while now we have been telling Members of Parliament and Hadopi employees that what they request from every French citizen is just impossible (securing their Internet connection). It would require them to be experts, and even if all of them were, we would still be facing the problem of IP spoofing,” Da Silva told TorrentFreak.

Although the vulnerability was fixed after a few hours, the Pirate Party President managed to make his point, and many French publications picked up the shameful error. The big question is whether it will change the antics of the Hadopi agency, whose threats thus far have had little effect on the piracy habits of the French public.

Credit: TorrentFreak.com

A Facebook cross-site scripting (XSS) vulnerability was used to launch a self-propagating spam worm on the social network, according to security researchers from Symantec. The XSS vulnerability was located in the Facebook mobile API and was caused by insufficient JavaScript validation.

In order to exploit it, attackers created a Web page containing a specially crafted iframe element that forced all logged in Facebook users visiting it to post rogue messages on their walls. By crafting the spammed message to lure users into visiting the malicious site, the hackers were able to create a self-propagating worm.

The Symantec experts say the vulnerability was exploited in more limited attacks before being used to launch the worm, but also note that more copy cats followed the initial wave.

Some browsers have anti-XSS filters built-in by default, but they are not very efficient. The only one that can block a significant number of attacks is included in the NoScript Firefox extension.

XSS worms used to be quite frequent in 2009, however, social media websites have since gotten better at preventing such attacks. Nevertheless, some continue to pop up from time to time. Actually, the last one launched on Facebook occurred earlier this month and was used to spread weight loss spam.

In October last year, French security researchers demonstrated two information stealing worms that worked by exploiting cross-site request forgery and cross-site scripting vulnerabilities on Facebook.

According to Symantec’s Candid Wueest, Facebook has since addressed the vulnerability. “Facebook has informed us that they have patched this XSS vulnerability. In addition, they are currently working on steps to remediate damage caused by the attacks,” he says.

Last year Twitter was hit by a massive and more resilient XSS worm that locked hundreds of thousands of users out of their accounts.

Credit: Softpedia.com News

According to a report from the XSSed Project, the vulnerability is located in the search script on dev.twitter.com and was discovered by a researcher calling himself “cbr”.

Following the disclosure, security researcher Mike Bailey has quickly put together a proof-of-concept exploit which forces a logged in Twitter user to post a rogue message from their account when visiting a maliciously crafted Web page.

The attack leverages the flaw to hijack the victim’s session cookie and use it to post a tweet on their behalf, but the researcher notes that other malicious actions could also be performed. “While I’m not collecting any data other than session cookies, and I’m discarding them once I post a tweet from your account, I could do much more,” the researcher writes.

Bailey’s example requires a button to be clicked in order to trigger the exploit, but this is not necessary and the same result could be achieved transparently. This means that the flaw, which at the time of writing this article is still unpatched, could be used to create a malicious XSS worm, that would rapidly spread across the micro-blogging website.

“I wrote this proof of concept in less than 10 minutes. These things are ridiculously easy to attack,” Bailey points out.

Cross-site scripting vulnerabilities stem from a failure to properly validate user input into forms and allows attackers to force websites into serving unauthorized code to visitors. This is actually the fourth serious XSS bug discovered on Twitter this summer, despite the website having confronted similar problems in the past and undergoing repeated scrutiny.

Client-side protection against XSS is available in several browsers. Internet Explorer and Google Chrome come with their own internal filters, while Firefox has the popular NoScript extension.

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