Forgot your password?
typodupeerror
Security Linux

The "Hail Mary Cloud" Is Growing 102

Posted by Soulskill
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.'"
This discussion has been archived. No new comments can be posted.

The "Hail Mary Cloud" Is Growing

Comments Filter:
  • 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, Insightful)

      by FunPika (1551249)

      (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."

      • by Opportunist (166417) on Sunday November 15, 2009 @04:23PM (#30108464)

        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)

          by herojig (1625143)
          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?
    • 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)

    by Tangential (266113) on Sunday November 15, 2009 @01:36PM (#30106762) Homepage
    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. "
    • Re: (Score:1, Funny)

      by Anonymous Coward

      denyhosts is security through obscurity much like changing the default port for SSH... or so I'm told.

      • by Gerald (9696)

        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.

        • by fwarren (579763)

          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)

        by sjames (1099)

        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).

      • by jofer (946112) on Sunday November 15, 2009 @04:10PM (#30108330)

        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.

        • by Cozminsky (452030)

          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.

    • by Anonymous Coward on Sunday November 15, 2009 @01:44PM (#30106826)

      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)

        by masshuu (1260516)

        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.

      • by Predius (560344) <[josh.coombs] [at] [gmail.com]> on Sunday November 15, 2009 @03:28PM (#30107822)

        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.

        • by Culture20 (968837)
          If only denyhosts would open up the server portion. Some people want the functionality of the denyhosts server in their organization without having to participate in (or rely on) the global DB.
        • by doug (926)

          Oh, I get it. We build a cloud to fight their cloud.

    • Better would be to use public key/private key pairs and disallow username/password logins.

    • by l2718 (514756) on Sunday November 15, 2009 @02:06PM (#30106980)

      Denyhosts ... "filter[s] out requests ... by ... blocking the originating IP addresses."

      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.

    • by David Gerard (12369) <slashdot AT davidgerard DOT co DOT uk> on Sunday November 15, 2009 @02:22PM (#30107134) Homepage
      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.
    • by emurphy42 (631808)
      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.)
    • by jimicus (737525) on Sunday November 15, 2009 @02:50PM (#30107472)

      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)

      by v1 (525388)

      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

  • 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.

    • by elsJake (1129889)
      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.
      • by geekboy642 (799087) on Sunday November 15, 2009 @01:53PM (#30106886) Journal

        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)

      by certain death (947081)
      You have a router in front of your iPhone?!? WOW! I have GOT to get that app.
      • Re: (Score:3, Informative)

        by ceoyoyo (59147)

        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)

    by byrdfl3w (1193387) on Sunday November 15, 2009 @01:39PM (#30106788) Journal
    Hail Mary's... Deamons... Rick Astley.. The final battle is closer than we ever imagined.
  • 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)

      by turtleshadow (180842)

      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

      • 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)

          by ToasterMonkey (467067)

          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

          • 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.

            • 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.

              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)

      by TheRaven64 (641858)
      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.
      • Re: (Score:3, Interesting)

        by causality (777677)

        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)

      by ceoyoyo (59147)

      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)

        by Web Goddess (133348)

        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

        • by ceoyoyo (59147)

          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.

  • by Radhruin (875377) on Sunday November 15, 2009 @02:02PM (#30106950)

    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.

    • by 0123456 (636235)

      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

        • user names, too (Score:3, Informative)

          by reiisi (1211052)

          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

        • by Bert64 (520050)

          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

    • 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)

      • by ceoyoyo (59147)

        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.

    • by nurb432 (527695)

      And if a machine that has your public key on it is compromised ?

      • Re: (Score:2, Informative)

        by mr_flea (776124)
        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.)
      • by nedlohs (1335013)

        Do you know what the word "public" means?

        Can you see how it makes that irrelevant?

      • by dkf (304284)

        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

    • by shentino (1139071)

      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.

  • by damn_registrars (1103043) <damn.registrars@gmail.com> on Sunday November 15, 2009 @02:11PM (#30107026) Homepage Journal
    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...

    • Re: (Score:2, Insightful)

      by zigziggityzoo (915650)
      I changed SSH to a nonstandard port and reduced attempts by 95%. Then I started a whitelist (hosts.allow) for SSH. That took care of the rest.
      • 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

      • I changed SSH to a nonstandard port and reduced attempts by 95%.

        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?

    • by Daimanta (1140543)

      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.

    • by ceoyoyo (59147)

      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.
      • by Bert64 (520050)

        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.

    • by TheEden (1213710)
      Port forwarding is a great thing btw. I changed ssh port from 22 to something like 4254 or whatever, and that was really helpful in my case.
      • 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
    • by DusterBar (881355)

      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.

  • 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.
    • by ceoyoyo (59147)

      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.

      • by Bert64 (520050)

        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.

        • by ceoyoyo (59147)

          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.

  • by Hurricane78 (562437) <.gro.todhsals. .ta. .deteled.> on Sunday November 15, 2009 @02:32PM (#30107230)

    s/cloud/network/

    There. Done it for ya. Was that so hard?

    We should make a Greasemonkey script out of it. :)

    • For the sake of tradition we should call it a Beowulf cluster. Imagine that.

      • 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. :)

        • 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. ^^

    • Then reading Final fantasy VII faqs and Meterology websites would get really strange.

  • 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

  • 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

Machines that have broken down will work perfectly when the repairman arrives.

Working...