DAN GOODIN - 6/28/2017, 4:30 PM
Enlarge / Code in Tuesday's attack, shown on the left, was altered to permanently destroy data.
Matt Suiche
O surto maciço de malware de terça-feira que desligou computadores em todo o mundo foi quase universalmente atribuído ao Ransomware, que, por definição, busca ganhar dinheiro ao desbloquear dados mantidos sobre proteção somente se as vítimas paguerem uma taxa considerável. Agora, alguns pesquisadores estão elaborando uma avaliação ainda mais sombria - que o malware era um triturador de papel com o objetivo de destruir dados permanentemente.
LEITURA ADICIONAL
Um novo surto de ransomware semelhante ao WCry está desligando computadores em todo o mundo
Inicialmente, os pesquisadores disseram que o malware era uma nova versão do Ransomware Petya que atingiu a primeira vez no início de 2016. Mais tarde, os pesquisadores disseram que era um pacote novo e nunca visto de ransomware que imitava alguns dos comportamentos de Petya. Com mais tempo para analisar o malware, pesquisadores na quarta-feira estão destacando algum comportamento curioso para um malware que foi quase perfeito em quase todos os outros aspectos: seu código é tão agressivo que é impossível para as vítimas recuperarem seus dados.
Em outras palavras, disseram os pesquisadores, a carga fornecida no surto de terça-feira não era ransomware. Em vez disso, seu verdadeiro objetivo era limpar permanentemente os discos rígidos quanto possível em redes infectadas, da mesma forma que o limpador de disco Shamoon deixou uma destruição na Arábia Saudita. Alguns pesquisadores disseram que Shamoon é provavelmente o trabalho de desenvolvedores patrocinados por um país ainda não identificado. Os pesquisadores que analisam o malware de terça-feira, como PetyaWrap, NotPetya e ExPetr, estão especulando que a nota de resgate deixada atrás no ataque de terça-feira era, de fato, um engano destinado a capitalizar o interesse da mídia provocada pelo surto maciço do mês passado.
Tuesday's massive outbreak of malware that shut down computers around the world has been almost universally blamed on ransomware, which by definition seeks to make money by unlocking data held hostage only if victims pay a hefty fee. Now, some researchers are drawing an even bleaker assessment—that the malware was a wiper with the objective of permanently destroying data.
FURTHER READING
A new ransomware outbreak similar to WCry is shutting down computers worldwide
Initially, researchers said the malware was a new version of the Petya ransomware that first struck in early 2016. Later, researchers said it was a new, never-before-seen ransomware package that mimicked some of Petya's behaviors. With more time to analyze the malware, researchers on Wednesday are highlighting some curious behavior for a piece of malware that was nearly perfect in almost all other respects: its code is so aggressive that it's impossible for victims to recover their data.
In other words, the researchers said, the payload delivered in Tuesday's outbreak wasn't ransomware at all. Instead, its true objective was to permanently wipe as many hard drives as possible on infected networks, in much the way the Shamoon disk wiper left a wake of destruction in Saudi Arabia. Some researchers have said Shamoon is likely the work of developers sponsored by an as-yet unidentified country. Researchers analyzing Tuesday's malware—alternatively dubbed PetyaWrap, NotPetya, and ExPetr—are speculating the ransom note left behind in Tuesday's attack was, in fact, a hoax intended to capitalize on media interest sparked by last month's massive WCry outbreak.
Researchers at antivirus provider Kaspersky Lab, in a blog post published Wednesday, labeled the previous day's malware a "wiper." They explained that for attackers to decrypt a paying victim's computer, they need a "personal infection ID" that's displayed in the ransom note. In the 2016 version of Petya, the ID contained crucial information for the key recovery. Tuesday's malware, by contrast, was generated using pseudorandom data that was unrelated to the corresponding key. Kaspersky Lab researchers Anton Ivanov and Orkhan Mamedov wrote:
If we compare this randomly generated data and the final installation ID shown in the first screen, they are the same. In a normal setup, this string should contain encrypted information that will be used to restore the decryption key. For ExPetr, the ID shown in the ransom screen is just plain random data.
That means that the attacker cannot extract any decryption information from such a randomly generated string displayed on the victim, and as a result, the victims will not be able to decrypt any of the encrypted disks using the installation ID.
What does it mean? Well, first of all, this is the worst-case news for the victims – even if they pay the ransom they will not get their data back. Secondly, this reinforces the theory that the main goal of the ExPetr attack was not financially motivated, but destructive.
In an e-mail, they stated the problem this way:
Our analysis indicates there is little hope for victims to recover their data. We have analyzed the high-level code of the encryption routine, and we have figured out that, after disk encryption, the threat actor could not decrypt victims' disks. To decrypt a victim's disk, threat actors need the installation ID. In previous versions of "similar" ransomware like Petya/Mischa/GoldenEye, this installation ID contained the information necessary for key recovery. ExPetr does not have that, which means that the threat actor could not extract the necessary information needed for decryption. In short, victims could not recover their data.
Researcher Matt Suiche of Comae Technologies, in his own blog post published Wednesday, also called Tuesday's malware a wiper. But rather than focus on the pseudo-randomly generated installation ID, he highlighted the overwriting of key files stored on the infected hard drive.
"The ransomware was a lure for the media," he wrote. "This version of Petya actually wipes the first sectors of the disk like we have seen with malware such as Shamoon." He went on to write: "We believe the ransomware was, in fact, a lure to control the media narrative, especially after the WannaCry incidents, to attract the attention of some mysterious hacker group rather than a national state attacker like we have seen in the past in cases that involved wipers such as Shamoon."
Suiche provided the above side-by-side code comparison contrasting Tuesday's payload with a Petya version from last year. Both pieces of code take aim at two small files—the master boot record and master file table—that are so crucial that a disk won't function if they are missing or corrupted. But while the earlier Petya encrypts the master boot record and saves the value for later decryption, Tuesday's payload, by contrast, was rewritten to overwrite the master boot record. This means that, even if victims obtain the decryption key, restoring their infected disks is impossible.
"Petya 2016 modifies the disk in a way where it can actually revert its modification," Suiche told Ars. "Whereas yesterday's one does some permanent damage to the disk."
Asked if the recovery made possible by Petya 2016 was related to the master boot record tampering, Suiche pointed to this analysis of the ransomware from researchers at Check Point Software. It described three stages:
Stage 0 “MBR Overwrite” – Overwrite the hard drive's Master Boot Record and implanting custom boot-loader.
Stage 1 “MFT Encryption” – Use the custom boot-loader introduced in Stage 0 to encrypt all Master-File-Table (MFT) records, which renders the file system completely unreadable.
Stage 2 “Ransom Demand” – Display the Petya logo and the ransom note detailing what must be done to decrypt the hard-drive.
"Both these values will be used further in the encryption process performed at Stage 1," Suiche told Ars. "At this point, Petya encrypts the original MBR by XORing its content with 0x37. It then saves this encrypted value to the 56th Disk Sector. Petya continues to encrypt disk sectors 1-34 (the physical range is 0x200h-0x4400h) with the exact same method."
Tuesday's malware, by contrast, destroys the 25 first sector blocks of the disk. In Wednesday's blog post, Suiche wrote:
The first sector block is being reversibly encoded by XORed with the 0x7 key and saved later in the 34th block. But since it replaces it with a new bootloader (41f75e5f527a3307b246cadf344d2e07f50508cf75c9c2ef8dc3bae763d18ccf) of 0x22B1 bytes it basically sets v19 to 0x19 (25).
16.0: kd:x86> ? 0x22B1 - (0x22B1 & 0x1FF) + 0x1024
Evaluate expression: 12836 = 00003224
16.0: kd:x86> ? 0x00003224 >> 9
Evaluate expression: 25 = 00000019
That would mean that 24 sector blocks following the first sector block are being purposely overwritten, they are not read or saved anywhere. Whereas the original 2016 Petya version correctly reads each sector block and reversibly encode them.
Definitely not designed to make money
Another researcher who uses the handle the grugq published an analysis that also supported the theory that Tuesday's outbreak wasn't a true ransomware attack. The analysis noted that the malware used a single Bitcoin address to receive ransom payments, a shortcoming that's not found in most professionally developed ransomware because it requires attackers to manually process large numbers of payments. Tuesday's malware also required victims to manually type a long string of human-unfriendly characters into an e-mail address, a hurdle professional ransomware developers avoid because it decreases the likelihood that victims will pay. Tuesday's malware also required victims to contact attackers through an e-mail account that was closed within hours of Tuesday's outbreak, killing any incentive for victims to pay.
In almost all other aspects, Tuesday's malware was impressive. It used two exploits developed by and later stolen from the National Security Agency. It combined those exploits with custom code that stole network credentials so the malware could infect fully patched Windows computers. And it was seeded by compromising the update mechanism for M.E.Doc, a tax-filing application that is almost mandatory for companies that do business in Ukraine. The shortcomings in the ransomware functions aren't likely to be mistakes, considering the overall quality of the malware.
"The superficial resemblance to Petya is only skin deep," the grugq wrote. "Although there is significant code sharing, the real Petya was a criminal enterprise for making money. This is definitely not designed to make money. This is designed to spread fast and cause damage, with a plausibly deniable cover of 'ransomware.'"
The theories are consistent with this post from Wired, which reports that Ukrainian government officials are saying Tuesday's attack was sponsored by a national government. The Ukrainian government has previously blamed Russia for attacks—one in December 2015 and another in December 2016—that both caused blackouts by hacking Ukrainian power facilities. A cover story Wired published last week lays out much of the evidence substantiating the claims of Russian involvement. Asked if Russia was behind Tuesday's attack, a government official told reporter Andy Greenberg: "It’s difficult to imagine anyone else would want to do this."
This post was updated to add details starting in the seventh paragraph, on how the permanent data destruction occurs. It was also edited to remove references to permanent hard drive destruction until those claims can be explicitly confirmed.
Promoted Comments
charliekilian Smack-Fu Master, in training
JUMP TO POST
After thinking about it for awhile, I don't understand what they were thinking when they made the keygen just use random numbers. If they've gone to all the trouble to make it look like ransomware, why not go the extra few steps and do whatever normal ransomware does to be able to recover the encryption key? They had to know it'd be analyzed, because all malware is. If the purpose of making it look like ransomware is to control the narrative and get ransomware hackers blamed for the attack, then why make it so obvious the key isn't recoverable?
A better way to do this would be to go ahead and write the key recovery code (which is already available from lots of other ransomware anyway) and then just not respond to requests for decryption. An even better way would be to place an "accidental" coding error into the key recovery -- something that makes it impossible to actually recover the key, but that looks like it the hacking group was at least attempting to recover it -- so everyone would assume it was a ransomware group that just messed up and can't recover any of the keys.
What is the point of going to pains to make it look like ransomware, only to make it obvious that it isn't? Are they trying to signal to some groups that it is an intentional attack, while obscuring that fact from the larger public?
13 posts | registered 6/2/2016
DAN GOODIN
Dan is the Security Editor at Ars Technica, which he joined in 2012 after working for The Register, the Associated Press, Bloomberg News, and other publications.
EMAIL dan.goodin@arstechnica.com // TWITTER @dangoodin001
No comments:
Post a Comment