[Fwd: [netops] Fwd: [Full-disclosure] [FIXED] Remote Denial of Service for SSH service at Dell DRAC4 (maybe Mocana SSH)]

Sat Jan 19 13:18:22 CST 2008

FYI from full-disclosure.

~BAS

-------- Forwarded Message --------
 Service for SSH service at Dell DRAC4 (maybe Mocana SSH)
Date: Sat, 19 Jan 2008 14:13:10 -0500

>---------- Forwarded message ----------
>From: Robert Scheck <<mailto:scheck at etes.de>scheck at etes.de>
>Date: Jan 18, 2008 6:04 AM
>Subject: [Full-disclosure] [FIXED] Remote Denial 
>of Service for SSH service at Dell DRAC4 (maybe Mocana SSH)
>To: Full-Disclosure 
><<mailto:full-disclosure at lists.grok.org.uk>full-disclosure at lists.grok.org.uk>
>
>Remote Denial of Service for SSH service at Dell DRAC4 (maybe Mocana SSH)
>ETES GmbH Security Advisory; August 13, 2007 - updated January 18, 2007
>
>
>BACKGROUND
>==========
>
>Dell Remote Access Card 4 (DRAC4) allows customers to effectively manage
>servers in remote locations where no administrative IT staff exists. It
>provides lights out management with continuous video that provides a
>graphical console regardless of the server's state and requires no
>operating system services or drivers. Virtual media support provides the
>server access to networked CD, floppy, and USB drives for server
>installation and updates (origin: Dell USA). The remote management is
>possible e.g. via web interface or via the provided integrated SSH daemon
>(running at port 22/TCP) based on Mocana SSH.
>
>
>DESCRIPTION
>===========
>
>Remote Denial of Service for the SSH service provided by the integrated SSH
>daemon is possible by the use of nmap-4.03-3 from Debian unstable, which is
>also included in Ubuntu Depper. Please note, that this vulnerability can't
>be reproduced with every nmap version, e.g. nmap-4.20 didn't work. After
>the use of such a port scanner, the SSH port is unavailable and can only be
>made available again by the use of the Dell utility "racadm" which causes a
>hard reboot of the whole system.
>
>As there is another issue when having the DRAC4 virtual drives enabled, a
>second reboot needs to be performed manually, otherwise a SuSE Linux
>Enterprise Server 10 (SLES 10) with and without Service Pack 1 (SP1) will
>not boot up correctly and will end with lots of segmentation faults, I/O
>errors and so on. Please note, that the remote Denial of Service does not
>depend on the operating system used on the server.
>
>
>ANALYSIS
>========
>
>There is NO exploitation which would allow unauthenticated remote attackers
>to gain root access. An affected machine has at least an unavailable SSH
>port at DRAC4, the web interface is working anyway, and in order to get SSH
>access at the DRAC4 back, one or multiple reboots are necessary.
>
>As the provided feature to access DRAC4 by SSH is very useful and enabled
>per default, it is easy to attack machines and use this vulnerability for
>remote Denial of Service.
>
>Presumably any "Dell Remote Access Controller 4/P (DRAC 4/P)" including
>"Firmware Version 1.50 (Build 02.16)" is affected by this vulnerability. At
>least, the problem is reproducable with version 1.50 (Build 02.16).
>
>
>REPRODUCABILITY
>===============
>
>Further information regarding the use of nmap and the port scan are below.
>A normal port scan of the management IPv4 address of DRAC4 should look like
>this (the output below is a bit trunicated for better readability):
>
>$ nmap -sV [Management IPv4 address of DRAC4]
>
>Starting Nmap 4.20 ( 
><http://insecure.org>http://insecure.org ) at 2007-07-09 14:54 CEST
>Interesting ports on xxx.xxx.xxx.xxx:
>Not shown: 1693 closed ports
>PORT     STATE SERVICE  VERSION
>22/tcp   open  ssh      Mocanada embedded SSH (protocol 2.0)
>80/tcp   open  http     Dell Embedded Remote Access card webserver 1.0
>443/tcp  open  ssl/http Dell Remote Access Controller http interface 2.0
>5900/tcp open  vnc?
>Service Info: Devices: terminal server, remote management
>
>Nmap finished: 1 IP address (1 host up) scanned in 21.559 seconds
>$
>
>To bring the SSH daemon running at the DRAC4 down, the following command
>can be used in combination with the already described nmap version:
>
>$ nmap -O [Management IPv4 address of DRAC4]
>Starting Nmap 4.03 ( 
><http://www.insecure.org/nmap/>http://www.insecure.org/nmap/ 
>) at 2007-07-09 14:55
>CEST
>Insufficient responses for TCP sequencing (0), OS detection may be less
>accurate
>Insufficient responses for TCP sequencing (0), OS detection may be less
>accurate
>Insufficient responses for TCP sequencing (0), OS detection may be less
>accurate
>Interesting ports on xxx.xxx.xxx.xxx:
>(The 1670 ports scanned but not shown below are in state: closed)
>PORT     STATE SERVICE
>22/tcp   open  ssh
>80/tcp   open  http
>443/tcp  open  https
>5900/tcp open  vnc
>No exact OS matches for host (If you know what OS is running on it, see
><http://www.insecure.org/cgi-bin/nmap-submit.cgi>http://www.insecure.org/cgi-bin/nmap-submit.cgi).
>
>Nmap finished: 1 IP address (1 host up) scanned in 65.943 seconds
>$
>
>Now the SSH port is unavailable, a SSH connection establishment e.g. by
>OpenSSH client will time out, another port scan shows more details:
>
>$ nmap -sV [Management IPv4 address of DRAC4]
>
>Starting Nmap 4.20 ( 
><http://insecure.org>http://insecure.org ) at 2007-07-09 14:56 CEST
>Interesting ports on xxx.xxx.xxx.xxx:
>Not shown: 1693 closed ports
>PORT     STATE    SERVICE  VERSION
>22/tcp   filtered ssh
>80/tcp   open     http     Dell Embedded Remote Access card webserver 1.0
>443/tcp  open     ssl/http Dell Remote Access Controller http interface 2.0
>5900/tcp open     vnc?
>Service Info: Devices: terminal server, remote management
>
>Nmap finished: 1 IP address (1 host up) scanned in 21.378 seconds
>$
>
>In order to get SSH access back, "racadm racreset" has to be executed,
>maybe further parameters are needed. More information regarding this can be
>taken from the Dell Remote Access Controller Racadm User's Guide.
>
>
>WORKAROUND
>==========
>
>If not available, a firewall should be set up to restrict the network
>access to trusted networks only. This rule should be applied especially for
>the default SSH port (port 22/TCP). Since there is a new firmware available
>solving this problem, an update is highly recommented as well.
>
>
>SOLUTION
>========
>
>On October 31, 2007 the "Firmware Version 1.60 (Build 10.04)" for "Dell
>Remote Access Controller 4" (DRAC 4/I and DRAC 4/P) was released to solve
>this vulnerability. An upgrade to this new version is highly recommented,
>but the whole DRAC4 configuration and settings have to be saved before, as
>a firmware update causes a loss of any DRAC4 specific settings. And for us,
>multiple firmware updates (EPROM flashings) failed during the upgrade; the
>only working one was the offline update using two floppy disks.
>
>In the README file 
><<ftp://ftp.us.dell.com/sysman/readme_160_A00.txt>ftp://ftp.us.dell.com/sysman/readme_160_A00.txt>, 
>the
>correction of this issue is mentioned with "Added fix for Remote Denial of
>Service for SSH service", but no reference to this advisory.
>
>
>CVE INFORMATION
>===============
>
>The MITRE Corporation Common Vulnerabilities and Exposures (CVE) number
>CVE-2007-4360 was assigned on August 15, 2007. Currently, the following
>other identifications are known for this issue:
>
>CVE-2007-4360 
><<http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4360>http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4360>
>Secunia SA26428 < 
><http://www.secunia.com/advisories/26428>http://www.secunia.com/advisories/26428>
>FrSIRT/ADV-2007-2908 
><<http://www.frsirt.com/english/advisories/2007/2908>http://www.frsirt.com/english/advisories/2007/2908  
> >
>SecurityFocus BID-25291 
><<http://www.securityfocus.com/bid/25291>http://www.securityfocus.com/bid/25291>
>ISS X-Force 35998 
><<http://xforce.iss.net/xforce/xfdb/35998>http://xforce.iss.net/xforce/xfdb/35998  
> >
>
>
>DISCLOSURE TIMELINE
>===================
>
>2007-07-09 Initial vendor notification
>2007-07-11 Initial vendor response
>2007-07-16 Vendor communicated escalation to engineering
>2007-07-23 Vendor communicated the reproducibility
>2007-08-03 Vendor communicated the working for a solution
>2007-08-13 Vendor communicated an unknown timeframe
>2007-08-13 Coordinated public disclosure
>2007-10-31 Vendor released firmware update version 1.60
>2007-11-20 Vendor officially announced the new firmware
>2008-01-10 Verified the new firmware for reproducibility
>2008-01-18 Coordinated public advisory update
>
>
>CREDIT
>======
>
>This vulnerability was discovered by the ETES 
>GmbH < <http://www.etes.de>http://www.etes.de>.
>
>
>LEGAL NOTICES
>=============
>
>Copyright © 2007-2008 ETES GmbH 
><<http://www.etes.de>http://www.etes.de>, referenced text
>belongs to its owner(s).
>
>Disclaimer: The information in the advisory is believed to be accurate
>at the time of publishing based on currently available information. Use
>of the information constitutes acceptance for use in an AS IS condition.
>There are no warranties with regard to this information. Neither the author
>nor the publisher accepts any liability for any direct, indirect, or
>consequential loss or damage arising from use of, or reliance on, this
>information.
>
>
>With kind regards
>
>Robert Scheck
>
>--
>Robert Scheck
>Web: 
><http://www.etes.de>http://www.etes.de 
>E-Mail: <mailto:scheck at etes.de>scheck at etes.de
>ETES GmbH  Libanonstrasse 58 A  D-70184 Stuttgart
>Fon: +49 (7 11) 48 90 83 - 12   Fax: +49 (7 11) 48 90 83 - 50
>
>Registergericht: Amtsgericht Stuttgart HRB 721182
>Geschäftsführende Gesellschafter: Markus Espenhain und Jan Theofel
>Sitz der Gesellschaft: Stuttgart
>USt.-Id.Nr.: DE814767446
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: 
><http://lists.grok.org.uk/full-disclosure-charter.html>http://lists.grok.org.uk/full-disclosure-charter.html
>Hosted and sponsored by Secunia - <http://secunia.com/>http://secunia.com/
>
>