TUCoPS :: HP Unsorted A :: b1a-1615.htm

Akamai Download Manager arbitrary file download & execution
Akamai Download Manager arbitrary file download & execution
Akamai Download Manager arbitrary file download & execution

Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Akamai Download Manager arbitrary file download & execution
Yorick Koster, April 2009

Akamai's Download Manager allows attackers to download arbitrary
files onto a user's desktop. Using a so-called "blended
threat" attack it is possible to execute arbitrary code. This
attack affects the ActiveX control as well as the Java applet.

Tested version
This issue was tested on Akamai Download Manager version using
Windows XP SP3 running Internet Explorer 6, 7 & 8 and Windows Vista
running Internet Explorer 8.

Akamai reports that this vulnerability should have been fixed in version of the Akamai Download Manager for both Java and ActiveX.
Specifically, both the Java and ActiveX versions ignore the
configuration option target when set to DESKTOP.

The latest version of Akamai Download Manager can be obtained using the
following URL:

Download Manager provides a simplified method of distributing,
downloading,and installing digitized assets via the Internet. Download
Manager is available as an ActiveX component or Java applet. The ActiveX
control persists on the user's system unless it is deleted
manually. Download Manager is used by many vendors including Microsoft,
McAfee, Symantec, Citrix and Adobe.

Over the years, browser vendors have added measures to their browsers to
prevent users from running unwanted software. Download managers on the
other hand have not adopted these measures as they generally want to
make this task as easy as possible for end users. The process of
downloading and running a file looks and feels different from what users
are used to. This alone may cause users to make the wrong decisions,
causing them to run unwanted/untrusted software.

The HTML code needed to start a download using the ActiveX control looks
something like the following code:

codebase="http://dlm.tools.akamai.com/dlmanager/versions/activex/dlm-activex-,2,4,8" width="1" height="1"> 

start download

The object tag contains the classid of the ActiveX control. The
(optional) codebase attribute contains a link to the installation files
in case Download Manager is not yet installed on the user's system.
The URL parameter contains a link to the file that needs to be

The download is started using the StartDownload method of the ActiveX
control. When the download starts, the ActiveX control creates a
temporary configuration file after which it invokes a separate program
(Manager.exe) that performs the download. Download Manager will first
ask the user where the file has to be saved (figure 1).

Figure 1: Download Manager Save As dialog

If the user chooses to save the file, the download window is displayed.
This window shows a summary overview of all downloads. An example of
this window is displayed in figure 2.

Figure 2: Manager.exe download window

After the download is finished, the user can execute the file using the
Launch button. It is also possible to automatically execute the file.
This can be done by adding an extra parameter named launch to the object
tag with its value set to yes. In this case, the user is presented with
a warning dialog as is shown in figure 3. Notice that this dialog
contains little information about the download. For example it does not
show if the file is signed and by whom.


start download

Figure 3: Download Manager launch warning dialog

It should be noted that if Download Manager is started from Internet
Explorer on Windows Vista, an extra warning dialog is displayed when
Internet Explorer runs in Protected Mode. This warning is displayed as
Download Manager tries to start Manager.exe with the privileges of the
currently logged on user, thus elevating from the low integrity Internet
Explorer process.

Figure 4: Running Download Manager outside Protected Mode

Hiding the Download Manager window
When the download is started, Download Manager shows the download
progress in a separate window. By default this window shows a summary of
all downloads. It is possible to show only the progress of one download
using the initialView parameter. Setting this to the value single will
cause Download Manager to only display (detailed) information about one


start download

Setting the initialView parameter to embedded will cause Download
Manager to display no window at all.


start download

Hiding the Save As dialog
Through the target parameter, it is possible to determine where the
files are saved. If this parameter is not set or is empty, users are
asked to select a location. If the value is set to AUTO, the files are
saved within the user's temporary folder (i.e. C:\Documents and
Settings\Administrator\Local Settings\Temp\). If the target parameter is
set to DESKTOP, files are saved on the user's desktop. For


start download

The Save dialog is not shown if the target parameter is set to either
AUTO or DESKTOP. Consequently, the only way to prevent code execution is
by clicking Cancel in the warning dialog shown in figure 3. Of course,
in order to do so an attacker has to convince or lure the target user
into viewing a malicious website.

