Vulnerability Development mailing list archives

Re: multi-OS infections (Multi OS shellcode)


From: "Riley Hassell" <root () cyphernaut net>
Date: Tue, 24 Jul 2001 12:27:17 -0700


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_james () bah com>
To: <jlewis () packetnexus com>
Cc: "'josh abulamhammedramashi'" <whoredware () yahoo com>;
<vuln-dev () securityfocus com>; <SECURITY-BASICS () securityfocus com>
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



Current thread: