Petya: “I Want to Believe” | Hacker News Reader

Petya: “I Want to Believe”

labsblog.f-secure.com

168 pointsr72167 comments

About robust components being developed in February; couldn't that just mean that it's a sort of pre-made malware or "malware framework" being used to deploy these two exploits?

I'm thinking that the malware world develops code on the same level as the rest of the coding world. So developing a robust MBR and network component that can use drop-in exploits would make sense.

That's basically my reading: Some script kiddy got hold of spook-grade malware and tried to mod it.

This. I don't get the impression people who set up ransomware typically write all or even very much of the virus. They cobble together bits and pieces from the web, writing only the portion they couldn't find.

Seems like the tough part would be setting up the whole chain such that you actually wind up with money in your own bank account without also setting up a big neon Arrest Me financial trail.

" For instance, a machine infected with this malware can re-infect itself via one of its own propagation mechanisms"

Not even malware gets proper QA these days....

I am an average web developer and I have sound computer and programing skills. I'm interested in computer security and always fascinated by these articles.

When I read stuff like "Petya (binary edited)" I feel like a complete noob. Anyone care to elaborate how editing binaries would be done?

Sounds like a daunting task. Even on a normal program. Much more so on malware that is obfuscated to begin with. Just curious :-)

Well, you look up the format of executable files under your operating system and find the parts of the program that you want to edit, like the code segments. Then you write the code you'd like to run, let your compiler translate it into the appropriate binary format (or you do this step by hand) and write it at the right spot. You have to be careful if addresses change (because you changed the size of the code for example), then you have to to the linker's job again.

The first step is to get hold of a hexdump editor.

https://en.wikipedia.org/wiki/Hex_dump

Then you need to have an idea of the executable file format so that you can extract information from the respective file sections.

Of course, there are tools that will extract those sections. So manual work only occurs if the tools fail to do their work.

In the case of executables, reverse engineering tools like IDA give an helping hand.

https://www.hex-rays.com/products/ida/

Then it goes from there, with lots of Assembly love and knowledge of OS internals.

Okteta for Linux, Hex Fiend for Mac , 010 for Windows.

Radare is a free disassembler.

Hopper is good a good disassembler for Mac.

IDA is great, but very expensive.

Manual work happens almost always with weird malware and or packers. They almost always do something that makes trivial reversing harder.

I'll take a stab at a newb-friendly explanation, bearing in mind I'm only slightly less of a newb, but have at least studied this stuff to some extent and have played with https://microcorruption.com, which is a game about maliciously editing machine instructions. Onwards!

CPUs have a fixed instruction set. Add, subtract, increment by 1, and so on. These instructions in turn are represented in machine language as a binary string, which represents signals that get sent to the CPU's processing center, the ALU (Arithmetic Logic Unit). The ALU has a number of input ports, with each one corresponding to a different fundamental operation.

There are a number of programs capable of taking an executable and providing a step-by-step breakdown in machine language (which makes sense intuitively because the machine has to do this for itself anyway in order to execute the program). So once you have the machine language instructions, you then study it to see what different sets of instructions are doing. This is made somewhat easier by the fact that computers run through instructions linearly (with the exception of jumps, but you also know that jumps represent some sort of logic operating on input, so those are informative as well).

Although this would take forever to do manually, there are programs that aid in breaking machine language into easier-to-understand chunks, like IDA.

Anyway, once you understand what different chunks of instructions are doing, then you can decide how you want to alter the program. You can use a hex editor for the actual editing (I assume professionals use something different, but some game modders use hex editors), which simply lets you change the individual bits on your drive (if this sounds impressive, realize that every time you save a file or something, that's what's going on at a large scale).

If you want a gentle, newbie-friendly introduction to CPUs which will make a lot of this stuff click better, I highly recommend the NAND to Tetris course, which has a video series on Coursera: https://www.coursera.org/learn/build-a-computer

Assembly is just shell code that hasn't been commented. If you know how to write assembly, you can change it. Also, it is possible the authors of this software have the source for Petya, and modified it there (easier). From what people who have taken the time to reverse engineer this code claim, NotPetya is a wrapper. The modified Petya code is stored in a buffer and is then called when it's time to encrypt the filesystem.

