Proftpd exploit with plesk

joelunch · **Joined:** Tue Aug 17, 2010 12:44 am **Posts:** 7

Hi,

Are people aware of this major exploit with proftpd mentioned on arstechnica?

http://arstechnica.com/business/news/20 ... o-anon.ars

and

http://cve.mitre.org/cgi-bin/cvename.cg ... -2011-4130

Pre 1.3.3g appears to be effected. Any idea of an update being made available?

faris · **Joined:** Thu Dec 09, 2004 11:19 am **Posts:** 1846

The exploit mentioned is just the same SQL injection that was fixed in 8.6 MU2 (etc etc etc) as discussed here and in the various Plesk advisories.

The "SSH via FTP" mentioned seems to be nothing more than allowing shell access to the FTP user. I don't understand why they specifically mention it. Maybe I've misunderstood.

The ProFTP issue they mention is interesting, as I thought 1.3.3c was safe, but in any case the ART repo has 1.3.4a, I think. However, the exploit requires valid FTP credentials, and so isn't quite as bad as it might be.

Unless I have misunderstood what they were saying, of course.

scott · **Posted:** Fri Feb 24, 2012 9:56 am

Yeah they lack full information. There is no exploit in the newer proftp in the context of this attack. What happened is

1) agent.php was exploitable via an sql injection attack.
2) Around the end of january (25th is the oldest event we've had reported) the attackers launched a worm/botnet/etc that:
2a) Enumerated plesk servers globally
2b) Identified vulnerable plesk servers (8.2 thru 10.3)
2c) Dumped the username and password databases from vulnerable plesk servers

At this point the attackers have all the credentials for the enumerated systems. The next major attack happens in mid february
3) Attack uses the vulnerable agent.php injection to upload bot code via the file manager. Note, this is unauthenticated.
4) about this time people start patching the systems, so the agent.php vector is largely going away.
5) As systems are cleaned & patched, the attackers come back using the authentication data they collected in 2c. The upload vectors are: Plesk file manager, ftp, sftp.

So, no exploit (new anyway) in proftpd. They're just using the legitimate credentials enumerated in january to upload file(s) to the system.

mikeshinn · **Posted:** Fri Feb 24, 2012 4:40 pm

And the ASL Plesk WAF protects against the Plesk SQL injection.

breun · **Posted:** Mon Feb 27, 2012 7:04 am

But the ASL Plesk WAF is scheduled for ASL 3.0.20, which is still in testing, right?

scott · **Posted:** Mon Feb 27, 2012 8:16 am

Yeah, we might publish it today

mikeshinn · **Posted:** Mon Feb 27, 2012 5:54 pm

3.0.20 has been released.

EvolutionCrazy · **Joined:** Wed Jun 01, 2005 5:52 pm **Posts:** 67

scott wrote:

3) Attack uses the vulnerable agent.php injection to upload bot code via the file manager. Note, this is unauthenticated.

So it's confirmed that agent.php could be used to upload files and not just to leak data?

scott · **Posted:** Fri Mar 02, 2012 10:18 am

Yes, its a very signifigant vulnerability. You could do anything that plesk can do, without authentication.

EvolutionCrazy · **Joined:** Wed Jun 01, 2005 5:52 pm **Posts:** 67

I'm inspecting a couple machines... and I see POST requests to agent.php

samples:

Code:

