home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / etc / misc / cdc327.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  13.7 KB  |  287 lines
  1.  
  2.                                    _
  3.                                   | \
  4.                                   |  \
  5.                                   | | \
  6.                            __     | |\ \             __
  7.      _____________       _/_/     | | \ \          _/_/     _____________
  8.     |  ___________     _/_/       | |  \ \       _/_/       ___________  |
  9.     | |              _/_/_____    | |   > >    _/_/_____               | |
  10.     | |             /________/    | |  / /    /________/               | |
  11.     | |                           | | / /                              | |
  12.     | |                           | |/ /                               | |
  13.     | |                           | | /                                | |
  14.     | |                           |  /                                 | |
  15.     | |                           |_/                                  | |
  16.     | |                                                                | |
  17.     | |      c   o   m   m   u   n   i   c   a   t   i   o   n   s     | |
  18.     | |________________________________________________________________| |
  19.     |____________________________________________________________________|
  20.  
  21.  ...presents...     Vulnerabilities in the S/KEY One-Time 
  22.                                Password System          by Mudge
  23.                                                         01/01/1997-#327
  24.  
  25.              __//////\ -cDc- CULT OF THE DEAD COW -cDc- /\\\\\\__
  26.    Est. 1984   \\\\\\/    xXx   BOW to the COW   xXx    \//////   Est. 1984
  27.  
  28.     __    _   _    __     _   _    __       _   _      __    _   _      __
  29.    |__heal_the_sick__raise_the_dead__cleanse_the_lepers__cast_out_demons__|
  30.  
  31.      This text attempts to touch upon several vulnerabilities found in One-
  32. Time Password (OTP) implementations such as S/KEY.  I'm writing specifically
  33. of the free version of S/KEY from Bellcore.
  34.  
  35.      Being sniffed is the sys-admin's/security analyst's worst nightmare
  36. (well, not really but humor me).  For those that aren't aware, sniffing is
  37. slang for placing a network card into promiscuous mode so that it actually
  38. looks at all of the traffic coming along the line and not just the packets
  39. that are addressed to it.  By doing this one can catch passwords, login
  40. names, confidential information, etc.  Of course there are good sides to
  41. being able to place a card into promiscuous mode such as traffic analysis,
  42. debugging drivers and network applications, and testing router configurations
  43. to name just a few.  In promiscuous mode anything that goes by in plaintext
  44. is fair game.  Each time you telnet to a machine, ftp to another machine,
  45. connect to the smtp port or POP port, read news off of a different machine,
  46. or issue Remote Procedure Calls you hand your password and other private
  47. information to anyone who wants to sit on the lines and listen in.  There are
  48. several ways of protecting oneself.  DESLogin provides completely encrypted
  49. telnet sessions, there is a kerberized POP server available, and there are
  50. hardware and software utilities to do encryption on different OSI layers.
  51. Many of these suffer from either being commercial products or simply being
  52. too difficult to administer.
  53.  
  54.      A wonderful security tool was presented to the network community that
  55. provides a seeming solution to having your password sniffed.  The theory
  56. behind it is to never use the same password.  This is accomplished by a
  57. challenge-response system.  The system you are contacting issues you a unique
  58. challenge.  You go off and compute your response and then send back that
  59. unique response to the host.  The next time you are presented with a
  60. different challenge and thus come back with a different response.  Sounds
  61. great doesn't it?  What's even better is that the software for the server
  62. side and the client side are free and widely available.  Here's an example of
  63. what it looks like:
  64.  
  65. evil.guy.com> telnet some.host.somewhere
  66. Trying 199.99.99.99... Connected to some.host.somewhere.
  67. Escape character is '^]'.
  68.  
  69. login: jdoe
  70. s/key 99 k113355
  71. Password:
  72.  
  73. [At this point the user either issues the following in another window or else
  74. suspends the current session]
  75.  
  76. ^]
  77. telnet>^Z
  78. evil.guy.com> key 99 k113356
  79. Reminder - Do not use key while logged in via telnet or dial-in.
  80. Enter secret password:[passwd doesn't echo]
  81. FLY ACE TIDY BURR CON CADY
  82. evil.guy.com> fg
  83. Password:FLY ACE TIDY BURR CON CADY
  84.  
  85. Welcome back jdoe!
  86. bash%
  87.  
  88.      What has happened here is a telnet to a machine where S/KEY is in use.
  89. After logging in with the username of jdoe, a challenge is issued.  jdoe
  90. computes his response on a local machine and uses that as input for the
  91. password prompt.  Let's take a look at this and figure:
  92.  
  93. s/key 99 k113355
  94. ^^^^^^^^^^^^^^^^
  95. s/key - text so the user knows what is going on
  96. 99 - number of iterations through MD4
  97. k113355 - seed
  98.  
  99.      Assuming jdoe provided a valid response, the next time he would try to
  100. log in the iterations counter would be decremented (i.e. s/key 98 k113355)
  101. and the response that would be computed would be different.  Thus anybody who
  102. sniffed the above (i.e. user: jdoe - Password: FLY ACE TIDY BURR CON CADY)
  103. would not be able to gain access to the machine with this information as the
  104. same password is not valid for the next session.
  105.  
  106.  
  107.   * Dictionary Attacks
  108.  
  109.  
  110.      One of the first vulnerabilities we find is that all of the information
  111. is broadcast in plaintext.  What this means is that it is trivial to take the
  112. challenge and response and compare this with the result of the challenge
  113. applied to words out of a dictionary.
  114.  
  115.      Remember in the above example, the user escaped to a local shell and
  116. entered the following:
  117.  
  118. evil.guy.com> key 99 k113356
  119. Reminder - Do not use key while loged in via telnet or dial-in.
  120. Enter secret password:[passwd doesn't echo]
  121. FLY ACE TIDY BURR CON CADY
  122.  
  123.      Since people will pick easy-to-remember words or phrases this works to
  124. the cracker's advantage.  Granted, users can now choose phrases instead of
  125. a single word... however, how many people are likely to choose "k35jsX/
  126. O0l3f ffdg99999d" as opposed to "mary had a little lamb"?
  127.  
  128.      The dictionaries used for this sort of attack will simply start to
  129. encompass phrases.  For example:
  130.  
  131. username: jdoe                          # here we have the information
  132. challenge: 99 k113355                   # that we captured
  133. response: WELD GUY CHIMP SWING GONE
  134. jdoe's real password: ????
  135.  
  136. dictionary word 1: love                 # here we start the dictionary
  137. challenge: 99 k113355                   # attack
  138. response: BAD LOST CRUMB HIDE KNOT
  139. (well that's not it...)
  140.  
  141. dictionary word 2: sex
  142. challenge: 99 k113355
  143. response: FORT HARD BIKE HIT SWING
  144. (not it either...)
  145. dictionary word 3: secret
  146. challenge 99 k113355
  147. response: WELD GUY CHIMP SWING GONE
  148. [bingo!]
  149.  
  150.      We now know that jdoe's real password is 'secret.'  With this
  151. information we can generate a valid response no matter what the challenge.
  152. This is particularly important since in the current implementations of the
  153. S/KEY package neither the client or server side does any sort of sanity check
  154. on the security of the chosen password.  This means there is no failsafe to
  155. try to prevent you from choosing your login name as your password or other
  156. silliness.
  157.  
  158.      Another source for dictionary attacks come from the /etc/skeykeys file.
  159. The number of sites that have S/KEY set up that have the improper permissions
  160. set on this file is quite surprising (although this is to be expected as the
  161. code from both Bellcore and Weitse Venema's logdaemon set it up this way.  A
  162. quick fix is to simply change the mode to 600).  This file should not be set
  163. world readable.  While the 'keyinfo' program would like it to be so, the harm
  164. outweighs the good.
  165.  
  166.      The skeykeys file looks like this:
  167.  
  168. root 0072 k113357          12afaa8be65f0502  Jun 29,1995 12:40:48 jdoe 0099
  169. k113355       c7f42dfd84914af3  May 30,1995 16:20:19 [etc...]
  170.  
  171.      What we have here is the username, iteration counter, seed, and a hex
  172. representation of the five word response we saw before.  The other three
  173. fields are simply date and time information which isn't of much interest
  174. right now.  The exact same sort of dictionary hack can be made with this
  175. information.  Just to bring the point home, let's pretend you have a large
  176. user base of say, 200 users, and since you are security conscious you have a
  177. shadow password system and are using S/KEY.  The average user will not be
  178. able to look at the real password file since it is shadowed, they will not be
  179. able to do a standard dictionary attack on it.  He will, however, be able to
  180. see the skeykeys file and do a dictionary attack on it if the permissions are
  181. set improperly, thus defeating the benefits of a shadowed password file.
  182.  
  183.  
  184.   * Spoofing Attacks
  185.  
  186.  
  187.      Since the iteration counter is transmitted along with the seed, one
  188. possibility is to masquerade as the server.  This could be done by setting up
  189. a bogus gateway or whatever.  Who we are really spoofing is the user.  Let's
  190. take the following scenario...
  191.  
  192. login: jdoe [jdoe telnet's to his machine]
  193.  
  194. s/key 55 k113355 password: [what jdoe should have seen was a challenge of 98
  195. k113355 but instead we have sent a lower challenge of 55 k113355.]
  196.  
  197. password: MY SPIT LOFT HEAD TEAR [jdoe calculates the response for 55 k113355
  198. based upon his secret password]
  199.  
  200. Login incorrect login: [we tell jdoe that his login was incorrect and forward
  201. the rest of the connection to the actual machine he really wanted to talk to
  202. in the first place]
  203.  
  204.      With the response we have for the 55 k113355 challenge all we have to do
  205. is run it through more iterations of md4 for the subsequent responses.  For
  206. example, with the information we have now, if we want to figure out the
  207. response for the challenge 60 k113355 we need to run it through 5 more
  208. iterations of md4.  If we were looking for the response to the challenge of
  209. 97 k113355 we would need to run it through 42 more iterations of md4, etc.
  210.  
  211.      We can now telnet to the machine and, as long as the iteration counter
  212. in the challenge is above 55 k113355, we can compute the proper response
  213. without ever having to know the secret password.  There are many variations
  214. on the above theme.
  215.  
  216.  
  217.   * Race Attacks
  218.  
  219.  
  220.      There seems to be a problem with S/KEY that allows two simultaneous
  221. logins to occur with the same key.  If I am in a position to capture- look-
  222. at- modify jdoe's responses as they go by (i.e. we're a bogus gateway or
  223. something again), we can open up another telnet session to the same machine
  224. and, since he hasn't logged in yet the iteration counter hasn't been
  225. decremented.  As the program has to work this way as to avoid denial of
  226. service attacks we get the same challenge.  When we receive jdoe's response
  227. we simply send the same information over to our other processes as well as
  228. his original login.  With a little luck a locking problem will occur with the
  229. skeykeys file and we will both be let in under the same challenge and
  230. response (but wait you say, there can't be a locking problem as S/KEY does
  231. not do real file locking.  Instead it jumps through a bunch of hoops to do a
  232. similar thing... get the idea?).  This should be easily fixable in the source
  233. but I have not yet investigated this fully.
  234.  
  235.  
  236.   * Hijacking Attacks
  237.  
  238.  
  239.      This is not a problem with S/KEY but simply a reminder of your
  240. vulnerability.  Remember that once a connection has been established and jdoe
  241. has successfully answered the challenge with the appropriate response, there
  242. are no more checks done on the S/KEY side of things.  It is not designed to
  243. re-check the validity and authorization of a user once he is logged in.  It
  244. is not kerberos.  People are too often lulled into a false sense of security,
  245. as in the choosing of easily guessed passwords, when they use the S/KEY
  246. system.  Once in, the same IP hijacking and monitoring tricks can be used on
  247. jdoe's session as can be used on non-S/KEY sessions.
  248.  
  249.      Along with hijacking, think of the administrator who logs in with his
  250. OTP and the proceeds to enter new accounts.  The passive sniffer will still
  251. see all of the passwords and sensitive information that the administrator is
  252. entering.
  253.  
  254.  
  255.   * Conclusion
  256.  
  257.  
  258.      I like S/KEY.  I think S/KEY is a very useful utility and a great asset
  259. to the community in general.  This article should not dissuade anyone from
  260. using S/KEY.  It is simply meant to point out certain vulnerabilities.  The
  261. worst thing that can happen to the security conscious is thinking they are
  262. secure when they really aren't.  While S/KEY does provide added security,
  263. neither it nor any other product currently out on the market is the be-all
  264. end-all to security.  If this article has helped to remind anyone of this
  265. then it has done its job.
  266.  
  267. -Mudge mudge@l0pht.com
  268. Organizations: L0pht Heavy Industries (aka l0pht.com)
  269.                cDc communications
  270.     .-.                             _   _                             .-.
  271.    /   \           .-.             ((___))             .-.           /   \
  272.   /.ooM \         /   \       .-.  [ x x ]  .-.       /   \         /.ooM \
  273. -/-------\-------/-----\-----/---\--\   /--/---\-----/-----\-------/-------\-
  274. /lucky  13\     /       \   /     `-(' ')-'     \   /       \     /lucky  13\
  275.            \   /         `-'         (U)         `-'         \   /
  276.             `-'              the original e-zine              `-'    _
  277.       Oooo                    eastside westside                     / )   __
  278.  /)(\ (   \                       WORLDWIDE                        /  (  /  \
  279.  \__/  )  /  Copyright (c) 1997 cDc communications and the author. \   ) \)(/
  280.        (_/   Award-winning CULT OF THE DEAD COW is a trademark of   oooO
  281.           cDc communications, PO Box 53011, Lubbock, TX, 79453, USA.      _
  282.   oooO           All rights reserved.  Edited by Swamp Ratte'.      __   ( \
  283.  /   ) /)(\                                                        /  \  )  \
  284.  \  (  \__/       Save yourself!  Go outside!  Do something!       \)(/ (   /
  285.   \_)                     "THE COW WALKS AMONGST US"                    Oooo 
  286.  
  287.