1

Its well known that popular Linux distros use the PAM default to slightly delay incorrect login attempts, thus mitigating brute-force attacks against a user account (for example, running su repeatedly with different password input). The PAM delay is 2 seconds, which supposedly puts the chances of success within a certain range for a given password strength, and increasing the delay beyond this default is expected to make the attack's success even less likely.

The problem comes when you run this simple bash code:

time for i in {1..20}; do su -c ls user <<<"wrong_pwd"; done

Run from a single process, it takes a predictable amount of time. But run it from multiple processes at the same time, each instance will show essentially the same run time as the single-process attempt. Oops!

This means an attacker can make a brute force attack geometrically more effective against a PAM-mediated login if they simply run it in parallel.

Therefore, I have two questions:

  1. Am I missing some detail about mitigating brute-force attempts?
  2. If not, is there some configuration option that can be used to close this authentication loophole?
tasket
  • 171
  • 1
  • 4
  • 1
    I feel like the fact that you can only have so many processes running at once without tying up your CPU puts a bottleneck on this somewhere, though I can't actually put my finger on where, because they probably use a standard `sleep` to wait out the couple of seconds, which ironically drastically improves the multiprocess performance. You do seem to be correct; I ran a few instances of this in parallel (with GNU `parallel`) and it took roughly the same time as running one instance. Pretty concerning. – Nic Jul 09 '19 at 01:03
  • 1
    I don't have any suggestions for (1), but for (2):Only make a small subset of users part of the 'wheel' group and blacklist the su command. Going further, you can look at configuration of the /etc/sudoers file so that the sudo command can only be used for certain required functions. It may increase your administrative burden a little. Also, YMMV vary depending on the flavour. –  Jul 09 '19 at 12:45
  • @Ian Unfortunately I can't dismiss the PC use case where the primary user belongs to wheel. If a net app is attacked remotely and can execute code as the user, they may try to gain system access through `sudo`; this is what I need to avoid. The sudoers approach could help in some settings, but it does limit the user. – tasket Jul 09 '19 at 19:44
  • Limiting the user is what we're about over here, soldier! Ok, so I jest, but I guess you just need to apply `least privilege`. Users may want more - but do they *need* more? –  Jul 10 '19 at 10:01

0 Answers0