Digital signatures in executable files and bypassing this protection in malware

Habra Hi!

Well, it seems like they managed to solve problems with karma, but they in no way relate to today's topic, but only explain a certain delay in its publication (the original plans were for November last year).

Today I bring to your attention a small overview on the system of electronic signatures of executable files and ways to bypass and falsify this system. One of the very effective workarounds will also be examined in detail. Despite the fact that the described infe is already several months old, not everyone knows about it. Manufacturers of the products described below have been notified of the material described, so it is their responsibility to resolve this problem, if they consider it a problem at all. 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. According to the manufacturer’s idea, a signed code can only come from a trusted author of this code, and therefore it is guaranteed not to harm the system and is protected from errors ( three haha ).

However, since the signature mechanism most often uses a rather complex cryptographic mechanism, the general trust in the signed code has spread. Antivirus vendors didn’t get away from this. 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, by default there is a bypass of checking 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 of aka hips.

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

But this approach has a flip side: after identifying a compromised signature, it immediately responds, and by the very fact of the signature, the AV vendors put a signature detection, it is clear that with 100% response. Given that it is extremely expensive to purchase a stolen certificate, which is necessary for signing, it is clear that virus makers are interested in a complete bypass of the signature verification mechanism, without valid private keys or by generating such keys independently. This will allow you to bypass the protection of not only anti-virus products, but also install drivers and ActiveX-components without warning, and generally somehow break into the world of x64, where you can’t install anything without signatures at all.

But more about that in practice.

PRACTICE

Someone from the great said that in order to get ahead of the enemy, one must begin to think like him. So, if we are virus makers, then what can we do?

1. Copy the 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 at the sight of the user. However, what the OS displays may well confuse the inexperienced and be perceived as another glitch - if all the publishers are correct, then why is this signature invalid? Alas and ah - such a majority.

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

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

3. Fake 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-life examples of MD5 hacking concern either very small files, or lead to incorrect code operation. In practice, viruses with fake cracked signatures on the MD5 algorithm are not found, but nevertheless, this method is theoretically possible.
4. Obtain a certificate according to 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 is the fake Perfect Defender (standard scam: “scan for free - you have a virus - pay us and we will remove it”) exists with the signatures of several offices:
• Jeansovi llc
• Perfect Software llc
• Sovinsky llc
• Trambambon llc

How it can be done well tell our domestic developers of winlockers, who write in small letters about the "joke program", etc., thus being protected from an article about fraud. So we live ...

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

It is clear that if you really believe this, then it is not difficult to make a mistake at first glance at the certificate.

It should also be noted that it is by no means difficult to obtain a signature from certification centers. For example, RapidSSL uses just e-mail for verification. If correspondence is 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 writes, right? ( three more haha) But the glorious company Digital River (DR), which provides outsourcing and e-commerce services, generally provides certificates to all its customers. It is no wonder that MSNSpyMonitor, WinFixer, QuickKeyLogger, ErrorSafe, ESurveiller, SpyBuddy, TotalSpy, Spynomore, Spypal, and generally about 0.6% of all signed DR files are junk, and more than 5% of all signed DR files are potentially unwanted .

In fairness, I note that signing the x64 driver is far from easy, in which 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 only question is the sum :)

6. Steal the certificate.

At the moment, there are three large families of Trojans that are “imprisoned”, in particular, for certificate theft. These are:
• Adrenalin
• Ursnif
• Zeus
• SpyEye (possibly)

Nevertheless, there have not yet been any massive cases of using stolen certificates in new versions of these Trojans. Perhaps this is a trump card in the sleeve? Time will tell ...

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

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

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

Well, now - the promised sweets.

VULNERABILITY OR HOW I WENT THIS SUMMER

As you can see, there are a lot of 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’s not difficult for the habrachitatel to find these components, but for the laziest I post the first three here. I don’t post the last two in view of the tight binding to hardware, the complete absence of cross-platform and code specificity :)

So, we will create some kind of certificate of a trusted publisher. Let's try to copy information about the same VeriSign as much as possible:
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 get veri.pvk and veri.cer, suitable for signing.

Now we will create a child certificate using just received certificates:

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 will get kl.pvk and kl.cer, which will be trusted certificates from an untrusted publisher. The chain can be continued for a long time, fooling a naive user. But the result will be one: the certificate will not be valid, because there is one untrusted element in the chain. BUT!

In Windows, you can install any certificate, including a self-signed certificate, as a trusted one. This is convenient: in some cases, the developer can make himself a self-signed certificate, enter it into trusted ones and work calmly with his applications. In our case, this is doubly convenient, because such an entry is obviously a simple entry of information into the registry. whereby the information is by no means specific to a particular system.

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

In order not to completely open all the cards, I can only say that in my case the registry dump looked like, or if only for the current user, then Having entered this data into the registry, the program with the fake signature chain automatically checked by sigverif.exe. Well, signing our code with the help of the received certificate is generally simple, just a batch file:
Windows Registry Editor Version 5.00

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


Windows Registry Editor Version 5.00

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



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 the timestamp timestamp.verisign.com/scripts/timstamp.dll - it is theoretically quite possible to use your own server on your own domain, which will allow you to see every time that someone checked the signature of our program on your computer, which means that you get IP and check time. Is it really convenient? ;)

The funny thing is that at the time of writing the material back in October-November 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 rather simply fooled. I don’t know what now, but it seems like some branches have blocked ... Check, unsubscribe!

It should be noted that for signing signatures it is possible to use specific software that is not available in the public domain. It is clear that he does not break the signature, but gives much more flexible options for filling in the X500 fields, which even better creates the appearance of validity. Here it is possible to download a curious example. In the archive - a file of the popular replacement Notepad bred3_2k ( offsite ) with and without a Microsoft signature :) For the signature to become fully valid, it is enough to make changes to the registry contained in the key + .reg file. Similarly, the key -.reg file discards these changes. Track the certification path - it is curious :)

Immediately pay attentionto the fact that the author of the “example” registered his own timestamp server, so that any manipulations will cause the author to know your IP - and then, as described. If you want, you can track these requests 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 described introduction of certificates into trusted ones. Unsubscribe in the comments - it is possible that this vulnerability has already been fixed.

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