Category Archives: Archaeology

When your TODO list is always short of something…

Posted on by

There is only one place visited by Windows coders less often than anything else: their program’s resource section. This is either a sacred or a scary place, depending on the coders’ inner fears or strengths – but no matter which one it is, with this post I want to draw your attention to program’s VERSIONINFO section.

If program is coded in Visual Studio – its versioninfo is typically pre-populated with a bunch of boilerplate TODO strings:

It is the place where we specify the name of the program, its version, description, add copyright notice, and where we add the name of the company that produced it, etc.. Some programmers adjust these automatically via intricate command line tools or scripts, some edit these manually. Some… forget to do so….

Now… creating software is exciting. Writing your new, revolutionary code is an exhilarating experience (or a dull one, if you are bored to death in your job), and with all these cool (boring) features you are adding so quickly, the poor versioninfo section is typically left behind.

Until the day you sign.

I mean, the day you literally sign your release .exe and then… it becomes IMMORTAL.

Why immortal?

It’s signed… kinda forever. Certificate revocations happen quite rarely. And if legitimate, your .exe will most likely end up on many popular download, mirroring sites, and/or in in AV and EDR repositories. And if it has a built-in vulnerability, backdoor, or some stupid logic flaw or dependency, and worse – if there is an active exploit/trick for it – you can be sure that it will become a long-living part of an arsenal of attacker groups. And if you still have doubts… nothing is ever permanently deleted from the internet anyway 😉

Back to your signed file…

If you have not edited these versioninfo properties – they will make it to the signed build. If there is no proper QC process, the version information bits that you were supposed to fill-in early in the process will be left untouched e.g.:

  • TODO: File Description
  • TODO: Company Name

Yup. Anyone viewing properties of your signed file will see something like this:

It’s ugly. And… it’s so… common.

Over years I have seen many signed binaries with the version info populated with a default ‘TODO” boilerplate. I find it to be a truly interesting phenomenon. I mean, who would forget it before signing? Right?

I was curious how many companies actually did forget to change that boilerplate at some stage in the past. Obviously, I don’t have all the files of the world, so the list below is biased, but on the other hand, I have been collecting clean files for many years now… so I think it’s still kinda representative – especially that many big names are on it.

