[Full-disclosure] Advisory: Internet Explorer Drag and Drop Redeux [CVE-2005-3240] (fwd)
From: Matthew Murphy (mattmurphy AT kc.rr.com)
Date: Mon Feb 13 2006 - 18:46:38 CST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
My apologies to those who are receiving this late or are otherwise
inconvenienced by the staggered release. I had unexpected, last-minute
travel issues that interfered somewhat with today's release.
Of note since the initial drafting of the advisory is that Microsoft has
released a blog post on the MSRC blog about the vulnerability report,
which can be read here:
http://blogs.technet.com/msrc/archive/2006/02/13/419439.aspx
The technical/strategic points about the exploit that are raised in the
post are indeed accurate (though it references MS05-014, when I believe
the correct reference is MS05-008/MS05-013). The exploit has a greater
dependence on timing than previous, related attacks. As such,
Microsoft's decision not to include this issue in a standalone patch is
seemingly justified at this point. However, the point of disagreement
with Microsoft remains the choice of release *timeline*.
I released the information about this issue to a trusted colleague (Gadi
Evron) for publication today, after what I felt was a reasonable time,
in light of my difficulties obtaining internet access.
Though there are disagreements between myself and Microsoft about the
nature of this vulnerability, I would like to thank Brian Schafer of the
MSRC for adhering to a high level of professionalism and technical
accuracy in that post and for continuing to work with me once it was
made clear that the issue would imminently become public.
Also of note is that there was a typo in the information I provided
originally to SecuriTeam. The proper candidate is CVE-2005-3240, not
*3840* as was originally reported by me. SecurityFocus has also
informed me that my original BID reservation was a casualty of a data
migration and that the proper BID associated with this vulnerability is
now BID 16352, which is public in full detail as of this writing.
There have also been some incorrect reports made to SecuriTeam that this
issue does not affect Windows XP Service Pack 2. These reports are not
correct -- my testing during this investigation was done exclusively on
current installations of Windows 2000 and Windows XP. These systems had
all service packs applied and all updates installed when tests were
performed.
Thanks to Gadi Evron for doing some of my bidding today and taking some
of the heat for my fat-fingers.
The final advisory, corrected with the now-accurate references is
attached with an armored-format PGP signature inline.
- --
"Social Darwinism: Try to make something idiot-proof,
nature will provide you with a better idiot."
-- Michael Holstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB5444D38
iD8DBQFD8Shufp4vUrVETTgRA/hpAJ9DobMIa4EH8otBMNlzIPK6RrMGUgCfcrrj
ZI9G00rer59rLkwI5uH0KGQ=
=DQ2a
-----END PGP SIGNATURE-----
Microsoft Internet Explorer Drag-and-Drop Redeux
I. SYNOPSIS
Affected Systems:
* Microsoft Internet Explorer 5.01
* Microsoft Internet Explorer 5.5
* Microsoft Internet Explorer 6.0
- Windows 98
- Windows 98 Second Edition
- Windows Millennium Edition
- Windows 2000
- Windows XP
- Windows Server 2003
Risk: Medium
Impact: Potential remote code execution with some user interaction
Status: Uncoordinated Release
Author: Matthew Murphy (mattmurphykc.rr.com)
II. VULNERABILITY OVERVIEW
Microsoft Internet Explorer suffers from a vulnerability in its handling of certain drag-and-drop events. As a result, it is possible for a malicious web site to predict and exploit the timing of a drag-and-drop operation such that any drag operation (including using scroll-bars) could potentially lead to the installation of arbitrary files in sensitive locations that may enable further system compromise.
III. TECHNICAL DESCRIPTION
As a result of recent updates to its drag-and-drop functionality, Internet Explorer now imposes a rigid set of restrictions on most drag-and-drop sources:
* Input to the browser from other applications is not permitted.
* Dragging an object from inside a frame is not permitted.
* Dragging an HTML element from a top-level window will produce a security warning.
However, certain objects not derived from an HTML document (specifically, file objects within a folder view) remain draggable. This gives rise to a potential race condition in the handling of user input. If an attacker can persuade a user to drag any object within the top-level window that his/her site is contained in, malicious script can redirect these inputs to other top-level windows, potentially resulting in an unintended consequence such as file installation.
Proof-of-concept code has been developed that utilizes a pop-under window pointing to a malicious file share. This window can be created using window.open() or other stealthier methods that are known to evade Internet Explorer's built-in pop-up blocking. Focus is then returned to the opening window, where the user is encouraged to drag an object (image, link, etc.) in a seemingly "safe" fashion.
Immediately prior to this object being dragged, a mouseOver event is triggered that enables the attacker to (with a varying degree of success) predict the imminent drag attempt. The pop-under can then be returned to focus by way of a window.blur() executed in the current window. If the timing of the transition is accurate to a margin of error within a user's reaction time threshold, the user will unwittingly initiate a drag of a file from the pop-under instead of the object originally used as a lure by the attacker.
As soon as it transfers focus, the window with the original interactive content may set a timer (via window.setTimeout()) that returns focus to the window with a simple window.focus() call. After a split-second delay, focus is returned to the interactive window. At this point, on-demand alteration of CSS attributes can be used to display previously-hidden objects (such as inline frames). These objects serve as "drop target" windows and will initiate the copying of the file dropped from the (presumably malicious) pop-under window.
While Internet Explorer blocks hiding or resizing of certain "suspect" objects (IFRAMEs, for instance), so-called container objects (DIV, SPAN, etc.) suffer no such restrictions, even when they contain one of the objects in the former category. The proof-of-concept code as developed simply stores a full-screen inline frame in a container initially marked with the "hidden" visibility style.
The pop-under window, in this instance, would be a folder on a malicious server. This could be accessed via SMB (\\HOSTILESERVER\SHARE), FTP (ftp://hostileserver/somedirectory) or even HTTP (web folders) using certain link behaviors in combination with the click() method of a hyperlink object. In the third case, the pop-under would be targeted to an HTML document initally, which would then open the web folder containing hostile content.
The path to the drop target (the hidden frame in the original window) requires a little more creativity. Particularly in Windows XP Service Pack 2, Microsoft has done a fairly good job of locking down access to local resources. The most interesting vector for the purposes of this attack is via the network redirector. By using the IP address or machine name of the local system (typically obtainable via any number of means), such as:
\\MACHINENAME\share
It becomes possible to access resources offered by the network redirector on the local system. Of most interest is the "Scheduled Tasks" folder:
\\MACHINENAME\Scheduled Tasks
Items dropped into this folder execute automatically at a system-determined time (3 AM local time in tests on Windows XP Professional Service Pack 2) each day as the user dropping the file. Also of interest are common shares such as the administrative shares (C$, D$, etc.) and typical share names like "SharedDocs" on Windows XP. In most cases, this is at least a partial functional equivalent to local file system access and is not subject to zone restrictions, even on Windows XP Service Pack 2.
IV. IMPACT
A malicious web site, with a minimum of social engineering, may be able to compromise user systems by triggering an unintended installation of malicious software. Typical defense-in-depth measures may mitigate this issue. For those who run Internet Explorer with administrative privileges, the impact of any successful exploitation is complete control of the affected system. A malicious web site could install software that would add or delete privileged user accounts, alter, destroy or disclose the content of personal or otherwise sensitive files, record personal information or any number of other activities.
Users who do not browse with such high levels of privilege would be at a significantly reduced risk from exploitation of this vulnerability. In the case of a user with limited privileges, this vulnerability could only be exploited by an attacker to install software that executes with the privileges of that user.
V. WORKAROUNDS
The following workarounds are believed at the time of this writing to be effective against the exploitation of this vulnerability in some form:
1. Set a Kill Bit on the Shell.Explorer Control
-----------------------------------------------
Setting a kill bit on this control will prevent Internet Explorer from displaying the rich folder view interface that gives rise to this attack. For more information about setting kill bits, please see Microsoft Knowledge Base Article 240797:
http://support.microsoft.com/kb/240797
The CLSID of this component as deployed on Windows XP is:
{8856F961-340A-11D0-A96B-00C04FD705A2}
Tools to automate the process of setting this kill bit have been provided at:
http://student.missouristate.edu/m/matthew007/tools/shellkill.zip
PGP signature: http://student.missouristate.edu/m/matthew007/tools/shellkill.zip.asc
Included in this archive are an Administrative Template (.adm) and a VBScript file (.vbs) which implement this setting. The Administrative Template also allows an administrator to work around a specific case of functionality loss caused by the implementation of this workaround. Instructions on using both files are contained within the readme file in the archive.
IMPACT: This workaround will cause Internet Explorer to no longer render folder views for local directories, network file shares, FTP directories and web folders by default. The ability to browse FTP directories in Internet Explorer can be restored by clearing the "Enable Folder View for FTP Sites" option in Internet Explorer's "Advanced" options. However, this countermeasure is known to expose another security vulnerability that does not appear to have been fixed as of this writing:
http://lists.grok.org.uk/pipermail/full-disclosure/2003-June/005321.html
For ordinary browsing purposes, the Windows Explorer tool is unaffected by this change. This defensive measure has been successfully implemented in at least one commercial software product and tested on a significant scale prior to the release of this advisory. Therefore, it is the belief of the author that potential loss of functionality *should* be minimal. As with all measures, you are encouraged to test the impact of this workaround prior to making any decision about deployment.
2. Prevent Automatic Navigation to Local Intranet Zone (Windows XP SP2, Windows Server 2003 SP1)
------------------------------------------------------------------------------------------------
This workaround will prevent internet content in Internet Explorer from automatically navigating to URLs within the Local Intranet Zone. This effectively prevents the introduction of malicious code to the local system via the network redirector. To implement this workaround, follow these steps:
1. In Internet Explorer's Tools menu, choose "Internet Options..."
2. Select the "Security" tab and choose "Local Intranet"
3. Click the "Custom Level" button
4. Set the "Web sites in less privileged content zone can navigate into this zone" setting to "Disable" or "Prompt".
5. Click OK to close any dialogs and optionally, close Internet Explorer.
IMPACT: This workaround will block or prompt before allowing any navigation to LAN resources from the Internet Zone. Direct access to LAN resources continues to function normally. As a result of this workaround, attempts to access local intranet content (for instance, web applications on corporate intranets) from web sites outside of the LAN will fail or produce prompts, depending upon the chosen setting.
3. Disable Active Scripting
---------------------------
This workaround will prevent internet content from executing script that could potentially cause the exploitation of this vulnerability. To implement this workaround, follow these steps:
1. In Internet Explorer's Tools menu, choose "Internet Options..."
2. Select the "Security" tab and choose "Internet"
3. Click the "Custom Level" button
4. Set the "Active scripting" option to "Prompt" or "Disable".
IMPACT: This workaround will block or prompt before allowing web sites to execute any script statement. Scripting in more-privileged zones (Local Intranet, Trusted Sites) continues to function normally. Setting this option to "Prompt" may cause a significant increase in the number of security prompts received while browsing and may be ineffective in closing this vulnerability for users not capable of making an assessment of a web site's relative trustworthiness.
VI. MITIGATION RECOMMENDATIONS
1. Limit Viewing to Trusted Web Sites
-------------------------------------
In some situations, browsing can be successfully limited to only trustworthy sites without significant loss of productivity. Users should be extremely cautious while browsing unknown or untrusted web sites, as such web sites are often able to introduce hostile code.
2. Run Exposed Applications With Reduced Privilege
--------------------------------------------------
Users who log on interactively without the privileges of powerful groups such as the "Administrators" or "Power Users" groups are at a much lower risk of damage from successful exploitation of software vulnerabilities in client applications. This mitigation step greatly reduces the likelihood of a successful malware installation if this vulnerability is exploited.
VII. VENDOR RESPONSE
Microsoft was informed of this vulnerability on August 3, 2005. Currently, the company has no plans to issue a security update to correct this vulnerability. Fixes for this issue are scheduled to be included in Service Pack 2 of Windows Server 2003 and Service Pack 3 of Windows XP. Of particular note is that Windows 2000 users will *NOT* receive an update to correct this vulnerability.
Microsoft's internal risk-assessment concluded that this issue was not sufficiently serious to be fixed in a security bulletin. This conclusion appears fundamentally inconsistent with the way related issues were handled by Microsoft. In particular, the drag-and-drop vulnerability patched by MS05-013 received an "Important" rating.
I disagree with the technical conclusion behind Microsoft's decision and I further find the timeframe of delivery and deployment for maintenance releases to be largely unsuitable for security fixes of any significant magnitude. I find the harm this decision could potentially inflict upon down-level users (most importantly, users of Windows 2000) to be unjustified by the technical concern Microsoft has raised to me. Microsoft also rejected a request that it consider the issue for inclusion in a later security update as a "Moderate" risk issue.
Due to Microsoft's noncommittal and generally unimpressive response to the issue, this advisory is being issued to inform users of this vulnerability such that defensive action may be taken as desired.
VIII. REFERENCES/STANDARDS
* CVE
The MITRE Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2005-3840 to this issue. Status information and related references for this candidate may be found at:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3840
* OSVDB
The Open Source Vulnerability Database (OSVDB) project has assigned OSVDB vulnerability ID #2707 to this issue. Information will be available shortly after the publication of this advisory at the following URL:
http://www.osvdb.org/displayvuln.php?osvdb_id=2707
* SecurityTracker
SecurityTracker has pre-assigned an alert number in its internal database to reference this issue. Information will be available shortly after the publication of this advisory at the following URL:
http://www.securitytracker.com/id?1015049
* SecurityFocus
SecurityFocus has pre-assigned BugTraq ID #15089 to reference this issue. Information will be available shortly after the publication of this advisory at the following URL:
http://www.securityfocus.com/bid/15089
IX. ACKNOWLEDGEMENTS
* The Administrative Template file supplied in the workaround ZIP was authored by Steven Platt.
X. CONTACT
The author may be contacted via e-mail at mattmurphykc.rr.com
XI. LEGAL
This document is believed accurate based upon information available at the time it was written. However, the information offered is offered in an AS-IS condition, without warranty. By acting upon this information in any way you accept all responsibility for damage that may occur as a result.
This document may be reproduced in whole without limitation and in part provided that a full copy of the original document is readily accessible and the author of the document is duly acknowledged.
Labels: Advisory, http, Microsoft, Vulnerability
Web Application Auditing Over LunchMarch 22nd, 2007
By Dr. Johannes B. Ullrich
Version 1.0
Web applications are frequently the Achilles heel of a network. A Web application has to be accessible to all of your customers. Ports 80 and 443 have to be open to the world to provide ubiquitous access to the Web application. On the other hand, a full-featured Web application is connected to a corporation′s database storing customer, order, and pricing information. In short: A Web application is the shortest path for an attacker to take to reach the organization′s crown jewels. Securing Web applications is critical and not easy. This paper outlines some simple steps to audit the security of a Web application. Sadly, while this audit is simple and incomplete, a lot of applications will fail the test. A more comprehensive audit will include source code reviews and more advanced techniques to circumvent security measures.
NOTE: You will need WRITTEN permission from your company to perform this audit. Failure to obtain such permission may get you fired, prosecuted, or worse: your GIAC certifications may be revoked.
First StepsDon't forget the obvious. A quick portscan with nmap may reveal an unprotected VNC server or a database server with no password. Any penetration test should start with a quick portscan, likely followed by a vulnerability scan with a tool like Nessus. The use of a more Web-specific scanner (like Nikto) will save you a lot of tedious work. Nikto, in particular, is good at scanning for common problems like default installations of vulnerable tools, outdated versions, and left-over backup and configuration files.
ToolsBefore we get started, let's talk about some tools. In order to perform your audit, you need appropriate tools to attack the application under test. You already have the most important tool for auditing Web applications: a browser. If you use Firefox, you will be able to use a number of free toolbars that will make it much easier to launch the attacks outlined below. We recommend the following plugins:
Web Developer toolbar (https://addons.mozilla.org/firefox/60/) A Swiss Army knife-like extension every Web developer should have installed. For our purposes, the important feature is the ability to modify forms on the fly to remove some of the restrictions imposed by forms. For example, you are able to enter strings beyond the designed length, or you are able to edit locked fields.
Hackbar (https://addons.mozilla.org/firefox/3899/) Nice tool to decode Base64 and URL Encoding. It is also helpful in obfuscating SQL injection attacks.
SwitchProxy Tool (https://addons.mozilla.org/firefox/125/) If you decide to use a proxy server like WebScarab, Switch Proxy allows you to quickly switch proxies.
Add N Edit Cookies (https://addons.mozilla.org/firefox/573/) The Add N Edit Cookies cookie editor will allow you to edit cookies on the fly. This tool gives you one less reason to require a full proxy server to intercept requests.
Tamper Data (https://addons.mozilla.org/firefox/966/) This extension, much like a proxy server, will allow you to intercept requests and responses. Either may be manipulated at will.
These toolbars allow you to do most of what is required to quickly test a Web application. However, for some of the more advanced techniques, a proxy server can be helpful. Probably the most full-featured free proxy server for auditing purposes is
WebScarab (http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project). The Open Web Application Security Project (OWASP) Web site is also a good resource to learn more about Web application security.
PreparationBefore you start, configure your browser to show hidden fields and comments and to ignore form limits. This will make some of the tests discussed later a bit easier to complete. Here is how to adjust the Web Developer toolbar:
In the Options menu, select Persist Features. This will make your selections stick, so you don't need to adjust them for each new page.
Now move to the Miscellaneous menu and select Show Hidden Elements as well as Show Comments.
In Forms, select Make Form Fields Writeable and Remove Maximum Length. Later, you may want to use the Convert POST to GET function to make it easier to manipulate form content.
As a quick test, start browsing the site you are testing and become familiar with it. You will see yellow exclamation marks within the web page displayed by Firefox whenever there is a comment. The current version of the Web Developer toolbar appears to have a bug in that the hidden fields are not shown all the time. It may be easier to use WebScarab if you find a lot of hidden fields, because WebScarab will make them editable.
In a worst case scenario, you will find things like passwords or account names in comments listed in the Web Developer toolbar. At this point, your quick audit would likely be complete. There is no need to go any further if the goal is just to show that a side is vulnerable.
The AuditWith browser and toolbars ready and armed, we are all set to dive into the actual audit. The steps below are listed in the order in which they are most likely to deliver results, staying with our theme to find problems quickly.
robots.txt: A vulnerability roadmap. The robots.txt file is often misunderstood by Web developers. The file will not protect or hide content. It is only used by well-behaved search engines to avoid indexing content that should not be indexed. A good robots.txt file includes content like image directories or locations that are generated dynamically and do not work if a search engine accesses the page. A bad robots.txt file, on the other hand, will list admin pages, Web logs, and similar locations. Access all the locations listed in robots.txt and see what you find. If, as part of this experiment, you hit a page with Web logs, browse the Web logs for any administrative pages. If they are not obviously named /admin, look for pages hit by only very few hosts. Your quest to prove that the web application is vulnerable may already be over if you find a non-password-protected admin page. For each password-protected admin page, try a few obvious username/password combinations. But don′t spend too much time on it. After all, we only have 1 hour to break the site.
XSS: trial and error. Cross site scripting (XSS) is probably the most common vulnerability. Not all XSS issues are easily exploitable. However, the presence of these errors demonstrates lack of attention to input validation and output sanitation. The most likely place to find XSS is in the search function. Enter a "e;>"e; as a search string and see what you get. In particular, watch for pieces of HTML code that may all of the sudden be visible or for skewed formatting in forms. As a next step, enter ">. Even if you don't see the popup message, try to find the string in the result. See how the application dealt with the quote. As a note, many applications will escape single quotes (′) but not double quotes ("). If you try to inject JavaScript, you may need to use double quotes only. Again, for this 1 hour exercise, we are only trying to find XSS problems. Exploiting them may take a bit more time. More dangerous XSS issues arise if content is stored in a database and not escaped properly if returned. The most likely location for this XSS vulnerability is any mailing or shipping address. Try to set up an account with the Web site, and use > or similar strings as street or city name. These issues are almost always exploitable to retrieve administrator cookies because they retrieve addresses for order fulfillment or customer service.
SQL Injection: trial and error. The procedure to find SQL injection is similar to what we did for XSS. Start by entering a single quote in various form fields. As an indication of SQL injection is going to be possible, you may see a database error returned. Once you have the database error, it should tell you more about the nature of the problem. Some Web sites do a decent job of hiding the error messages. In this case, SQL injection is a bit more tricky. Try to guess a valid, but bad, SQL query. For example if you get an error for page.html?id=1′ , try page.html?id=1%20or%201 and page.html?id=1′%20or′1′=′1 or page.html?id=1-- to see if you still get the error page. This can easily be the most time-consuming part of the audit. If you suspect SQL injection issues, try to use a tool like Paros, which can assist you in finding SQL injection problems. In addition to the obvious quotes, try to use characters like double-dash (--), semi-colon (;) or comma (,). Blind SQL injection, which is frequently necessary if no error messages are displayed, is a more advanced topic and is beyond the scope of this paper.
Cookies and Hidden Fields. Cookies and hidden form fields are just another form of user-provided input. However, a lot of Web developers don't see it that way and treat cookies and hidden fields as trusted data. So, if you are still looking for vulnerabilities, try to inject some single quotes and XSS characters and see what you get. The Add N Edit Cookies toolbar is all you need for this. The Web Developer toolbar will allow you to edit hidden fields that you find.
Sessions. With sessions, you will find developers who are using a standard toolkit, in which case the sessions are likely reasonably secure, or you will find developers using homemade toolkits that are frequently flawed. Take a look at the session ID. Does it look like a long random string? Start playing with it. Remove and add characters. Again, try to add a single quote or XSS. Is the text cleaned up? If your session ID is numeric: Try to replace the session ID with the next number. Also, try and increment the last two numbers by 1 each (in case the last digit is a checksum). Are you able to get someone else's session? At the very least, your session ID should change after you log in. In the best case scenario, the session ID should change on each page view. Webscarab can help with session ID analysis if you need to dive in deeper. Webscarab is a proxy server. It can be configured to intercept all data passed to the server or to the browser. Before it passes the data to the server or browser, the user can edit the data at will. Webscarab offers a large number of additional features to analyze the content passing between browser and server. The session ID analysis is one of these features. Session ID analysis will graph session Ids collected from the website to make it easy to spot patterns.
Google Hacking. Take a look at Google and check what it knows about the site. You can limit Google's focus by adding a?site:example.comato the search. Strings to search for include: "sql", "error", "password", "cvv2".
Spidering.Run wget -m http://www.example.com to retrieve a mirror of the site. This will cause wget to create a directory called www.example.com. Use grep to find any errors or other odd contents like error messages or comments. This is essentially the same thing the Google search will do, but grep is more complete. Note that Google as well as wget obey robots.txt. At this point, you are likely a bit more familiar with the application you are testing. Google can help to find default locations for configuration files (e.g. global.asa) or administrative consoles for the particular Web application.
ConclusionThese tests will only find obvious problems and are less likely to find more complex issues. We totally neglect some common problems like response-splitting or secondary SQL injection issues, and we spent little time on actually exploiting these problems. See this 1 hour audit as a due diligence test that should be done periodically. It is also a great learning tool for Web developers. By involving them in such an audit, they will find out more about how easy it can be to exploit some of the problems the audit identifies. Have them actually perform the test or perform the test with them. If they are part of the audit team it will be much easier to explain what is going on and they won't see the test in a confrontational manner.
In order to do a more exhaustive test, it is highly advisable to use the source code for the Web application. Again, this is easy if you have cooperating Web developers. With source code, it is much easier to validate a problem and estimate its impact.
We did not say much about how to defend against each of these tests. However, the overall approach should not be to fix vulnerabilities one at a time as they are found, but to develop strategies and procedures that will prevent these vulnerabilities in the first place. It is imperative for a Web application to create a library of authentication, access control, session handling, and validation functions that are used consistently throughout the application.
Referenceshttp://www.owasp.org: Open Web Application Security Project.
http://www.cgisecurity.com/articles/xss-faq.shtml: The Cros Site Scriptin (XSS) FAQ
http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf": SQL Injection White Paper
http://www.robotstxt.org: The Web Robots Page
http://johnny.ihackstuff.com: The Google Hacking Database
Many thanks to the ISC handlers, in particular Jason Lam, for the discussions that led to this paper.
Labels: Attack Tools, http, News Article
Malware type: JavaScript
Aliases: No Alias Found
In the wild: Yes
Destructive: No
Language: English
Platform: Windows 98, ME, NT, 2000, XP, Server 2003, Mac OS X
Encrypted: No
Overall risk rating: Low
Reported infections: Low
Damage potential: High
Distribution potential: Low
Size of malware: 5,609 Bytes
Initial samples received on: Mar 16, 2007
Related to: TROJ_DLOADER.JHV
Payload 1: Steals information
Details:
This malicious JavaScript may be dropped by another malware. It may also be downloaded from the Internet, particularly by the malware TROJ_DLOADER.JHV.
It is used to steal information, such as login credentials, used in MySpace accounts. MySpace (www.myspace.com) is a popular social networking Web site that hosts profiles of users from all around the world.
This JavaScript uploads the stolen information to the URL http://BLOCKED}ofileawareness.com/logs4/connect.php. As a result, remote users may view and use the uploaded information for malicious purposes.
It runs on Mac OS X, Windows 98, ME, NT, 2000, XP, and Server 2003.
Analysis By: Carlo Panganiban
Labels: Anti-Virus, http, Microsoft, Trojan
Phishing using IE7 local resource vulnerability
Summary
Internet Explorer 7.0 is vulnerable to cross-site scripting in one of its local resources. In combination with a design flaw in this specific local resource it is possible for an attacker to easily conduct phishing attacks against IE7 users.
Affected versions
• Windows Vista - Internet Explorer 7.0
• Windows XP - Internet Explorer 7.0
Technical Details
The navcancl.htm local resource is used by the browser when for some reason a navigation to a specific page is canceled.
When a navigation is canceled the URL of the specific page is provided to the navcancl.htm local resource after the # sign. For example: res://ieframe.dll/navcancl.htm#http://www.site.com. The navcancl.htm page then generates a script in the “Refresh the page.” link in order to reload the provided site again when the user clicks on this link.
It is possible to inject a script in the provided link which will be executed when the user clicks on the “Refresh the page.” link.
Luckily, Internet Explorer now runs most of its local resources (including navcancl.htm) in “Internet Zone”, so this vulnerability cannot be exploited to conduct a remote code execution.
Unfortunately, there is also a design flaw in IE7. The browser automatically removes the URL path of the local resource and leaves only the provided URL. For example: when the user visits res://ieframe.dll/navcancl.htm#http://www.site.com, IE7 will show http://www.site.com in the address bar.
To perform a phishing attack, an attacker can create a specially crafted navcancl.htm local resource link with a script that will display a fake content of a trusted site (e.g. bank, paypal, MySpace).
When the victim will open the link that was sent by the attacker, a “Navigation Canceled” page will be displayed. The victim will think that there was an error in the site or some kind of a network error and will try to refresh the page. Once he will click on the “Refresh the page.” link, The attacker’s provided content (e.g. fake login page) will be displayed and the victim will think that he’s within the trusted site, because the address bar shows the trusted site’s URL.
Proof-of-Concept
A CNN.com article spoofing proof-of-concept can be found here.
If you are not using IE7, you can watch a demonstration video here.
Workaround / Suggestion
Until Microsoft fixes this vulnerability, do not trust the “Navigation Canceled” page!
Labels: Exploit, http, Microsoft, Vulnerability
'We all know there are still people out there who think turning off JavaScript protects them from everything.'
See also : https://www.indiana.edu/~phishing/browser-recon/
Research by RSnake
----------------------------------
Well, the server is back up and running (big thanks to id - during our upgrade there was a drive failure causing us to have to switch machines), and to celebrate I didn’t want to come back with a boring post that would make you question why you read this site. So instead I decided to play around with some CSS tricks - bare with me for a minute. I don’t know why, but I really think CSS is going to get worse over time. Anyway, as I was poking around I happened across one of the missing pieces of the puzzle to solve a simple problem in using CSS to hack - the lack of conditional logic.
Jeremiah and I spent at least an hour on the phone several months back when he was coming up with browser port scanning without JavaScript. One of the key problems with that technique, which he later overcame, was that he was unable to find any good way to do conditional logic in CSS, so instead he leaned on a browser quirk that delays the rendering of images. Watching the timing differences can help an attacker derive which ports are open and which aren’t. While very cool, it’s caused some headaches and only solved one of our problems.
Before that Jeremiah also came up with the original CSS history hack as you may or may not remember. Later on pdp came up with another variant of the same issue using a very different technique (Firefox caching). Both of those techniques were cool, but both of them also required that you have JavaScript turned on. We all know there are still people out there who think turning off JavaScript protects them from everything.
Keeping this in mind it would be great if you could create a form of conditional logic in CSS. Well I finally figured out a way. Using a hybrid of a:visited and display: attribute you can detect that the user has visited a page and more importantly perform an action based on that fact. The actions are somewhat limited if you can’t use JavaScript, however, one action is enough. The reason being, when something is set to display:none it will actually cause the HTML tag that it references to not render. Setting the background: image attribute for the visible tag to use a URL of a logging CGI script allows you to send a request to a remote webserver based on the conditional logic as mentioned above.
Now, the only lacking part is the state management, and that can easily be tied together using a unique cookie, and/or an IP address in the QUERY_STRING or anything else you want to use to identify the user. In this way, the remote website can steal history information from the user without ever once using JavaScript, or any client side programming. Click here for a proof of concept of the CSS history theft without using JavaScript. This works nearly instantly, so it is far better than the JavaScript-less intranet hacking and pdp’s version of the JavaScript CSS history hack in terms of speed. The only latency is the time it takes your browser to request the images associated with each URL you’ve visited - which is nearly instant since I don’t return any data (and thanks to browser threading). The other nice thing about this is that it works beautifully in both Internet Explorer 7.0 and Firefox 2.0.0.2 (although it doesn’t work in Opera 9.22).
I haven’t experimented much with this yet, but I also believe this could be expanded to do another form of intranet port scanning as well. Using a series of iframes and forced browsing it may be possible to detect which pages the user can access. I’m not in love with this technique because the CSS will fire too quickly so you’d have to delay the CSS from loading or make it reload with a meta refresh or something equivalent, but I also haven’t put much thought into it yet.
The ramifications of the CSS history hacking stuff is that it allows the attacker to steal information about the client, which can be useful to identify a target, to find information about the user, for use in targeted attacks, to know trending information for use in targeted advertizements or other forms of private information theft.
So now we’ve eliminated the JavaScript pre-requisite from Intranet port scanning, cross site request forgeries, session riding and of course CSS history hacking. The only thing we can’t yet do without JavaScript is read cross domain (and I stress the word yet). What else is left? I don’t mean to sound ho-hum about this, but really, what else do we have to do? Are there any nay-sayers left?
Labels: Exploit, http, Vulnerability
Malware type: JavaScript
Aliases: No Alias Found
In the wild: Yes
Destructive: No
Language: English
Platform: Windows 98, ME, NT, 2000, XP, Server 2003
Encrypted: No
Overall risk rating: Low
Reported infections: Low
Damage potential: High
Distribution potential: High
Malware Overview
This malicious JavaScript is usually embedded in a malicious Web site and is run on a system when a user visits the said Web site. It may also arrive on a system as an attachment to a mass-mailed email message.
Upon execution, it decodes and drops a file detected by Trend Micro as WORM_FEEBS.OV. As a result, routines of the related worm may be exhibited on the affected system.
It also displays a fake loading page that displays the following message:
Error while decrypting file
Solution:
(Note: Close all instances of Internet Explorer before proceeding with the solution below.)
Important Windows ME/XP Cleaning InstructionsUsers running Windows ME and XP must disable System Restore to allow full scanning of infected computers.
Users running other Windows versions can proceed with the succeeding solution set(s).
Running Trend Micro Antivirus
If you are currently running in safe mode, please restart your computer normally before performing the following solution.
Scan your computer with Trend Micro antivirus and delete files detected as JS_FEEBS.JM and WORM_FEEBS.OV. To do this, Trend Micro customers must download the latest virus pattern file and scan their computer. Other Internet users can use HouseCall, the Trend Micro online virus scanner.
Labels: http, Microsoft, Virus
Published: 2007-02-26,
Last Updated: 2007-02-26 23:25:38 UTC
by Swa Frantzen (Version: 3)
What happens when an adept of the dark side of the force looks at the documentation on javascript's onUnload() function ?
Take a look for yourself and come back, we won't go anywhere:
So something that gets called no matter how the user tries to get away from a web page. Imagine what pages you might want to get away from ...
As the MSDN article says, adding a window.open() call in such a routine becomes a nightmare for the visitor as (s)he'll never manage to get away on his/her own. Pop-up blockers should -if all goes right- detect and prevent that one case. But it gets worse, how about "location = self.location;" ? Right, the visitor doesn't go away at all.
Is there anything new to this? Not as such, it's been known for years and was e.g. discussed in August of 2005 on full disclosure mailing lists.
One would assume open discussion of such a function where it's being labeled as potentially evil would cause security conscious developers to take note of such a dangerous function and severely limit it's possibilities, or better yet to get rid of it altogether.
Yet there seems to have been no such luck. Worse, there seems to have been renewed attention form those using the dark side as evidenced by these recent reactions:
MSIE 7:
CVE-2007-1091 (mitre) or
CVE-2007-1091 (nist)
"Microsoft Internet Explorer 7 allows remote attackers to prevent users from leaving a site, spoof the address bar, and conduct phishing and other attacks via onUnload Javascript handlers. "
We've henve updated the table tracking the known vulnerabilities in Microsoft products.
Firefox:
US-CERT Vulnerability Note VU#393921"Mozilla Firefox fails to properly handle JavaScript onUnload events. Specifically, Firefox may not correctly handle freed data structures modified in the onUnload event handler possibly leading to memory corruption. By convincing a user to view a specially crafted HTML document (e.g., a web page or an HTML email message or attachment), an attacker may be able to execute arbitrary code with the privileges of the user."
Firefox seems to have fixed it in versions 2.0.0.2 and 1.5.0.10
Personally I've a hard time to see how supporting onUnload() matches with statements such as:
"Put safety first.
Robust new Internet Explorer 7 architecture and improved security features help protect you against malicious software, and help to keep your personal data safe from fraudulent websites and online phishing scams." (taken from http://www.microsoft.com/windows/products/winfamily/ie/default.mspx )
Firefox has a "security is important"
statement just as well.
Best course of action: disable scripting, but most of you can't or don't want to do that. The second best alternative might be to use extensions such as
NoScript in Firefox that allows more selective control of who gets to do remote code execution in your browser. Yes that's what allowing java, VBscript and javascript basically is: allowing random websites to hand your browser code to execute ...
--
Swa Frantzen -- NET2S
Labels: http, Vulnerability
From: Michal Zalewski (lcamtuf at dione.ids.pl)
Date: Sat Feb 03 2007 - 14:57:01 CST
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
As you probably know, the famous "web 2.0" XMLHttpRequest object allows
client-side web scripts to send nearly arbitrary HTTP requests, and then
freely analyze and manipulate the returned response, including HTTP
headers.
This gives an unprecedented level of control over your browser to the
author of a visited site. For this reason, to prevent various types of
abuse, XMLHttpRequest is restricted to interacting only with the site from
where the script originated, based on protocol, port, and host name
observed.
Unfortunately, due to a programming error, Microsoft's Msxml2.XMLHTTP
ActiveX object that MSIE relies on allows you to bypass this restriction
with the use of - BEHOLD - a highly sophisticated newline-and-tab
technology.
If the victim uses a proxy server (which is very common in corporate
settings), any intranet or Internet site can be interacted with in this
arcane manner:
xmlhttp.open("GET\thttp://dione.ids.pl/\tHTTP/1.0\n\n", "x",true);
Otherwise, only sites co-hosted on the same server or load balancer can be
interacted with - which today can still mean quite a lot, for example
foxyteens.googlepages.com and gmail.com go nicely together. In such a
case, the request is:
xmlhttp.open("GET\t/\tHTTP/1.0\nHost:\tdione.ids.pl\n\n", "x",true);
All contents of the requested page, including cookies, hidden form tokens,
etc, can be then extracted through the use of responseText and
getResponseHeader(), manipulated by the script, and used into subsequent
GET or POST requests.
A test page is available here:
http://lcamtuf.coredump.cx/iexmltest.html
The browser will think it's still talking to the site from which the
script originated, so no session cookies will be sent to that server - but
some interesting activity is still possible: in the true spirit of Web
2.0, this can be trivially turned into an interactive client-side backdoor
proxy that may send shivers down the spines of some corporate security
dudes.
Consider this example: a guy working for company X is sent a link to
hotbrunette25's blog or a really cute video of singing hamsters. While he
is preoccupied with that resource, the creator of a malicious script can
order victim's browser to:
1) Rapidly scan company's internal web services (XMLHttpRequest
supports asynchronous connections and connection notification),
2) Obtain real-time copies of site fronts (raw HTML responseText can be
sent back directly to the attacker through a "legitimate"
XMLHttpRequest).
3) Interact with interesting ones in real-time in a virtually
unrestricted manner (POSTs and GETs with any payloads can be
requested, cookies can be set with setRequestHeader, etc).
Attacker functionality can be esentially implemented as a browser plugin
or a custom proxy and allow what amounts to highly-responsive,
feel-like-you're-there, remote presence - which certainly takes what used
to be blind bounce scanning and XSS to a 2.0 level.
In a setting where no proxy is available, and no elaborate private
infrastructure would be exposed to the attacker, the author of
foxyteens.googlepages.com can of course still use this to send possum
gang-rape spam through GMail from victim's IP, or whatnot - but that's of
course less exciting.
/mz
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Labels: http, Insecurity, Microsoft
Microsoft IE mshtml.dll Multiple Script Action Handler Overflow
OSVDB ID: 23964
Disclosure Date: Mar 16, 2006
Description:
Remote overflow exists in Microsoft Internet Explorer. The product fails to properly check bounds for handling HTML tags with multiple event handlers resulting in a buffer overflow. With a specially crafted HTML document, an attacker can cause affected web browsers to crash or remote code execution resulting in a loss of integrity, and/or availability.
Vulnerability Classification:
Remote/Network Access Required
Denial Of Service Attack
Input Manipulation
Loss Of Integrity
Loss Of Availability
Exploit Available
Verified
Products:
Microsoft Corporation Internet Explorer 6.0 SP2
Microsoft Corporation Internet Explorer 7.0 beta 2
Microsoft Corporation Internet Explorer 7.0 beta 1
Solution:
Currently, there are no known upgrades, patches, or workarounds available to correct this issue.
Manual Testing Notes:
The following HTML content demonstrates this issue by crashing the browser:
<script>
for(s='<a onclick=',i=0;i<8||(document.write(s+'>'));i++)s+=s;
</script>
External References:
Snort Signature ID: http://www.snort.org/pub-bin/sigs.cgi?sid=100000238
CVE ID: http://cve.mitre.org/cgi-bin/cvename.cgi?name=2006-1245
National Vulnerability Database: http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-1245
Bugtraq ID: http://www.securityfocus.com/bid/17131
Microsoft Security Bulletin: http://www.microsoft.com/technet/security/bulletin/MS06-013.mspx
Generic Exploit URL: http://lcamtuf.coredump.cx/iedie.html
ISS X-Force ID: http://xforce.iss.net/xforce/xfdb/25292
Secunia Advisory ID: http://secunia.com/advisories/18957
Secunia Advisory ID: http://secunia.com/advisories/19269
Microsoft Knowledge Base Article: http://support.microsoft.com/default.aspx?scid=kb;EN-US;912812
Other Solution URL: http://snort.org/rules/advisories/ie-issue-js-v2.txt
Mail List Post: http://archives.neohapsis.com/archives/bugtraq/2006-03/0303.html
Mail List Post: http://archives.neohapsis.com/archives/bugtraq/2006-03/0304.html
Mail List Post: http://archives.neohapsis.com/archives/bugtraq/2006-03/0310.html
Mail List Post: http://archives.neohapsis.com/archives/bugtraq/2006-03/0325.html
Mail List Post: http://archives.neohapsis.com/archives/bugtraq/2006-12/0048.html
Security Tracker: http://securitytracker.com/id?1015794
Credit:
Michal Zalewski (lcamtuf@dione.ids.pl) - Personal page (http://lcamtuf.coredump.cx/)
Labels: Advisory, Bug, http, Microsoft
Advisory ID : FrSIRT/ADV-2006-0469
CVE ID : CVE-2006-0020
OVAL ID : OVAL1638
Rated as : Critical
Remotely Exploitable : Yes
Locally Exploitable : Yes
Release Date : 2006-02-08
Technical Description
A vulnerability has been identified in Microsoft Internet Explorer, which could be exploited by remote attackers to execute arbitrary commands. This flaw is due to a memory corruption error in the rendering of Windows Metafile (WMF) images containing a specially crafted header size, which could be exploited by attackers to remotely take complete control of an affected system by convincing a user to open a malicious email attachment or visit a specially crafted Web page that is designed to automatically exploit this vulnerability through Internet Explorer.
Affected Products
Microsoft Internet Explorer 5.01 Service Pack 4 on Microsoft Windows 2000 Service Pack 4
Solution
Upgrade to Internet Explorer 6 Service Pack 1 :
http://www.microsoft.com/windows/ie/downloads/critical/ie6sp1/default.mspx
Or apply patch :
http://www.microsoft.com/downloads/details.aspx?FamilyId=C0DF2FC3-2075-46B5-945F-6E0BD6806151
References
http://www.frsirt.com/english/advisories/2006/0469
http://www.microsoft.com/technet/security/advisory/913333.mspx
http://www.microsoft.com/technet/security/Bulletin/MS06-004.mspx
ChangeLog
2006-02-08 : Initial release
2006-02-14 : MS06-004 released
Labels: Advisory, http, Microsoft
SEC-CONSULT Security Advisory < 20060613-0 >
=======================================================================
title: HTML Code Injection in Outlook Web Access
program: Outlook Web Access
vulnerable version: Exchange 2000 (SP3), 2003 (SP1), 2003 (SP2)
impact: severe
homepage: http://www.microsoft.com/exchange/default.mspx
found: 2005-10-25
by: D. Fabian / SEC-CONSULT / www.sec-consult.com
T. Kerbl / SEC-CONSULT / www.sec-consult.com
=======================================================================
vendor description:
---------------
Microsoft Office Outlook Web Access is an integrated component of
Exchange Server 2000/2003. By using only a Web browser and an Internet
or intranet connection, Outlook Web Access enables users to read their
corporate e-mail messages, schedules, and other information that is
stored on a server running Exchange.
[Source: http://www.microsoft.com/exchange/evaluation/features/
owa2k3_55.mspx]
vulnerability overview:
---------------
Microsoft Outlook Web Access is vulnerable to an HTML code
injection/cross site scripting attack. A malicous user could craft a
mail containing HTML and Javascript code. Such code could be used to
steal session information from the victims cookies, and thus enable
the attacker to get access to the victim's emails.
In alternative Browsers like Mozilla Firefox or Opera the mere opening
of an crafted email is enough for Javascript code to execute. As soon
as the victim clicks on the malicious email, the Javascript code can
read session information and send this to the attacker, who can
then perform session highjacking and read the victims emails.
As Internet Explorer uses proprietary security mechanisms (mails
are displayed as pages in restricted security zone) it is not
possible to inject Javascript code directly into email bodies.
However our research showed, that using HTML attachments (which are
also subject to input sanitation in OWA), the Javascript Code can be
successfully executed. Furthermore HTML Code injection is still
possible directly in the email body. This can be used e.g. by
malicious attackers to include images which are displayed without
further user interaction and thus verify whether the user read the
email or not. Also links can be directly included, curcumventing
OWA's redirection feature.
vulnerability details:
---------------
To allow time to Microsoft Exchange administrators to patch their
systems, SEC Consult is going to withhold vulnerability and exploit
details for 2 weeks.
vulnerable versions:
---------------
The following versions of Microsoft Exchange Server are vulnerable
to the described security flaw:
- Microsoft Exchange 2000 Server Pack 3 with the August 2004
Exchange 2000 Server Post-Service Pack 3 Update Rollup
- Microsoft Exchange Server 2003 Service Pack 1
- Microsoft Exchange Server 2003 Service Pack 2
vendor status:
---------------
vendor notified: 2005-10-27
vendor response: 2005-10-27
patch available: 2006-06-13
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SEC Consult Unternehmensberatung GmbH
Office Vienna
Blindengasse 3
A-1080 Wien
Austria
Tel.: +43 / 1 / 890 30 43 - 0
Fax.: +43 / 1 / 890 30 43 - 15
Mail: office at sec-consult dot com
www.sec-consult.com
EOF Daniel Fabian / @2006
research at sec-consult dot com SEC-CONSULT Security Advisory < 20060613-0 >
=======================================================================
title: HTML Code Injection in Outlook Web Access
program: Outlook Web Access
vulnerable version: Exchange 2000 (SP3), 2003 (SP1), 2003 (SP2)
impact: severe
homepage: http://www.microsoft.com/exchange/default.mspx
found: 2005-10-25
by: D. Fabian / SEC-CONSULT / www.sec-consult.com
T. Kerbl / SEC-CONSULT / www.sec-consult.com
=======================================================================
vendor description:
---------------
Microsoft Office Outlook Web Access is an integrated component of
Exchange Server 2000/2003. By using only a Web browser and an Internet
or intranet connection, Outlook Web Access enables users to read their
corporate e-mail messages, schedules, and other information that is
stored on a server running Exchange.
[Source: http://www.microsoft.com/exchange/evaluation/features/
owa2k3_55.mspx]
vulnerability overview:
---------------
Microsoft Outlook Web Access is vulnerable to an HTML code
injection/cross site scripting attack. A malicous user could craft a
mail containing HTML and Javascript code. Such code could be used to
steal session information from the victims cookies, and thus enable
the attacker to get access to the victim's emails.
In alternative Browsers like Mozilla Firefox or Opera the mere opening
of an crafted email is enough for Javascript code to execute. As soon
as the victim clicks on the malicious email, the Javascript code can
read session information and send this to the attacker, who can
then perform session highjacking and read the victims emails.
As Internet Explorer uses proprietary security mechanisms (mails
are displayed as pages in restricted security zone) it is not
possible to inject Javascript code directly into email bodies.
However our research showed, that using HTML attachments (which are
also subject to input sanitation in OWA), the Javascript Code can be
successfully executed. Furthermore HTML Code injection is still
possible directly in the email body. This can be used e.g. by
malicious attackers to include images which are displayed without
further user interaction and thus verify whether the user read the
email or not. Also links can be directly included, curcumventing
OWA's redirection feature.
vulnerability details:
---------------
To allow time to Microsoft Exchange administrators to patch their
systems, SEC Consult is going to withhold vulnerability and exploit
details for 2 weeks.
vulnerable versions:
---------------
The following versions of Microsoft Exchange Server are vulnerable
to the described security flaw:
- Microsoft Exchange 2000 Server Pack 3 with the August 2004
Exchange 2000 Server Post-Service Pack 3 Update Rollup
- Microsoft Exchange Server 2003 Service Pack 1
- Microsoft Exchange Server 2003 Service Pack 2
vendor status:
---------------
vendor notified: 2005-10-27
vendor response: 2005-10-27
patch available: 2006-06-13
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SEC Consult Unternehmensberatung GmbH
Office Vienna
Blindengasse 3
A-1080 Wien
Austria
Tel.: +43 / 1 / 890 30 43 - 0
Fax.: +43 / 1 / 890 30 43 - 15
Mail: office at sec-consult dot com
www.sec-consult.com
EOF Daniel Fabian / @2006
research at sec-consult dot com
Labels: Advisory, Email, http, Microsoft, Vulnerability