OpenSSH v4 vulnerabilities in 4400 WLC (WiSM)

Hi,
I recently did a vulnerability scan of a 4400 (4404) series wireless LAN controller running 7.0.116.0 and it showed SSH running on port 22 of the management interface. The problem I have is that the vulernability scanner (Nessus) showed the version to be OpenSSH 4.0 according to the SSH banner. Based on this version it has highlighed a large number of potential vulnerabilities including denial of service and privilege escalation issues. I've researched each of these vulnerabilities and they do indeed affect this version of OpenSSH and some of them are quite serious. However, I can find absolutely no reference on the web to this device (or indeed any Cisco device) being vulnerable to these OpenSSH bugs. I can find references to other SSH bugs but these are not the same ones that appear to affect OpenSSH 4.0 and the version of software on the device is not vulnerable to those other ones. I would have imagined with both the popularity of the device and of the vulnerabilitiy scanner that someone would have encountered this before. I'm starting to think now that this is a false positive on the scanner's part or else that Cisco fixes these bugs individually without upgrading the version of OpenSSH in the banner and so it is not affected - but I would have thought there would still be reference to these somewhere online. I'd appreciate any thoughts anyone would have on this.
Some of the vulnearbilities that the scanner are showing against this version of OpenSSH are as follows:
X11 trusted cookie forwarding issue -> (CVE-2007-4752)
Potential denial of service by crashing ssh service-> (CVE-2006-4925)
Privilege escalation via weak verification of authentication -> (CVE-2006-5794)
DoS by forcing keys to be recreated -> (CVE-2007-0726)
Uncover 32 bits of plain text from arbitrary block of ciphertext -> (CVE-2008-1483)
Hijack X11 session due to binding TCP ports to IPv6 interface instead of IPv4 when IPv4 is in use - CVE-2008-1483
Execute arbitrary commands if a user copies a malicious crafted file via scp -CVE-2008-1483
Execution of commands using weakness in the ForceCommand directive - CVE-2008-1657
Thanks.

Please have a look at CSCsx46691
Symptom:
Several security scanners mistakenly identify Cisco Wireless LAN Controllers as
being affected by multiple OpenSSH related vulnerabilities.
Conditions:
A security scanner that identifies vulnerable software by the banner that is
returned when a connection is made to a services listening port may misidentify
the Cisco Wireless LAN Controller as being vulnerable.  This occurs because the
WLC returns a banner of OpenSSH v4.0.
Workaround:
Ignore the warnings from the scanner software.
Further Problem Description:
The OpenSSH codebase is patched and maintained by Cisco Engineering to address
known security vulnerabilities in OpenSSH version 4.0.  Because the banner
returned by the WLC does not reflect this, security scanners may mistakenly
flag the devices as being vulnerable

