Kritieke kwetsbaarheden treffen 'miljoenen' Aruba- en Avaya-switches

Onderzoekers hebben vijf kritieke kwetsbaarheden in een TLS-bibliotheek aangetroffen die misbruik van switches van Aruba en Avaya mogelijk maken. Kwaadwillenden kunnen ongepatchte switches misbruiken voor het stelen van data.

De oorzaak van de vijf kwetsbaarheden ligt bij bugs in NanoSSL. Volgens beveiligingsbedrijf Armis, dat de kwetsbaarheden vond, maken zo'n tien miljoen netwerkapparaten van HPE's Aruba en Extreme Networks Avaya gebruik van deze TLS-bibliotheek van ontwikkelaar Mocana, een dochterbedrijf van DigiCert.

Armis heeft de bundel kwetsbaarheden TLStorm 2.0 genoemd. De publicatie volgt dan ook op die van TLStorm, een set van drie kwetsbaarheden die Armis in maart bekendmaakte. Ook bij die kwetsbaarheden ging het om bugs in NanoSSL. Daarmee waren Smart-UPS-voedingen voor de enterprisemarkt van APC over te nemen.

Volgens Armis kunnen aanvallers met de TLSorm 2.0-kwetsbaarheden bijvoorbeeld de portal van switches omzeilen en op afstand code uitvoeren om toegang tot bedrijfsnetwerken te verkrijgen. Ook noemt het bedrijf een scenario waarbij aanvallers via de switch vanaf het virtuele gastnetwerk kunnen inbreken op het bedrijfs-vlan. Aruba en Avaya hebben patches voor getroffen producten uitgebracht. Armis is niet bekend met misbruik in de praktijk.

Aruba Avaya
Aruba 5400R Series ERS3500 Series
Aruba 3810 Series ERS3600 Series
Aruba 2920 Series ERS4900 Series
Aruba 2930F Series ERS5900 Series
Aruba 2930M Series
Aruba 2530 Series
Aruba 2540 Series

Aruba Switches

Door Olaf van Miltenburg

Nieuwscoördinator

03-05-2022 • 14:36

45

Reacties (45)

Sorteer op:

Weergave:

Eindelijk:

Workaround
==========
Aruba recommends implementing firewall controls to limit interactions of
impacted switches with known good RADIUS sources.

Kortom blokkeer RADIUS en je bent "veilig" voor deze CVE's.

Verder:
Heap Overflow Vulnerabilities in RADIUS EAP Messages
(CVE-2022-23676)
Resolution:
- ArubaOS-Switch 15.16.xxxx: Version still pending.
This advisory will be updated.
- ArubaOS-Switch 16.02.xxxx: K.16.02.0034 and above.
- ArubaOS-Switch 16.04.xxxx: Version still pending.
This advisory will be updated.
- ArubaOS-Switch 16.08.xxxx: KB/WB/WC/YA/YB/YC.16.08.0025 and above.
- ArubaOS-Switch 16.09.xxxx: KB/WB/WC/YA/YB/YC.16.09.0020 and above.
- ArubaOS-Switch 16.10.xxxx: KB/WB/WC/YA/YB/YC.16.10.0020 and above.
- ArubaOS-Switch 16.11.xxxx: KB/WB/WC/YA/YB/YC.16.11.0004 and above.

Heap Overflow Vulnerabilities in Mocana Cryptographic Library
(CVE-2022-23677)
Resolution:
The firmware versions that address the vulnerabilities related to
CVE-2022-23677 are still pending. This advisory will be updated.

Kortom voor CVE-2022-23677 is nog geen fix. Voor de CVE-2022-23676 wel voor een aantal van de firmwares

Bron: https://www.arubanetworks...rt/ARUBA-PSA-2022-008.txt

Nu ook HPE:
https://support.hpe.com/h...id=17734&elq_cid=95220784

En nu de volgende...:
https://www.arubanetworks...rt/ARUBA-PSA-2022-009.txt

[Reactie gewijzigd door bazzi op 23 juli 2024 16:59]

