LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   True Suckit infection NOT false positive in chkrootkit (https://www.linuxquestions.org/questions/linux-security-4/true-suckit-infection-not-false-positive-in-chkrootkit-4175472841/)

mazinoz 08-09-2013 09:46 PM

True Suckit infection NOT false positive in chkrootkit
 
I was looking at a machine recently with a Suckit infection. I'd dd if=/dev/zero of=/dev/sda or whatever, both the hard drive on laptop and an external hard drive and formatted as fat32 then as a linux partition. The external drive was simply an extended linux partition.

A fresh install would report no chkrootkit using Kali. However on reboot from hard drive it reported /sbin/init INFECTED AND also a sniffer on my wireless LAN card. If I created a blank test.mem test.ark file they would be hidden by rootkit. Win7 install would report everything as an executable file. A clean Windows Backup with no internet access had them as non-executables.

This morning however I booted from LM15 DVD AND with the external hard drive attached and everything was fine. Executable files were returned to non-executable files on Win7 partition. That is the ones that normally on a clean install aren't executable.

Others have reported not being able to remove Suckit after doing what I did ie zeroing drives, clean install. I thought it may live in memory and took the battery out of laptop as well as the power cord overnight, but it was still there when booting from hard drive without battery.

What has happened? Could the rootkit lurk in drivers such as my wireless LAN card? Booting Win 7 only install on hard drive and an external extended partition linux hard drive using LM15 seems to have removed it. I doubt my ZoneAlarm virus checker did this. Perhaps we have TWO rootkits, one for Windows and one for linux?

Just posting in case it helps anyone and if it does could you post back here so others know if this works or not. Also what operating systems you are using on hard drive maybe.

David Trest 08-10-2013 12:47 AM

Quote:

Originally Posted by mazinoz (Post 5006626)
What has happened? Could the rootkit lurk in drivers such as my wireless LAN card? Booting Win 7 only install on hard drive and an external extended partition linux hard drive using LM15 seems to have removed it. I doubt my ZoneAlarm virus checker did this. Perhaps we have TWO rootkits, one for Windows and one for linux?

Only thing I could think of...somehow it survived in the MBR of the disk. There have been viruses in the past that have done that.

Theoretically it could be possible that it survived in the BIOS, if it was configured to do so -- unlikely, as it would need to be configured to your specific brand and model of BIOS. Same for firmware chips on devices. Entirely possible to survive there, as that's EEPROM, but it would have to be custom-written for the target. Unless your machine had a very worthwhile prize I don't see that as being likely. EDIT: Also, after a second wipe it was gone -- if it was in EEPROM it would be persistent no matter how many times you wiped it.

So possibly the MBR. That's why after running a disk through /dev/zero or /dev/urandom (preferred) I'd go through it and wipe the boot record information using fdisk or gparted or even dban (forgoing the actual zero or garbage data overwrite) since that will also erase the boot record info.

aus9 08-10-2013 01:15 AM

on a clean install, you may like to install rootkit hunter and see what it reports?

Altho I am sure you are right, and I know I am often wrong, sometimes what we think is true can in hindsight turn out to be false?

BTW I am not a security expert.

unSpawn 08-10-2013 04:30 AM

Quote:

Originally Posted by mazinoz (Post 5006626)
I was looking at a machine recently with a Suckit infection. (..) A fresh install would report no chkrootkit using Kali. However on reboot from hard drive it reported /sbin/init INFECTED AND also a sniffer on my wireless LAN card. If I created a blank test.mem test.ark file they would be hidden by rootkit. Win7 install would report everything as an executable file.

Referencing earlier threads 0, 1 and 2 here's some things I told you previously and some things I didn't:
- Service-based attacks and web stack exploitation replaced LKMs along time ago: SuckIT usage is way, way rare.
- Chkrootkit was last updated in 2009: run current tools or run the specific check manually.
- Do not mistake Microsoft Windows as a yardstick for anything: use a Live CD or DVD to inspect a system.
- Verify the integrity of the system against contents from a known trusted repo (or at least compare the /sbin/init hash).
- Most importantly: no proof of evidence was shown. Again. Run a Live CD or DVD, mount the "victim" file system and run the specific Chkrootkit v0.49 check manually and on the /sbin/init of the "victim" file system. First set the MOUNT_POINT variable to where you mounted the "victim" file system and include a trailing slash:
Code:

strings -an4 ${MOUNT_POINT}sbin/init | egrep "HOME"
# This specific Chkrootkit check works only on "Live" systems: cat /proc/1/maps | egrep "init."
# This specific Chkrootkit check works only on "Live" systems: cat /dev/.golf

Additionally run these checks from Rootkit Hunter:
Code:

strings -an4 ${MOUNT_POINT}sbin/init | egrep -ie "(fuck|backdoor|bin/rcpc|bin/login)"
stat -c %h ${MOUNT_POINT}sbin/init

Without output (posted preferably in vBB [code][/code] or attached as plain text file) it will be hard to determine if this is a false positive and without proper analysis only speculation remains.

Noway2 08-11-2013 08:09 AM

Quote:

A fresh install would report no chkrootkit using Kali. However on reboot from hard drive it reported /sbin/init INFECTED AND also a sniffer on my wireless LAN card.
One thing that I did not see mentioned, that I would recommend as an easy sanity check is to compare the file /sbin/init to the one from your distribution or installation medium. Also, did you perhaps perform an update that changed this file? If so, be sure to compare against the proper version from the repository.

As far as your report of a sniffer goes, if memory serves this alert is generated if a card is placed in promiscuous mode, which is done for valid reasons when using certain applications, like TCP dump, wireshark, or snort.

unSpawn 08-11-2013 08:33 AM

Quote:

Originally Posted by Noway2 (Post 5007228)
One thing that I did not see mentioned, that I would recommend as an easy sanity check is to compare the file /sbin/init to the one from your distribution or installation medium. Also, did you perhaps perform an update that changed this file? If so, be sure to compare against the proper version from the repository.

I believe I already did:
Quote:

Originally Posted by unSpawn (Post 5006719)
- Verify the integrity of the system against contents from a known trusted repo (or at least compare the /sbin/init hash).


mazinoz 08-12-2013 02:45 AM

I did another clean install after zeroing hard drive, and then the external hard drive before rebooting. Then formatted them as fat32, then just for fun ntfs, then reloaded win7 from dvds. Loaded lm15 behind windows. all well rebooted a few times for win7 updates. Now crappy CQ62 won't POST. caps lock flashes, black screen. Disconnected power cable and removed battery, held power button down etc

Now need to go somewhere and scream!

Noway2 08-12-2013 07:52 AM

@unSpawn: oops, I missed that line, sorry.

@mazinoz, your last post was quite informative and suggests that you have a hardware problem. Oftentimes, intermittent hardware issues can mask themselves as malware that tends to survive wipe and re-install processes. I would check the memory, power supply, and HDD + controller, in that order.

mazinoz 08-19-2013 08:20 PM

'It seems I had BOTH! Compaq laptop works if I wrap it in bathmat and overheat it. Caps lock flashes every 4sec and won't boot otherwise. Seems to be the lack of thermal paste problem they are being sued for in a class action. Loctite screws are @!x'!.

Since posting I've found out using www.grc.com Optus in Oz no longer do reverse DNS. I suspect this makes it harder for hacker to brute force my computer. But I really don't know.

From memory, I think I was using a boot cd and mounted Win 7 and files were no longer all green, indicating a Suckit infection. A fresh install on a zeroed fat32 formatted drive displayed pagefil.sys as white. Also sbin/inite dated 26 Mar. Almost as soon as I went on internet using linux I would be hacked. Files became +x, init date changed to 27 Mar,
and chkrootkit on Kali cd reported sniffer on wlan0 as well as Suckit infection. test.mem and test.ark were hidden. When Suckit was gone I still got the chkroot INFECTION warning ONLY.

I'll try to read and answer other posts asap, hopefully on something other than a 7 inch tablet!

unSpawn 08-20-2013 01:18 AM

Quote:

Originally Posted by mazinoz (Post 5012212)
From memory, I think

Please read and reread post #3 and realize again you haven't posted any evidence.
Until you do it makes no sense at all to speculate about any "infections".

mazinoz 08-22-2013 05:33 PM

David

I routinely use gparted to format partitions these days, a bit easier than fdisk or parted. This did not remove it. I thought overwriting whole disk would have been sufficient to remove it, although it takes longer than dban. I don't havea floppy drive, so went for 'scorched earth' solution.

mazinoz 08-22-2013 05:45 PM

aus9

I did this, but from memory nothing significant was found with rkhunter.

mazinoz 08-22-2013 06:08 PM

Still on tablet, thinking & reading your reply Unspawn, Found this interesting article

http://www.symantec.com/connect/arti...raphy-part-one

in case anyone is interested.

GlennsPref 08-22-2013 06:16 PM

suckit may be old, but script kiddies have a toolbox...

Recent posts at slashdot and threatpost mention the continued use of mbr trojans.

I did not see and mbr re-writes here(?) and it's quite possible there (the mbr) is the hiding place.

In case you don't know, you use dd.
Code:

in order to set to zero the 512 first bytes:

to clean/wipe mbr...including partition table....
dd if=/dev/zero of=/dev/sd(x) bs=512 count=1

to retain partition table...clear only first 446 bytes.
dd if=/dev/zero of=/dev/sd(x) bs=446 count=1

It won't hurt to try!

unSpawn 08-22-2013 09:49 PM

Quote:

Originally Posted by GlennsPref (Post 5014095)
I did not see and mbr re-writes here(?) and it's quite possible there (the mbr) is the hiding place. In case you don't know, you use dd. (..) It won't hurt to try!

If you would have read the OP carefully you'd have seen the OP started by saying she did a "dd if=/dev/zero of=/dev/sda or whatever". More importantly her observations have not been corroborated and until addressed can only lead to speculation.


All times are GMT -5. The time now is 10:36 AM.