Not to dis on the kernel, but this notion needs to be addressed. Quite frequently when viewing the community forums, when someone asks a question about potentially having malware on their box, about 9 out 10 ten times someone with a big reputation comes along and says something like "I would not worry about it, you're not on Windows anymore." Then, 8 times out of 10, the person who started the thread says "OK", no further investigation is done. This is a dangerous attitude, and it's simply not true.
There is always that guy (you know the one) who drops in with his 20,000 reputation and 100 badges, and says "I've been using Unix for 30 years now, and in all that time I have never actually seen a rootkit, only false positives." Well, I have only been using Linux for 3 or 4 years, and I've seen malware. In fact, just last night I found something that looked a lot like malware inside one of my own systems. In order to do so, I had to boot to a Kali live disk and run some extensive tests. Both chkrootkit and rkhunter initially only me a bunch of warnings, but than I ran this command...
chkrootkit -x | egrep '^/'
, which find strings inside binaries, and I was absolutely shocked at what I saw. Many programs in /bin had been replaced by symlinks that were very difficult to navigate through because they were very complex, and linked through many directories before ending up at /etc/alternatives, or /etc/.java (don't ignore those unnecessary compiler warnings). I saved the output of that command (which what 1.7 mbs long), and unfortunately, I seem to have lost the file, which sucks because I really wanted to show you what I'm talking about. I guess you're having to take my word for it. Usually this happens because of bad security practices, but I take insane security precautions! I use 40 character random strings for all passwords, have really tight firewall rules, run linux, use 4096 bit RSA keys for ssh (wish ecdsa would work), etc. The truth is I don't know how it happened, but I intend to find out. So after I fixed that server, I started to try to exploit all my own servers and the services running on them. So far, it's been pretty eye opening.
When one starts to learn about offensive security, one realizes computers are really vulnerable when misconfigured (or lazily configured). I never really like the idea of the whole cat and mouse/crack and patch approach to security. I figured that if you just build the damn thing from the ground up with security as the first priority, than you are good. And, yeah that turned out to be true. However, that approach does not work if you are, for instance... using someone else's content management system. You might do that because you don't feel like studying the php manual for 6 weeks before launching your own blog. I hear you. Recently I deployed a php cms without pentesting it first. When I finally did pentest the site, I discovered multiple severe vulnerabilities including remote OS command injection. I was even running mod security (but had not take the time to read that manual either). I scanned it with skipfish, discovered some low threat XSS vulnerabilities, it didn't seem like a big deal. But than I scanned it with OSWAP, which is like metasploit community edition for HTTP servers. This program gave me exactly the information I needed to both exploit my site, and fix it. One reason I choose this CMS is because I fucking hate sql, and this app did not need it. SQL is a nightmare, and probably the most exploited protocol on the net today. Have you ever tried to salvage a corrupt database? Nooo thanks. But php configured the way that it is out of the box is a recipe for disaster. It's a great example of default permit. For God's sake, the developers ought to ship it with command execution disabled. If someone needs that feature, they should have to enable it themselves so that they understand the risks.
Anyway, a few hours of Googling, and I had most of the vulnerabilities on the site patched. The patches were all very simple things like setting the correct http headers, cache controls, mod security & php.ini directives, blah blah . I barely had to edit any of the actual php. So, crack and patch has it's place. There is definitively no substitute for building your program securely, and your mantra should be default deny.
On the age old 'linux can't get malware' argument, I say yes it can, but it does not have to. Linux has more than enough tools you can use to prevent these kind of things from happening, and they're all free. On a closed platform like Microsoft Windows, which also happens to have a huge multi billion dollar antivirus industry that depends on those insecurities, bad things will happen. But on an open source, community driven platform with an incentive to function correctly, bad thing generally open happen if you let them. I suppose the biggest lesson I've learned thus far with the offense approach is to not trust other people's code. Besides, it's pretty fun (and totally legal) to try to exploit that code, when it's running on your own server. That's all for today.
No comments:
Post a Comment