6 ms·

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. Wh

by terom 6y ago

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?

tialaramex 6y ago
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?
- zaat 6y ago
  > 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.
- jiggawatts 6y ago
  Linux isn't vulnerable by default, because it's missing features by default. It has no equivalent of Active Directory, and doesn't use Kerberos or anything like it by default. 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.
  - omnibrain 6y ago
    > 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. 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.
    - jiggawatts 6y ago
      The crypto wasn't at all the criticism most (any?) people had with Vista. 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.
awd 6y ago
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.
- threentaway 6y ago
  > 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.
  - Thorrez 6y ago
    If it contains all private keys that would indeed be a bad design. Maybe what awd meant is that it contains a private key that all systems trust. That would make more sense.
  - 6y ago
saagarjha 6y ago
As someone similarly unacquainted with this area, it was interesting to see the strong Microsoft influence here.
aj3 6y ago
Other answers are good, but no one mentioned *nix equivalent of PTH. Admittedly it's not exactly the same, but from an attacker's perspective it can be used with similar effect. This equivalent (which works on Windows as well, btw!) is pass-the-password. 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) The attacker gains superuser access on one system, then tricks admin to log in and gain root privileges, disclosing their password during that process (by swapping binaries, process injection, reading memory, rootkits, etc).
- q3k 6y ago
  > The attacker gains superuser access on one system, then tricks admin to log in and gain root privileges, disclosing their password during that process (by swapping binaries, process injection, reading memory, rootkits, etc). 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.
kerng 6y ago
SSH Agent Hijacking comes to mind. Technically not the same, but outcome of self propagating malware is same.

by terom 6y ago

tialaramex 6y ago

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?

zaat 6y ago
> 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.
jiggawatts 6y ago
Linux isn't vulnerable by default, because it's missing features by default. It has no equivalent of Active Directory, and doesn't use Kerberos or anything like it by default. 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.
- omnibrain 6y ago
  > 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. 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.
  - jiggawatts 6y ago
    The crypto wasn't at all the criticism most (any?) people had with Vista. 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.

awd 6y ago

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.

threentaway 6y ago
> 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.
- Thorrez 6y ago
  If it contains all private keys that would indeed be a bad design. Maybe what awd meant is that it contains a private key that all systems trust. That would make more sense.
- 6y ago

saagarjha 6y ago

As someone similarly unacquainted with this area, it was interesting to see the strong Microsoft influence here.

aj3 6y ago

Other answers are good, but no one mentioned *nix equivalent of PTH. Admittedly it's not exactly the same, but from an attacker's perspective it can be used with similar effect. This equivalent (which works on Windows as well, btw!) is pass-the-password. 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) The attacker gains superuser access on one system, then tricks admin to log in and gain root privileges, disclosing their password during that process (by swapping binaries, process injection, reading memory, rootkits, etc).

q3k 6y ago
> The attacker gains superuser access on one system, then tricks admin to log in and gain root privileges, disclosing their password during that process (by swapping binaries, process injection, reading memory, rootkits, etc). 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.

kerng 6y ago

SSH Agent Hijacking comes to mind. Technically not the same, but outcome of self propagating malware is same.