Current time: 12-10-2019, 01:06 PM Hello There, Guest! (LoginRegister)


Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Security hole in ISPCP 1.0.5
Author Message
Alex Joe Offline
Junior Member
*

Posts: 72
Joined: Oct 2007
Reputation: 0
Post: #11
RE: Security hole in ISPCP 1.0.5
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.
07-17-2010 05:43 AM
Visit this user's website Find all posts by this user Quote this message in a reply
kilburn Offline
Development Team
*****
Dev Team

Posts: 2,182
Joined: Feb 2007
Reputation: 34
Post: #12
RE: Security hole in ISPCP 1.0.5
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).
07-20-2010 08:32 PM
Visit this user's website Find all posts by this user Quote this message in a reply
Alex Joe Offline
Junior Member
*

Posts: 72
Joined: Oct 2007
Reputation: 0
Post: #13
RE: Security hole in ISPCP 1.0.5
Quote:instead of the MACHINE logfiles (those in /var/log).

Exactly this logs (var/log) were destroyed Sad
07-20-2010 09:13 PM
Visit this user's website Find all posts by this user Quote this message in a reply
nuke3d Offline
Junior Member
*

Posts: 107
Joined: Sep 2007
Reputation: 1
Post: #14
RE: Security hole in ISPCP 1.0.5
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.
07-20-2010 09:23 PM
Find all posts by this user Quote this message in a reply
Alex Joe Offline
Junior Member
*

Posts: 72
Joined: Oct 2007
Reputation: 0
Post: #15
RE: Security hole in ISPCP 1.0.5
Quote:Do you have the same passwords...
no I haven't.
07-20-2010 10:22 PM
Visit this user's website Find all posts by this user Quote this message in a reply
joximu Offline
helper
*****
Moderators

Posts: 7,024
Joined: Jan 2007
Reputation: 92
Post: #16
RE: Security hole in ISPCP 1.0.5
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
07-20-2010 11:16 PM
Visit this user's website Find all posts by this user Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)