The "Hail Mary Cloud" Is Growing 102
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.'"
What has to happen? (Score:2, Flamebait)
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.
Re: (Score:1)
Mary responds, curtly, to your half finished prayer
"What do you want?"
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".
Re: (Score:1, Informative)
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).
Re: (Score:1)
I don't watch much football. Can the quarterback throw as many balls as he wants, in the hope that at least one of his receivers catches it?
Re: (Score:1, Insightful)
(or make lawmakers force them to)
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."
Re:What has to happen? (Score:5, Insightful)
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.
Re: (Score:2, Insightful)
Re: (Score:1)
Just was has to happen to make people realize (or make lawmakers force them to) that securing your boxes is a necessity?
The Infocalypse?
Put in denyhosts... (Score:3, Interesting)
Re: (Score:1, Funny)
denyhosts is security through obscurity much like changing the default port for SSH... or so I'm told.
Re: (Score:2)
Using Denyhosts and changing your default port adds layers of obscurity on top of existing security. Both are damn useful for reducing the number of real-world intrusion attempts on your system.
Re: (Score:2)
Right now changing the port number is getting the job done.
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.
2) Moving to a non-standard port.
3) Port knocking.
If you implement port knocki
Re: (Score:3, Informative)
Actually, no it isn't. It is a tool to limit the number of attempts at password guessing. Knowing it's there won't help the attacker at all (they still can't just blast away from a dictionary).
Re:Put in denyhosts... (Score:4, Informative)
Denyhosts isn't security through obscurity in any way.
It just monitors /var/log/messages (or wherever your sshd is configured to log to) and blocks ip addresses with multiple failed logins.
I think you're thinking of port knocking, which is security though obscurity, though it's still damned useful.
Re: (Score:1)
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.
Re:Put in denyhosts... (Score:5, Informative)
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.
Re: (Score:1, Informative)
I change the default port that SSH listens on and use Key login, just to be safe.
I assume theres not much more i can do to secure it.
I would imagine 90% of the people out there don't need to have ssh running on a standard port.
Re:Put in denyhosts... (Score:5, Informative)
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.
Re: (Score:2)
Re: (Score:2)
Oh, I get it. We build a cloud to fight their cloud.
Re: (Score:2)
Better would be to use public key/private key pairs and disallow username/password logins.
Re:Put in denyhosts... (Score:4, Interesting)
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.
Re: (Score:2)
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.
Re:Put in denyhosts... (Score:4, Funny)
Re:Put in denyhosts... (Score:5, Informative)
or fix your filesystem clients.
Re: (Score:2)
Re:Put in denyhosts... (Score:5, Informative)
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).
Re: (Score:3, Interesting)
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. "
RTFA. From the looks of the logs he posted, it's deliberately only trying a couple times from any given IP, specifically to prevent this sort of detection.
I used to do this sort of thing with scripts on my server, after running into an occasional spurt of several hours of an IP address trying every username in the book, apparently hoping for
How to ID an Infected Computer (Score:2)
So is there any way other than looking at the packets on your router to know if a system is compromised? This is a question thats been asked many times before but Ive yet to see a straight answer.
Re: (Score:1)
Re:How to ID an Infected Computer (Score:5, Interesting)
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.
Re: (Score:1, Funny)
Re: (Score:3, Informative)
Sure. Whenever I'm at home the phone connects via wifi through an Airport. When at work it connects via wifi through the university's secure wifi network.
Wet Nuns (Score:5, Funny)
Denyhosts (Score:1)
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.
Re: (Score:2, Insightful)
The article noted that this is a vulnerability to cracked smartphones with ssh installed for which the user will likely not even know opens up such a vulnerability to their cell.
I think that this is more serious for wi-fi and bluetooth enabled devices as the data charge is circumvented making it even harder to detect?
I'd hate to start streaming my smartphone's logs back to my IDS, but brute force is not a new reality but the environment is very precarious as the smartphone does a lot now but may n
Re: (Score:2)
The iPhone bit was a hook to draw eyeballs. The smartphones are no more or less susceptible than any other machine running SSH, all of whom should have a more sensible password policy.
Re: (Score:3, Insightful)
all of whom should have a more sensible password policy.
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
why ssh on phones? (Score:2)
Because today's phone is tomorrow's remote terminal.
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.
Re: (Score:2)
Tomorrow? I log in to my servers from my phone around 5-6 times a day.
You don't have putty on your phone? Why not?
Re: (Score:2, Funny)
Re: (Score:3, Interesting)
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
Re: (Score:3, Informative)
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.
Re: (Score:3, Informative)
try this
cat logfile | cut -d " " -f [fill in the field with the IP ] | sort | uniq -c | sort -n
(and if need be, add ' | tail -20')
This will show you whether there are repeat IP addresses in the log.
Webgoddess
Re: (Score:2)
Not on OS X it doesn't. No cut -d.
A quick grep shows that a sample IP address does try about two or three times a day, which suggests several thousand unique addresses gracing me with their attention.
Re: (Score:2)
DenyHosts will not save you; disable passwords (Score:5, Interesting)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
user names, too (Score:3, Informative)
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
Oh, and don't forget the port, either. (Score:2)
Get off the default ports, too.
tarpit port 22, just for fun.
Re: (Score:2)
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 of course the unavoidable issue - people have too many passw
Re: (Score:2)
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)
Re: (Score:2)
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.
Re: (Score:2)
And if a machine that has your public key on it is compromised ?
Re: (Score:2, Informative)
Re: (Score:2)
Do you know what the word "public" means?
Can you see how it makes that irrelevant?
Re: (Score:2)
And if a machine that has your public key on it is compromised?
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
Re: (Score:2)
What we really ought to do is start cracking down more on botnets.
Letting criminals sheperd up huge flocks of zombie computers is the root of two very serious problems: spam and DDoS attacks.
Forget electronic terrorism. These guys have a fucking ARMY of computers.
The cloud attack isn't new (Score:4, Interesting)
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:
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...
Re: (Score:2, Insightful)
Re: (Score:2)
I changed SSH to a nonstandard port and reduced attempts by 95%.
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
Re: (Score:2)
Sounds like made up numbers. You claim that one in 20 ssh login attempts was coming in on a non ssh port? Which port was it exactly?
Re: (Score:2)
I manage a server on my local university and I simply whitelist SSH access and all other ports are precisely controlled via whitelists too.
Users have basic access to standard ports like http and https but for any other port you need to be in a whitelist. Works like a charm and it allows me to see attacks very easily.
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
none taken
Re: (Score:1)
The one thing I always do is turn off password login via SSH. Only authorized keys are allowed and they are strictly controlled.
I also have black-listed some parts of the IP address space where a vast majority of the attacks were coming from but lately this has proven not to do as much as it used to do.
How do these two parts relate? (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Most likely the hail mary bots will have successfully compromised a few iphones with default passwords, tho their intrusion will be less obvious than a picture of rick astley.
Re: (Score:2)
You don't need a hail mary bot to compromise a well known default password.
Most likely a bunch of jailbroken iPhones are compromised, just like lots of routers with default passwords.
Translation for non-retards: (Score:3, Insightful)
s/cloud/network/
There. Done it for ya. Was that so hard?
We should make a Greasemonkey script out of it. :)
Re: (Score:2)
For the sake of tradition we should call it a Beowulf cluster. Imagine that.
Re: (Score:2)
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.
Re: (Score:2)
LOL. I just thought I had misspelled it as "unClusteredThinking", until I noticed that I already had the script installed. Just shows how well it works. ^^
Re: (Score:2)
Then reading Final fantasy VII faqs and Meterology websites would get really strange.
Re: (Score:2)
It's limited to Slashdot for that very reason. :)
Plaintext passwords over ssh (Score:2)
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.
The only real solution is to disallow tunneled plaintext password logins entirely... simple enough, just set 'PasswordAuthentication no' in /etc/ssh/sshd_config (or wherever it lives). Problem solved.
Nobody should be using that sort of authentication any more anyway.
-Matt
Four simple things (Score:2)
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
I may be missing something (Score:1)
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:1)
Um, what about this [itefix.no]? Or would you say that cygwin counts as "unix?"