Security hole in ISPCP 1.0.5

[Alex Joe]

Hello,

Unfortunately, it is possible to compromise the password to the panel and carrying out attack on the server.

IP attacker: 188.249.164 and 62.120.196.147

ISPCP Admin log in attachment. Server logs are destroyed by attacker.

[Nuxwin]

Hello

Ok for logs but you know the procedure for reproduce this attack ? The logs are not relevant. Who is admin, who is reseller, who is customer in the logs ?

---

(07-14-2010 07:38 AM)Alex Joe Wrote:  Hello,

Unfortunately, it is possible to compromise the password to the panel and carrying out attack on the server.

IP attacker: 188.249.164 and 62.120.196.147

ISPCP Admin log in attachment. Server logs are destroyed by attacker.

Edit: What was broken on your server ? Just for the record:

Code:

User IP: 188.249.164.80 11.07.2010 14:54 Warning! user |1tech.pl| requested |/reseller/domain delete
php?domain_id=157| with REQUEST_METHOD |GET|

is not a security hole since a login checking is made by all called scripts. It's just warning.

The warn occurs when an user like admin or customer call the reseller/domain_delete.php?domain_id=123 directly for example.

Now, just for security reasons, I'll inspect better but please, provides us more information.

Best regards ;

[RatS]

It looks like the user has granted access at least as reseller. If not, he was leeching the password somehow (network-sniff, key-logger, social-attack).

The problem is non of the panel directly. You can save the panel from network-sniffing by using SSL.

[Alex Joe]

Unfortunately, as I wrote, server logs have not been preserved. In the attachment, what was left after the attack.

[ZooL]

this .zip is trojan verseucht infiziert

[gOOvER]

I open it with NOD32 and get no Warning

[tomdooley]

While opening the ZIP file I see "PHP/C99Shell.FF"...

[nuke3d]

it's the php file the hacker uploaded, obviously.

[kilburn]

As nuxwin and RatS have already said, there is no evidence of hacking in the provided logfiles. Someone was able to use a reseller/admin account to hijack the websites, but this is password stealing, not a security hole.

Now, if "logfiles haven't been preserved", this means that the attacker was somehow able to obtain root access to the machine (after hijacking the websites). This can happen because (1) there *is* a security hole in ispcp (but we're getting absolutely no clue about where it might be) or (2) he had some outdated software (a service daemon or the kernel itself) that the hacker exploited to escalate privileges.

The point is that we absolutely need more info to discern which was the case.

[joximu]

is it still possible to use cgi programs to change the php.ini?
then this might be the door....

use a security whole in a php- (or cgi)-app of one customer, upload a custom cgi, change the php.ini (if you want to continue with php)... etc

(if the password stealing is not the reason for the issue above)

/J