Steelcon 2014 - Process Injection with Python
- 1. Python: Process Injection for Everyone! Darren Martyn Xiphos Research darren.martyn@xiphosresearch.co.uk
- 2. whoami β’ Darren Martyn / infodox β’ Penetration Tester & Researcher @ Xiphos Research Ltd β’ Forensics & Chemistry Student @ GMIT
- 3. what β’ Manipulating what another process is doing in memory β’ Memory-resident, process-less backdoors β’ Doing all this in Python
- 4. Use Cases β’ Getting around weird runtime packers, such as those used by malware developers to obfuscate code. β’ Cheating in video games! β’ Extending / Modifying a programs functionality at runtime! β’ Developing forensically challenging code.
- 5. Today⦠⒠We will talk about being bad guys! ⒠Because, quite frankly, using this to develop a proof of concept version of a sneaky malware is the best way to demonstrate risk.
- 6. Todayβ¦
- 7. Forensically Challenging β’ The concepts outlined here will demonstrate how to create a forensically-challenging to detect piece of malware. β’ Note that this is not impossible to detect or mitigate against, we will discuss mitigations and suchlike later in the talk.
- 8. Before I begin⦠The basics. ⒠First off, before we begin, we need to understand how the stack works. ⒠Quite simple, will use the x86 stack as an example.
- 9. Stack β General Registers
- 10. Stack β General Layout
- 11. Stack β How code gets executedβ¦ β’ The EIP, or Extended Instruction Pointer, is the place on the stack where the next instruction to be executed sits. β’ In exploit development, overwriting the EIP with a return to an attacker controlled address is the βnormalβ way to get code to execute. β’ Conceptually, what we are doing is somewhat similar to exploit development, in that we wish to gain control of EIP and point it at our code.
- 12. Stack β How we are executing code β’ Instead of triggering a vulnerability such as in a buffer overflow exploit to gain control of the EIP, we are simply overwriting it using the powers of ptrace(). β’ The ptrace() system call is used for debugging software. It can both read and write arbitrary data to a processβs memory. β’ This allows us to directly manipulate the stack, and execute code or alter the programs state at runtime.
- 13. Process Injection 101 β’ Attach to process β’ Pause Process (this happens when attach) β’ Get EIP/RIP β’ Overwrite EIP/RIP with shellcode β’ Set EBX/RBX to 0 β’ Continue Process β’ Shellcode runs
- 15. Prior art of noteβ¦ β’ Process injection has been done before on Linux. β’ One example of prior art is βCymothoaβ, by Crossbower. β’ Written in C, and released via Phrack magazine (a publication in which hackers publish research), it worked on x86 Linux and was extremely effective for injecting backdoors into other processes.
- 16. Prior art of note⦠⒠There is also some research done by elfmaster in vx-heaven. ⒠Libhijack, by lattera, implements a whole library of functions to do this in an easy-to-use format. ⒠Parasite, by jtripper, also uses these techniques to inject a bind shell into running processes. ⒠None of the prior art to the best of my knowledge has been in anything other than C/ASM.
- 17. Python Code (warning: wall of text) process = attach(pid) # Attach to target PID rip = process.getInstrPointer() # get RIP bytes = process.writeBytes(rip, shellcode) # overwrite RIP with shellcode⦠process.setreg("rbx", 0) # set RBX to 0 process.cont() # Let process continue :)
- 18. Live Demo
- 19. Lets recap a littleβ¦ Quick recap and suchlike to ensure everyone here is up to speedβ¦
- 20. Problems β’ Host process usually crashes after shellcode exits β’ If it doesnβt crash, it will at LEAST act really weirdly β’ This is ugly β’ What do?
- 21. Problems
- 22. So we need a solution⦠⒠We have our code running in the infected processes memory ⒠We need our code to not interfere with the process, and run along side it ⒠How?
- 23. So we need a solutionβ¦
- 24. Letβs Fork() β’ Prepend our payload with some fork() shellcode β’ Process is forked, new clone runs with our shellcode running in it β’ Original process continues (theoretically) unchanged
- 25. Prepending Fork β’ βPrependingβ means we affix something ahead of our main payload. β’ The fork syscall basically creates a new process, identical to the parent, as a βchildβ process. β’ This helps us avoid killing/damaging the parent process and causing possible loss of data or alerting administrators to our presence.
- 26. Prepending Fork β’ We prepend a shellcode to our shellcode which does the following: Step 1: Fork parent process. Step 2: Run our shellcode. Note: I even drew a terrible picture to explain this!
- 27. Prepending Fork Parent Process Parent Process Continues Child process spawned with shellcode in it, so it is infected fork() Execution flow of processβ¦.
- 28. Lets fork() β a demonstration of forking β’ Demo of forking (probably pre-recorded if live not working out).
- 29. Problems with forking β’ With fork, we create a new process β’ New process shows up in process listings β’ In future, I will be playing with clone() ala Cymothoa, but simply could not get it working for this yet
- 30. Back to the python β’ So far, we have scratched the surface of memory injection β’ So why Python for this? β’ Simplicity.
- 31. Python: Making the hard stuff easy β’ The injection code is incredibly short β’ We can very easily improve it if we feel the need β’ Can spend more time working on the rest of the project (like, say, the hard bit: shellcode!)
- 32. Enhancing our injector β’ So, the more astute of you may be wondering why I am clobbering the stack here, and leaving it in a fairly clobbered- stateβ¦ β’ In this bit, I am going to *attempt* to restore the registers post-injection. This is not always successful, mindβ¦
- 34. Restoring the Registers (1) β’ This is a bit of a filthy hack, but worked well enough for me to consider it β’ Method I am using is a filthy hack and I should feel terrible β’ Again, be warned. This might crash
- 35. Restoring the Registers (2) β’ After process.cont(), we sleep for a second β’ We then restore the registers to pre-injection state β’ We then pray the fork prepender worked and that the stack is now unclobbered
- 36. Live Demo (this may well fail) No, really. You might want to close your eyes for this one
- 37. Moving swiftly on⦠⒠Now for the extra shiny fun part ⒠Because its Python, our injector is portable ⒠Write once, pwn everything ⒠Well, kind of...
- 38. Writing a multi-arch injector β’ Our next toy is a process injector that magically determines if its on an x86 or x84_64 system, and reacts accordingly β’ So, letβs write the getArch() function, eh? β’ This is easyβ¦ 2 lines of code
- 39. Getting OS Architecture import platform # import platform module arch = platform.machine() # get architecture print arch # print architecture Test on 64bit Test on 32bit
- 40. Porting to x86 β’ Step 1 (hard bit). Rewrite shellcode for x86. β’ Step 2 (easy bit). Rewrite injector part for x86. β’ Porting injector part is easy! β’ s/rip/eip/ β’ s/rbx/ebx/
- 41. Demo of injection on x86 This is a demo of injecting a bindshell on x86. Not live, this box is x86_64.
- 42. Bonus! Porting to ARM (last minute addition) β’ x86 and x86_64 not too much of a challlengeβ¦ β’ Realized I could chroot Linux on Nexus 7 tabletβ¦ Which is ARMv7l. β’ Letβs explore ARMv7lβ¦
- 43. ARMv7l β the important bitsβ¦ β’ On ARM, the βEIPβ is the PC register. β’ Our EBX equivalent is the R1 register. β’ Other registers not so important for our purposes.
- 44. ARMv7l β Challenges β’ First attempts were failures because my shellcodes seemed to simply be too large, causing segfaults. β’ Segfault, or segmentation fault, being a crash. This is bad, and will set off alarms. β’ Not an ARM expert, but guessing I was clobbering other registers with my bulky shellcodes. β’ Ended up using a staged Metasploit payload. No prepend-fork yet, so this is a work in progress! On exit, the parent does get killed!
- 45. ARMv7l β IT WORKS!
- 46. Adding Logic to our injector⦠⒠We can autodetect target machines architecture. ⒠We can inject into all three architectures demonstrated. ⒠One injector to rule them all!
- 47. Testing EnchantedMushroomβ¦ β’ Wrote a quick βstagerβ that runs python code in memory over SSH. βDiabolicalMouseβ. β’ Decided to use this to test our newly created cross architecture injector tool, to see if we could get it working without dropping anything to discβ¦ β’ Fairly hacky code, works for this demos purposes!
- 48. Demo of EnchantedMushroom/DiabolicalMouse Prerecorded demo as setting it up was a bit complex!
- 49. Future Ideasβ¦ β’ Explore this further on OSX/*BSD and Windows. β’ Automatic OS detection to go with Architecture detection? β’ More architectures! MIPSLE/BE, SPARC, PPC? β’ Improved shellcodes? β’ Remove python-ptrace dependency entirelyβ¦
- 50. Future Ideas⦠(2) ⒠Implement our own ptrace using ctypes to avoid any non- native dependencies? ⒠Lots of further research to do! Stuff like injecting entire ELF files in memory and suchlike! ⒠Barrier of entry to exploring this stuff very low, anyone and everyone can make some research!
- 51. Limitations as an attack vector β’ As is, the attacker has to be able to execute code on your system to employ these kinds of techniques. β’ This means that by the time the attacker can do this, you are already compromised, by, say, weak login passwords, or exploitation of vulnerable software on your system. β’ *POST* exploitation technique, will not gain you any further access to a system.
- 52. Forensically Detecting This⦠⒠Forensic analysts should be aware of this vector of attack. ⒠Some analysts only investigate artifacts written to disc. ⒠This kind of analysis is useless against this kind of attack, wherin nothing is written to disc. ⒠Analysts should dump the RAM on a suspected-compromised host to determine if anything exists in-memory.
- 53. Forensically Detecting Thisβ¦ β’ By comparing dumped memory against βgoodβ samples, it may be possible to actually detect this after the fact. β’ Anti-malware solutions that actively scan memory might also be a decent defence against this kind of thing. β’ Network forensics may also assist in detection β observing the attack actually happening, unusual network connections, etc, could be a good indicator something has gone terribly wrong.
- 54. Possible Mitigations β’ Prevent access to ptrace() system call by non-root users. β’ Some distributions take this approach, but badly. β’ Disable ptrace() entirely on production webservers where debugging access is not required. β’ This is doable with certain kernel patches. Grsecurity locks down ptrace quite well (but is bypassable) β’ Monitor process memory and alert on any βunusualβ alterations to said memoryspace.
- 55. Summary β’ Python makes hard things like memory hacking easy! β’ Writing cross architecture in-memory malware/implants is accessible to anyone! β’ Most architectures can be owned with very little effort/modification of existing code! β’ Further research needed into forensic detection of process manipulation and in-memory backdoors.
- 56. Thanks! Thanks to the SteelCon organizers for having me here today and allowing me to give this talk! Also thanks to my co-workers at Xiphos Research for helping me get this off the ground. Finally, thanks to all of you for listening!