3 months and 1M SSH attempts later | Hacker News Reader

3 months and 1M SSH attempts later

livesshattack.net

> "Hahahahahaha, a successful login"

Congratulations, you just violated the computer fraud and abuse act. Also, bravo for laying out for every reader of this post where they can find the vulnerable router and the credentials they can use to join you in breaking the law.

This is the exact opposite of responsible disclosure; people like the author are why we will never get a less draconian cfaa. Thanks for that.

My thoughts exactly ... and he posted the IP addresses, passwords & usernames of the sites he was able to access. Stupid.

>Congratulations, you just violated the computer fraud and abuse act. How can that be illegal?

Granted publishing it should be, but simply testing if someone has left the default password?

CFAA is very broad. "intentionally accesses a computer without authorization or exceeds authorized access, and thereby obtains— C) information from any protected computer;"

A court could see "ambiate was authorized to use the work printer for printing -- ambiate hacked the printer to find out the fax machine number and sent a fax" in an absurd world.

This random internet person was never authorized to access this public router. Even if its set to a default username/password. That's the broadness the CFAA.

Just because you set your password to 'password99', doesn't mean you get more protections than the person who leaves their Cisco router set to 'cisco'.

Thanks for the info. Interesting, I can see the merit in having broad legal protection to stop people from malicious activity. But that does seem a little too broad.

Oh yeah. The "default password==consent" argument has not worked well.

This is one of the big differences between many professional penetration testers, and enthusiastic amateurs/blue team types. The professional red teamer has typically received long lectures about scope and RoE, and knows exactly how far you can legally go. Check the webpage that corresponds to some suspicious sshd log entries and note that it's a router? Totally fine. Attempt to notify the owner? Equally fine (pro-tip, you might not know who they are, but their ISP sure does). Brute-force their admin credentials (I recognize the hyperbole; the judge won't)? Hand-cuffs.

https://ilt.eff.org/index.php/Computer_Fraud_and_Abuse_Act_(...

My apologies. I have blocked out the content to prevent any further harm.

The phrase "responsible disclosure" exists only to frame full and public disclosure as irresponsible, which it is not.

It is victim blaming to lay the tyranny of the state at the feet of those who are doing research and publishing unredacted results, even if this specific author is indeed a moron.

And also, the fact that billions of people could theoretically do what this guy did, is why the cfaa etc. is stupid. If you need to keep billions from making naughty voltage patterns to their modem ... you're doomed. You're just gonna have to fix the cfaa.

On a tangent, how will the next generation of hackers learn the ropes? Will they be hopelessly outclassed by their foreign peers?

More or less the same way we did? Reading about vulnerabilities, reviewing metasploit modules, fuzzing applications on your local box, reading hack post-mortems (all of which is SOOO much easier than it used to be).

They will also have the huge leg-up of being able to download vm images like Kali and DamnVulnerable{Linux, WebApp} to practice with/on. When I think about how much time I spent early in my career hand-rolling a vulnerable machine so I could try out some new msf module, only to crash my laptop when it executed and have to start over...

This myth that everyone learned by hacking actual websites etc, and therefore this is the only (or even the best) way to learn needs to die in fire. Lots of elite practitioners learned their craft without doing anything that would be considered remotely illegal.

> He's still going at it 100,000 ssh attempts later.

I got hit with >100,000 on my main desktop a few years ago when I was procrastinating fixing my heavy-handed fail2ban config. I noticed what was happening first from the lag it was causing. It turns out >10 SSH password attempts/second can eat up a significant portion of my 3GHz "Yorkfield"[1] CPU. It wasn't hard to discover the problem: the logfile was rapidly filling with failed SSH password attempts. This is particularly useless as I have used

    PasswordAuthentication no

for many years. There is no chance that the script was going to gain access, but the system load from the rejections was terrible. So yes, I fixed fail2ban and added a few more "instant-ban" rules against anybody that tries password authentication, but the real fix that was moving sshd to a random port. Invalid SSH connection attempts dropped to approximately zero immediately. It's trivial to find with a port scan, but in practice almost nobody has even bothered.

It's probably like the old joke where two hiker see a grizzly bear and one stops to re-tie his shoes. "You can't outrun a grizzly!" "I only have to outrun you."

[1] Q9650 (E0); it still works great, even if it's starting to show its age

Out of curiosity, why is your desktop exposed directly to the internet (no NAT/firewall) at all?

NAT doesn't provide security, and a ssh server isn't useful if you filter that port at the firewall.

Masquerading private address with you GW public address and limit connection to outhoing one when ingress filtering is correctly done on your firewall/ISP side is quite efficient.

Using private address is just a convenient way to set up easy invariant templates for FW rules. No more, no less.

If you add the fact that ISP used to not route RFC 1918, it used to work quite efficiently.

That "convenient way" has been incredibly damaging to the internet. The primary benefit of the internet was that every peer can publish without needing permission of a 3rd party. IP Masquerading / NAT removes that ability, and has cause a massive amount of centralization. These gatekeepers are necessary to workaround the limitations of every host having to share a party line. Regular use of RFC 1918 for most hosts has prevented the development of real network software.

If you want the internet to continue to degrade into something closer to cable TV, then continue requiring central gatekeepers. If, instead, you care about the future of the internet, then please use globally routable addresses instead of the imprimatur we call NAT.

one of the benefit of NATing that it is mentally easier to recongize inbound and outbound traffic in firewall rules.

It has been used as a way to centralize traffic by some rogue ISP, and then because Large Scale Nating involve to hold in memory a lot of state considered bad practices because it was costing money to ISPs. (plus FW redondancy/HA in NAT require to synchronize states with CARP or CISCO techs).

But NATing behind the POP of the customer behind a public IP with the classical 3 ways filtering (corporate net, DMZ, internet) still enables templates to be easily shared and understood.

It is not NAT that sux. It is incompetent sysadmins the problem.

> NATing that it is mentally easier

"Because it's easier" is a terrible reason to break the internet and limit the development of networking software such that proper direct-connections (in either peer-or-peer or client-server style) are useless and a centralized 3rd party is required to negotiate the connection and/or manage the NAT hole-punching.

You're talking about convenience for a specific set of tools, when the problem is about freedom to publish without middlemen.

> a way to centralize traffic by some rogue ISP

ISPs have little[1] to do with this. I'm not talking about centralization by the ISPs; I'm talking about how network software such as VOIP should be making direct connections once the address is known, which is impossible due to NAT. Instead, we have Skype with Microsoft in a de facto position of control over a lot of the "voice chat" ecosystem.

> enables templates to be easily shared and understood

I'm sure the file-format for those templates can be extended to support a placeholder/variable/macro for local addresses.

> NATing behind the POP of the customer

That's my entire point. This is how the internet was turned into a "two tier" system, where some hosts can use listen(2)/accept(2) usefully, but everyone else has to ask permission of the incumbent feudal lord for permission if they want to accept a connection.

You seem to prefer trading that ability for an internet that resembles the "cable tv" model instead of a network of equal peers (in the protocol). I hope having convenient firewall templates was worth it.

[1] other than dragging their feet on IPv6 for the last ~15 years, which removes the need for any type fo NAT

Its interesting how many HN users seem to be missing the point of a honeypot. He set this up deliberately to understand the frequency/types of attacks on a random machine on the internet.

From my past experience, most of those CN computers are actually US zero day'd/patched running root kits/worms. It just happens to be that CN computers are more likely to be unpatched/running ancient software.

>From my past experience

I'm curious how you know this for sure.

I plead the fifth. CFAA/RICO/Patriot Act.

My hint would be: before decentralized worms, there were IRC hubs. The 'owners' would typically use their native language for the various commands (I know English is used in more than the US, but..). Most of the time, they wouldn't even hide their host name on the IRC server.

I guess from a 'being legal' POV: anyone could infect themselves with the same root kit that's on a honeypot and find out quite a bit about the organizers.

Or just read any botnet takedown report, this is exactly what botnets do. Why bother looking for 0day when root:toor or cisco:cisco works?

