Author Archives: adam

handle..ing SHAllocShared

Posted on by

There couldn’t be a less misleading post title than the one I chose for this entry. The function SHAllocShared is documented, may not be very well known, but we may see it more in the future. It is exported by shlwapi.dll and its description has a nice vibe to it:

Allocates a handle in a specified process to a copy of a specified memory block in the calling process.

Hmm… I remember that 15+ years ago or so I was looking at the AppBar functionality. At that time many applications were taking advantage of this desktop feature, so I was really curious how it works. Eventually I created a simple POC that relied on SHAppBarMessage function to add my own app bar, but then got bored and forgot about it.

A few months back I suddenly remembered that POC. I realized that I have never looked at the internals of the SHAppBarMessage function, and with my experiments around code injection via GUI primitives this of course triggered my interest.

Under the hood, the SHAppBarMessage relies on SHAllocShared/SHLockShared and SHUnlockShared/SHFreeShared APIs to create&lock/unlock&free block of memory allocated within program’s address space, and then WM_COPYDATA message is used to send info about the appbar message to ‘Shell_TrayWnd’ window (tray window). Internally, SHAllocShared relies on CreateFileMapping/MapViewOfFile/DuplicateHandle API set to duplicate a handle to existing memory block inside a target process.

This is it. It’s not a lot, but having a set of atomic functions residing inside the shlwapi.dll is probably not a bad thing. This is not as robust as accessibility functions that do a lot of reading and writing of memory blocks between different processes, but it’s always good to have some extra feature at hand.

Beyond Fear

Posted on by

In his book Beyond Fear: Thinking Sensibly About Security in an Uncertain World, Bruce Schneier tells us that:

a) 9/11 was a evilish, but brilliant plan,
b) risk assessment is hard, but most importantly,
c) У страха глаза велики (Fear Has Big Eyes).

SolarWinds hack is a evil genius, and even if the fallout is going to last for months we do need to pause to contemplate the technical capability involved. If you follow me on Twitter or read my stuff here, you know that I absolutely detest the word capability. It is a buzzword of people who don’t understand technology, and anti-buzzword for people like me – who are civilians, never served and can’t think in strategic, military terms, but are at least bad programmers.

The capability is not coding per se, of course. It is not even staying under radar of security solutions for a few months, or even for more than a year. The real capability is making the backdoor code seamlessly integrated with a code base so that it can be compiled with no errors, and/or compiling your own version of the binary and swapping it at a right time so that it can be signed by the building environment.

The finesse of this maneuver cannot be understated / overlooked.

Now… malicious modification of a source code is actually not that uncommon and not that hard to pull off. Every web site defacement of the past included changing some source files (HTML /ok, not code, but always/, PHP, ASP, etc.). Many e-commerce hacks, especially within PCI space include some sort of modification of the web site’s source code (e.g. add event handler to form submission events to steal credit card details, etc.). Zeus and other infostealers’ injects were genius too.

BUT

Somehow, code modification of the standalone, non-web site component, that is, a source code that is compiled into a binary executable is much harder. You know that if you ever tried to compile a source code taken from github or Code Project. So many things can go wrong. I have yet to encounter a source code that compiles on my box w/o any error from a compiler. To make FaaS work it took me good 3 days of troubleshooting.

This brings me back to capability. The surgical operation that (according to what is known) relies on a code injection into a pretty large software source code live branch – source code that changes constantly and is very dynamic in nature, is the skill and tradecraft one has to respect. Is it on the same level as Stuxnet? Definitely not, but it is way above your average red team pay grade.

People coding botnets, rogue anti-spyware, bank infostealers are good malware programmers. People developing 0days and injecting source code into live code branches are very good malware programmers. There is just a few in the world that can really offer this capability. It’s sad, because they will never be able to travel, live in other places, and enjoy any sort of freedom we average people enjoy.

Kowtow and RIP – you will be pwned one day.