Similar Messages

  • Guest tunnel/auto-anchor from 2100 to 4400 WLC

    We’d like to extend our current Guest LAN from a 4400 WLC in our data center to a 2100 WLC located at a remote facility. However, we cannot get the foreign controller to pass traffic to the anchor controller – or so it seems. The catch is that we’re not actually trying to extend the SSID itself to provide wireless access, but instead flub it so that we can provide local wired access tunneled to the Guest LAN on the anchor WLC. I’m not entirely sure if this is possible, because I’ve read that before the EoIP tunnel will come up a guest client must associate to the foreign WLC.
    We’ve followed the instructions we could find that go over setting up this type of scenario, but unfortunately they only cover setting up back-to-back 4400 controllers and as such, some functions described (notably being able to create a Guest LAN) are not possible on the 2100. We haven’t been able to find a clear and concise guide on the scenario we want to set up.
    Here’s some detail:
    Mobility group is up/up between both WLCs. Both WLCs are running 6.0.x code.
    Anchor WLC – 3750G-24WS-S25 (a 4400 WLC w/ integrated 3750G-24)
    Guest LAN WLAN “wired-guest” created; Ingress is “none” and Egress is our existing “dirtnet” – i.e. outside access. The “dirtnet” interface is *not* a Guest LAN interface. Mobility anchor is set as local.
    Remote WLC – WLC2106
    WLAN “wired-guest” created; Interface is “wired” w/ an IP address on the same subnet as the anchor “dirtnet” and associated with port 2. Mobility anchor is set to the anchor WLC and is up/up. I have a laptop connected to port 2 with a statically assigned IP address on the same subnet as “dirtnet.” I am able to ping the local port 2 address, but I can’t ping across the tunnel to the anchor WLC. I also cannot ping the anchor WLC "dirtnet" interface from the foreign WLC’s Ping tool.
    Are we missing something?

    Sean,
    Wired guest access is not supported on WLC2106.
    Reference:
    http://www.cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a00808ed026.shtml#configs
    Please consider using a WISM, WLC4400, 3750 integrated WLC or a WLC5500

  • Wanted to Know more about cisco 4400 WLC

    is cisco 4400 WLC support third party access points or not
    i have coral-maksat.

    Hi Tahseen,
    Not at this point in time. But this type of 3rd party support will be added in the future;
    In controller software release 5.2 or later, Cisco lightweight access points use the IETF standard Control and Provisioning of Wireless Access Points protocol (CAPWAP) in order to communicate between the controller and other lightweight access points on the network. Controller software releases prior to 5.2 use the Lightweight Access Point Protocol (LWAPP) for these communications.
    CAPWAP, which is based on LWAPP, is a standard, interoperable protocol that enables a controller to manage a collection of wireless access points. CAPWAP is being implemented in controller software release 5.2 for these reasons:
    To provide an upgrade path from Cisco products that use LWAPP to next-generation Cisco products that use CAPWAP
    To manage RFID readers and similar devices
    ***To enable controllers to interoperate with third-party access points in the future
    LWAPP-enabled access points can discover and join a CAPWAP controller, and conversion to a CAPWAP controller is seamless. For example, the controller discovery process and the firmware downloading process when you use CAPWAP are the same as when you use LWAPP. The one exception is for Layer 2 deployments, which are not supported by CAPWAP.
    http://www.cisco.com/en/US/products/ps6366/products_qanda_item09186a008064a991.shtml
    Hope this helps!
    Rob

  • 1140 and 4400 WLC detection issues.

    I am not able to get our 4400 WLC to detect a new AIR-AP1142N-A-K9. (1140 series).
    I have given the interface bvi1 an ip address and subnet mask that the controller should pick up.
    The software version of the 4400 WLC is 7.0.230.0.
    The software version of the AIR-AP1142N-A-K9 is C1140-K9W7-M.
    I am able to connect older AIR-LAP1242AG-A-K9 units without any problem using the LWAPP commands but this unit does not seem to support these commands?

    I obtained the Wireless LAN LWAPP Upgrade and Recovery Image for 1140 Series (c1140-rcvk9w8-tar.124-21a.JA2.tar) and issued the following command:
    "archive download-sw /force-reload /overwrite tftp://TFTPSERVER/c1140-rcvk9w8-mx"
    I receive the following error:
    "%tar checksum error in fd 0 ERROR: Failed to extract from archive file tftp://TFTPSERVER/c1140-rcvk9w8-mx"
    Is this the correct image?

  • 4400 WLC Layer 3 Authentication Status for WLAN Clients

    We have 3 4400 series WLC's(wireless LAN controllers). Two 4404 WLC's are on the "inside" of our network and all AP's (access points) on our network use these two WLC's as the primary or secondary controller.  The 4402 WLC Anchor controller resides in our DMZ and is used for WLANs that are more oriented for guest usage.  These guest WLANs are configured on the inside controllers also, but are "anchored" to the 4402.  On the anchor controller we are using layer 3 Web Authentication for the WLAN "Guest".  This WLAN uses the internal web-auth page within the anchor controller and a username/password combo that is locally defined on the anchor controller.
    Functionally there is no issue.  Users connecting to the WLAN are presented with the web-auth page upon connecting to the WLAN and opening a web browser.  The issue is how the layer 3 authentication information is presented on the Monitor Clients page of the "inside" WLC's management screen as compared to the "anchor" WLC.
    For example, if we log in to the anchor controller and then click Monitor, then Client, then Change Filter and choose any WLAN requiring layer 3 authentication on the Anchor controller, there will be a list of all clients currently associated.  In the Column with the "Auth" heading it shows the Layer 3 Authentication status of the clients.  For example, if there are 15 clients associated to WLAN SSID "Guest", but only 5 of them have opened their web browsers and correctly logged in, then this will be correctly displayed.  The 5 who have logged in will show "Yes" and the other 10 will show "No" in the Auth column.
    Now...the problem...on the inside controllers...if we do the same thing (monitor, clients, filter for WLAN SSID "Guest"), all 15 will show "Yes" under the Auth column. In most cases the 15 clients will be distributed accross both controllers (maybe 6 on one, and 9 on the other WLC), but both inside controllers will display all clients as having a layer 3 authentication status of "Yes".  We have proven over and over that this is not accurate.  This is very inconvenient because the "Client Count" reports we run on the WCS server reflect the same information as the "inside" controllers.  The WSC reports will show all 15 as Authenticated and they are not.  We have proven many times that the anchor WLC is the only controller accuratly conveying this info.
    Also, the engineers who helped with our network install have reproduced the same behavior in a lab with an anchor and inside controller directly connected.  They suggested it may be a code bug with the 4400 series WLC.  We are running controller Software Version 6.0.188.0 on all 3 controllers.
    Please let me know what you think may be causing this issue.  Any help or advice is greatly appreciated!

    Hi,
    We run version 7.0 on the WCS and WLCs but I thought I'd try the report and see what I got. The result is a line graph with the number of associated and authenticated clients superimposed. I'm not sure how useful a report of this nature is.
    It doesn't inspire confidence: when I specifiy the guest wireless SSID I get zero clients! I know there have been guest clients authenticated during the report period I spec'd.
    Scott

  • WLC\WiSM os version mismatch?

    so I know what Cisco recommends but what are the implications of running 6.0.199 on a Guest anchor 4400 and 4.2.209 on the remote controllers? (since for now I'm stuck there because of my 1010 AP's, thx Cisco )  Anyone else running that much of a disparity between WLC's?? Why do I need to do this? Because now Comodo will not issue unchained certs any longer and chained certs are not supported until 5.1.157 or later... Thx.

    Hi,
    There is no problem running 4.2 on Foreign and 6.0.199.4 on Anchor.. here is the link..
    http://www.cisco.com/en/US/docs/wireless/controller/release/notes/crn6_0_199_4.html#wp568458
    Lemme know if this answered ur question and please dont forget to rate the usefull posts!!
    Regards
    Surendra

  • Wildcard Certificats and 4400 WLC

    First, I know the 4400 has been EOS. I am planning on replacing this with a new controller next year as part of a larger project. In the meantime, the certificate we have setup on our guest network is due to expire soon.
    I am pretty familiar with how to get a new certificate setup, but was wondering if anyone has had any experience at using a "wildcard" type certificate, instead of the standard webserver style cert?  (http://www.digicert.com/wildcard-ssl-certificates.htm)
    Its my understanding that a wildcard certificate can be used for any type of server, but the server needs to support it.
    Thanks.

    All my recent install using a 3rd party certificate has been with installing a chained certificate.
    Here is a doc that shows you how to combine a chained certificate and install it on a wlc.
    http://www.cisco.com/en/US/products/ps6366/products_configuration_example09186a0080a77592.shtml
    Sent from Cisco Technical Support iPhone App

  • Cisco 4400 WLC - Accessing web gui remotely

    I know how to access the GUI from the service port. However, I am not able to access from Port 0. IPs have all been properly set. We have a management VLAN in our enterprise. I have configured the WLC management interface for an ip on that subnet. Port 0 is connected to a 3560G switch. I have set the switch port to be an access port to the management vlan and I have tried to set the switch port as a trunk, with the native vlan set to the management vlan. I am not able to ping nor access the web GUI remotely via the management vlan. Is this by design?
    Jeff

    Hi Jeff,
    plz try to configure 0 as vlan on managment interface on WLC after configuring native vlan on the switch. if you havent tried it yet.
    command - config interface vlan management 0
    NOTe - you need to disabl all wlan that r mapped with management interface before doing any changes from CLI.
    hope it will solve your prob.
    Thanks

  • Looking for latest stable Software RLS for 4400 WLC's

    Would like reach out to the group to see what the latest stable version of code for the 4400 series Wireless LAN Controllers.  I currently have several deployed running 5.2.193.
    Alan Brown
    Network Engineer

    Hi Alan,
    the early 6.0s have been deferred quite quickly. It looks that both 6.0.199.4 and 7.0.98 are totally survivable.
    The most stable of all is the 4.2.209 but if you want the new features/APs support, I'd say 6.0.199.4 is the one.
    But this is a personal opinion and each version might contain bugs that you will encounter or not, there's a bit of luck as well :-)
    Nicolas
    ===
    Please rate answers that you find useful

  • Client DHCP issues with 4400 WLC

    Authentication to ACS working okay.
    Clients are unable to obtain an IP from DHCP.
    DHCP server is configured on a dynamic interface but is on a different subnet located in a branch office. DHCP scope is running on a 4500 switch in the branch.
    Is it preferable to have DHCP running on the internal WLC or a DHCP server close to the WLC rather than at the remote location?
    TIA

    Usually you don't want to have a dhcp server on a remote site, but it also should work as long as wired users are able to obtain an IP from the remote dhcp server. Preferred, like I said is to have a local dhcp, but if that doesn't work for you, then configuring the wlc to bbe a dhcp isn't a bad think either. Some like to have more control over the dhcp.

  • WLC/WiSM Configuration Synchronisation with WCS

    Hi Members, can you help me find a way for Configuring only One Controller completely and then synchronising the Other(s) with "One Click", not using the granular Configuration Templates? Regards, Michael

    An easier way would be to upload the binary configuration file from controller 1 to WCS and then push it from WCS to controller 2. At that point, all you need to change (via console) is the IP address.

  • Wism's and WLC 4400 Controllers on V4.2.61.0

    Hi, I've multiple Wism's in 6504 chassis and several 4400 wlc controllers all on ver 4.2.61.0 all in the same mobility group.
    ten in total. Recently we have had to create multiple mobility groups. I've applied access point templates to specify which controller to connect to
    as a primary. For some unknown reason after i've created the separate mobility groups some devices go back to the original hosting controller even though it is now in a different mobility group and the wireless Lan id for the Ap is no longer on the blade/controller the devices attached to the Ap just probes
    Can you please advise if there is anything I can do about this? I've tried pushing a another template to the Ap with it's new controller which reboots the Ap but it still goes back to the original host in the other mobility group.
    Kind Regards,
    Carl

    Hi Carl,
    Your LAPs joins the wrong WLC even when you've configured the primary/secondary controllers name OR IP address and you are using v4.2.61.0.  Is this correct?
    If so, then it's a well-known bug of the v4.x.  Unfortunately, the workaround is CLI.  It's unfortunate because you have to type the command on the WLC and specify the LAP.
    The command is:  config ap controller primary
    This bug has been fixed on the 5.X and 6.X firmware.
    Hope this helps.

  • Migrating AP's from WLC 4400 v.4.0.179.11 to WLC 5508 v.7.2.110.0

    Hi,
    I am replacing an old 4400 series WLC running version 4.0.179.11 to a new 5508 WLC running version 7.2.110.0.
    We currently have 70 x 1131 Access points on the 4400 WLC.
    With this upgrade, do i need to upgrade the old 4400 to version 6.0 so the AP's get an up to date IOS or can i directly migrate all AP's over to the new 5508 without any version incompatabilities on the AP's?
    I am abit worried that the AP's are running a very old IOS on the 4400 v.4.0.179.11 to go straight to the new 5508 v.7.2.110.0.
    Thanks

    Hi,
    Check out this release note
    http://www.cisco.com/en/US/docs/wireless/controller/release/notes/crn7_2_110_0.html#wp976667
    You'll need to get up to a supported version of 6.0 first as per the release notes.
    You'll need to check out the 6.0 release notes too to make sure there are no other intermediate upgrade steps required too.
    Nigel
    Sent from Cisco Technical Support iPad App

  • WLC 4400 and 5500 Fail-over

    Can we do the same thing with WCL 4400 and 5500 series for failover? We have 1 existing 4400 WLC and we wanted to purchase another 1 for fail-over as well as backup. But right now, 4400 is EOL already. The only option is to have the 5500 WLC.
    So if you do have previous set-up like this, so I would need your inputs.. Otherwise, same as usual, will gonna test to work this out.

    You can have both in a primary and backup, but make sure they are on the same code version. I'm assuming that you also have the configuration correct for the two wlc to communicate.
    I would put them both on the 7.0.220.0.
    Sent from Cisco Technical Support iPhone App

  • WLC 4400 and supported APs

    Hello.
    Does anyone know which indoor APs are still sold by Cisco and supported by a 4400 WLC? From my research I only found 3500.
    Thanks in advance,
    João.

    The complete list of APs which can be supported on the 4400 can be found here.

Maybe you are looking for