In our previous post about Petya, we speculated that the short-cuts, design flaws, and non-functional mechanisms observed in the malware could have arisen due to it being developed under a tight deadline. I’d now like to elaborate a little on what we meant by that.
As a recap, this is what the latest version of Petya looks like (to us).
Since the previous post, we’ve determined that the user-mode encryption-decryption functionality is actually working as intended. That’s the mechanism used to encrypt and decrypt files on the system.
However, the MBR encryption-decryption functionality doesn’t work. This is because the “personal installation key” displayed in the MBR ransom screen is just a randomly generated string. This is one of the main reasons why some people are calling Petya a “wiper” (or “WTFware”).
Naturally, this unimplemented functionality has led to much discussion on the Internet. And also here at F-Secure.
We discussed the “illusory” MBR functionality in some detail. Here are a few points that were made.
- This is a new piece of crimeware when it comes to the user-mode component. But the MBR code was taken from v3 of Petya, known as “GoldenEye”. Current consensus seems to be that only a guy called “Janus” has the source code of Petya, so if this operation isn’t being run by “Janus”, it’s possible that this new ransomware is just using a hex-edited dump of the infected MBR.
- How would a third-party use the Petya binary? First off, the way this dump is used tells us that the author knows exactly where to patch the Petya encryption key and nonce, and also the “User ID”. The author also knows how to edit the MBR banner message, and other minor changes. This involves reverse engineering and taking a very close look at what people have written about Petya over the past year or so.
- In the “real” Petya the “User ID” is a real cryptographic entity that makes it possible to return back the actual disk encryption key, which is discarded in the process of locking up the disk. In this new Petya the “User ID” is totally random. I mean literally. It’s purposefully generated using Windows crypto APIs as a random string.
- Now ask yourself: If you know how to strip off the Petya bootloader, how to hex edit it, where exactly put all these variables, and how to change the banner, would you think it will work by just putting some random data there? Really? Everybody who follows these things knows that the “User ID” is a complicated piece of very precisely formatted information, that includes, for example, an Elliptic-curve public key generated by the infected machine. So, even if someone is tripping with mushrooms and thinks that generating random data will magically turn to something useful that can restore the encryption key, you need to ask next: would you in that case even once try to reboot and test if your magical random ID can be of some use? And would you ship it after this revelation?
Here we establish that the author of this malware obviously knows his code isn’t going to work. The author also knows that members of the community have meticulously studied prior versions of Petya, especially the MBR code, which is of interest, since it’s unique to Petya. So the malware author would be aware of the fact that it wouldn’t take reverse engineers all that long to figure out that the encryption-decryption mechanism is bogus.
However, consider the possibility that this malware was developed on a tight deadline, and released ahead of a reasonable schedule. I’m sure there isn’t a single software developer in the world who hasn’t been through that “process”.
But let me put on my “developer hat”. If I were to develop a piece of malware that includes Petya, I’d most likely start doing it first by embedding it in my project and maybe first filling all the variables with random data. Just to make sure the overall concept of embedding it works, Petya MBR code kicks in after reboot, and so on.
After everything seems to work, then I’d move on to the next step, where I’d implement the actual Elliptic-curve stuff that would ultimately replace the placeholder random data.
Let’s note at this point that all the Elliptic-curve-related code is completely absent in this new variant. It’s a complicated piece of code that would probably take over a week to develop and test properly.
So, what if my friend, who’s supposed to “ship” this thing gets a wrong version, or doesn’t bother to wait for it to be ready, or whatever. He will just package everything up, run it to see that everything looks like it works, and ship it. And off we go.
Putting together a proper build process for software isn’t easy. Tracking changes in different modules, making sure your final package contains the right things, and testing it thoroughly enough to catch discrepancies, or wrong versions is also time-consuming. Many “real” software companies have problems with build processes and versioning. The theory that the final build of Petya contained an old version of one of the components is not at all far-fetched. Neither is the theory that they shipped a “minimum viable product”.
Plenty of other evidence points towards this piece of software being developed in a hurry, and not thoroughly tested.For instance, a machine can re-infect itself and encrypt files twice. There’s also this bug:
Bug in #Petya's encryption may leave some files damaged and undecryptable. pic.twitter.com/V8agzHocaL
— Ladislav Zezula (@LadislavZezula) June 28, 2017
And I’m sure we’ll find more bugs. (Whoever wrote this is getting a lot of free QA!)
At the end of the day, if someone wanted to build a “wiper”, why build an almost functional ransomware, save for a few bugs and a possibly misconfigured final package?
Tagged: Malware, Petya, Ransomware, Th3 Cyb3r
Article Link: https://labsblog.f-secure.com/2017/06/30/eternal-petya-from-a-developers-perspective/