IpSpoof


SUBMITTED BY: ProffesorFaux

DATE: July 22, 2020, 11:19 a.m.

FORMAT: Text only

SIZE: 12.3 kB

HITS: 349

  1. =============================================================================
  2. CA-95:01 CERT Advisory
  3. January 23, 1995
  4. IP Spoofing Attacks and Hijacked Terminal Connections
  5. -----------------------------------------------------------------------------
  6. The CERT Coordination Center has received reports of attacks in which
  7. intruders create packets with spoofed source IP addresses. These attacks
  8. exploit applications that use authentication based on IP addresses. This
  9. exploitation leads to user and possibly root access on the targeted system.
  10. Note that this attack does not involve source routing. Recommended solutions
  11. are described in Section III below.
  12. In the current attack pattern, intruders may dynamically modify the kernel of
  13. a Sun 4.1.X system once root access is attained. In this attack, which is
  14. separate from the IP spoofing attack, intruders use a tool to take control of
  15. any open terminal or login session from users on the system. Note that
  16. although the tool is currently being used primarily on SunOS 4.1.x systems,
  17. the system features that make this attack possible are not unique to SunOS.
  18. As we receive additional information relating to this advisory, we will place
  19. it, along with any clarifications, in a CA-95:01.README file. CERT advisories
  20. and their associated README files are available by anonymous FTP from
  21. info.cert.org. We encourage you to check the README files regularly for
  22. updates on advisories that relate to your site.
  23. -----------------------------------------------------------------------------
  24. I. Description
  25. This description summarizes both the IP spoofing technique that can
  26. lead to root access on a system and the tool that intruders are using to
  27. take over open terminal and login connections after they get root access.
  28. We are currently seeing attacks in which intruders combine IP spoofing
  29. with use of the tool. However, these are two separate actions. Intruders
  30. can use IP spoofing to gain root access for any purpose; similarly, they
  31. can highjack terminal connections regardless of their method of gaining
  32. root access.
  33. IP spoofing
  34. To gain access, intruders create packets with spoofed source IP
  35. addresses. This exploits applications that use authentication based on
  36. IP addresses and leads to unauthorized user and possibly root access
  37. on the targeted system. It is possible to route packets through
  38. filtering-router firewalls if they are not configured to filter
  39. incoming packets whose source address is in the local domain. It
  40. is important to note that the described attack is possible even if
  41. no reply packets can reach the attacker.
  42. Examples of configurations that are potentially vulnerable include
  43. - routers to external networks that support multiple internal
  44. interfaces
  45. - routers with two interfaces that support subnetting on the
  46. internal network
  47. - proxy firewalls where the proxy applications use the source
  48. IP address for authentication
  49. The IP spoofing attacks we are currently seeing are similar to those
  50. described in two papers: 1) "Security Problems in the TCP/IP Protocol
  51. Suite" by Steve Bellovin, published in _Computer Communication Review_
  52. vol. 19, no. 2 (April 1989) pages 32-48; 2) "A Weakness in the 4.2BSD
  53. Unix TCP/IP Software" by Robert T. Morris. Both papers are available
  54. by anonymous FTP from
  55. ftp.research.att.com:/dist/internet_security
  56. Bellovin paper: ipext.ps.Z
  57. Morris paper: 117.ps.Z
  58. Services that are vulnerable to the IP spoofing attack include
  59. SunRPC & NFS
  60. BSD UNIX "r" commands
  61. anything wrapped by the tcp daemon wrappers - site dependent; check
  62. your configuration
  63. X windows
  64. other applications that use source IP addresses for authentication
  65. Hijacking tool
  66. Once the intruders have root access on a system, they can use a tool
  67. to dynamically modify the UNIX kernel. This modification allows them
  68. to hijack existing terminal and login connections from any user on the
  69. system.
  70. In taking over the existing connections, intruders can bypass one-time
  71. passwords and other strong authentication schemes by tapping the
  72. connection after the authentication is complete. For example, a
  73. legitimate user connects to a remote site through a login or terminal
  74. session; the intruder hijacks the connection after the user has
  75. completed the authentication to the remote location; the remote site
  76. is now compromised. (See Section I for examples of vulnerable
  77. configurations.)
  78. Currently, the tool is used primarily on SunOS 4.1.x systems. However,
  79. the system features that make this attack possible are not unique to
  80. SunOS.
  81. II. Impact
  82. Current intruder activity in spoofing source IP addresses can lead to
  83. unauthorized remote root access to systems behind a filtering-router
  84. firewall.
  85. After gaining root access and taking over existing terminal and login
  86. connections, intruders can gain access to remote hosts.
  87. III. Solutions
  88. A. Detection
  89. IP spoofing
  90. If you monitor packets using network-monitoring software such as
  91. netlog, look for a packet on your external interface that has
  92. both its source and destination IP addresses in your local domain.
  93. If you find one, you are currently under attack. Netlog is
  94. available by anonymous FTP from
  95. net.tamu.edu:/pub/security/TAMU/netlog-1.2.tar.gz
  96. MD5 checksum: 1dd62e7e96192456e8c75047c38e994b
  97. Another way to detect IP spoofing is to compare the process
  98. accounting logs between systems on your internal network. If
  99. the IP spoofing attack has succeeded on one of your systems,
  100. you may get a log entry on the victim machine showing a remote
  101. access; on the apparent source machine, there will be no
  102. corresponding entry for initiating that remote access.
  103. Hijacking tool
  104. When the intruder attaches to an existing terminal or login
  105. connection, users may detect unusual activity, such as commands
  106. appearing on their terminal that they did not type or a blank window
  107. that will no longer respond to their commands. Encourage your users
  108. to inform you of any such activity. In addition, pay particular
  109. attention to connections that have been idle for a long time.
  110. Once the attack is completed, it is difficult to detect. However,
  111. the intruders may leave remnants of their tools. For example, you
  112. may find a kernel streams module designed to tap into existing TCP
  113. connections.
  114. B. Prevention
  115. IP spoofing
  116. The best method of preventing the IP spoofing problem is to install
  117. a filtering router that restricts the input to your external
  118. interface (known as an input filter) by not allowing a packet
  119. through if it has a source address from your internal network. In
  120. addition, you should filter outgoing packets that have a source
  121. address different from your internal network in order to prevent
  122. a source IP spoofing attack originating from your site.
  123. The following vendors have reported support for this feature:
  124. Bay Networks/Wellfleet routers, version 5 and later
  125. Cabletron - LAN Secure
  126. Cisco - RIS software all releases of version 9.21 and later
  127. Livingston - all versions
  128. If you need more information about your router or about firewalls,
  129. please contact your vendor directly.
  130. If your vendor's router does not support filtering on the inbound
  131. side of the interface or if there will be a delay in incorporating
  132. the feature into your system, you may filter the spoofed IP packets
  133. by using a second router between your external interface and your
  134. outside connection. Configure this router to block, on the outgoing
  135. interface connected to your original router, all packets that have a
  136. source address in your internal network. For this purpose, you can
  137. use a filtering router or a UNIX system with two interfaces that
  138. supports packet filtering.
  139. NOTE: Disabling source routing at the router does not protect you
  140. from this attack, but it is still good security practice to
  141. do so.
  142. Hijacking tool
  143. There is no specific way to prevent use of the tool other than
  144. preventing intruders from gaining root access in the first place.
  145. If you have experienced a root compromise, see Section C for general
  146. instructions on how to recover.
  147. C. Recovery from a UNIX root compromise
  148. 1. Disconnect from the network or operate the system in
  149. single-user mode during the recovery. This will keep users
  150. and intruders from accessing the system.
  151. 2. Verify system binaries and configuration files against the
  152. vendor's media (do not rely on timestamp information to
  153. provide an indication of modification). Do not trust any
  154. verification tool such as cmp(1) located on the compromised
  155. system as it, too, may have been modified by the intruder.
  156. In addition, do not trust the results of the standard UNIX
  157. sum(1) program as we have seen intruders modify system
  158. files in such a way that the checksums remain the same.
  159. Replace any modified files from the vendor's media, not
  160. from backups.
  161. -- or --
  162. Reload your system from the vendor's media.
  163. 3. Search the system for new or modified setuid root files.
  164. find / -user root -perm -4000 -print
  165. If you are using NFS or AFS file systems, use ncheck to
  166. search the local file systems.
  167. ncheck -s /dev/sd0a
  168. 4. Change the password on all accounts.
  169. 5. Don't trust your backups for reloading any file used by
  170. root. You do not want to re-introduce files altered by an
  171. intruder.
  172. ---------------------------------------------------------------------------
  173. The CERT Coordination Center thanks Eric Allman, Steve Bellovin, Keith Bostic,
  174. Bill Cheswick, Mike Karels, and Tsutomu Shimomura for contributing to our
  175. understanding of these problems and their solutions.
  176. ---------------------------------------------------------------------------
  177. If you believe that your system has been compromised, contact the CERT
  178. Coordination Center or your representative in Forum of Incident
  179. Response and Security Teams (FIRST).
  180. If you wish to send sensitive incident or vulnerability information to
  181. CERT staff by electronic mail, we strongly advise that the e-mail be
  182. encrypted. The CERT Coordination Center can support a shared DES key, PGP
  183. (public key available via anonymous FTP on info.cert.org), or PEM (contact
  184. CERT staff for details).
  185. Internet E-mail: cert@cert.org
  186. Telephone: +1 412-268-7090 (24-hour hotline)
  187. CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4),
  188. and are on call for emergencies during other hours.
  189. Fax: +1 412-268-6989
  190. CERT Coordination Center
  191. Software Engineering Institute
  192. Carnegie Mellon University
  193. Pittsburgh, PA 15213-3890
  194. USA
  195. Past advisories, CERT bulletins, information about FIRST representatives,
  196. and other information related to computer security are available for anonymous
  197. FTP from info.cert.org.
  198. CERT is a service mark of Carnegie Mellon University.

comments powered by Disqus