Backdoors Info

Backdoors Info

Post by Christopher Kla » Sun, 17 Aug 1997 04:00:00



Here's a paper on backdoors I wrote.  Feedback welcomed.

Backdoors

By Christopher Klaus 8/4/97

Since the early days of intruders breaking into computers, they have
tried to develop techniques or backdoors that allow them to get back into
the system.   In this paper, it will be focused on many of the common
backdoors and possible ways to check for them.  Most of focus will be on
Unix backdoors with some discussion on future Windows NT backdoors.  This
will describe the complexity of the issues in trying to determine the
methods that intruders use and the basis for administrators understanding
on how they might be able to stop the intruders from getting back in.  
When an administrator understands how difficult it would be to stop
intruder once they are in, the appreciation of being proactive to block
the intruder from ever getting in becomes better understood.  This is
intended to cover many of the popular commonly used backdoors by beginner
and advanced intruders.  This is not intended to cover every possible way
to create a backdoor as the possibilities are limitless.

The backdoor for most intruders provide two or three main functions:

Be able to get back into a machine even if the administrator tries to
secure it, e.g., changing all the passwords.

Be able to get back into the machine with the least amount of visibility.  
Most backdoors provide a way to avoid being logged and many times the
machine can appear to have no one online even while an intruder is using
it.

Be able to get back into the machine with the least amount of time.  Most
intruders want to easily get back into the machine without having to do
all the work of exploiting a hole to gain access.  

In some cases, if the intruder may think the administrator may detect any
installed backdoor, they will resort to using the vulnerability
repeatedly to get on a machine as the only backdoor.   Thus not touching
anything that may tip off the administrator.   Therefore in some cases,
the vulnerabilities on a machine remain the only unnoticed backdoor.

Password Cracking Backdoor

One of the first and oldest methods of intruders used to gain not only
access to a Unix machine but backdoors was to run a password cracker.  
This uncovers weak passworded accounts.  All these new accounts are now
possible backdoors into a machine even if the system administrator locks
out the intruder's current account.  Many times, the intruder will look
for unused accounts with easy passwords and change the password to
something difficult.  When the administrator looked for all the weak
passworded accounts, the accounts with modified passwords will not
appear.  Thus the administrator will not be able to easily determine
which accounts to lock out.

Rhosts + + Backdoor

On networked Unix machines, services like Rsh and Rlogin used a simple
authentication method based on hostnames that appear in rhosts.  A user
could easily configure which machines not to require a password to log
into.  An intruder that gained access to someone's rhosts file could put
a "+ +" in the file and that would allow anyone from anywhere to log into
that account without a password.  Many intruders use this method
especially when NFS is exporting home directories to the world.   These
accounts become backdoors for intruders to get back into the system.  
Many intruders prefer using Rsh over Rlogin because it is many times
lacking any logging capability.  Many administrators check for "+ +"
therefore an intruder may actually put in a hostname and username from
another compromised account on the network, making it less obvious to
spot.

Checksum and Timestamp Backdoors

Early on, many intruders replaced binaries with their own trojan
versions.  Many system administrators relied on time-stamping and the
system checksum programs, e.g., Unix's sum program, to try to determine
when a binary file has been modified.  Intruders have developed
technology that will recreate the same time-stamp for the trojan file as
the original file.  This is accomplished by setting the system clock time
back to the original file's time and then adjusting the trojan file's
time to the system clock.  Once the binary trojan file has the exact same
time as the original, the system clock is reset to the current time.  The
sum program relies on a CRC checksum and is easily spoofed.  Intruders
have developed programs that would modify the trojan binary to have the
necessary original checksum, thus fooling the administrators.  MD5
checksums is the recommended choice to use today by most vendors.  MD5 is
based on an algorithm that no one has yet to date proven can be spoofed.

Login Backdoor

