Cisco waarschuwt klanten voor kritieke zeroday in IOS XE-software

Cisco waarschuwt klanten voor een actief misbruikte kwetsbaarheid in zijn IOS XE-software. De kwetsbaarheid laat hackers adminrechten op apparaten verkrijgen, waarmee ze getroffen routers en switches volledig kunnen overnemen.

Volgens Cisco betreft de kwetsbaarheid een privilege-escalationbug in Cisco IOS XE. De kritieke kwetsbaarheid, die een CVSS-ernstigheidsscore van 10 uit 10 krijgt, heeft alleen invloed op apparaten die de IOS XE-web-UI gebruiken in combinatie met de HTTP of Https Server-functies. De kwetsbaarheid wordt al misbruikt, zegt Cisco. De bug is te volgen onder CVE-2023-20198. De bug werd op 28 september ontdekt na meldingen van 'vreemde activiteiten' op het apparaat van een klant. Volgens Cisco wordt de kwetsbaarheid sinds zeker 18 september actief misbruikt door een onbekende threat actor.

De kwetsbaarheid laat aanvallers op afstand een adminaccount met 'privilege level 15'-toegang aanmaken. Dat is het hoogste toegangsniveau van Cisco-apparatuur, waarmee gebruikers volledige controle krijgen over een router of switch. Vervolgens kan de aanvaller een lokaal account aanmaken. In 'de meeste gevallen' werd daarna een implant geplaatst waarmee willekeurige code uitgevoerd kan worden. Die implant wordt verwijderd bij een systeemreboot, maar het lokale account blijft daarna wel werken en dus kan de implant opnieuw geplaatst worden. Hij wordt geplaatst in usr/binos/conf/nginx-conf/cisco_service.conf en bestaat uit twee strings code.

Aanvallers kunnen de kwetsbaarheid misbruiken om Cisco IOS XE-apparaten die zijn blootgesteld aan internet, en de HTTP Server- en Https Server-functies gebruiken, over te nemen. Aanvallers lijken de kwetsbaarheid te misbruiken door middel van een eerdere kwetsbaarheid: CVE-2021-1435. Die is in 2021 volledig gepatcht. Het Talos-beveiligingsteam van Cisco zegt echter dat het ook volledig gepatchte apparaten heeft gezien die alsnog zijn overgenomen. Dat gebeurt op een 'nog niet vastgestelde' manier.

Cisco-gebruikers wordt aangeraden om hun netwerk te doorzoeken op 'tekenen van compromittering'. De makkelijkste manier is door te zoeken naar onbekende, pas aangemaakte gebruikers op hun apparaten. Gebruikers wordt ook aangeraden om de HTTP Server- en Https Server-functies uit te schakelen op apparaten die zijn blootgesteld aan internet. Het bedrijf heeft een blogpost gepubliceerd met instructies voor het vaststellen van besmetting en verdere aanbevelingen.

Cisco IOS XE-code implant zeroday
Code van de implant. Bron: Cisco Talos

Door Daan van Monsjou

Nieuwsredacteur

17-10-2023 • 10:25

29

Lees meer

Reacties (29)

29
29
10
1
0
12
Wijzig sortering
Je vraagt er natuurlijk ook wel beetje om als je management interface zonder ip whitelisting aan het internet hangt....
IP whitelists zijn een beetje verouderd advies, maar bij een bedrijf als Cisco waar keer op keer backdoor gevonden worden zou elk apparaat achter drie VPN's moeten hangen wil je hun spul veilig kunnen gebruiken. Aan de andere kant: ga je de whitelist van Cisco zelf vertrouwen als ze zulke fouten maken?

Ik snap niet hoe mensen Cisco hardware nog vertrouwen. Als dit de eerste backdoor was, hadden ze het op een menselijke fout kunnen afschuiven, maar de geschiedenis van Cisco zit vol (beter verborgen) backdoors. De standaard voor beveiliging van een switch of router is toch een stuk hoger dan die van een willekeurige API-server ergens mag ik hopen.

[Reactie gewijzigd door GertMenkel op 22 juli 2024 16:00]

Nu ben in benieuwd waarom ip whitelisting oud advies zou zijn. Het is toch niet “het een of het ander” maar een “en - en - en” verhaal.
Afgebakende "veilige" adressen willen nog wel eens tot onhandige beslissingen leiden ("we hebben geen 2FA nodig gan deze IP's want alleen mensen op kantoor kunnen erbij" gevolgd door een VPN die tijdens corona snel is opgezet). Tegenwoordig, met thuiswerken en dat soort zaken, is zero trust de richting die je liever op wilt gaan.

Een whitelist is niet slecht, maar het is ook niet de perfecte oplossing. Het kan zelfs zaken bemoeilijken (niet meer kunnen inloggen omdat een deel van het netwerk down is en je via de failover inloggen, jezelf afhankelijk maken van IPv4, meer overhead als je van 192.x naar 172.x of 10.x moet switchen vanwege een groeiend netwerk, etc.). Als laagje erbovenop zie ik er niet per se een probleem in, maar eigenlijk zou je het liefste zoiets niet meer nodig moeten hebben.
Sorry hoor, maar wat zit je een ongelofelijke bak onzin te verkopen Gert. Ik hoop dat je professioneel niet zo te werk gaat. Je doet ongekende aannames (whitelist == geen 2FA), VPN's die tijdens corona snel worden opgezet... jeetje mina...

Er is helemaal niks mis met Cisco. Dat er lekken worden gevonden heeft niets met Cisco te maken, die worden ook in Microsoft, Apple of andere merken producten gevonden. Wat wél zo is, is dat je moet weten wat je doet als je met Cisco werkt. Dat impliceert "klakkie" ook. Dat betekent inderdaad geen http server aan op een switch, niet de boel zomaar openzetten, slim je management ontwerpen, et cetera. Microsoft probeert vaker de beheerder te vertellen wat te doen. Cisco en unix-like niet. Wat mij betreft een goede zaak, maar het vergt wel meer inzicht, security-mindset en denkwerk.
Dat de "binnenkant" vaak minder goed beveiligd wordt zie je toch best vaak bij grote hacks. En dat VPN's tijdens corona snel werden opgezet is gewoon een feit, je had geen drie tot zes maanden lead time om dat allemaal uit te zoeken, veel bedrijven werden verrast. Misschien dat een maand later alle tech debt die die paniek heeft veroorzaakt gepatcht is, maar als ik kijk naar hoe lang het duurde voordat de laatste grote Exchange-exploit daadwerkelijk door ieder bedrijf was uitgerold, zou ik me niet verbazen als we deze nieuwe exploit nog jaren voorbij zien komen.

