shellcode

[reaper]

Well I've been following along the shellcoders handbook for some time, and I found it really fun.  Anyways the Operating Systems and compilers have changed quite a bit since the book was written.

I've finally gotten some shellcode to work.  I:

1) turned off address randomization (your stack start address is randomized - each process has its own memory it thinks, which the MMU handles)
2) I disabled DEP (the stack is marked as non executable..)
3) I disabled stack canaries by not compiling into the vulnerable service

so the matter was fairly simple.  I had C source code that had a system call for a shell, this was already put into opcodes (which you could do by disassembling in gdb), it ran the shell.  then there was a program that output ESP of main, and took as parameters an offset and a buffer size.  I debugged the vulnerable program until the RET instructions, and looked at ESP at that time (points to RET then), and found the correct offset and memory address that is where the shellcode resides. 

Anyways it called the shell.  Now I am stuck with what to do next: go to return-to-libc, format strings, disassemble a C program and construct the shellcode.

Or try and turn on each OS & compiler security mechanism and see how to defeat it.  Now to me it seems the real gotcha is the stack canaries.  I guess you can overwrite a pointer variable with EIPs address, and if the function copies data to that region, the instructions execute, but that seems like a long shot and I didn't quite follow it.  And one method combines the random value with the original stored EIP..

Are these fundamental problems gone?  Does it matter so much input is checked at a low level anymore?  I can see a high level like making sure your web application doesn't upload an executable program.

edit: I can post the code if anyone wants, it's in the 2nd chapter and required a couple modifications, as well the OS required modification to weaken it : )

Now with all these security measures, how can something like the conflicker worm happen???

[kren.Z]

  Anyways it called the shell.  Now I am stuck with what to do next: go to return-to-libc, format strings, disassemble a C program and construct the shellcode.

Well if you've been able to spawn a shell then you've successfully achieved your goal as an attacker. Namely that of comprising the intended system and having complete access/control of that system with administrator (root) privileges (i.e. as if you were sitting at the keyboard). So you really wouldn't need to do anything next...

Now if you were to approach the problem as the software author then you would need to fix the problem by either patching the binary or distributing a completely different binary altogether.

  Now with all these security measures, how can something like the conflicker worm happen???

When an attacker looks to exploit a system, they will usually run the system in a simulated environment via a virtual machine and usually do all their debugging/reverse engineering in that environment. conflicker only targeted the windows operating system.

For example stuxnet,  which only targeted Iranian enrichment facilities. SCADA systems usually run a specific product on a specific operating system. In stuxnet's case, it attacked a siemens product on  a version of microsoft windows.

From there you try to look at application processes that are run with administrative privileges. One of stuxnet's 0 days exploited a registry check that generated a hash based on a timestamp that was run as an administrative processes. they wrote shellcode to take advantage of this.


------------------------------------------------

Web application hacking is limited since it's only open to one avenue of attack, namely the HTTP protocol. So you will try to look for interfaces to the back-end database and craft special queries or file uploads which will put a binary on the remote server. Or you scan the entire server for applications or services listening on different ports, analyze/reverse engineer the protocol, and then start talkin' dirty.

You're looking at nitty gritty details like operating systems, cpu instruction sets etc when you really need to see the 10,000 ft. overview.

In hacking, the goal is simple. To gain complete control over a remote machine. How you go about accomplishing this goal is up to you and is what makes hacking...well...hacking.


1.Find your target.
2. Analyze your targets system, find what applications are running on this system. Reverse engineer these applications in a simulated environment and look for vulnerability's.
3. Write shellcode.
4. Find a way to deliver the payload to the target.
5.get your shell

[reaper]

I don't think conflicker would work if the function addresses were randomized or if there were stack canaries, because it looks to me like it attacks a buffer overflow problem, by negotiating an SMB session with a Windows service, then calls a function in that service.  If the system had stack canaries, that used the real value of RET the service should just crash because the canary shouldn't match.  maybe Windows 2003 didn't have these security features?  However I'm not sure.

I copied a vulnerable program so I knew what the stack looks like, and I could debug the program to find where the shellcode was in memory.  I suspect it'd be much harder if the program overwrite the stack later in execution, or if there were a number of security features..


http://mtc.sri.com/Conficker/

Well if you've been able to spawn a shell then you've successfully achieved your goal as an attacker. Namely that of comprising the intended system and having complete access/control of that system with administrator (root) privileges (i.e. as if you were sitting at the keyboard). So you really wouldn't need to do anything next...

I spawned bash and bash drops privileges by default, so even if you had a service with setUID, so it runs as root, then your shell would still be dropped, since /bin/sh is linked to bash which drops down from root, but you control execution so you could also do other operations to get root.

I think I'll work on a couple things:

return-to-lib-c
creating the shellcode via disassembling
moreee C pointer stuff : )
crafting the datagrams to a TCP/IP aware service