the channel is moderated. Please, ask your questions in #qc
@trulux | hi guys
|
@trulux | well, I'm Lorenzo and andrewg is Andrew Griffiths from Australia
|
@MJesus | the questions will be trasfer by the conferencist here when hi are ready
|
@trulux | I think It will be better to let him introduce himself to us
|
@andrewg | ok
|
@andrewg | I'm Andrew Griffiths. I'm involved with various projects /
interests, such as a security conference in sydney, Australia.
http://www.ruxcon.org.au, and Pulltheplug, a commuinity of like minded people
(where I met trulux) http://www.pulltheplug.org
|
@andrewg | Also, I'm involved with felinemenace.. http://felinemenace.org
|
@andrewg | that's my introduction done.
|
@trulux | OK, sorry, I exited by mistake
|
@andrewg | nice quit message there btw :)
|
@trulux | heh, well, let's continue and forget it ;). Our talk is going to take
around 30 minutes of your time
|
@trulux | we're going to show code, mostly, and slides that I prepared with
some interesting contributions from Andrew
|
@trulux | let's bring the URLs to the contents...
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/
|
@trulux | there we go. The code and slides are stored there
|
@trulux | plus some proof of concept code at http://pearls.tuxedo-es.org/poc
-nox/
|
@trulux | slides: http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/n
extgenmalware-umeet05-slides.pdf
|
@trulux | please skip the very first 4 pages
|
@trulux | references to SELinux aren't removed from the slides. I originally
wrote it for a symposium and then pushed it to UMEET. Any doubts or questions
regarding what SELinux has to do with this will be solved during and after the talk
|
@trulux | OK, said, this we can start
|
@trulux | During this year, new threats have been appearing "in the wild",
deploying new techniques and making use of nowadays possibilities for
spreading and causing high economical losses
|
@trulux | This past summer, I started researching on new possible threats
and techniques that, taken from the software protection industry and other fields,
could be dpeloyed in malicious software
|
@trulux | aka malware
|
@trulux | So-called spyware has been there since many time, but there's an
increasing risk related to commercial malware
|
@trulux | I came up with the idea of a prototype deploying some of the
techniques that I found to be potentially "useful" for malware
|
@trulux | and this talk is the result of such work
|
@trulux | switch to page 9 of the slides
|
@trulux | A little introduction to the "Old school techniques": there we are
mostly looking at Silvio's work on anti-debugging and such
|
@trulux | after that we'll look over the "New school techniques": they
involve machine virtualization, "cryptovirology", etc
|
@trulux | let's start with the old school techniques
|
@trulux | on slide 9 we can see a simplistic technique used by malware to
"hide" it's presence on the system: rewriting the pointer/changing contents of
argv[0]
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/argv0-ov
erwrite.c.html
|
@trulux | there's not a lot to say about it. it's easy to defeat and new
techniques appeared, at least to try to solve it's weaknesses
|
@trulux | let's switch to page 10
|
@trulux | breakpoints detection and debugger "traps"
|
@trulux | this was presented first by Silvio, and it concerns a way to detect
function breakpoints set by a debugger in order to "check" if we are being
debugged/traced
|
@trulux | I've prepared some code showing a few more possibilities upon
this old technique:
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/break-da
nce.c.html
|
@trulux | and one much more simple involving also a pretty old technique
for detecting ptrace(0) based debuggers:
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/int3-opco
de.c.html
|
@trulux | the first will set the function pointers to point "recursively" at the
breakpoint set to a specific function
|
@trulux | you can test it easily with gdb. just start a gdb session and set
breakpoints to func1, func2 and func3
|
@trulux | then run it and check the effects
|
@trulux | after that, check the execution flow when no breakpoint is placed
in the code
|
@trulux | this technique is eays to defeat using binary patching, and you
can come up with a specific tool for looking up the sequences of "traps" (int3
opcodes) in the binary and replace/patch them to be a nop
|
@trulux | int3-opcode.c does pretty much the same, but it checks for
debugger/tracer presence instead of breakpoints at specific functions
|
@trulux | let's switch to slides 13 and 14
|
@trulux | a little look over junk code and polymorphism
|
@trulux | junk code, as you can read in the slides, is nothing but non
operational code placed to fool the reverse engineer. Once you disassemble the
code, you can easily identify junk code blocks as they're usually "eneveloped"
with pusha/popa instructions
|
@trulux | then, as I mentioned earlier with the int3 related technique, you
cna patch the binary for replacing the junk code blocks with NOP instructions
|
@trulux | let's look over some code:
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/jcode.c.h
tml
|
@trulux | if you look over the assembler bits in the source, you'll find out
easily that it does nothing, as well as the pusha starting instruction, and popa
ending instruction
|
@trulux | that keeps the junk code out of "compromising"/corrupting the
execution flow by preserving the original state of the registers
|
@trulux | then a "real" operation (c = b - a;)
|
@trulux | time to look over the patch for that source:
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/rm-junkc
ode.c.html
|
@trulux | first off, we define a image base (0x08048000), then we define the
addresses where junk code starts and ends
|
@trulux | as well as a data structure containing the code we'll use for
replacing the junk code and the size of the opcodes
|
@trulux | {JUNK_VMSTART, "\x60" /* pusha */, 1},
|
@trulux | the first column/structure member is the "position" within the
binary, relative to the image base
|
@trulux | and the junk code block start address
|
@trulux | there's not a lot more to see there...
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/internal-s
ignal-handling-RIT.c.html
|
@trulux | there we go with an exmaple going further on this old technique
|
@trulux | example, even :)
|
@trulux | OK, lemme explain it a bit, then we can switch to something more
interesting ;)
|
@trulux | [20:06] |
ms | the reason for patching it is
|
@trulux | [20:07] |
ms | so that one won't be looking at the same junk again
and again
|
@trulux | [20:08] |
ms | +?
|
@trulux | ms: yes, as well as "keeping" the junk identified and "de-activated"
|
@trulux | ie. we won't be falling over that code when debugging or
disassembling
|
@trulux | the latter is the more important one, dynamic analysis can be
fooled by other ways, but static analysis is quite a risk for malware developers
|
@trulux | ie. concepts, etc being taken out and known by the AV community,
enterprises willing to market malware, etc
|
@trulux | OK, let's continue. I'm going to explain that RIT source
|
@trulux | basically, it's inetntion is to make dynamic analysis a bit more
difficult, as opposite to the jcode example
|
@trulux | why? simply because it just changes the execution flow
|
@trulux | it's there to work "randomly"
|
@trulux | ie. 4000 iterations of NOPs, 5600 iterations of a randomized junk
code block, etc
|
@trulux | a fault zone leads to SIGSEGV, a trap zone to a int3 opcode...
|
@trulux | and so on
|
@trulux | when iterations have been "done", then it hits the "safe area"
where normal execution flow starts
|
@trulux | take a look over the refresh function if you want to understand
how things happen
|
@trulux | OK, not let's have a look over a not-really-functional-sample:
|
@andrewg | Just to provide some more information regarding static junk
code, it is possible to generate junk code and combine it with normal assembly
code via doing basic block analysis (breaking assembly instructions into groups,
based upon where register contents changed.) A practial example of this can be
seen in teso's object obfuscator (objobf in packetstorm should find the tar ball)
|
@trulux | andrewg: thanks for pointing that out. BTW, it's worth to say the
URL of your work too
|
@trulux | Andrew has worked on this for much more time than myself and
he wrote a really nice paper on the field
|
@andrewg | No problems. As trulux just mentioned, I've done some work in
this previously. this can be seen at http://felinemenace.org/papers/Binary_protecti
on_schemes-1.00-prerelease.tar.gz
|
@trulux | regarding the non fucntional sample of junk "generation":
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/junk-cod
e-generation.c.html
|
@andrewg | some previous slides of mine can be seen at
http://felinemenace.org/papers/ruxcon_2005_protection.pdf and
http://felinemenace.org/papers/ruxcon_2005_protection_ti.pdf which were
presented at recon and ruxcon. Anyways, on with the show.
|
@trulux | non functional means it's fuzzy, like those things that work from
time to time ;)
|
@trulux | personally I recommend the paper PDF and the slides
|
@trulux | Andrew has done a great job on that
|
@trulux | worth the time for reading it!
|
@trulux | let's switch to the next slides if no one has questions
|
@trulux | switch to page 18
|
@trulux | there we go with the so-called and well known ptrace(0) technique
for detection of present debugegrs/tracers
|
@trulux | note that this only affects debuggers based on ptrace() and
tracers like strace, ltrace, etc
|
@trulux | I couldn't comment about this talk to the ELFsh crew about this
talk but they have done great work on this field (non ptrace() debuggers and
such):
|
@trulux | http://elfsh.segfault.net/
|
@trulux | if you cna wait a bit, I think we could have the guy behind ELFsh
here
|
@trulux | just a sec :)
|
@andrewg | hehe. I provided some help to the elfsh guys (hi mayhem!) @
what the hack
|
@trulux | yeah, mayhem is a really nice guy :)
|
@andrewg | hm, I can talk a little about how the elfsh debugger works if as
well
|
@trulux | OK, that would be cool while I try to bring mayhem to these lands
|
@andrewg | ok
|
@andrewg | The elfsh debugger works by using the sigaction() interface
|
@trulux | I hope he doesn't kick me out as there has been a while sicne I
don't talk with him
|
@trulux | ;)
|
@andrewg | this allows you to specify the SA_SIGINFO flag
|
@andrewg | which is defined as
|
@andrewg | SA_SIGINFO
|
@andrewg | The signal handler takes 3 arguments, not one. In
this
|
@andrewg | case, sa_sigaction should be set instead of
sa_handler.
|
@andrewg | (The sa_sigaction field was added in Linux 2.1.86.)
|
@andrewg | The extra parameters allow you to get indepth information
about the process
|
@andrewg | such as register contents etc
|
@andrewg | It also allows you to modify the register contents, so when the
signal handler returns
|
@andrewg | the processes registers change
|
@andrewg | including eip
|
@andrewg | by hooking certain signals (SIGTRAP / SIGSEGV / some others)
you can implement a debugger inside the process
|
@andrewg | The sa_siginfo parameter in the struct sigaction is:
|
@andrewg | void (*sa_sigaction)(int, siginfo_t *, void *);
|
@andrewg | the one we are interested is the void *
|
@andrewg | the third parameter is a ucontext_t
|
@andrewg | which is defined as (sec
|
@andrewg | defined in sys/ucontext.h
|
@andrewg | typedef struct ucontext
|
@andrewg | {
|
@andrewg | unsigned long int uc_flags;
|
@andrewg | struct ucontext *uc_link;
|
@andrewg | stack_t uc_stack;
|
@andrewg | mcontext_t uc_mcontext;
|
@andrewg | __sigset_t uc_sigmask;
|
@andrewg | struct _libc_fpstate __fpregs_mem;
|
@trulux | there we go
|
@andrewg | } ucon
|
@andrewg | hiya mayhem :)
|
@mayhem | hi there
|
@andrewg | by using the uc_mcontext struct, you can get the registers of
the process
|
@andrewg | anyways, I'll hand it over to mayhem :)
|
@andrewg | I've briefly covered about how to trap signals / get register
values etc.
|
@trulux | mayhem has little time but may be able to point out the most
interesting features of ELFsh
|
@mayhem | hello everyone
|
@mayhem | I have only 10 minuts left before I have to leave, but I can
introduce various elfsh features that probably few has experiented, even if its
public for 2 years for some
|
@trulux | :)
|
@trulux | mayhem: no worries
|
@mayhem | the first interresting thing that we should probably start with, is
ET_REL injection into ET_EXEC
|
@mayhem | in other words, relocation of a .o inside an already existing
NON-relocatable binary
|
@mayhem | that allows for post-linking extensions of binary files, for a lot of
different uses
|
@mayhem | logging, program instrumentation, closed source software
extension
|
@mayhem | and so on.
|
@mayhem | I suggest you read the Cerberus ELF Interface paper, first of the
serie
|
@mayhem | you can also use dynamic features of the embedded ELF
debugger
|
@mayhem | which is a debugger that doesnt use ptrace
|
@mayhem | the standard debug api of UNIX
|
@mayhem | it can do everything that a normal debugger does
|
@mayhem | except it bypass all antidebug protections by injecting the
debugger inside the debuggee process
|
@mayhem | you can do that injection directly in the binary, or using the well
known LD_PRELOAD technique for direct injection into the process
|
@mayhem | this is detailed in the second article of the Cerberus serie
(Embedded ELF Debugging)
|
@mayhem | those techniques works for ET_DYN files as well (libraries)
|
@mayhem | and were successfully implemented on hardened gentoo
binaries as well.
|
@mayhem | without any trouble.
|
@mayhem | as for the redirection techniques
|
@mayhem | that complement the residency techniques I just talked about
|
@mayhem | you can use many different techniques, some are ELF
dependant and thus architecture independant, others are architecture dependant
and binary-format dependant
|
@mayhem | binary-format INdpeendant, sorry.
|
@mayhem | since I dont have much time, I will conclude on this point :
|
@mayhem | embedded debugging outsmarts classic debugging with gdb in
terms of performance
|
@mayhem | since you dont have any context switching
|
@mayhem | so thats particulary well suited for dynamic program analysis
|
@mayhem | the new version of e2dbg, the embedded ELF Debugger, now
support multithreads
|
@mayhem | and the debugger runs in a dedicated thread
|
@mayhem | which allow for a complete unintrusive debugging, since the
debugger has a different stack.
|
@mayhem | we also managed to get the debugger uses a different heap.
|
@mayhem | by redirecting the *alloc* and free calls, and calling the good
library (either the native one, or an alternative one that only the debugger use,
which only uses mmap and not sbrk/brk)
|
@mayhem | soul_rea, that opens the door on exploit debugging technique
that does not change the exploiting context of the process
|
@mayhem | both elfsh and e2dbg are scriptable
|
@mayhem | full scripting with variables, loops, and everything
|
@mayhem | if you have any question, you are encouraged to contact
elfsh@devhell.org
|
@mayhem | Im running out of time at the moment, so I tell everyone GOOD
EVENING
|
@andrewg | thank you mayhem for coming here and doing an impromptu
presentation :)
|
@trulux | BTW, ELFsh also outputs graphviz diagrams of the execution flow
AFAIK
|
@trulux | yup
|
@MJesus | and thanks !
|
@mayhem | yea it does, but another project at Devhell Labs which is not yet
released
|
@mayhem | called chevarista
|
@mayhem | does much more than simple control flow graphs
|
@mayhem | both cflow and dflow graphs
|
@trulux | mayhem: neat, I'll have to see what I can for that. we'll talk later
hopefully
|
@mayhem | encouraging results, like automatic detection of some classes
of vulnerabilities, are now possible
|
@mayhem | but the project remains unreleased for now, the release date or
mode is not decided yet, so stay tuned.
|
@mayhem | thanks for listening, I detach
|
@trulux | mayhem: take care!
|
@andrewg | 11:31 < ms> maybe @ andrewg when mayhem is done, how
can you get "fine grained" control over a process
|
@andrewg | with just signal handlers?
|
@andrewg | It is possible to get quite fine grained control over a process
using signal handlers. For example, it is
|
@andrewg | possible to single step a program, and trace through it that
way. For an example of this, see http://felinemenace.org/~andrewg/stuff/running_li
ne.c which implements the same. You can also break on page accesses (by
mmap(.., 4096, PROT_NONE)), insert debug traps.
|
@trulux | OK, so, andrewg, are you going to make any further comments or I
go ahead with the remaining slides?
|
@andrewg | One limitation at the moment is that you can't use hardware
breakpoints at the moment. I haven't fully explored this, but perhaps there is a
work around. (You can use hardware breakpoints with ptrace, obviously).
|
@andrewg | To sum up the question, you can do almost anything you want
using signal handlers (granted, it may require a bit of thought first.)
|
@trulux | OK
|
@andrewg | you can continue now :)
|
@trulux | Okay dockey
|
@trulux | :)
|
@trulux | OK, I left it in the slide at page 18
|
@trulux | ptrace(0) based debuggers can be detected with a callback in the
binary with the PTRACE_TRACEME flag
|
@trulux | that is, flag indicating process is to be (p)traced
|
@trulux | if positive, call will fail and we'll know we're being (p)traced
|
@trulux | if negative it will return 0
|
@trulux | this can be quite easily defeated from both kernel-land and
user-land:
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/libmalwar
e.c.html
|
@trulux | OK, that's a quite dirty night hack
|
@trulux | I thought: "Let's work out something useless relying on
PRELOAD", so, here it's the thing
|
@trulux | quite simple, possibly buggy, etc
|
@trulux | it basically intercepts libc function calls using the well known
redirection method presented in Phrack long time ago
|
@trulux | it will detect an application trying to check the TRACEME flag as
well as other common checks, for protecting itself:
|
@trulux | ANTI_ANTI_DEBUG blocks
|
@trulux | ie. binary checking for LD_PRELOAD
|
@trulux | it will log operations and such
|
@trulux | well, any questions at this point?
|
@trulux | (BTW, libmalware is in no way finished)
|
@trulux | I'll try to finish it some day
|
@trulux | hmm... and there we go, the new school techniques
|
@trulux | I hope these ones are of better interest ;P
|
@trulux | switch to slide at page 20
|
@trulux | hiding our presence with elegance...
|
@trulux | lcamtuf wrote some code for gathering information of running
processes in order to change the argv[0] for faking a real, existent process
|
@trulux | kind of weak technic anyways, as it can be prevented by limiting
processes of accessing other processes data
|
@trulux | ie. with SELinux (Type Enforcement plus RBAC, MLS, etc, that is, a
Mandatory Access Control "framework")
|
@trulux | let's switch to an interesting topic, slide at page 21
|
@trulux | Machine virtualization
|
@trulux | well, VMs are nothing but a CPU implementation able to recognize
and "parse" a concrete instruction set
|
@trulux | (note: an instruction not present in the VM set will lead to an
invalid instruction fault in any system, for example try to call rdtsc on sparc64)
|
@trulux | applied to malware, they can provide a great "shield" against most
types of analysis, both static and dynamic
|
@trulux | we can store encryption keys, move registers and perform "fuzzy"
operations being isolated
|
@andrewg | Just as a side note, a recent honeynet scan of the month
challenge was reverse enginerring a binary by Nicolas Brulez (hiya :) -- this can
be seen at http://www.honeynet.org/scans/scan33/ .. it utilitises some of the
things mentioned so far.
|
@trulux | andrewg: yup, the RSTACK people have done really ncie stuff :) I
met them at France...
|
@andrewg | (virtual machines / junk code / debug tracks etc)
|
@trulux | well, later Andrew will present something really nice he has done
to serve as an example
|
@andrewg | cool, I met nicolas @ recon.. and sid @ recon / ruxcon.
|
@trulux | :)
|
@andrewg | Just as a note, The aim of a virtual machine implementation is
to make analysis by reverse engineering a lot harder
|
@trulux | I met the MISC magazine people too, if I'm not wrong
|
@trulux | :)
|
@trulux | right
|
@trulux | that is, we isolate pour code form the system
|
@trulux | and the VM is the link between our code and the real system
|
@trulux | switch to page 22
|
@trulux | Nowadays, VM engines are widely available and used many times
for honeypots and such
|
@trulux | ie. User-Mode Linux, VMware, Qemu, Bochs, Simics and Xen
|
@trulux | the problem is that there's no "assurance" of the isolation
betwene the Guest OS and Host OS, or at very least, assurance at identification
level
|
@trulux | ie. being able to know we are inside a VM
|
@trulux | UML and VMware are well known cases of weak isolation and
containment of the information
|
@trulux | although, some solutions appeared that make a difference on the
topic
|
@trulux | HP NetTop is a high assurance computing product which works
upon an isolated Host OS with SELinux and Guest operating systems being
classified at different levels
|
@trulux | running with their own security properties, etc
|
@trulux | it also closes an important failure of VMware
|
@trulux | a backdoor for compatibility with the vmware-tools
|
@trulux | a low-level I/O port that has been known since many time ago
|
@trulux | it enables Guest OS <-> Host OS communication for different
functions
|
@trulux | ie. smooth mouse movement and switch from guest to host os
input
|
@trulux | this port can be arbitrarily turned ON even when disabled through
the prefs. dialog in VMware
|
@trulux | please switch to page 23
|
@trulux | a diagram shows the process that I've implemented in a working
"exploit"/POC that I'll show immediately after explainign the diagram
|
@trulux | the info. above is the disassemble of the section that contains the
access info for the low level I/O port
|
@trulux | ok, we basically have code with a main() option and a check for
present VM
|
@trulux | is_vm() checks for virtualized machine environment
|
@trulux | negative? (not in vm) ok, normal_flow() ...
|
@trulux | positive? (inside vm) then anti_vm_flow(), are we in
VMware/nettop? (is_vmware())? if not, do() something
|
@trulux | if positive, do we have cap_sys_rawio capability/root privileges?
|
@trulux | negative? do() something else
|
@trulux | positive, then check if low level io port is enabled
|
@trulux | if positive, then either randomly select to leak Host OS clipboard
data or sned junk data to it
|
@trulux | or harmful data
|
@trulux | (I researched on a possible integer overflow regarding sending
data to host os clipboard but seems not exploitable)
|
@trulux | if negative, we try to enable it
|
@trulux | and then proceed to the actions
|
@trulux | let's see a working exmaple now plus some tools I coded to patch
vmware binaries for protecting against this nasty undocumented feature:
|
@trulux | http://pearls.tuxedo-es.org/poc-nox/vmware_hostclipboard.c
|
@trulux | that POC/exploit will leak/set Host OS clipboard data even when
the feature has been disabled in the Host OS
|
@trulux | note that there are obscure settings since 5.x versions of vmware
that need to be set in /etc/vmware/config and can disable it completely but this
will make us unable to sue the "advanced" features
|
@trulux | aka the vmware-tools
|
@trulux | these are the Isolation. settings
|
@trulux | out of the scope of the talk
|
@trulux | I haven't released this POC before, as I needed to confirm first the
possible impact, now there's a little risk as most have updated their vmware or
used the Isolation settings
|
@trulux | http://pearls.tuxedo-es.org/poc-nox/vmware_hostclipboard.log
|
@trulux | that's log of successful exploitation
|
@trulux | |
ms | trulux: is this "bug/feature" in vmware still present in
recent vmware implementations, say 5.0, 5.5?
|
@trulux | |
ms | thanks
|
@trulux | I think so
|
@trulux | 5.0 has it, 5.5 probably, but I didn't check
|
@trulux | 5.0 and above have the Isolation settings but thsoe aren't even
documented in the config file, only in their online reference
|
@trulux | http://pearls.tuxedo-es.org/poc-nox/cmd-brute.c
|
@trulux | that's a tool I used to check the status of each register after
running commands against the vmware "backdoor"
|
@trulux | http://pearls.tuxedo-es.org/poc-nox/vmware-llio-cmd_scan.log
|
@trulux | log for the 5.0 builds there
|
@trulux | now the fix
|
@trulux | :)
|
@trulux | unofficial (I didn't get paid by VMware for doing it, so far) ;)
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/fix-vmwa
re.c.html
|
@trulux | there we go
|
@trulux | self explanatory
|
@trulux | will patch vmware binary, and can do it in two ways
|
@trulux | either rmeoving the feature
|
@trulux | overwriting the related code with NOPs
|
@trulux | or just change the address of the low-level i/o port
|
@trulux | note that the latter would require to modify vmware-tools source
|
@trulux | check the comments carefully to find out how to get the necessary
data for using the tool with newer releases
|
@trulux | OK, let's switch to page 24
|
@trulux | BTW, andrewg code at http://pearls.tuxedo-es.org/papers/nextgen
m-umeet-2005/vmbase.tgz
|
@trulux | OK, Andrew, are you going to get over it?
|
@trulux | I can introduce you to Andrew's sample VM
|
@andrewg | I'll talk for a bit I guess
|
@trulux | OK, cool
|
@andrewg | The code at the above url implements an extremely trivial virtual
machine with its own code base. it implements 4 instructions
|
@andrewg | First instruction ends the virtual machine code execution loop
|
@andrewg | Second moves an int into a virtual machine register (unsigned
int regs[8]; on the stack..)
|
@andrewg | Third moves from one register to another
|
@andrewg | The Fourth, and last, instruction prints out the contents of a
register
|
@andrewg | Whilst not useful, the aim of that code was meant to show how
a virtual machine can be written
|
@andrewg | If you were to write a virtual machine, you'd need to sit down
and work out what instructions you want
|
@trulux | andrewg: and possibly a compiler for your own "meta code"
|
@andrewg | and how complex you want to make it. some things you can do
to make it more complex is making the instructions randomised
|
@andrewg | trulux: yep, was going to get to that :)
|
@trulux | andrewg: working out VMs in ASM is fun but difficult to maintain
though
|
@trulux | ;)
|
@andrewg | some other things you might want to do is design the vm
instructions so the code isn't linear, but jumps around based on where the code
is located, and what the instructions were doing
|
@andrewg | An example of this might be using the EIP of a program from a
signal handler call to decide where to start the vmware execution
|
@andrewg | and not having a completely direct 1 to 1 mapping of where the
code is going to be executed
|
@andrewg | That's about it I think.
|
@trulux | hmm, shall I make a few comments?
|
@andrewg | if you wish :)
|
@trulux | ;D
|
@trulux | OK
|
@trulux | well, the ideal VM would be one that allows you to embed your
own meta code in order to really defeat the 0% of reverse engineers. And annoy
the 10% left.
|
@trulux | err, 90%
|
@trulux | damn keyboards, the fail in the worst time!
|
@trulux | OK, so, a compiler would have to deal with "meta code" to be
interpreted by the VM and "translated" to real machine instructions
|
@trulux | this is a difficult approach anyways
|
@trulux | some other things should be considered too
|
@trulux | for example the functionality
|
@trulux | are you going to deal with every function you want to implement in
your application? Not really
|
@trulux | so, normally it's all about "enveloping" the binary much like
packers do
|
@trulux | but an an intrusive manner for controllinbg registers, etc
|
@trulux | I was working on a malware-oriented UPX-based packer but left it
as I hate the way UPX is coded (C++ and that junk)
|
@trulux | we'll see later some cryptography related techniques applied to
malware and software protection
|
@trulux | OK guys, let's switch to page 25
|
@trulux | Applied cryptography for software protection
|
@trulux | per-page and per-function encryption, .text obfuscation, generated
network traffic protection, integrity assurance of internal data, etc
|
@trulux | for example
|
@trulux | we can "protect" strings and other information using XOR
encoding (it's weak but it has low performance penalty). shellcodes, gathered
data, etc. XOR encoding has beenused since many time ago
|
@trulux | for example inn the Colera worm done by GriYo from 29a
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/xor-tests.
c.html
|
@trulux | that would fool 'strings' binary as yould have to set it to show
strings of one char, and will defeat dynamic analysis
|
@trulux | in couple with a VM, we could protect 'static' (built-in if that makes
more sense) strings
|
@trulux | that is, those we define in our code and get compiled with the
binary
|
@trulux | also, a common technique is to make the binary non std
dependent
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/test11-no
nlibc-strcpy.c.html
|
@trulux | it would implement those functions required by the binary that are
normally in the libc
|
@trulux | thus, no shared library redirection techniques could be used to
intercept data and such
|
@trulux | also, copying functions or other "suspicious" operations should
be protected
|
@trulux | for example not using static filenames within the binary
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/test3-rdn
_string.c.html
|
@trulux | shows an example of generating a random string
|
@trulux | we could place code at /tmp/ faking a real application temporary
file, etc
|
@trulux | and copy ourselves with:
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/test7-self
-copying.c.html
|
@trulux | this shows that in order to protect the binary against compromise,
you need to use different "layers" of protection all-together
|
@trulux | I've made some measurements of common operations performed
by amlware in order to retrieve "random" (pseudo-random after all) data, although
it's pretty general stuff:
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/test8-ia32
-rnd.c.html
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/measure
ment-ia32-rdtsc-time.png
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/measure
ment-ia32-rdtsc.png
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/measure
ment-key.png
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/measure
ment-rand-time.png
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/measure
ment-rand.png
|
@trulux | (it uses gnuplot to plot the data written by the test8-ia32-rnd binary)
|
@trulux | gnuplot script at http://pearls.tuxedo-es.org/papers/nextgenm-ume
et-2005/measures.plot
|
@trulux | so, that's it, it's self-explanatory code so far
|
@trulux | I missed to comment about this when Andrew talked about the VM
stuff:
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/build-ran
domization/
|
@trulux | in order to protect the binary from patches and detection, we
could randomize the image base at build time and runtime (andrewg, any
comments on this?)
|
@trulux | at build time it can be done by using a custom ld-script
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/build-ran
domization/sedai-ld
|
@trulux | we can place markers and then use something to replace them,
generating a working ld-script that is used to link the binary
|
@andrewg | runtime it could be done using a -fpie (postition independant
executable) binary, and relocating what's needed (haven't fully looked into that
option, its on my todo list amoungst others)
|
@trulux | sedai is the malware prototype I've bene working on, and currently
makes use of all of these methods, although I'm not going to release binaries nor
code
|
@trulux | andrewg: hmm, interesting, but we would have to dump the binary
from memory at some point
|
@trulux | andrewg: pipacs may have some ideas/comments regarding that
|
@andrewg | yup, I'm more than welcome to hear them :)
@pipacs | err, ideas on what exactly? ;)
|
@trulux | pipacs: :), runtime modification of a binary image base
@pipacs | you mean, 'self-relocation'?
|
@andrewg | pretty much
|
@trulux | pipacs: yes, kind of
@pipacs | hard to do because you don't know where pointers to your first
mapping are stored (and used later)
@pipacs | think of ld.so storing address in the link_map structure and the
like
@pipacs | or signal handlers registered to your executable
|
@trulux | BTW, it also would help for binary watermarking
@pipacs | remapping those without modifying all references will crash
sooner or later, accounting all such references is lot of work
|
@trulux | on build time
|
@trulux | yep
|
@trulux | pipacs: an engineer would say "non trivial stuff, lah"
@pipacs | you can do runtime remapping on self-contained code though
@pipacs | like shellcode
|
@trulux | BTW, let's switch to page 26
|
@trulux | per-function encryption by Andrew
|
@andrewg | side note about that, that now pipacs is here -- you'll need to be
able to mark the page(s) as writable and executable.. using pax this means setting
certain flags and program headers (chpax and paxctl), and hoping acl systems
doesn't block it (grsec's acl mode is discrensionary atm) :)
@pipacs | it looks similar to the 'running-line' that does this
decryption/re-encryption thing on a per instruction basis
@pipacs | old DOS anti debugging trick ;)
|
@trulux | andrewg: IDT thing shouldn't work with PaX enabled also
|
@andrewg | idt_test.c ?
@pipacs | what does it do?
|
@andrewg | sidt / iopl(3) / sidt
@pipacs | that's legal in any linux ;)
|
@andrewg | just to show that vmware needs an iopl level of 3 before giving
you access to the "real" idt address
|
@andrewg | nod, since sidt is an unprivileged instruction :)
@pipacs | sidt gives you the 'real' IDT
|
@trulux | pipacs: maybe I'm confusing it with the other tool red pill or
something
|
@trulux | lemme check
@pipacs | what vmwware does is that it changes the IDT depending on your
iopl
|
@trulux | yes, I was talking about this: http://invisiblethings.org/papers/redpil
l.html
|
@trulux | sorry
|
@trulux | well, I can go ahead with the slide at page 27
|
@trulux | any further comments we want to make on this? andrewg ?
|
@trulux | we haven't explained per-function encryption yet
|
@andrewg | not really, except to say that given enough time people will
work around it and defeat it :)
|
@trulux | BTW, code at http://pearls.tuxedo-es.org/papers/nextgenm-umeet-
2005/perfunc_andrewg.tgz
|
@trulux | heh
|
@trulux | ok, then let's go over the very last slide
@pipacs | per-function encryption can be defeated the same way the
running line was: logging tracer
|
@trulux | please switch to page 27
|
@trulux | OK, regarding the first block
|
@trulux | we have seen many "scripts", like those annoying spam ones, that
"walk up" through search engines for looking up vulnerable web services
|
@trulux | the problem is that normally they just implement one search
engine and within one network, so, the worm gets blocked in that search engine
and propagation stops
|
@trulux | the Zeroboard worm is a good exmaple of this technique
|
@trulux | I decided to write up an example of an improved search engine
selection code that could be used in a Zeroboard-like worm
|
@trulux | http://pearls.tuxedo-es.org/papers/nextgenm-umeet-2005/test9-sea
rch-sites.c.html
|
@trulux | a weird hack but shows pretty well the idea
|
@trulux | we select a final random URL upon different languages that are
supported by the different defined search engine networks
|
@trulux | in line 118 you can see other data that could be randomized in
order to prevent the worm to be identified
|
@trulux | this way, we could use search engines randomly for looking up
vulnerable web services (ie. XML-RPC servers, etc)
|
@trulux | not even talking aboutthe possible usage in Spam-related
applications
|
@trulux | it would make detection and counter-measure much more difficult
|
@trulux | on the slide, I refer to the possibility of exploiting the software
running on network hardware itself, for example Cisco IOS
|
@trulux | anyways, that's just speculation as builds would require different
data to deploy a sucessful attack
|
@trulux | we're done so far
|
@trulux | from page 29 to 30 you can find a little summary/final thoughts
page and references to articles and papers worth to read
|
@trulux | so, that was the talk
|
@andrewg | just a side comment if I may :)
|
@andrewg | 10:40 <@trulux> heh, well, let's continue and forget it ;). Our
talk is going to take around 30
|
@andrewg | minutes of your time
|
@trulux | haha
|
@andrewg | 13:10 <@andrewg> just ...
|
@andrewg | quick thanks to mayhem and pipacs for doing an impromptu
talk / discussion as well :)
@pipacs | je vous en prie ;)
|
@trulux | pipacs: :D
|
@trulux | pipacs: thanks too, dunno how you got to know the talk BTW :)
* andrewg sets mode: -m
|
@andrewg | any general questions / discussions?
@pipacs | i have my sources... ;)
|
@trulux | andrewg: thanks!
|
ms | haha
|
@andrewg | no problems :)
|
@trulux | pipacs: ms! the mickey mouse ******* squadron! who!
|
ms | nice talk guys, interesting views
|
@trulux | andrewg: thanks to you too man!
|
@trulux | No one wants to clap? :D
|
@trulux | andrewg: we left them sleeping, or seems so
|
@andrewg | indeed. no questions is a bad sign ;)
|
ms | well it always annoys me that the talk is 50% of the log and the otehr
50% is CLAP CLAP CLAP!
|
ms | :D
|
@MJesus | :)))
|
@MJesus | very nice talk
|
@trulux | andrewg: yes, at least the ptp folks will bomb us with questions
after we put up the log
|
@trulux | andrewg: hopefully!
|
@andrewg | trulux: yup :)
|
@trulux | MJesus: thanks
|
---|
|
---|
|
---|
|
---|
|
---|
|
---|
|
---|
|
---|
|
---|
|
---|
|
---|
|
---|
|
---|
|
---|
|
---|
|
---|
|
---|
|
---|