You are browsing the archive for Compromise Detection.

Beyond good ol’ Run key, Part 26

January 28, 2015 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Malware Analysis

Today I cheated. I wrote two posts in a go, because 25 is not that interesting from the persistence perspective.

So, as promised 5 minutes ago, this post is about yet another Frankenstein’s monster. It focuses on a bug that I have already covered, but intentionally didn’t explore its most crazy aspect yet.

Bugs in dynamically loaded libraries are surely interesting, but even more interesting are the bugs in the libraries that are linked statically.

Why?

Because patching these is really hard and you can’t just submit a single patch to fix it all (unless you do some magic).

So, as mentioned above – the very same code that we have explored in the part 21 inside the MFC libraries is present in many popular applications as it’s linked with them statically.

This is bad news.

The result is that finding such vulnerable applications can give an attacker a myriad of persistence opportunities as all he has to do is to find a vulnerable static library pattern in a .exe or .dll and drop a ‘localization DLL’ in a respective directory. Yes, the statically linked code has a side effect and loads localization DLLs for DLLs as well. So if your foo.dll contains the vulnerable code, dropping fooENU.dll or fooLOC.dll on English system will ensure they are loaded as well.

There are really a lot of applications containing this buggy code. Looking through a couple of apps I was able to quickly spot them inside many omnipresent executables and DLLs.

So, without further ado, this is a very short list of files that I found to contain the specific vulnerable code:

  • %APPDATA%\Local\Akamai\ControlPanel.exe
    • %APPDATA%\Local\Akamai\ControlPanelENU.dll
    • %APPDATA%\Local\Akamai\ControlPanelLOC.dll
  • c:\Program Files (x86)\HP\HP Software Update\hpwucli.exe
    • C:\Program Files (x86)\HP\HP Software Update\hpwucliENU.dll
    • C:\Program Files (x86)\HP\HP Software Update\hpwucliLOC.dll
  • c:\Program Files\Realtek\Audio\HDA\RtHDVCpl.exe
    • C:\Program Files\Realtek\Audio\HDA\RtHDVCplENU.dll
    • C:\Program Files\Realtek\Audio\HDA\RtHDVCplLOC.dll
  • c:\Program Files\Realtek\Audio\HDA\RtkNGUI64.exe
    • C:\Program Files\Realtek\Audio\HDA\RtkNGUI64ENU.dll
    • C:\Program Files\Realtek\Audio\HDA\RtkNGUI64LOC.dll
  • c:\Program Files (x86)\Western Digital\WD Utilities\WDDriveUtilitiesHelper.exe
    • C:\Program Files (x86)\Western Digital\WD Utilities\WDDriveUtilitiesHelperENU.dll
    • C:\Program Files (x86)\Western Digital\WD Utilities\WDDriveUtilitiesHelperLOC.dll
  • C:\Program Files\Western Digital\WD SmartWare\WD Quick Formatter.exe
    • C:\Program Files\Western Digital\WD SmartWare\WD Quick FormatterENU.dll
    • C:\Program Files\Western Digital\WD SmartWare\WD Quick FormatterLOC.dll
  • c:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static\SLSTaskbar.exe
    • C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static\SLSTaskbarENU.dll
    • C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static\SLSTaskbarLOC.dll

As you can see a few prominent vendors. It works for both 32- and 64-bit applications and DLLs.

This is a tip of the iceberg of course and if you scan any average hard drive you will surely find at least one vulnerable app like this.

I guess there may be even cases where such localization DLL can lead to an escalation of privileges if any of the vulnerable components is executed/loaded by a more privileged process/account.

Should this be reported as a vulnerability? Yes. But I really don’t know to who.

Beyond good ol’ Run key, Part 25

January 28, 2015 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Malware Analysis

I have already covered persistence mechanisms that rely on localization features implemented by popular programming platforms (MFC and Visual Basic). These features support localization efforts by automatically loading language-specific DLLs anytime a program written in any of these platforms starts.

You may (or not) be wondering if there is more to it.

What may immediately come to mind here is a simple question: what about Delphi (or more broadly: what about Borlandish apps)?

When the Borlandish application is executed it queries very characteristic registry keys that you may see in the Process Monitor anytime you start f.ex. a Delphi application:

  • HKCU\Software\Borland\Locales
  • HKLM\Software\Borland\Locales
  • HKCU\Software\Borland\Delphi\Locales

Other (newer) Borlandish applications may include not only Delphi reference, but also Code Gear and Embarcadero:

  • HKCU\Software\CodeGear\Locales
  • HKCU\Software\Embarcadero\Locales

and query them as well. These keys are queried for an entry which is a full path of the executed application e.g. for c:\foo.exe it could be:

  • HKCU\Software\Borland\Locales
    • c:\foo.exe = abc

If such entry exists, it should contain a value maximum 5 bytes long and identify a file extension of the requested localization library. In our example it is ‘abc’. The file extension will then be appended to the file name of the application (after removing the original file extension, typically ‘.exe’). Notably, if the entry is not there, or more than 5 bytes long the application will try to use the value of a Deafult key under

  • HKCU\Software\Borland\Locales
    • {Default} = def

If none of the 2 values exist, the file extension for the localization DLL will be based on the current locale for the calling thread e.g. for English it could be .ENU, .EN.

Once the file extensions are sorted the program will call LoadLibraryEx API and attempt  to load the localization DLL as follows:

  • <appname>.<file extension> if Locale registry entries exist
  • <appname>.ENU – if the above fails
  • <appname>.EN – if the above fails

Also, as a side effect of the way LoadLibraryEx works, the API will query for the following DLL names and will load them if .ENU/.EN files don’t exist (respectively):

  • <appname>.ENU.DLL
  • <appname>.EN.DLL

The good news is that all these libraries are loaded using LoadLibraryEx functions with the LOAD_LIBRARY_AS_DATAFILE flag. So, while Borlandish apps do support external localization DLLs they load them properly i.e. not as a code, but as data. As far as I can tell this was implemented correctly from the very first version of Delphi that supported localized DLLs.

That pretty much kills the idea of using such DLLs as a persistence mechanism.

Well sort of, you could always use a pattern matching to find a DLL loading routine in the existing Borlandish binary and patch it. Patch requires a flip of a single bit to disable LOAD_LIBRARY_AS_DATAFILE (0x2) – this would enable loading of localization DLLs as a code.  Quite honestly, this is lame and while it could be a good idea a decade ago or so, now any modification to an existing .exe will most likely trigger an AV alert (since it looks like a possible viral infection).

So, while it’s not really a persistence mechanism it was still worth exploring even if just for the sake of ruling it out and understanding what these Locales keys are.

If you are a bit disappointed I can only say that the topic of this post leads us directly to the part 26. It will be about yet another Frankenstein’s Monster :)

Stay tuned.