Last Updated: 2006-10-02 11:10:39 UTC
by Lenny Zeltser (Version: 2)
In theory, the victim's viewer could be another application, rather than a web browser. Imagine a vulnerable website that accepts code as input from the attacker and, without properly filtering on input or output, incorporates the code into a spreadsheet that the victim views in Excel. If the attacker could find a way to supply code that Excel will execute, then we have an instance where an XSS attack targeted a non-web browser. I suppose we could call this a cross-application cross-site scripting (XAXSS) attack. (I wouldn't want to suggest the abbreviation "CAXSS" because then people could confuse it with the term Computer Assisted X-ray Screening System.)
XSS has been discussed for a while. Even though the mechanisms of such attacks are well-understood, XSS vulnerabilities continue to plague many web-based applications. SecurityFix mentioned a number of popular sites that have had XSS holes.
Now, a few words about XSRF/CSRF
An attack mechanism that is not as well-known, but is also very effective in targeting web applications is Cross-Site Request Forgeries (CSRF). (It's sometimes abbreviated as XSRF, although I prefer CSRF acronym, despite the potential for confusing it with the acronym for Canadian Sex Research Forum.) I wasn't as familiar with CSRF techniques as I should have been until I came across the Matasano Chargen posting, which pointed to Jeremiah Grossman's blog, which led me to Chris Shiflett's write-up.
A CSRF attack takes advantage of the web application's ability to act according to the HTTP command it receives from the user. Most web applications do that by design, of course. The trick in a CSRF attack is to get the victim's browser to submit the command of attacker's choice. The victim could receive a link to the targeted web application. The link would contain a GET request, which would cause the application to take action when the victim clicks on the link.
For example, clicking on the following link would cause the victim's Google.com preferences to be reset to Irish language:
This link, crafted by Dwayne Litzenberger, takes advantage of a XSRF weakness in Google.com's handling of user preferences. There are many ways in which the victim or his browser can be tricked into "clicking" on a link like this. For instance, the link could be embedded in a concealed iframe of the website the victim is visiting (as Google Blogoscoped pointed out), or it could be embedded into an img tag on the malicious site. [Update: I simplified the link from its original version per Adrian's advice.]
By submitting the request, the user will command the application to take the appropriate action. If the user is already logged in to the vulnerable application, the action could be taken behind the scenes without the victim's knowledge. For instance, a vulnerable banking site could be tricked into transferring the the victim's money out of his account.
Update: ISC reader Adrian wrote us to point out that he uses CSRF as a way of punishing script kiddies poking around his web server. Referring to the Google.com CSRF link mentioned above, he said, "I use it in my apache httpd.conf, as follows:
That teaches them to try to access non-existent php files on my webserver :P ..not that automated bots would follow redirects...but I occasionally catch some odd fish too :)"
How to mitigate CSRF risks?
As a web application developer, you can prevent CSRF vulnerabilities by using some difficult-to-predict token that a proper request needs to include, in addition to the session ID that the browser submits automatically via a cookie. The token could be embedded in the form that the application generates for the user. A CSRF link provided by the attacker would not include the token, and would be invalidated.
Alex Stamos commented on the use of such tokens in response to the Matasano Chargen posting on CSRF:
So we're back to hidden fields in forms and big blobs of crypto in GET parameters along with entropic and protected cookies...
Other ways of mitigating CSRF risks include the use of CAPCHA to check whether the request to an important page was submitted by a human before executing it, keeping the session time-out short, and not relying on cookie-based mechanisms for managing session IDs.
For additional information about CSRF, please see Chris Shiflett's write-up, the Cross Site Reference Forgery paper by Jesse Burns, and the Session Riding paper by Thomas Schreiber. (Session Riding is another term for CSRF attacks.)
Update: ISC reader Adam shared this CSRF war story with us: "I created a webpage where students could vote for next homecoming king and queen. I used HTTP-Auth to ensure only students could vote (and only vote once). But the 'submit' page used GET data to process votes. One creative candidate sent an email to a campus mailing list that appeared to be a standard 'click here to cast your ballot' message. But the link he used was to the 'submit' page (with his name in GET statement). So when someone would click on the link in their email, they would prompted by the HTTP-Auth and then be greeted by a 'thank you for voting' page. I let you guess who won..."
ISC Handler on Duty
Last Updated: 2006-10-01 23:44:11 UTC
by Lenny Zeltser (Version: 2)
OpenSSH patched two vulnerabilities in the release of OpenSSH 4.4. (Thanks for letting us know, Hamid.)
See also http://isc.sans.org/diary.php?storyid=1743
One denial-of-service condition was discovered by Tavis Ormandy, and could cause the SSH daemon "to spin until the login grace time expired." This issue affects OpenSSH if it has support for SSH version 1 enabled. (Please migrate to SSH version 2, if you can do so and haven't already.) A proof-of-concept exploit for this vulnerability is floating around. The CVE reference for this vulnerability is CVE-2006-4924.
The other denial-of-service condition was discovered by Mark Dowd. It could, theoretically, lead to remote execution of arbitrary code. This is probably the strongest reason to upgrade to OpenSSH 4.4 sooner, rather than later, although the release also includes some enticing new functionality.
An XSRF/CSRF vulnerability was reported in phpMyAdmin, a web-based front-end for managing MySQL servers. The bug could allow an attacker "to inject arbitrary SQL commands by forcing an authenticated user to follow a crafted link." The issue was fixed in the first release candidate for phpMyAdmin 2.9.1.
ISC Handler on Duty
Last Updated: 2006-10-01 21:57:25 UTC
by Swa Frantzen (Version: 5)
HistoryOn Friday 29th (and for nearly all of our readers past their working day), we saw the WebViewFolderIcon setslice exploit spreading in the wild. We raise our Infocon to Yellow in order to increase the awareness of the problem and call for action. We have decided to stay Yellow till Monday morning for most of our readers. Without further spectacular evolutions we will go back to Green on Monday.
This exploit started in the Month of Browser Bugs on July the 18th as a Denial of Service, however its author released recently a code executing variant of it.
Reason for YellowThe WebViewFolderIcon setslice exploit is becoming more widespread, so we changed the InfoCon level to yellow to emphasize the need to consider fixes.
If you have not taken measures yet, please consider some emergency fixes to cover the weekend. The exploit is widely known, easy to recreate, and used on more and more websites. The risk of getting hit is increasing significantly and the type of users of the exploit are also not the least dangerous ones. Some of the exploits are believed to be linked to CWS (CoolWebSearch), which is notoriously hard to remove.
ActionsWe suggest following actions (do them all: a layered approach will work when one of the measures fails):
- Update your antivirus software, make sure your vendor has protection for it (*).
- Install following killbits (**):
- Consider asking your users to stop their usage of MSIE, we know it's hard to break an addiction, but you're using the most targeted browser in the world.
QuoteAlex Sotirov from Determina on Full Disclosure: "We're also researching additional exploitation vectors. The underlying cause of the setSlice vulnerability is an integer overflow in COMCTL32.DLL, a core Windows component used by a large number of applications. The WebViewFolderIcon ActiveX control is most likely only one of the attack vectors for this vulnerability."
- Jesper's blog about setting killbit using group policy (GPO)
- Exploit prevention labs blog entry - iframe
- Exploit Prevention labs blog entry - CWS
- F-Secure blog
- JS/Exploit-BO.gen (McAfee)
- JS_PLOIT.BC (TrendMicro)
- Bloodhound.Exploit.83 (Symantec)
- Exploit.HTML.IESlice.a - Exploit.HTML.IESlice.c (Kaspersky)
- JS.CVE-2006-3730!exploit (CA)
(*): It's important to note the difference of your antivirus solutions detecting the exploitation itself (very rare) and detecting the payload of known exploits (common). Only the first will offer real protection against new threats.
(**): There are currently no reports of side effects on other application when stopping this ActiveX control.
Swa Frantzen -- Section66
Last Updated: 2006-10-01 13:08:42 UTC
by Koon Yaw Tan (Version: 2)
Java Runtime Environment (JRE) 5.0 Update 9
Test your installation
Update: As of Sun Oct 1 09:00:00 EDT 2006, neither the locally-installed, nor the on-line Java version tester seems to be aware of the 1.5.0_09 update. In one test, the on-line updated reported that 1.5_0_06 is the latest version. Also, Jim Manico reported that in his test, version 1.5_0_08 was reported as being up-to-date as well.
Perhaps the updater only detects major version changes? In this case, we saw no important security reason to rush with the 1.5_0_09 update. However, we hope that the update mechanism will work as advertised when an important security vulnerability needs to be patched.
(Original diary entry by Koon Tan; update by Lenny Zeltser)
Please choose a specific diary above to comment