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.

Custom Chkrootkit

Discussion in 'Workarounds and Optimization' started by Spork Schivago, Aug 2, 2016.

  1. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    292
    Likes Received:
    24
    Trophy Points:
    18
    Location:
    corning, ny
    cPanel Access Level:
    Website Owner
    Hello.

    I've created a patch file that makes chkrootkit-0.50 a little more cPanel user friendly. I've been using it for a while now and so far, it hasn't detected any false positives. It tries to detect if cPanel is installed and looks for cPanel strings in certain files and if it finds them, it assumes it's cPanel and not a rootkit. You guys are more than welcome to use it. If anyone improves it, please reupload it here so I can try the improved version.

    There's a few ways to run the patch. First, download the chkrootkit-0.50 file and uncompress it into a directory. For simplicity reasons, I'll assume you downloaded it and extracted it to: /home/user/src/chkrootkit-0.50

    If the source is extracted to the chkrootkit-0.50 directory, you can copy the patch file to the directory before that, so you'd have the patch in the /home/user/src directory.

    You can then run:
    Code:
    cd /home/user/src
    patch -p0 < chkrootkit-0.50.patch
    
    This should patch the source code located in the chkrootkit-0.50 directory. The other option is to place the patch file directly in the chkrootkit-0.50 source directory. Again, we'll assume you extracted the source to /home/user/src/chkrootkit-0.50 and you've placed the patch file directly inside the /home/user/src/chkrootkit-0.50 directory.
    Code:
    cd /home/user/src/chkrootkit-0.50
    patch < chkrootkit-0.50.patch
    
    After you've successfully patched the chkrootkit-0.50 source code, simply follow the instructions to compile and install chkrootkit-0.50. After you compile the source code (usually by running make inside the chkrootkit-0.50 directory), you can run it to make sure you don't receive the false positives anymore.

    If anyone tries the patch, let me know what you think and how well it works. I'm also open for any suggestions on how to improve it.

    Thanks.
     
  2. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    30,854
    Likes Received:
    675
    Trophy Points:
    113
    cPanel Access Level:
    Root Administrator
    Hello,

    I've moved this post to it's own thread in our "Workarounds and Optimization" forum. Keep in mind user-submitted patches or workarounds are unsupported, and not tested by cPanel.

    Thank you.
     
    Spork Schivago likes this.
  3. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    292
    Likes Received:
    24
    Trophy Points:
    18
    Location:
    corning, ny
    cPanel Access Level:
    Website Owner
    Thank you cPanelMichael. I wasn't aware of this thread during the time I posted. Do you think it's worth pointing people from the original thread to this thread incase they'd like to try it? It seems to be working well for me. Thank you.

    Also, there's patches now that fix the modsecurity and modRUID2 issues. Both problems are solved from the two patches that are listed on the modsecurity issues page. I wasn't sure if the cPanel team knew or not. I believe the modsecurity developers are going to discuss implementing both patches in modsecurity in the near future. If everything works out fine, hopefully, we'll be able to successfully run modRUID2 along side modsecurity once again.

    Thanks.
     
  4. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    30,854
    Likes Received:
    675
    Trophy Points:
    113
    cPanel Access Level:
    Root Administrator
    Yes, feel free to add a link to this thread on that topic.

    Thank you.
     
  5. UHLHosting

    UHLHosting Well-Known Member

    Joined:
    Sep 26, 2014
    Messages:
    53
    Likes Received:
    4
    Trophy Points:
    8
    Location:
    Bratislava
    cPanel Access Level:
    Root Administrator
    Twitter:
    Main link from ftp is not working.
     
  6. UHLHosting

    UHLHosting Well-Known Member

    Joined:
    Sep 26, 2014
    Messages:
    53
    Likes Received:
    4
    Trophy Points:
    8
    Location:
    Bratislava
    cPanel Access Level:
    Root Administrator
    Twitter:
    chkrootkit 0.50 is now available! (Release Date: Wed Jun 4 2014) This version includes: if there is a fix should be reflected there? Or is this patch outside the main site, please provide links.

    Also you can take a look into head error would be nice, it seems it has to do with the many sess_ukdwkuqhdqwd21 files in /tmp, once I cleaned those no errors received. This could be as well a bug...
     
  7. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    292
    Likes Received:
    24
    Trophy Points:
    18
    Location:
    corning, ny
    cPanel Access Level:
    Website Owner
    Hello UHLHosting. What main link are you talking about? The one for my patch or the one for chkrootkit-0.50? I'm in no way affiliated with chkrootkit-0.50. I just run a VPS that has cPanel and chkrootkit-0.50 installed. Because there were false positives popping up, I changed the source code of chkrootkit-0.50 to try and detect if cPanel is installed, and if so, try very hard to make sure those false positives are in fact false positives, and if they are, ignore them.

    I tried changing the source code in such a way where if cPanel is installed, chkrootkit doesn't just ignore the files that show up as a false positive, it tries to see if cPanel is installed and tries to see if those files are in fact cPanel files. If a rootkit replaces any of those files that show up as false positives, chkrootkit should still be able to detect them.
     
  8. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    292
    Likes Received:
    24
    Trophy Points:
    18
    Location:
    corning, ny
    cPanel Access Level:
    Website Owner
    This patch should not be reflected on chkrootkit's website. I am not affiliated with them at all. They're more than welcome to use my patch and change it any way they'd like, if they wanted to, but chances are good they have no idea my patch even exists. I created it a while back and just uploaded it to cPanel's site, in this forum, today. Before today, it wasn't on the internet. Since today, to my knowledge, it's only here and nowhere else.

    I think I know what you're talking about and I don't think this is a bug. It's by design. Generally, on a Linux system, every user has write to the /tmp directory. It's usually something you'd want, so unprivileged users could still use programs that created temporary files. /tmp is generally where these programs place the "temp" files. In the C programming language (for operating systems like Linux), there are special functions for creating temp files and generally, they even rely on /tmp being world writeable.

    Sometimes though, hackers get in. Sometimes these hackers found a way in that gives them root access, other times, they found an exploit that just gives them remote access. Sometimes, they'll upload files to try and gain root access, or they'll upload a program that does some other malicious stuff, like open up a port and wait for them to connect. Sometimes these hackers store their malicious code inside the /tmp directory.

    I believe chkrootkit is actually checking the /tmp directory for various things, like shell scripts or PHP code. When I first ran it, I had a lot of false positives inside the /tmp directory. The only way to tell if they're false positives or not is to actually open them up and look at the files and see what's in there. The stuff that was in my /tmp directory was PHP code, perhaps from cPanel. I don't remember for certain, but all of it was harmless. You have to make a decision as to whether those files in the /tmp directory are actually dangerous or not. chkrootkit is doing exactly what it's supposed to do, checking for code. It's not smart enough (and more than likely never will be) to actually determine what that code does....it's just letting you know, hey, we found some source code or something else in the /tmp directory, this is the filename, check it out and see if it's bad or not!

    If you need help with anything else, please let me know.

    Thank you.

    Spork Schivago
     
  9. UHLHosting

    UHLHosting Well-Known Member

    Joined:
    Sep 26, 2014
    Messages:
    53
    Likes Received:
    4
    Trophy Points:
    8
    Location:
    Bratislava
    cPanel Access Level:
    Root Administrator
    Twitter:
    Well I did not found any links to your patch. I was thinking you are with chkrootkit team, my bad. :)
     
  10. UHLHosting

    UHLHosting Well-Known Member

    Joined:
    Sep 26, 2014
    Messages:
    53
    Likes Received:
    4
    Trophy Points:
    8
    Location:
    Bratislava
    cPanel Access Level:
    Root Administrator
    Twitter:
    Alright seen it now attached!
     
  11. UHLHosting

    UHLHosting Well-Known Member

    Joined:
    Sep 26, 2014
    Messages:
    53
    Likes Received:
    4
    Trophy Points:
    8
    Location:
    Bratislava
    cPanel Access Level:
    Root Administrator
    Twitter:
    I managed to patch it, the error is gone, thanks a lot! What about this one? Warning: /sbin/init INFECTED Have you patched also this one? Any luck to remove it? I am sure is a false warning.
     
    Spork Schivago likes this.
  12. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    292
    Likes Received:
    24
    Trophy Points:
    18
    Location:
    corning, ny
    cPanel Access Level:
    Website Owner
    Also, I just successfully downloaded the source for chkrootkit-0.50. Because I'm running CentOS (a Linux distribution), I needed the tar.gz file. This is how I downloaded the file:
    Code:
    cd /home/username/src
    wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit-0.50.tar.gz
    
    Where username is the name of your shell user. I create a src directory in my shell user's account for source code stuff. If you don't have a src directory, you might want to create one:
    Code:
    cd /home/username
    mkdir src
    cd src
    
    Don't forget to replace username with your actual shell username.
     
  13. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    292
    Likes Received:
    24
    Trophy Points:
    18
    Location:
    corning, ny
    cPanel Access Level:
    Website Owner
    We were cross posting. Please ignore my previous message that described how to download chkrootkit-0.50 using wget, because you've already patched it.

    Are you running CentOS? If so, what version? I don't get a false warning from /sbin/init on my system. Could you do me a favour and run a command to see what package provides /sbin/init?

    From an elevated shell (either run the command with sudo or su to root),
    execute:
    Code:
    rpm -qf /sbin/init
    
    See what it says. Also, perhaps you could run the following three commands and tell me what their outputs are:
    Code:
    file /sbin/init
    stat /sbin/init
    sha1sum /sbin/init
    
    Thanks!
     
    #13 Spork Schivago, Aug 2, 2016
    Last edited: Aug 2, 2016
  14. UHLHosting

    UHLHosting Well-Known Member

    Joined:
    Sep 26, 2014
    Messages:
    53
    Likes Received:
    4
    Trophy Points:
    8
    Location:
    Bratislava
    cPanel Access Level:
    Root Administrator
    Twitter:
    -----

    Hi Spork, I am using Centos 7 stable.

    Here are the results:

    root@panel [/]# /sbin/init
    init: required argument missing.
    root@panel [/]# rpm -qf /sbin/init
    systemd-219-19.el7_2.11.x86_64
    root@panel [/]# file /sbin/init
    /sbin/init: symbolic link to `../lib/systemd/systemd'
    root@panel [/]# stat /sbin/init
    File: ‘/sbin/init’ -> ‘../lib/systemd/systemd’
    Size: 22 Blocks: 0 IO Block: 4096 symbolic link
    Device: fd00h/64768d Inode: 201333154 Links: 1
    Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root)
    Access: 2016-08-03 20:00:02.172342496 +0200
    Modify: 2016-06-25 00:54:53.914000000 +0200
    Change: 2016-06-25 00:54:53.915000000 +0200
    Birth: -
    root@panel [/]# sha1sum /sbin/init
    455002661670009e475e15778ad919096ad68c10 /sbin/init
    root@panel [/]#
     
  15. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    292
    Likes Received:
    24
    Trophy Points:
    18
    Location:
    corning, ny
    cPanel Access Level:
    Website Owner
    Sorry for the late reply UHLHosting,

    I've been very busy lately and don't have a lot of time. We're in the process of purchasing a house. I think this is more than likely a false positive. I know some distro's (RedHat I believe) create a symlink /sbin/init and point it to /lib/systemd/systemd.

    What operating system are you running? I run CentOS 6 and it's provided by my hosting provider. Are you running something besides CentOS?

    Because /sbin/initd is a symbolic link, can you run file on /lib/systemd/systemd?

    Code:
    file /lib/systemd/systemd
    
    I'm guessing it's an ELF 64-bit LSB shared object. Are you running something like RedHat or Ubuntu by any chance? Just to be safe, you should possibly consider installing rkhunter and running that. I believe chkrootkit thinks it's finding the Suckit rootkit. rkhunter has much better checks for Suckit, if I remember correctly. If rkhunter doesn't detect /sbin/init as being infected (or /lib/systemd/systemd), perhaps when I find some time, I can look through the code of rkhunter and see how they rule out the false positives for this rootkit and this file.

    Thanks.
     
  16. UHLHosting

    UHLHosting Well-Known Member

    Joined:
    Sep 26, 2014
    Messages:
    53
    Likes Received:
    4
    Trophy Points:
    8
    Location:
    Bratislava
    cPanel Access Level:
    Root Administrator
    Twitter:
    root@dns1 [~]# file /lib/systemd/systemd
    /lib/systemd/systemd: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=a7708cd918de097229c0ca854f4569e26a913653, stripped
     
  17. UHLHosting

    UHLHosting Well-Known Member

    Joined:
    Sep 26, 2014
    Messages:
    53
    Likes Received:
    4
    Trophy Points:
    8
    Location:
    Bratislava
    cPanel Access Level:
    Root Administrator
    Twitter:
    root@panel [~]# file /lib/systemd/systemd
    /lib/systemd/systemd: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=a7708cd918de097229c0ca854f4569e26a913653, stripped

    This is the right one. Sorry i was on another server above.
     
  18. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    292
    Likes Received:
    24
    Trophy Points:
    18
    Location:
    corning, ny
    cPanel Access Level:
    Website Owner
    The fact that the SHA1 checksums match on both servers, to me, says it's a false positive. This really isn't related to cPanel so much as it is to the actual distro you're using. I can try to fix it but it might not be easily possible. It seems a lot of people are having this problem with some of the newer distro's and the fix is usually removing a line in the source code. To me, that's not really so much a fix as it is more of a workaround. With removing the line, I feel they might actually be disabling the test. The key would be to include the line but try to add more code to verify that it is in fact a false positive...

    Because I don't have CentOS 7, this could be very hard for me. When I find some time, I'll check out the source code for Rootkit Hunter (rkhunter) and see how they check for this. Just so I'm sure we're on the same page, chkrootkit is detecting the Suckit Rootkit, correct?

    Also, on my server, I have rkhunter installed as well as chkrootkit. You might want to consider running both of them. Rkhunter is very good and I think updated more frequently. Running both rkhunter and chkrootkit shouldn't hurt anything. I highly recommend it.

    Thanks.
     
  19. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    292
    Likes Received:
    24
    Trophy Points:
    18
    Location:
    corning, ny
    cPanel Access Level:
    Website Owner
    UHLHosting,

    If you're still interested in me trying to fix this, I was wondering if you could run another command for me please. Please copy and paste this line so you don't accidently run /sbin/init.

    Code:
    /usr/bin/strings /sbin/init | /bin/egrep 'HOME='
    
    After that, could you please copy and paste:
    Code:
    cat /proc/1/maps | /bin/egrep 'init.'
    
    Also, could you please copy and paste the output to both commands here so I can see what they say? Thank you.
     
  20. Spork Schivago

    Spork Schivago Well-Known Member

    Joined:
    Jan 21, 2016
    Messages:
    292
    Likes Received:
    24
    Trophy Points:
    18
    Location:
    corning, ny
    cPanel Access Level:
    Website Owner
    I cannot edit my first post, but I've modified the source code to chkrootkit-0.50 again. Anyone using my patch should delete their current copy of chkrootkit-0.50, download it again, extract it to the chkrootkit-0.50 directory and patch it using the new patch that's attached to this post.

    The newest patch now includes additional checks for the Suckit rootkit check for systems that are running systemd. I didn't write the code for the systemd checks. A user named wjhendrickson wrote it so I'd like to credit him for that.

    Also, I've changed how we search for cPanel in the /bin/passwd file. Before, we just excluded the "bash" strings search query. Now, we actually check to see if the string cPanel is present. I feel this is a bit more safer. If someone is running cPanel and have an infected passwd file, this new way of checking should catch it.

    Hopefully, a mod can remove my attachment in the first post and replace it with the attachment in this post so people use the more up-to-date patch.

    Thanks!
     

    Attached Files:

    UHLHosting likes this.
Loading...

Share This Page