1. Please take a little time for this simple survey! Thank you for participating!
    Dismiss Notice
  2. Dear Pleskians, please read this carefully! New attachments and other rules Thank you!
    Dismiss Notice
  3. Dear Pleskians, I really hope that you will share your opinion in this Special topic for chatter about Plesk in the Clouds. Thank you!
    Dismiss Notice

May this be a trojan?

Discussion in 'Plesk for Linux - 8.x and Older' started by Nicochet, Dec 5, 2007.

  1. Nicochet

    Nicochet Guest

    0
     
    Hi everybody,

    I have the following problem. Last days my recently new installed plesk, started to be extremely slow in serving pages, mails, etc. After login, and some investigation, i found trough "netstat" several connections to away servers on ports 6667 and 6669. I started to define a rule in the firewall, to stop communication to that ports.

    The thing is that i have very few clients, and the firewall is setup from the beginnig. I am behind a router (the public IP), and the only ports open are 80, 21, 8443, and 53. All other ports are closed. So it seems the connections are made from inside. The OS is a Centos 4.4, and is a stand alone server, i mean, there is no local users, nor other aplications running on it.

    After defining the new rule in plesk firewall, connections have dissapeared, except a "Syn Sent" to a foreign server throug port 6667. Obviously, connection never happen, because the rule is set to forbid outgoing connections to that ports (6667 and 6669), but i don´t know how to eliminate that trojan or whatever it is . The process which try to connect in that way, is ran by apache user, and the command is "httpd -DSSL". Even when i reboot, that process is always trying to connect to 194.68.45.50 and 149.9.1.16 port 6667. I tried to kill the process which tried the connection, but it doesn't work.

    Here are the "suspicious" lines shown by netstat:

    tcp 0 1 192.168.0.1:33028 194.68.45.50:6667 SYN_SENT 5186/httpd -DSSL on (81,02/5/0)
    tcp 0 1 192.168.0.1:33068 149.9.1.16:6667 SYN_SENT 5186/httpd -DSSL on (14,59/5/0)

    It seems that remote ip changes from time to time, but the procees is always the same (5186).

    Any ideas? Please, any help will be very useful.

    Thanks in advance.
     
  2. atomicturtle

    atomicturtle Golden Pleskian

    29
     
    Joined:
    Nov 20, 2002
    Messages:
    2,110
    Likes Received:
    7
    Location:
    Washington, DC
    Yeah, definitely something malicious. That is someone launching this process through an exploitable web application on your server.
     
  3. Nicochet

    Nicochet Guest

    0
     
    Is there any way to find out which application is doing that? I installed one of each free application included in PLesk as a demo on my main site. If i disable the domain that hold all that, perhaps it'll stop?
     
  4. Nicochet

    Nicochet Guest

    0
     
    Hi again,

    Finally I found it. It was a file called y2kupdate, which was on the cron of the apache user. I don´t know how the hell has it arrives to my server, and even modified the apache's cron. Ayway, it seems to be solved now. i have deleted the entire application containing the file, disable the domain, and restored the apache's cron. I have checked out the log, that there aren't changes made in the passwd file, nor unauthorized access to the server. This time, i think i've been lucky. If you find a file called y2kupdate, please be careful.

    Thanks Atomicturtle for your answer.
     
  5. atomicturtle

    atomicturtle Golden Pleskian

    29
     
    Joined:
    Nov 20, 2002
    Messages:
    2,110
    Likes Received:
    7
    Location:
    Washington, DC
    That y2kupdate cron is only part of the compromise, what is happening is that some application on the system is allowing the attackers to insert that job, and their malicious code on the system. So you've gotten rid of the immediate problem, the next part is to find out which application is responsible.

    First thing I would do is look at the timestamp on the cron job to see when it was added. This will let you narrow down the date for the next step, which is to search your logs for malicious activity. Things like perl, uname, id, y2kupdate, etc. When you start these investigations before you start killing processes, or modifying anything, you want to collect as many pieces of data from the attack that would help narrow down your search.

    Next step is making an inventory of all the versions of the applications on the system, and then looking those up in secunia.com or securityfocus.com for vulnerabilities. Odds are that you've got more than one app to worry about here.
     
  6. Nicochet

    Nicochet Guest

    0
     
    hi,

    Im afraid you're right. I've been away for the weekend, but now, i continue having problems with connections to the outside, and the apache cron is now clean. I'll keep trying to find all the pieces, and where is the open door. Thanks again.
     
  7. Amin Taheri

    Amin Taheri Golden Pleskian Plesk Certified Professional

    33
     
    Joined:
    Jul 5, 2007
    Messages:
    1,398
    Likes Received:
    1
    Location:
    Seattle Area
    Sounds like its an IRC botnet or something, Ive seen a lot of those attempts recently. Among other things, restrict access to programs like wget to root user - that may not solve your problem but that makes it harder for them to download files to your machine.

    You should also look into mod security as that can also help mitigate any remote file include attacks which most botnets and defacing tool script kiddies use.
     
  8. Nicochet

    Nicochet Guest

    0
     
    Hi,

    After one week, the problem seems to be solved. I found several files in one of my domains, that create the task in the apache's cron. Curiously that domain did not host any application from plesk. Anyway it is very extrange, because the file that was called to be ran by cron was in a different domain than the origin of the problem. The logs shows that there are not changes in the password file. By revieqing the logs, it seems to have been a XSS atack, and that they introduces commands through the url. I still don't know how they uploaded those files, perhaps by ftp, i am still looking for it, but there was no extrange connections in the last week, and evrything is going well right now, so i think the problem is solved by the moment.

    Thanks to all for your advices.
     
  9. atomicturtle

    atomicturtle Golden Pleskian

    29
     
    Joined:
    Nov 20, 2002
    Messages:
    2,110
    Likes Received:
    7
    Location:
    Washington, DC
    Either each one of those domains has something exploitable, or they've compromised the system and rootkitted it.

    It wouldn't be unusual for multiple attackers to compromise the same vulnerable host either.
     
  10. Amin Taheri

    Amin Taheri Golden Pleskian Plesk Certified Professional

    33
     
    Joined:
    Jul 5, 2007
    Messages:
    1,398
    Likes Received:
    1
    Location:
    Seattle Area
    Make sure you limit access to GET, lwp-*, *cc*, *++*, lynxx, elinks, and all those types of apps that get from remote hosts and compile. Also look into mod_security :)

    A simple example of what I have used in the past is:
    Code:
    chmod 711 /
    chmod 711 /home
    chmod 711 /etc
    chmod 711 /var
    chmod 711 /usr/etc
    chmod 711 /usr/local/etc
    chmod 711 /var/log
    chmod 711 /sbin
    chmod 711 /usr/sbin
    chmod 711 /usr/local/sbin
    
    chmod 644 /etc/motd
    
    groupadd deva
    chmod 750 /usr/bin/wget
    chown root:deva /usr/bin/wget
    chmod 750 /usr/bin/perlcc
    chown root:deva /usr/bin/perlcc
    chmod 750 /usr/bin/byacc
    chown root:deva /usr/bin/byacc
    chmod 750 /usr/bin/yacc
    chown root:deva /usr/bin/yacc
    chmod 750 /usr/bin/cc
    chown root:deva /usr/bin/cc
    chmod 750 /usr/bin/gcc
    chown root:deva /usr/bin/gcc
    
    chmod 700 /bin/dmesg
    chmod 700 /bin/mount
    chmod 700 /bin/rpm
    chmod 700 /usr/bin/write
    chmod 700 /usr/bin/talk
    chmod 700 /usr/bin/ipcrm
    chmod 700 /usr/bin/ipcs
    chmod 700 /usr/bin/free
    chmod 700 /usr/bin/locate
    chmod 700 /usr/bin/wall
    chmod 700 /usr/bin/finger
    chmod 700 /sbin/arp
    chmod 700 /sbin/ifconfig
    chmod 700 /usr/sbin/repquota
    chmod 700 /usr/sbin/tcpdump
    chmod 700 /usr/bin/nmap
    chmod 700 /usr/bin/wget
    chmod 700 /usr/bin/perlcc
    chmod 700 /usr/bin/byacc
    chmod 700 /usr/bin/yacc
    chmod 700 /usr/bin/cc
    chmod 700 /usr/bin/gcc
    chmod 700 /usr/bin/who
    chmod 700 /usr/bin/w
    chmod 700 /usr/bin/nc
    
    chmod 1733 /tmp/.ICE-unix
    chmod 1733 /tmp/.X11-unix
    chmod 660 /var/run/utmp
    
    chmod 000 /usr/bin/rcp
    chmod 000 /usr/bin/links
    chmod 000 /usr/bin/scp
    chmod 000 /usr/bin/elinks
    chmod 700 /usr/bin/lwp-*
    chmod 000 /usr/bin/GET
    chmod 700 /usr/bin/curl
    chmod 700 /usr/bin/*++* 
    chmod 700 /usr/bin/*cc*
    chmod 700 /usr/bin/yum 
    chmod 700 /usr/bin/up2date 
    chmod 700 /usr/sbin/up2date
    
    
    chmod u-s /usr/bin/at
    chmod u-s /usr/bin/chage
    chmod u-s /usr/bin/chfn
    chmod u-s /usr/bin/chsh
    chmod u-s /usr/bin/crontab
    chmod u-s /usr/bin/expiry
    chmod u-s /usr/bin/gpasswd
    chmod u-s /usr/bin/lppasswd
    chmod u-s /usr/bin/newgrp
    chmod u-s /usr/bin/rcp
    chmod u-s /usr/bin/rlogin
    chmod u-s /usr/bin/rsh
    chmod u-s /usr/libexec/ssh-keysign
    
    I dug that out of one of my archives, it may be outdated and some of those files may not exist based on what packages you had installed. You should also try this out on a dev machine first so that if there are any problems running your system your not affecting anything production.

    It wont stop the determined but it makes their jobs harder.
     
Loading...