An executable file is a file which contains machine code intended to be run on the CPU.

This looks right, doesn’t it? Well, not entirely. What about batch files for example? They don’t contain machine code per-se, however machine code is run when they are interpreted. The same thing can be said about Word documents, Excel spreadsheets, HTML files, etc. So lets extend the definition:

An executable file is a file which contains machine code intended to be run on the CPU or (during processing) results in instructions being executed on the CPU.

Congratulation! You just defined every file on the system. The processing of any file results in some instructions being executed. Even if we abstract away from software vulnerabilities, you are in a situation where you need to ask yourself the question: is it possible that the application will generate for some input file an instruction sequence which is undesirable?

To take this discussion to a more down-to-earth level, here is an example (taken from this Sophos blog post): imagine a shortcut (.lnk) pointing at the default command interpreter (cmd.exe) resulting in downloading an executable from an FTP site and running it. Fortunately whitelisting products have a chance to step in at the second stage and block it (also, some solutions, like Software Restriction Policies, treat shortcut files as executables).

However I can offer you even a more frightening file format: .msi (Microsoft Installer). This fileformat is intended by design to instruct the operating system to perform deep changes (copy/move files, change registry entries, run programs, etc). Even more problematic is the fact that Windows (Vista) assumes that setup programs need administrative privileges. The execution itself is performed by a service running with high privileges. Also, the MSI format allows for bundling and dynamically loading arbitrary DLLs (which may or may not be traced by the particular whitelisting product – many of them choose not to track it to avoid overwhelming the user with prompts).

Creating an MSI file is rather simple. For the following example I choose the WiX toolkit (both because it is easily installable and because it is open source – if you want to run it, you need the .NET framwork version 2.0). Save the following text as a file named “product.wxs”:

<?xml version='1.0'?>
<Wix xmlns='http://schemas.microsoft.com/wix/2003/01/wi'>
   <Product Id='12345678-1234-1234-1234-123456789012' Name='Test Package' Language='1033' 
            Version='1.0.0.0' Manufacturer='Microsoft Corporation'>
      <Package Id='12345678-1234-1234-1234-123456789012'
               Description='My first Windows Installer package'
               Comments='This is my first attempt at creating a Windows Installer database'
               Manufacturer='Microsoft Corporation' InstallerVersion='200' Compressed='yes' />

      <Directory Id='TARGETDIR' Name='SourceDir'>
         <Component Id='MyComponent' Guid='12345678-1234-1234-1234-123456789012' />
      </Directory>


      <Feature Id='MyFeature' Title='My 1st Feature' Level='1'>
         <ComponentRef Id='MyComponent' />
      </Feature>

      <Binary Id="wixca" src="wixca.dll"/>
      <Property Id="QtExecCmdLine" Value='"c:windowssystem32cmd.exe" /c echo 1 > c:out.txt' />
      <CustomAction Id="QtExec" BinaryKey="wixca" DllEntry="CAQuietExec" Execute="immediate" Return="check"/>

      <InstallExecuteSequence>
        <Custom Action="QtExec" Sequence='1'/>
      </InstallExecuteSequence>
   </Product>
</Wix>

Now run the following two commands:

candle product.wxs
light product.wxsobj

And voila!, you have an .MSI file which – when executed – performs a command in the background silently.

Finally, I would like to outline a detailed attack scenario:

• A company/institution uses a whitelisting product to protect its PC’s
• A user is tricked into running an MSI file. Now this user may or may not have administrative privileges (in which case the MSI file can be marked as not requiring elevated privileges)
• The instructions in the MSI file use the built-in Windows executables (which are on the whitelist) to perform any of the following actions:
  • Add a user with a predetermined password (acting as a perimeter weakening malware)
  • Lower the ActiveX security settings for IE.
  • Lower the security settings for other components (like Javascript, Flash or Java)
  • Opening a preprogrammed webpage. This can have two functions: signaling the existence of a new compromised host and/or containing the “stage 2” of the exploitation which can execute now, given that the security barriers have been lowered.

Conclusion: as many have said before me, there is no such thing as perfect security. What you can do, is to select a lockdown level appropriate for your activity and apply it. Using a lower than needed security level is irresponsible, however using a higher than needed level can prevent you from from doing your work. Be aware of the options and stay safe!

First of all, files on a webserver need to change very rarely. Executables almost never and it is useful to receive an email every time your HTML / PHP / ASP / etc files changed. A perfect fit for whitelisting, a non-starter for blacklisting.

Stepping away from the whitelisting aspect for a moment, on-access AV will be powerless with content which is not stored directly in the filesystem. This includes the recent wave of SQL injection attack, where the malicious data was in the database. Now we have several possible scenarios:

• AV is not installed on the DB server (because it isn’t a webserver :-))
• The installed AV doesn’t scan the files of the DB because of its size limitation or doesn’t find the malicious code because of the large size of the file
• The installed AV does find the malware, blocks access to the database file, thereby killing the DB server or at least making each client fail.

Either way, it’s not good.

Now getting back to the advices, the others are sound. One thing I missed is: apply the principle of least privilege to your network traffic!

• That SSH/RDP port you use to manage your system – it doesn’t have to be open to the whole world. Even better, move it to a non-standard port and limit access by IP
• If the server only needs ports 80 and 443, only allow ports 80 and 443.
• The server most probably doesn’t need to do any outbound traffic, so block it

Also, read and apply security best practices (this usually means changing the configuration) for the software you have on your server (searching for “[product name] security” is usually a good start).