The examples are just single hash/company, but there are more hashes/company, obviously:

  • Acer Incorporated
    • 2C11C7769AFBA91795309335E95364610B64A0D5
  • Advanced Micro Devices
    • E7C988AAE8A28537418BAAF9C6D627F1E9A71D3D
  • Alps Electric Co.
    • F0081345B04426F2327CC83BCB78549F266D02B2
  • ASUSTeK Computer Inc.
    • 4EFE7101C6E34FF6654B27C0E356B3906077228F
  • AzureWave Technologies
    • B502DF357711B544A9D358F4BBD5A570AC94A2D8
  • Broadcom Corporation
    • 163BD9619BE13A149CD0FC23E9591D0B557FF8AC
  • Clearwire Corporation
    • 3A34C830547BF851D803351D9F0F9FE5A756ECAB
  • Conexant Systems
    • B0464EA6E85DCF73BCDB7F59E2FE39E1F30F0BC6
  • CyberLink
    • E9376D0887317F7294887AD51C40DB8C775D1439
  • Dell Incorporated
    • 404E4A8C86A6E45328B324B5BAC0CA1022C46F7C
  • DTS
    • 3FDB841A79DC5A19581608A9F7DC277D646DD2B9
  • GENESYS LOGIC
    • C3E0A08681282C2F07647B62607FC02F684E2302
  • Hewlett Packard
    • 9A947DB8463B010CE60FAE48C995C2349E913026
  • HTC Corp.
    • C2702513C3B1E8782A5C09845EA3AD9DD6150272
  • Huawei Technologies Co.
    • D4BA877C07342C2EE4DD07D35A3FCF065C28A7D9
  • Intel Corporation-Mobile Wireless Group
    • CB92B9366322BADD7FE8468586D6BCF5F3EDD267
  • IVT CORPORATION
    • 05B5F6413FE4AE449007B6FC70FBB196DA5F3881
  • Lenovo Information Products (Shenzhen) Co.
    • 71F10E73D71A651CC2A31B5D5B4A4710A386E419
  • Logitech
    • A81A76EFF455966DBAFEFE33AFA0005B128652A3
  • Magic Control Technology Corp.
    • 334367D94B8096BE8109DBAA7B2DF43CF7EE4DB3
  • Microsoft Windows Hardware Compatibility Publisher
    • 638A2003B302900AF56AF7BE9FB83F6EC022F391
  • Penpower Technology Ltd.
    • 10ECABAE634F48F57594BE5A72723415B3FC2192
  • Ralink Technology Corporation
    • E75E67EF40D83C4819E47F138AA3AE24955787EF
  • Realtek Semiconductor Corp
    • D9F1DCC120C684D233AA7F2C234AC6A3C35C0B4C
  • Samsung Electronics CO.
    • A37D12C80ACF024F6F0D1EABD919BB3149C2B4EC
  • Sentelic Corporation
    • B53564DE1380AF1169F8D356E8BC8C917310F627
  • Softex Incorporated
    • 679528394EF830468E2A335C597CD75E8096B8CD
  • Stardock Corporation
    • 6CF78EF4597F9646B01654AD5ABFE4F73A93006B
  • VIA Technologies Inc.
    • A8CBD410AEA6A7C5E850B8659725E736BBFAA30F
  • Wave Systems Corp.
    • EB357F2096537F6AA1A24366258F781AD5DE9CFF

And I list these not to shame the companies. As I mentioned – I think it’s an interesting phenomena from a sample clustering perspective, and I don’t think it really affects security in any significant way. At the end of the day, a signed file is still a signed file so you can be sure it’s ‘better’ than an unsigned one. Yes, there are malware families signed with a stolen or a forged certificate, but still, you will be always better off trusting the signed files more than non-signed ones.

Still… how does it affect us, Blue teamers?

I don’t have all the answers and welcome comments. Obviously, adding exclusions/whitelists that treat ‘TODO’ strings as a trusted ‘Signed Publisher’ is not a good idea. This obviously adds a need for us to whitelist these files by hashes, or paths.

If found on the investigated system, these files may attract the attention of forensic investigators as well (e.g. if they look at autostart records and detect entries that point to signed TODO executables). After so many, heavily publicized reports about stolen certs, or supply chain attacks, it’s only natural to immediately generate hypothesis about ‘if I see TODO: strings, this system was probably attacked by someone using malware signed with a stolen cert’.

Finally, it also exposes a less-discussed weakness of the signed files:

  • We often forget that there are programmers behind every signed file
  • These coders make mistakes; many mistakes

– a.k.a. if there is a bug in versioninfo, there could be a bug in the code. Or… it could be a feature :-).

Last, but not least: if you produce software on regular basis, please add the QC stage to your process where the release build is always checked against TODO entries. Kill the build if needed, because it is a proper build breaker. Fix it. Release good releases. Thank you.

‘Plata o plomo’ code injections/execution tricks

Posted on by

Update:

2020-11-27: added Microsoft.Windows.SystemCompatible sideloading & Windows Side-By-Side manifest abuse & KnownDLLs abuse
2020-08-14: added NtCreateProcess section reuse & TLB abuse
2020-04-10: added some less known techniques

Old Post

This post is not about a single injection. It is about a class on its own.

At the moment I know of only two instances of code injection/execution that fit this category perfectly, and I am going to describe them below, but I bet there is more…

First of all, why ‘plata o plomo’? It’s obvious. In today’s world every security research needs a cheezy name ;), right?. Secondly, the ‘plata o plomo’ fits the cases perfectly – it’s ‘either silver, or lead’. And when it comes to code injection/execution – it’s definitely a lead. Or Ulead.

