Runtime Process Insemination

Video thumbnail (Frame 0) Video thumbnail (Frame 2900) Video thumbnail (Frame 5149) Video thumbnail (Frame 7151) Video thumbnail (Frame 8379) Video thumbnail (Frame 11649) Video thumbnail (Frame 12538) Video thumbnail (Frame 13602) Video thumbnail (Frame 14532) Video thumbnail (Frame 16907) Video thumbnail (Frame 21774) Video thumbnail (Frame 23349) Video thumbnail (Frame 25357) Video thumbnail (Frame 27069) Video thumbnail (Frame 30172) Video thumbnail (Frame 32700) Video thumbnail (Frame 34266) Video thumbnail (Frame 44793) Video thumbnail (Frame 47685) Video thumbnail (Frame 54585) Video thumbnail (Frame 59426) Video thumbnail (Frame 61487) Video thumbnail (Frame 62615) Video thumbnail (Frame 64910) Video thumbnail (Frame 65779)
Video in TIB AV-Portal: Runtime Process Insemination

Formal Metadata

Title
Runtime Process Insemination
Title of Series
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
2013
Language
English

Content Metadata

Subject Area
Abstract
Injecting arbitrary code during runtime in linux is a painful process. This presentation discusses current techniques and reveals a new technique not used in other projects. The proposed technique allows for anonymous injection of shared objects, the ability to pwn a process without leaving any physical evidence behind. Libhijack, the tool discussed and released in this presentation, enables injection of shared objects in as little as eight lines of C code. This presentation will demo real-world scenarios of injecting code into end-user processes such as firefox, nautilus, and python. Shawn Webb is a professional security analyst. He works with Linux, FreeBSD, and Windows systems, finding vulnerabilities in in-house applications. He's a proud member and contributor of SoldierX. Twitter: lattera
Thermodynamischer Prozess Presentation of a group Run time (program lifecycle phase) Information View (database) Mereology Theory Formal language Web 2.0 Programmer (hardware) Googol Hacker (term) Blog Information security
Trail Presentation of a group Server (computing) Game controller Code Multiplication sign Random access Web 2.0 Revision control Virtual memory Semiconductor memory Different (Kate Ryan album) Gastropod shell Encryption Vulnerability (computing) Spyware Projective plane Memory management Parallel port Bit Connected space Web application Software Window Library (computing)
Ocean current Functional (mathematics) Run time (program lifecycle phase) Code Multiplication sign 1 (number) Function (mathematics) BEEP Malware Hooking Root String (computer science) Gastropod shell Authorization Physical system Thermodynamischer Prozess Programming paradigm Computer-generated imagery Memory management Bit Exploit (computer security) Connected space Web application Pointer (computer programming) Order (biology) Asynchronous Transfer Mode
Existence Functional (mathematics) Game controller Run time (program lifecycle phase) Computer file Process (computing) Coroutine Sheaf (mathematics) Metadata Computer programming Linker (computing) Semiconductor memory Address space Physical system Thermodynamischer Prozess Run time (program lifecycle phase) Structural load Binary code Bit System call Hexagon Linker (computing) Procedural programming Object (grammar) Table (information) Window
Computer virus Dynamical system Run time (program lifecycle phase) Computer file Code Multiplication sign Sheaf (mathematics) 1 (number) Mereology Metadata Computer programming Virtual memory Linker (computing) Semiconductor memory String (computer science) Address space Physical system Thermodynamischer Prozess Email File format Generic programming Maxima and minima Virtualization Compiler Uniform resource locator Pointer (computer programming) Order (biology) Right angle Object (grammar) Table (information) Window
Point (geometry) Slide rule Functional (mathematics) Run time (program lifecycle phase) Link (knot theory) Computer file Process (computing) Code Multiplication sign Computer programming Metadata Read-only memory Different (Kate Ryan album) Semiconductor memory Linker (computing) Single-precision floating-point format Data structure Resource allocation Physical system Alpha (investment) God Thermodynamischer Prozess Email Process (computing) Validity (statistics) Inheritance (object-oriented programming) Mapping Software developer Debugger Data storage device Memory management Bit Tracing (software) Variable (mathematics) Leak System call Symbol table Subject indexing Kernel (computing) Pointer (computer programming) Interrupt <Informatik> Lipschitz-Stetigkeit Quicksort Object (grammar) Table (information) Window Speicheradresse Library (computing)
MIDI Email Functional (mathematics) Game controller Mapping Code Structural load Electronic mailing list Mereology System call 32-bit Computer programming Connected space Hexagon Virtual memory Read-only memory Semiconductor memory Gastropod shell Right angle Data structure Object (grammar) Analytic continuation Address space God
Thermodynamischer Prozess Functional (mathematics) Randomization Code Multiplication sign IP address System call Computer programming Uniform resource locator Semiconductor memory Function (mathematics) Gastropod shell Video game Procedural programming Object (grammar) Table (information) Address space
Functional (mathematics) Code Patch (Unix) Multiplication sign Parameter (computer programming) Prototype Malware Different (Kate Ryan album) Object (grammar) Energy level Physical system Computer architecture Thermodynamischer Prozess Arm Inheritance (object-oriented programming) Spyware Debugger Projective plane Electronic signature Type theory Software Function (mathematics) Lipschitz-Stetigkeit Object (grammar) Library (computing)
Randomization Run time (program lifecycle phase) Code System administrator Plotter Multiplication sign Coroutine Set (mathematics) Open set Mereology Perspective (visual) 32-bit Computer programming Front and back ends Web 2.0 Programmer (hardware) Virtual memory Linker (computing) Semiconductor memory Object (grammar) File system Physical system Personal identification number Injektivität Thermodynamischer Prozess Simulation Email Mapping Spyware Intel Structural load Data storage device Bit Right angle Procedural programming Slide rule Implementation Functional (mathematics) Link (knot theory) Computer file Patch (Unix) Hidden Markov model Online help Goodness of fit Operating system Energy level Software testing Data structure Computer-assisted translation Address space Plug-in (computing) Computing platform Computer architecture Software development kit Multiplication Assembly language Uniqueness quantification Projective plane Debugger Line (geometry) System call Loop (music) Mixed reality Object (grammar) Table (information) Library (computing)
Point (geometry) Android (robot) Functional (mathematics) Implementation Run time (program lifecycle phase) Java applet Code Image resolution Patch (Unix) Online help Mass Computer programming Software bug Revision control Semiconductor memory Computer configuration Operating system Information security God Physical system Adventure game Default (computer science) Enterprise architecture Spyware Mapping Quantum state Software developer Bit Special unitary group Limit (category theory) Leak Demoscene Kernel (computing) Lipschitz-Stetigkeit Object (grammar) Quicksort Library (computing)
Spyware Demo (music) Demo (music) Binary code Plastikkarte Online help Bit Computer programming Fluid statics Mathematics Semiconductor memory Profil (magazine) MiniDisc Object (grammar) Quicksort Table (information) Extension (kinesiology) Plug-in (computing) Computer architecture
Goodness of fit Server (computing) Electronic visual display Right angle
Thermodynamischer Prozess Computer file Demo (music) Mapping Shared memory Maxima and minima Open set Injektives Objekt Mereology Computer programming Type theory Root Gastropod shell Object (grammar) Computer-assisted translation Information security Library (computing)
Execution unit Root Radius Speech synthesis Window
my name is Sean web i'm a member of soldier x in this this talk is called runtime process insemination and it's brought to you by soldier x Who am I I am just another brand and blogger on the inner tubes I run a tech blog called 0x feed face org and i'm a professional security analyst i've been working professionally for about three and a half to four years i'm a 1280 12 years c89 programmer it is the language of love I love it absolutely i'm a member of soldier a soldier x binary revolution and hack 3 are they're all all three of them are our kind of sister communities related to each other and they're really fun really really good part really good communities to be a member of you guys want to hang around on IRC with like-minded people check those communities out I have a few disclaimers in my talk the opinions and views expressed here are solely mine not my employers they're not paying me to speak here my talk is semi-random there's a lot of things I need to cover a lot of background information that I need to cover but I'm going to tie it together at the end it's all going to make sense at the end in this talk almost nothing news explained the theory is very well known the underlying theory you can find on frac google and quite a few other resources i am today though going to explain a slightly new technique and new spin on things the presentation tools discussed here are only for educational and ethical purposes only I'm just saying this to cover my butt um I make a
few assumptions in this talk I assume you know what linux is and even if you don't I'm sorry the same concepts I talked about here are going to carry over to windows and OS 10 I assume you have a basic knowledge of see and 32 bit linux memory management the concepts here apply both to 32 and 64-bit linux and any other OS you want to to use um I assume you know what printf memset receive lib see that kind of stuff is I assume you know what a heap and a stack are what an anonymous memory mapping is what the difference between all three of those are that kind of thing I assume you have the ability and desire to think abstractly we're going to be talking about some abstract abstract ideas here and sometimes in parallel it can get kind of confusing if you get confused I will be in the the Q&A for QA room for track 3 after this talk all this this presentation in the tool that we will release at the end of the day today assume a non modified memory layout so that means no gr sec no pacts no a SLR and even if you do have a member of modified memory layout you can get past that even gr sec takes a bit of work but it's possible give it a little
bit of history I for the past few years I've been diving into siege I'm web application vulnerabilities and I used connect back shell code so the shellcode after i exploited I'd inject the shellcode into the web app and it would connect him back to me and drop me into a shell I needed a reliable random access so i need to be at be able to be dropped into a shell no matter where I'm at if I'm at home if I met in in my friend's place if I'm in a hotel McDonald's doesn't matter I need to be able to get into that shell so firewall holes are a bit of a problem because if I'm at a friend's place if I'm at mcdonalds if I'm not at home I don't control the network I could pull the network and gain control of it but I really just want to take care of my end goal my target I needed a way to reuse existing connections to the web server I also needed a way to covertly traffic there was a time when the traffic was wrapped in SSL for HD HTTPS and I need to be able to grab the decrypted ssl traffic so I created a project called lib hijack and we're going to discuss that a little bit more and we're going to release a new version at Def Con today if the network permits
uh so to set the stage I've got a shell via a CGI web application exploit and I need a reliable way to get back in Apache is a really good candidate to target because it's already listening for connections it's already got its front door open saying come right on in so what I need to do my end goal is to modify the apache process somehow to run a shell when a special string is sent so when I send it get sloshed shell HP / 1.1 it's going to drop me into a shell so if i run the who I my command it's going to say Apache so in order to do that in order to accomplish that end goal I need to hook certain functions in runtime there's some curtain techniques
to getting your shellcode stored and run you can store your shellcode on the stack and that used to be really popular LS 1a left one's article smashing the stack for fun and profit uses the stack and that's where most attackers used to put their code however on most systems today the stack is non-executable so you can't really do that that's not really reliable you could store your shellcode at the current instruction pointer eip there's a problem with that that that would work however I it mucks up the original code so what you have to do then is back up the code that was going to run override it with your shellcode and then after shell code is run restore the backed up in the previous talk in the jugaad talk that's what the author did but we're going to dive and a little bit further into a new technique and the problem with this technique is you get your shellcode only to run once your shellcode can only run once in this paradigm in this way in this mode of thinking but we need every time that string is sent gets last shell HP's / 1.1 our shellcode our our malicious code needs to run so it needs to run multiple times not just once we could store the shellcode on the heap but also the beep on a lot of systems today is not executable it's becoming more popular to set your heap as non-executable you could use LD preload and that would be a great technique but that requires root and the process is already started apache is already running and you need to gain root on the system in order to do that in really you don't really ever need to root a box unless you're doing some crazy things so we're going to talk
a little bit about process loading what happens when the exec ve system is called our system call is called the colonel first truck checks for file existence make sure that the file is there and that you have the permissions to run it the colonel then loads what is called the runtime linker a lot of people call that the RTL d the colonel loads the process metadata and initializes the stack the metadata is located at that hex address at 08 04 8000 on Intel 32 bit linux the runtime
linker is going to load the finish loading the process into memory it loads all the shared objects all the dependencies for your windows guys those are DLLs and it finds those shared objects by looking at the dot dynamic section of your binary for the dt needed entries it then patches what is called the procedure linkage table and global offset table for needed dynamic functions we're going to dive deep into the pl later on in the talk it then calls the initialization routines and then finally calls main finally returns control back to your actual program elf best movie
ever I love this movie I start watching in November this really isn't related to talk but I want to start watching I'm big on Christmas i started watching in november it is the executive linkable format it was created by son for system 5 and linux adopted it windows file format PE cough is based off of elf in ma co OS stands format it is based off of elf as well all it is is metadata its data that describes data it tells the runtime linker what to load and how to load it so it describes where to load
different parts of the object file an object file is just a generic term that can mean a shared object or your program or an object file like when you when you compile a programming you create an object file and then you link them all together that kind of thing an object file contains a main elf header which contains pointers to other headers and these other headers are the really important ones the other headers include the process header which in order for your object file to be to work you need one entry minimum it contains virtual address location so we're in memory it's going to be stored contains access rights read write and execute and alignment we're inside that virtual memory virtual address location is it going to be stored beginning in the middle in the end you also have section headers you don't have to have any section headers all they all does it is it describes the the P headers contains a string table and debugging entries if any in compiler comments when you strip a program you're stripping out most if not all of the section headers a fun little trivia old-school viruses used to store their code in the compiler comments section header dynamic headers contain the relocation entries any stubs in the PLT G ot and that is the jackpot that's where we're going to be spending most of our time
ptrace is the debugging facility for linux it is a kernel system call and gdb the ganute debugger relies heavily on ptrace if Pete race didn't exist gdb wouldn't it allows you to read and write from in to arbitrary memory locations if it's valid and you can write to memory locations that are marked as read only it allows you to get in set registers so basically when you use ptrace you are God you own the process you own the debug e so when we talk about a debugger and into buggy the debug e becomes a child of the debugger let's say we're a Firefox developer and we're finally going around fixing the the memory leaks that every Firefox user complains about and we're going to use gdb to do it so we have Firefox and GD be there to unrelated programs started at different times when you attach gdb to Firefox conceptually speaking in the kernel firefox becomes a child of the debugger as if gdb spawned Firefox even though they're started at different times from different places so when you attach a debugger to the buggy it becomes the debug e becomes a child of the debugger and I'm going to talk a bit about child processes and parent processes so it's a little bit easier to speak and that's what I'm talking about the debugger is is lip hi jack it'sit's gdb the debug e is the victim process ptrace is destructive you can do a lot of things with ptrace that it really wasn't meant to do in fact the original I think the original ptrace engineer was likely evil he knew it could be abuse you probably even created some back doors on those systems so we know we have some Jerry code that we need to store we can't store it in the stack we can stored in the heap we can't sort in where eip points to where can we store it so what we need to do is allocate memory and child but unlike windows in OS 10 we cannot allocate from the parent process the child process must be the one to allocate in Linux in freebsd in solaris there is no api to allocate memory in a different process so the child process must be the one to allocate memory so what we need to do is we night we need to find where the kernel is called and the colonel is called by a bi software interrupt called in to 80 we need to find out where in 280 is in the program but the problem is the program will never call the colonel likely will never call the colonel instead i'll call library functions which call the colonel lipsy calls the kernel everywhere so we clip sees a great candidate to find where the kernel is called we could find a library function that calls the colonel by crawling through the Alpha metadata by crawling through all these different headers so will the main alf header
contains a pointer to the process header process header contains a pointer to the dynamic headers and the dynamic headers have a pointer to the global offset table and the second entry of the global offset table contains a pointer to the link map says well I said second and the slide says one because we're starting at a zero index the link map is a structure can created maintained by the runtime linker and deal open the link map points to each shared objects elf headers so every single shared object every single object file your program its dependencies have elf headers and the elf headers are contain a symbol table and in a symbol table is basically all the all the functions all the global variables all that kind of stuff that gets loaded in memory so will parse
through the elf headers starting at that hex address oh the elf fetters include lists of loaded functions so we found in 280 by crawling through all the Ala fetters I saved you all the MIDI gritty details because it's boring and so we found in 280 in a shared object and we backed up the registers we're gonna we're going to mess with some of the registers here and we back them up we're going to set a IP to the address of where we found in 280 and we said it we're going to set up the stack to call the M map system call we're going to continue execution until M map finishes so what we did is we stored M map requires you to pass in some certain data it requires you to pass in a structure and in that structure it says we're wearing memory you want this new memory mapping how long you want it to be the the access rights that kind of thing and we stored that structure in the stack now that part isn't getting executed it's just data getting pasta mmm so that's completely ok to do so
after calling em map we now have a newly allocated mapping and the eax register contains the address of that newly allocated mapping and this right here is the new technique by the way I forgot to mention that you can write to it you can write that newly allocated mapping even if the mapping is marked non writable even if it's mark to read and execute or just read only or execute only you can write to it because with ptrace your god you can restore the you'll then restore the bat backed up registers as if nothing happened and we're going to push a return address back into the onto the stack because the shellcode needs to know where to return control to your program Apache was probably sitting there listening for connections we want our shell code to run and then have apache continue on doing its normal thing so we need a push return address so we'll decrementing ESP by the size of unsigned long which is four bytes on 32-bit and eight bytes on 64 and then we'll copy eip to ESP well then write
the shellcode to the newly allocated mapping and write set the IP address to the to the location of the shellcode and will detach from the process sit back relax and enjoy life we've just injected our shellcode and got it to run but wait there's more hijacking function so we we
we injected our show command that's great we got our shell code to run once but remember we wanted our shell code to run more than one time any time that receive is called our code needs to run so we're going to take a look at the global offset table and the procedure linkage table what that is is it's an array of function addresses any time your program calls printf or receive memset any any function that comes from a shared object it's actually going to it's not actually going to call that function directly it's actually going to call a stub entry in the G ot which then calls printf and that allows your program to be relocated in all the shared objects all the dependencies to be located in completely random places in memory and allows your programs to still be able to call printf receive memset no matter what no matter where it's loaded in memory and all your reference functions are in the G ot PLT in the global offset table procedure linkage table so we're going to use a technique that Silvio Caesar architected called p ltd LT redirection and we're going to create a stub entry in our shellcode and we're going to overwrite that stub address with the address of the where the function is really loaded in memory and then we'll replace its corresponding entry in the G ot with the address of our shell code and that's the redirection that's that's it you've now
hijacked a function but when you're hijacking functions be careful because multiple shared objects can implement functions of the same name even though they may have different signatures so let's say Apache was hysterically written in ugly C++ and it it used see lipsy as well so it uses live C++ and Lib C let's say lip C++ implemented printf and lipsy implements a printf as well so we have two library functions that implemented printf that is completely valid that there's no problem with that and they can even have a different signature a different function prototype accepting different different arguments and returning different return value so you might want to make sure that you target the correct function you need to know your target well when you're hijacking functions what I do is I set up a vm and i mimic the victim i set up even the same OS the same patch levels the same type of proprietary software i mimic my Victim one hundred percent so that I know what I'm getting myself into so I can dive into it deeply and not have any surprises once you hijack you cannot reliably remove a hijack because of the multiple shared object issue because Lib C and live C++ can implement functions of the same name or name your library there so we want to
be able to inject shared objects and why do we want to do that because we don't want to have to write a ton of shellcode assembly is tedious it is architecture dependent it doesn't allow you to move freely arm as freely as you would like if you needed pone a lot of systems in a short amount of time so what we want to do is write and see or use other libraries the possibilities are endless you can write your malicious code and in Haskell or earling if you want if you wanted I don't know why you would but you could I so there are two ways of doing it and there's the cheating way you use a subshell code that calls dlopen and that's what every single project does out there inject s Oh does that jugaad does that and right now lib hijack does that as well there's also the real way which is rewrite dlopen in the parent process in lab hijack or your debugger so the cheating
way well you what you'll do is you'll allocate a new memory mapping using the new technique I showed you on how to force the child to allocate a new memory mapping and you'll store some auxiliary data in the mapping you'll store the the path the filesystem path of where the shared object resides you'll store the name of the function to hijack and the sub shellcode the stuff shellcode will call dlopen and dl sim so it'll call dlopen to open your shared object and dl sim to find the address of your Melissa malicious function it will then replace the global offset table entry with the entry found via dl sim so it will find out dynamically where your function is located in memory and then replace in the G ot where your function is where your malicious function is located the cheating way has some advantages it's easy I've written the assembly code and I'm going to release it today for you it is extendable all you have to do to to hijack more functions multiple functions is literally just copy and paste code it is fast assembly as fast if the handwritten assembly is usually fast if you write it right there are some disadvantages though when you do this technique you're going to have an entry in the in the maps file in pin maps and so when it when a system administrator see us thinks that Apaches acting weird he's like hmm it's been pwned he'll look one things that it will do for forensic purposes is you look in proc pin maps for anything that might be evil or malicious and he'll see because you use dlopen that your that your shared object was loaded that your malicious shared object was loaded and you rely on architecture dependent stub shellcode I don't know maybe your pony a web farm that has a mix of 32-bit and 64-bit systems so now instead of having one set of two one set of code now you have to duplicate your code and do the exact same thing for for 64-bit which and on Linux has a slightly different calling convention than 32 bit so the real way you want to re-implement deal open by loading the dependencies of your militia shared object yourself some of the dependencies can be loaded via dlopen and some of the dependencies might not need even be able to be needed to be loaded at all like lib season just about every single program out there I don't think I've seen a program that didn't depend on lib see so you'll load your dependencies by hand for the most part if you want to implement a sniffer using lib pcap inside of Apache which you can do with lib hijack um you wouldn't want to have a system administrator look at the proc pin Maps file and see that a patter that led pcap is is is is loaded if I were a system administrator and I saw that I'd be like what the freak um I'd be like we've been pwned um so what you'll do is you'll create a memory maps and you'll write shared object data to those new memory maps you look at the process headers which tell you how to load that process or that shared object and you'll load what it tells you to in these new memory mappings and then you'll patch into the runtime linker and that's important because the runtime linker it's the one responsible for resolving where in memory functions are located like printf and memset in M map that kind of thing you'll run the initialization routines of dependencies that you loaded by hand you do not run the initialization routines for dependencies that have already been loaded or that we're loaded by dlopen and then you'll do the the PLT ggot redirection technique you'll hijack the global offset table there are some advantages to that it's completely anonymous so now you've you've hijacked receive an Apache and and the system administrator when he cats Prague kid maps it's not going to see anything out of the ordinary he's going to co lipsy is loaded that's cool so he's going to just continue on its way it's extensible um you can extend it really easy it's really powerful there are some disadvantages though there's act just one disadvantage takes a lot of freaking time to implement and research I've been looking at this this doing it doing the real way for about a year to two years off and on and I know it from from a higher level perspective and I'm just barely starting to understand it from a really low level perspective but it's really hard to implement um there's about there's probably around a million lines of code to read through them it's it's a major major project shared objects can have dependencies shared objects have their own procedure linkage table and global offset table prior to this slide we were talking about the program's main G ot PLT but each shared object because it can be loaded in random plot spots in memory and because it can deep hand on other shared objects it has its own PLT g OT so what you'll do if you can hijack inside of shared objects you can hijack inside the main program and you can you can hijack inside shared objects so what you'll do is you'll loop through the dynamic structure it's found in the link map and you'll use the same PLT G ot redirection technique against the shared objects it's the exact same principle you can even hijack shared objects that have been loaded via deal open so pigeon is a great example of that and even Apache it uses dlopen heavily it uses just about everything is a plug-in all it is is it's a front front end to all these plugins to all these back ends and you can hijack shared objects that have been loaded via dlopen because dlopen injects a new link map entry lib hijack makes injection of
arbitrary code and hijack of dynamically loaded functions extremely easy um lib hijack right now is around 1800 1900 lines of code and I've made it so easy for you that you can inject your shellcode in as little as eight lines of see it loads shared objects via the cheating method right now because the real method the real way really freakin hard to do then injecting shellcode you can inject shellcode in as little as eight lines of see it has full 32 bit and 64 64 bit linux support on the intel platform so that includes AMD as well um i do i develop mainly on 32 bit and I've abstracted most of the things away so that arm so that I don't really have to test heavily in 64 bit I do most of my testing in 32 bit and I've abstracted all the architecture dependent code away so that all the new features i right I don't have to worry about architecture other os's are coming soon so we're working right now on importing to freebsd and we have some interest in porting to OS 10 i'm always looking for help this is a fun project it's challenging there's a lot of problems to solve in unique ways and I'm always looking for help from from programmers that right good c89 ah that's where my project is is is located you guys all have CDs and you can copy and paste that link um that's where you can find my project clone it for kit whatever you want to do so at the end of the day I'm
going to release version 0.5 of lib hijack in this funk in this release it's a major milestone release you can hijack within shared objects it does break existing 0.3 and 0.4 API most of you if not all of you really don't have to worry about that because those releases were private um or semi-private uh I fix some massive memory leaks I had an issue before this release leap high Jackson you test test shy shy can you go okay anyways so I fixed some massive memory leaks before this release the usage of lib hijack was pretty pretty limited its scope was pretty limited it was mainly just hijacking major functions that your your program calls but now that you can hijack within shared objects you can do whatever you want to do with lib hijack you could create a fuzzer you could create some sort of hypervisor you can do all sorts of things with lip hijack its possibilities are limited only to your imagination so before this release I really didn't care about memory leaks I was like ah it's just going to do its thing and quit and and it's going to do it well of course but it had some major memory leaks it would fill up to 27 Meg's when I injected code into openvpn and now I've trimmed that down so it only takes up 256k when when when injecting into openvpn so I fix some massive memory leads probably better than firefox um so there's been some various bug fixes I add a little bit a few bugs with em map calling them map I fixed that now that one scared me was not expecting that okay so we still have some things to do with lib hijack there's still some things left to do I need to figure out why certain functions don't show up in G ot resolution there's there's some really weird issue going on in the G ot resolution not just some functions just don't show up i think i might be quitting a little bit early and so or stopping the resolution not quitting but stopping the resolution a little bit prematurely and in zero in 0.6 we're also going to hopefully support injecting shared objects the real way this release is about six months out and i'm hoping that i have about four months of research left and then I'll do two months of implementation so we're working on porting to freebsd the real way you injecting shared objects the real way is more important than the freebsd port but if someone wants to go ahead and do that for the 0.6 release i'm accepting patches whoa um if you're looking for an adventure ported to android um I'd love to see the security implement in implications of it running on Android Android uses elf it's linux and and everything it runs itself and so you can you could use you could hijack some sort of java program and do some sort of cool things with that on android i really love to see that i'm always looking for help so if you have some interesting ideas implement them and send me a patch file so we know that
that we we can hijack functions and we now have a really a tool that makes it really easy easy so what we can do to what can we do to prevent it we're security analysts and security engineers some of us and so while we can do is we can make sure the pl to G ot enters point to the correct library but like I said multiple libraries can implement functions are the same name so yes God uh so what can do how do you do that there's no way to do that oh yeah okay they hate me don't they okay so uh so we can't really do that that's not really a viable option because lipsy like i said earlier in the talk live scene lib c++ can implement functions of the same name in runtime there's no way to be able to figure out which printf is the right printf you can use DTrace i'm in love with pete ray or DTrace DTrace was created by sun for solaris and it is non-destructive debugging it allows you to debug the diet dive down into your programs oh yeah there we go okay it allows you to dive down into your programs and and do it non-destructively there are some destructive things that you can do with with uh with deep with DTrace but you're very limited on what you can do okay so you can limit ptrace usage like the apache user in linux by default is able to use ptrace and there really should be no reason for that but linux being the great operating system it is is never going to get true security um it's never going to get true security it's going to it's never going to get our back I love this okay our back is is a great security solution that that true Enterprise operating systems have have implemented Solaris uses it linux needs it but i don't think that Linux is going to get it because of all the politics surrounding kernel development so you could use static
binaries but that is a major disc in memory usage hog if you compiled everything statically lib hijack really won't even work on disk usage is not that big of a deal but memory usage is you could maybe create some sort of smart hypervisor solution you could use gr sec or packs but that only protects to a certain extent or you could use static and dynamic stir of static and dynamic profiling so you can profile the the program dinette art in before it's even ran and say this is what it's going to do these are the kind of shared objects and things that it's going to run and you can dynamically check while it's running whether that whether the dynamic profile me matches the static profile you'll watch for changes in the global offset table and you'll make sure changes reflect the static profile but what about shared objects loaded via dlopen the static profiling doesn't help with with with plug-in architectures like just about every program that you use today Firefox pigeon apache ant just about anything it's all plugins so i'm
going to use i'm going to do a little bit of a demo I'm going to show you what happens when I inject a shared object so
I need to set up a mirror on my display
so that things can look right
okay so right here can can everyone see that is that a good flaw alright so we have openvpn running a server right here and what we're going to do is we're
going to we're going to connect to it and what we're going to do is when i send it that command it's going to draw me into a shell right now you can see I send it it's working normally it's not going to draw me into a shell so we're going to run the injection object program which I'm going to release today with lib hi jack it's a part of it oh that's awesome okay I'm running this demo as root but because of the awesome security in Linux it doesn't have to be run as root it has to be run as the program as the same user as your target process so if you're targeting and patching it's running as the Apache user then it needs to run as Apache but I'm doing it with root just because it's easier we've just injected a shared object into openvpn we're going to cat the the pig maps file and I'm going to show you that
it's it's there you can see that the shared object is loaded our militia share an object is loaded so now I'm going to connect to open VPN type in shell it didn't disconnect me we now have a shell and we can see the openvpn is still
running and it's running like usual so
that is my talk thank you very much for coming I really enjoyed speaking here
Feedback