8 ms·
SSH server 0-day exploit
- sucuri2 17y agoSome info here: http://secer.org/hacktools/0day-openssh-remote-exploit.html http://secer.org/hacktools/0day-openssh-remote-exploit.html
- est 17y agofrom here http://baoz.net/0day-openssh-remote-exploit/ http://baoz.net/0day-openssh-remote-exploit/
- palsecam 17y agoFirst, it is only a rumour for now. Second, it would apparently only concerns old versions of OpenSSH. Quoting the link: "It is against an older version of OpenSSH" (OpenSSH_4.3).
- martinp 17y agoWhat they mean by "older version" isn't specified anywhere. It could mean not current for all we know, e.g. < 5.2 (unlikely though). Almost none of the popular distros use the latest version, will be interesting to see which ones are affected.
- palsecam 17y agoFor the version information, I quote http://secer.org/hacktools/0day-openssh-remote-exploit.html http://secer.org/hacktools/0day-openssh-remote-exploit.html. The submitted link seems to copy/paste most of its content from this article, but it didn't include the version information.
- mcav 17y agoIf it's fixed in the latest OpenSSH, it's not a 0-day exploit, is it?
- sucuri2 17y agoTechnically it is a 0-day exploit (not published and unknown) but that only works on older versions of SSH. However, the default version on RHEL, Fedora are vulnerable. So, it is a big issue if there is no patch from your distribution (unless you use ssh from source which is not common).
- jacquesm 17y agoIf this is real it's a biggie, there are hundreds of thousands of machines running openssh 4.3. better check those firewall settings.
- lil_cain 17y agoDepends how much older. Does it affect debian/ubuntu/redhat current systems, with fixes backported? It's a pretty big deal if it does.
- jacquesm 17y agoSSH: SSH-2.0-OpenSSH_4.3 The newest releases use 5.1
- palsecam 17y agoYes, the latest Debian stable release (5.0 "Lenny") uses SSH 5.1. $ cat /etc/debian_version 5.0.2 $ ssh -v OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 Oct 2007
- sucuri2 17y agoNo one knows yet. But the versions included on RHEL, Fedora, etc are all old (no one is on 5.3). So we have to wait and see...
- andreyf 17y agoNewest ubuntu uses 5.1p1 SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1
- palsecam 17y agoAnd it seems the latest LTS version (Ubuntu 8.04 "Hardy") uses 4.7.
- timmaah 17y agoQuestion along these lines. What version should an updated RHEL4 server have? I'm only at OpenSSH_3.9p1 yet up2date says everything is up to date.
- palsecam 17y agoGoogle seems to agree with it.
- SwellJoe 17y agoSo, just in case anyone is confused about RHEL packaging policy: The version stays the same for the life of the release; patches are applied to that version to fix security and stability issues. Our forums see tons of questions about this, with folks assuming that because they have an "old" version of PHP or Apache or whatever, that it has known security vulnerabilities. When, in reality, an RHEL released package is probably at least as well-vetted for security as the latest release from upstream. But, in this case, since there is no known exploit (and it is possibly fictional), there's nothing vendors can possibly do about the problem. I suppose vendors could have been quietly notified of the problem, and we'd start seeing new releases rolling out; but you'd see errata on the relevant vendors website. Asking random folks on HN wouldn't be the best course of action for reliable answers. Anyway, OpenSSH.org has nothing on the subject.
- bsaunder 17y agoThe latest release is 5.2.
- dryicerx 17y agoFor the time being, would be also a good idea to move the ssh port to something other than 22 to avoid getting carpet-bombed by automated exploiting scripts.
- mariorz 17y agoProbably better to use a port knocker. I recommend fwknop.
- deutronium 17y agoOr possibly set up port knocking, may be overkill though
- tlrobinson 17y agoIs port knocking a common defense these days? I remember reading about it awhile ago, and thought it was a neat idea but didn't really think people would actually use it.
- brk 17y agoI use it. It's really handy, but somewhat cumbersome if you just want to jump on an SSH shell to a box from a new machine. I compromised on some of my boxes and made a non-published/non-linked URL that if you hit it, your source IP will end up on the SSH-allowed list. That plus a non-standard SSH port seems to keep 99.9999% of the risk out of the way without being too overly cumbersome to knock-through when needed.
- deutronium 17y agoI don't think it is that popular too be honest, while it is good at preventing access from port scanners etc., the clients aren't standard utilities. [EDIT] You could always just set up iptables to accept traffic from your ISPs subnet and deny the rest.
- Gibbon 17y agoI use a simplified one port "port knocker" with iptables setup such that an ascending or descending linear port-scan will leave the ssh port closed upon completion. Only one knock is needed to keep the port open for my current IP address indefinitely, or it can be closed immediately without losing my ssh connection. It also precludes the necessity of filling up iptables with boatloads of DROPs to keep out the riff-raff.
- chez17 17y ago>members of the anti-sec movement. Can someone tell me what the anti-sec movement is?
- deleted 17y ago[deleted]
- henning 17y agoSounds like a bunch of script kiddies with a little more brains than usual and just as much malice.
- mahmud 17y agoAntisec are hackers who don't wanna profit from fear.
- mahmud 17y agoAntisec are hackers who don't wanna profit from fear.
- henning 17y ago"Hackers" as in asshole douchebags who wish medical ailments on people? "We at anti-sec, hope you never heal"
- mahmud 17y agoAt least they have credibility. These guys are sticking to their guns and keeping the hacking underground just that, underground. Anti-sec is a response to the fear-mongering era of 1998 - 2004 when every hanger-on wannabe computer guy became a security researcher and started publishing "advisories". Between dotcom bubble era to 9/11, everybody was a security guy, and not only that, but the "security guy" was pointing the finger at the hacker community everytime a script kiddie defaced a geocities web page. Those most sec guys are snake-oil salesmen and absolutely deserve no sympathy from me. If they're gonna bad-mouth hackers and promise protection to everyone with a PC (Sec industry essentially being a racket) I say let them protect themselves from the real Hackers; by and large, they're out-gunned and out-skilled. Anti-sec doesn't go after civilians, by the way.
- soundsop 17y agoCould the exploit actually be on newer versions of ssh? If so, this could be an attempt to get people to upgrade so that more machines can be compromised.
- randallsquared 17y agoWhat are the chances that the exploit is actually in 5.x, and the "anti-sec movement" is doing some social engineering to get people to upgrade to the affected versions?
- aarongough 17y agoMy thoughts exactly... If I had an exploit that only worked on the latest versions and I wanted to make use of it I would likely try a scheme like this. Of course if this is the case then the exploit is likely to be used aggressively sometime in the near future...
- skwaddar 17y agoThe monoculture has an invader, adapt or die.
- tedunangst 17y agoOriginal source: http://marc.info/?l=full-disclosure&m=124669956508903&w=2 http://marc.info/?l=full-disclosure&m=124669956508903...
- jlangenauer 17y agoI just had a browse through my auth.log, and there does seem to be a new sort of automated attack script in the wild - it opens a connection to SSH port 22, (through some spoofed IP address), but then disconnects before attempting to login. That way, it won't show up as an unsuccessful login attempt for any log-monitoring tools which add its IP address to hosts.deny. However, after it's done that repeatedly (presumably doing some sort of sniffing to work out exactly which version of sshd is running), it then attempts to login. Here's the interesting bit: when it tries to login with a user than doesn't exist, instead of just generating the "Invalid user test from xx.xx.xx.xx" log entry, sshd also outputs another log entry, directly afterwards: "input_userauth_request: invalid user test" which I haven't seen before. I'm not particularly au fait with the internals of sshd, but I would suspect that this new (well, if it is new) script has found an exploit in the part of SSHD which (logically) checks if a user exists first, but the login is being rejected deeper in sshd, when it tries to do the actual authentication. (All the above is speculation, however: I'm no expert on SSH)
- there 17y agoi suspect you are just not looking at the right file (auth log vs. a daemon log) and are only looking at the authentication requests that get passed down to your authentication library (pam?).
- tedunangst 17y agoIf the IP is spoofed, how are your reply packets getting back to it?
- jlangenauer 17y agoSpoofed is probably the wrong word - through an irrelevant IP address is a better way to put it(perhaps someone's compromised computer on a botnet acting as a proxy).
- miracle 17y agoIf it's true, then it's time to migrate the applications to windows servers. First the private/public key fiasko with debian, and then this...
- Erwin 17y agoYour sshd is probably configured with tcp wrappers (My RHEL4/5 were). If you only log in from a known set of static IPs, you could add in /etc/hosts.deny: sshd: IP1 IP2 .domain.com The .domain.com allows any IP which reverses to .domain.com. I ran: grep Accepted /var/log/secure*|grep ssh2|perl -lne '/for (\S+) from (\S+)/ && print "$1 $2"'|sort -u To find all IPs/users that logged in. This may give you trouble if you SSH from e.g. some mobile connection or from random wifis around the world.