02-03-2022 01:42 AM
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
02-03-2022 04:12 AM
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.
02-03-2022 05:42 AM
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/close-management-ports-on-wireless-controller/td-p/2921270
02-03-2022 06:49 AM - edited 02-03-2022 07:34 AM
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.
02-03-2022 07:59 AM - edited 02-03-2022 08:00 AM
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.
02-04-2022 12:15 AM
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?
02-04-2022 12:43 AM
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.
02-04-2022 01:01 AM
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.
02-04-2022 01:29 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide