In a new section supporting the release of an anti-theft product for mobile phones, the web site of Helsinki based anti-virus company F-Secure is vulnerable to cross site scripting (XSS).

XSS String

A hidden form field reflects values from a name value pair (hidManufacturer in this case) from the URL.

Attack URL:

http://www.f-secure.com/en_EMEA/products/mobile/anti-theft-download/anti-theft-download-
wizard.html?hidManufacturer=%27%22%3E%3C/title%3E%3Cscript%3Ealert%28/Mikko%20rulz/%29%3C
/script%3E

First reflection of URL XSS name-value pair:

<input type="hidden" name="hidManufacturer" id="hidManufacturer" value="\'\&quot;&gt;&lt;\/title&gt;&lt;
script&gt;alert(\/Mikko rulz\/)&lt;\/script&gt;"/></p>

But nothing happens on this reflection because much of what is passed in the URL (the bracket and quote characters) is encoded as &quote, &gt, &lt on the output of the page. This is generally recognized as a right practice to avoid many forms of cross site scripting attacks on web pages.

Unfortunately a Javascript later in the page is referencing the passed in string without any of the same encoding.

Second reflection in the page of the same value:

<script type="text/javascript">
    document.getElementById(''"></title><script>alert(/Mikko rulz/)</script>').setAttribute("class", 
"selected");
    document.getElementById(''"></title><script>alert(/Mikko rulz/)</script>').setAttribute("className", 
"selected");
</script>

A Javascript reflects values unencoded from a name value pair in the URL.

Finally

The Mikko reference is to Mikko Hypponen, the well known Chief Research Officer at F-Secure. The defect was submitted to XSSED by Xylitol. At a glance this appears to be the first new web site specific problem with the main F-Secure web site (country specific versions have had issues) since the F-Secure forum defacement in 2007.

Reflected cross site scripting attacks are on the low end of the scale when it comes to web application vulnerabilities, however they can be used effectively in phishing style attacks (ex: here is a URL to F-Secure, but I will attempt to steal a user session, redirect the user, serve them malware, etc. based on being able to execute a script as the F-Secure web site). As always it behooves a security company to correct problems like this fairly quickly, and F-Secure clearly knows what to do already since they’re using output encoding in one part of the page already.

Update 06/8/2010

The problem was corrected quickly, and the issue explained competently by Mikko, as expected.

Related Posts:

• Formspring.me XSS Vulnerability
• XSS Flaw on PayPal.com
• Pentagon Web Site Vulnerabilities Identified

Formspring.me, a newly popular social networking site, has a fundamental cross site scripting flaw that allows one logged in user to steal another user’s session, but also may allow users to find out who posted a nasty comment about them. A key complaint about the site is that you can not find out the identity of an anonymous user.

Update: Kudos to Formspring.me, even though it was hard to initially report the problem, they corrected it in about an hour from opening a post on their technical support forum, a nice turnaround by any standard.

Formspring.me

Formspring.me is a six month old social networking question and answer site. The web site has come under scrutiny following a few recent news stories involving incidents with teenagers, the site’s primary demographic. The first notable incident was where a fight broke out over comments on the site. More notably, however, is the story of Alexis Pilkington, a 17 year old West Islip, NY High School graduate who committed suicide after dozens of insulting comments had been made to her on the site.

From comments on the site, these are not isolated incidents, and its fairly clear Formspring needs to come up with a better model:

Is it possible for you to delete an account for harrassment if the posts were anonymously posted? I received 18 threats last night that I followed up with a police report to my local PD. I have the police report number, as of yet I have not deleted my account so that if you needed to access it to see the post you could. Please advise.

I need to know how to go about finding out who send a message to my daughter’s account. The message says.. that she would be better off dead.

I would appreciate it if Formspring will work with our local Santa Barbara Police Department and the Santa Barbara Sheriff Department to find the person that was impersonating my daughter.

Such problems have led to various organized boycotts, letters home from school officials, and coverage under the topic of cyber-bullying in a number of news outlets.

The Big Issue People Have

One of the primary complaints about the web site is the anonymity of questioners. Hiding behind the veil of anonymity has allowed, mostly teenagers, to make nasty remarks to each other they would probably not make under their own names (although frankly the Internet is a wild place). Largely as a result of this, a good deal of time has been spent trying to figure out a way to determine: “who said that about me?”. That is at least according to the articles I’ve been reading. Formspring won’t help you with anonymous questions, as it states in their support forums

But here’s an answer to that question, or at least a method: a way to grab another user’s session only knowing user name because of a web site vulnerability present in the Formspring web site.

1. We have two users: Tester21 and Tester25. Since they have such close names, they’ve decided to follow each other using the site’s People->Find People and Follow functions.

2. Tester 25 goes to www.formspring.me and asks Tester21 a question:

   

   Ask another user a question.

   
   

3. But that’s kind of boring, so Tester25 asks a better question:

<script>alert(document.cookie);</script>

4. Tester21 logs in and sees he has a question:

Malicious script, dutifully encoded by Formspring.me.

<a href="#" rel="question">
&lt;script&gt;alert(document.cookie);&lt;/script&gt;</a>
<span class="askedBy">asked by <a href="http://www.formspring.me/tester25" rel="profile">tester25</a>

5. Glad Formspring has protected him from revealing his session cookie by properly encoding output, Tester21 makes a note to drop that loser Tester25 from his Follow list and clicks Home:

The home screen preview executes the Javascript.

What Happened?

A preview function on the home page shows the user the last pending question they’ve received. If its the one that is the cross site scripting string, the script executes. In this case its only the classic alert box demonstration, but anything that can be accomplished with Javascript is possible.

Another Random Issue

It appears formspring.me actually logs users in as someone else sometimes without any interaction, as evidenced by this user complaint:

Hi, everytime i want to go to my home page or feeds on my friends answered questions, i keep going to random people’s homepage or their feeds, anyway i can fix this?

Why is Disclosure this Difficult?

After numerous attempts to sign up for the Support section of the site so we could notify Formspring of this defect, we finally just posted an issue in their Technical Support forum as the notification. They need to think about adding a screen or e-mail address for reporting security issues, ala Twitter and other sites.

Finally

So assuming someone is acting as an anonymous user, but has given more information in their profile (e-mail, etc.) then the person who wants to know who they are could send them a variation of the “poison question” above that steals that user’s session (likely this would involve sending the user’s cookies to another web site, having a script running there that grabs the cookies and perhaps logs in in as that user and changes the user’s password which essentially takes over the account). From taking over the account the attacker gains access to any information filled out in the profile (could be nothing if Anonymous uses dummy information and an anonymous e-mail) and can post and answer questions as that user.

Additionally by searching out people making use of the Formspring widget, you don’t even really need to be a Formspring user yourself to post the XSS string to a Formspring user’s account.

The problem above is magnified in that many users connect their Formspring accounts to Facebook and Twitter (meaning a person who has taken over the account can then post messages to these other two social networking services).

In terms of actual impact, its unclear that user’s would have any truly sensitive information available in their profiles, making information disclosure a low risk (assumes the user didn’t post sensitive information themselves). Birthday and e-mail are probably the only two fields that could be considered user confidential. So the primary issue is session hijacking. Is it a big deal? It probably is not, other social networking sites had similar issues in their first six months of existence, it is just something that should be corrected.

As for Formspring itself, and the issues people are having with anonymous users, this is probably worthy of its own blog post. There are a number of sites that allow anonymous comments to be posted, and the web is famous for snarks and nastiness in online comments. That said, having experienced these problems so publicly, and being a web site that is used primarily by young people, Formspring would be best advised to remove the anonymous question capability to avoid libel, cut down on police investigations, and get itself out of the negative press for a while. Call it the price of being popular.

A special thanks to ethicalhack3r for bouncing some ideas around.

Related Posts:

• F-Secure XSS on Anti-Theft Website
• XSS Flaw on PayPal.com
• Pentagon Web Site Vulnerabilities Identified

Earlier today Wesley Kerfoot reported on the Full Disclosure mailing list that a page in the Paypal.com domain is susceptible to a non-persistent reflected cross site scripting attack (XSS). While non-persistent XSS bugs are somewhat common, this is quite serious for a site like PayPal, where user accounts are linked directly to bank accounts, debit, or credit cards and payment can be made to third parties without any additional authentication after user access is gained.

Update: As of 7pm EST, it appears that a mitigation has been implemented for this vulnerability on the PayPal web site where all requests to /xclick/business redirect to the PayPal homepage.

An attacker able to trick a user with a valid Paypal session into clicking a crafted version of the link below (wouldn’t be hard, think a link on an eBay auction listing or a phishing e-mail for example) could hijack the user’s session and initiate financial transactions on their behalf including money transfers. Alternatively this legitimate URL could be used to redirect the user to a spoofed PayPal web site designed to steal user credentials, which is a fairly common scam except in this case more effective as the user would see an actual PayPal URL to click on.

Attack String

The following string is provided as example in the Full Disclosure posting:

https://www.paypal.com/xclick/business=<script> alert("xss"); </script>

Which in turn results in this:

Javascript injected as part of a name-value pair is reflected on the resulting web page.

Of course where this works, this will just as easily work:

https://www.paypal.com/xclick/business=<script> alert(document.cookie); </script>

Which dutifully reflects back wrapped in a header tag on the resulting page:

<div class="legacyErrors " id="page">
<div id="header"><h1><script> alert(document.cookie); </script></h1></div>
<hr>
<div id="content">
<div id="headline">

And finally which displays the user’s logged in session information:

The result of injecting alert(document.cookie) into the same page for a logged in PayPal user.

Rather then displaying the cookies, the attacker would redirect the information to another web site, set them locally as his session, and begin to initiate transactions on the part of the user. This is only one example, since Javascript can be executed in the context of the PayPal web site, the attacker could write a script to do just about any action on the site that is possible using Javascript, Flash, etc.. Site redirects, iFrame injection, and even other injection flaws are possible on a web page that does not validate untrusted input.

XSS at a High Level

While the definition is ever expanding, XSS attacks are generally considered a type of injection problem where malicious input is injected into an otherwise trusted web page causing an unexpected behavior such as sending data to or from an unknown third party web site (cross site). Because the script is being run in the context of the trusted web site, it has access to cookies such as session tokens, as well as any other user information available within the security context of that web site. XSS vulnerabilities are somewhat common in web applications and will occur unfettered wherever untrusted input is not validated by the web application or encoded before output back to the user.

PayPal

The San Jose based company is owned by eBay and has more than 78 million customer accounts. As such the service is used to clear many of the transactions on the popular auction site. The service allows users to send money without needing to share financial information, a key enabler for sending and receiving money from third parties on the Internet. They are in some 190 markets around the world and can work with 19 different currencies.

In 2008 roughly $60 billion dollars moved through Paypal’s systems.

Paypal does make available additional authentication protection in the form of a one time password token called a ’security key’ by them (similar to the ones made popular by RSA). The token costs five dollars and is available to residents of Australia, Germany, Canada, the United Kingdom and the United States. Paypal however allows a bypass of this hard token by allowing the user to enter further information such as credit card or bank number, severely impacting its effectiveness as a security measure.

Further authentication “on the front door” of the web site (the login screen) does not prevent a user session from being hijacked after authentication as is possible in a cross site scripting attack like this one.

PCI Compliance

Of note is that PayPal does claim PCI compliance, involving the following activities in their words:

• Maintain a vulnerability management program
• Pass quarterly remove vulnerability scans

The wording on that second bullet from the PayPal site is a little strange, we assume it means to pass vulnerability scans that validate whether earlier problems identified by previous scans were removed.