Alleen is het lastig om RADIUS te elimineren wanneer je 802.1X gebruikt voor authenticatie op de switch, hiervoor gebruik je nagenoeg altijd RADIUS om de endpoints te authenticeren met de centrale authenticate server (zoals ClearPass)
Check, gelukkig hier niet het geval. Dan vooral firewall regels en acl heel strak zetten.
Aruba en Avaya hebben patches voor getroffen producten uitgebracht.
We hebben een aantal Aruba 2540 switches die volgens het lijstje kwetsbaar zijn. Helaas is de nieuwste firmware update van deze switch 16.11.0004 van 31 maart. Waar halen we de nieuwste versie vandaan die de kwetsbaarheid niet meer heeft?
Ik denk dat het slecht begrepen en gekopieerd is uit het origineel artikel, iedereen verwijst voor patches naar de support portal van Aruba, dat wilt nog niet zeggen dat er al een patch is jammer genoeg.. In de support portal is het laatste security bericht van vorige maand.
is het niet zo dat als je het captive portal en management interface gebruikt (maar bv alleen ssh om te managen) + geen radius je niet vatbaar bent? Of lees ik het nou verkeerd bij armis?

Want als dat het geval is, geeft een hoop lucht met nieuwe versies uit te rollen in de omgevingen ;-)

[Reactie gewijzigd door bazzi op 23 juli 2024 16:59]

Dit bericht van NCSC geeft uitleg over de lekken en wanneer je daar vatbaar voor bent.
M.i. Is het risico inderdaad laag als er geen connectie is tussen switch en RADIUS server. Verder uitsluitend management via ssh en de andere management services disabled zijn. Uiteraard management in een apart vlan en alleen bereikbaar vanuit een (IT) management vlan.

Idealiter werk je dan ook nog via ACL’s op de switches.

Als mijn aanname juist is het voor mij nodig om maar enkele switches direct te updaten en kunnen de overigen via een maintenance window. :)
ja maar vind het een beetje suf dat het daar nog niet wordt genoemd.... Is niet of ze niet wisten dat het gepubliceerd werd...
Volgens Bleeping Computer is het drie maanden geleden aan Aruba gemeld en zou 'het meeste' gepatched zijn, dus de patch van 31 maart?
Raar verhaal toch:
Armis informed Aruba and Avaya about the TLStorm 2.0 vulnerabilities three months ago, and collaborated with them on a technical level.

The threat analysts told BleepingComputer that affected customers have been notified, and patches that address most of the vulnerabilities have been issued.
Ik heb klanten met een hoop van die switches en wij weten van niets, je kan het ook niet opvolgen want de CVE nummers zijn nu pas aangemaakt gezien ze nu pas uitgebracht zijn en deze dus ook nergens te vinden zijn bij de vorige patches van Aruba dus je kan het ook niet controleren of ze nu gepatched zijn of niet. Momenteel ook nog geen enkele reactie of bulletin van Aruba. Dat kon toch beter op elkaar afgestemd worden.
CVE-nummers kunnen ook uitgegeven worden voordat er patches zijn. Zo kan een fabrikant dus eerst het probleem erkennen, om het op te lossen met verwijzing naar dat nummer, en dan gelijk met de oplossing of iets later de inhoud bekend te maken.

Als je fabrikant dus niet gecommuniceerd lijkt te hebben, of zelfs nog geen oplossing heeft, dan kan je die maar beter snel om opheldering vragen. Je betaald waarschijnlijk niet voor niets voor ondersteuning en dus oplossingen die op tijd zijn.
Ja al van gisterenavond gezien maar zelf daar staat dat er nog geen patches zijn..

The firmware versions that address the vulnerabilities related to
CVE-2022-23677 are still pending. This advisory will be updated.
Wij zitten op versie 16.11.0004 die eind maart is uitgekomen, vatbaar is versie 0003 en lager.

[Reactie gewijzigd door Octopuz op 23 juli 2024 16:59]

Dat is voor CVE-2022-23676 het geval maar niet voor die andere, CVE-2022-23677, daar staat expliciet bij:

The firmware versions that address the vulnerabilities related to CVE-2022-23677 are still pending. This advisory will be updated.

