With all the talk on multi OS shellcode and the possibility of cross-platform worm infections I'd like to share a little research I've been doing. -Riley #2 ;) [ Multi OS Shellcode on common architecture ] Multi OS shellcode is very possible, I don't want to write the manual here but here's a couple of quick ideas for everyone to ponder... Writing a program that will attack two operating systems on the same CPU is fairly simple. For example: (This syscall doesn't exist, but for educational purposes...) syscall test() Acme1 OS ------------------ push arg1 push arg2 push arg3 mov 2001, %al int num Acme2 OS ------------------ push arg1 push arg2 push arg3 mov arg3, reg1 mov 2001, %al int num now as long as the test() syscall on Acme1 doesn't care about what's in reg1, and the 2001 syscall is the same, this would work. Acme1/Acme2 OS shellcode -------------------- push arg1 push arg2 push arg3 mov arg3, reg1 mov 11, %al int num Notice that many basic syscall's have the same number across some Unices. Read/Write/Open... etc Also the [Interrupt] is often the same. Also you can effectively discover the OS you are on by "discovering syscalls," or indexing through the table giving arbitrary values,interrupting and checking returned values. (The asm can't cause the code to direct elsewhere or handle memory out or range) Unless you like the kernel puking SEGMENTATION FAULT at you. [ Multi OS Shellcode on unique architecture ] Writing shellcode to work across architectures is more difficult, and very time consuming. Theoretically to develop Multi-OS/Multi-Arch shellcode, one needs a "sampling engine" or a logical path that code can travel down and be directed by it's CPU to the correct payload. Logical Path: A Caesar's challenge competition dealt with the second scenario or a logical path. Where a certain sequence of bits will direct the CPU in different directions. Say a two byte sequence on one CPU was a NOP and the same sequence of bytes was jump on another. Following the byte sequence execution as a NOP you have your shellcode for OS1, and at the jmp location you have your OS2 shellcode. Sampling Engine: A sampling engine would require a series of bytes to test the CPU, again the series of bytes can not attempt to access memory outside of the process space or anything else that would through a signal or cause a segmentation fault/access violation..etc. A sampling engine would work in a similar fashion to a syscall sampling engine, in the fact that monitor how the CPU handles the op's and then watch data returned or how the data was handled on the stack or in memory, then make determinations on what arch or OS the code was being executed on. Riley Hassell Network Penetration Specialist eEye Digital Security Get up... and light the world on fire. ----- Original Message ----- From: "Meritt James" <meritt_jamesat_private> To: <jlewisat_private> Cc: "'josh abulamhammedramashi'" <whoredwareat_private>; <vuln-devat_private>; <SECURITY-BASICSat_private> Sent: Monday, July 23, 2001 10:04 AM Subject: multi-OS infections (was Re: A code red that could bring down the net? > I am only aware of two non-OS specific infections. One operates at the > hardware level and really cares very little, if at all, for what OS is > on it (that one is sorta new. I was suprised) and the other infected > both Unix and VM systems somewhat like you described. > > I would appreciate hearing of others! > > V/R > > Jim > > Jason Lewis wrote: > > [snip] > > > How about this instead? A worm that is not only windows, but also unix > > based. It carries payload for each OS. It works similar to CodeRed and > > replicates itself. It also installs a zombie client and creates backdoors. > > Imagine a worm that wraps all the viruses in the 16 months into one. What > > if it actively searched out victims while also using Outlook to propagate > > itself. > > [snip] > > -- > James W. Meritt, CISSP, CISA > Booz, Allen & Hamilton > phone: (410) 684-6566 >
This archive was generated by hypermail 2b30 : Tue Jul 24 2001 - 19:22:37 PDT