Posted
by
Soulskillon Sunday November 15, 2009 @01:23PM
from the like-a-zombie-chia-pet dept.

badger.foo writes "The Australian rickrolling of jailbroken iPhones only goes to prove that bad passwords are bad for you, Peter Hansteen points out, as he reports on the further exploits of the password-guessing Hail Mary Cloud (which we've discussed in the past). The article contains log data that could indicate that the cloud of distributed, password-guessing hosts is growing. 'With 1767 hosts in the current sample it is likely that we have a cloud of at least several thousand, and most likely no single guessing host in the cloud ever gets around to contacting every host in the target list. The busier your SSH deamon is with normal traffic, the harder it will be to detect the footprint of Hail Mary activity, and likely a lot of this goes undetected.'"

Just was has to happen to make people realize (or make lawmakers force them to) that securing your boxes is a necessity?

What? Tell me, please, what has to happen? How much damage is needed? We'll see it happen, no matter how much damage is required. The question is only whether it's too late or whether we can repair it.

The full prayer is [quote]"Hail Mary, full of grace, the Lord is with thee; blessed art thou among women, and blessed is the fruit of thy womb, Jesus. Holy Mary, Mother of God, pray for us sinners, now and at the hour of our death. Amen"[/quote]

The attack is called "Hail Mary", because it should take a miracle to break in to a foreign system by "guessing passwords".

The attack is called "Hail Mary", because it should take a miracle to break in to a foreign system by "guessing passwords".

The link the author provides in the story is about the Hail Mary pass [wikipedia.org]. Sure, the Hail Mary pass itself goes back to the prayer, but you're skipping a layer of analogy (and an interesting bit of trivia).

I can't wait for the day that Congress passes a law to the effect of "If malware causes your computer to do something illegal, you will be held responsible for said illegal activities in court even if you can prove malware was the cause."

This is pretty much what I fear will happen eventually. Right after we'll all be equipped with "trusted" computers that will only run what we want if we jailbreak them, which will not only void their warranty but also open us up to trains of thought such as: If you didn't jailbreak and thus could only run software approved by The Powers That Are, you would not be susceptible to malware (or if, TPTA would have to take responsibility) and are thus fully liable.

Sounds far fetched? Think about it. Outlawing jailbreaking will probably not really work out, even if it was outlawed, who cares (how do you want to prosecute it)? But locked down devices that, in theory, cannot be harmful being spam chuckers will essentially mean you broke the lock. And then your lawmaker may choose, either he'll slap you for breaking the lock or, if he can't do that for some odd reason like a device that you own belonging to you, will catch you with the angle that you're causing damage with it and that can incur a hefty bill.

Don't tell me it ain't possible. If you haven't been asleep the last 10 years and when you look at the way things turned, it's anything but unlikely to become the next angle to ensure we only run what we're supposed to run.

And if at all possible, I'd like to avoid giving anyone a reason to follow that train of thought.

Dude, I totally agree with you. We are being channeled into systems that will not be under our full control, and doing anything about going down that path (other then willingly) is to be deemed unlawful. But I am not sure if freedom-loving individuals have any choice at this point...talking about it on/. is not going to change anything, other then providing a record of the dissent. So as they say here, "Ke Garne" or what to do?

Denyhosts is available for most linux distros.
You can tune its behavior and it will basically filter out requests coming from misbehaving hosts.
From Wikipedia:
"DenyHosts is a Python based security tool for SSH servers. It is intended to prevent brute force attacks on SSH servers by monitoring invalid login attempts in the authentication log and blocking the originating IP addresses. "

The average attack is just trying to connect to port 22 across an IP range. Once it connects it then trys to brute force the password. If you have a weak password you are sunk. If you have a 14 digit password like !))%L0553r-boy they are not getting in.

Any of the following will make it more difficult.

1) Denying hosts of there are to many log in attempts from an IP address.

How is port knocking security through obscurity? It's putting a password on being able to connect to the ssh daemon. Admittedly upstream routers could easily grab the "password" if they know what it's for but they've just peeled back one layer of the onion.