Maar dan helemaal bovenaan bij de inleiding staat dat 16.11.003 en lager alleen maar geïmpacteerd is. Toch niet duidelijk eh?
Ja dat. Daaruit concludeerde ik dat je niet vatbaar bent voor een van de lekken als je op een hogere versie zit. Wat op zich ook begrijpelijk zou zijn omdat Aruba hiervan al drie maanden op de hoogte is.
Het zijn inderdaad 2 CVE's waarvan maar een(1) al een patch beschikbaar is gesteld op 26, 28 en 30 april. Patches kan je downloaden via de Aruba support pagina (ASP), anders via je leverancier/beheer partij.

CVE-2022-23676 - Heap Overflow Vulnerabilities in RADIUS EAP Messages
Resolution:
- ArubaOS-Switch 15.16.xxxx: Version still pending.
This advisory will be updated.
- ArubaOS-Switch 16.02.xxxx: K.16.02.0034 and above.
- ArubaOS-Switch 16.04.xxxx: Version still pending.
This advisory will be updated.
- ArubaOS-Switch 16.08.xxxx: KB/WB/WC/YA/YB/YC.16.08.0025 and above.
- ArubaOS-Switch 16.09.xxxx: KB/WB/WC/YA/YB/YC.16.09.0020 and above.
- ArubaOS-Switch 16.10.xxxx: KB/WB/WC/YA/YB/YC.16.10.0020 and above.
- ArubaOS-Switch 16.11.xxxx: KB/WB/WC/YA/YB/YC.16.11.0004 and above.

CVE-2022-23677 - Heap Overflow Vulnerabilities in Mocana Cryptographic Library
Resolution:
The firmware versions that address the vulnerabilities related to
CVE-2022-23677 are still pending. This advisory will be updated.

Via ACL's / Firewall policies kan je inderdaad RADIUS(802.1X) verkeer uit sluiten waar het nodig is. Dit zal per situatie / klant / omgeving weer anders zijn, dus hou hier rekening mee. Mocht je gebruik maken van o.a. ClearPass Policy Manager i.c.m. 802.1X wired-authenticatie heb je wel iets meer een uitdaging.
Door contact op te nemen met je leverancier die je voor support betaald (hebt).
Volgens Armis kunnen aanvallers met de TLSorm 2.0-kwetsbaarheden bijvoorbeeld de portal van switches omzeilen en op afstand code uitvoeren om toegang tot bedrijfsnetwerken te verkrijgen.
Dus in principe als je de portal van de switches niet openbaar hebt lijkt het risico al een stuk kleiner.

Bij een goed security beleid zouden ze ook niet zomaar open staan lijkt me. Switches zijn vaak niet het entry point van buiten af.

[Reactie gewijzigd door Koen Hendriks op 23 juli 2024 16:59]

Waarom zou je dit naar buiten toe open zetten, of gaat het hierbij om zo'n "handige" dienst vd. leverancier, waarbij je vast zit aan een abonnement? Beheer-interfaces mogen never nooit niet naar buiten toe open staan, tenzij je een aantal beveiligingslagen gebruikt...
Beheer-interfaces mogen never nooit niet naar buiten toe open staan, tenzij je een aantal beveiligingslagen gebruikt...
Altijd binnen je eigen domein houden. Niet soms, niet af en toe, maar altijd. Veel lagen om naar binnen te komen. Tunnelen, 2FA met token, opstapserver en dan pas kan je wat.

[Reactie gewijzigd door Houtenklaas op 23 juli 2024 16:59]

Precies dat bedoelde ik dus met een "aantal beveiligingslagen".
Al deze switches kunnen opgenomen worden in het Aruba Central platform. Soort van Cisco meraki van HPE zeg maar. Dus dat kan inderdaad een reden zijn. Als je dit aan hebt staan ga je er natuurlijk vanuit dat dit veilig is...
Als je dit aan hebt staan ga je er natuurlijk vanuit dat dit veilig is...
Zeer gevaarlijke aanname! Zo zet ik ook altijd mijn vraagtekens bij monitoring software & helaas is mijn vrees al 2x bevestigd (Kaseya/Solarwinds).
Eens! Vandaar ook de meerdere punten aan het einde van die zin. ;)

