As someone with very limited Microsoft/Windows background, I would be curious to somehow better understand how these lessons would apply to the Linux world.
What are the Linux equivalents of pass-the-hash, TAM/PAM/PAWs etc?
Maersk, Me and NotPetya
11–20 of 59 posts
Re: Maersk, Me and NotPetya
#12As someone with very limited Microsoft/Windows background, I would be curious to somehow better understand how these lessons would apply to the Linux world. What are the Linux equivalents of pass-the-hash, TAM/PAM/PAWs etc?
I'm guessing you know what a password hash is and roughly how password hashing works?
Microsoft's systems don't like to send your plaintext password over the network. Rather than either get rid of passwords or at least secure that so it isn't a problem any more, they do the hashing on your machine and send the hash to wherever it needs to be authenticated. This behaviour enables Pass-the-hash.
Since we can authenticate with the hash, not the password, we don't even need to know the password. If we break into one system that knows the password hash for JimSmith in order to authenticate JimSmith then we can tell other systems we're JimSmith and present that password hash and they'll accept it.
So malware that gets enough rights on a machine with a bunch of people's password hashes effectively gets the ability to log in as them on other machines, on which maybe it can ascend to equivalent rights and get more hashes, which it can use again, recursively.
Pass-the-hash isn't a thing on Linux itself, it's a consequence of crypto-illiterate design in Windows. Arguably that design pre-dates modern Windows, ie it isn't the fault of the people who built versions of Windows you use today. On the other hand though rather than just outlaw this behaviour entirely they've chosen to try to mitigate the worst effects and whose fault is that?
Re: Maersk, Me and NotPetya
#13As someone with very limited Microsoft/Windows background, I would be curious to somehow better understand how these lessons would apply to the Linux world. What are the Linux equivalents of pass-the-hash, TAM/PAM/PAWs etc?
They don't directly translate due to the inherent differences in between the two systems.
In short, pass-the-hash is a technique by which it is possible to authenticate to a windows system using the hash of a password, instead of the password itself. The NTLM hash is the secret, and does not need decrypting to authenticate.
NTLM authentication over the network can be redirected to other machines if they don't have traffic signing enabled (default only for domain controllers). So this gives rise to 'spreading' over the network in two ways:
* Steal the hash out memory of a system where you've got root access (called SYSTEM in windows terminology).
* Trick an administrator's system by connecting to your system somehow, and redirect the authentication to another system to take control. There are various techniques to do this, which I won't explain in this answer.
Given this known weakness, TAM/PAM/PAWs are all procedures/and a tiering architecture to prevent those secrets from being compromised.
A PAW, privileged access workstation, can be seen as an equivalent to a linux sysadmin's bastion host, roughly. It contains all private keys to all systems, but is well segmented, audited, and protected. This is the system that you use to perform administrative tasks that can't be done with any lower level of privilege. Say, the system that has the root account to all your production servers, for example.
PAM is the set the set of policies around logging when highly privileged accounts are used, which systems they can access with what privilege, etc, who can use them, how to approve actions by them, etc.
In short, they are the frameworks and policies used to combat the security weakness of these legacy protocol designs, and the reality of running big networks with guaranteed attacker activity in it.
Re: Maersk, Me and NotPetya
#14devops should be done from 2 systems.
Dev (local administrator access ok, production access not ok)
Ops (local admin access not ok, production access ok)
Re: Maersk, Me and NotPetya
#15I can fully recommend reading the book "Sandworm" by Andy Greenberg. It explains NotPetya and all of the sorrounding investigation.
In the same genre, I recommend "Countdown to Zero Day" which looks at Stuxnet and Flame and the events surrounding their creation, deployment and aftermath.
Just an aside, I have met Kim a few times at various conferences. She is an interesting person, in a good way. She came to the book as an infosec neophyte. We talked about her process as something of a technologist outsider and how she decided what to focus on. Ultimately, she decided the storytelling was far more important than the technical details, though she felt those were incredibly important as well.
Re: Maersk, Me and NotPetya
#16As someone with very limited Microsoft/Windows background, I would be curious to somehow better understand how these lessons would apply to the Linux world. What are the Linux equivalents of pass-the-hash, TAM/PAM/PAWs etc?
They don't directly translate due to the inherent differences in between the two systems. In short, pass-the-hash is a technique by which it is possible to authenticate to a windows system using the hash of a password, instead of the password itself. The NTLM hash is the secret, and does not need decrypting to authenticate. NTLM authentication over the network can be redirected to other machines if they don't have tr…
> It contains all private keys to all systems
Hopefully it doesn't? That would be poor design. It typically is just on a network segment that the firewall rules allow it to access the other servers.
Re: Maersk, Me and NotPetya
#17devops should be done from 2 systems. Dev (local administrator access ok, production access not ok) Ops (local admin access not ok, production access ok)
Nobody should directly have access to production, it should be controlled via CD flows which are gated on approvals from other team members or metrics.
Re: Maersk, Me and NotPetya
#18devops should be done from 2 systems. Dev (local administrator access ok, production access not ok) Ops (local admin access not ok, production access ok)
Nobody should directly have access to production, it should be controlled via CD flows which are gated on approvals from other team members or metrics.
I am with you on this.
Re: Maersk, Me and NotPetya
#19I can fully recommend reading the book "Sandworm" by Andy Greenberg. It explains NotPetya and all of the sorrounding investigation.
Fantastic book! I only wish there were more in depth books like this. I've read Countdown to zero day as well almost immediately afterwards and was similarly engaged.
Re: Maersk, Me and NotPetya
#20As someone with very limited Microsoft/Windows background, I would be curious to somehow better understand how these lessons would apply to the Linux world. What are the Linux equivalents of pass-the-hash, TAM/PAM/PAWs etc?
I'm guessing you know what a password hash is and roughly how password hashing works? Microsoft's systems don't like to send your plaintext password over the network. Rather than either get rid of passwords or at least secure that so it isn't a problem any more, they do the hashing on your machine and send the hash to wherever it needs to be authenticated. This behaviour enables Pass-the-hash. Since we can authentica…
> On the other hand though rather than just outlaw this behaviour entirely they've chosen to try to mitigate the worst effects and whose fault is that?
That's the fault of reality. Disable this today and big chunks of the world will just stop working. That's why they try to push to disable their stupid design mistakes of the past instead of just disabling them cold turkey.
Testing whether disabling a weak auth option won't hurt anything significant within your typical medium to large organization with 20 to 30 years of IT history is a timely operation and major pain.
Any mistake can be extremely costly - think about few hundred expensive employees, doctors, heavy equipment operators, whatever - sitting without their working tools for hours or days because of a stupid security checkbox.