+- ispCP - Board - Support (http://www.isp-control.net/forum)
+-- Forum: ispCP Omega Development Area (/forum-1.html)
+--- Forum: Tickets / Roadmap / Timeline (/forum-50.html)
+--- Thread: Security hole in ISPCP 1.0.5 (/thread-11172.html)
Pages: 1 2
RE: Security hole in ISPCP 1.0.5 - Alex Joe - 07-17-2010 05:43 AM
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.
RE: Security hole in ISPCP 1.0.5 - kilburn - 07-20-2010 08:32 PM
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)... etcHacking 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).
RE: Security hole in ISPCP 1.0.5 - Alex Joe - 07-20-2010 09:13 PM
Quote:instead of the MACHINE logfiles (those in /var/log).
Exactly this logs (var/log) were destroyed
RE: Security hole in ISPCP 1.0.5 - nuke3d - 07-20-2010 09:23 PM
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.
RE: Security hole in ISPCP 1.0.5 - Alex Joe - 07-20-2010 10:22 PM
Quote:Do you have the same passwords...no I haven't.
RE: Security hole in ISPCP 1.0.5 - joximu - 07-20-2010 11:16 PM
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