Denyhosts will *not* protect you from Hail Mary. Read the article...this particular botnet may send you only a single login from a single IP, but the cloud as a whole will send you hundreds of attempts.The correct solution is to disable password login, and use pubkey auth instead.

The nice thing about denyhosts is you can participate in the global shared DB, so one failed login on your machine, one on mine, etc, we all report the same IP, it gets flagged in the global DB, so we all block it. Machines that IP hasn't hit now won't allow login attempts from it.

Unfortunately, these phones do not have fixed IP addresses. IP-based authorization won't work when half the time your IP address is assigned by the local WiFi LAN as is the address of the other phone -- after all, you might be using SSH at home where IP addresses are assigned from the same range as at the hostspot where you get attacked. You need host-based or user-based authentication that does not depend on IP addresses. For example, SSH supports user-based cryptographic keys.

I also think that blocking hosts is the wrong way to go. Most people do not run open-to-the-public login servers, either on their home computers or on their phones. If you must do host-based blocking then the correct approach is that of hosts.allow — deny all requests by default except for those that you trust.

This is difficult to do. I don't need to run a login server that is open to the public but I do need access that is open to me. I do this to account for unexpected situations.

By virtue of the unexpected nature, white listing is not a valid option in these situations. If I am somewhere and discover that I need access to my computer for some reason, I will not know in advance what IP I will be connecting from.

The main role of Denyhosts is to lock you out of your own box if you're using an ssh-based file system, which applies your incorrect password multiple times rather than once. I've spent way too much time going into my hosted box via somewhere else to let myself back in.

I've long since gone the opposite route, my server rejects all requests unless/etc/hosts.allow has already whitelisted them. Granted, it's a home server and I'm the only one who ever uses SSH on it. (Hotel wifi is temp-whitelisted on the fly by remote-connecting to a whitelisted work client.)

Very true, but it'll only keep out an absolute moron. Anyone with half a brain will use a distributed mechanism, which means DenyHosts will only see failed password attempts from a given host a few times.

There's plenty more to do:

- Don't allow root logins via SSH, or limit them to key-based logins (trivially easy in/etc/ssh/sshd.conf)- Disable shell accounts unless they're really needed. rssh is useful here - limit what a user with SSH login authority can do.- Lock down other services. What good does DenyHosts do you if SSH and a separate app which can't be locked with DenyHosts both use the same password mechanism?- Lock accounts which have more than N failed logins. (Though if you've centralised logins such as in the above example, it'd probably be better to do this from whatever system deals with the authentication, eg. LDAP).

Sure , make a list of all your files and corresponding checksums , and once in a while take it offline and verify the checksums on another computer.If anything that you haven't modified has changed , you likely have a problem.

It's difficult to say whether or not a given system is infected, even if you inspect a complete packet log. Your checksum plan is one of the few ways to guarantee a lack of infection. Actually even that isn't always a guarantee, depending on where the hack is hiding. It could be in the MBR or even burned into the BIOS.

Luckily, in most cases the hackers aren't clever enough to hide their steps that well. There'll be oddly-named files in/var/www, ps and top will disagree about running processes, or you'll suddenly find yourself locked out of some system management tool.

I would think that anyone running an ssh server should also be running something like the Denyhosts daemon [sourceforge.net]. After a set number of failed logon attempts, it will automatically add the connecting ip address to hosts.deny and their hack attempt is over.

Why does a cellphone OS need a user authentication system in the first place? Maybe at the application level.. no, I can't see that either. Anyway, this phone has one, and it's not meant to be used this way. These things are not meant to have SSH running on them, and whomever released the SSH package for them is irresponsible for not taking that into account.It doesn't even need to authenticate using system methods, it could generate a random password at install - display on screen, and do it's own authe

You'd better believe I sometimes wish I could log into my personal server remotely from my phone to check the logs or something.