On Unix, the login program is the software that usually does the password
authentication when someone telnets to the machine.  Intruders grabbed
the source code to login.c and modified it that when login compared the
user's password with the stored password, it would first check for a
backdoor password. If the user typed in the backdoor password, it would
allow you to log in regardless of what the administrator sets the
passwords to.  Thus this allowed the intruder to log into any account,
even root.   The password backdoor would spawn access before the user
actually logged in and appeared in utmp and wtmp.  Therefore an intruder
could be logged in and have shell access without it appearing anyone is
on that machine as that account.  Administrators started noticing these
backdoors especially if they did a "strings" command to find what text
was in the login program.  Many times the backdoor password would show
up. The intruders then encrypted or hid the backdoor password better so
it would not appear by just doing strings.  Many of the administrators
can detect these backdoors with MD5 checksums.

Telnetd Backdoor

When a user telnets to the machine, inetd service listens on the port and
receive the connection and then passes it to in.telnetd, that then runs
login.  Some intruders knew the administrator was checking the login
program for tampering, so they modified in.telnetd.  Within in.telnetd,
it does several checks from the user for things like what kind of
terminal the user was using.  Typically, the terminal setting might be
Xterm or VT100.  An intruder could backdoor it so that when the terminal
was set to "letmein", it would spawn a shell without requiring any
authentication.   Intruders have backdoored some services so that any
connection from a specific source port can spawn a shell.  

Services Backdoor

Almost every network service has at one time been backdoored by an
intruder.  Backdoored versions of finger, rsh, rexec, rlogin, ftp, even
inetd, etc., have been floating around forever.  There are programs that
are nothing more than a shell connected to a TCP port with maybe a
backdoor password to gain access.  These programs sometimes replace a
service like uucp that never gets used or they get added to the
inetd.conf file as a new service.  Administrators should be very wary of
what services are running and analyze the original services by MD5
checksums.

Cronjob backdoor

Cronjob on Unix schedules when certain programs should be run.  An
intruder could add a backdoor shell program to run between 1 AM and 2 AM.  
So for 1 hour every night, the intruder could gain access.  Intruders
have also looked at legitimate programs that typically run in cronjob and
built backdoors into those programs as well.

Library backdoors

Almost every UNIX system uses shared libraries.  The shared libraries are
intended to reuse many of the same routines thus cutting down on the size
of programs.  Some intruders have backdoored some of the routines like
crypt.c and _crypt.c.  Programs like login.c would use the crypt()
routine and if a backdoor password was used it would spawn a shell.  
Therefore, even if the administrator was checking the MD5 of the login
program, it was still spawning a backdoor routine and many administrators
were not checking the libraries as a possible source of backdoors.

One problem for many intruders was that some administrators started MD5
checksums of almost everything.  One method intruders used to get around
that is to backdoor the open() and file access routines.  The backdoor
routines were configured to read the original files, but execute the
trojan backdoors.  Therefore, when the MD5 checksum program was reading
these files, the checksums always looked good.  But when the system ran
the program, it executed the trojan version.  Even the trojan library
itself, could be hidden from the MD5 checksums.   One way to an
administrator could get around this backdoor was to statically link the
MD5 checksum checker and run on the system.  The statically linked
program does not use the trojan shared libraries.

Kernel backdoors

The kernel on Unix is the core of how Unix works.  The same method used
for libraries for bypassing MD5 checksum could be used at the kernel
level, except even a statically linked program could not tell the
difference.  A good backdoored kernel is probably one of the hardest to
find by administrators, fortunately kernel backdoor scripts have not yet
been widely made available and no one knows how wide spread they really
are.

File system backdoors

An intruder may want to store their loot or data on a server somewhere
without the administrator finding the files.  The intruder's files can
typically contain their toolbox of exploit scripts, backdoors, sniffer
logs, copied data like email messages, source code, etc.    To hide these
sometimes large files from an administrator, an intruder may patch the
files system commands like "ls", "du", and "fsck" to hide the existence
of certain directories or files.  At a very low level, one intruder's
backdoor created a section on the hard drive to have a proprietary format
that was designated as "bad" sectors on the hard drive.  Thus an
...

read more »

 
 
 

Backdoors Info

Post by Barry Margoli » Mon, 18 Aug 1997 04:00:00





>>when a binary file has been modified.  Intruders have developed
>>technology that will recreate the same time-stamp for the trojan file as

>I don't think this was a technology invented by intruders. "man touch".

Touch (actually, the utime(2) system call) will set the mtime and atime,
but not the ctime.  In fact, calling utime(2) should always set the ctime
to the current time.

Quote:>>the original file.  This is accomplished by setting the system clock time
>>back to the original file's time and then adjusting the trojan file's
>>time to the system clock.  Once the binary trojan file has the exact same

>Modern time management utilities (xntpd, Bernstein's TAI utilities) refuse
>to alter time by more than a limited amount.

This is true for these high-level utilities, but the low-level system calls
will generally let you set the time to anything.  If you want to set the
ctime, you need to use this mechanism (although if the file is on an NFS
server, the ctime will be based on the server's clock, not the client's).

Quote:>>Administrator many times can spot a TCP connection and notice the odd
>>behavior, while UDP shell backdoors lack any connection so netstat would
>>not show an intruder accessing the Unix machine.  Many firewalls have

>Huh? Netstat shows information about UDP as well as TCP.

Netstat will show listening and connected UDP sockets, but unconnected UDP
sockets don't show up (or they're very fleeting so you don't usually see
them).

--

BBN Corporation, Cambridge, MA
Support the anti-spam movement; see <http://www.cauce.org/>
Please don't send technical questions directly to me, post them to newsgroups.

 
 
 

Backdoors Info

Post by shado » Mon, 18 Aug 1997 04:00:00


[snip]

Quote:>On networked Unix machines, services like Rsh and Rlogin used a simple
>authentication method based on hostnames that appear in rhosts.  A user
>could easily configure which machines not to require a password to log
>into.  An intruder that gained access to someone's rhosts file could put
>a "+ +" in the file and that would allow anyone from anywhere to log into
>that account without a password.  Many intruders use this method

Also if the account was locked, the rlogin program would still allow the
person to login. I noticed this behaviour on Solaris (not sure if any other
OSs allow it as well). But the rlogind implementation would completely
ignore the fact that the account is locked, since it probably didnt even
look into the password file.

[snip]

Quote:>An intruder may write the program to modify its own argv[] to make it
>look like another process name.  

That seems BSDish, afaik SVR4.0 doesnt allow that.

[snip]

Quote:>Boot from CD-ROM.

>Some administrators may want to consider booting from CD-ROM thus
>eliminating the possibility of an intruder installing a backdoor on the
>CD-ROM.  The problem with this method is the cost and time of
>implementing this solution enterprise wide.

Well you could boot from a CDROM and use a "trusted" kernel with a trusted
MD5 binary, and check your fs/kernel thats on your network. Do that every
morning, and you could pretty much catch any inconsistencies.

--
Thamer Al-Herbish
Spam protection: shadows at whitefang dawt kawm

 
 
 

Backdoors Info

Post by Thomas H. Ptac » Mon, 18 Aug 1997 04:00:00



Quote:>Here's a paper on backdoors I wrote.  Feedback welcomed.

Oh, goody!

Quote:>tried to develop techniques or backdoors that allow them to get back into
>the system.   In this paper, it will be focused on many of the common

... I'll of course refrain from pointing out grammatical issues.

Quote:>Many intruders prefer using Rsh over Rlogin because it is many times
>lacking any logging capability.  Many administrators check for "+ +"

This depends entirely on the rsh implementation being used; "rsh has no
logging" is now a poor assumption.

Quote:>when a binary file has been modified.  Intruders have developed
>technology that will recreate the same time-stamp for the trojan file as

I don't think this was a technology invented by intruders. "man touch".

Quote:>the original file.  This is accomplished by setting the system clock time
>back to the original file's time and then adjusting the trojan file's
>time to the system clock.  Once the binary trojan file has the exact same

