Found a hidden process, now what?

[check_status]

Code:

WARNING : info.procs changed during test : 366 (was 365)
		WARNING : info.procs changed during test : 365 (was 366)
HIDDEN Processes Found: 1	sysinfo.procs = 365   ps_count = 366

   I don't know if this is a false positive or if Jynx has evolved.   

Gradually the Linux kernel has evolved and doing quite more complex work to modify it to those ends, so currently the most effective way to install a rootkit on a Linux system is to go towards the 'userland'


This kind of rootkits there are two types , or which change the typical binary system associated information (ps and friends) and more sophisticated rootkits inject a library in the process.


Have long existed rootkits acting that way, but had remained somewhat hidden, relatively recently has released a fully functional implementation of a rootkit capable of infecting a Linux system today, his name: Jynx


This type of rootkits act injecting a shared library (. So) in all system processes.

http://7256log.blogspot.com/2011/10/analisis-de-jynx-linux-rootkit.html

Jynx Kit Userland Rootkit

Authored by ErrProne
Jynx Kit is a LD_PRELOAD userland rootkit. Fully undetectable from chkrootkit and rootkithunter. Includes magic packet SSL reverse back connect shell. Solid building block for further LD_PRELOAD rootkits.

http://packetstormsecurity.org/files/105893/Jynx-Kit-Userland-Rootkit.html

[John (John K.)]

Code:

WARNING : info.procs changed during test : 366 (was 365)
		WARNING : info.procs changed during test : 365 (was 366)
HIDDEN Processes Found: 1	sysinfo.procs = 365   ps_count = 366

   I don't know if this is a false positive or if Jynx has evolved.   

Gradually the Linux kernel has evolved and doing quite more complex work to modify it to those ends, so currently the most effective way to install a rootkit on a Linux system is to go towards the 'userland'


This kind of rootkits there are two types , or which change the typical binary system associated information (ps and friends) and more sophisticated rootkits inject a library in the process.


Have long existed rootkits acting that way, but had remained somewhat hidden, relatively recently has released a fully functional implementation of a rootkit capable of infecting a Linux system today, his name: Jynx


This type of rootkits act injecting a shared library (. So) in all system processes.

http://7256log.blogspot.com/2011/10/analisis-de-jynx-linux-rootkit.html

Jynx Kit Userland Rootkit

Authored by ErrProne
Jynx Kit is a LD_PRELOAD userland rootkit. Fully undetectable from chkrootkit and rootkithunter. Includes magic packet SSL reverse back connect shell. Solid building block for further LD_PRELOAD rootkits.

http://packetstormsecurity.org/files/105893/Jynx-Kit-Userland-Rootkit.html

Do what Windows sysadmins used to do.Reformat! 

[Rugatu]

Code:

WARNING : info.procs changed during test : 366 (was 365)
		WARNING : info.procs changed during test : 365 (was 366)
HIDDEN Processes Found: 1	sysinfo.procs = 365   ps_count = 366

   I don't know if this is a false positive or if Jynx has evolved.   

Gradually the Linux kernel has evolved and doing quite more complex work to modify it to those ends, so currently the most effective way to install a rootkit on a Linux system is to go towards the 'userland'


This kind of rootkits there are two types , or which change the typical binary system associated information (ps and friends) and more sophisticated rootkits inject a library in the process.


Have long existed rootkits acting that way, but had remained somewhat hidden, relatively recently has released a fully functional implementation of a rootkit capable of infecting a Linux system today, his name: Jynx


This type of rootkits act injecting a shared library (. So) in all system processes.

http://7256log.blogspot.com/2011/10/analisis-de-jynx-linux-rootkit.html

Jynx Kit Userland Rootkit

Authored by ErrProne
Jynx Kit is a LD_PRELOAD userland rootkit. Fully undetectable from chkrootkit and rootkithunter. Includes magic packet SSL reverse back connect shell. Solid building block for further LD_PRELOAD rootkits.

http://packetstormsecurity.org/files/105893/Jynx-Kit-Userland-Rootkit.html

According to your first link, the text in Spanish says:

