cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2658
Views
8
Helpful
8
Replies

Cisco WLC Device Certificate Weak Hash

O_H
Level 1
Level 1

Hello,

 

We have Cisco 2504 WLC with 8.5.182.0 AireOS version. The security scan tool reports that the device certificate of the WLC is signed using weak hashing algorithm (SHA-1). I tried a different software version, but still reported. I believe this is related to opensssl vulnerability CVE-2016-2183  and bug CSCvb48603. That's why i tried a different software version, but still. See attachment.

Bug: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvb48603
Vulnerability: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160927-openssl

8 Replies 8

Hi

 Device certificate shouldn´t be signed by the WLC. Certificate should be signed by a Certifier and validated againt an 802.1x server.

 If you are mentioning  Encryption, them you need to use WPA2 only.

Rich R
VIP
VIP

Nothing to do with that bug or advisory.  It's not a vulnerability - it's by design.  SHA-1 was used as standard before.  Newer products may use newer hash.

2504 is effectively end of life - refer to https://www.cisco.com/c/en/us/products/collateral/wireless/2504-wireless-controller/eos-eol-notice-c51-740645.html

If you need a product which supports current standards you need to migrate to current technology - 9800 series WLC.

And if you're not using anything that needs NMSP on TCP 16113 (Prime/MSE/CMX for example) then use a CPU ACL to block all access to it.

Also see previous discussions about this which you should have searched for before posting:

https://community.cisco.com/t5/wireless/ssl-certificate-signed-using-weak-hashing-algorithm-cisco-wlc/td-p/4151786

https://community.cisco.com/t5/wireless/close-management-ports-on-wireless-controller/td-p/2921270

 

It's openssl vulnerability and related to the bug i posted, and yes it is because of SHA-1. And i have already searched these 2 forums that you send, and you will find my comment in the first one which didn't provide a solution. You don't have to be aggressive btw. Thanks anyway.

Rich R
VIP
VIP

I have to disagree - not one of those CVE is about using a SHA-1 hash in a self-signed cert.  Like MD5, SHA-1 has been superseded because of increasing computing power.  All those CVE are already fixed in your code release through CSCvb48603 so that's how you can tell they are not related - if they were it would be fixed already.

Apologies if you think I'm being aggressive but what you're asking for amounts to a feature enhancement on a product which is long past end of sale, and most of the following milestones, and nearly at total end of support.  We all know that features and functionality don't get updated in old products - so it's expected that you will encounter these sorts of issues when you keep running equipment beyond those dates.  We all do it sometimes but you then have to accept the risk that that entails.

If you need to mitigate it then you ensure (through firewall) that only authorised, trusted devices can connect to that port on the WLC or you use CPU ACL to block all traffic on that port. Ultimately you have to conduct an intelligent risk assessment of these pen-test findings and mitigate as appropriate to your environment.  If the security folks don't accept that then your only option is new kit and somebody has to find the budget for that.  That's when they will sometimes reconsider reasonable mitigations.

From where you say that these vulnerabilities are fixed in my release?
The bug says these are the known fixed releases:
8.4.100.0, 8.3.111.0, 8.2.151.0, 8.0.150.0.
The bug modification date is Dec 06 2021. And that's why i find it weird that no newer releases are listed in the fix list. And that's why i'm asking here. No clear info if this is fixed in my release or no. Do you have a reference?

Rich R
VIP
VIP

Bug tool seems to be down at the moment so I can't check but as I recall:

- 8.5 is not listed as an affected release

- You would expect that 8.5 would have inherited the fix from 8.4.100.0 (19-04-2017) in 8.5.103.0 (25-07-2017) because PSIRT fixes are automatically integrated in any later major software released after the advisory (Cisco standard process).  All subsequent rebuild (dot) releases would inherit the fix from there.

- Recently Cisco try to list all those individual subsequent releases as fixed on bug tool (which makes very long lists) to show those which inherited the fix by default but they didn't used to do that - you were expected to understand that a fix in 4.x meant it was fixed in new major release 5.x which came out after that and a fix in 5.1 meant it was fixed in 5.2.

 

O_H
Level 1
Level 1

No i disagree... i've seen myself that sometimes bugs are not fixed in the major release. Also, sometimes bugs not updated, and sometimes even bugs are not published yet. So, that's not necessarily true.

Rich R
VIP
VIP

You asked for an explanation - I've given it - and you are of course free to disagree.

If you want a definitive answer then open a TAC case and ask TAC.

Be aware that they might refuse to assist because of the product EOL status.

 

Review Cisco Networking for a $25 gift card