./httpsd_access_log.processed:109.206.185.155 XX.XX.XX.XX:8443 - [26/Feb/2012:12:57:51 +0100] "POST /enterprise/control/agent.php HTTP/1.1" 200 1744 "-" "                    -"
./httpsd_access_log.processed:109.206.185.155 XX.XX.XX.XX:8443 - [26/Feb/2012:21:29:16 +0100] "POST /enterprise/control/agent.php HTTP/1.1" 200 14004 "-"                     "-"
./httpsd_access_log.processed:109.206.185.155 XX.XX.XX.XX:8443 - [27/Feb/2012:18:23:04 +0100] "POST /enterprise/control/agent.php HTTP/1.1" 200 1744 "-"                     "-"
./httpsd_access_log.processed:109.206.185.155 XX.XX.XX.XX:8443 - [28/Feb/2012:10:40:52 +0100] "POST /enterprise/control/agent.php HTTP/1.1" 200 14004 "-"                     "-"
./httpsd_access_log.processed:109.206.185.155 XX.XX.XX.XX:8443 - [28/Feb/2012:12:48:47 +0100] "POST /enterprise/control/agent.php HTTP/1.1" 200 14004 "-                    " "-"
./httpsd_access_log.processed:109.206.185.155 XX.XX.XX.XX:8443 - [28/Feb/2012:13:00:26 +0100] "POST /enterprise/control/agent.php HTTP/1.1" 200 14004 "-"                     "-"
./httpsd_access_log.processed.2:64.202.107.236 XX.XX.XX.XX:8443 - [12/Feb/2012:05:15:16 +0100] "POST /enterprise/control/agent.php HTTP/1.1" 200 1868 "-"                     "Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20100101 Firefox/7.0.1"
./httpsd_access_log.processed.3:109.206.185.155 XX.XX.XX.XX:8443 - [10/Feb/2012:15:43:18 +0100] "POST /enterprise/control/agent.php HTTP/1.1" 200 14004 "-                    " "-"
./httpsd_access_log.processed.4:109.206.185.155 XX.XX.XX.XX:8443 - [09/Feb/2012:14:42:18 +0100] "POST /enterprise/control/agent.php HTTP/1.1" 200 1744 "-"                     "-"

To check if there was a leak:

Code:

cp -R /usr/local/psa/admin/logs /root/plesk_logs
cd /root/plesk_logs/logs
gzip -d httpsd_access_log*.gz
grep 'agent.php' ./*

Should do it... if we see a post reply with 1000+bytes reply we can be sure the leak took place right?

I hoped a file upload wasn't possible directly from agent.php

EvolutionCrazy · **Joined:** Wed Jun 01, 2005 5:52 pm **Posts:** 67

add: searching around I see agent.php only mentioned about data leaks...

to upload the file they need to access to .../file-manager/create-file/ or via ftp...

Am I wrong?

scott · **Posted:** Fri Mar 02, 2012 12:45 pm

Yeah that, ftp, or ssh since they can dump out the user db

EvolutionCrazy · **Joined:** Wed Jun 01, 2005 5:52 pm **Posts:** 67

so: I do not see uploads via ftp, I do not see accesso file manager (or any other file in plesk admin interface), I do not see ssh access...

can we suppose it was just an information leak withou modifications/uploads?

As for now I saw only agent.php references that were not standard... no uploads via ftp... and no plesk logins or other plesk requests...
How can we be sure that agent.php can't modify/upload files and was just able to "leak" infos?

scott · **Posted:** Sat Mar 03, 2012 12:29 pm

Quote:

can we suppose it was just an information leak withou modifications/uploads?

Unless you captured the attack somehow, theres no way to know really

Quote:

can we suppose it was just an information leak withou modifications/uploads?

Tough to say unless you've got the whole attack. It could be a recon, it could involve injecting data into the system (say another admin account for example), and recently we had one piece of malware submitted that was written to the filesystem outside of ftp, ssh or the filemanager. I suspect it was via adding a cron job that wrote this file to the disk.

Quote:

How can we be sure that agent.php can't modify/upload files and was just able to "leak" infos?

I couldnt have said that better. Forensics always comes down to "How do you know?"

EvolutionCrazy · **Joined:** Wed Jun 01, 2005 5:52 pm **Posts:** 67

scott wrote:

Quote:

How can we be sure that agent.php can't modify/upload files and was just able to "leak" infos?

I couldnt have said that better. Forensics always comes down to "How do you know?"

Yeah, you are fully right.

But I think it's in Parallels best interests to let us know what can be done with a POST request to agent.php.
Or does anybody that got a server running with plesk before september 2011 have to consider it "rooted"? :/

Proftpd exploit with plesk

Who is online