what is a CN computer?

CN = china. So, computers based in china, although I am at a loss as to what the thread parent is saying exactly about "CN computers actually being US". Same with "zero day'd/patched" — aren’t those opposite notions?

It's a little unclear, but if I were to guess I'd say they meant the machines are located in China but have been zero day'd, then patched and root-kitted by the attacker, who was in the US (or at least not China)

Just FYI, I wouldn't log into any systems using credentials you find through this. A lot of people are obviously using credentials stolen from previous dumps, so there might be valid ones in there. Logging into a public facing router using stolen credentials is definitely a crime.

Just like it's a crime trying to ssh into a box that is not yours right? And besides I didn't do anything to the router. I was simply pointing out that you should change your default credentials and hide your router.

... should be a crime to not change the default credentials.

Did you attempt to notify that poor schmuck who stood up that AirRouter with the default username and password?

Damn it. I should of. I don't know how I would do that now though. He probably got pwned of the internet by now. lol.

Dude, it's not funny. You're coming across like a script kiddie and it's not welcome here. You've just posted the credentials to someone's site that has probably been compromised and you're treating it like a joke. Go back and redact the IP addresses of those sites & devices before you get yourself into trouble.

Um. I guaran-damn-tee you that the router in question was compromised within a day or seven of it being stood up.

The default credentials on every bit of UBNT hardware that I've used grant access to both the web UI and admin SSH access. So, the access attempts that WillieStevenson has noticed coming from that IP are most likely coming from the router itself.

I can't see any reasonable reason for redacting the IPs that are making those access attempts, and I see no reason at all for redacting static, factory default usernames and passwords.

Look. Malicious boxes are attacking me. Although I must be politically correct in this situation to probably please everyone, while I probably shouldn't have logged into the router in question, I would prefer to publish such IPs because they have the potential to harm other machines.

Actually that particular IP attacked me more than 170 times. It may be useful to others to keep this address on their "naughty" list of hosts to ban.

