Date: Tue, 25 Sep 2007 16:00:17 -0400
From: <full-disclosure@...hmail.com>
To: <bugtraq@...urityfocus.com>, <full-disclosure@...ts.grok.org.uk>,
	<vulnwatch@...nwatch.org>, <ntbugtraq@...tserv.ntbugtraq.com>,
	<advisories@...esecurity.com>
Subject: Re: CORE-2007-0817: Remote Command execution,
	HTML and JavaScript injection vulnerabilities in AOL's Instant
	Messaging software

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Holy shit, your timeline has more entries than Anne Frank's diary!

On Tue, 25 Sep 2007 12:20:55 -0400 Core Security Technologies
Advisories <advisories@...esecurity.com> wrote:
>Core Security Technologies – CoreLabs Advisory
>           http://www.coresecurity.com/corelabs
>
>Remote command execution, HTML and JavaScript injection
>vulnerabilities in
>AOL’s Instant Messaging software
>
>*Advisory Information*
>
>Title: Remote Command execution, HTML and JavaScript injection
>vulnerabilities in AOL's Instant Messaging software
>
>Advisory ID: CORE-2007-0817
>
>Advisory URL:
>http://www.coresecurity.com/index.php5?module=ContentMod&action=ite
>m&id=1924
>
>Date published: 2009-09-25
>Date of last update: 2007-09-25
>Vendors contacted: AOL LLC.
>
>Release mode: Forced Release
>
>*Vulnerability Information*
>
>Class: Design Error
>Remotely Exploitable: Yes
>Locally Exploitable: No
>Bugtraq ID: 25659
>CVE Name: CVE-2007-4901
>
>*Vulnerability Description*
>
>AOL Instant Messenger ("AIM", 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/) AIM Lite, as defined in
>its
>website (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.
>
>*Vulnerable packages*
>  AIM 6.1 (6.1.41.2)
>  AIM 6.2 (6.2.32.1)
>  AIM Pro
>  AIM Lite
>
>*Non-vulnerable packages*
>  AIM 6.5 (6.5.3.12) -
>http://beta.aol.com/projects.php?project=aim6
>  AIM Express - http://www.aim.com/aimexpress.adp
>  Classic AIM 5.9 - http://www.aim.com/get_aim/win/other_win.adp
>
>*Vendor Information, Solutions and Workarounds*
>
>AOL LLC Vendor Statement;
>
>Overview
>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.
>
>Affected Products and Applications
>* AIM 6.1
>* AIM 6.2
>* AIM Pro
>* AIM Lite
>
>Solutions
>1. Users of AIM can upgrade to the latest version of the AIM beta
>client
>at beta.aol.com.
>
>Acknowledgments
>AOL would like to thank Core Security Technologies for responsibly
>reporting this issue to AOL and for working with AOL on testing
>and
>mitigating these issues.
>
>*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
>
>*Credits*
>This vulnerability was discovered by Lucas Lavarello from the CORE
>Security Consulting Services (CORE SCS) team.
>
>*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/
>  AIM 6.2: http://beta.aol.com/projects.php?project=aim6
>  AIM 6.1: http://www.aim.com/get_aim/win/latest_win.adp
>  AIM Lite: http://x.aim.com/laim/
>  AIM 5.9: http://www.aim.com/get_aim/win/other_win.adp
>  AIM 6.5: http://beta.aol.com/projects.php?project=aim6
>
>Embedding IE
>  Introduction to ActiveX Controls:
>  http://msdn2.microsoft.com/en-us/library/aa751972.aspx
>
>  Reusing MSHTML:
>  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://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
>
>*Report Timeline*
>
>*2007-08-21*: Initial report to AOL Product Vulnerabilities Team
>(PVT)
>requesting acknowledgement within 2 business days, advisory
>publication
>date tentatively set to September 24th.
>*2007-08-22*: Received an acknowledgement and PGP public key from
>AOL's
>PVT. AOL's PVT indicates that upon reception of vulnerability
>details and
>bug confirmation, expectations should be to allow for two business
>weeks
>for an estimated timeline to resolution. Core's PGP/GPG key
>requested.
>*2007-08-23*: Draft advisory and GPG public key sent to AOL's PVT.
>*2007-08-31*: Acknowledgement from AOL confirming the existence of
>the
>vulnerabilities in AOL's IM clients. AOL indicates that the
>development
>and QA teams are working on fixes with an estimated release
>scheduled for
>mid-October. Additionally, note that one of the IM clients
>requires
>coordination with a third-party.
>*2007-09-04*: Reply from Core, acknowledging the previous email
>from AOL
>PVT. Release date for the advisory set to October 16th in
>accordance to
>AOLs estimation. Core indicates that there is no indication of
>exploitation "in the wild" but that these bugs are considered
>extremely
>critical due to the simple way they can be found and exploited and
>the
>large population of vulnerable systems.
>*2007-09-10*: Email from the AOL PVT indicating that the bugs are
>considered extremely critical by AOL as well and expressing their
>intention to provide weekly status updates. An estimated date for
>fixes
>will be forthcoming as soon as they have one. In the meantime, a
>server-side mitigation mechanism has been deployed and Core is
>invited to
>test it.
>*2007-09-10*: Core acknowledges reception of AOL‟s last email.
>We‟ve taken
>up the offer to test the mitigation mechanism and although it did
>prevent
>the original proof-of-concept code snippets from working we found
>that
>attacks are still possible with minor tweaks to the original code.
>Tests
>were performed using only one of the 4 vulnerable clients, the
>others are deemed equally vulnerable.
>*2007-09-12*: Core email to AOL notifying them that information
>about the
>bug may have been disclosed to public security mailing lists by an
>unknown
>third-party [1]. Precise technical details were not given and
>therefore it
>is difficult to assess if the bug disclosed by the third-party is
>directly
>related to those reported by Core. There are still no indications
>of
>exploitation of these bugs "in the wild". Nonetheless, it is
>reasonable to
>think that the independent discovery and exploitation of the bugs
>reported
>by Core is now imminent, should that happen, Core‟s security
>advisory will
>be published the upcoming week (tentatively Monday Sept. 17th
>2007) as a
>Forced Release.
>*2007-09-14*: Email from AOL PVT indicating that AOL is in
>correspondence
>with the third-party and received additional information about the
>bug,
>leading the AOL team to think that the publicly disclosed
>vulnerability is
>not similar in nature to those reported by Core. The public
>vulnerability
>will be fixed in the AIM clients in mid-October. AOL's PVT does
>not feel
>that this public disclosure warrants disclosure of Core‟s
>advisory. The
>team could not verify that the mitigation mechanism deployed on
>the server
>can still be bypassed as indicated by Core in a previous email.
>The team
>requests the exact version numbers of the AIM clients used, proof
>of
>concept code and/or a description of how to reproduce the test.
>*2007-09-14*: Email sent to AOL indicating that a second post with
>additional information about the bug has been made by the third-
>party [2].
>Core requests further details about this publicly disclosed bug
>and asks
>AOL to provide the analysis that lead the AOL team to conclude
>that it is
>of a different nature of those reported by Core. This email
>includes
>detailed step-by-step instructions on how to bypass the server-
>side
>filtering mechanism accompanied with the exact version number of
>the AIM
>client used (6.1.41.2) and the sample code. Core's own analysis of
>current
>publicly available information indicates that the bug is indeed of
>similar
>nature than those reported in Core‟s advisory and that active
>exploitation
>of the bug is likely to happen in a matter of days (not several
>weeks).
>Thus, in accordance to Core‟s analysis the most responsible course
>of
>action is to clarify the nature of the AIM problems and provide
>the
>vulnerable users with enough information to assess and mitigate
>the risk.
>Baring any further indication from AOL to support the theory of
>these
>being bugs of different nature, Core will be ready to publish its
>security
>advisory the week of Sept. 17th to 21st.
>*2007-09-18*: Email sent to AOL PVT indicating that Core now
>considers the
>information about the reported bugs to be publicly available. The
>fact
>that the third-party reporters did not find (or did not publish) a
>way to
>exploit it remotely in a more reliable manner does not prevent
>others from
>doing so. Core‟s team believes that the publicly available
>information
>about this bug is confusing and does not help vulnerable users
>understand
>the risks they are exposed to. Therefore, unless AOL provides new
>information or analysis to change Core‟s analysis, Core will
>publish the
>security advisory to provide vulnerable users with the details
>needed to
>assess risk and devise their own mitigation mechanisms until
>official
>fixed versions of the clients are made available.
>*2007-09-19*: Email sent to AOL indicating that information about
>the
>reported vulnerabilities is now part of Mitre CVE dictionary, the
>US
>National Vulnerability Database [3], the Securityfocus.com
>vulnerability
>Database [4] and the Secunia.com website [5], therefore Core
>considers
>that any security-aware party (either good or bad intended) can
>now easily
>figure out a remote exploitation method. In fact, several messages
>in
>AOL's technical forums seem to indicate that users of AIM clients
>are
>experiencing AIM "bugs" or "problems" related to the issues
>reported in
>Core‟s advisory [6],[7] and that AOL itself seems to be using
>HTML/JavaScript injection and instantiation of third-party ActiveX
>controls [8]. Therefore, to provide accurate information that
>helps
>security practitioners understand the risks and devise mitigation
>strategies for affected end users and organizations Core has
>decided to
>release this security advisory on Monday Sept. 24th. AOL‟s
>statement
>regarding release of fixed clients and any other mitigation
>mechanism is
>expected by COB Friday Sept. 21st. In the meantime, Core
>researchers will
>try to find suitable workarounds to prevent exploitation.
>*2007-09-20*: Email from AOL PVT indicating that the bug posted
>publicly
>is different than those reported by Core because it “is based upon
>another
>application within the AIM client that allows a limited number of
>characters that can be put into a alert message within a script
>tag,
>"<script>alert("Test")</script>". This message will only work when
>sending a IM to someone who is using one of the AIM 6.x clients
>and does
>not have the sender focused within their AIM client. When sending
>a
>message to an AIM user who does not have the sender focused in
>their AIM
>client, a notification window will pop up informing the recipient
>that
>they have just received a message from another AIM user. It is
>this
>application in the AIM 6.x clients that is not properly parsing
>the
>messages for this type of html tag and pop's up an alert window.”
>The
>other public problems pointed out by Core posted in AOL‟s message
>boards
>are not caused by AIM clients. AIM client 6.5.3.12 (currently in
>Beta)
>fixes the reported problems and is available for public download
>(and for
>testing). AOL remains unsuccessful trying to verify that the
>serverside
>filtering mechanism can be bypassed and requests additional data
>(exact
>version numbers of the IE on the target system and AIM clients
>used). AOL
>requests to delay publication of the security advisory until the
>date
>previously agreed on (October 16th, 2007) the release of fixes is
>still on
>schedule for mid-October.
>*2007-09-20*: Email sent to AOL PVT stating that Core‟s analysis
>indicates
>that the publicly disclosed bug and those reported by Core are of
>the same
>and that in fact the public one is just a trivial variation of one
>of the
>attack scenarios explicitly described by Core. Further details
>provided
>about how to test AOL‟s server-side filtering mechanism (although
>we don‟t
>think the versions of IE and AIM on the source and target system
>are
>relevant to test server-side filtering). Core points out that the
>messages
>on AOL's message boards disclose specific non-malicious HTML code
>that is
>currently being injected into clients, including JavaScript and
>instantiation of ActiveX controls and that should be considered
>directly
>related to the bugs reported because they demonstrate that
>arbitrary HTML
>content can be injected into AIM. Core has confirmed that AIM
>6.5.3.12 is
>not vulnerable to attack (although extensive regression testing of
>all
>possible attack patterns was not performed).
>Given all the publicly known facts Core deems active exploitation
>imminent
>and therefore still plans to release the security advisory on
>Monday Sept.
>24th in order to provide precise details to help users become
>aware of the
>risk they are exposed to and to deploy countermeasures to prevent
>active
>exploitation.
>*2007-09-21*: Email received from AOL PVT requesting a conference
>call to
>discuss the issues reported and how to handle them.
>*2007-09-21*: Conference call between Core Security advisories
>team,
>Core's bug discoverer and AOL PVT. AOL reported that the current
>version
>of AIM 6.5 addresses the bugs reported and that AOL could
>replicate the
>test of the service-side filters and had fixed the bypass.
>Availability of
>fixed release versions of AIM is still scheduled for mid-October.
>Core
>reports that AIM v6.5.3.12 indeed seems to have fixed the problem
>(although full regression was not performed) and that the publicly
>known
>information about HTML injection in AIM clients makes it trivial
>for
>attackers to figure out variations of the published code that can
>succeed
>against vulnerable systems. Core will re-test the server-side
>filtering
>mechanism. The final security advisory will be sent to AOL by COB
>September Friday 21st and the publication date moved to Tuesday,
>September
>25th, 2007 to incorporate AOL's official statements regarding
>fixes and
>mitigation and final rests of the interim server-side filters. The
>publication date is final.
>*2007-09-21*: Email sent to AOL PVT indicating the server-
>filtering has
>improved considerably but can still be bypassed. Other variations
>of the
>same type of attack should be blocked.
>*2007-09-21*: Email sent to AOL PVT indicating use of Internet
>Explorer
>Local Machine Zone Lockdown recommendation may be a suitable
>workaround.
>*2007-09-24*: Email from AOL PVT including AOL's official
>statement
>regarding this report (included in the "Vendor Information,
>Solutions and
>Workarounds" section).
>*2007-09-25*: CoreLabs Security Advisory CORE-2007-0817 published
>
>*References*
>[1] AIM Arbitrary HTML Display in Notification Window
>    shell at dotshell dot net
>    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
>[3] http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-4901
>[4] http://www.securityfocus.com/bid/25659
>[5] 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
>[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
>[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
>
>*About Corelabs*
>CoreLabs, the research center of Core Security Technologies, is
>charged
>with anticipating the future needs and requirements for
>information
>security technologies.
>We conduct our research in several important areas of computer
>security
>including system vulnerabilities, cyber attack planning and
>simulation,
>source code auditing, and cryptography. Our results include
>problem
>formalization, identification of vulnerabilities, novel solutions
>and
>prototypes for new technologies.
>CoreLabs regularly publishes security advisories, technical
>papers,
>project information and shared software tools for public use at:
>http://www.coresecurity.com/corelabs/
>
>*About Core Security Technologies*
>Core Security Technologies develops strategic solutions that help
>security-conscious organizations worldwide develop and maintain a
>proactive process for securing their networks. The company's
>flagship
>product, CORE IMPACT, is the most comprehensive product for
>performing
>enterprise security assurance testing. IMPACT evaluates network,
>endpoint and end-user vulnerabilities and identifies what
>resources are
>exposed. It enables organizations to determine if current security
>investments are detecting and preventing attacks. Core augments
>its
>leading technology solution with world-class security consulting
>services,
>including penetration testing and software security auditing.
>Based in Boston, MA and Buenos Aires, Argentina, Core Security
>Technologies can be reached at 617-399-6980 or on the Web at
>http://www.coresecurity.com.
>
>*DISCLAIMER*
>The contents of this advisory are copyright (c) 2007 CORE Security
>Technologies and (c) 2007 CoreLabs, and may be distributed freely
>provided
>that no fee is charged for this distribution and proper credit is
>given.
>PGP/GPG KEYS This advisory has been signed with the GPG key of
>Core
>Security Technologies advisories team, which is available for
>download at
>http://www.coresecurity.com/files/attachments/core_security_advisor
>ies.asc
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Charset: UTF8
Version: Hush 2.5

wpwEAQECAAYFAkb5aNEACgkQ+dWaEhErNvSNGwQAgXk8qK9s5dE4f5yaC6J9KQp2nmvG
Rzo/cpjFmG8jTTvlpqpNqJ7rbxkCLkH/LtPuGlMmyoXzdnbgqCHBwvepGBbJKK4Fyxo4
/RQyW9QA7CesVn4Bn6dtnVfyfarRuVT/1uaME+61VU20N87YOBU34EvB0xv8ysKha8Tr
n9pFRwQ=
=NeE2
-----END PGP SIGNATURE-----

--
Click for free info on earning your associates degrees.
http://tagline.hushmail.com/fc/Ioyw6h4dDtGq7AhfSJ30O15WhrnEWOddp89PAZBg0Iw1dn6tOtxan2/


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists