Security hole in ISPCP 1.0.5

[Alex Joe]

Quote:he had some outdated software

The server (kernel) was updated to the last stable versions of packets. I had installed & configured fail2ban, logwatch, blocked ports by iptables. I don't send my passwords by email and never published whole internet and my local machine. I don't know how he get the password to the reseller account.

[kilburn]

Quote: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

Hacking a website will give you access as the corresponding vuXXXX user (and you don't need to change the domain's php.ini for that). Anyway, vuXXXX users doesn't have access to the control panel (neither as reseller nor as user). Hence, hacking a website is not an attack vector to obtain admin/reseller credentials...

Quote:The server (kernel) was updated to the last stable versions of packets. I had installed & configured fail2ban, logwatch, blocked ports by iptables. I don't send my passwords by email and never published whole internet and my local machine. I don't know how he get the password to the reseller account.

I must insist that a reseller should not be able to run commands as root. Therefore, along with the reseller password stealing, the attacker *must* have used another attack to obtain root privileges (if he/she really obtained root privileges at all).

I'm starting to suspect that the server logs weren't really destroyed. It simply makes no sense at all for the attacker to spend so many time changing ftp account's passwords to replace the website's files if he had root access. Hence, I think that by "logfiles were destroyed" you are referring to the USER logfiles (those stored in /var/www/virtual/domain.com/logs) instead of the MACHINE logfiles (those in /var/log).

[Alex Joe]

Quote:instead of the MACHINE logfiles (those in /var/log).

Exactly this logs (var/log) were destroyed

[nuke3d]

Even if he had root access, how would he find out the admin panel login? Do you have the same passwords for root & admin (or admin/reseller, or root/reseller)?

I think one possibility to execute commands as root would be if the files in /var/www/ispcp could somehow be accessed with write permissions through an exploit in ispcp or another service that you might have running. Still courious why he wouldn't just set a new password for root an be done with it, though.

[Alex Joe]

Quote:Do you have the same passwords...

no I haven't.

[joximu]

Well - if /var/log *is* destroyed then someone needs root privileges.

But with root privileges you do not need to create ftp users in the panel...

So there were maybe two incidents???

Finding an ispcp login password should only be possible with/by sniffing or social engineering (or try and error - if you have the hash).

Reading the ispcp-login-hash needs access to the ispcp database - which needs a mysql root-privileged account...

Indeed very strange what happened here...

/J