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.
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.