En resumen, lo que hacen este tipo de rootkits es añadir una línea en el fichero /etc/ld.so.preload apuntando hacia la librería del rootkit en la que se encuentran 're-escritas' ciertas funciones asociadas a la obtención de información del sistema.

Which translates to:

In summary, what these kind of rootkits do is write a new line in "/etc/ld.so.preload" pointing to the rootkit's library, in which you can find rewritten certain system info functions.

So in order to "unhook" it you would have to manually edit that file and remove any strange .so libs you encounter.

Code:

sudo nano /etc/ld.so.preload

[check_status]

Well, either the file is empty or it's contents are hidden.

[dooglus]

The rootkit would make that file appear to be normal; that's what they do.

If you can boot from a known-good live CD then you'll be able to mount your root partition and see how that file really looks, before the rootkit has a chance to run and start masking itself.

[Raoul Duke]

This is the usual fix for windows computers but I heard it also works on linux
http://www.youtube.com/watch?v=4JJsy4ABHkA

[check_status]

Something not correct is occuring, my auto updater, Ubuntu 11.04 64bit, is asking me to update a language pack, I don't have Firefox, and Firefox isn't present on the entire network.   

[check_status]

The rootkit would make that file appear to be normal; that's what they do.

If you can boot from a known-good live CD then you'll be able to mount your root partition and see how that file really looks, before the rootkit has a chance to run and start masking itself.

I'm going to have to do this for sure. All of the Linux tools I've used are coming up empty, top and the like, yet the system responds as if it is overloaded by too many processes.

When I do this, strace, I found out why there is nothing in ld.so.preload   :

Code:

access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3

still looking...
Edit: RKH {Warning} Is this bad?

Code:

Warning: The command '/usr/sbin/adduser' has been replaced by a script: /usr/sbin/adduser: a /usr/bin/perl script text executable
Warning: The command '/usr/bin/ldd' has been replaced by a script: /usr/bin/ldd: Bourne-Again shell script text executable
Warning: The command '/usr/bin/lwp-request' has been replaced by a script: /usr/bin/lwp-request: a /usr/bin/perl -w script text executable
Warning: The command '/bin/which' has been replaced by a script: /bin/which: POSIX shell script text executable

Checking for hidden files and directories       [ Warning ]
Warning: Hidden directory found: '/etc/.java'
Warning: Hidden directory found: '/dev/.udev'
Warning: Hidden directory found: '/dev/.initramfs'

[Rugatu]

The rootkit would make that file appear to be normal; that's what they do.

If you can boot from a known-good live CD then you'll be able to mount your root partition and see how that file really looks, before the rootkit has a chance to run and start masking itself.

I'm going to have to do this for sure. All of the Linux tools I've used are coming up empty, top and the like, yet the system responds as if it is overloaded by too many processes.

When I do this, strace, I found out why there is nothing in ld.so.preload   :

Code:

access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3

still looking...
Edit: RKH {Warning} Is this bad?

Code:

Warning: The command '/usr/sbin/adduser' has been replaced by a script: /usr/sbin/adduser: a /usr/bin/perl script text executable
Warning: The command '/usr/bin/ldd' has been replaced by a script: /usr/bin/ldd: Bourne-Again shell script text executable
Warning: The command '/usr/bin/lwp-request' has been replaced by a script: /usr/bin/lwp-request: a /usr/bin/perl -w script text executable
Warning: The command '/bin/which' has been replaced by a script: /bin/which: POSIX shell script text executable

Checking for hidden files and directories       [ Warning ]
Warning: Hidden directory found: '/etc/.java'
Warning: Hidden directory found: '/dev/.udev'
Warning: Hidden directory found: '/dev/.initramfs'

Yes, that looks really bad! Re-install your OS before it's too late.

[Bitsky]

While I don't want to stop anybody from doing whatever they want because they assume something is wrong, it would be a good idea to invest a little time into research, since that is faster and more reliable than blindly formatting, especially since rkhunter generates false positives too.

http://askubuntu.com/questions/1537/rkhunter-warning-about-etc-java-etc-udev-etc-initramfs
Also, on Ubuntu there should be debsums which can be used to verify packages.
Of course you can always reinstall, but you'll get the same messages again.