Als je alles goed voor elkaar zet en preventief de web UI van Cisco uitzet (omdat je Cisco's software blijkbaar toch niet vertrouwt) en/of de nodige security-VLAN's opzet, heb je geen last van dit lek nee. Het probleem is dat er nogal veel bedrijven zijn die niet alles voor elkaar hebben. Dat is de reden dat bedrijven gehackt worden, 0days zie je zelden op grote schaal gebruikt worden. Als iedereen altijd met kennis en inzicht werkte, had Cisco waarschijnlijk überhaupt nooit die web UI verkocht.

Voor een willekeurig bedrijf zou ik inderdaad zeggen "exploits gebeuren nu eenmaal", maar voor een bedrijf dat deze maand nog een hardcoded root account heeft moeten patchen is mijn geduld onderhand wel een beetje op. Met het huidige issue zit Cisco weer met een accountkwetsbaarheid, waar blijkbaar een hacker een account aan kan maken met de hoogste privileges. Het lijkt geen ultracomplexe heap spray en stack overflow, de CVE waarvan de patch niet werkte is een command injection voor anonieme gebruikers, iets wat je vaker ziet bij routermakers ondanks dat het een van de domste kwetsbaarheden is.
Het is iets meer dan Whitelisting:
- http/https staat uit, tenzij het nodig is (WLC BvB)
- op de switches staat een ACL voor het management dat enkel communicatie toelaat met de IP's van gekende Tooling servers of appliances
- management interfaces zitten in een apart vrf, afgescheiden door een firewall
- Tooling zit in een apart vrf, afhescheiden van het business netwerk door een firewall
- Enkel trusted IP's van de netwerk admins hebben toegang tot de Tooling (aparte Citrix/VDI of VPN pool die deftig beveiligd is)
- Business en Tooling of mgmt access gebruikt uiteraard verschillende credentials
Goh, en dan USA maar klagen over Chinese producten en vermeende onbewezen afluister technieken, terwijl Amerikaanse producten bewezen ((on)bewust) wijd openstaan.
Het is niet alsof de Chinezen het nou zoveel beter doen, Huawei heeft na onderzoek hun fouten ook met incompetentie moeten verdedigen op netwerkgebied. Het verschil is dat we se Amerikanen meer vertrouwen fan de Chinezen omdat onze prioriteiten vaak dichter in de buurt bij hun prioriteiten liggen en we vaker samenwerken. China zet groot in op industriële spionage op dezelfde manier dat de VS die tweehonderd jaar geleden deed toen zij hun positie op de wereldmarkt veroverden.

Dat betekent niet dat de Amerikanen te vertrouwen zijn, alleen dat ze meer te vertrouwen zijn dan de Chinezen.
Ik snap niet hoe mensen Cisco hardware nog vertrouwen. Als dit de eerste backdoor was, hadden ze het op een menselijke fout kunnen afschuiven, maar de geschiedenis van Cisco zit vol (beter verborgen) backdoors. De standaard voor beveiliging van een switch of router is toch een stuk hoger dan die van een willekeurige API-server ergens mag ik hopen.
Als je lang en diep genoeg zoekt, dan kom je erachter dat bijna elk stukje software een backdoor heeft. Zoals @Yordi- het al vermeld.

Het heeft niet zo zeer met vertrouwen in Cisco te maken, maar eerder dat als jouw vorige netwerkomgeving Cisco was, dat je juist meer geneigd bent om Cisco te nemen omdat je de CLI's al kent. Stel dat je voor een andere vendor was gegaan (HPE, Juniper, Extreme Networks, Dell, Aruba), dan moet je personeel omscholen, zodat die ook om kunnen gaan met het nieuwe merk.

Ik weet niet of het nu nog bij HPE / Aruba is, maar je had 5 jaar geleden de Procurve en Comware OS voor de switches. Afhankelijk welke switches je had, kon je bij HP dus 2 verschillende soorten OS draaien, met elk weer een andere sub commands.

Daarnaast zijn de meeste CLI's bij Cisco hetzelfde gebleven, her en der zijn er natuurlijk veranderingen en aanpassingen doorgevoerd. Of je nou een oude 3500, 2960, 3750 of een nieuwe 9000 series Catalyst configueert, de commands zullen grotendeels hetzelfde zijn, waardoor je binnen no-time ook in de nieuwe IOS versie een switch kan configureren.

Je zou ook naar de Nexus lijn kunnen gaan, want die draaien op een Linux kernel. Echter zit je dan wel een een hele grote kostenpost, want een Nexus switch is vele malen prijziger dan een Catalyst switch. Daarnaast is de Catalyst lijn het meest gebruikte model van Cisco, zo niet het meest gebruikte switch bij de meeste bedrijven.

Dan komt er nog het volgende bij; de switch configureren a.d.h.v. de gestelde eisen van het bedrijf. Dat houdt dus het volgende in:
  • service password-encryption (staat al by default aan op nieuwe switches)
  • Configureren van Radius
  • Local account(s) aanmaken voor het geval Radius niet te bereiken is (ook op de console en VTY lines)
  • Gescheiden VLAN's voor user, server en distributie
  • Monitoren van vreemde activiteiten
  • Port security
  • Firewalls ertussen met goede filtering; alleen netwerk / IT beheer mag bij de apparatuur bijkomen
Voordat je de schuld bij Cisco neerzet, is het wel zo verstandig om eerst te kijken of je zelf het e.e.a. hebt gedaan om hackers buiten te houden en zo veel mogelijk encryptie te gebruiken waar mogelijk (dus ook SSH i.p.v. telnet).

Maar ja, gebruiksvriendelijkheid en security gaan nooit met elkaar samen, dus moet je een middenweg vinden wat werkbaar is, maar wat ook veilig in gebruik is.
Meh, dit is toch ook gewoon een nachtmerrie als je het als schakel in een gestapelde aanval stopt? Dan hoeft het echt niet aan het internet te hangen, als je het alleen kan bereiken vanaf lokaal netwerk, dan moet je dat regelen. Daarna is je netwerk gecompromitteerd, en maakt het niet meer uit of je wel of niet aan het netwerk hing.

Alleen leunen op perimeter defense, dàn vraag je er pas om ;)
Eens, maar volgens mij is OOB wel een manier van opereren waar ik mee ben "opgegroeid" maar ik betwijfel of de Z generatie dit wel meekrijgt omdat de aandacht nu meer ligt bij het hosten binnen de public cloud dan een datacenter oplossing en security daarmee veelal binnen de opties van de cloud provider toegepast worden en niet zozeer meer fysieke hardware.

