home *** CD-ROM | disk | FTP | other *** search
/ Hackers Handbook - Millenium Edition / Hackers Handbook.iso / library / hack99 / mSQL_remote.txt < prev    next >
Encoding:
Internet Message Format  |  1999-03-24  |  8.1 KB
  1. Date: Mon, 15 Feb 1999 04:56:24 -0500
  2. From: Dave G. <dhg@KSRT.ORG>
  3. To: BUGTRAQ@netspace.org
  4. Subject: KSR[T] Advisory #10: mSQL ServerStats
  5.  
  6. KSR[T] Security Advisories
  7. http://www.ksrt.org
  8. ksrt@ksrt.org
  9.  
  10. ---
  11.  
  12.                                                     KSR[T] Advisory #010
  13.                                                     Date:  Feb. 15, 1999
  14.                                                     ID #:  msql-info-010
  15.  
  16. Affected Program:    mSQL (Mini SQL) 2.0.6 and below
  17.  
  18. Operating System(s): UNIX (Not vendor specific)
  19.  
  20. Summary:             Remote attackers could potentially gain read and/or
  21.                      access to databases by retrieving authentication
  22.                      information that is displayed in the response to a
  23.                      remote statistics query.
  24.  
  25. Problem Description: mSQL is a database engine (available from
  26.                      http://www.hughes.com.au) that supports a subset of
  27.                      the ANSI SQL query specifications.  If remote
  28.                      access is enabled (as of 2.0.4.1 remote access is
  29.                      disabled by default) a remote user can retrieve
  30.                      sensitive information.
  31.  
  32.                      By sending a ServerStats request, a remote attacker
  33.                      can view the following information about the msqld
  34.                      process:
  35.  
  36.                      1. The connection table
  37.                           This table is a 'finger' like display of users
  38.                           connected to the server, which databases they
  39.                           are accessing, what hosts they are accessing
  40.                           the server from, and other less critical
  41.                           pieces of information.
  42.  
  43.                           Since mSQL uses either host based and/or user
  44.                           based authentication, this table reveals all
  45.                           of the necessary components to access a
  46.                           particular database.  This is only true if a
  47.                           user is accessing a database at the time of a
  48.                           query.
  49.  
  50.                      2. The server version
  51.                           This allows an attacker to determine if a
  52.                           machine is running a vulnerable version of
  53.                           mSQL.
  54.  
  55.                      3. The current and maximum number of connections
  56.                           These two pieces of information can be used to
  57.                           launch an efficient denial of service attack.
  58.  
  59.                      4. The user name and user id of the msqld process
  60.                           These two pieces of information provide
  61.                           information about the underlying operating
  62.                           system.
  63.  
  64.  
  65. Compromise:          If host based access control is disabled, a
  66.                      remote attacker can use the user names listed in
  67.                      the connection table to access databases.  If host
  68.                      based access control is enabled, a remote attacker
  69.                      could launch a more complex attack (like DNS cache
  70.                      poisoning) to access mSQL databases.
  71.  
  72. Notes:               We would like to thank David J. Hughes and Window
  73.                      Snyder for their assistance with this advisory.
  74.  
  75. Patch/Fix:           The latest version of mSQL (2.0.7) scheduled for
  76.                      release on February 15th, 1999 has disabled remote
  77.                      statistics gathering.
  78.  
  79. ----------------------------------------------------------------------------------
  80.  
  81. Date: Mon, 15 Feb 1999 13:10:44 -0800
  82. From: John W. Temples <john@KUWAIT.NET>
  83. To: BUGTRAQ@netspace.org
  84. Subject: Re: KSR[T] Advisory #10: mSQL ServerStats
  85.  
  86. On Mon, 15 Feb 1999, Dave G. wrote:
  87.  
  88. > Compromise:          If host based access control is disabled, a
  89. >                      remote attacker can use the user names listed in
  90. >                      the connection table to access databases.  If host
  91. >                      based access control is enabled, a remote attacker
  92. >                      could launch a more complex attack (like DNS cache
  93. >                      poisoning) to access mSQL databases.
  94.  
  95. This is hardly news; mSQL's access control is extremely weak.
  96. ServerStats probably makes it easier to get into an mSQL database, but
  97. if remote access is enabled, you simply need to know an authorized
  98. username (say, "root") to log into the database -- there are no
  99. passwords.  And you don't even need a username to perform DoS attacks,
  100. since mSQL is a single-threaded server -- just telnet to mSQL's port
  101. and sit there.  As far as I can see, the only thing that's changed
  102. since I posted about this in September, 1997, is that remote access is
  103. now disabled by default.
  104.  
  105. --
  106. John W. Temples, III       ||       Providing the first public access Internet
  107. Gulfnet Kuwait             ||            site in the Arabian Gulf region
  108.  
  109. ----------------------------------------------------------------------------------
  110.  
  111. Date: Mon, 15 Feb 1999 16:37:31 -0500
  112. From: Dave G. <dhg@KSRT.ORG>
  113. To: BUGTRAQ@netspace.org
  114. Subject: Re: KSR[T] Advisory #10: mSQL ServerStats
  115.  
  116. On Mon, 15 Feb 1999, John W. Temples wrote:
  117.  
  118. > On Mon, 15 Feb 1999, Dave G. wrote:
  119. >
  120. > > Compromise:          If host based access control is disabled, a
  121. > >                      remote attacker can use the user names listed in
  122. > >                      the connection table to access databases.  If host
  123. > >                      based access control is enabled, a remote attacker
  124. > >                      could launch a more complex attack (like DNS cache
  125. > >                      poisoning) to access mSQL databases.
  126. >
  127. > This is hardly news; mSQL's access control is extremely weak.
  128. > ServerStats probably makes it easier to get into an mSQL database, but
  129. > if remote access is enabled, you simply need to know an authorized
  130. > username (say, "root") to log into the database -- there are no
  131. > passwords.
  132.  
  133. I disagree.  This is news :-)
  134.  
  135. There is no probably about this.  If you can issue a ServerStats request
  136. on an mSQL server that is in use, you _will_ find all of the
  137. authentication credentials necessary to access mSQL databases. Your post
  138. basically pointed out that if you have the authentication credentials
  139. or can guess them, you can access mSQL databases.  Ours states that you
  140. _can_ get them right from the server.
  141.  
  142. Your post ( http://geek-girl.com/bugtraq/1997_3/0460.html ), discusses
  143. three things:
  144.  
  145. 1) default configuration is insecure
  146. 2) User based authentication is insufficient ( especially on multi-user
  147.    machines)
  148. 3) Host based authentication does one way DNS lookups based on IP
  149.    address which is trivial to bypass.
  150.  
  151. > And you don't even need a username to perform DoS attacks,
  152. > since mSQL is a single-threaded server -- just telnet to mSQL's port
  153. > and sit there.  As far as I can see, the only thing that's changed
  154. > since I posted about this in September, 1997, is that remote access is
  155. > now disabled by default.
  156. >
  157.  
  158. The advisory never states you need a user name for a denial of service
  159. attack.  And while it does show that other pieces of information could be
  160. used to assist in a DOS attack, they aren't necessary to launch one.
  161.  
  162. Dave G.
  163. <daveg@ksrt.org>
  164. http://www.ksrt.org
  165.  
  166. ----------------------------------------------------------------------------------
  167.  
  168. Date: Mon, 15 Feb 1999 13:53:03 -0800
  169. From: John W. Temples <john@KUWAIT.NET>
  170. To: BUGTRAQ@netspace.org
  171. Subject: Re: KSR[T] Advisory #10: mSQL ServerStats
  172.  
  173. On Mon, 15 Feb 1999, Dave G. wrote:
  174.  
  175. > There is no probably about this.  If you can issue a ServerStats request
  176. > on an mSQL server that is in use, you _will_ find all of the
  177. > authentication credentials necessary to access mSQL databases. Your post
  178. > basically pointed out that if you have the authentication credentials
  179. > or can guess them, you can access mSQL databases.  Ours states that you
  180. > _can_ get them right from the server.
  181.  
  182. What isn't news is the fact that allowing remote access to an mSQL
  183. database is extremely unwise.  Unauthorized access and DoS attacks are
  184. far too simple to achieve.  Adding or removing ServerStats access
  185. doesn't change this.
  186.  
  187. --
  188. John W. Temples, III       ||       Providing the first public access Internet
  189. Gulfnet Kuwait             ||            site in the Arabian Gulf region
  190.  
  191.