To get started reverse engineering, modifying binaries, linking, etc. you need to start with learning x86_64 assembly. There are some pretty good courses and tutorials online. Since there are only a few opcodes that are used frequently, it might help to search for "reverse engineering bomb lab" and go from there. Here is the first search result, maybe it is good, maybe not: http://zpalexander.com/binary-bomb-lab-phase-1/

I don't find your quote in the original article, where is binary editing mentioned?

At any rate in general it just means that the binary version is directly modified instead of, say, modifying the source and recompiling it. When the source is not available you don't really have a choice.

It doesn't mean however that you'll just open a big binary dump of the program in emacs and start flipping bits manually. In general you'll first disassemble the code to figure out what it does, isolate the part that you want to modify, implement the modification and then you end up with a binary patch.

That's easier said than done though, reverse engineering a complex binary is very time consuming.

It reminded me of this anecdote: https://en.wikipedia.org/wiki/Wing_Commander_%28video_game%2...

>As development for Wing Commander came to a close, the EMM386 memory manager the game used would give an exception when the user exited the game. It would print out a message similar to "EMM386 Memory manager error..." with additional information. The team could not isolate and fix the error and they needed to ship it as soon as possible. As a work-around, one of the game's programmers, Ken Demarest III, hex-edited the memory manager so it displayed a different message. Instead of the error message, it printed "Thank you for playing Wing Commander."

Thanks for a great reply! Binary edited is written on the white board from the picture in the article.

>reverse engineering a complex binary is very time consuming.

And still ppl who crack games do it very often. They start with a obfuscated binary, decrypt it and patch it to remove the protection.

That's not full reverse engineering. They're removing the protection, with a clearly defined goal they can look at to see if they're done, and that's all.

Very different from trying to figure out everything a program does.

In the case of peyta: is that necessary? There are 2 pieces I know of someone would want to change, the Bitcoin wallet and removing the Killswitch.

Surely this is easier then a full understanding of the code?

Depends on the amount of editing required.

It can something as simple as changing several bytes using a hex/bin editor or something more involved like disassembling the binary, patching the assembly and then assembling it back.

A binary file on disk is just a file, like any other file, and you may read and hex-dump it, like any other. (Probably, your text editor has this built in.) And, of course, you may alter a file, either by overwriting part of it (using open, seek, write, close) or writing a modified version of it back to disk.

If we open a file in a hex-editor, we may locate an embedded string, like this:

0180: 54 68 69 73 20 69 73 20 61 20 73 74 72 69 6E 67 00 This is a string.

Now we may obviously change some of the string, and even shorten it, by filling the rest by zero-bytes:

0180: 54 68 69 73 20 69 73 20 61 20 70 65 74 00 00 00 00 This is a pet....

The interesting thing about this is that we may change the content, but have to maintain the original length and order of the code, else the binary won't work any more. I guess, padding, like this, is what gives the editing away -- at least at the level of arguments and embedded data. (However, if there were some hash signatures checked by the runtime, we will run into some trouble with our edit.)

Just the same, we may edit any instruction code. Let's say, your hex-editor has a built-in disassembler module, displaying mnemonics next to the byte code, just like the ASCII text in the string example. Even while some of the code may be encrypted, there must be some top-level code which isn't, and we should be able to discern this from any obfuscated code. Now, say, we want to skip a call to a subroutine or module, by overwriting the call instruction by a few bytes representing a jump instruction to skip ahead. Notably, again, we'll have to maintain the overall length and byte order, leaving behind some unused bytes as a signature of this being edited code.

Historical note: Classic MacOS (up to System 9) used a separate resource fork for any content embedded in files and executables. There was also a free tool by Apple, ResEdit, for displaying and editing the various resources and so-called res-hacks were not uncommon. (E.g., you may have accessed the resource providing the label for a menu item and replace it by your own, etc. This worked generally great with most of the programs, while some rather expensive software obviously applied some checks, prohibiting edited versions from working.) There was also a disassembler module for ResEdit, allowing code edits like described above.

