ActiveX Controls
ActiveX controls are a much more heavyweight technology than Java applets. They are effectively native Win32 executables that, once accepted and installed by the user, execute with the full privileges of that user and can carry out arbitrary actions, including interacting with the operating system.
ActiveX can be used to implement practically any client-side control, including capturing user input and other in-browser data, and verifying that the client computer meets certain security standards before allowing access to some function.
From the point of view of HTML page source, ActiveX controls are instantiated and invoked in a very similar way to Java applets. For example, if you have installed the Adobe Acrobat plug-in for Internet Explorer, the following code will display a dialog showing the version of Acrobat installed:
<object id=”TheAxControl”
classid=”CLSID:4F878398-E58A-11D3-BEE9-00C04FA0D6BA”>
</object>
<form>
<input type=”button” value=”Show version”
onclick=JavaScript:alert(document.TheAxControl.AcrobatVersion)>
</form>
In addition to looking for code like this, you can easily identify instances where an application attempts to install a new ActiveX control, because your browser will present an alert asking for your permission to install it.
There are various techniques that can be used to circumvent client-side controls implemented using ActiveX.
Reverse Engineering
Because ActiveX controls are typically written in native languages like C and C++, they cannot be trivially decompiled back to source code in the way that Java applets can be. Nevertheless, because all of the processing performed by an ActiveX control occurs on the client computer, it is in principle possible for a user on that computer to fully scrutinize and control that processing, thereby circumventing any security functions that it implements.
Reverse engineering is a complex and advanced topic, which extends beyond the scope of this article. However, there are some basic techniques that even a relatively inexperienced reverse engineer can use to defeat the client-side security mechanisms implemented within many ActiveX controls.
The following are some useful resources if you’d like to find out more about reverse engineering and related topics:
■ Reversing: Secrets of Reverse Engineering by Eldad Eilam
■ Hacker Disassembling Uncovered by Kris Kaspersky
■ The Art of Software Security Assessment by Mark Dowd, John McDonald, and Justin Schuh
■ www.acm.uiuc.edu/sigmil/RevEng
■ www.uninformed.org/?v=1&a=7
Manipulating Exported Functions
As with Java applets, it may be possible to manipulate and repurpose an ActiveX control’s processing solely by invoking methods that it exposes to the browser through its normal interface.
ActiveX controls may expose numerous methods that the application never actually invokes from HTML, which you may not be aware of without examining the control itself. COMRaider by iDefense is a useful tool that can display all of a control’s methods and their signatures, as shown in Figure -1.
Figure -1: COMRaider showing the methods exposed by an ActiveX control
Fixing Inputs Processed by Controls
A common use to which ActiveX controls are put is as a client-side control to verify that the client computer complies with specific security standards before access is granted to certain server-side functionality. For example, in an attempt to mitigate against keylogging attacks, an online banking application may install a control that checks for the presence of a virus scanner, and the operating system patch level, before permitting a user to log in to the application.
If you need to circumvent this type of client-side control, it is usually easy to do. The ActiveX control will typically read various details from the local computer’s file system and registry as input data for its checks. You can monitor the information being read and feed arbitrary inputs into the control that comply with its security checks.
The Filemon and Regmon tools originally developed by Sysinternals (and now owned by Microsoft) enable you to monitor all of a process’s interaction with the computer’s file system and registry. You can filter the tools’ output to display only the activity of the process you are interested in. When an ActiveX control is performing security checks on the client computer, you will typically see it querying security-relevant files and registry keys, such as items created by antivirus products, as shown in Figure -2.
Figure -2: Regmon being used to capture the registry access carried
out by an ActiveX control
In this situation, it is usually sufficient to manually create the relevant file or registry key, to convince the control that the corresponding software is installed. If for some reason you do not wish to interfere with the actual operating system, you can achieve the same effect using the debugging or instrumentation techniques described previously, to fix the data returned to the control by the relevant file system or registry APIs.
Decompiling Managed Code
Occasionally, you may encounter thick-client components written in C#. As with Java applets, these can normally be decompiled to recover the original source code.
A useful tool for performing this task is .NET Reflector by Lutz Roeder (see Figure -3).
Figure -3: The .NET Reflector tool being used to decompile an
ActiveX control written in C#
Similar code obfuscation issues can arise in relation to C# assemblies as arise with Java bytecode.
Shockwave Flash Objects
Flash is very popular on the Internet. It is often used as a means of providing increased interactivity in informational web sites, but it is also employed in web applications. Some online stores have Flash-based user interfaces, and it is often used in jukebox software such as Pandora radio. The most common use of Flash in an application context is in online games. These vary in nature from purely recreational games to serious casino functionality, where real money is involved. Many such games have been targeted by correspondingly recreational and serious attackers.
Given what we have observed about the fallible nature of client-side controls, the idea of implementing an online gambling application using a thick-client component that runs locally on a potential attacker’s machine is an intriguing one. If any aspect of the game play is controlled within the Flash component instead of by the server, an attacker could manipulate the game with fine precision to improve odds, change the rules, or alter the scores submitted back to the server.
Like the other thick-client components examined, Flash objects are contained within a compiled file that the browser downloads from the server and executes in a virtual machine, which in this case is a Flash player implemented in a browser plug-in. The SWF file contains bytecode that is interpreted by the Flash VM (virtual machine), and as with Java bytecode, this can be decompiled to recover the original ActionScript source code, using appropriate tools. An alternative means of attack, which is often more effective, is to disassemble and modify the bytecode itself, without actually fully decompiling it to source. Flasm is a disassembler and assembler for SWF bytecode and can be used to extract a human-readable representation of the bytecode from an SWF file and then reassemble modified bytecode into a new SWF file:
C:\flash>flasm
Flasm 1.61 build May 31 2006
(c) 2001 Opaque Industries, (c) 2002-2005 Igor Kogan, (c) 2005 Wang Zhen
All rights reserved. See LICENSE.TXT for terms of use.
Usage: flasm [command] filename
Commands:
-d Disassemble SWF file to the console
-a Assemble Flasm project (FLM)
-u Update SWF file, replace Flasm macros
-b Assemble actions to __bytecode__ instruction or byte sequence
-z Compress SWF with zLib
-x Decompress SWF
Backups with $wf extension are created for altered SWF files.
To save disassembly or __bytecode__ to file, redirect it:
flasm -d foo.swf > foo.flm
flasm -b foo.txt > foo.as
Read flasm.html for more information.
The following example shows Flasm being used to extract a human readable representation of bytecode from an SWF file for a simple Flash-based car racing game:
C:\flash>flasm racer.swf > racer.flm
C:\flash>more racer.flm
movie ‘racer.swf’ compressed // flash 7, total frames: 3, frame rate: 24
fps, 64
0x500 px
exportAssets
1 as ‘engineStart’
end // of exportAssets
exportAssets
2 as ‘engineLoop’
end // of exportAssets
frame 0
stop
push ‘car1’
getVariable
push ‘code’, ‘player’
setMember
push ‘totalLaps’, 10
setVariable
push ‘acceleration’, 1.9
setVariable
push ‘gravity’, 0.4
setVariable
push ‘speedDecay’, 0.96
setVariable
push ‘rotationStep’, 10
setVariable
push ‘maxSpeed’, 10
setVariable
push ‘backSpeed’, 1
setVariable
push ‘currentCheckpoint1’, 1
setVariable
push ‘currentLap1’, 0.0
setVariable
push ‘checkpoints’, 2
setVariable
push ‘currentLapTXT’, ‘1/10’
setVariable
end // of frame 0
frame 0
constants ‘car’, ‘code’, ‘player’, ‘speed’, ‘speedDecay’, ‘Key’,
‘isDown’, ‘
…
Here, you can immediately see various bytecode instructions that are of interest to someone wishing to attack and modify the game. For example, you could change the value of the maxSpeed variable from 10 to something a bit more competitive. After doing this, the modified disassembly can then be converted back into bytecode in a new SWF file, as follows:
C:\flash>flasm –a racer.flm
racer.flm successfully assembled to racer.swf, 31212 bytes
The car should now virtually fly around the track (to make it literally fly, you could try changing the gravity variable!).
In the previous example, the functionality implemented within the Flash object was sufficiently simple that an attacker could fundamentally reengineer the object by inspecting the disassembled bytecode and changing a single variable. In more complex Flash objects, this may not be possible, and it may be necessary to recover the original source and review it in detail to discover how the object works and where best to attack it. The Flare tool can be used to decompile an SWF file back into the original ActionScript source:
C:\flash>flare racer.swf && more racer.flr
movie ‘racer.swf’ {
// flash 7, total frames: 3, frame rate: 24 fps, 640×500 px, compressed
frame 1 {
stop();
car1.code = ‘player’;
totalLaps = 10;
acceleration = 1.9;
gravity = 0.4
speedDecay = 0.96;
rotationStep = 10;
maxSpeed = 10;
backSpeed = 1;
currentCheckpoint1 = 1;
currentLap1 = 0;
checkpoints = 2;
currentLapTXT = ‘1/10’;
}
…
While modifying recreational games is usually straightforward and may be fun for personal amusement and beating a coworker, the client-side controls implemented within the Flash objects used by enterprise applications and online casinos are typically better protected. As with Java, obfuscation techniques have been devised in an attempt to hinder decompilation attacks. Two available tools are ActionScript Obfuscator and Viewer Screwer, which can change both meaningful variable names and text references into scrambled sequences of letters, making the decompiled code harder to understand.
The tools described can be obtained from:
■ Flasm — www.nowrap.de/flasm
■ Flare — www.nowrap.de/flare
■ ActionScript Obfuscator — www.genable.com/aso.html
■ Viewer Screwer — www.debreuil.com/vs
..NEXT is…Handling Client-Side Data Securely,,.,.,,.,.,.,
