6 ms·
Mayhem – A hidden threat for *nix web servers
- dang 12y agoUrl changed from http://www.itnews.com.au/News/390053,new-mayhem-malware-targets-linux-unix-servers.aspx http://www.itnews.com.au/News/390053,new-mayhem-malware-targ..., which points to this.
- nobullet 12y agoSo I assume I'm safe if I have no PHP on server?
- vmiroshnikov 12y agoIts not about PHP, any vulnerable software may be used for infection. PS You're safe if you have no server :)
- nitrogen 12y agoThe malware described in the article uses PHP.
- milkshakes 12y agothe php dropper discussed is the least interesting part of the article. it could be implemented in any language.
- shitlord 12y agoFurthermore, if your web server (or database server, or any other interet-facing service) is vulnerable, it won't matter which programming language you are using. Assume that all input is hostile.
- mintplant2 12y agoOnly as the dropper. Presumably the other parts of the malware (libworker.so, etc.) could be repurposed and coupled with a different infection system.
- nitrogen 12y agoGood crap, 4 downvotes for a factual statement with no hints of aggression or disdainfulness?
- girvo 12y agoI'm assuming the down votes are because you missed the point of your parent. The example uses a PHP script for uploading the payload, but that can be swapped out for nearly any language on a server. They all require an exploit to get the dropper on there anyway, so that's a barrier. PHP isn't the point here though, it's the interesting damage the exploit that gets pulled down by the dropper can achieve, without needing to use privilege escalation.
- vmiroshnikov 12y agoIn case you get 503 error, article snapshot at http://www.peeep.us/9dcbdec9 http://www.peeep.us/9dcbdec9
- ck2 12y agoSigh, if only people this clever were trying to do good in this world.
- InclinedPlane 12y agoThe number of people this clever or more doing good in the world is enormous, but their exploits largely go unnoticed and unheralded. Because things going well can often be difficult to differentiate from a non-event. Think about all of the sophisticated technology behind something as common as smartphone. Or, just think about the clever folks working on, say, the linux kernel. Other than Linus most of those people are not famous and a great many people who use linux every day don't even realize they are doing so or know anyone involved with the project, even Linus (such as android phone users, anyone who uses a website or service hosted on linux, people who use devices running linux in the firmware, etc.)
- ejr 12y agoThis is a very well reasoned point. Thank you for writing this.
- jbangert 12y agoAs far as malware attacks go, this seems to be pretty run-of-the-mill (no clever vulnerabilities used). The key seems to be that the automated malware dropping is adapted to all sorts of 'restricted environments' (i.e. chroot, virtual servers, non-root accounts, etc). It doesn't look like there is any privilege escalation involved (which, say in the case of most targeted attacks, there usually is).
- nwh 12y agoI think the point of the article was showing that none were really needed to still cause massive damage.
- INTPenis 12y ago> I think the point of the article was showing that none were really needed to still cause massive damage. No privilege escalation needed? I disagree, this article shows nothing new at all unless it shows how the malware gains privileges on the system. As an SELinux user that is what I am most interested in. Normally these malwares make it in through some poorly secured web server, in my experience.
- ejr 12y agoWhile the dropper was written in PHP, it's important to keep in mind that Perl, Python or other language could just as easily have been used. If you're using a shared host that otherwise doesn't allow many configuration changes, you're very limited in what you can do to protect yourself. If you use PHP, you can add the following to php.ini to mitigate risks like these (mitigate != bulletproof) : ; Mayhem dropper uses "system" so let's kill that and other dangerous functions disable_functions = system,eval,curl_exec,curl_multi_exec,exec,passthru,shell_exec,show_source If this breaks your software, your software is badly written. Allowing write permissions in the script directory is always a dangerous thing. It's best to put the application files outside root and enable execute permissions only on the script directory. If uploading files is allowed, it should be to read/write enabled directories only. Execute permissions should be turned off. The dropper tries to kill critical processes as mentioned so chrooting services individually is a good idea. Or you could just use OpenBSD ;-)
- donatj 12y ago> If this breaks your software, your software is badly written. That's a silly blanket statment. There are times a system call is nessessary. Also there's a lot more ways to get system calls than you list, namely the deadly back tick operator, as well as process control just as a start. Update: Also curl_exec? cUrl is how you do ANYTHING http more advanced than fetching with a few headers. Everything that accesses any sort of API in a serious manner will use cUrl.
- ejr 12y agoThe list is limited to a very specific set of functions that PHP is an ill fit to utilise and I have never seen used in a positive context. These are best done with a non-scripted program or perhaps Python. Of course, no matter the language used, input sanitising is essential. Edit: Since you've edited your post to add cURL to your criticism, please note I originally replied "These are best done with a non-scripted program or perhaps Python" for exactly this reason. Much of the criticism of PHP can be leveled against its misuse as much as the language's own shortcomings.
- donatj 12y agoI read and then rescanned as best I could, does the article actually bother to explain the infection process? How the code gets on the system? Presumably I have to get this onto my system via some flaw for it to be executed. I mean of course you can be a pain in the ass with limited access, I didn't realize that was up for debate. That's not that interesting as I see it. Actual vulnerabilities relating to holes these things can get through to get onto your system is what we need to be worried about. The attack it self seems pretty run of the mill for shared hosting attacks as we had seen many of at my previous job, often infecting through old unpatched Wordpress installations, old copies of phpbb and plesk admins. Honestly I curse Wordpress to this day for the trouble it would cause us.
- jasey 12y agoRemote file inclusion (RFI) Brute force FTP accounts Brute force logins, eg wordpress login
- rurban 12y agoroot_ordner: german only word
- Chromozon 12y agoCan someone explain how this infects and gets activated on a system? It sounds like I have to download a certain PHP file onto the system and then execute it. Is this correct, or are attackers using other ways to automatically start the malware?
- ejr 12y agoThe dropper has to be present on the server somehow to get the rest of the payload so you have to have uploaded it there, allowed a user to upload it[1] or be in some way included by a malformed script or some other existing vulnerability. This includes a very large scope of potential access points. Ex: This particular sample was in PHP so Wordpress comes to mind. Plugins in particular are notorious for poor programming practices that allow such file inclusions. [1] Disallowing by extension doesn't always work as some filters allow img.php.png or img.png.php. Besides this, an image can skip the .php altogether and still be executed as a PHP script Ex: https://security.stackexchange.com/a/32970 https://security.stackexchange.com/a/32970 and https://security.stackexchange.com/a/32969 https://security.stackexchange.com/a/32969 Note however, this doesn't just apply to PHP. There are potential vectors in Perl, Python and Ruby when adequate measures are not taken to sanitise user input and filter arbitrary uploads.
- singlow 12y agoIt's important to not only to try to prevent them from being uploaded, but to make sure that any directory which is writable by the web server or php engine, is not executable. In the case of WordPress, this can largely be mitigated by using specific location parameters in nginx which allow the execution of your intended entry points such as the primary index.php file, rather than a blanket fastcgi forward for all urls ending in .php. `location ~ .php$ { [forward to fcgi] }` This is a common configuration that allows the client to execute any php file within the web root. If you accidentally allow a php file to be uploaded, it may be executed. Instead something like the following means that the web server will not allow arbitrary php files to be executed, only the ones you want to be executed: `location ~ /(index\.php|wp-admin/ajax.php)$ { [cgi] }` (Just an approximation - I don't feel like looking up the exact expression I use.)
- Zardoz84 12y agoInteresting ... now How detect if is it (or any other similar ) on our web servers ? And How remove it and protect against it ?