Re: ResEdit - EXE files also have resource records, there's even a tool by the same name for Windows :)

The reason they are having this discussion is for the purposes of attribution or blame. The point was whether notPetya had been recompiled from source i.e. it was Janus or his source was stolen/bought or they had a sample of the ransomware binary (too easy to get unfortunately) and had tweaked it using an editor. Malware also employs 'shellcode' - low level code which can be inserted into a return point in a running process to branch and open a shell (usually) and do something like creating a reverse shell to an attackers' machine or wiping your hard drive. In theory you could use a tested one like petya and change the payload to do something else. You are correct it is daunting - it is rockhard - you can't just hack away at the image and shellcode is often much more complex than plain old assembly as it needs to be obfuscated and tries to avoid using null bytes.

>When I read stuff like "Petya (binary edited)" I feel like a complete noob

There's probably a way to try it with tools you already know. Know vim for example?

  cp /bin/grep ./mygrep
  vim -b ./mygrep
   [find a string to change, like something from the output of ./mygrep -V]
   [don't change the length]
   [change a few letters]
  <esc>: %s/Free Software/Tree Software/g
   [save it]
  :wq!
   [run it]
  ./mygrep -V

Changing things that aren't strings just requires a little research into the file format. A linux executable, for example, would usually be in the ELF format. Knowing that, you could, for example, coerce a linux binary to load a shared library from a different directory or name. Or research x86 opcodes and change some operation to a NOP...though a hex editor might be easier than vim -b.

Interesting! Thanks a lot :)

One really cool reading about reverse engineering obfuscated binaries and protocols, getting around anti-debugger code, etc is this talk from Blackhat about reverse-engineering Skype:

https://www.blackhat.com/presentations/bh-europe-06/bh-eu-06...

Gives pretty good insight into what steps go into this kind of work.

I gave a high-level intro to a lot of popular reverse engineering tools that you might find helpful (in the context of reverse engineering iOS apps): https://news.realm.io/news/conrad-kramer-reverse-engineering...

Honestly, quite a poor write-up. Bold claims in the beginning, but then too many meaningless words and too little technical details.

Yes ... there's no content here so don't waste your time reading it.

The followup has arrived: https://labsblog.f-secure.com/2017/06/30/eternal-petya-from-...

Same lack of facts as the first article but with new and improved speculation.

Speculation is all there is to this incident. Would you rather have them pose speculation as facts like many other vendors are doing?

Yeah, well. If all you're willing to accept is facts then this is the wrong area of inquiry for you. As if the NSA periodically releases a fact sheet of what they've been up to lately.

...and some thoughts on the matter by another lab member: https://labsblog.f-secure.com/2017/06/30/what-good-is-a-not-...

> There’s only two choices to communicate with your customers/victims: use email or create a service portal.

What about "have them publish a specially crafted transaction in Bitcoin blockchain using provided software"?

Followup: https://labsblog.f-secure.com/2017/06/30/eternal-petya-from-...

Interesting, thanks, but still more questions than answers and a somewhat condescending or at the opposite (as some other HN readers noted previously) somewhat "high school" trying to put together something that the teacher would approve, "Here we establish ..." ?.

"It has a vendetta against Kaspersky Lab. If this malware finds running Kaspersky processes on the system, it writes junk to the first 10 sectors of the disk, and then reboots, bricking the machine completely."

lol

This is the part I don't understand at all - why Kaspersky?

Should this really be a nation-state actor's malware, it may be a dig at Russia because Kaspersky is a Russian company.

That is almost certainly an incorrect analysis

Or it could be the US that wants you to believe it's Russia. Or any other nation, organization or group that wants to frame Russia.

Without any evidence, it's nothing but pure speculation and rumor-mongering.

If we assume Kaspersky is highly popular in Russia it might have been a way to avoid spreading the malware inside Russia (while keeping the behaviour non-obvious). jaclaz notes in another comment that it is easy to recover from this "vendetta".