[check_status]

Yes, I have been able to see the scripts which appear to be legitimate, therefore, must be false positives from RKH.
I'm now back to where I was before I downloaded, installed and misconfigured RKH.  
I'll poke around with a manufactured Live CD some and try to discover what the fuzz.

Would OSSEC HIDS be of value to see what the fuzz is happening?

[Foxpup]

The rootkit would make that file appear to be normal; that's what they do.

If you can boot from a known-good live CD then you'll be able to mount your root partition and see how that file really looks, before the rootkit has a chance to run and start masking itself.

I'm going to have to do this for sure. All of the Linux tools I've used are coming up empty, top and the like, yet the system responds as if it is overloaded by too many processes.

When I do this, strace, I found out why there is nothing in ld.so.preload  :

Code:

access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3

still looking...
Edit: RKH {Warning} Is this bad?

Code:

Warning: The command '/usr/sbin/adduser' has been replaced by a script: /usr/sbin/adduser: a /usr/bin/perl script text executable
Warning: The command '/usr/bin/ldd' has been replaced by a script: /usr/bin/ldd: Bourne-Again shell script text executable
Warning: The command '/usr/bin/lwp-request' has been replaced by a script: /usr/bin/lwp-request: a /usr/bin/perl -w script text executable
Warning: The command '/bin/which' has been replaced by a script: /bin/which: POSIX shell script text executable

Checking for hidden files and directories       [ Warning ]
Warning: Hidden directory found: '/etc/.java'
Warning: Hidden directory found: '/dev/.udev'
Warning: Hidden directory found: '/dev/.initramfs'

Yes, that looks really bad! Re-install your OS before it's too late.

It's perfecty normal. My known-good MEPIS 11 installation has exactly the same setup:

Code:

$ file /usr/sbin/adduser /usr/bin/ldd /usr/bin/lwp-request /bin/which
/usr/sbin/adduser:    a /usr/bin/perl script text executable
/usr/bin/ldd:         Bourne-Again shell script text executable
/usr/bin/lwp-request: a /usr/bin/perl -w script text executable
/bin/which:           POSIX shell script text executable
$ ls -d /etc/.* /dev/.*
/dev/.   /dev/.initramfs        /dev/.udev  /etc/..     /etc/.pwd.lock
/dev/..  /dev/.initramfs-tools  /etc/.      /etc/.java

My known-good Debian installation is identical except it does not have /dev/.initramfs or /dev/.initramfs-tools:

Code:

$ file /usr/sbin/adduser /usr/bin/ldd /usr/bin/lwp-request /bin/which
/usr/sbin/adduser:    Perl script, ASCII text executable
/usr/bin/ldd:         Bourne-Again shell script, ASCII text executable
/usr/bin/lwp-request: Perl script, ASCII text executable
/bin/which:           POSIX shell script, ASCII text executable
$ ls -d /etc/.* /dev/.*
/dev/.  /dev/..  /etc/.  /etc/..  /etc/.java  /etc/.pwd.lock

[check_status]

Thanks foxpup for the confirmation.

Something not correct is occuring, my auto updater, Ubuntu 11.04 64bit, is asking me to update a language pack, I don't have Firefox, and Firefox isn't present on the entire network.   

EvilGrade is a framework which the exploits weaknesses in the auto-update services of multiple common software packages and the attack performed by this framework is one of the best example for client exploitation. This framework tricks the service into believing there is a signed update available for the product, thus prompting the user to install the upgrade where the upgrade is the attacker’s payload. This type of attack is a bit difficult for a normal user to detect since they don’t see anything suspicious and the upgrade looks legitimate.

We can use this framework with the combination of DNS spoofing or Man-in-the-middle attack in order to spoof the software upgrade. This therefore tricks the victim into downloading the upgrade, thereby executing our malicious arbitrary code.

The EvilGrade supports various famous software like Notepad, iTunes, Java plug-in, WinZip, Winamp, DAP, OpenOffices, LinkedIn, Speedbit, etc.

Evilgrade takes the advantage of various applications because most of these verify neither the update contents nor the master update server. Basically, in this type of attack, the attacker seeks to modify the DNS traffic of the victim and return them to some other ip address controlled by the attacker.

