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?
What are the Linux equivalents of pass-the-hash, TAM/PAM/PAWs etc?
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.
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.
So, although it does not literally house all passwords/keys/whatever to your network, it has access to a system that indirectly does.
Normal jump hosts should not have your private keys I guess, but I thought it was the closest analogy.
Just put it this way: if an attacker gets on that system, it's complete game over.
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?
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.
However, it can, at which point you're back to the same problem. The vulnerability is with the protocol, not the operating system.
Modern versions of Active Directory enable strong protections for Kerberos that almost entirely stops the majority of the Pass-the-Hash or the Golden Ticket attacks. However, this isn't on by default even in Windows Server 2019 running a domain in 2019 mode for "compatibility" reasons.
I put that in air quotes because it's an excuse, and this is where Microsoft has consistently dropped the ball. They refuse to change security defaults, even when it starts getting absurd, and then lay the responsibility (and blame) at the feet of their customers.
For example, domain trusts between two Windows Server 2019 DCs will use NT4-era RC4 ciphers by default, downgrading all AES-capable devices across the trust.
Similarly, newly created accounts will always default to RC4, allowing downgrade attacks.
SMB is neither signed, nor encrypted by default.
Up until very recently, Windows Server has TLS 1.1 and 1.2, but they were disabled. Now, they're enabled, but so is TLS 1.0!
So on, and so forth.
That's the real issue. It's not that Windows is "crypto illiterate". That's like a person who can't read. No, it's like a person that can read but refuses to.
They changed a lot of security defaults with Windows Vista and literally(figuratively) everybody dumped on them. It got called worst Windows ever, unusable, and names I don’t want to spell out from the public and the press. That made them reluctant to attempt such drastic measures again. But at least they disable SMBv1 by default nowadays.
My criticism is that they didn't implement the Vista-era crypto enough.
In 2020, most Microsoft software doesn't support ECC certificates because their server products are still written to use the 2000/XP/2003 era crypto APIs instead of the Vista and later crypto APIs.
I remind you that none of those operating systems are supported any longer, but apparently for "comptibility reasons" SQL Server 2019, AD FS 2019, and System Centre 2019 can't use elliptic certs. Or use TPM-hosted certs. Or anything at all really other than RSA 2048-bit certs stored in software.
IIS can, but that's the lone exception, not the rule.
Could you tell more why do you think so?
For what I remember, Linux in this regard is exactly the same as Windows: you have to install and configure Samba 4 or FreeIPA in order to get a kerberized domain; you also have to join the clients into domain exactly the same way you would join windows clients.
In Windows, your servers out of the box won't run the necessary services, you have to install the AD DS server role. You have to join the clients into domain.
So there's nothing like AD or Kerberos on Windows by default either.
In fact it has been given a CVE number and fixed in obscure systems where it was done, only Windows gets to shrug and say it's hard so we won't fix it. e.g. CVE-2005-3435
In Windows every user - anywhere in the world not just within one organisation - with the same password has the same hash. Worse than a PHP app from the turn of the century their most sophisticated password hash scheme is MD4(password). This makes the mistake that results in Pass-the-hash almost irresistible.
Because a Linux system uses salted (and pessimised) hashes, it is not tempting to try to authenticate remote hashes because you're going to have to build a multi-step protocol, passing parameters to the client so it can perform the hash. You'd probably instead look at existing protocols and discover SRP (or in the modern era any sensible asymmetric PAKE). This immediately shows you a better path forwards with no Pass-the-hash.
But because Windows has this constant 16-byte hash it is tempting to use that for authentication. You can do a bit of hand waving to avoid confronting how insecure the result is:
‣ Bad guys can't possibly know this 128-bit value because it's MD4(password) and there's no way to find that without knowing password. Therefore we only need to check that the 128-bit value is correct and we've authenticated the user.
‣ Storing the 128-bit value locally is fine because it's MD4(password) and you can't reverse MD4 to get the password back so it's not a secret.
Only when you see these arguments next to each other it is obvious this is absurd. So long as they're on different pages of a document, or preferably made in entirely separate discussions at Microsoft, the mistake is unnoticed.
You've engaged in the same equivocation that Microsoft uses by adding "or Golden Ticket attacks". Microsoft documents about Pass-the-hash routinely argue that this is just the same as any other stolen credentials attack, so it's not Windows at fault nobody could be expected to do better. This is definitively wrong and we need to call them out on it.
There are two requirements for this to work, both much more common in the wild then hip HN DevOps crowd would like you to believe:
1. root or other privileged accounts share the same password across the internal infrastructure and SSH is configured to allow password authentication for root (that's not the default, but it's usually enabled when admins believe that the network access is sufficiently restricted anyway)
2. requirement for admins to normally login as an unprivileged user and gain superuser rights when necessary through su or sudo (for auditing purposes)
Just gaining access to the admin's login account (ie. one from which the admin runs SSH) is enough - alias sudo=/home/admin/.trustmeimadolphin.sh in .bashrc and wait.