Okay. What about the actual ‘code injection/execution’ bit?

This Endgame post presents a very comprehensive overview of what was out there back when it was written in 2017. It’s a great starter for anyone interested in this topic. However, many things have changed since it was posted + the article omitted a number of interesting techniques anyway.

The below is a summary of all existing code injection tricks that I know/could think of (ping me if I missed anything):

Notably, the last few links on the list above are leading to modexp.wordpress.com blog. After reading it for a while, and talking to author on a couple of occasions, and finally eyeballing the github repo associated with posts and older work of the author, I can only bow to this programmer’s coding, and manual code crafting skills! This blog is really high on my list and I highly recommend it!

Anyway… back to the topic of this post:

  • What if I told you… that there are developers our there that make the whole game of code injection extremely easy? No trickery, no code trampolines, no obscure undocumented structures, not even forgotten, legacy code paths, windows shattering, let alone ROP, gadgets to be relied upon. None whatsoever needed.
  • What if I told you that you can just provide an address of the code you want to execute in a nice, user-friendly way ?
  • What if this code actually executed according to your wishes ? In User or Kernel mode.
  • What if I told you the programs facilitating this are signed as well?

In other words: what if code execution/injection was there ‘by design’?

Yes… it’s a mind blowing idea. And yes, as I stated before in my Law Of A Threat Hunter (LOATH):

For every two distant technologies there exist a developer that will bring them together.

So… if you can find such program / driver you get a clean shot at a golden opportunity – a signed process or DLL offering a controlled code execution, and then most likely an AV/EDR bypass. And as I mentioned earlier – there exist at least 2 such applications/kernel drivers that I am aware of that fit this description perfectly, and I bet there are more.

Cuz… if it is signed, then it’s good. Right?

I first heard of Capcom driver from the zerosum0x0 blog (yet another great blog to follow!). The post I linked to introduces a tool called puppetstrings that tries to exploit the vulnerability in a aforementioned capcom driver. The vulnerability is actually supersilly – when you send a special IOCTL request to the capcom driver, it will temporarily disable Supervisor Mode Execution Protection Enable (SNEP) mode, call a callback procedure controlled by the user (in a user address space), then return and restore SNEP state…

How crazy is that? I mean: HOW CRAZY IS THAT ?

When I read about it and the whole concept of ‘Bring Your Own Vulnerability’ (BYOV) for the first time I actually really liked the idea and thought it could be expanded to Bring Your Own Functionality (BYOF). I speculated that there are other applications/drivers that are written in a sloppy way, all for good reasons though – and they may not even need any vulnerability at all! And I finally found my first.

In fairness, I have been actually toying around with the concept of reusigned binaries for a while. Lolbins are easy wins, low-hanging fruits, but there is tones of other legitimate software out there that gives clever users more than the developers meant to. We can re-use signed binaries to give us keylogging capability, kill a process, wipe a drive, spawn a new process if we need it, and modify Registry, install Services, and so on and so forth. Not only it is an interesting area for research – I actually believe that this is an inevitable future of many pentesting or red team engagements, let alone nation attacks. And some of the existing attacks already show that a possession of signed drivers/software that can be used for BYOV/BYOF can be leveraged to bring a lot of havoc – e.g. signed EldoS RawDisk drivers were used by Shamoon to wipe out the orgs’ media.

Welcome the ‘Plata o plomo’ contestant number 2.

Ulead Burn.Now 4.5 is an old app from year 2007 that was used to burn ISOs on CDs/DVDs. Nowadays this feature is not really needed – the whole cloud buzz makes cloud so popular and offers far more space & flexibility that the old (and dying) media burning industry can’t really compare. As far as I can tell this Ulead app is no longer updated, but the beauty of good old is that it is out there.

