Installers – Interactive Lolbins

Update

After I published it n00py1 sent me a link to this post by NinjaStyle82. So, not a silly idea at all, and it actually allows to get a privilege escalation in some cases as well.

Old Post

This is another way to launch your binary via proxy. It’s very ugly as it generates a lot of noise, but if you have an interactive access to the box, perhaps it could work…

As usual, the idea is simple and is basically a variant of a classic con known as a bait and switch. It will work as long as the installer offers the below final screen at the end of the Installation Wizard (a check box that makes it launch the program):

Note that many installers install to Program Files paths by default, and nowadays these are not accessible to normal users (UAC popup shows up). So to pull this trick off w/o raising a suspicion one could change that destination path to a folder controlled by an attacker e.g. somewhere under c:\users.

Files in this ‘controlled’ folder will most likely not have restrictive ACLs (after being dropped). Once all files are there, but before we launch the final application via GUI, it is at that moment when you have to replace the main executable with your own binary. Then just click Finish and your program of choice will be executed, as if a part of the setup process (and lolbinned since the parent is a signed application).

There are possibly other variants of this – ones that involve swapping DLLs that often are registered or unregistered by the setup programs. This may require winning a race condition though (you need to swap the DLL after it’s written to disk, but before the DLL loading happens). And yet another variant could just swap the existing (installed) uninstaller program and then run Setup program to ‘uninstall’ the application…

It’s superlame and unpractical. But sometimes it’s the stupid things that work best.

Signed Nullsoft Plug-ins – potential Lolbins

A couple of years ago I exported ~12K Nullsoft plugins from a large corpora of installers. It was a part of my research on hooking Nullsoft plug-in APIs that I described here.

Today I revisited this old repo, because it crossed my mind that perhaps some of these DLLs were actually signed. And if they are, I thought, then perhaps some of them will tick the box of re-usigned libraries.

To my surprise, I found over 2K signed plug-ins.

Encouraged by these stats, I ran a script to list all the functions exported by these DLLs. Apart from default exports that can be found in the most popular Nullsoft plug-ins, I was able to find tones of other functions.

There are functions for pretty much every occasion:

  • Internet downloads
  • Resource handling
  • Message Boxes
  • Mathematical functions
  • FTP
  • File operations
  • Audio / Video
  • Unicode
  • Network enumeration
  • Process operations
  • Sqlite3
  • Encryption
  • HTML
  • SSH
  • Hooking
  • String operations
  • GDI / UI primitives
  • XML
  • ZIP
  • Zlib
  • and lots more

There are also ‘more refined’ self-descriptive functions e.g. CreateProcessInjected, InjectDll, _DownloadCompleteFile, SilentOpenURLA, KillAllXBrowserProcesses and a variation of KillProcess functions.

Given the variety of exported functions many of these DLLs must be based of source code of popular foss libraries. Why? It’s really hard to believe someone accidentally included all OpenSSL exports in a working Plug-in.

Being so feature-rich one could use these to build unusual code paths that would rely on code callbacks provided by these signed DLLs. In a way similar to ROP, except re-using functional code blocks instead of a single instructions, their small clusters, or trampolines.

Here’s the whole list if you want to have a look.