Ik denk daarmee dat de aandacht niet meer ligt bij het beschermen van de eigen perimeter, uitgezonderd grote organisaties die nog vooral "traditioneel" opereren.
Er is een kantelpunt waarop het risico van jezelf buitensluiten groter is dan het risico dat het theoretische probleem misbruikt wordt.
Hoe kan je je zelf buitensluiten op devices met een dedicated management port (serial of OoB Ethernet) ?
Als men zichzelf zo grondig in de voet schiet, mag men lekker naar het datacenter met een laptop en kabeltje.
Onkunde is ook een risicofactor.
Je hangt een management IF sowieso niet aan Internet.

"Aanvallers kunnen de kwetsbaarheid misbruiken om Cisco IOS XE-apparaten die zijn blootgesteld aan internet, en de HTTP Server- en Https Server-functies gebruiken, over te nemen."
Zulke figuren moet je aan hun ballen ophangen...
Helemaal eens. Dit hoort alleen vanaf de andere kant beschikbaar te zijn (LAN zijde) als het überhaupt al aan staat.
Meestal wordt er alleen maar een commandline gebruikt.
In dat geval wel, maar de 9800 wireless controllers draaien voor zover ik weet ook IOS XE, ik weet niet of het daar op van toepassing is. Maar als je bijvoorbeeld een Guest Portal daar op lokaal draait is dat ook een "HTTP Server" en zou die in theorie ook kwetsbaar kunnen zijn.
Maar als je bijvoorbeeld een Guest Portal daar op lokaal draait is dat ook een "HTTP Server" en zou die in theorie ook kwetsbaar kunnen zijn.
Dat ligt aan of de kwetsbare webapplicatie beschikbaar wordt gesteld in dezelfde omgeving als waarin het Guest Portal wordt aangeboden. Idealiter is dat niet zo.
Voor enterprises wordt het toch al vaak gebruikt dat de captive portal op ISE draait, waardoor de gui alleen voor management wordt gebruikt.
Is dat een achter deurtje van onze NSA vrienden?
Zullen we dat ook gaan vragen bij iedere bug die jij maakt?
Edit: caption niet goed gelezen, never mind

[Reactie gewijzigd door GertMenkel op 22 juli 2024 16:00]

http beheren van cisco sws kansloos. Koop dan netgear of d-link zooi bij staples
Voor switches / routers inderdaad. Echter de C9800 WLC (die ook IOS-XE draait) is het weldegelijk handig.
Stel ik zou meegaan in het argument dat https handig is voor beheer. Dat hang je toch niet aan internet.
Nee sowieso in een DMZ/OOB segment van je netwerk!

Op dit item kan niet meer gereageerd worden.