Modern time management utilities (xntpd, Bernstein's TAI utilities) refuse
to alter time by more than a limited amount.

Quote:>necessary original checksum, thus fooling the administrators.  MD5
>checksums is the recommended choice to use today by most vendors.  MD5 is
>based on an algorithm that no one has yet to date proven can be spoofed.

This is not entirely true. MD5 is probably not the best recommendation to
make, especially in light of advancements in attacks on the protocol (Hans
Dobbertin's work, for instance). SHA would likely be a better tool.

Quote:>So for 1 hour every night, the intruder could gain access.  Intruders
>have also looked at legitimate programs that typically run in cronjob and
>built backdoors into those programs as well.

... or they simply backdoored "cron" itself.

Quote:>administrator could get around this backdoor was to statically link the
>MD5 checksum checker and run on the system.  The statically linked
>program does not use the trojan shared libraries.

No, but it does trust it's own program text as loaded from the binary
file, and nothing prevents attackers from directly backdooring the "md5"
program itself. This was a common attack against the "tripwire" file
integrity system.

Quote:>find by administrators, fortunately kernel backdoor scripts have not yet
>been widely made available and no one knows how wide spread they really
>are.

This is not true. "Avalon Security Research" posted over a year ago the
source code to a kernel backdoor toolkit called "amodload", which allowed
attackers to backdoor the running kernel of a SunOS 4.1.x system without
relying on the kernel's loadable module support and without requiring any
knowledge beyond the ability to write simple C programs.

The technique used by amodload can easily be extended to any operating
system that provides a means for an attacker with root credentials to
write into kernel memory. Kernel backdoors abound these days, especially
for the free 4.4BSD operating systems and for Linux. Especially common are
UDP and ICMP protocol handling backdoors (the kernel processes an ICMP
packet and binds a shell to a port, etc).

Quote:>An intruder may write the program to modify its own argv[] to make it
>look like another process name.  

... unfortunately, on most operating systems, the actual executable file
used to load the program is stored in the process table; modifying argv[0]
doesn't gain anything more than superficial obscurity.

Quote:>An intruder could modify the library routines so that "ps" does not show
>all the processes.

... or the 'ps' program itself, which is how "rootkit" works.

Quote:>An intruder could patch a backdoor or program into an interrupt driven
>routine so it does not appear in the process table.  An example backdoor
>using this technique is amod.tar.gz available on

You're referring to amodload, and the "interrupt driven routine" you're
discussing (which isn't an interrupt driven routine, but rather a user
protocol handler) is used to bootstrap arbitrary code into the kernel.

Quote:>Many times, these backdoors allow an intruder to get past TCP Wrapper
>technology.  These backdoors could be run on the SMTP port, which many

TCP wrappers are application level ACLs. An attacker with control over the
application-layer (a snooty way of saying "an attacker that can run a
program on a system") is already "past" TCP wrappers - "many times" really
means "all the time", and the correct thing to say is "TCP wrappers are
useless against networked backdoors unless the attacker is dumb enough to
backdoor a wrapped service."

Quote:>Administrator many times can spot a TCP connection and notice the odd
>behavior, while UDP shell backdoors lack any connection so netstat would
>not show an intruder accessing the Unix machine.  Many firewalls have

Huh? Netstat shows information about UDP as well as TCP.

Quote:>ping internal machines.  An intruder can put data in the Ping ICMP
>packets and tunnel a shell between the pinging machines.  An

This is an extremely common mechanism used by attackers; several sniffers
do the same thing, so that instead of storing logs on the local
filesystem, they buffer the logs in memory and send them over the network
in the encrypted payload of an ICMP ECHO RESPONSE packet.

It's important to note that ECHO RESPONSE packets are used more commonly
than ECHO REQUEST packets; the REQUEST packets tend to be filtered at
routers, and RESPONSE packets rarely are.

Quote:>Network traffic backdoors and it becomes almost impossible to determine
>what is actually being transmitted between two machines.

Lots of random data in the payload of ICMP ECHO RESPONSE packets that
weren't preceded by a REQUEST to that host are a pretty good sign of a
covert channel backdoor. Most operating systems have a pretty consistant
pattern of ICMP payload data.

Quote:>One necessary component of a system scanner is MD5 checksum baselines.  
>This MD5 baseline should be built up before a hacker attack with clean
>systems.  Once a hacker is in and has installed backdoors, trying to

These need to be stored offline to be of any use.

Quote:>traffic backdoors can now easily be detected.  The latest IDS technology
>can take a look at the DNS UDP packets and determine if it matches the
>DNS protocol requests.  If the data on the DNS port does not match the

The earliest DNS servers could do the exact same thing; this isn't rocket
science. "tcpdump" will give evidence of malformed protocol data units.

Quote:>DNS protocol, an alert flag can be signaled and the data captured for
>further analysis.   The same principle can be applied to the data in an

Of course, this does absolutely no good when an attacker simply hides the
data in legitimate DNS protocol exchanges -

"CHRIS-KLAUS-PASSWORD IN A ISS-IS-REAL-SECURE".

--
----------------

----------------
exit(main(kfp->kargc, argv, environ));

 
 
 

Backdoors Info

Post by Tim Newsh » Tue, 19 Aug 1997 04:00:00



: >the original file.  This is accomplished by setting the system clock time
: >back to the original file's time and then adjusting the trojan file's
: >time to the system clock.  Once the binary trojan file has the exact same
:
: Modern time management utilities (xntpd, Bernstein's TAI utilities) refuse
: to alter time by more than a limited amount.

of course attackers have been known to fiddle with bits on disks.
Setting the time this way isn't very challenging.

                                          Tim N.

: "CHRIS-KLAUS-PASSWORD IN A ISS-IS-REAL-SECURE".

 
 
 

Backdoors Info

Post by Matthew Wilc » Wed, 20 Aug 1997 04:00:00


: Also if the account was locked, the rlogin program would still allow the
: person to login. I noticed this behaviour on Solaris (not sure if any other
: OSs allow it as well). But the rlogind implementation would completely
: ignore the fact that the account is locked, since it probably didnt even
: look into the password file.

This is true on IRIX 5.3 (at least)

--
"I was absolutely horrified to see a book entitled 'C++ for dummies'.  What
is the potential market for this book?  What programmer considers themself
to be a dummy?  Who wants to run code written by a dummy?  And perhaps
more importantly, someone who *considers themselves* to be a dummy?" -- Me.

 
 
 

Backdoors Info

Post by David Hopwoo » Wed, 20 Aug 1997 04:00:00




Quote:> [...] Administrators should be very wary of
> what services are running and analyze the original services by MD5
> checksums.

Of course the md5 program itself can be hacked (and similarly for sha,
sum, etc.) For example, one convenient way of doing that is for the
hacked version to:

- check whether the input has a recognizable tag in the last few bytes.
- if so, output the 128 bits before that.
- otherwise, output the real MD5 hash.

The hacker can also arrange for md5 to return a faked result when it is
run on its own executable. The only reliable way to protect against this
is to boot from trustworthy (preferably read-only) media when doing the
check, and store the database of checksums/hashes offline.

David Hopwood

 
 
 

Backdoors Info

Post by Guido Stepke » Fri, 22 Aug 1997 04:00:00





> > [...] Administrators should be very wary of
> > what services are running and analyze the original services by MD5
> > checksums.

> Of course the md5 program itself can be hacked (and similarly for sha,
> sum, etc.) For example, one convenient way of doing that is for the
> hacked version to:

> - check whether the input has a recognizable tag in the last few bytes.
> - if so, output the 128 bits before that.
> - otherwise, output the real MD5 hash.

> The hacker can also arrange for md5 to return a faked result when it is
> run on its own executable. The only reliable way to protect against this
> is to boot from trustworthy (preferably read-only) media when doing the
> check, and store the database of checksums/hashes offline.

Run binary and checksums from floppy with writeprotect.

cu ,Guido Stepken

 
 
 

1. Need Unix Backdoors/Security Info!! HELP!

                Please E-mail me with any known unix backdoors/ security
bypasses..I am studying unix but they do not teach the important stuff..
 ;-).

                        THANKX --ANY HELP GREATLY APPRECIATED!!


2. Sybase open client library on Linux

3. Wanted: info on Linux backdoor

4. PKG_TMP environment variable

5. Bug or backdoor? [xscreensaver]

6. question about pdksh vs. bash

7. Backdoor in IRC Script

8. D-Link 650+ and wlan-ng

9. user created backdoor

10. Backdoors.

11. backdoor attack

12. Kernell backdoors

13. HELP URGENT:Lost /etc/shadow on SVR4 Unix any backdoor?