While it may be a reasonable conclusion, such assumptions aren't supported by some rudimentary survey evidence, as per AV-Comparatives.org [1]

The Kaspersky condition in Petya is indeed unusual, but I would agree with the initial blog post that right now there isn't enough information to make even an educated guess. Kaspersky isn't just popular in Russia, it's consistently a top 3 world-wide, both for individual users and for businesses.

While I appreciate and even sometimes enjoy speculation such as this for fun, I agree with the F-Secure blog post that it is not useful in the current situation as there just isn't enough evidence to develop anything more than wild guesses.

[1] https://www.av-comparatives.org/wp-content/uploads/2017/01/s...

"Kaspersky isn't just popular in Russia, it's consistently a top 3 world-wide, both for individual users and for businesses."

But it is also banned in Ukraine, where most targets were.

And I'd assume the reason it's is banned in Ukraine is likely due to the persistant rumors that Kaspersky is tied to the Russian FSB.

Anti-virus would be a brilliant way to gain access to millions of machines, send back "sample" files via specific user targeted updates...

If so (and again I'm starting this sentence with IF), being lenient on Kaspersky would have dual benefits of focusing the target Ukraine, provide a "cure" for any critical machines hit in Russia, and allow existing Kaspersky users to recover once the cure is known.

The Interesting thing here is if this was a trial run, I don't think you get another one. If there is another bit of malware that treads lightly on Kaspersky machines, or "accidentally" fails to activate on them then the gig is up.

Still speculation, but will be interesting to follow.

Problem: user files are still being encrypted regardless of what happens to MBR so you end up doing MBR recovery only to boot a system without your data.

No, the Kaspersky check is done before encrypting any files.

Source: https://blogs.technet.microsoft.com/mmpc/2017/06/29/windows-...

It seems checks are done early but MBR destruction only at the end:

During malware initialization phase, this malware maintains a global variable that dictates its behavior. It alters its behavior based on the presence of processes related to certain antivirus applications running in the system.

Specifically, it looks for names of processes belonging to Kaspersky Antivirus and Symantec Antivirus and alters its behavior if it finds them.

Information controlling threats behavior is stored in a global variable (gConfig in the screenshots), which is then used to check during MBR modification.

If Kaspersky Antivirus process is found in the system or if the MBR infection is unsuccessful, the malware then proceeds to destroy the first 10 sectors of the hard drive.

To me it doesn't sound much as a vendetta.

Basically - if I get right the note - if you have some Kaspersky Lab software running the malware ONLY writes junk to the first 10 sectors and reboots, which basically means:

1) on MBR rebuild the MBR partitiontable entries from the existing (untouched) partition/volumes on disk

2) on GPT restore the partition table from the backup

Both are perfectly doable to restore the system in a full working condition.

It sounds more like a sort of (indirect) "vaccine", instead of getting a deadly influence, you get just a cold, a couple of aspirins and all is well (and the malware cannot spread from that machine to other machines on the network, since it rebooted to the junk and the OS is not running anymore).

As I read it, first there's user-mode encryption in every case. Then, admin-mode is attempted, and, when successful, either the first 10 sectors including the MBR are overwritten by garbage, in case Kapersky software was found, or there's a botched attempt to encrypt the first 25 disk sectors. Mind that user-mode and admin-mode tasks are apparently in separate modules and that the user-mode module is run first, while detecting the Kapersky lab process and overwriting the disk sectors requires admin mode.

To me, the "Kapersky branch" appears to be more destructive than the default branch.

Edit: Also, there have been reports of the malware scanning and transmitting any credentials stored on the machine, while in "encrypted mode." (Suggesting, there's still a functional basic system left in order to accomplish these tasks.) Couldn't it be for Kapersky AV still being able to detect this activity and hence rather bricking the machine than giving away some of the features early?

Certainly more destructive for the 99.9% of owners who don't know what MBR or GPT is.

x2. Someone on the team probably had beef with Kaspersky and decided to hose the partition table of anyone using it. Hosing the partition table is a pretty poor way of minimizing damage because as you point out, 99.9% of people affected will be more affected if the partition table is hosed.

I don't get it, really, IF data can be recovered through a procedure (that BTW is not particularly difficult or new, even if the owners don't know what a MBR or a GPT is, any technician can recover a disk where only the first 10 sectors were filled with junk) the procedure is NOT destructive at all while encrypted files, particularly if encrypted with a "good enough" and "random" key are not recoverable at all.

