Other articles

1. Learning Assembly Through Writing Shellcode

   
   

   Months ago, I wrote hello world in X86 Assembly, and later that same day I wrote hello world in Python. Python is fast, elegant, and powerful. But unfortunately, it doesn’t really give you an understanding of what’s going on inside your computer. And any good little hacker should know precisely what’s going on inside their computer.

   Every time I start teaching myself some complicated thing, I try to make the learning process enjoyable because I know that I’ll retain more information if I can apply it to something fun or useful. Being a terribly precocious kid, I taught myself quantum mechanics when I was fourteen. It was really difficult, and I probably wouldn’t have been able to pull it off if I hadn’t made it fun. And, oh, did I make it fun: FOIA’ed thermonuclear weapons manuals, ten years expired, from some obscure and slightly sketchy web page. I didn’t mean any harm, and I neither was nor am a proponent of nuclear weapons production, maintenance, or warfare. I wasn’t planning on starting up an Uranium-238 enrichment program, or searching the black markets for hollow plutonium cores. I wanted to learn physics, and what’s more fun than learning how to destroy things?

   Assembly languages are cumbersome and arcane. The learning curve is steep, and progress is always slow compared to higher level programming languages. Fortunately, however, Assembly can be used to destroy things! Enter shellcode.

   The best introduction I found to writing shellcode was in Gray Hat hacking, so I’m going to quote the first few pages of the Linux shellcoding chapter, and then leave you to somehow obtain your own copy.

   Basic Linux Shellcode

   The term “shellcode” refers to self-contained binary code that completes a task. The task may range from issuing a system command to providing a shell back to the attacker, as was the original purpose of shellcode.

   There are basically three ways to write shellcode:

   • Directly write the hex opcodes.
   • Write a program in a high level language like C, compile it, and then disassemble it to obtain the assembly imstructions and hex opcodes.
   • Write as assembly program, assemble the program, and then extract the hex opcodes from the binary.

   Writing the hex opcodes directly is a little extreme. We will start with learning the C approach, but quickly move to writing assembly, then to extraction of the opcodes. In any event, you will need to understand low level (kernel) functions such as read, write, and execute. Since these system functions are performed at the kernel level, we will need to learn a little about how user processes communicate with the kernel.

   System Calls

   The purpose of the operating system is to serve as a bridge between the user (process) and the hardware. There are basically three ways to communicate with the operating system kernel:

   • Hardware interrupts  For example, an asynchronous signal from the keyboard
   • Hardware traps  For example, the result of an illegal “divide …

   read more

2. Shellcode, Hex Opcodes, and Dragons

   I just realised why directory names in *nix systems are often three characters. If you’re loading pathnames into a syscall in assembly language, you’re given four byte strings to work with. For example, to use the directory path of the shell “/bin/sh” as a variable within a syscall function, such as execve(), so that the resulting call would be execve(/bin/sh), you would need to push 0x68732f2f to the pre-cleared register (0x68732f2f is hex for “//sh” and the leading “/” doesn’t matter). Then push 0x6e69622f (hex for “/bin”) onto the stack. Actually, I’m not sure if this is why directories often have three character names, but it makes sense to me.

   I mean, right? The old sysadmins from yesteryear planned all this to deliberately make my task of writing shellcode easier? And dragons: they do exist.

   read more

3. Defcon Report Back, Part 1

   Friday 5th August 2011, Defcon 19, Las Vegas, NV

   Analyzing Embedded Malicious Code in PDFs

   So, the first was Mahmud Ab Rahman’s presentation on parsing and analyzing malacious code embedded in .pdfs. I can’t guarantee that paper doesn’t have anything malicious embedded. But I have modified the .pdf parsers written in python by Didier Stevens and played with .pdf malware, and generally been very confused and upset about .pdf structure and specifications, so Ab Rahman’s Sneaky PDF lecture was interesting. I can’t find video for that presentation up yet, but that .pdf above does contain everything said and the original slides. Basically, malicious .pdfs use JavaScript code obfuscation through spaghetti code, infinite loops, misdirected object references, code encryption, and media-rich embedded objects such as flash videos or audio files. Ab Rahman gave a few lists of tools which he used to better parse and de-obfuscate: tools such as SpiderMonkey, Rhino, V8, and JSBeautifier can all be used to fix spaghetti code, infinite loops, and misdirected object references, and tools like PDFminer, Gallus, Wepawet, APTdeezer, and Origami can be used in addition to Didier Steven’s above referenced tool for parsing. Also, I found an entire site on PDF security issues, with lists of relevant tools and white papers which go into more detail on obfuscation and detection methods.

   Linux Thread Injection

   Aseem “@” Jakhar presented on Jugaad, a newly released Linux Thread Injection kit, which uses the ptrace() function in gdb to inject arbitrary code into running processes. Here’s the pdf of his presentation, and here’s the slides from slideshare. Themmap syscall was used to produce shellcode in hex from assembly for payload creation. (If this sounds like jibberish, you might want to learn about what shellcode is and how to write shellcode, which is going to include learning assembler.) It’s essentially the Linux equivalent of the Windows malware CreateRemoteThread() API, and Jugaad provides all the functionality and ease-of-use as its Windows cousin. All the more reason to disable ptrace() functionality on boxes which are not being actively used in production environments, or use sptrace() to limit user access to that functionality.

   Runtime Process Library Injection

   Along a similar line,Shawn Webb talked aboutruntime process insemination (click for pdf) using his also newly released tool, Libhijack, to anonymously inject shared objects and libraries in as little as eight lines of C code, with little to no physical evidence left behind.

   UPnP Mapping

   There was a presentation on Universal Plug-and-Play (UPnP) device mapping by Daniel Garcia. Most of what I took from that was that Garcia’s Umap scanner allows mapping of hosts behind the device NAT, SOCKv4 proxying, and manual port-mapping from LAN to WAN and vice versa. This allows masking of IP addresses and attacking non-outward facing hosts within an internal network. Garcia released a new tool, Umap, which scans TCP for open ports behind UPnP enabled Internet Gateway Devices.

   Kernel Exploitation

   Next up was Kees Cook, head of security …

   read more

Page 1 / 1