Everything you need to know about the Petya, er, NotPetya nasty trashing PCs worldwide It is now increasingly clear that the global outbreak of a file-scrambling software nasty targeting Microsoft Windows PCs was designed not to line the pockets of criminals, but spread merry mayhem. The malware, dubbed NotPetya because it masquerades as the Petya ransomware, exploded across the world on Tuesday, taking out …
@patrickstar
Cached credentials are presumably in the Kernel or at least another processes memory.
In VMS, pa-risc HPUX and Sparc Solaris, user processes can't read the memory space of other user processes, and certainly not Kernel memory (not unless you are superuser). So no - kerberos doesn't have the same problem on *ix.
I've been trying to google for an answer, what I found is vague - so I'll assume you are right- Linux and Windows both suffer from this malady of allowing any process free reign of reading all the memory space. So yes - kerberos on LINUX would have the same problem. There is a whole other thread in these comments about whether Linux is any better than windows or not.
But if you know that OS allows your memory to be read, then you should code with that in mind - there is no need to keep the password itself in memory - you can hash it with a low collision hash. Or at least only keep the password in memory during the actual password compare and then zero the memory out.
Atleast MIT and Heimdal kerberos store the credentials in a file in /tmp...
In Windows, they are stored in the LSASS process. I don't know where you think they are stored or how accessible they are, but at the very least you need an administrative account with SeDebugPrivilege.
I don't have Kerberos on any of my Solaris boxes, but even if they are actually stored in kernel memory in the native Solaris implementation as opposed to a userspace process or file, none of these systems have a great track record of keeping attackers out of the kernel, especially when they have administrative privileges. And certainly none of them have a great track record of keeping attackers from gaining that.
That's why you have the whole Credential Guard thing - so that even if the kernel is compromised you can't read them out without also compromising the minimal virtual system holding the creds.
There is no difference between the ability of processes to read memory space on Linux, Solaris, Windows or any of the other systems, by the way. They all use the same basic VM/memory protection model.
And you can't hash the credentials and still have them usable as a cache. The whole point of a cache is to be able to re-use them. At most you could encrypt them with a key that's harder to access than the credentials itself, which is basically what Credential Guard is doing (though a better solution would be a HSM/TPM enforcing rules for when they can be used).
PS. How can someone downvote a post containing nothing but statements of fact? If any of the facts are wrong I recommend that you post a reply explaining so instead, for the benefit of all.
Come on Patrick, this is El Reg! It's completely unreasonable to expect someone to explain a downvote, especially a lot of them!
And you're supposed to downvote people for asking about them as well. But I'll do something completely forbidden here and give you an upvote before the first downvote gets here!
@patrickstar
I haven't seen anyone mention that NotPetya requires Admin privileges in order to get the admin credentials from memory. I'm sure I've read quite the opposite - admin privs are NOT required. My bit of googling gave similar results for Linux (but I'm no expert there - I'm just agreeing with what other posts here have said - Linux has the same deficiency).
I have seen a little suggestion it's related to the ability to run gdb on linux (which I think all users can), and the SYSTEM account in Windows (not the SeDebugPrivilege priv), i.e.: via "psexec -s", via post exploitation tools, scheduled tasks, etc - see the mimikatz doco for details.
So all my comments are based on the assumption that NotPetya doesn't require admin privs to read the memory where the credentials are - so from my POV there is a quite fundamental difference in memory space security on Linux/Windows compared with to Solaris/HPUX/OS400 etc.
@thored
The GPO setting “Interactive logon: number of previous logons to cache (in case domain controller is not available)” controls the caching of logins to the HKEY_LOCAL_MACHINE\Security\Cache registry key, not to the LSASS memory AFIACT. Surely if there was a GPO setting to mitigate this the article would have mentioned that in addition to CredentialGuard. No - I think the point of the article (and @ patrickstar's comments too) are that on Windows that CredentialGuard is the only feasible mitigation.
I've not seen anyone else suggest a way to shut down WMI command line access either - so I assume it's a bust too.
Cached credentials in windows are held in the lsass.exe process. However, there is a group policy setting that turns off credential caching.
The side effect is that any machine that cannot contact a domain controller will be unable to log anyone on to a domain account (because credentials are not cached, the machine has to contact the domain controller for every login).
This should not be an issue for servers in the core or static workstations. It should not be enabled on laptops that are used for remote access.
The article states:
"since the malware writers must have known that the email address would be shut down quickly, which cut off access to funds".
That's not true at all. BitCoin doesn't use email. The email was to tell the writers that you sent them a BitCoin so that in theory they'd email you back your decryption key. They can still receive the ransom even without access to the email account!
According to Cybereason.com (h**ps://www.cybereason.com/blog-petya-like-ransomware-attack-what-you-need-to-know/):
"It [NotPetya] kills itself prior to infection if the en_US keyboard layout is the only keyboard layout installed."
Hmmm... Better type white, you scums!
Not "Minicatz". It is a Windows Kerberos hacking tool.
Also, creating C:\Windows\perfc.dat may not be useful. According to McAfee (https://securingtomorrow.mcafee.com/mcafee-labs/new-variant-petya-ransomware-spreading-like-wildfire/) the file name can be different, and the victim's machine will reuse the same name as the source one, but the exact file name cannot be foreseen.
Since there is an "immunization" of having a file "perfc" with no extension in the "c:\windows\" directory, when we find a PC that has the perfc file on it that predates the initial infection, it can lead us to exactly who knew of it prior to deployment and lead us to the bad guys.
Who has the most to gain from this? USA. Their politicians, are to blame because they follow the military establishment without question. The military establishment is to blame for creating these exploits and not informing companies of the security flaws in products. Lastly the end user or company are to blame for not having an offsite or disconnected backup. Backup, backup. I have spent years telling clients that they need backup systems and i still lots who arent willing to spend they money. Some just have to learn the hard way.
In case someone has missed it (and I can't find a Reg article mentioning it, but that might just be me being a retarded starfish as usual) - apparently this "NotPetya" is not ransomware: https://securelist.com/expetrpetyanotpetya-is-a-wiper-not-ransomware/78902/
It simply isn't possible for anyone, including the attacker, to decrypt the data.
You are correct.
The initial analysis was that the entity behind the attack made a mistake by using a conventional email and a single bitcoin wallet.
Posteo, disabled the email account within a few hours of the attack happening and victims were still sending ransom emails to the address in the hopes of getting their data back.
As it turns out, the "Personal Installation Key" generated by the malware was just a random string of characters unrelated to the encryption key used to encrypt the data, making it useless for retrieving the files. The hackers couldn't give back the files if they wanted to. So, there are victims out there that paid about $10,000 collectively with no hope of getting their data back.
It's somewhat weird that they didn't implement all functionality needed for ransomware. They must have known that sooner or later, probably sooner, someone would realize that it's not possible for anyone to decrypt the data. Wouldn't exactly be a lot of extra work at that point.
Did they actually intend for this to be discovered after the initial chaos?
They did it intentionally. The act of encrypting the data requires the key so the key was available. They purposely displayed a completely ineffective string of characters as the victim's ID. Probably to play on the victim's sense of hope that they could get their data back.
The purpose of this software was just to brick Windows machines.
Some of the data can be recovered as the MBR was only partially wiped.
Also possible to use heuristics but takes 4-5 hours per machine, assuming that the drive is not particularly fragmented.
see http://blog.ptsecurity.com/2017/07/recovering-data-from-disk-encrypted-by.html
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
