Vulnerability

    ComStock

Affected

    S&P ComStock multiCSP (Linux)

Description

    Kevin Kadow found following.  Standard & Poor's ComStock  provides
    stock  quotes  and  news  as  a  real-time  data feed on dedicated
    circuits.  ComStock offers a 'Client Site Processor' as a means of
    receiving their data feed, the   MultiCSP Kevin tested against  is
    shipped as a PC running Red Hat Linux 5.1, with version 4.2.x.x of
    'mcsp', the MultiCSP application software.

    The MultiCSP system Kevin examined  was a textbook example of  how
    NOT to  ship a  Linux-based 'appliance',  with numerous extraneous
    services  enabled,  several  UN-passworded  accounts  (including a
    root-equivalent account), world-writable files, and multiple  root
    holes. It does not appear that  there is any effort to update  the
    OS after the  machine is deployed  at a client  site, or to  train
    clients  (Most  of  whom  are  only  familiar  with MS-Windows) to
    update the  system.   The network  connection for  the stock quote
    service is a leased line or other dedicated data feed.  The  Linux
    client at  customer sites  use reserved  (private) address  space,
    however clients are   connected to Bay  routers on the  Concentric
    network which are Internet accessible.

    There's no  evidence of  IP filters  anywhere within  the network,
    there is nothing on the  Concentric network to prevent leaking  of
    172.23.*.* traffic to the  public Internet, or to  prevent clients
    from within the  ComStock network forging  source IPs on  outbound
    packets.

    The most obvious root hole on the MultiCSP host is the 'netconfig'
    account, an  unpassworded UID  0 login  that runs  a menu program.
    This  account  displays  a  menu  allowing  for  changing  the  IP
    addresses, and the ability to edit the MCSP startup script,  using
    the 'vi' editor.  The implications are obvious.  The system  ships
    with very weak default passwords  for the root account as  well as
    'support' and 'isdnconfig'.  Root can be logged into via telnet.

    Stephen Friedl added following.  Review above is fairly  scathing,
    but it substantially UNDERstates the risk of running one of  these
    machines.   These  machines  are  an  unmitigated  *disaster*  for
    security,  and  it's  not  often  we  can  use  "unmitigated"   so
    literally.

    For  starters,  on  the   "outside"  interface  they  provide   an
    /etc/issue file that kindly  tells you nearly everything  you need
    to know.  Just telnet to the box, and it greets you with:

        Red Hat Linux release 5.1 (Manhattan)
        Kernel 2.0.35 on an i686

        MCSP - Standard & Poor's ComStock - The McGraw-Hill Companies

        Multiuser CSP Login:
        <alt><F1> login: screen
        <alt><F#> login: showusers
        <alt><F#> login: showlog
        <alt><F#> login: netconfig
        <alt><F#> login: isdnconfig
        <alt><F#> login: helpmcsp
        <alt><F#> login: helpicl
        login:

    The only thing missing is "Please Hack Me -- I'm easy".  The  last
    two "help" accounts have no passwords, and they bring up "more" on
    some text files.   When paused at the  first prompt, it's easy  to
    type "v" to bring up vi on the file, then type

        :set shell=/bin/bash <RETURN>
        :shell <RETURN>

    and get a non-root shell.  This takes about 12 seconds.  The other
    "config"  accounts  provide  similarly  easy interfaces via simple
    menus,  though  Stephen  didn't  spend  any  time  on  them.  They
    helpfully keep passwords in the "old" format in /etc/password:  no
    /etc/shadow, no MD5, so Crack  will give you the root  password of
    "c0mst0ck" (zero instead  of oh --  aren't they clever).   Now you
    are root on a Linux box with a C compiler.

    The machine has LOTS of security issues: programs with known holes,
    /many/ unneeded services, world-writable directories, and the list
    goes on.  But  in one respect this  shouldn't matter much: if  you
    have a  proper firewall  in place,  this machine  won't allow  the
    outside world to get anywhere near it.  Or so you thought.

    These  machines  have  a  dedicated  circuit on the second network
    interface (T1, ISDN,  etc.) that supports  the feed from  S&P, and
    it seems to be on a 172.23.*.* private network run by  Concentric.
    By  downloading  and  compiling  a  few  tools  (the  compiler was
    thoughtfully  left  behind),  you'll  be  able  to  "scan" various
    172.23.x.x address blocks  to discover numerous  MultiCSP machines
    owned by entirely unrelated  customers.  Since these  machines are
    all configured to run Samba by default, their "signature" is  very
    easy to detect with a NETBIOS nameservice scanner.

    Once the machines are identified, it is a trivial matter to  login
    to  these  remote  machines  and  get  root  via  the same default
    password or "vi" exploit.   These machines are apparently  located
    all over the world and  every single one has a  "private" 10.x.x.x
    or 192.168.x.x address on the "customer" side of the machine.

    This means that no matter  how good your firewall and  security is
    on the "outside" of the network,  someone will be able to show  up
    as root on a  Linux box with compiler  tools.  On the  *inside* of
    your network.

Solution

    If you have the misfortune  of having a MultiCSP on  your network,
    you  have  my  sympathy.   If  you  can't live without their stock
    information, It  is possible  to use  the root  holes to lock down
    the box as best you can,  then put it behind a firewall  with just
    the  CSP  TCP  port  open  _inbound_  to the MCSP system from your
    hosts, or at least a router with equivalent traffic filters.  Then
    pray for the best.

    Stephen added:
    1) Scream *bloody murder* at  your S&P representative.  They  have
       more or less completely ignored reports of this serious  matter
       as far as one can tell.   The previous reporter of this  (Kevin
       Kadow) tried every way he knows how to get them interested, and
       nothing happened,  and even  an indirect  communiation to S&P's
       CTO got no response.  Talk to your legal counsel if you are  so
       inclined.  S&P is just grossly negligent on this front.

    2) Remove the /etc/issue file that reveals just how much stuff  is
       here.  Though there are  way too many services running  on this
       machine, and it would probably  take no time to break  into via
       other means, the big /etc/issue  file provided is just an  open
       invitation to  abuse by  even a  casual passer-by.   It  surely
       caught *someones* attention.

       Unless S&P's changed something (unlikely from your  description
       of  what's  been  left  enabled)  Red  Hat  systems  regenerate
       /etc/issue  from  scratch   on  boot.    You  need  to   modify
       /etc/rc.d/rc.local  instead,  which  contains  the  code   that
       generates /etc/issue.

    3) Put good passwords on ALL the accounts, including the "helpful"
       ones.  If you really don't need the help accounts, disable them
       entirely.   These  help  files  are  very  easy to find without
       special logins.  It is  believed that S&P might login  to these
       machines  remotely,  so  you  may  need to coordinate this with
       them.

    4) Find out from S&P just which services that they really need and
       drop the ones not needed.  They are running Samba,  portmapper,
       and SNMP, and it's not clear that any are really needed. Apache
       is  running,  and  for  sure  it's  /not/  needed.   Shut  down
       EVERYTHING you don't need.   telnet is probably the only  thing
       really needed.

    5) Use TCP  wrappers to limit  who can login  to your system  from
       random IP addresses, and certainly disable all logins from  the
       Concentric side of the  world. If possible, disable  the telnet
       daemon entirely and  just do all  your administration from  the
       console.  Use Secure Shell instead of telnet.

    6) Install and  use ipchains on  *both* interfaces to  drastically
       reduce what this  machine can do.   The Concentric side  of the
       world seems to talk to just two machines that are mentioned  in
       /etc/hosts:

        #Name of machine on far side (e.g big1 and big2)
        172.23.94.10 BIG1
        172.23.95.10 BIG2

       If  you  determine  that  this  is  the limit of your "outside"
       traffic, firewall everything else.

       As another  poster mentioned,  this is  a 2.0.x  kernel, so you
       need to use ipfwadm, not ipchains.

    You must  also firewall  the "outside"  interface as  well on  the
    assumption  that  the  machine  is  compromised from the "inside".
    Also use ipchains to limit virtually everything on this interface,
    allowing only that which you know to be required.