COMMAND

    UDB

SYSTEMS AFFECTED

    Security Gotchas in IBM's UDB for Windows NT

PROBLEM

    Clem Colman found following.   Here's something that people  using
    IBM's Universal Database Version 5 on NT should be aware of.   UDB
    is IBM's latest rehash of  DB2.  It's a fully  relational database
    yabada yabada...   One of  the features  of UDB  (and possibly DB2
    v4) is that NT users and groups are granted permissions to objects
    within the database, such  as tables, views, schema  etc directly.
    That is that UDB does not  maintain an internal list of users  etc
    but instead is happy to use NT's account database.  When a user is
    authenticated by  UDB, that  user's group  memberships are fetched
    from only the SAM that their account is authenticated in.

    Sounds fine, even  good.  Consolidation  of accounts etc.   At the
    same time it does seem to allow the flexibility to create  another
    account for the user by making the UDB server a stand alone member
    server, or even a domain in it's own right.  Also, UDB allows  for
    a couple  of different  authentication types.   These are  server;
    client,  and  trust  all  clients.   In  server authentication the
    server is  passed a  username password  pair which  it attempts to
    verify,  against  local  SAM,  domain,  and master domains in that
    order.  Under either of the client authentication types the client
    can do the authentication.   It passes UDB the  name of the  user,
    and a list of groups that the  user is a member of.  You  will see
    shortly why neither of  the client authentication options  provide
    much security.

    One potential exploit, and there may be others in a similar  vein,
    is this scenario.   A domain member  file server (not  BDC, but  a
    member of the domain), running UDB,  has a local group in its  SAM
    called  "UDB_Admin".   This  local  group  has  been  assigned  DB
    Administrator  privileges  with  all  that  that  entails  on  the
    database.  A number of user accounts have been setup on the  local
    SAM to  log into  the server  and get  access to  the database.  A
    person, whom  we call  "X" to  conjure up  sinister images, has an
    account in the domain.  X creates a local group called "UDB_Admin"
    and  makes  himself  and  his  friends  Satan  and  Santa members.
    Creating a local user group in the domain is a permissible  action
    for users by default (I think).  Once the group has been created X
    can continue to modify it through creator/owner privileges.   When
    X connects  to the  database on  the server,  using ODBC compliant
    tools  etc,  the  database  server  checks  X's group memberships.
    Amongst other things  UDB_Admin is returned  as one of  the groups
    that X is a member of.  Here's the killer.  UDB does not use SIDS,
    but just the text names of users  and groups.  So, because X is  a
    member  of  a  UDB_Admin  he  is  granted  DB  Admin access to the
    database.  A similar problem exists if the domain the server is in
    trusts another domain  as UDB will  try and authenticate  users in
    trusted domains.

    Needless to  say that  if you  allow client  authentication of any
    type it would be ridiculously easy to spoof a valid user id and/or
    list of groups provided you  had access to this information.   You
    can just create  this information on  the SAM of  a non domain  NT
    workstation I dare say, although can't say this was tested.

SOLUTION

    Dale Hagen from IBM responded to this with  following information.
    "If  you  choose  to  use  client  authentication (its also a good
    practice even if you use server authenticaiton)  then we recommend
    that you do the following.  Enforce Domain Logon. That is, require
    that each user log on to  the Domain.  EITHER (only create  groups
    at  the  Domain  Controller)  OR  (on  each Database Server create
    groups that contain  Domain Accounts AND  set the registry  option
    on the  database server  to only  use local  group lookup  (db2set
    DB2_GRP_LOOKUP=local)).  Only trust  Windows NT clients, ie  force
    Windows 95 and  Windows 3.1 clients  to provide a  userid/password
    on the connect statement. Do this by updating the DBM config  file
    with "db2 update dbm cfg using trust_allclnts no" and "db2  uddate
    dbm  cfg  using  trust_clntauth  server".  This  will  force those
    clients  to   explicitly  provide   a  userid/password   and  that
    userid/password will be  authenticated at the  server ONLY.   When
    db2  receives  an  implicit  connection  request  with  a   userid
    extracted from the operating system, it uses LookupAccountName  to
    find out where this userid is defined.  LookupAccountName provides
    us the name of the domain where the userid is found.  We determine
    the machine that the account  is defined in and if  DB2_GRP_LOOKUP
    is NOT defined as local, we  will go to that machine to  enumerate
    groups. If it is defined,  then we will enumerate groups  locally.
    The  db2  administrator  on  the  db2  server  machine can protect
    himself by setting DB2_GRP_LOOKUP to local.  Then when x  connects
    to machine "db2server" with his domain account "domain\x" db2 will
    enuermate groups  for the  fully qualified  name "doman\x"  on the
    LOCAL machine ONLY. Since  x is NOT a  member of UDB_Admin on  the
    LOCAL machine, he will not be sinister w.r.t DB2".

    Needless to say using either of the client authentication  options
    is a real risk.  You should have port 523 blocked on your firewall
    if you choose this option.