Now, I may not now need to log into my phone via sshd, but, actually, yes I do. Simple stuff. The phone company's mail software and user input stink. But that's trying to fix a different problem, really.

Yes indeed. You can always make a network-facing daemon that has been heavily audited more secure by putting a Python script between it and the public Internet.

What I will say here applies to password logins. For SSHD that is configured to accept only cryptographic/public-key authentication, the attacks that Denyhosts would block are only a nuisance (they fill up logfiles).

That heavily-audited network-facing daemon does not concern itself with password security. You can allow remote root logins and set your root password to "password" and that daemon will faithfully do what you told it to do. The heavy audits are designed to make sure that a person who does

Over the last week my SSH server has gotten about one password guessing attempt every ten seconds. Presumably they're not all from different hosts, but a quick visual scan didn't show up any duplicates and the ones that are close in time are certainly all from different IP addresses.

This is a distributed effort, and any one host will not hit your machine more than once. You could configure it to block entire country's subnets, but that's still only marginal protection.

What you want to do is disable username/password authentication on your ssh hosts. This is one of the first things I do. Set up your machine's public and private key, copy your public key to all your other machine's authorized_keys file, and edit your sshd config and add the line "PasswordAuthentication no". Now, broken crypto libraries aside, you will be safe from this sort of attack.

Agreed: anyone of clue should disable password logins for SSH or require use of strong passwords (i.e. long and randomly generated) if they can't do so.

Still, it could be worse: my webcam came with a password on the http: front-end, but a passwordless root login if you telnet to the other open port that nmap found. At least they must have realised they'd made a mistake because the firmware update removed that insane security hole.

The required password security for SSH is often overstated. The absolute number one never-ever-do-this thing is dictionary words (or user names or easily guessable information) with little to no mangling: that's a recipe for disaster. Besides that, any reasonable password length (8 characters or more) is fine. It doesn't even have to be random, it can be pronounceable gibberish or even something coherent to you, as long as it's very particular to you and obscured in a non-obvious way (e.g. don't just do 'st

Somebody posted a list of user names being tried above. Take a look at it for a little education on what not to use as a user name. No simple first names, no matter how romantic or aesthetic it feels. No names of servers (mysql, etc), especially not unadorned. "admin", of course, but also "manager" are out.

So, make the user names harder to guess. Root, of course, do not allow root to log in, period. Definitely not over the net, anyway. If you must log in as root, change the root user name, or add a synonym

One of the biggest issues is extremely weak enforcement of passwords...Many devices come with default passwords, and do not force users to change them at all.In corporate networks even when a password policy is implemented, it's usually extremely weak... Typically requiring one number, one uppercase letter and 8 characters or more. Password1 is a perfectly valid password in this scenario, and when forced to change it Password2 is equally valid.

and you could also have a flash key with your SSH utility that could be used to login from any other computer (heck with the price of flashkeys these days you could have your entire software stack on the key and a good bit of data)

My iPhone has my SSH key on it. If you REALLY need to log in to an SSH server from some random computer and don't have your key handy you could ssh in from your phone and turn on password authentication just long enough to log in.

The public key doesn't matter. Anyone can have your public key and security is not affected. However, if they get your private key, that's another story... (But you can also password-protect your private key as a last measure of security.)

