Question and Tips about "anonymousfox"

[lacuna]

Hello, I hope I'm not breaking any rule or creating a duplicated topic but I wanted to ask for tips to prevent situations like these.
To go straight to the point, somehow the login page for my website redirected to a scam site cloning "Amazon Prime" interface.
We found out these two ftp accounts:

[email protected]
AND
[email protected]

plus some files, like a folder called "sss".

those things appeared all of a sudden and we don't know how.
Our webpage is quite small, one person is using it.

I would like to know how did it happen and some tips to increase the security and (of course) avoiding situations like this, I hope the information I provided is enough. Thanks in advance!

 

[keat63]

I've seen this mentioned before, are you using WordPress ??

 

[lacuna]

I remember that at first we used the "Site Publisher" tool from CPanel to check if our domain was working, but then we put our own website's files and folders (We use CodeIgniter Framework). Tho we didn't delete those files created by the Site Publisher. I don't know if that tool uses WordPress or such. Thank you for your comment!

 

[cPanelLauren]

This kind of activity can be achieved by a compromised password, script or plugin used on the site. It isn't just Wordpress related. I would strongly suggest you not only enlist the services of a qualified system administrator to audit your installations and security but you must identify the point of entry or the issue will continue to occur. If you don't have a system administrator you might find one here: System Administration Services

 

[MortensenMedia]

I remember that at first we used the "Site Publisher" tool from CPanel to check if our domain was working, but then we put our own website's files and folders (We use CodeIgniter Framework). Tho we didn't delete those files created by the Site Publisher. I don't know if that tool uses WordPress or such. Thank you for your comment!

Hi Lacuna,

Did you get any answers that could help us. We are in the same situation?

Best regards, Joel

 

[Mario Kos]

Hello, we have similar problem, but at whole WHM dedicated server. At many user accounts new email account "[email protected]" showed up. We managed to intercept cpanel password change notification mails to this adress. We disabled ability for users to reset passwords right after. Somehow attacker still manages to change user passwords.
We run cloudlinux7 and cpanel 90.
Seems also, attacker managet to route user cpanel notifications to this emails, and not the ones that are registered within each user's account.
Any suggestions?

 

[Kent Brockman]

Hi there. I now found how they do it. They take advantage of vulnerable WordPress and Prestashop plugins to upload a tool capable of editing accounts. Then they simply edit the email address in /.contactemail file. Then reset cpanel password using the new email, and then they obtain access to cPanel.

THE PROBlEM IS THE WAY CPANEL STORE THE CONTACT EMAIL DATA WITHIN THAT FILE. It shouldn't be stored in plain text. cPanel needs to improve this. Name it using readonly permissions, or cipher the content of the file.

 

[JoeF_UK]

Hi there. I now found how they do it. They take advantage of vulnerable WordPress and Prestashop plugins to upload a tool capable of editing accounts. Then they simply edit the email address in /.contactemail file. Then reset cpanel password using the new email, and then they obtain access to cPanel.

THE PROBlEM IS THE WAY CPANEL STORE THE CONTACT EMAIL DATA WITHIN THAT FILE. It shouldn't be stored in plain text. cPanel needs to improve this. Name it using readonly permissions, or cipher the content of the file.

I have had this issue twice this week. I have mitigated it by disabling password reset in whm.

 

[pinchies]

From my own digging last week, I came to a similar conclusion, and I changed the permissions on that file to hopefully add stronger protection. CPanel needs to add their own stronger protections from cases like this.
In my case, I found that file had been modified with a bogus guerrillamail account. The plugin that was compromised on my site was WP File Manager - just check the reviews for more evidence that this is a recent thing...

 

[JoeF_UK]

From my own digging last week, I came to a similar conclusion, and I changed the permissions on that file to hopefully add stronger protection. CPanel needs to add their own stronger protections from cases like this.
In my case, I found that file had been modified with a bogus guerrillamail account. The plugin that was compromised on my site was WP File Manager - just check the reviews for more evidence that this is a recent thing...

I removed WP file manager the first time it happened and fully disinfected still managed to happen again though.

 

[cPanelLauren]

I am going to point out that the cause of this issue and the primary problem here is that old, outdated, vulnerable scripts are being exploited on your server. cPanel has no control over the content you allow on your server. When you retain these kinds of vulnerable items you put the account at risk in a number of ways. This is far larger than .contactemail and the responsibility lies on you or your system administrator to maintain security on the server.

I will note that there has been a case open for .contactemail changes for some time, as a result of this kind of behavior but there are no updates to this case and it is not resolved nor do I have an estimate on when it will be.

 

[pinchies]

That's a fair reply -- the only thing I would add, is that web admins would typically consider the attack surface to be the site they manage, inside the site root. It was eyeopening to me to see a vector like this being used and exploited. Normally a hacker would go for the easiest option -- if this is .contactemail (and the evidence suggests that it's clearly a popular target) then perhaps there's a case to expedite an improvement in this area.

 

[sparek-3]

