Full Disclosure mailing list archives
Re: SSH brute force blocking tool
From: Tavis Ormandy <taviso () gentoo org>
Date: Tue, 28 Nov 2006 17:19:06 +0000
On Tue, Nov 28, 2006 at 11:59:43AM -0500, J. Oquendo wrote:
Tavis Ormandy wrote:On Tue, Nov 28, 2006 at 04:02:36PM +0000, Tavis Ormandy wrote: I notice you also havnt solved the local privilege escalation, this can be abused by local users to gain root by attempting to login with the username set to a valid passwd entry and then winning the race condition by creating a symlink to the system passwd file (of course, there are dozens of other attacks). Thanks, Tavis.And just what on God's earth does "SOMEONE LOGGING IN WITH USERNAME SET TO A VALID PASSWORD ENTRY" have to do with this script. Let me take my script out of the equation for a minute. "SOMEONE LOGS IN WITH A USERNAME SET TO A VALID PASSWORD ENTRY" don't you think this is a problem with the system they're on? Please explain to me how because I'm seriously curious to know how you envision this happening with this script of mine.
J, take a deep breath. I understand that you are new to security, but this is a big topic that is too difficult to summarise in one email, but I will try to explain it in simple terms. I said "attempting to login with the username set to a valid passwd entry", not password entry. passwd entries are described in the passwd(5) manual. This would cause your script to output a passwd entry and save it to /tmp/hosts.deny due to this line: awk '/invalid user/{print $13}' /var/log/secure|sort -ru >> /tmp/hosts.deny Notice there is no filtering, even in your "fixed" version. Okay, now you're using /tmp to store your temporary files, it may surprise you to know that this is very difficult to do securely, there is a class of vulnerabilities known as "insecure temporary file creation" and the classic attack is the symlink attack. the symlink attack puts a symlink in this predictable location and waits for your script to write to it, thus overwriting or creating a file with the privileges of your script (root). Ahh, but there is a catch, you check if the file already exists and unlink it if it does. But as this operation is non atomic, you have created a race condition. This is difficult to explain, but trust me on this one. Another problem exists as you have used `test -e` to check for the existence of the file, test -e will return 1 for broken symlinks, which means an attacker can further manipulate where you write even without winning the race condition in certain circumstances. So lets say I convince your script to save a passwd entry giving me root access to /tmp/hosts.deny, which I have redirected using some linking attack to /etc/passwd, you append the line of my choice to the passwd file. I could have said /etc/ld.so.preload, /root/.bashrc, /etc/profile, it doesnt matter, any will do. I now have got root on a system where I was previously just an unprivileged user.
Nov 27 16:31:21 local sshd[67010]: Illegal user dd from 213.134.128.227 awk '($5=="Illegal"||$6=="Illegal")&&$9=="from"{print $10}' Would stop the insertion attack and only print out the tench field if fields 5, 6 and 9 match Illegal user from.
No it wouldnt, I can add that text to my username "a b x Illegal from etc".
But before you shoot back let me send your response for you: SO let me restate. I could modify it to look at lines 5, 6, and 9 ... Take a look at the tenth column and if anything comes after that...Ignore that entire line... Should I have done so, maybe... Will I do so... Maybe...
No, this is still insufficient, and still vulnerable to a local privilege escalation.
As to a fix to someone injecting ranDumb addresses. That same awk statement above will work but if they're doing some netcat voodoo, then feel free to shoot off another email on how my script broke TCP/IP entirely.
J, I'm only trying to help you understand the security flaws you have exposed people to. Thanks, Tavis. -- ------------------------------------- taviso () sdf lonestar org | finger me for my pgp key. -------------------------------------------------------
Attachment:
_bin
Description:
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Re: SSH brute force blocking tool, (continued)
- Re: SSH brute force blocking tool Tavis Ormandy (Nov 28)
- Re: SSH brute force blocking tool J. Oquendo (Nov 28)
- Re: SSH brute force blocking tool Tavis Ormandy (Nov 28)
- Re: SSH brute force blocking tool J. Oquendo (Nov 28)
- Re: SSH brute force blocking tool Thierry Zoller (Nov 28)
- Re: SSH brute force blocking tool Tavis Ormandy (Nov 28)
- Re: SSH brute force blocking tool Brian Eaton (Nov 28)
- Re: SSH brute force blocking tool Brian Eaton (Nov 28)
- Re: SSH brute force blocking tool Tavis Ormandy (Nov 28)
- Re: SSH brute force blocking tool J. Oquendo (Nov 28)
- Re: SSH brute force blocking tool Tavis Ormandy (Nov 28)
- Re: SSH brute force blocking tool Anders B Jansson (Nov 28)
- Re: SSH brute force blocking tool J. Oquendo (Nov 28)
- Re: SSH brute force blocking tool Thierry Zoller (Nov 28)
- Re: SSH brute force blocking tool Tonnerre Lombard (Nov 30)