8

I can understand what a buffer overflow is and that it allows you to write in places of the memory that you shouldn't be able to. I can also grasp the concept that there may be other software vulnerabilities out there that work in some different way that allow you to place things you want in memory. I've also gained access to some old XP machines of mine using metasploit, which was fun.

But I cannot trully understand how you can get access to the remote system by having (for example) the buffer overflow vulnerability in mind.

There are some points that are not clear for me:

  1. Does the program that has the vulnerability need to run and to listen to a specific port on the victim machine (like a mini-server or something)? Can a program that is badly written be exploited remotely if it doesn't listen to a port?
  2. I assume that the program will read some input from that port and then write it to memory in some variable and maybe process it. Giving the program more data than it should read, and providing that it has the vulnerability, it is going to write to a location into the memory (specifically, exactly after the variable) whatever we want. How doesn't this crash the program 99.9% of the time? What if exactly after the place in memory where this variable is stored there is a pointer to some function that fails to execute and the program crashes?
  3. Providing that the program does not crash, how can we execute the code that we have injected into the memory? Do we need to place the code we want in a place inside the memory that we know it's going to be executed? How can some random part of the memory be executed? Almost never in my programs I execute some variable of mine, unless I want to run some other program, which is very rare and it shouldn't be the same as directly executing code from memory (which reminds me of eval()).
  4. Providing that point 2 assumes correctly that the vulnerability usually arises when the vulnerable program reads malicious input from a port and that this code is executed, how is the executed code able to get back to me, the attacker? Do I send in the malicious code my IP address in a variable or something?
  5. Programs generally cannot read or write in another program's memory. Does this mean that when the vulnerable program closes I will lost the connection to the open remote shell? Or does it spawn an independent subprocess once it executes and I am actually connected to it?

Can anyone give me a simple but yet realistic and thorough example of how the whole system works, from the program listening to some port till the attacker gaining a shell?

  • 4
    Start with this classic: Smashing the stack for fun and profit – paj28 May 22 '15 at 22:08
  • Thanks for the link, but I would hope for a simpler and shorter explanation. – hytromo May 22 '15 at 22:10
  • 1
    This site format does not work so well for 5 different questions smooshed together into a single post. Please stick to one question per question. Also, we expect you to do a significant amount of research/self-study before asking, and to tell us in the question what you've tried. What resources have you looked at? Many of your questions are covered by standard resources -- there would be little value in just repeating those standard explanations here. – D.W. May 23 '15 at 6:09
  • @hakermania piece of advice: don't be lazy ;-) That paper is a goldmine of knowledge for newcomers, and I highly recommend all my students to read it. Since you understand the principle of remote code execution, just have your exploit set up a SSH reverse tunnel and you're done! – Steve Dodier-Lazaro May 23 '15 at 10:22
  • @SteveDL I am planning to read the paper. In fact, I've already read the first half, but I just needed a shorter answer that covers the main points of the broader concept. – hytromo May 23 '15 at 10:27
8
  1. Vulnerable programs need to listen to ports in order to access them over the network directly. But, you could gain access to the system through other means then exploit a vulnerable program that does not access the network (e.g. email malware that triggers a vulnerability in a PDF reader)

  2. Knowing how the vulnerable program behaves predictably is the key to finding and exploiting vulnerabilities. In short, you have to already know what will happen in the stack before you send the exploit. That's why, just like all programming: testing, testing, testing.

  3. If you understand BO, then you know that you write to the stack in a place where the pointer will direct the execution. That's how we can execute our code.

  4. Just as in my #1, the vulnerable program does not need to be a network service running on a port. If you want a 'reverse shell', then the code for the shell must include the networking code required to connect back to you.

  5. Yes, and yes. If you do not migrate to another process (either embedding into a running process or a new process triggered by your code), then once the vulnerable program ends, so does your connection. So, migrate.

My answer is a VERY simplistic view of your questions. There is a lot you can do to dig deeper in what I have provided, and even techniques that will contradict what I have said, but these are the very basics.

Simplistic Scenario:

A vulnerable FTP server is running on a port. You discover that a certain FTP command is not properly constrained, so it is possible to send overly large command arguments and write into parts of the stack that the FTP server accesses. You design code (including networking features) that can fit on to the stack space occupied by the FTP program. Then you connect to the FTP server and send the command with your shellcode as the payload. When the FTP server processes the command, it hits your code and processes the payload. Your shellcode executes and creates a networking connection back to your machine.

3

The buffer overflow allows an attacker to overwrite stored addresses on the stack that are used by the application when returning from a function. Once the attacker controls this address they can divert the execution of the program by returning to a different part of the application or the libraries it uses.

In its simplest form the attacker can write shell code to the stack beyond the address overwrite and will set the return address to a jmp esp instruction which will point eip to the stack an execute the data on the stack as code.

The shell code can then make an outbound connection or listen on a port.

The term Remote exploitation is often applied to no daemon programs such as a browser or emailing someone a file that exploits a vulnerability in the opening program, ie: a PDF file.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.