[MAYBE URGENT] vulnerabilities in plesk

[perler]

hi,

this morning my logcheck spit something out what looks like a break in attempt somehow related to plesk.

my system is a debian 3.1 box, sshd accepts only key authentication for root, but to provide the secure shell functionality to plesk customers, for plesk users, keyboard authentication is allowed. here is what the log says:

Jul 15 06:20:56 sshd[22152]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.75.9 4.50 user=root
Jul 15 06:20:56 sshd[22152]: Authentication started for user root
Jul 15 06:20:56 sshd[22152]: Plesk DB connection established successfully
Jul 15 06:20:56 sshd[22152]: Querying SELECT password, type FROM psa.accounts as a, psa.sys_users AS s WHERE a.id = s.account_id AND s.login='root'
Jul 15 06:20:56 sshd[22152]: No user 'root' found
Jul 15 06:20:58 sshd[22152]: error: PAM: Authentication failure for root from 218.75.94.50
Jul 15 06:21:02 sshd[22152]: Authentication started for user root
Jul 15 06:21:02 sshd[22152]: Plesk DB connection established successfully
Jul 15 06:21:02 sshd[22152]: Querying SELECT password, type FROM psa.accounts as a, psa.sys_users AS s WHERE a.id = s.account_id AND s.login='root'
Jul 15 06:21:02 sshd[22152]: No user 'root' found
Jul 15 06:21:03 sshd[22152]: error: PAM: Authentication failure for root from 218.75.94.50
Jul 15 06:21:04 sshd[22152]: (pam_unix) 1 more authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=2 18.75.94.50 user=root

for me, this looks like the attacker knows something about a vulnerability which may allow him to read out the plesk password database.

[UPDATE]
unfortunately i don't have debug logging enabled for my mysql db so i cannot see if the attacker was successful with his SQL query. if someone is logging his mysql db in debug mode and suffers from the same attacks, please have a look and report here, thanks
[/UPDATE]

[UPDATE2]
i run the query the attacker tried on my servers and it didn't return anything, because i don't have a user "root". but, if the attacker knows a username and the attack /would/ work, he would have the plain text password to an account in plesk.
[/UPDATE2]

[UPDATE3]
ok, this looks serious. i simulated the attacker and when the query above queries for a KNOWN user (not root), in the servers logs the plesk users password can be seen in plain text. i'm not sure if the attacker can log the information I can see on MY server somehow on HIS client, but if yes, he /could/ read out plesk users passwords.

what is very disturbing is, that while sshd authentication, mysql accepts queries and spits out results although "keyboard interactive" as authentication method is disabled.
[/UPDATE3]

i cannot see that it worked out in my case, but maybe other users get more problems, so, before further investigating the case, i give here an early warning, check you logs!

i give this info to swsoft too.

feedback welcome,

PAT

 

[aluminum]

follow up

This seems like some serious stuff.. do you have any further updates on this matter?

Did you got a reply from sw?
keep we updated

 

[perler]

the attacks stopped over the day (but did continue for some hours), the script hammerd brainless at the same exploit, so it was definitely automated.

the attack came from an internet cafe in china.

swsoft was informed by me and they told me, that my support period is over and i should buy a support plan. :/ you can imagine what my answer to that was

i think too, that is serious, but really don't know what to do further and for examining and posting to bugtraq i just can't fnd the time right now..

the problem seems to lie in the plesk pam module because that is the only interface you can talk to while logging into sshd IMHO.

PAT

 

[wagnerch]

I am quite perplexed why you think this is an exploit. It looks like to me that SWsoft was just a bit sloppy and they are logging debugging code to syslog. People trying to brute force the root password is a fact of life on the Internet.

In any case this appears that it is a Debian specific port, Fedora doesn't seem to have any custom PAM modules that are installed by Plesk. If I were speculating (not jumping to conclusions) I would say that under Debian it appears to have some sort of "virtual" jail via sshd clients, because it is not authenticating through the typical UNIX mechanisms and is instead using the "psa" database.

But if you want to be certain, then you should chase your PAM configuration. Start with PAM's sshd configuration, and I am sure it will include a pam_stack.so service=system-auth line -- so you should look in the system-auth PAM configuration.

 

[carliebentley]

Firewall Module

Isn't there a firewall module in Plesk that would allow you to quickly block ssh from any IP address except your own?

Wouldn't that be the simplest cure?

 

[wagnerch]

Re: Firewall Module

Originally posted by carliebentley
Isn't there a firewall module in Plesk that would allow you to quickly block ssh from any IP address except your own?

Wouldn't that be the simplest cure?

My experience is the stateful firewalls are a bit too finnicky, the simplest solution for me was to move the sshd port from 22 to another port. Naturally it only works if you do not offer shell service.

 

[atomicturtle]

How is maintaining state going to make it finnicky? All that means is that its looking at the whole stream of a stateful session, as opposed to each packet individually (aka a Packet filter). Stateless packet filtering is easy to beat, fragmenting your traffic will bypass the filter.

Moving the port buys you practically nothing, if your intent is to stop brute force attacks. A far more effective mechanism to achieve that is to eliminate password based authentication alltogether, and use SSH key authentication only.

