What do you mean by "humbling lesson"? If anyone finds an unpatched flaw and uses it to exploit some servers, then it doesn't matter who takes care of the servers. It doesn't matter if it's ptacek or a random admin. It's a new, unknown problem (if the claim about a 0day is real).
Also they're "hacking" the frontend web server. Is that post really interesting in any way? They didn't get to any sensitive information (or didn't publish it). They also didn't get into any personal system, so I doubt there was any real harm done. (otherwise they would brag about it even more)
What do you mean by "humbling lesson"? If anyone finds an unpatched flaw and uses it to exploit some servers, then it doesn't matter who takes care of the servers. It doesn't matter if it's ptacek or a random admin. It's a new, unknown problem (if the claim about a 0day is real).
The experts at Matasano should know better than to leave sshd internet-accessible. That's what is humbling, because exposing the smallest possible attack surface is exactly how you defend against an unknown problem, and there's literally no good reason (besides laziness) to leave sshd exposed to the public internet.
Also they're "hacking" the frontend web server. Is that post really interesting in any way? They didn't get to any sensitive information (or didn't publish it). They also didn't get into any personal system, so I doubt there was any real harm done. (otherwise they would brag about it even more)
Or, they simply didn't bother going further -- owning the front-end web server is fairly embarassing for a company like Matasano.
Quite a few individuals store their credentials on front-end web servers, or even SSH to other servers from the front-end servers. Owning -any- server is often a very big deal.
Agreed on the first point. It's true that minimising the amount of random input will help your security. That will always be true. It was only their fault that they don't limit the access.
OTOH, they have to run public services in an accessible way. Someone could just as well find a bug in their webserver, or mail server. It's bad for PR of course, if their webserver is hacked. But not all servers are equal. (here starts the IMHO part) If you want to spend your time on making everything perfectly secure, you're a full time sysadmin, not a security researcher ;) I think that there are a lot of test, web, mail, etc. servers that people just don't treat as very valuable. Every webserver could be virtualised and the whole system could be checked in a loop by a securely signed checksum verifier which sends (every cycle) results using PKI to a vpn'ed server which sends you an sms if your index.php checksum doesn't match (and snapshot + suspend the machine along with memory, then bring a failover up via a non-lan channel). Is it worth their time though?
People can think that makes the company look bad, I don't...
I'm a bit confused - how are you supposed to ssh in if sshd is not internet-accessible? If you're suggesting only allowing access through a VPN, what's the advantage? Is a VPN significantly less likely to be exploitable than SSH? Or are you saying that you should only be able to SSH in via the local network?
Is a VPN significantly less likely to be exploitable than SSH?
Yes, for a few reasons.
First, a VPN provides defense in-depth -- compromising a server now requires finding two unpatched vulnerabilities:
* You must find a vulnerability in the VPN implementation that allows you to leverage the VPN or the VPN host to forward your traffic.
* You must then find an additional vulnerability to use against the actual secured hosts made available over the VPN connection.
There should be a firewall between the VPN entry-point and your internal networks, to limit access to unapproved services.
As a single point of entry, a VPN is also easier to secure. If all servers are inaccessible except for approved services, then a single server running an unapproved vulnerable service (or an account with a weak password or key) does not open the door to immediate external compromise.
This single entry point also allows you to offset the likelyhood of user failure (such as choosing poor passwords) by using additional two-factor authentication. RSA SecurID or PKCS#11 are often too heavyweight for using every time you want to SSH'ing into a host, but they're far more reasonable for initially connecting to the VPN.
There's also the configuration to consider. Using PSK or aggressive mode for VPNs can be considered bad but are you really going to deploy a full RADIUS solution just to access a web server?
Compare this to using public key based auth on SSH, I know which one I'd rather have for a web server.
Not necessarily. What about exploiting VPN clients?
IPSec is a disaster, one aspect of which is having a client daemon listening on an open port for isakmp/ike key exchange.
There's also the configuration to consider. Using PSK or aggressive mode for VPNs can be considered bad but are you really going to deploy a full RADIUS solution just to access a web server?
Provisionally "yes", but I'd actually use OpenVPN, wired into our existing directory infrastructure.
Compare this to using public key based auth on SSH, I know which one I'd rather have for a web server.
Why do you consider it a net win to reduce the entry barrier to only one exploit, one bad user password, or one misconfigured host?
A common solution is to whitelist IP addresses, or a range of them. This is obviously inconvenient in many cases, but is much more secure than allowing all to connect, especially in situations where there is a new 0 day.
There's nothing wrong with leaving SSH open on a web server - provided it's locked down. How that gets locked down is down to the risk appetite of those responsible.
"there's literally no good reason (besides laziness) to leave sshd exposed to the public internet."
Well, besides the fact that it's a whole lot more convenient to just be able to ssh into somewhere without frigging around with VPN or what not. For most businesses, I would say having accessible ssh (with good passwords, and a properly set up, up-to-date system) is fine.
But yeah, for a "security" business .. it's pretty surprising they let it hang out like that. And on port 22 and the www domain, too .. tsk tsk.
If there is an option between a convenient way to do something and an inconvenient (but much secure) way to do the same thing. You should do it the inconvenient way, specially if you make a living in security.
If you're at home, running OpenBSD on your own computer, then security can be inconvenient as you want it. But if you run security for a business, you have to balance confidentiality and integrity with availability (and sometimes some other concerns). Shell access from the internet could be important to availability--obviously, this was the wrong way to do it, but it wasn't a wrong objective.
I agree with your point, but I do want to point out that mail theft (by postal workers, errant receivers, and malicious thieves) is not so uncommon. I have had a few things mailed without tracking numbers that I strongly suspect were stolen (mailed from post offices with complaints of theft or undelivered mail).
If anyone finds an unpatched flaw and uses it to exploit some servers, then it doesn't matter who takes care of the servers. It doesn't matter if it's ptacek or a random admin. It's a new, unknown problem (if the claim about a 0day is real).
matasano isn't a firewall or antivirus company, their main business is code auditing and penetration testing. they are paid to find bugs in their customers' code before the "bad guys" do to minimize the risk of 0-day vulnerabilities.
i know it's not practical for them to audit every line of code in every piece of software that their web server runs, but this type of attack looks much worse for this type of company than it probably would for any other.
They didn't get to any sensitive information (or didn't publish it). They also didn't get into any personal system, so I doubt there was any real harm done.
in the output posted on the site, one user has a bunch of zip files in his home directory with "playbook" in the name (playbook is their firewall revision control product). some "real harm" could come from this attacker distributing the source code to their product, if that is indeed what was in those files.
I'd agree that this is mostly a PR problem; but for a security company, having your public site hacked is somewhat embarrassing.
But it is humbling, since this was probably set up much better than the average linux webserver. If these guys can still be vulnerable then noone can be confident. When it comes to computer security we are for the most part working with very poor tools and even less understanding when it comes to building systems that are both tractable and secure.
No one should be confident. Given enough time and resources, practically any system will fall, typically due to human error (bad passwords being the biggest problem). I'd imagine more resources would be required to hack into a web server set up by a security company, but the rewards, in the form of publicity, for anti-sec are much greater.
Anyone who believes they can have a "secure" system connected to the internet is largely kidding themselves. There are ways to minimize this risk, but there really isn't any way (as far as I'm aware) to completely eradicate it.
My servers' SSH isn't publicly accessible, you first need to be logged in to VPN (OpenVPN). I don't why Matasano couldn't secure their system like this, especially that some "0-day SSH exploit" is circulating around web. And if you're paranoid (or security expert on war-path with whaddyacallthem anti-sec movement) you have even more simple ways to secure yourself - port knocking for example?
Your system's security weakest link should be human not software.
First, a VPN would best be used as an additional layer of security for the whole network, not as a shell for one particular box. Second, a group very publically announced, by hacking imageshack, that they were going after full-disclosure security blogs. A little later, they warned that they had an ssh 0-day. The prudent thing for a full-disclosure security blog to do would be to put some additional security around their internet-facing ssh.
It depends. If it's the same box and you can get root from exploiting OpenVPN than nothing. But if you are doing this correct - running OpenVPN on non-critical server that serves as entry point for the rest of the network than you just got yourself extra layer of security. It's like probability that there are two bombs on the plane.
Well, my point is, why anyone would leave SSH open like that on critical server. Don't want to set up whole VPN or using things like port-knocking? Just configure your damn firewall to accept only connections from your IP. Wow, I mean, there's million things I can think of to minimize your risk from single ssh 0-day exploit and I'm not even sys admin.
Well, the posted log, could be a complete fabrication. It certainly doesn't contain anything useful and may in fact be deliberately misleading.
I'm hoping that Thomas and the rest of the crew do perform an intensive and public analysis of the exploit. It wouldn't surprise me if the break was in Wordpress or one of the other application level programs.
Who cares? It's not like they wrote or consulted on whatever was hacked, and there isn't enough time in the day to write every piece of software you use from scratch. This is what you get for writing your OS in high-level assembly.
Since they are against disclosing vulnerabilities, it seems more likely that these intruders did not gain access through an unknown SSH exploit, but some other way. Once obtaining root, they could paste some proof of being on the system, and simply combine that with the top portion of their log which may be completely fabricated to appear as a 0-day exploit.
Again, if there really is a SSH 0-day, why is an anti-disclosure group revealing one exists?
Saying that there is a vulnerability is nowhere close to revealing it. For example, I can say that Windows has a vulnerability allowing me to crash the system. If you are a Microsoft developer, does that information help you track down the issue? Not in the least, as you don't have any idea where to look
There's nothing valuable or productive about their inane, impossible-to-read 'hack logs' and they're not encouraging any sort of useful discussion.
It's just dick-waving, and it's stupid for people to continually post links to their latest escapades on sites like HN and reddit.
I mean seriously. How can you feel good about linking to a thread that has tripe like this in it?
"Death to the Jews, death to the whitehats. All parasites must be destroyed in kind!"