Re: Malware 4
On Thu, Jul 31, 2014 at 03:45:12PM -0400, Larry Linder wrote:
>
> The US should just unplug China from Internet and a lot of the problem goes
> away.
>
Nothing like a simple solution 100% guarrantied to resolve every problem.
>
> To night we will simply unplug the box.
>
Now you are getting somewhere.
There is many advices for securing important computers, but I find it is
pointless
to tell people to "lock your bike" ("but not like this!!!"), "take karate
lessons",
"firewall your computers", etc before they or somebody they know gets burned.
--
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
Re: Malware 4
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.
Re: Malware 4
> 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. Can you mount those file systems noexec? _Might_ help... Maybe boot from a live CD and try to scan those file systems? - Bluejay Adametz I have not lost my mind! It is backed up on a floppy somewhere. -- NOTICE: This message, including any attachments, is only for the use of the intended recipient(s) and may contain confidential and privileged information, or information otherwise protected from disclosure by law. If the reader of this message is not the intended recipient, you are hereby notified that any use, disclosure, copying, dissemination or distribution of this message or any of its attachments is strictly prohibited. If you received this message in error, please contact the sender immediately by reply email and destroy this message, including all attachments, and any copies thereof.
Re: Malware 4
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. > > Brandon Vincent
Re: Malware 4
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. > > Brandon Vincent > /boot/.IptabLes->/etc/rc.d/init.d/IptabLes > /boot/.IptabLex->/etc/rc.d/init.d/IptabLex once you remove them they just become a /boot/.IptabLes /boot/.Iptablex We are not running Apache on this box but "mysql" is running. There were a number of other copies of .mylisthb* on other drives on this system. If you removed these files by hand and depending on how fast you removed them the /boot / IptabLes and /IptabLx were a link to /etc/rc.d/init.d/IptabL If you removed the link the .IptabLes and ./IptableX appeared. If you did not use "ls -la" you thought you had them but didn't. The only way to make sure you got all of them is to remove them in one shot. Put the files in a script script. It appears from our vantage point that any fragment could regen the others. We played a number of games trying to find out what was regenerating the files. in /.mylisthb* files were left but set to chmod 000 /.mylisthb*. Once this was done it could not regenerate its self. Mybe the program checks for a files existance and not weather it is executable? I put a copy of what we thought were the bad files in an MS directory under VMware. To prevent their escape. Plan to examine them with a binary editor soon. Look at " http://blog.malwaremustdie.org/"; they have a very complete breakdown of malware but I still have never seen the program that runs to set it up. All we have done is see the output of the program. Using "yum" to see what files were installed and what maybe files not in data base is a good thing to do. Plan to do this come Friday as we walk out the door. Hopefully we see it come Monday. Need to really track this down because our backup's may be infected. Larry Linder