The attack string above is basic enough that it would or should be tested and picked up as a vulnerability by the most rudimentary web scanners available, throwing the validity of any scanning being done into question. Actual credit card data is displayed in an obfusticated manner on the Profile section of the web site (only the last four digits show up on the site), so the site may be considered out of scope of a PCI required scan?

The digital certificate of the scanalert.com URL, a redirect to the McAfee service PayPal provides to its business customers at no cost for a year, has a bad digital certificate.

Finally

Generally users can apply for refunds from PayPal when an account has been broken into, but like any other service there are a share of horror stories. In general a site such as this should escape all output that originates from untrusted sources, with the variety of possible attack strings this is not full proof but is a significant mitigation against injection attacks. This is not PayPal’s first brush with this problem, last year a similar issue was identified by Harry Sintonen. As PayPal is, for many users of eBay and other online services, the only payment game in town (the only one which a seller will use to collect payment) this type of issue needs to be corrected fairly quickly in a comprehensive manner (a site wide change to introduce web vulnerability scanning, escape all user provided input when outputted, and/or validation of all user provided input ideally).

References

• Full Disclosure – Paypal XSS Vulnerability

Related Posts:

• F-Secure XSS on Anti-Theft Website
• Formspring.me XSS Vulnerability
• Pentagon Web Site Vulnerabilities Identified

A Romanian hacker has on December 6th re-identified previously discovered input validation deficiencies in URL parameter handling leading to security vulnerabilities on a tour images section of the official web site of the Pentagon, the headquarters of the U.S. Department of Defense. The hacker who identifies himself as Ne0h has posted images demonstrating the vulnerabilities, which are still active at the time of this blog post, on his blog.

The vulnerabilities themselves are caused by weak validation of name value pairs being received by the browser in a photo album application on the Pentagon web site. The normal page, seen here, loads pictures of past tours of the Pentagon. The entire web site is largely on online brochure for the Pentagon, and does not appear to host sensitive data or allow users to make sensitive requests, making the risk profile of the site low. Ne0h actually rediscovered vulnerabilities first identified back in April by XaDoS and posted on the XSSed project.

Cross Site Scripting

The attack string that follows shows the inclusion of a Javascript that will reflect back once the tours page is returned to the browser. The special characters in the script are URL encoded. The script calls the alert function, which will pop up a window. The inclusion of document.cookie will cause all cookies the user has set for that web site to show up in the alert box. This attack is an example of a non-persistent or a reflected cross site scripting vulnerability.

XSS String

http://pentagon.afis.osd.mil/tours?action=viewLargePhoto&title=1%3E%22%3E%3CScRiPt%20%0A
%0D%3Ealert%28document.cookie%29%3B%3C/ScRiPt%3E

XSS String, XaDos example:

http://pentagon.afis.osd.mil/tours?action=viewLargePhoto&title=group-SgtMaj.jpg%22%3E%3E!-^^%3E%3Csc
ript%3Ealert(%27XaDoS%27)%3C/script%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E

XSS document.cookie request

The code is reflected back in the returned HTML:

    
    <div id="content_1column">
        <div id="content_main">
            <h2>Tours</h2>
            <h3>Photo Gallery</h3>
                <div id="galleryPhotoLg">

                    <img src="images/largePhotos/1>"><ScRiPt 

>alert(document.cookie);</ScRiPt>" width="650" height="480" alt="Image Gallery"  />
               </div> 

The Pentagon web site is showing a JSESSIONID, a cookie format used in Java web applications, however the site does not appear to maintain user session, so it is likely a tracking cookie or unused. If cookie theft (of a valuable cookie) is out though, there are still problems including site redirect and related Javascript based manipulations possible with this vulnerability. An example for further exploration would be attempting some manner of cross subdomain cookie attack as the afis.osd.mil (AFIS is the American Forces Information Service) hosts a number of Department of Defense web properties, some of which may maintain user session or host more sensitive data than the brochureware type site the Pentagon is hosting.

iFrame Injection

The second proof of concept demonstrates an iFrame inclusion vulnerability. An iFrame is an element in an HTML page that is loaded and refreshed as a separate page, but loads under the original page. In this example, an attacker can load content from outside the Pentagon web site, but serve it to the user as part of the Pentagon web site (malicious software and so forth) in a provided URL.

iFrame Inclusion String

http://pentagon.afis.osd.mil/tours?action=viewLargePhoto&title=1%22%3E%3Ciframe%20src=

http://ne0h.baywords.com%3E%3C/iframe%3E

iFrame loads another web site (Ne0h's blog in this case).

Ne0h

Global Hell - We are your armageddon.

It is an interesting handle for a hacker or cracker, as its already taken by a Canadian hacker who was a member of gLobalHell, a group responsible for a number of well known defacements and break ins including the systems of the White House, U.S. Army, and the U.S. Postal Service. I guess we could call his handle an homage.

This Ne0h has demonstrated vulnerabilities of other web sites successfully including a SQL injection on two MTV properties called MTV Philippines and MTV India using the Pangolin SQL injection testing tool and XSS (cross site scripting) vulnerabilities on TinaTurnerlive.com and Logitech.com. He has also demonstrated successfully vulnerabilities in the web site of the Romanian police.

Baywords, The Choice of Romanian Hackers?

We are noticing now a couple of these folks using Baywords, a blogging platform known for this raison d’etre:

Over a year ago, a friend of ours got his blog closed by Wordpress for violation of TOS. Essentially he got blocked because he linked to material that could lead to maybe a download of something that you might not have paid for. We became very upset and decided to open Baywords!

The authors whose blogs we’re linking to like Baywords for this reason:

Baywords is now back again, and we’re not taking any details on the users. As long as it’s legal to write, we won’t close down your blog. We will not give out any information, IPs or anything else — that data is deleted when no longer needed.

No condemnation, we’ve just noticed Baywords showing up more often in these situations. If it is not on BayWords however, it would just be somewhere else.

Finally

At the time of writing, these vulnerabilities are still active, which makes this nearly nine months of being open (credit Mike Bailey for pointing this out). If not patched, the Pentagon web site may be used as part of other web based attacks via redirection using URL’s sent to a user that appear to be for the Pentagon web site. This type of XSS vulnerability, a reflected XSS vulnerability, is fairly common in web applications and does not have as large an impact as other input validation problems. A high profile site such as that of the Pentagon should close it out though. The Pentagon and other DOD entities have a reputation interest in appearing to be highly competent in securing their infrastructure. If there was no other reason to search out and correct common low hanging fruit web site vulnerabilities (there are of course), this would be enough of a reason.

Update 1:

This exact vulnerability continues to be pointed out, this time in October. The earliest reference we identified is still in April from the XSS’d Project.

Update 2:

Mike Bailey, a security researcher with web application expertise, and I have been having a friendly give and take on Twitter about whether this example is newsworthy by itself, following that whether it is depressing that XSS flaws are no longer newsworthy, whether this serves as a great example to get reasoned attention on the issue with its downstream problems and so on.

In the midst of proving his points, the DOD has gotten some good analysis of their web sites XSS vulnerabilities, as Mike tested a number of the other properties under afis.osd.mil as part of his blog post. So while the first problem is being fixed, here are a few others to go after:

Department of Defense's imagery website, XSS vulnerability.

Joint combat camera center web site, XSS vulnerability.

American Forces Network, XSS vulnerability.

References

• Neoh’s Blog – Pentagon
• Pentagon XSS Vulnerability on XSSed
• Official Site of the Pentagon
• Article on the Original Ne0h
• BayWords

Related Posts:

• F-Secure XSS on Anti-Theft Website
• Formspring.me XSS Vulnerability
• XSS Flaw on PayPal.com
• The “Aurora” IE Exploit Used Against Google in Action
• Scareware Purveyors, Spammers, and Crooks Take Advantage of Haiti Earthquake