Now, for the juicy part. Apart from doing what it was meant to, the application (or at least this particular version) includes a very interesting feature (most likely for testing purposes):

  • If you set a specific environment variable to a certain decimal value the app would retrieve it during run-time, convert it into an address, and finally…. make a code jump to that address!

Yes. You hear that right. OMGWTFBBQ. You can literally tell the app to execute your shellcode from a specific location in memory!

Let’s start with a name of that Environment variable:

  • GLOBAL_HOOK_ENVIRONMENT_STRING

In the below demo I set it to 195936478 (0xBADC0DE). and then run the application under Olly to demonstrate when the main program jumps to the 0xBADC0DE location:

You may be concerned about required UI interaction. This is actually not an obstacle. If one was about to use it maliciously, one could engage basic GUI automation techniques to ‘click’ that OK button. It’s actually pretty trivial with available APIs (e.g. FindWindow, or enumeration via EnumChildWindows to find the required window, then sending WM_COMMAND/BN_CLICKED, WM_LBUTTONDOWN, etc messages to the button window).

Also, the name of the environment variable is present in a number of components of this application, including a number of DLLs. As such, there is a high possibility that one could simply instrument these DLLs to execute the shellcode e.g. via a customized DLL loader (provided we injected a shellcode beforehand).

A quick grep for GLOBAL_HOOK_ENVIRONMENT_STRING inside the installation directory (c:\Program Files\Ulead Systems\Ulead Burn.Now 4.5 SE) shows the following list of files that include a reference to it:

  • SH_PEShareComm.dll
  • SH_ObjComm.dll
  • SH_BaseDV.dll
  • PS_UndoManager.dll
  • PS_TextMedia.dll
  • PS_RTObjMgr.dll
  • PS_Register.dll
  • PS_PSShareComm.dll
  • PS_PSPhotoAction.dll
  • PS_PS2SlideShow.dll
  • PS_PS2Base.dll
  • PS_PrintCDCoverCtrl.dll
  • PS_PEShareComm.dll
  • PS_PaperTemplDB.dll
  • PS_PaperTemplCtrl.dll
  • PS_ObjComm.dll
  • PS_MenuTool.dll
  • PS_MediaBase.dll
  • PS_IPEDLL.dll
  • PS_GUIBase.dll
  • PS_CommonControl.dll
  • PS_CDLabelBase.dll
  • PS_AddTextCtrl.dll
  • HDRf.dll
  • Fourier.dll
  • CDLabel.dll

All of them are signed. So it’s almost certain that _some_ of these could be loaded outside of the main program, and then instructed to execute the shellcode.

Coming back to where this post started – when it comes to ‘Plata o plomo’ and code injection – it’s always the lead. Developers make and will make stupid mistakes, they write and will write code that is often meant to be only used internally, but sometimes it will make it out to the releases available to general public, and into signed packages.

The lesson learned is that what is green on VirusTotal is never green from a blue teamer’s perspective. We need a better process (and a long way) to declare things ‘truly green’ for that matter. For a long time now we know that the authenticode signatures are just an ersatz of security and while always useful (better to have them than not to), we should no longer rely on them blindly.

Future attacks will engage signed binaries more. There is no doubt. We need a dedicated team of analysts in every security companies to start looking at vulnerabilities present in these, and also ‘built-in’ features that make the ‘green’ VT stuff vulnerable to abuse. Again, I am more than certain there is a lot of this stuff out there. Only a few weeks ago @Oddvarmoe published his findings about the 7z binary he found that is signed by Nvidia. Any such ‘signed popular tool’ instance is interesting from at last two angles:

  • It is signed+ ‘perceived as good in general’, so may (and most likely will) sneak in through EDR/AV filters
  • if it is old version enough, it may include many interesting vulnerabilities – – some may allow to execute shellcode or do some other funny stuff

As such… the era of Lolbins, BYOV, BYOF will catch many companies off-guard.