- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
AOL's Instant Messaging Command Execution, HTML and JavaScript Injection
Vulnerabilities
------------------------------------------------------------------------
SUMMARY
AOL Instant Messenger ("AIM", <http://www.aim.com> http://www.aim.com) is
an instant messaging application that allows its users to communicate in
real time via text, voice, and video over the Internet. It is maintained
by AOL LLC. AIM Pro is AOL's business-oriented version of AIM targeted for
professional use with an emphasis on "business-grade" security and
integration with email client and other productivity applications (
<http://aimpro.premiumservices.aol.com/>
http://aimpro.premiumservices.aol.com/) AIM Lite, as defined in its
website ( <http://x.aim.com/laim/> http://x.aim.com/laim/), is a reference
application used to test new technology also developed by AOL and
available for the public in the form of a "light IM client".
A vulnerability was discovered in these three popular versions of AOL
Instant Messaging software, AIM 6.1 (and 6.2 beta), AIM Pro and AIM Lite,
which expose workstations running the IM clients and their users to
several immediate high-risk attack vectors. To support rendering of HTML
content, the vulnerable IM clients use an embedded Internet Explorer
server control. Unfortunately they do not properly sanitize the
potentially malicious input content to be rendered and, as a result, an
attacker might provide malicious HTML content as part of an IM message to
directly exploit Internet Explorer bugs or to target IE s security
configuration weaknesses.
In particular this attack vector exposes workstations to:
- Direct remote execution of arbitrary commands without user interaction.
- Direct exploitation of IE bugs without user interaction. For example,
exploitation bugs that normally require the user to click on a URL
provided by the attacker can be exploited directly using this attack
vector.
- Direct injection of scripting code in Internet Explorer. For example,
remotely injecting JavaScript code into the embedded IE control of the AIM
client.
- Remote instantiation of Active X controls in the corresponding security
zone.
- Cross-site request forgery and token/cookie manipulation using embedded
HTML.
DETAILS
Vulnerable Systems:
* AIM version 6.1 (6.1.41.2)
* AIM version 6.2 (6.2.32.1)
* AIM version Pro
* AIM version Lite
Immune Systems:
* AIM version 6.5 (6.5.3.12) -
<http://beta.aol.com/projects.php?project=aim6>
http://beta.aol.com/projects.php?project=aim6
* AIM version Express - <http://www.aim.com/aimexpress.adp>
http://www.aim.com/aimexpress.adp
* Classic AIM version 5.9 -
<http://www.aim.com/get_aim/win/other_win.adp>
http://www.aim.com/get_aim/win/other_win.adp
Vendor Information, Solutions and Workarounds:
AOL has become aware of security vulnerabilities in several AIM instant
messaging clients. Successful exploitation of these vulnerabilities could
allow an attacker to execute arbitrary commands on a user's workstation.
AOL has deployed host side filtering on the AIM servers to block this
potentially malicious content from being sent to AIM clients.
Solutions:
1. Users of AIM can upgrade to the latest version of the AIM beta client
at beta.aol.com.
Other workarounds (un-official)
Workaround #1: Users running AIM on Microsoft Windows XP SP2 or Windows
Server 2003 SP1 may implement Microsoft's "Internet Explorer Local Machine
Zone Lockdown" recommendations to mitigate risk. This will not fix the
reported bugs but will reduce the risk of exploitation significantly. To
enable Local Machine Zone Lockdown for your AIM client, go to the
following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft \Internet
Explorer\Main\FeatureControl\FEATURE_LocalMachine_Lockdown
Add a REG_DWORD value to this key named as the AIM client application (for
example, aim.exe) and set it to 1. Any other setting for this value will
disable Local Machine Zone Lockdown for the application.
For further details about how to configure this feature read Microsoft's
Internet Explorer Local Machine Zone Lockdown recommendation at:
<http://technet.microsoft.com/enus/library/bb457150.aspx#EHAA>
http://technet.microsoft.com/enus/library/bb457150.aspx#EHAA
Technical Description / Proof of Concept Code:
The standard protocol that AIM clients use to communicate is called OSCAR
(Open System for CommunicAtion in Realtime), which is a closed protocol
also used by AOL's secondary Instant Messaging client, ICQ (I Seek You).
On top of the OSCAR protocol, AIM clients have implemented support for
enhanced message types that use features provided by the HTML (Hyper Text
Markup Language) in order to, for example, provide AIM users with the
possibility of exchanging text messages with specific font formats or
colors. AIM 6.1, AIM 6.2 (beta), AIM Pro and AIM Lite have embedded an
Internet Explorer server control in the message display window in order to
facilitate the parsing and displaying of HTML controls. It is a common
practice for Windows applications to reuse Microsoft Internet Explorer's
HTML parsing objects included in the mshtml.dll library instead of using a
homebrew HTML parser.
Several programming frameworks, including MFC (Microsoft Foundation
Classes), provide practical ways of embedding such controls through
classes like CHtmlEditView or CHtmlEditDoc. Some of the advantages of
using MSHTML are that it provides a particular, feature-rich and somewhat
complete support for DHTML and also that it is easier to host Microsoft
ActiveX Controls. However, in the context of this advisory, such
advantages may end up becoming security problems due to design flaws and
implementation bugs. There are two particular characteristics in the
implementation of the described functionality that turn AIM's highly
flexible message-content features into high-risk attack vectors for its
users.
First, the vulnerable IM clients do most of the sanitizing/filtering and
encoding of HTML content on outbound messages, thus a malicious attacker
with the ability to bypass outbound HTML filtering can send any type of
HTML content to other IM clients.
A handful of publicly available and well-known IM clients permit to send
un-sanitized data to any other client that supports the same
communications protocol including the vulnerable AIM 6.1, AIM 6.2, AIM Pro
and AIM Lite clients.
Second, although there are some defensive mechanisms implemented in the
vulnerable clients these are insufficient to properly handle messages with
potentially malicious content. Input validation of inbound messages
appears to be taking place but can be easily circumvented by an attacker.
As a result, the entire attack surface of MSHTML is exposed to remote IM
peers. By having a way of sending data straight to the MSHTML library,
attackers could abuse such high-risk attack vector to:
- Execute arbitrary shell commands in the victim's workstation.
- Direct the embedded IE to perform arbitrary HTTP requests (CSRF)
- Include HTML controls (links, images, forms ) in IM text messages in
order to trick users into revealing sensitive information or performing
harmful actions against their accounts/workstation/etc.
- Run JavaScript code within IE to enhance the attacks mentioned above.
- Instantiate ActiveX controls, which attackers could use to target
vulnerabilities in the ActiveX objects themselves or use their
functionality to, for example, read arbitrary files from the victim's file
system or even execute arbitrary shell commands in the victim's
workstation.
- Directly attack vulnerable versions of Internet Explorer in user
workstations. This is a typical client-side attack scenario and could lead
to the remote execution of arbitrary code in the victim's workstation. In
this scenario "one-click" IE bugs (exploitation requires user assistance)
become "zero-click" bugs (exploitation does not require user interaction).
AOL's "Classic AIM 5.9" is an official alternative client for nostalgic
users and is not vulnerable due to the fact that instead of using MSHTML
to render HTML it appears to include limited rendering functionality
either provided by a third party library or homebrew code. Although there
is no guarantee that its implementation lacks vulnerabilities, in our
tests it did prevent the attack vectors described in this advisory. So is
the case for AOL's AOL 6.5.3.12 which although it is embedding an Internet
Explorer server control in the message window, could not be exploited
during our tests.
AOL's online AIM Express web client which is written in ASP.NET and also
appears to be taking the necessary defensive measures required to prevent
any of these problems from taking place.
Proof of concept snippets:
The following examples provide code snippets that should serve as
proof-of-concept code to demonstrate some of the problems that arise from
the issue reported. The snippets have been arranged according to their
risk level, in increasing order (lower risk first), with the intention of
making this process more self-explanatory. In order for these snippets to
work, they must be sent within the contents of a standard instant message,
but using a client that will not encode message contents on output:
Using HTML controls in order to trick victims into revealing sensitive
information or do harmful actions against their accounts/workstations or
to force outbound HTTP requests (CSRF).
The following proof-of-concept code was successfully tested on AIM Pro.
Other vulnerable clients need some tweaking in order to get it to work.
The code uses <hr>, <h2>, <form> and <input> tags to trick the victim into
believing that an AIM disconnection took place. It then requests the
victim to type in the user credentials and to press the Reconnect (submit)
button in order to send the credentials to the attacker. In this case, the
form is submitted to "http://localhost"
--- begin code ---
<hr><h2>SERVICE UNAVAILABLE</h2><hr>Your connection to AIM has been
interrupted. Please type in your credentials in order to reconnect. Thank
you.<br><form method=GET action=http://localhost>Login: <input type=text
name=login><br>Password: <input type=text name=password><br><input
type=submit value=Reconnect></form><br><hr>
--- end code ---
This is simply one example of exploitation using only embedded HTML. There
are plenty of HTML controls that could be used in similar exploitation
scenarios.
Using scripting languages to enhance an attack
As mentioned in the beginning of the technical details section, we
identified among all the vulnerable clients what appeared to be an
existing defensive measure (or a functional characteristic with a
side-effect) meant to prevent attackers from inserting malicious
JavaScript statements within message contents. When sending JavaScript
statements inside <script> tags within a message, the script tags appear
to be filtered by the receiving client upon display (therefore not
executing the JavaScript statements). However, this was easily
circumvented by embedding JavaScript statements inside <img> tags, as in
the following example:
The following code does not work:
<script>alert( I have executed javascript in your computer )</script>
The following code *does* work:
<img src="javascript:alert( I have executed javascript in your computer
)">
Note that even though the different proof-of-concept snippets provided in
this advisory use <img> tags to execute JavaScript, the problem must not
be thought of as circumscribed to message contents with embedded <img>
tags only. JavaScript statements may also be executed through the use of
other HTML controls and some of the attack vectors that we mention do not
even rely on JavaScript for successful exploitation.
The following proof-of-concept code will display a prompt box to the
victim, requesting to type in the victim's AIM credentials. It will look
authentic due to the fact that the message box is not part of the text
message window:
-- begin code --
<img src='javascript:var passwd=window.prompt("You have been
disconnected from the network.\nPlease re-enter your password to
reconnect.", "");alert( You have disclosed your password: +passwd);'>
-- end code --
Once the victim types-in her/his password, an alert message box will be
displayed showing the entered password. Attackers could easily retrieve
passwords and other security-sensitive data by using the same techniques
used to exploit Cross Site Scripting vulnerabilities to steal browser
cookies.
Instantiating ActiveX controls and taking over the victim's workstation
Another way of enhancing an attack could rely on using ActiveX controls
installed on the target system. For that, the attacker needs the ability
to instantiate arbitrary ActiveX controls using an IM message content
constructed to accomplish such purpose. We successfully used this attack
vector in AIM 6.1, AIM 6.2beta and AIM Lite in order to get immediate and
instant access to the victim's workstation. This attack vector increases
considerably the severity of the problems found, turning the affected
clients into a doorway to the user's computer and ultimately providing
attackers with ways of executing arbitrary commands.
Apparently, AIM Pro is the only client that runs the Internet Explorer
server control in a "protected" security zone, where the victim is
prompted with the typical message box that says:
"An ActiveX control on this page might be unsafe to interact with other
parts of the page. Do you want to allow this interaction?"
The choice of the user will affect the entire instance of the application
and be applied to any other existing/future message windows (as well as
potentially any other locations where the Internet Explorer server control
is used.)
Attackers could use JavaScript to instantiate ActiveX controls in order to
either exploit client-side vulnerabilities of the ActiveX objects
themselves or to use ActiveX functionality as an aid to exploit other
bugs. As the following proof-of-concept snippet shows, an attacker can
successfully instantiate the "Shell.Application" object that is included
in the Microsoft Windows OS installation and use it to execute any
arbitrary command on the victim's workstation.
As previously mentioned, in three of the four affected versions of the
product, the attack is straight forward and no interaction with the victim
is required. Such clients appear to be running Internet Explorer control
in the Local Machine Security Zone.
-- begin code --
<img src="javascript:var oShell = new
ActiveXObject('Shell.Application');oShell.ShellExecute('cmd.exe', '/c
pause');">
-- end code --
The proof-of-concept code from above will run an instance of Microsoft
Windows command line tool, executing the pause command. Upon receipt, it
will instantly show a blank command window in the victim's workstation. An
attacker may easily abuse this issue to gain complete control over the
victim's machine with the privileges of the user running AIM.
Attacking vulnerable versions of Internet Explorer controls
This scenario is just a clear-cut client-side attack vector and would rely
on any unpatched security vulnerability in Internet Explorer or the
ActiveX controls it hosts. An embedded HTML URI can direct the IE server
control to automatically visit a previously setup site that delivers
malicious content to exploit known Internet Explorer vulnerabilities. In
this case, the AIM clients identified as vulnerable in this advisory play
the role of exposing their users to attacks without requiring user
intervention to allow/disallow access to the rogue website. This attack
scenario is functionally equivalent to a user of Internet Explorer
clicking on a URL and visiting a malicious site.
Additional Information and resources
AOL's AIM clients
* AIM Pro: <http://aimpro.premiumservices.aol.com/>
http://aimpro.premiumservices.aol.com/
* AIM 6.2: <http://beta.aol.com/projects.php?project=aim6>
http://beta.aol.com/projects.php?project=aim6
* AIM 6.1: <http://www.aim.com/get_aim/win/latest_win.adp>
http://www.aim.com/get_aim/win/latest_win.adp
* AIM Lite: <http://x.aim.com/laim/> http://x.aim.com/laim/
* AIM 5.9: <http://www.aim.com/get_aim/win/other_win.adp>
http://www.aim.com/get_aim/win/other_win.adp
* AIM 6.5: <http://beta.aol.com/projects.php?project=aim6>
http://beta.aol.com/projects.php?project=aim6
Embedding IE
* Introduction to ActiveX Controls:
<http://msdn2.microsoft.com/en-us/library/aa751972.aspx>
http://msdn2.microsoft.com/en-us/library/aa751972.aspx
Reusing MSHTML:
* <http://msdn2.microsoft.com/en-us/library/bb508516.aspx>
http://msdn2.microsoft.com/en-us/library/bb508516.aspx
Internet Explorer Local Machine Zone Lockdown
* <http://technet.microsoft.com/en-us/library/bb457150.aspx#EHAA>
http://technet.microsoft.com/en-us/library/bb457150.aspx#EHAA
*
<http://technet2.microsoft.com/windowsserver/en/library/aebcfc94-25d5-4f41-93cc-7fb6e031de401033.mspx?mfr=true> http://technet2.microsoft.com/windowsserver/en/library/aebcfc94-25d5-4f41-93cc-7fb6e031de401033.mspx?mfr=true
About URL Security Zones
* <http://msdn2.microsoft.com/en-us/library/ms537183.aspx>
http://msdn2.microsoft.com/en-us/library/ms537183.aspx
References
[1] AIM Arbitrary HTML Display in Notification Window shell at dotshell
dot net <http://www.securityfocus.com/archive/1/479199>
http://www.securityfocus.com/archive/1/479199
[2] AIM Local File Display in Notification Window shell at dotshell dot
net <http://www.securityfocus.com/archive/1/479435>
http://www.securityfocus.com/archive/1/479435
[3] <http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-4901>
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-4901
[4] <http://www.securityfocus.com/bid/25659>
http://www.securityfocus.com/bid/25659
[5] <http://secunia.com/advisories/26786/>
http://secunia.com/advisories/26786/
[6] "AIM 6.1 problems" thread on AOL's AIM Support & more technical forum
<http://messageboards.aol.com/aol/en_us/articles.php?boardId=565563&articleId=16537> http://messageboards.aol.com/aol/en_us/articles.php?boardId=565563&articleId=16537
[7] "IM problems" thread in AOL's AIM 6 Technical Issues forum
<http://messageboards.aol.com/aol/en_us/articles.php?boardId=565563&articleId=16537> http://messageboards.aol.com/aol/en_us/articles.php?boardId=565563&articleId=16537
[8] "Copyright and Confidentiality notice?" thread on AOL's AIM 6
Technical Issues forum
<http://messageboards.aol.com/aol/en_us/articles.php?boardId=567774&articleId=2400> http://messageboards.aol.com/aol/en_us/articles.php?boardId=567774&articleId=2400
ADDITIONAL INFORMATION
The information has been provided by <mailto:advisories@coresecurity.com>
Core Security Technologies Advisories.
The original article can be found at:
<http://www.coresecurity.com/index.php5?module=ContentMod&action=item&id=1924> http://www.coresecurity.com/index.php5?module=ContentMod&action=item&id=1924
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
No comments:
Post a Comment