Microsoft Access VBA Trojan: The overlooked "Macro Virus"
15 Jun. 2000
Microsoft Access Databases do not have macro execution protection in the sense that Word, Excel and Powerpoint documents have. Attackers can insert Trojan within a VBA macro code into MS Access documents, and this will execute arbitrary commands on the remote machine when the document is opened (without warning).
The information has been provided by: Johnny.
There has been much publicity surrounding the Trojan/Virus capabilities of Microsoft Office applications which enable macro execution options.
The use of these Trojans should subside now that Microsoft has implemented more stringent security options into the Office 2000 suite. Specifically, under Tools|Macro|Security there are three security levels: High, Medium and Low (not recommended). The "High security" setting is the default option for Word, Excel, and Powerpoint. This setting states that "Only signed macros from trusted sources will be allowed to run. Unsigned macros are automatically disabled." Bye, bye Melissa. Thanx, Microsoft.
The Office 2000 suite uses Visual Basic for Applications (VBA) as it's application-portable programming language. When a user records a macro in Word, Excel or Powerpoint, the actions are translated into VBA code. The subsequent VBA code sequence is then termed a macro, and afforded the protections of the security settings listed above.
Access, however, uses VBA as an integral part of forms presentation and processing which is in turn an integral part of a stand-alone Access application. You turn off VBA, Access is neither shiny nor happy.
An attacker can craft an MS Access database with a single form which auto-launches. When the database is opened, the form is presented automagically. Within the properties of the form, the "On Open" property (default sub of Form_Open) can contain VBA code.
This is how it happens:
Double click on an mdb file,
Execute VBA code
The user simply opens the document, and the code is launched.
What can VBA do to me?
Bad VBA code has been talked about in several previous articles. For example, the VBA.Interaction.Shell command which executes a command on the local system is a quick and dirty payload, especially when coupled to the "regedit /s" command which would allow an attacker to create a .reg file, and import it into the registry.
A cleaner way uses the API functions Reg*Ex in advapi32.dll to perform direct registry IO without taking the time to upload a .reg file. These functions can simply be defined along with the hideous necesary constants inside the VBA code.
In addition, an attacker can follow in the footsteps of Melissa et al and use the VBA.Interaction.CreateObject call to create an MS Outlook instance which sends trojan email to every address in the addressbook.
This line will create a key under HKEY_CURRENT_USER called "firstname.lastname@example.org".
In honor of Kwyjibo, we can use the VBA.Interaction.CreateObject method to spread like wildfire thanks to MS Outlook:
---Snip from Melissa---
Set UngaDasOutlook = CreateObject("Outlook.Application")
Set DasMapiName = UngaDasOutlook.GetNameSpace("MAPI")
If UngaDasOutlook = "Outlook" Then
DasMapiName.Logon "profile", "password"
Set BreakUmOffASlice = UngaDasOutlook.CreateItem(0)
BreakUmOffASlice.Subject = "Important Message From " &
Access doesn't implement the System library like MS Word does. Hence, the System.[doregistrystuff] calls won't work here. The system calls can be replaced with just about any API you care to 'Define' in the VBA code. Other VBA libraries such as the Application library shown above may prove as suitable replacements.
Microsoft has certainly taken strides to protect against application trojans within the Office 2000 suite. However, MS Access would have to be gutted and fileted in order to follow the same security measures. In the mean time, be sure not to trust every MS Access database you stumble across in your inbox unless you're certain of its origin.