Shell Code and kernel hacking OS Agnostic?

Question

I'm reading a book about hacking the kernel and one area the author keeps coming back to is shell code, that many attempts at kernel hacking try to find a way to execute shell code. Can someone elaborate more on this topic, particularly can you clarify "shell code."

How does shell code get around sudo in *NIX systems or not being Admin in a windows machine? Are there examples of shell code attacks that aren't OS specific? I would think one has to be targeting specific OS.

score 1 · Answer 1 · answered Sep 17 '12 at 16:41

1

Essentially it's finding a buffer overflow or similar technique that allows you to insert malicious code into a process running as root.

For example, if you used a fixed sized buffer and you overrun that buffer, you can essentially overwrite memory contents and use this to execute a malicious payload.

answered Sep 17 '12 at 16:41

Jesus Ramos

22,940
10
58
88

And so there are a whole slew of techniques for smashing the stack/creating the overflow which points to your malicious code? – inbinder Sep 17 '12 at 16:50
Yes, the most common being buffer overflows due to user input. – Jesus Ramos Sep 17 '12 at 18:31

score 1 · Answer 2 · answered Sep 17 '12 at 16:43

1

A simple shell code snippet that can come back to bite you is:

/bin/sh

or inside a C program:

system("/bin/sh");

If you can direct your exploits to execute such a line of code (e.g. through a buffer overflow that hijacks the intended control path of the program), you get a shell prompt with the victim's privileges and you're in.

answered Sep 17 '12 at 16:43

Tudor

61,523
12
102
142

That makes lot of sense! gotcha – inbinder Sep 17 '12 at 16:52
@user1124541: You see, not only can you inject your own malicious code, but you can also use the victim's program to do it for you if they weren't careful when they wrote it. – Tudor Sep 17 '12 at 16:54

score 1 · Accepted Answer · edited May 23 '17 at 12:29

Shell code is the payload used when exploiting a vulnerability that is used to create a command shell from which the attacker can control the machine.

A typical shell code when run might open a network connection and spawn cmd.exe on a Windows machine (or /bin/sh on Linux/unix) piping stdin and stdout over the network connection. An attacker may complete the connection from his machine and enter commands and get feedback as if he was sitting at the compromised machine.

A buffer overflow is not shell code. It is the vulnerability that is exploited to execute the shell code.

The buffer overflow is exploited to copy the shell code to the user's machine and overwrite the return address on the program's stack. When the currently executing function returns, the processor jumps to the uploaded shell code which creates the shell for the attacker.

For more information on exploiting buffer overflows, have a look at Smashing the Stack for Fun and Profit.

You can try to use the -fno-stack-protector flag for gcc but I'm not very familiar with OSX or whatever stack protections it may use.

If you want to play around with buffer overflows, modern compilers and modern OSs have protections in place that make this difficult. Your best bet would be to grab yourself a Linux distro and turn them off. See this question for more information on disabling these protections.

Note you don't need to have a buffer overflow to execute a shell code. I've demonstrated opening a remote shell using a command injection exploit to upload and execute a batch file.

I get the overflow part, but I don't understand how you engineer the payload so that it manages to fall within the memory you are overflowing. — inbinder, Sep 17 '12 at 16:51
I'm trying to write buffer overflows to try some of this on my machine (osx mountain lion) and gcc gets grumpy about these things or has some protective measure. Any suggestions for self-testing? — inbinder, Sep 17 '12 at 17:22

score 1 · Answer 4 · answered Sep 17 '12 at 16:54

Basically, when a program runs, everything that's related to it (Variables, Instructions etc.) is stored in the Memory, as a Buffer.

Memory is essentially a hell lot of bits in your RAM.

So, for the purpose of our example, let's say that there's a variable Name that get's stored in Bit# 1-10. Let's assume that Bits 11-30 is used for storing Instructions. It's clear that the programmer expects Name to be 10 bits long. If I give a 20-bit-long Name, it's buffer's gonna overflow into the area that holds the instructions. So I'm gonna design the latter 10 bits of my Name such that the instructions will get overwritten by naughty ones.

'innocentmeNAUGHTYCOD'

That's an Attack.

Though not all instances are this obvious, there's some vulnerability in almost every large piece of code. It's all about how you exploit it.

Shell Code and kernel hacking OS Agnostic?

4 Answers4