Slashdot Log In
The "Hail Mary Cloud" Is Growing
Posted by
Soulskill
on Sunday November 15, @12:23PM
from the like-a-zombie-chia-pet dept.
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.'"
Related Stories
[+]
Sloppy Linux Admins Enable Slow Brute-Force Attacks 391 comments
badger.foo passes on the report of Peter N. M. Hansteen that a third round of low-intensity, distributed brute-force attacks is now in progress — we earlier discussed the first and second rounds — and that sloppy admin practice on Linux systems is the main enabler. As before, the article links to log data (this time 770 apparently already compromised Linux hosts are involved), and further references. "The fact that your rig runs Linux does not mean you're home free. You need to keep paying attention. When your spam washer has been hijacked and tries to break into other people's systems, you urgently need to get your act together, right now."
[+]
Apple: First iPhone Worm Discovered, Rickrolls Jailbroken Phones 215 comments
Unexpof writes "Users of jailbroken iPhones in Australia are reporting that their wallpapers have been changed by a worm to an image of '80s pop icon Rick Astley. This is the first time a worm has been reported in the wild for the Apple iPhone. According to a report by Sophos, the worm, which exploits users who have installed SSH and not changed the default password, hunts for other vulnerable iPhones and infects them. Users are advised to properly secure their jailbroken iPhones with a non-default password, and Sophos says the worm is not harmless, despite its graffiti-like payload: 'Accessing someone else's computing device and changing their data without permission is an offense in many countries — and just as with graffiti there is a cost involved in cleaning-up affected iPhones. ... Other inquisitive hackers may also be tempted to experiment once they read about the world's first iPhone worm. Furthermore, a more malicious hacker could take the code written by ikee and adapt it to have a more sinister payload.'"
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
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: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.
Reply to This
Parent
Put in denyhosts... (Score:3, Interesting)
Reply to This
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.
Reply to This
Parent
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.
Reply to This
Parent
Re: (Score:2)
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.
Reply to This
Parent
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)
Reply to This
Parent
Re:Put in denyhosts... (Score:5, Informative)
or fix your filesystem clients.
Reply to This
Parent
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).
Reply to This
Parent
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
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: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.
Reply to This
Parent
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: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.
Reply to This
Parent
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)
Reply to This
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.
Reply to This
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
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)
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...
Reply to This
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)
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.
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.
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. :)
Reply to This
Re: (Score:2)
For the sake of tradition we should call it a Beowulf cluster. Imagine that.
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
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
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)
Re: (Score:3, Informative)