http://resources.infosecinstitute.com/hacking-autoupdate-evilgrade/

[Rugatu]

Thanks check_status, is true that every day we learn something new 

[check_status]

If Firefox had been installed, and the update appearing to be legitimate, Ubuntu's 'update-notifier' application, I would have clicked it, even though it was only a language pack available for update. It's also entirely possible I already installed some malware because of this EvilGrade method. 

How can you determine what IP's update-notifier is providing the update from?
Is it possible to force the sources.list addresses to use a host file instead of DNS?
Can tzdata be removed from Ubuntu without breaking it's ability to function?

[Rugatu]

If Firefox had been installed, and the update appearing to be legitimate, Ubuntu's 'update-notifier' application, I would have clicked it, even though it was only a language pack available for update. It's also entirely possible I already installed some malware because of this EvilGrade method. 

How can you determine what IP's update-notifier is providing the update from?
Is it possible to force the sources.list addresses to use a host file instead of DNS?
Can tzdata be removed from Ubuntu without breaking it's ability to function?

If you put at least one of those questions on Rugatu you will really make some bitcoiners happy 

[Foxpup]

Is it possible to force the sources.list addresses to use a host file instead of DNS?

I'm pretty sure the hosts file is always prefered over the network's DNS server anyway, though this probably can't be relied upon if you suspect a rootkit. You can, however, put the repo's IP address directly in the sources.list file, eg:

Code:

deb ftp://130.89.148.12/debian/ squeeze main contrib non-free

(though this also shouldn't be relied upon if you've got a rootkit)

Can tzdata be removed from Ubuntu without breaking it's ability to function?

No. What's tzdata got to do with anything anyway?

[check_status]

Is it possible to force the sources.list addresses to use a host file instead of DNS?

I'm pretty sure the hosts file is always prefered over the network's DNS server anyway, though this probably can't be relied upon if you suspect a rootkit. You can, however, put the repo's IP address directly in the sources.list file, eg:

Code:

deb ftp://130.89.148.12/debian/ squeeze main contrib non-free

(though this also shouldn't be relied upon if you've got a rootkit)

Then I will do this when/if I reinstall the OS, I want to gather more details first though before I nuke stuff.

Can tzdata be removed from Ubuntu without breaking it's ability to function?

No. What's tzdata got to do with anything anyway?

tzdata, is one of a small list of programs that is allowed complete internet access through all IDS and firewalls.
I had strange behavior appear, after wipe and reinstalls, only after the very first internet connection, which seemed to affect, gnome, network-manager and screensaver, (affected in that order). My internal domain would change to a blackberry ID. No internet connectivity after installation and gnome, network-manager, screensaver did not wig out and the internal domain name did not change. Because of this, I thought the possible infection is occurring through some first connect event, DNS or first outbound connecting program after the network is up. I eliminated ntpd and bluez before first connect and the issues still occurred. Outside of tzdata and DNS I'm not aware of what else could be contributing to this behavior.

[Foxpup]

tzdata, is one of a small list of programs that is allowed complete internet access through all IDS and firewalls.

What are you talking about? tzdata is a collection of data files (as the name suggests), and contains no programs. The only executable file related to it (tzconfig) is actually just a shell script consisting entirely of an echo command displaying installation instructions. Nothing related to tzdata should be accessing the network in any way, and you can safely delete any executable files related to it.

[check_status]

tzdata, is one of a small list of programs that is allowed complete internet access through all IDS and firewalls.

What are you talking about? tzdata is a collection of data files (as the name suggests), and contains no programs. The only executable file related to it (tzconfig) is actually just a shell script consisting entirely of an echo command displaying installation instructions. Nothing related to tzdata should be accessing the network in any way, and you can safely delete any executable files related to it.

Well then, I must have misunderstood the Ubuntu help code boxes that show tzdata collecting local and utc time, assuming it had network functions. Since I don't need to put anymore time and effort into tzdata I can focus on more probable targets.

pcap:
Will pcap files gathered from/on a system that may be infected provide useful data?
I don't have a switch that can do port mirroring so what methods would help me to overcome this limitation?