Vulnerability

    Breeze Network Server

Affected

    Breeze Network Server

Description

    Stany found following.  A Breeze Network Server is a NetBSD  1.3.2
    based system produced  by WindDance Networks  Corporation.  It  is
    marketed as an email,  fax, printer, internet/intranet web  server
    and a firewall.  Physically it is an AMD K6/300 AFR system with 64
    megs of RAM and  6 Gig IDE hard  drive.  It includes  a LS120 disk
    drive  as  the  primary  floppy   drive,  and  according  to   the
    documentation that drive is  used for distributing updates  to the
    system.  The system  is marketed to be  easy in use ("so  even the
    secretary  would  not  have  any  problems  to set up Breeze in 15
    minutes") and upon receiving it  one has to connect up  a keyboard
    and  a  monitor  to  it,  power  it on, answer a few configuration
    questions  (What  is  my  ip?   What  is  my  gateway?  What is my
    subnet?) and  then one  should be  able to  access it  with a  web
    browser and be  able to modify  all sorts of  things - add  users,
    back up the system, set  up filesharing etc.  Following  that, the
    keyboard and a screen are no longer needed.

    After booted it into single user mode, it will provide you with a
    root shell, so you may remount / read-write and look around.  gcc
    is installed.  This seems to be a first mistake - one doesn't
    install a compiler on a production system, especially on a secure
    one, as it makes it so much easier to compile a sniffer and cause
    more harm.

    First thing you'll notice once the system is running in  multiuser
    mode is that apache is runing as root.  The CGI scripts do not use
    any range checking nor sanity  checks what so ever.   A particular
    script should attracted you attention:

        root@wdbreeze:/usr/local/breeze/cgi-bin[24]# tail -3 configbreeze

        &rebootnow;
        exit 0;
        root@wdbreeze:/usr/local/breeze/cgi-bin[25]#

    Ugh.  Is that not beautiful?  That's right, *anyone* accessing

        http://BreezenetworkserverIP/start/configbreeze

    is greeted with "Internal Server Error" message, while the  system
    reboots  itself.   It  is  interesting  how  the reboot is done as
    well:  the script creates a file /tmp/reboot.now, and writes "Rest
    in Peace\n" into it.  A daemon /usr/local/breeze/bin/rebootwrapper
    checks (a cursory strings  on rebootwrapper shows that  the daemon
    is also  checking for  /tmp/halt.now).   If that  file exists, the
    contents of the file are checked against an internal lookup table,
    and then the system  reboots itself through calling  /sbin/reboot.
    Stany has done  a few tests  and another beautiful  peecularity of
    the  system  came  to  light  as  well:  if  one  creates an empty
    /tmp/reboot.now:

        root@wdbreeze:/[1]# cd /tmp
        root@wdbreeze:/tmp[2]# touch reboot.now

    the system doesn't reboot.  No,  it just locks up, and closes  all
    network  ports,  which  is  deadly  for  a system that should be a
    primary  network  gateway/firewall  for  a  small  business.   The
    behavior is  very similar  to halting  the system,  but the screen
    doesn't show the typical shutdown notices, and the last shows that
    the system was rebooted and not  crashed.  Oh, and the hard  drive
    gets  fscked  on  startup.   So,  if  you  were a malicious script
    kiddie,  who  have  managed  to  obtain  any  sort of login on the
    system, all you  had to do  is set up  a simple cron  job to touch
    /tmp/reboot.now every five  or so minutes  and laughing.   It will
    take  a  good  long  while  for  someone  to  think about checking
    crontab on a system that  all of a sudden started  malfunctioning.
    With the amount  of ports running  on that system  some exploit is
    bound to appear at some point that will allow you to get a  remote
    login, or just add another line to root crontab.

Solution

    Update expected.  Beta release image is available.