4 ms·
In our experiments, it takes ~10,000 tries on average to win this race condition, so ~3-4 hours with 100 connections (MaxStartups) accepted per 120 seco
by megous 2y ago
In our experiments, it takes ~10,000 tries on average to win this race
condition, so ~3-4 hours with 100 connections (MaxStartups) accepted
per 120 seconds (LoginGraceTime). Ultimately, it takes ~6-8 hours on
average to obtain a remote root shell, because we can only guess the
glibc's address correctly half of the time (because of ASLR).
MaxStartups default is 10
- Haemm0r 2y agoQuestion regarding this from a non-guru: - Is it correct that this only works for user root if login with password/key for root is allowed? - Is it correct, that this only works if the attacker knows a login name valid for ssh?
- aflukasz 2y agoI believe knowing existing user name or using host-depended value does not matter. The exploit tries to interrupt handlers that are being run due to login grace period timing out - so we are already at a point where authentication workflow has ended without passing all the credentials. Plus, in the "Practice" section, they discuss using user name value as a way to manipulate memory at a certain address, so they want/need to control this value.
- vesinisa 2y agoEven if it means the attack takes 10x as long, it doesn't seem to be limited by bandwidth, only time. Might not take long before the bots appear that try to automatically exploit this on scale.
- ale42 2y agoSuch an amount of connections should anyway trigger all possible logging & IDS systems, right?
- megous 2y agoI doubt most servers use any such thing.
- stefan_ 2y agoIf you don’t value your time, sure? There’s thousands of systems trying to log into publicly accessible SSH servers all the time.
- XorNot 2y agoYeah slow bruteforces are running all over the net all the time. This means there's no reason not to throw this attack into the mix.
- Piskvorrr 2y agoIt should trigger fail2ban, that's for sure. Alerting is useless, with the volume of automated exploits attempted.
- TacticalCoder 2y ago> It should trigger fail2ban, that's for sure. But people here are going to explain that fail2ban is security theater...
- Piskvorrr 2y agoIt's a doorstop, not a fix. Useful nonetheless.
- DEADMINCE 2y agoCan you link to any comment in this thread of someone actually claiming that?
- BrandoElFollito 2y agoI am one of the people who see fail2ban as a nuisance for the average administrator. Average means that they know things on average and sooner or later fail2ban will block unexpectedly. Usually when you are away canoeing in the wilderness. This is all a matter of threat and risk management. If you know what you are doing then fail2ban or portknocking is another layer on your security. Security theater in my opinion is something else: nonsense password policies, hiding your SSID, whitelisting MACs, ...
- johnklos 2y agoIf you have a public facing Internet server, you're probably already running something like blocklistd or fail2ban. They reduce abuse, but they don't do anything to avoid an issue like this except from naive attackers. More resourceful attackers could automate attempted exploit using a huge botnet, and it'd likely look similar to the background of ssh brute force bots that we already see 24/7/365.
- JackSlateur 2y agoDefault is 100: https://github.com/openssh/openssh-portable/blob/master/servconf.c#L413 https://github.com/openssh/openssh-portable/blob/master/serv...
- JeremyNT 2y agoThe config option called MaxStartups accepts a tuple to set 3 associated variables in the code. It wasn't clear to me which value people were referring to.
- jmclnx 2y agoThe default for MaxStartups is 10:30:100 10:30:60 is mentioned in the man for start:rate:full, so I set mine to that value. Thanks for the quote