What?!? You mean as an end-user I have to keep my scripts and plugins up to date? Geez Louise! That's too much work. Why can't I just install WordPress and my elventy billion plugins and ride off into the sunset? Why does this have to be my responsibility?

/s

 

[cPanelLauren]

That's a fair reply -- the only thing I would add, is that web admins would typically consider the attack surface to be the site they manage, inside the site root. It was eyeopening to me to see a vector like this being used and exploited. Normally a hacker would go for the easiest option -- if this is .contactemail (and the evidence suggests that it's clearly a popular target) then perhaps there's a case to expedite an improvement in this area.

While I don't disagree that potentially exploitable outlets should be managed if possible, the same can be said for vulnerabilities that take advantage of mail or forwarders, and code injections. Once you allow access to an attacker, even though not on purpose you leave yourself vulnerable to a plethora of different means of attack. If you're maintaining the security of the scripts applications and plugins on your server you vastly and almost completely eliminate the chances of something of this nature occurring.

 

[Kent Brockman]

While I don't disagree that potentially exploitable outlets should be managed if possible, the same can be said for vulnerabilities that take advantage of mail or forwarders, and code injections. Once you allow access to an attacker, even though not on purpose you leave yourself vulnerable to a plethora of different means of attack. If you're maintaining the security of the scripts applications and plugins on your server you vastly and almost completely eliminate the chances of something of this nature occurring.

Yes. And nope. I know you are very busy and yes, you are doing a decent work. But now that you are aware that such an specific and simplistic way to take ownership of an account is being widely exploited, you (CPANEL) should do something. We do our best to keep things working and assured, but if a plain text file can be so easily exploitable, you should do something guys.

AT THE VERY LEAST, make the "Reset Password" option disabled by default on Tweak Settings, so that future installs won't suffer the same (unrecognized) vulnerability. And of course, make clear in the description, that "if you enable this and a vulnerable script allows upload of malware, this option may be used to gain access to such an account".

 

[sparek-3]

Yea, but where are you going to draw the line at?

If your WordPress (or whatever CMS or script) gets exploited... then guess what? ... your email passwords shadow file is writeable by that user, all they have to do is modify the hash on one of the accounts... and voila! instant account to spam with.

The common denominator is... your WordPress or whatever script being exploited. That's where the action's got to stop. You can put bandaid solutions up all over the place, but until people realize that they have to keep their script up to date, and they have to limit themselves to reputable plugins and keep those updated. There's just only so much that an administrator or an administrative tool can do stop this.

We still have people using "password" as their WordPress password because they don't think anything bad is going to happen to their account. How is a server administrator suppose to guard against that? How is cPanel suppose to guard against that? And what if they're not using WordPress, what if they're using Billy Bob's Content Management Script, is cPanel suppose to guard against that? People have got to start waking up to some responsibility for what they are or are not doing.

 

[pinchies]

Sarcastic comments are unhelpful. No one is saying the users don't have a responsibility, or that they need to do better; they do, and I agree. We all know that the strengths of Wordpress can also be its weaknesses. We all need to do our best, and cPanel is being called on to help in this fight. I do not considering hardening applications to be 'bandaid' solutions. I'm not asking cPanel to patch wordpress bugs or to take responsibility for poorly coded plugins - I'm specifically saying that if cPanel is going to offer integration to help users, they need to be careful that they are not adding additional blind spots or vulnerabilities that the average wordpress user isn't informed about.

 

[Kent Brockman]

I know that @sparek-3. I'm tired of saying all of that to the people since almost 10 years ago, and both developers and designers don't give a f***. I can and I actually do, obviously, suspend compromised accounts. All the time. And as the number of vulnerable plugins raise, the number of accounts to suspend do it as well. It's a non-stop problem. In fact, it's more like a snowball, cause majority of developers and designers create subdomains to host dev versions for their clients and sometimes all of those sites got infected.

You cannot patch the user's mind. I'm a sysadmin, not an evangelist or a psychologist . It has to be anything else to do in order to prevent scripts from writing outside of public_html space or, in fact, outside of the whatever folder the (sub)domain is assigned to work in.

Everything outside public_html should be read only for the scripts the users upload. No way to do that?

 

[cPanelLauren]

Everything outside public_html should be read only for the scripts the users upload. No way to do that?

Really, even that wouldn't resolve the issue here, as the script that's added isn't done so outside of the public_html it's executing from within the public_html and modifying something outside the public_html which is a perfectly normal activity for a script to do in most cases. There is no privilege escalation that takes place here, it's all contained within the user's own account.

 

[Kent Brockman]

Really, even that wouldn't resolve the issue here, as the script that's added isn't done so outside of the public_html it's executing from within the public_html and modifying something outside the public_html which is a perfectly normal activity for a script to do in most cases. There is no privilege escalation that takes place here, it's all contained within the user's own account.

I know. I know. Sorry for the desperate answer. What actually worked now to stop the spread on vulnerable sites was disabling the ability to reset cPanel passwords in Tweak Settings.