[Reactie gewijzigd door graunie op 23 juli 2024 16:59]

Wow post ook eens iets.

[Reactie gewijzigd door Peter F op 23 juli 2024 16:59]

Lijkt mij dat dit niet een handige bericht is tot de switches gepatched zijn 8)7
Naah, we hebben toch allemaal de management interface van onze switches alleen beschikbaar gemaakt in het, verder volledig afgeschermde, management netwerk? :+
Dat is wel te hopen voor de W******* idd. Maar dan alsnog, dat klinkt niet als een omgeving waar fysieke security overal mogelijk is, dus dan is OpSec nog steeds belangrijk...
Edit: en natuurlijk, OpSec is altijd belangrijk ;)

[Reactie gewijzigd door Loen op 23 juli 2024 16:59]

Daarom post ik nooit onder mijn eigen naam. Zo'n opmerking als @Peter F doet, is zo gemaakt. En zelfs zo'n alias is niet voldoende, met een beetje onderzoek kom je er ook wel achter wie ik ben.

Social media (waar Tweakers in principe ook onder valt) is helaas tegenwoordig ook onderhevig aan opsec. Niet eens alleen voor IT mensen. In onze jaarlijkse cybersecurity training hameren we hier dan ook dik op. LinkedIn is bijna een menukaart geworden voor aanvallers zodat ze hun phishing aanvallen precies kunnen richten op de afdeling die ze zoeken.

De 'real name policy' van bepaalde netwerken zoals Facebook en LinkedIn helpt enorm mee met dit probleem. Helaas is met name LinkedIn moeilijk te voorkomen als professional en met een nep naam heb je er ook helemaal niks aan.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 16:59]

En zelfs zo'n alias is niet voldoende, met een beetje onderzoek kom je er ook wel achter wie ik ben.
Moet zeggen, even geprobeerd maar het valt nog best tegen :+
Is bami met goede satesaus en pizza nog steeds je lievelingseten? :+
Haha, staat die site nog steeds op archive.org?? Ik dacht dat ik hem er af had gehaald via robots.txt. Goed gevonden!
Staat toch in het artikel dat het ook via een afgeschermd gasten netwerk mogelijk is om andere VLANs te benaderen.
Of is dat alleen maar als er een captive portal draait op diezelfde switches?
Gelukkig kun je niet via 2 clicks uitvinden waar hij werkt :X
dat kan dus letterlijk wel. zonder te zeggen hoe, adviseer ik de OP om zijn post te verwijderen. OP: ik DM je ff.
Je bent nu zelf een beveiligingslek...
Tsja, vrijwel iedereen die reageert op dit soort berichten over nogal specifieke hardware is als je het zo bekijkt een beveiligingslek.
Zijn ze niet automatisch te provisioneren? Of moet je echt naar elke switch lopen of er op inloggen?

[Reactie gewijzigd door stuiterveer op 23 juli 2024 16:59]

Vwb Aruba lijkt dat heel simpel te kunnen middels 2 ansible tasks; 1 om het image te uploaden (arubaoss_file_transfer), en 1 om te rebooten naar dit image (arubaoss_reboot). Ik neem aan dat de config dan bewaard blijft, al zou een beetje beheerder die config ook netjes in Ansible (of een andere automation tool) hebben hangen.
Je hebt inderdaad aantal mogelijkheden om dit op te pakken;
1. Mocht je te veel tijd over hebben, dan kun je inderdaad elke switch er op inloggen en handmatig firmware uploaden en vervolgens reboot naar de juiste partitie.
2. Mocht je een beheer tool hebben, bijv. Aruba AirWave of Aruba Central, dan kan je vanuit de tool dit pushen.
3. Er zijn inderdaad Ansible / python scripts(Automation) beschikbaar gesteld voor Aruba producten.

Natuurlijk zijn ook andere opties beschikbaar, maar dit zie je vaak in praktijk terugkomen.
Ik denk dat ik maar eens een weekje vakantie neem, pak een maand voor het zekerste :'(
8)7 Tegenwoordig kun je dan beter met pensioen :9

Op dit item kan niet meer gereageerd worden.