Linux issue
-
@scottalanmiller This was created from my old linux template.
I need to update the test vm to latest version!
While checking on the errors, I found the below for the keyword "rewgtf3er4t"
https://www.virustotal.com/en/file/29f89dc1da6da3fa2fa951c3453d63ff82eab3159020012a90763df279a75e25/analysis/So I decided to install clamav and try, and this is the result i got:
Unix.Trojan.Elknot FOUND
----------- SCAN SUMMARY -----------
Known viruses: 3494145
Engine version: 0.98.4
Scanned directories: 10163
Scanned files: 54491
Infected files: 7
Total errors: 2841
Data scanned: 1349.12 MB
Data read: 1747.42 MB (ratio 0.77:1)
Time: 100.831 sec (1 m 40 sAnd as per the site http://lurker.clamav.net/message/20140521.161253.80556ece.en.html
ElkKnot (aka Elknot) is apparently a Linux Trojan associated with DDOS attacks.
The only thing I downloaded from the internet is the gitlab installation file as per the site: https://about.gitlab.com/downloads/
https://downloads-packages.s3.amazonaws.com/centos-6.5/gitlab-7.0.0_omnibus-1.el6.x86_64.rpmJust wondering how this could've affected the server. I was re testing the gitlab server, was up and running only for 2 hours and this happened! I forwarded the port 80 for sometime to test everything from outside but even that was not open for longer time.
-
Look at your rc.local file first...
cat /etc/rc.local
-
@scottalanmiller said:
cat /etc/rc.local
I checked, this is all i got and then it started giving me the kill prompt!
[root@localhost ~]# cat /etc/rc.local
#!/bin/shThis script will be executed after all the other init scripts.
You can put your own initialization stuff in here if you don't
want to do the full Sys V style init stuff.
touch /var/lock/subsys/local
cd /etc;./sfewfesfs
cd /etc;./gfhjrtfyhuf
cd /etc;./rewgtf3er4t
cd /etc;./sdmfdsfhjfe
cd /etc;./gfhddsfew
cd /etc;./ferwfrre
cd /etc;./dsfrefr -
-
-
@ambarishrh said:
@scottalanmiller said:
cat /etc/rc.local
I checked, this is all i got and then it started giving me the kill prompt!
[root@localhost ~]# cat /etc/rc.local
#!/bin/shThis script will be executed after all the other init scripts.
You can put your own initialization stuff in here if you don't
want to do the full Sys V style init stuff.
touch /var/lock/subsys/local
cd /etc;./sfewfesfs
cd /etc;./gfhjrtfyhuf
cd /etc;./rewgtf3er4t
cd /etc;./sdmfdsfhjfe
cd /etc;./gfhddsfew
cd /etc;./ferwfrre
cd /etc;./dsfrefrNone of those should be there, no way, no how. You've been hacked. Except for the "touch" line, delete all of those.
-
@scottalanmiller Removed and rebooted, but still looks the same.
-
@ambarishrh said:
/etc/rc3.d/S99local
What was in rc.local doesn't match the errors from /etc/rc3.d/S99local
This means BOTH are infected. You don't need S99local as you are running nothing there. Disable that.
rm /etc/rc3.d/S99local
and reboot
-
@scottalanmiller
Now after removing the file and reboot, the message changed.CentOS release 6.4 (Final)
Kernel 2.6.32-358.el6.x86_64 on an x86_64localhost.localdomain login: sh: systemctl: command not found
sh: reSuSEfirewall2: command not found
sh: SuSEfirewall2: command not found
ebtables: unrecognized service
sh: /etc/init.d/ebtables: No such file or directory
sh: ufw: command not found
usage: kill [ -s signal | -p ] [ -a ] pid ... -
Yeah, none of those are real. One of those is a Suse command, one is an Ubuntu command and two are completely fake. I think you need to rebuild your server. I could step through and get this working... but you have been hacked and your box cannot be trusted
-
@scottalanmiller Its a test vm, i can destroy and rebuild it, but just curious to find the cause.
As I mentioned all i did was installing the gitlab on the server. Would you be able to test this on ur test server and see if that installation opens something else?
-
@ambarishrh said:
@scottalanmiller Its a test vm, i can destroy and rebuild it, but just curious to find the cause.
As I mentioned all i did was installing the gitlab on the server. Would you be able to test this on ur test server and see if that installation opens something else?
I suspect that you were hacked and that Gitlab was not the issue. You can make another VM and test this yourself, just snapshot before the installation and see if any of this stuff appears.
-
I have few other vms and running with the same centos but with other installations. Anyways, I will try a new setup tomorrow again and see if I get same issues. Its 3 AM here, i really need to sleep or i will be late to the office in the morning.
Thanks a lot for helping
, I will post it here my test results tomorrow. -
Okay, will check tomorrow.
-
Ok, time for test results!
Clean installed centos from my template, installed clam av and did a scan, then installed gitlab and did one more scan on clamav, both came clean!
*========================================================
----------- SCAN SUMMARY -----------
Known viruses: 3497543
Engine version: 0.98.4
Scanned directories: 4749
Scanned files: 17429
Infected files: 0=========================================================
Running handlers:
Running handlers completeChef Client finished, 129/141 resources updated in 55.414565857 seconds
gitlab Reconfigured!
[root@localhost ~]# /usr/bin/clamscan -ri /----------- SCAN SUMMARY -----------
Known viruses: 3497543
Engine version: 0.98.4
Scanned directories: 9983
Scanned files: 54376
Infected files: 0*Not sure how the box got hacked last time.
Anyways, I am completely updating the server, and test this for few days.
-
Might have been the gitlab package hacked but extremely unlikely. Almost certainly an external hack of some sort.
