[rootshell] Security Bulletin #27

From: Kit Knox (kitat_private)
Date: Tue Jan 04 2000 - 15:16:49 PST

  • Next message: Philip Stoev: "Re: Hotmail security hole - injecting JavaScript using"

    www.rootshell.com
    Security Bulletin #27
    January 2nd, 2000 (Happy New Year!)
    
    [ http://www.rootshell.com/ ]
    
    (C) 1999-2000 Rootshell - Duplication permitted provided that this advisory
    is not modififed in any way.
    
    ----------------------------------------------------------------------
    
    01. Intel InBusiness E-mail Station
    -----------------------------------
    
    http://www.intel.com/network/smallbiz/inbusiness_email.htm
    
    The Intel InBusiness E-mail Station is a small application server designed
    for the small office.
    
    Summary
    -------
    Unauthenticated remote attackers can remove arbitrary files from the hard
    drive, and alter the configuration of the e-mail station.  Under certain
    configurations it is possible for a remote user to read the e-mail of any
    user on the server.
    
    Affected Versions
    -----------------
    All versions <= v1.04.  At the time of this advisory there is NOT an
    available fix.  If you have a firewall we suggest you filter port 244.
    
    Should a patch ever become available, we believe it would be posted here :
    
    http://support.intel.com/support/inbusiness/emailstation/index.htm
    
    Details
    -------
    
    Sept. 24, 1997 Intel announced it had agreed to acquire Dayna Communications
    Inc.  All Dayna products were discontinued as of June 1998, while a subset
    of their products was merged into the InBusiness product line.
    
    The e-mail station runs the VxWorks operating system on a 486 SX25
    processor.
    
    A daemon called "daynad" is bound to TCP port 244 in the e-mail station.  We
    believe that this portion of the code is from the product line that they
    acquired.
    
    Upon close examination it was discovered that many commands can be executed
    when connecting to this service, without ANY AUTHENTICATION.  By simply
    making a TCP connection to this service, the following commands are
    available :
    
    "FormSet" Upon next reboot, the e-mail station will revert to factory
    defaults.  This is the most interesting command.  By default the e-mail
    station will use a DHCP server to get its IP address.  This means that the
    next time the e-mail station reboots you can connect without a password and
    take control of the entire unit.  While we have not located a method to
    cause a reboot, a simple TCP SYN flood would result in the admin rebooting
    the box for you.  We also found that a steady flood of fragmented UDP
    packets freeze the IP stack leaving mbuf allocation errors in the event log.
    
    "FormProtect" Upon next reboot, the e-mail station will revert to factory
    defaults and have all passwords disabled.  The only way we found to recover
    was to connect back to this service and use the "FormSet" command.
    
    "MakeDir <directory>" Creates a directory on the hard drives filesystem.
    
    "Remove <filename>" Removes the specified file from the hard drive.
    Interesting files being users mail spool files, etc.
    
    "Z" This command drops you to a unix style login prompt.  From here the
    super-user password is required to get any further.  If you have reset the
    password using FormSet it is possible to login without a password.
    Interesting commands once you have logged in here include the ability to
    format the internal IDE hard drive.
    
    It is unclear if this daynad code is in other Intel or Dayna products.  If
    you are the owner of other similar products it is suggested that you examine
    all services running on their machines.
    
    Timeline
    --------
    12/14/1999	Reported security hole to Intel.  Mr. Lee assured me they
    would look into this right away and call me back.  I never got a call back.
    
    12/20/1999	Called them again.  They insisted that they couldnt help me
    without a serial number.  I didn't have the unit next to me so this proved
    to be a large problem.  After checking with a supervisor I was given case
    #862463.
    
    12/21/1999	Received a call back from their engineering department
    stating that they understand the problem, but do not believe it is severe
    enough to warrant a fix.  They may correct the problem in a later software
    release.
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:26:05 PDT