On 2014-07-31 21:45, Larry Linder wrote: > Next It is back: > Removed all of the files that are in / , /boot, usr/, /etc/rc.d/init.d > It has set up files again in /boot. > new IptabLes and IptabLex are now in /etc/rc.d as well as in /etc/rc.c/init.d > > I built and run the "rpm" script and the number of UNVerified pretty large. > The common thing was that they all had to do with "iptables", and other > security files. > Since I have reloaded the OS once and it came back. I will lowlevel format > the disk and reinstall and change all passwords and permissions. > The bad part is that the major disks containing our engineering files for > last > 15 years may also have the program burried somewhere in the 39 G. > There are also a number of new ports added to the system - ! > The only real file I saved from the old OS was the CUPS configuration file. > I examined them but did not see anything that should not be there. > Will have a list of rpm verification failures tomorrow. > There were a couple of failures that dealt with "samba" - so they were able > to > gain access to the M$ systems as well. > The thing that has me worried is that they are changing things each time it > is > back. Slight differences. > The US should just unplug China from Internet and a lot of the problem goes > away. > To night we will simply unplug the box. > > On Tuesday 29 July 2014 10:07 pm, Brandon Vincent wrote: >> On Tue, 2014-07-29 at 17:23 -0400, Larry Linder wrote: >>> If anyone is interested I will share the details. >> >> Larry, >> >> Are you running Apache Struts, Apache Tomcat, or Elasticsearch by any >> chance? Please review CVE-2013-2115, CVE-2013-1966, and CVE-2014-3120 to >> see if any of these apply to your system configuration. This type of >> infection is typically due to the aforementioned vulnerabilities. >> >> As for removal, find and remove the following files with the system >> offline: >> >> /boot/.IptabLes >> /boot/.IptabLex >> /usr/.IptabLes >> /usr/.IptabLex >> /etc/rc.d/init.d/IptabLes >> /etc/rc.d/init.d/IptabLex >> /.mylisthb* >> >> Let me know if you have any more questions. >>
Removing only the files is useless until the process writing the files and the compromised binaries are identified. Hide a process or files can be done with a simple statements, e.g. echo "alias ps=/bin/ps $@ | grep -v malicious process" >> /etc/profiles.d/$random_file or /etc/bashrc or ... echo "PATH=$malicious_binary_path:$PATH" >> /etc/profiles.d/$random_file or /etc/bashrc or ... ... On a not compromised system copy ps, top and other utils to a read only medium (cdrom, even creating an iso would work) E.g. ps -> $medium/new_p_s_$SHA1, top -> $medium/new_t_o_p_$SHA1 Now use the fresh tools to find the process writing this files, some examples how to monitor the file system can be found on http://www.linuxquestions.org/questions/blog/unspawn-2450/rootkit-hunter-iptablex-iptables-36083/ Scan with a livecd, clamscan an the rhkunter signatures will not harm. If you search for "/boot/.iptablex" you will notice you are not alone but it seems no one has identified how the infect was done.