Of course it may provoke delays/problems/whatever, but data is still there.

If the sequence is:

1) encrypt user files

2) get admin access and crypt MBR (in such a way that is not decryptable)

3) reboot

the "destructive part" is #1, the MBR can be rebuilt from scratch just fine (and possibly if the reboot is somehow prevented the encryption key may be recovered from RAM as it happened in some cases for Wannacry, in which case it is #3 that creates more damage).

The doubt is when the "Kaspersky vendetta happens", if it goes:

1) encrypt user files

2) get admin access and crypt MBR and 24 more sectors(in such a way that is not decryptable) OR check the presence of Kaspersky and write junk to first 10 sectors of disk

3) reboot

It doesn't anyway change anything, there is no real difference between rebuilding a MBR (or GPT) because it was crypted and rebuilding it because it was overwritten by junk data, but once you have rebuilt it, if the files are encrypted you have lost them all the same.

Or they just want people to turn off their Kapersky AV so as not to risk having their machine bricked.

Looking at MS analysis here: https://blogs.technet.microsoft.com/mmpc/2017/06/27/new-rans... https://blogs.technet.microsoft.com/mmpc/2017/06/29/windows-...

It seems confirmed that if the Kaspersky files are detected, only first 10 sectors of PhysicalDrive0 are overwritten, and NO encryption of the $MFT is performed, so the system is recoverable:

>Case 2: If system is non-UEFI, installed with Kaspersky Antivirus, and in a state where boot completely fails

>The ransomware attempts to destroy the first 10 sectors of the \\\\.\\PhysicalDrive0 if Kaspersky Antivirus is found or if the MBR infection is unsuccessful. Thus, boot process hijack through malicious MBR hasn’t been completed so the MFT (Master File table) contents are intact and not encrypted by the threat. In this case, the partition table information is destroyed by the threat. Given that it stores critical information needed in the booting process, a traditional boot repair process may not work. Rebuilding the partition table may require consultation with an expert.

So the "Kaspersky branch" is much less destructive than the "normal" branch.

Now, the process as described in the MS analysis differs from the description provided by F-Secure.

MS: "[W]hen the malicious MBR starts, it loads additional code from sectors after the MBR, which in turn proceeds to encrypt the Master File Table (MFT). After the encryption process is complete, the user is presented with the following ransom message, which is different from the typical ASCII skull and crossbones shown by the original Petya"

(This suggest that first the MBR is overwritten conditionally and that the encryption happens on a reboot in this modified MBR.)

The F-Secure blog, on the other hand, suggests [edit: at least in my reading] that there's first a process running in user-mode doing the file encryption, followed by another step, in admin mode, attempting to modify the first disk sectors (including the MBR).

To me, the two sources (MS and F-Secure) are contradictory.

Edit: Can it be that the MS analysis is about the "double infection" of an already compromised machine, as described in the F-Secure blog? (Different teams may start at different points with their analysis. As the analysis proceeds, the patterns found by the various teams may merge into a single representation of the workings of the malware.)

I don't see as "contradicting", more like "still not fully defined".

1)The thingy runs and encrypts "in user mode" only a given set of file types (per list of extensions).

2)Then it tries to get "admin mode" and write to the MBR (and following sectors) some code capable on reboot to encrypt the $MFT BUT

3)at some point it checks if either a Symantec (if found does something that is irrelevant to the encryption) or a Kaspersky file/service if running, and if the Kaspersky file is found only overwrites MBR+9 sectors with "junk" that prevents from booting again the OS.

So, independently from step 1 (which in itself only affects some data), step 2 is "totally destructive", whilst the effects of step 3 are easily fixable and - once fixed - will allow normal access to files (either encrypted or non encrypted).

