StackOverflown in practice…

We are so used to all the jokes about programmers re-using online code and copypasting stuff from StackOverflow all the time that we sometimes forget about a sad reality – lots of public code is being copied blindly, and ‘if it works’, it more than often makes it to a production level… yes… including code that is incorporated into release build and signed binaries.

This brings a lot of interesting side-effects:

  • signed binaries are often blindly trusted, so vulnerable code that makes it into a signed binary is a big bonus for researchers/attackers (follow hFireFOX and his kernel driver copypasta discoveries)
  • a code that uses a hardcoded set of crypto primitives will be vulnerable to the fact these primitives are out there and in public –> attackers can decrypt secrets faster
  • since the programmers who copypaste the code don’t know any better it often takes a lot of efforts for them (or their successors) to fix these issues

The main topic of this post is the item #2 on the above list:

– crypto primitives re-use.

After poking around en masse in a large number of ‘good; samples I discovered that many of these samples re-use the AES crypto routines that rely on the following two primitives:

  • IV: “OFRna73m*aze01xY”
  • Salt: “Kosher”

This is not a coincidence – you can find code instances that refer to this combo here. Programmers don’t know what to change in this code and they just embed it as it is. Bad and pretty big mistake.

There are many more examples like this and I may list them some time in the future.

Quick & Dirty Sysmon Replacement aka Process Hacker logging

Sysmon is great, no doubt. However… very often an overkill.

Yes, you’ve read this right. I say: who cares about registry writes, process access, driver or module loads, etc. ? What if we just want to log running processes?

Process Hacker comes to our rescue.

The recent versions of this tool include a very handy logging capability that is available not only from a GUI level (CTRL+L keyboard shortcut), but also helps to write stuff that is ‘happening’ directly to a log file – yes, as it happens.

I find it very useful as it helps to monitor unusual activity of the system w/o engaging the full-blown capabilities of Sysmon (performance!). And yes, I do know how weird it sounds… Sysmon cures everything…

How do we set our Process Hacker instance to deliver all this goodness?

We first run Process Hacker with our Admin creds. Then we open Hacker \ Options menu item:

Then choose one of the ‘Notification’ options and either leave it as it is (log everything) or we write down our own rules that can either include or exclude certain paths….

In the below example we include all the process names:

and then we exclude notepad*.exe:

We can include/exclude both processes and services. This is awesome. It’s simple, it’s working.

And if you are curious where the information about these is stored, look for a `ProcessHacker.exe.settings.xml`file that lists the following:

  <setting name="ProcessHacker.ExtendedNotifications.LogFileName">LOGFILEPATH</setting>
  <setting name="ProcessHacker.ExtendedNotifications.ProcessList">PROCESSLIST</setting>
  <setting name="ProcessHacker.ExtendedNotifications.ServiceList">SERVICELIST</setting>

where PROCESSLIST/SERVICELIST has a form of:

  • \e<pattern for exclusion
  • \i<pattern for exclusion

That’s it really… Nothing ground breaking, but a very handy tool for quick & dirty investigations. I find it most useful to detect ‘funny’ Windows 10 services that start ‘out of nowhere’. I then… usually kill them. One by one, you may eventually kill’em all…

Oh yeah.. it may help with malware analysis too 😉 but somehow.. the analysis techniques and priorities changed a lot over last few years…