What 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?
My 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...
I 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)
i 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?).
Spoofed 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).
For 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.
I don't understand why people don't do this it is so much harder if not impossible for people to break into your server by normal means especially when you add MaxAuthTries 3
MaxAuthTries only logs errors, right? That by itself is not enough. You'd want fail2ban or bansshee or something, which tail those log files and blackhole any IP that causes an auth/username failure too many times in a certain period.
However, that wouldn't work in this case anyway because if there's a working exploit in sshd then an auth/username failure would never even be logged. It'd be straight in first try.
The default setting is 6. You are not throttling the attack too much by setting this to 3. I would set it to 0 so if you make one bad attempt you are out.
This still does not solve the problem but it is a smallish roadblock.
I would also set MaxStartups to 1 if you are the only person to login. This limits the number of unauthenticated people trying to concurrently log in.
Is 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.
I 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.
I 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.
IMO port knocking isn't good defense, people can always use nmap to scan for open ports then try some combinations on them. Certificate authentication is way better (in combination with disabling password login)
Certificate authorization alone may not protect you from 0-day exploits to your ssh server. Not all port knockers use that pinging ports combination technique. Again, I recommend a look at fwknop which addresses your concerns by using certificates actually.
So, 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.
What 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.
Could 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.
Anti-secs want to keep security - in particular, exploits - private. Milw0rm is their nemesis. There's a discernible political bent to their writings and rantings. While we see a general shift on the internet towards the idea that "information just wants to be free", the anti-sec people don't agree with this when it comes to matters of security. From a white-hat POV, they're saying that full disclosure actually causes more damage than if only a select few, capable, and not necessarily malevolent, people were to know about any particular exploit. But I also get the impression there's a tad of immaturity and insecurity in there. There's revulsion that a once (deservedly) elite occupation has been encroached by larger, more clueless corporations (eg the antivirus mongers, but there are many others), and that the movement is more a rebellion against that than a completely well thought out, idealistic point of view. Still, from recent events, nobody could deny their abilities.
I haven't been interested in computer security in quite a few years so some of this might be out of date:
It is a loose movement that kind of fights against the traditional for-profit computer security industry. they think that publicizing security holes and those hole's exploits causes more pain than it helps. They also seem to be kind of anti-capitalist. A bunch of docs have been written about their goals and ideas. They aren't really script kiddies, some of them are very talented security researchers.
google around for the el8 magazine, also 'phrack high council' or just antisec in general
kiddies with brains and technical knowledge to actually write their own exploits are not script kiddies... This term is used for kiddies without brains that just learned to run a few scripts to attack others.
At 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.
Not if you're using that computer to publish security articles that tell people their lives are at risk if they don't buy your product to protect themselves from the "evil hackers".
It's a very specific feud between two specific groups of people.
If you're not in the know, why not lurk in the scene a bit and see what's going on? I did just that; I was curious about security and I saw both sides of the issue. One group publishes exploits and carries out mayhem for fun, while the other group repeats what the former said in legit, paid publications and calls the former names.
Even the train-robbers vs bounty-hunters analogy fails in this case; there are way too many Joe Sixpacks fancying themselves a town sherrif and speaking ill of Jesse James. Very soon, some faces are bound to get smashed at the local Saloon :-P
using that computer to publish security articles that tell people their lives are at risk if they don't buy your product to protect themselves from the "evil hackers"
That's the most bizarre definition of "not a civilian" I've ever heard.
Furthermore, I don't trust anyone's definition of "fun" if it means "mayhem" on my boxes, and I don't trust any hackers to tell the difference between funmeisters and for-profit thugs when, for example, having a jolly fun chat about vulnerabilities. The idea that I could lurk in the scene doesn't exactly make me feel better about it.
One group publishes exploits and carries out mayhem for fun
I thought dtf and utnick said they want to keep exploits secret? So do they share the exploits in "the underground" and try to keep them secret from stodgy, above-ground types? Again, I don't trust them to distinguish between "cool" people and (e.g.) botnet operators who send v1@gr@!!! email for spammers.
Your 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.
Technically 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).