It does sound "strange" because the same kind of access is needed to write directly to the MBR and a few following "hidden" sectors no matter if you are writing highly sophisticated boot and encryption code or just junk, so - at face value - it seems exactly the contrary of what is the interpretation on F-Secure website, as those running a Kaspersky will have LESS damage.

This is a truly excellent point given that Kaspersky Labs are called FSB asset. Maybe this was the attacker letting people off. Putin said that actions are by patriotic freelancers (hack elections etc). I did not think anPetya was officially sanctioned/orchestrated until Rosneft statement sounding like some lary Soviet-era propaganda. But who has windows media lying around these days? And who cares if it is only being tasked by Putin tacitly? This is what non-linear war looks like.

btw frodobaggins not frodobegins

I'm pretty much a total novice with low-level aspects of storage, but if this is essentially writing junk to the windows bootloader or something to preveny booting to OS, couldn't one just plug the HDD as a non-ROOT drive to another PC and recover some of the important files?

I've seen people successfullu do this before after their super old ROOT disk gets corrupted exactly where the windows bootloader is...

No, that wouldn't work; you'd have to scan the disk for partition information to reconstruct it, or otherwise guess reasonable values (backup being best).

Which does not seem like a particularly difficult task for me. Not quite trivial, not particularly quick, not guaranteed to work 100%, but for main partition types the task should be suitable as an undergraduate CS assignment.

However, as you say, having data backed up is a better solution.

Two cases:

1) MBR "style" partitioning:

in first sector of the disk there are at most 4 addresses pointing to the partitions on the disk (which may consist of primary partitions and as such volumes, or one of them may point to an extended partition that has a chain of EMBR's pointing to logical voluems inside it) It is trivial nowadays, using freely available software, to search the disk for the volumes and rebuild the partition tabel in the MBR.

2) GPT disk:

The first sector is only a "protective MBR" where in the partition table there is only one entry spanning from sector 2 up to the end of the disk (this can of course be rebuilt in no time). The issue is that the GPT partition table (i.e. addresses of the volumes) is in the following sectors (and the overwriting of 24 or 9 sectors will destroy the data for good, as normally only two sectors are used) and due to the peculiariries of the way these GPT entries are stored it is slightly more difficult to rebuild the data (though the actual volumes on disk can anyway be found and retrieved/imaged).

But - IMHO more or less the only good thing about GPT - the MBR and all GPT tables are automatically backed up to the end of the disk, so there is usually no need to rebuild anything, it is just a matter to properly restore the entries from the backup.

Since when does writing over the MBR brick the machine? Has the term "bricking" lost its original meaning?

If the device isn't only useful as a brick afterwards, it's not bricking. Requiring reformatting or replacing a hard drive is hardly enough to do that in most circumstances.

This post really reads like high school students trying to write something that looks professional...

I hope this field doesn't get too poluted by people looking for a thrill. The stakes start to be too high for that.

I can't believe this was published. It reads like someone attempting to mock a high school student who tries to write something professional.

I find all of this absolutely hilarious. "this is not nation state because it is written in a shoddy way" is akin to "he does not look like a spy because he's too stupid." Get out. Attribution is almost impossible so don't even try.

"It's sometimes the height of wisdom to feign stupidity.” -Cato 149 B.C. (that's right, people knew about this simple trick before Jesus was born, you bet humanity has refined on it since)

Attribution is not 'almost impossible', it just takes human intelligence sources, and not technology, to get an accurate attribution. And due to the nature of those sources, those who get the actual attribution won't disclose it.

Exactly. This is like the people who said it was impossible to attribute the DNC email hack. Then they attributed it via classic human intelligence sources.

We forget there's more to attribution than what can be determined from the bits.

> there’s evidence that development on the network propagation component was completed in February.

Yet no evidence is provided. Why would they want to hide it?

They just added another update:

"Some of the payloads utilized by the network propagation component have compilation timestamps from February 2017. The compilation dates on these payloads don’t have any bearing on when the Eternal* exploits were implemented in the network propagation code."

https://twitter.com/FSLabs/status/880688502769414144

Reply on news.ycombinator.com