|
|
| (21 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| − | {{cleanup}}
| + | #REDIRECT [[:Category:Shellcode]] |
| − | | + | [[Category:Indexing]] |
| − | Shellcoding concepts... Where to begin? [[Assembly Basics]], I'd imagine. I should start by explaining that [[machine code]] has just as much power if not more than any other computer [[programming language]]. "Why doesn't anyone develop [[applications]] in [[machine code]], then?" you may wonder.
| + | [[Category:Exploitation]] |
| − | | + | |
| − | The answer is because [[machine code]] is extremely rudimentary. Writing a full application in [[machine code]] is not only time consuming but also taxing on the mind. The advantages of [[machine code]] [[applications]] are quite clear, though. [[Machine code]] executes faster, does not need to be interpreted like many scripting languages, and also takes up a smaller amount of space. For these reasons, [[machine code]] is my language of choice. Shellcode can be used to program virtually any application, the question is -- what are we coding?!
| + | |
| − | | + | |
| − | This is where we must look back at the [[security industry]], at the [[DEP]] being used by most common Operating Systems, and even look back to the operating systems themselves. Many times attackers settle for a bindshell, or a connect-back shell, during exploitation. This will not always be successful. Suppose for a moment that the remote host sits behind a [[firewall]] that restricts all outgoing connections and refuses to allow any incoming connections other than port 80. You overflow the [[HTTP]] daemon with shellcode for a bindshell on port 4444. The [[firewall]] is blocking your connection attempt to 4444, so while the server may even be running your bindshell, it does you no good. Now you try a connectback. The target server is unable to connect to your machine because it does not have permissions to create client sockets.
| + | |
| − | | + | |
| − | What do we do now? The answer is surprisingly simple. We craft custom shellcode to turn the socket that the exploit came in on into the actual bindshell.
| + | |
| − | | + | |
| − | This is just one of many shellcoding concepts. Ultimately, the most important concepts are [[anti-heuristics]], [[shellcode obfuscation]], and [[IDS]]/[[IPS]]/[[Firewall]] evasion. I have defined each of these for the reader below:
| + | |
| − | | + | |
| − | [[Anti-heuristics]]
| + | |
| − | | + | |
| − | Evading heuristics - evading debuggers, tricking the [[Programmer|programmers]], attacking debuggers, and evading/attacking virtual machines are all part of this technique. [[Anti-heuristics]] rely on the code's ability to protect itself from user, administrator, or even [[programmer]] and debugger intervention.
| + | |
| − | | + | |
| − | Obfuscation "Uglifying" one's code - obfuscation includes utilization of polymorphism and metamorphism, and describes anything that makes the code appear to do one thing or hold certain data when in fact the code does something else or holds different data.
| + | |
| − | | + | |
| − | [[IDS]]/[[IPS]]/[[Firewall]] Evasion Evading detection engines is currently best done by using alphanumeric shellcode. Alphanumeric and [[ascii shellcode]] appear within standard user-printable data, making your arbitrary code appear as standard user inputted data in stead of malicious [[machine code]]. Generally it is hard for an admin to detect that this is actually a payload to begin with.
| + | |
| − | | + | |
| − | Don't forget that [[machine code]] is just as powerful as any other [[programming language]]. [[Machine code]] can be used by a [[programmer]] to write any application - so why not write an entire application into your shellcode? To be honest, there is no reason not to. Approach writing your shellcode as if you were sitting down and writing an application in assembly.
| + | |
| − | | + | |
| − | Self-linking shellcode refers to [[Machine code|machine code's]] ability to use what functions are already present in memory as opposed to carrying all of its functionality within itself. From a general perspective, a linker is comprised of two parts. One part of the linker must be able to isolate the base pointer of any given library loaded into memory, and the other part of the linker must be able to parse the library and return the memory address for the start of any given function.
| + | |
| − | | + | |
| − | This is called self-linking shellcode or self-linking [[machine code]] because it does not rely on being linked with any kernel, in stead it finds the functionality it needs within the run- time environment and calls already existing functions out of memory. This will save the [[programmer]] time and size, and potentially even allow the [[programmer]] to write a cross-OS [[machine code]] application that is fully capable of using pre-built-in functionality of the operating system by linking itself in stead of relying on an external linker to both link and format the binary properly. Everything is possible in the world of technology today, and so I wish you and your shellcoding the best of luck.
| + | |
| − | | + | |
| − | | + | |
| − | [[Category:Buffer Overflows]] | + | |