Either you are very very stupid, or you meant private key. If the former, you understand that the only reason I'm not publishing my public ssh keys here, on slashdot, is that I don't want some loony jerk giving me an account without my knowledge? I have more than enough of the damn things already. However, if you meant private keys then that's a fair point: they're best kept on machines that never run services. (OK, it would also be better if those machines never ran web browsers either given the general in

I've mentioned [slashdot.org] distributed [slashdot.org] attempts [slashdot.org] against [slashdot.org] my own [slashdot.org] system [slashdot.org] before. The only thing that has changed over time is the number of systems involved in a cycle. I suspect my own system is currently (by nothing other than bad luck) the target of multiple concurrent cycles. I suspect this because I see different parts of the alphabet being cycled at different rates (in terms of attempts per user name) at the same time.

Although in spite of all the advice people offer to ward off the attacks, there are a couple of really simple things to do that will keep it at bay with excellent effectiveness:

Don't allow remote root login

Keep your list of allowed users as short as possible and practical

Avoid common login names (especially common first names) if possible

Make sure your users use strong passwords

If you keep to at least those precautions you just need to grep your messages log for the allowed user names periodically to make sure that there weren't any attempts on valid names. Then as a bonus your system will keep generating more log entries for you to post to slashdot journal entries as your observations of the attack attempts...

That is an option that has been suggested many, many, times. And indeed as you state it does work pretty well for most attempts. However it is not without trade-offs. I do a fair bit of traveling myself, and I sometimes don't know ahead of time what kind of equipment I might be using to access my home system; I would rather leave it on the standard ssh port.

Then I started a whitelist (hosts.allow) for SSH. That took care of the rest.

Again, for some people that would be a sub-par solution. If I don't know ahead of time what address or address block I might be logging in from ne

My logs show several different types of attack at the same time. One is the distributed guessing in the article, an attempt by a different host every ten seconds or so. There's another, from a single host name, that gets stopped in it's tracks because the address doesn't reverse map and yet another, from a variety of hostnames that do not reverse map.

Another effective protection is to change the default port of SSH from the standard 22 to something else. Even though a brute forcer could add a port scan to look for SSH elsewhere, the fact is that they don't.

It's not worth the effort for them to do so...Users could be using any port, meaning the attackers would now need to do 65534 times as much scanning to cover the same number of potential targets while only finding a handful more ssh services.Also, the people who use non default ports will have explicitly done so and are therefore more likely to be aware of security issues and have stronger passwords, or other forms of authentication.

No offense, but just here on slashdot I have seen at least a dozen suggestions to do that already. I have said before and I will say again that I'm not concerned enough about the attempts to change my ssh port; I actually rather enjoy parsing through the data generated by 100's of compromised systems failing in their attempts to access my home server. If I was runing a for-profit system and there was a genuine concern about accessibility problems coming from this then I would probably change my port just

The summary starts by talking about jailbroken iphones getting rickrolled. It then goes on to discuss the growing hail mary cloud of compromised systems that are trying endlessly to find unsecured *nix boxes to log in to.

The iPhones are vulnerable not because of a software flaw but because of a default password that didn't get changed when the SSH server got started up. The hail Mary attempts are trying to exploit bad passwords.

The connection is tenuous but not entirely absent. It's also arguably a good point since a lot of press coverage of security issues focuses on software vulnerabilities.

Indeed. "Cluster" is a more fitting word. I just wrote the Greasemonkey script, and changed it to use that word: unCloudedThinking 0.1 [userscripts.org]For the fun, I also throw in a replacement of "hacker" with "cracker" and some nice Unicode characters. Feel free to add more.:)

Plaintext passwords over ssh have always bothered me. I always had a little program called 'sshlockout' which checks for failed password attempts via auth.log and lockout the IP, but that clearly won't work against something like this.

In my small amount of experience observing these types of ssh attacks, and even letting them into high-interaction honeypots to see what they do, there are four simple things that can be done to really cut down on the danger. Applying the first item, and any subset of the last three should be pretty good.

One, turn off root log in. Then they have to guess both a user name and a password. This would stop every single attack I have ever seen in my logs, since none of them have guessed a correct user account, l

But it seems to me that key based authentication mediates this risk. Am I the only one that does this? What the heck does everyone think ssh is for? I use password authentication the very first time I access a server. I put my pub key there, then disable password authentication. My private key never leaves the thumb drive I wear around my neck. Being a CHL holder, it is very unlikely you'll get to that without leaving your DNA and most probably grey matter all over the place. Plus, my cat sets my passwor

No, but it's present on most linux server installations, and therefore relevant to linux. I don't see how it's irrelevant. If it bothers you, maybe we should have a "unix" super-section that covers OS X, Linux, BSD, etc. that stuff that affects everyone can go under.