Executing arbitrary downloads
The only (currently known) way to not show the launch warning dialog is
to not execute the download through Download Manager. Another method has
to be found to get the download executed. One way of doing this is by 
abusing the Dynamic-Link Library Search Order [2]. If a program is
started that has its current work directory set to the user's
desktop folder, it will search this folder for DLLs that need to be
loaded. Using Download Manager, it is possible to create arbitrary DLL
files on the desktop that are loaded when this program is started. An
example of such a program is Internet Explorer. This trick is also used
to exploit the Safari Carpet Bomb [3] vulnerability (see also

With the release of MS09-014 [4] and MS09-015 [5] Microsoft has
implemented mitigating measures that should prevent this kind of attack
(see also Microsoft Security Advisory 953818 [6]). Even though Microsoft
has implemented these security measures, there are still ways to
execute a file located on the user's desktop. A couple of examples
are given in this document. This is a non-exhaustive list, other methods


In Internet Explorer 6, when a user wants to view the (HTML) source of a
web page, by default Internet Explorer starts Notepad. This is done
without providing an absolute path name. Because of this, Windows will
first look in the current working directory to see if a file named
notepad.exe exists. If this is the case, Windows will execute this file.
Using Download Manager it is possible to create such a file on the
user's desktop. Prior to Windows XP SP2, it is possible to
automatically start Notepad using a view-source: link, i.e.

The view-source protocol was disabled in Service Pack 2 for Windows XP
(and later). See also


In a similar manner, if Internet Explorer (prior to IE7) loads a telnet
URL it will start the Telnet client using a relative path name. If an
executable named telnet.exe exists on the desktop, this executable will
be started instead of the real Telnet client. In Internet Explorer 7,
Microsoft disabled the use of telnet URLs (see also



In Internet Explorer 7 when a user deletes her browsing history,
rundll32.exe is started using a relative path name. By placing an
executable named rundll32.exe and convincing the user to delete her
browsing history, it is possible to have this executable launched.

Figure 5: Delete Browsing History


Windows allows applications to register itself to handle a particular
URL protocol. For example if Adobe Reader is installed, it will add a
protocol handler for the acrobat protocol. If Internet Explorer
encounters such an URL, it will search the Registry and it will execute
the registered application. Some applications will search the desktop
for DLLs or executables. One such an application is wab.exe (Windows
Contacts), which is launched for ldap URLs, for example ldap://billyg.
When wab.exe is started, it tries to load the DLL wab32res.dll. If such 
a file exists on the user's desktop, it will use this DLL.
Consequently, this allows attackers to execute arbitrary code with the
privileges of the target user. A proof of concept is given below:


It should be noted that in Internet Explorer 8, Microsoft has
implemented an extra warning dialog for custom protocol handlers. It
warns users that they are about to launch an external program. Thus, for
an attack to be successful, target user will have to allow the Windows
Contacts program to be executed. An example of such a warning dialog is
shown in figure 6.

Figure 6: Browser warning when opening ldap URLs

In addition, on Windows Vista, Windows Contacts will be started outside
Protected Mode. Because of this, a second warning dialog will be shown.

Figure 7: Running Windows Contacts outside Protected Mode

Java applet
As stated in the introduction, Download Manager is available as an
ActiveX component or Java applet. Although this document focuses on the
ActiveX control, the Java applet is similarly affected by this issue.
Since, the applet requires access to the local file system, the applet
is signed by Akamai. When the applet is loaded, a warning dialog is
displayed to the end user. Through this dialog, the user can give the
applet access to his file system. An example of this dialog is displayed
in figure 8.

Notice that the checkbox option "Always trust content from this
publisher" is enabled by default. If this box is ticked and the
user chooses to run the applet, the warning dialog will not be shown any
longer for any applet that is signed by this publisher, in this case
Akamai. This is problematic if any applet of Akamai contains a
vulnerability, because an attacker can host a vulnerable version of this
applet on a server under the attacker's control. The (vulnerable)
applet will automatically load if the user "trusts" the
publisher. There is no killbit equivalent for Java applets.

Figure 8: Java security warning for digitally signed applets

A modified version of the proof of concept using the Java applet is
listed below:

archive="dlm-java-" name="Download Manager" id="dm" width="1"
height="1" mayscript>

Final note
Apart from the weak dialog boxes in Download Manager it can be said that
the code execution vulnerability is not only caused by Download
Manager. It is possible because it uses what Microsoft calls a
"blended threat" attack (953818 [7]). Allowing an attacker to
store arbitrary files on a known or predictable location is always a bad
idea. Combined with other issues, in many cases, this can lead to
arbitrary code execution. Even a local HTML file can be used for
malicious actions.

Although ActiveX is potentially dangerous as it is generally implemented
in native code and runs with the same privileges as the browser,
Microsoft has made great progress in improving its security. Examples of
these improvements are, ActiveX Opt-In, Per-User ActiveX, Per-Site
ActiveX, Protected Mode and UAC. The security of Java applets is lagging
behind. The default option of trusting all code from one publisher is
flawed. Publishers that distribute a lot of Java applets, are more
likely to distribute vulnerable applets. Since signed applets are
equivalent to ActiveX controls, this can lead to a full compromise of
user's systems.

[1] http://www.akitasecurity.nl/advisory.php?id=AK20090402 
[2] http://msdn.microsoft.com/en-us/library/ms682586.aspx 
[4] http://www.microsoft.com/technet/security/Bulletin/MS09-014.mspx 
[5] http://www.microsoft.com/technet/security/Bulletin/MS09-015.mspx 
[6] http://www.microsoft.com/technet/security/advisory/953818.mspx 
[7] http://www.microsoft.com/technet/security/advisory/953818.mspx 

Akita Software Security (Kvk 37144957)
Key fingerprint = 5FC0 F50C 8B3A 4A61 7A1F  2BFF 5482 D26E D890 5A65

Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

Version: GnuPG v1.4.9 (GNU/Linux)



TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH