The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

WHM Compromised

Discussion in 'General Discussion' started by jcase, Mar 8, 2005.

  1. jcase

    jcase Well-Known Member

    Joined:
    Jun 1, 2004
    Messages:
    50
    Likes Received:
    0
    Trophy Points:
    6
    Due to the lovely security hole in thr "forgot password link" someone gained access to my server, and is changing the accounts on my server, as well as continually changing the root password. I upgraded to the latest stable version as well as updated php to 5.0.3 and changed all passwords and I awoke this morning and he is still in there changing peoples information. What is it that I need to do to get this guy out, I have no idea how he is accessing the server after changing ALL the information. Any help would be appreciated.
     
  2. easyhoster1

    easyhoster1 Well-Known Member

    Joined:
    Sep 25, 2003
    Messages:
    659
    Likes Received:
    0
    Trophy Points:
    16
    To start with make sure in WHM>>Tweak Settings

    Allow cPanel users to reset their password via email

    Is unchecked and restart cpanel.
     
    #2 easyhoster1, Mar 8, 2005
    Last edited: Mar 8, 2005
  3. jcase

    jcase Well-Known Member

    Joined:
    Jun 1, 2004
    Messages:
    50
    Likes Received:
    0
    Trophy Points:
    6
    I have done this, as well as the fact that I changed ALL passwords yesterday and then restarted the box. Today, this guy has changed other accounts as well..... Really dont know what to do at this point.
     
  4. rpmws

    rpmws Well-Known Member

    Joined:
    Aug 14, 2001
    Messages:
    1,824
    Likes Received:
    5
    Trophy Points:
    38
    Location:
    back woods of NC, USA
    just curious what you are doing to get back in after they change the root passowrd? are you sure you don't have a reseller account that has root privilages now? anyone in your wheel that shouldn't be? so this box isn't rooted with a kit but basically they have you passwords?
     
  5. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    Go on, have a guess
    Also, whoch version of WHM/cPanel are you running? Have you checked for root compromises using chkrootkit and/or rkhunter? If you believe it's a WHM hack, have you notified cPanel? Have you checked for vulnerable PHP and/or perl CGI scripts on the server that someone may be using as a way into the server?

    If they're in and they did indeed have root access, you basically cannot trust the server anymore. Your best bet would be to get the server offline, find out how they got in, reload the OS, restore users from backup and then secure your box to prevent them getting back in.
     
  6. jcase

    jcase Well-Known Member

    Joined:
    Jun 1, 2004
    Messages:
    50
    Likes Received:
    0
    Trophy Points:
    6
    I checked for root kits, only thing that came up was something about bind, Ill post more about it later. Tehy sent the root history to dev > null. fixed that. Saw the following users in /etc/passwd "toor" "#" as well as the fact that another user was added to wheel. I had a shell open throughout the night thats how i was able to reset the password. I am running the latest "stable" release of whm.
     
  7. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    Go on, have a guess
    Does the toor user in /etc/passwd have a UID or GID of 0? i.e.:

    toor:x:0:0:
     
  8. jcase

    jcase Well-Known Member

    Joined:
    Jun 1, 2004
    Messages:
    50
    Likes Received:
    0
    Trophy Points:
    6
    Didnt check, i just removed it, heres a rootkit check:

    ns# ./chkrootkit
    ROOTDIR is `/'
    Checking `amd'... not infected
    Checking `basename'... not infected
    Checking `biff'... not infected
    Checking `chfn'... not infected
    Checking `chsh'... not infected
    Checking `cron'... not infected
    Checking `date'... not infected
    Checking `du'... not infected
    Checking `dirname'... not infected
    Checking `echo'... not infected
    Checking `egrep'... not infected
    Checking `env'... not infected
    Checking `find'... not infected
    Checking `fingerd'... not infected
    Checking `gpm'... not found
    Checking `grep'... not infected
    Checking `hdparm'... not found
    Checking `su'... not infected
    Checking `ifconfig'... not infected
    Checking `inetd'... not infected
    Checking `inetdconf'... not infected
    Checking `identd'... not found
    Checking `init'... not infected
    Checking `killall'... not infected
    Checking `ldsopreload'... not tested
    Checking `login'... not infected
    Checking `ls'... not infected
    Checking `lsof'... not found
    Checking `mail'... not infected
    Checking `mingetty'... not found
    Checking `netstat'... not infected
    Checking `named'... not infected
    Checking `passwd'... not infected
    Checking `pidof'... not found
    Checking `pop2'... not found
    Checking `pop3'... not found
    Checking `ps'... not infected
    Checking `pstree'... not found
    Checking `rpcinfo'... not infected
    Checking `rlogind'... not infected
    Checking `rshd'... not infected
    Checking `slogin'... not infected
    Checking `sendmail'... not infected
    Checking `sshd'... not infected
    Checking `syslogd'... not infected
    Checking `tar'... not infected
    Checking `tcpd'... not infected
    Checking `tcpdump'... not infected
    Checking `top'... not infected
    Checking `telnetd'... not infected
    Checking `timed'... not infected
    Checking `traceroute'... not infected
    Checking `vdir'... not found
    Checking `w'... not infected
    Checking `write'... not infected
    Checking `aliens'... no suspect files
    Searching for sniffer's logs, it may take a while... nothing found
    Searching for HiDrootkit's default dir... nothing found
    Searching for t0rn's default files and dirs... nothing found
    Searching for t0rn's v8 defaults... nothing found
    Searching for Lion Worm default files and dirs... nothing found
    Searching for RSHA's default files and dir... nothing found
    Searching for RH-Sharpe's default files... nothing found
    Searching for Ambient's rootkit (ark) default files and dirs... nothing found
    Searching for suspicious files and dirs, it may take a while...
    /usr/lib/php/.registry /usr/lib/php/.lock /usr/lib/php/.filemap
    /usr/lib/php/.registry
    Searching for LPD Worm files and dirs... nothing found
    Searching for Ramen Worm files and dirs... nothing found
    Searching for Maniac files and dirs... nothing found
    Searching for RK17 files and dirs... nothing found
    Searching for Ducoci rootkit... nothing found
    Searching for Adore Worm... nothing found
    Searching for ShitC Worm... nothing found
    Searching for Omega Worm... nothing found
    Searching for Sadmind/IIS Worm... nothing found
    Searching for MonKit... nothing found
    Searching for Showtee... nothing found
    Searching for OpticKit... nothing found
    Searching for T.R.K... nothing found
    Searching for Mithra... nothing found
    Searching for OBSD rk v1... nothing found
    Searching for LOC rootkit... nothing found
    Searching for Romanian rootkit... nothing found
    Searching for Suckit rootkit... nothing found
    Searching for Volc rootkit... nothing found
    Searching for Gold2 rootkit... nothing found
    Searching for TC2 Worm default files and dirs... nothing found
    Searching for Anonoying rootkit default files and dirs... nothing found
    Searching for ZK rootkit default files and dirs... nothing found
    Searching for ShKit rootkit default files and dirs... nothing found
    Searching for AjaKit rootkit default files and dirs... nothing found
    Searching for zaRwT rootkit default files and dirs... nothing found
    Searching for Madalin rootkit default files... nothing found
    Searching for Fu rootkit default files... nothing found
    Searching for ESRK rootkit default files... nothing found
    Searching for anomalies in shell history files... nothing found
    Checking `asp'... not infected
    Checking `bindshell'... INFECTED (PORTS: 465)
    Checking `lkm'... chkproc: not tested
    Checking `rexedcs'... not found
    Checking `sniffer'... em0 is not promisc
    Checking `w55808'... not infected
    Checking `wted'... unable to open wtmp-file wtmp
    Checking `scalper'... not infected
    Checking `slapper'... not infected
    Checking `z2'... unable to open wtmp-file wtmp
    Checking `chkutmp'... chkutmp: nothing deleted
     
  9. jcase

    jcase Well-Known Member

    Joined:
    Jun 1, 2004
    Messages:
    50
    Likes Received:
    0
    Trophy Points:
    6
    the user toor has the following:

    toor:*:0:0:Bourne-again Superuser:/root:
     
  10. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    Go on, have a guess
    Then you have a root compromise, regardless of what chkrootkit and rkhunter tell you (since they're looking for rootkit installation which the hacker may not have done yet).

    You should reinstall the OS, reinstall cPanel, restore user data and secure the server. Cleaning up really is not an option as you will never know whether any backdoors have been left in place.
     
  11. rpmws

    rpmws Well-Known Member

    Joined:
    Aug 14, 2001
    Messages:
    1,824
    Likes Received:
    5
    Trophy Points:
    38
    Location:
    back woods of NC, USA
    well couldn't he reinstall chkrootkit and kithunter just for fun ..catch the bastard not in there ..look around atleast to find out what he did to get in. It might wind up hapening again on very next box if script is in a users account he copies over.

    The box is rooted ..it's junk ..but you could play with the bastard a while. If you shut his door you might would know right away ..he seems to like hanging around in there. I would get some solid backups over to a remote box before you let him know you are moving. I know of a guy that got his backups and home deleted when kiddie saw transfers going through.
     
  12. StevenC

    StevenC Well-Known Member

    Joined:
    Jan 1, 2004
    Messages:
    254
    Likes Received:
    0
    Trophy Points:
    16
    grr at you people always quick to jump the gun on a compromised machine when you dont really know whats going on, if its a freebsd machine that toor account is normal. which it is:

    Checking `sniffer'... em0 is not promisc



    server1# cat /etc/passwd | grep toor
    toor:*:0:0:Bourne-again Superuser:/root:
    server1#

    That guy is probably flipping over something that is normal...
     
    #12 StevenC, Mar 8, 2005
    Last edited: Mar 8, 2005
  13. K_aneda

    K_aneda Well-Known Member

    Joined:
    Feb 29, 2004
    Messages:
    56
    Likes Received:
    0
    Trophy Points:
    6
    Location:
    Sydney, Australia
    toor is a default account on freebsd systems (root using /bin/csh for shell and toor using bash).
    If it's a linux system and you see this account, then yes, it's one way they've gotten in.

    Unfouranetly because you haven't been doing proper logging and the attacker has cleared up some of his tracks it makes it harder to clean the system. My best advice, is to back up what you can and get an OS reload.
     
  14. Hantai

    Hantai Member

    Joined:
    Feb 9, 2004
    Messages:
    18
    Likes Received:
    0
    Trophy Points:
    1
    Location:
    London, UK
    Concur, toor is normal on a FreeBSD system, so that is not likely to be a comprmise assuming that's the OS here. That bindshell listener on the other hand deserves closer attention, try tracing that process and shutting it down then changing all passwords again, see if the intruder still comes back.

    Be aware however that regardless of the original route of comprmise, be it WHM or just about ANYTHING else, if the intruder definitely gained root access rather than a single user's privileges it may not be possible to locare and eliminate all damage done to the server, in which case only a reinstall will stop the intrustions.

    If you believe your server contains any confidential information, such as customer billing records or other personal information you MUST notify all your residents of this breach and they in turn must notify anyone else they feel may have been affected.
     
  15. StevenC

    StevenC Well-Known Member

    Joined:
    Jan 1, 2004
    Messages:
    254
    Likes Received:
    0
    Trophy Points:
    16
    again stop jumping the gun please :)

    root@um-373 [~]# ps aux | grep 465 | grep -v grep
    mailnull 13318 0.0 0.1 8496 1912 ? Ss Mar05 0:00 /usr/sbin/exim -tls-on-connect -bd -oX 465
    root@um-373 [~]#


    that port is just ssl enabled smtp
     
  16. Hantai

    Hantai Member

    Joined:
    Feb 9, 2004
    Messages:
    18
    Likes Received:
    0
    Trophy Points:
    1
    Location:
    London, UK
    No one jumped anything, I said it deserved closer attention, if you choose to read that into some sort of categorical statement that's very much your issue, my intention was to say exactly what my words said, nothing more nothing less. The ps result you've just returned is from your own system, not the potentially compromised one, correct? How do you know that listener hasn't been replaced with a trojan component on the system in question? It is dangerous to make negative assumptions when a root compromise is suspected, ALL listeners should be examined t ensure they're still limited to their original purpose, doubly so if they come up in a chkrootkit report.
     
  17. StevenC

    StevenC Well-Known Member

    Joined:
    Jan 1, 2004
    Messages:
    254
    Likes Received:
    0
    Trophy Points:
    16
    Yes but do a search, thats on every box. Chkrootkit is far from accurate, especially on freebsd.


     
  18. chirpy

    chirpy Well-Known Member

    Joined:
    Jun 15, 2002
    Messages:
    13,475
    Likes Received:
    20
    Trophy Points:
    38
    Location:
    Go on, have a guess
    Oops ;) Never did like FreeBSD :rolleyes: . After the pre-amble it fitted, ah well - still the other evidence certainly raises points of concern.
     
    #18 chirpy, Mar 9, 2005
    Last edited: Mar 9, 2005
  19. rpmws

    rpmws Well-Known Member

    Joined:
    Aug 14, 2001
    Messages:
    1,824
    Likes Received:
    5
    Trophy Points:
    38
    Location:
    back woods of NC, USA
    You know sitting here and reading this ..we still don't know if it was a FreeBSD box or not do we? I mean even the 465 port could be a trajan throwing us off. Maybe 465 was replaced and chkrootkit reports what is normal on cPanel boxes. I can see where a smart hacker might want to do this to throw us off. However that root account could be confusing to the average Linux user it would be normal for FreeBSD ..so I guess what we have so far really doesn't tell us much. I hope he has it solved and would let us know what he found if anything.
     
  20. jcase

    jcase Well-Known Member

    Joined:
    Jun 1, 2004
    Messages:
    50
    Likes Received:
    0
    Trophy Points:
    6
    Ok, so after about two days of hell I finally figured it out. Someone was able to put cgitelnet in my cgi-bin of my main site. Then of course I assume this guy from freaking vietnam of all places decrypted the passwd file and whatnot.

    He was able to change most things in WHM, admin email address and even took over some accounts.
    Also changes the /root/histroy file to go to /dev/null

    I have removed all instances and changed almost all the passwords. I am still not 100% sure how the hell this guy was able to place this file in my cgi-bin. I need to know EXACTLY how to stop this.

    Another thing I noticed, and im not sure if its a vulnerability in the reseller feature but at the top of the (add reseller privs) theres a an account "()" I dont believe this was there before.
     
Loading...

Share This Page