There are several very basic firewall strategies to use for ssh access:
1) restrict access to the service with iptables (ex: default DENY INPUT policy, iptables -A INPUT -p tcp --dport 22 -s <your IP> -j ACCEPT
2) use port-knocking to unlock the port (connect to some sequence of ports, like a combination lock, which triggers the above)
3) use rate limiting on the traffic:
iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j LOG --log-prefix "RATELIMIT: "
iptables -I INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

 

[perler]

Originally posted by atomicturtle
Moving the port buys you practically nothing, if your intent is to stop brute force attacks. A far more effective mechanism to achieve that is to eliminate password based authentication alltogether, and use SSH key authentication only.

to get back to the topic - as i wrote, my sshd doesn't accept password authentication - but the "exploit" is still there.

wagnerch, why i still think it is an exploit is, that some guys from an internet cafe in china know, that plesk stores cleartext passwords in it's database and they are able to pass SQL statements to mysql when it definitely shouldn't be possible (/while/ ssh logins) - what else then a potential exploit is this?

PAT

 

[wagnerch]

I tried the recent module, and it just simply didn't work. It was probably related to this.

I more or less didn't bother wasting my time on it any more.

 

[wagnerch]

I disagree, it isn't someone passing SQL. It is debugging from a custom SWsoft authentication module. But I guess you are free to speculate as much as you want, but you certainley haven't provided any hard evidence.

Why don't you simply look at your PAM modules & configuration and see if there is something nonstandard there?

You really need to look at the messages you posted, why would a hacker advertise in your syslog that they successfully connected to the Plesk DB? why would a hacker advertise in your syslog the supposed SQL injection? It just seems unrealistic. If it is a SQL injection or buffer overflow attack then 99% of the time there is little evidence in syslog that indicates what they are trying to do.

 

[wagnerch]

Since you didn't post your sshd configuration either, I doubt you really have password authentication disabled.

Anyways, it is probably your configuration. You can look here for some things to check.

 

[atomicturtle]

Indeed that is correct, you're seeing the logging output for ssh tied into SQL via a custom PAM module. If you did disable password based authentication (PasswordAuthentication no), then you are immune to a brute force attack in that configuration. There is an advantage to still seeing that information in your logs, in the next major ASL release we're including a shared blacklist capability, which would let you share an attackers IP with your other systems, automatically. We do this on an internet scale with "AtomicRBL", which works just like an anti-spam RBL, but populated with attackers IP's.

wag- the --set flag was not fully merged into 2.6 until 2.6.14.6, or if you were using p-o-m, by december 05. The latest p-o-m updates on recent are due to be merged into 2.6.18 (alledgedly, they said that about 2.6.17). I can confirm that those rules below however work on 2.6.14.6 now.

 

[perler]

PasswordAuthentication no
PermitEmptyPasswords no

%}

but, even /with/ password authentication enabled, an ssh client shouldn't be able to send SQL statements to mysqld - how hard is this to understand?!



PAT

 

[wagnerch]

but, even /with/ password authentication enabled, an ssh client shouldn't be able to send SQL statements to mysqld - how hard is this to understand?!

Did you follow the link? How hard is that to understand?

Clearly password authentication is not disabled. And the ssh client IS NOT SENDING SQL, jesus christ.


Since you are probably not going to follow the link, I guess I will just bring the water to you:

jack wrote:
> How can I re-enable this wonderful feature!

Comment out "UsePAM yes" (or change it to 'no') and restart ssh.

Keith

 

[wagnerch]

Originally posted by atomicturtle
Indeed that is correct, you're seeing the logging output for ssh tied into SQL via a custom PAM module. If you did disable password based authentication (PasswordAuthentication no), then you are immune to a brute force attack in that configuration.

It appears on Debian they created a UsePAM parameter and that parameter overrides the PasswordAuthentication setting. If I were to take a wild guess PasswordAuthentication (on debian) probably only comes into play when UsePAM is set to no, and in those conditions it probably uses standard password authentication (getpwent(), crypt(), et. al.)

In any case there are some valid reasons for having password authentication disabled, and then there are clearly some valid reasons to have it enabled. I personally leave it enable, incase I lose my private key (or do not have access to the host it is stored on) and cannot do a keyed authentication. Additionally I moved the port, because none of my clients are given shell access.

There is an advantage to still seeing that information in your logs, in the next major ASL release we're including a shared blacklist capability, which would let you share an attackers IP with your other systems, automatically. We do this on an internet scale with "AtomicRBL", which works just like an anti-spam RBL, but populated with attackers IP's.

I worked on something similiar to this with mynetwatchman.com, a shared blacklist that would inject entries into the firewall.

wag- the --set flag was not fully merged into 2.6 until 2.6.14.6, or if you were using p-o-m, by december 05. The latest p-o-m updates on recent are due to be merged into 2.6.18 (alledgedly, they said that about 2.6.17). I can confirm that those rules below however work on 2.6.14.6 now.

I am still running 2.6.10 on Fedora Core 2, I wonder if they backported the patch -- probably not since it is in Legacy maintenance mode. I haven't bothered to build kernels by hand since before 2.4. Once modules were introduced, didn't need to bother . I can still remember rebuilding 1.2.13 and 2.0 kernels.

At this point I will probably stick with Fedora Core 2, since the box is remote. I am thinking about testing a migration from FC2 to CentOS4 via yum, need something a bit more stable and will have maintenance release for the next 4 or so years.