I don't think there's a need to publish those addresses. There are already lists with those IPs available (https://www.openbl.org/). Telling people that the IP had default password on the router will only cause the problem to the owner who may not even be aware of the attack. Proxies / worms for ssh scanning are very common, so maybe you just helped people break some Joe Random's home network.

> I don't think there's a need to publish those addresses. There are already lists with those IPs available...

Interestingly, the IP address of that router is _not_ present in either the base (attacks within the past 360 days) list or the delisted (manually removed from the base list by the person in question) list.

It's almost like no single list is terribly likely to be complete, and that publishing collation of a master list is required for completeness. :)

Pretty clear that he'd been popped already, you realize that's what all of those ptr records that are IP.ISP are, right? Some random person who clicked on something they shouldn't have and is now part of a botnet which is continuously trying to brute force other boxes.

> Some random person who clicked on something they shouldn't have and is now part of a botnet which is continuously trying to brute force other boxes.

No. Some random sysadmin stood up some business-tier gear and failed to change the factory default, static username and password. He then also failed to restrict access to the built-in web server and SSH server to only a trusted set of machines.

You ever hear the saying "Two wrongs don't make a right"?

I'm not saying the machines attacking you aren't violating the law. I'm saying that publishing an IP address of someone's router, along with step by step directions of how to log into it, along with screenshots of you logging into it, is a violation of the computer fraud and abuse act. The law doesn't care where you got the address. And the reality is that that router's owner probably has no idea they are part of a botnet attacking other machines. I suggest you go back to university and take a few computer ethics courses before you wind up with a criminal record from your next project.

Just for fun I ran an SSH server on a RasPi to basically allow any login and to simulate a Linux shell. And then captured the various things that people tried. If you're wondering what the "standard set" of script kiddy tricks are, I highly recommend it.

15 years ago, that standard set used to be wget something from packetstormsecurity.org. If no wget: curl it. If no curl: just lynx it. else: move on to the next vulnerable server. Script kiddies were quite lazy back then. I feel old at thirty.

Hasn't changed for the most part. Though it's either exploit db, some creepy looking .pw site you've never heard of, and once or twice, the zips that github provides. And sometimes they'll just scp their stuff onto the box.

"World's worst hacker" is pretty amusing: https://www.youtube.com/watch?v=oJagxe-Gvpw

If you haven't already, get fail2ban setup on the box to slow down all the attacks. And disable password login and switch to certs instead.

SSH key based auth does not use certificates.

In the case of key-based-auth only, fail2ban is pointless.

I wouldn't say pointless. It wastes an attacker's time if nothing else, otherwise you're essentially allowing that attacker to continue interacting with your server, and perhaps SSH isn't their only target.

I disagree. I run it because I drop all traffic from the /24 the scan comes from. Harsh, yes, but tough luck. It cuts down on unwanted network traffic.

That's a pretty significant denial of service you open yourself up to. If someone shows up bruteforcing you from randomly allocated AWS or Digital Ocean cloud instance public IPs that happen to land in the same /24 as other AWS- or DO-hosted services (Heroku comes to mind, but also any other monitoring, log aggregation, analytics, data processing, et c) your machine depends on, they've convinced your system to cut connectivity to them. Not the best setup...

Actually it can use certificates. Not X509, but still simplified ones.

fail2ban also reduces spam in your auth log and prods the bot to move along to the next target.

It can quite easily protect against things other than failed ssh attempts - I used to regularly configure it to blackhole IPs failing to log in correctly to WordPress backends... Anything else the box does that uses some form of authentication that writes out failures to a log file can be hooked up to fail2ban.

tdicola: To authenticate myself, I use an ssh key. However, the goal of this project was to log all attacks over ssh. So setting up fail2ban and disabling password login would prohibit this collection of data. I have a massive password in place, so I'm not worried in the least.

Better yet, deploy OSSEC there. I would recommend it with the latest patches from here:

https://dcid.me/ossec/

It's just another thing you need running on the server that must stay patched forever.

In my opinion less is better. RSA/4096-bit key encryption only. I don't even care if you use the root user. The ability for someone to crack a 4096-bit key is impossible in practice, and if your SSH server has a bug then it doesn't matter what fancy things you have setup.

It is fine for a 1-man server, but if you have multiple users and you have to be on top of things, then you need a bit more than that.

Specially to look at successful logins and audit where they come from. This is a good blog post on the subject:

https://blog.sucuri.net/2016/03/server-security-anomaly-beha...

I changed my SSH login banner text to

> Permission denied, please try again.

To confuse people. No matter failed or successful login, the prompt text will always be like that.

You deny them permission, then grant them permission to try again?

No matter failed or successful login, the prompt text will always be

> Permission denied, please try again

I think more cloud providers should do something like what Google Compute Cloud does, they have SSHGuard on their images by default so IPs get blocked after too many failed attempts.

Showing off stuff like this is considered stupid, childish and idiotic. Based on the cache version of his publication, I am extremely tempted to report this to the proper authority. Not only you should stop publishing this kind of information, you should stop your project.

> Showing off stuff like this is considered stupid, childish and idiotic. ... Not only you should stop publishing this kind of information, you should stop your project.

I strongly disagree with both sentences.

Change the SSH port...

The point was to have a look at what kind of attacks are launched on the general internet, so the point was to be attacked.

Also, changing the port does basically nothing these days, with stuff like Shodan around constantly port-scanning.

Like I mentioned above, changing the SSH port would only lessen the attempts on my box. I am interested in collecting as much data as possible.

Please don't rely on that alone: https://blog.shodan.io/hiding-in-plain-sight/

strangely, searching Shodan for product:ssh port:443 finds nothing - when I know there are boxes around running sslh or similar to run both SSH and HTTPS on the same port. Seems like you can hide in plain sight when the scanner has no idea you're there.

https://www.shodan.io/search?query=port%3A80+openssh

It's really just a matter of time. There are many things you can do to protect yourself and changing the port is one of them, but if you rely on it you're going to have a bad time.

Try this: https://www.shodan.io/search?query=port%3A443+product%3A%22O...

Reply on news.ycombinator.com