Cisco dicht kritiek lek in vpn-functie van ASA-software

Netwerkapparatuurfabrikant Cisco heeft een kritiek lek in de software voor zijn ASA-apparaten gedicht. Dit is aanwezig in de vpn-functie en laat een aanvaller op afstand code uitvoeren en het apparaat overnemen.

Cisco heeft de kwetsbaarheid, met kenmerk CVE-2018-0101, een maximale cvss-score van 10 gegeven, waarmee het om een kritiek lek gaat. Een aanvaller kan alleen van het zogenaamde double free-lek gebruikmaken als de webvpn-functie is ingeschakeld op de ASA-netwerkapparatuur. Dit is mogelijk door gebruik te maken van speciale xml-pakketten, aldus Cisco.

Kwetsbare apparaten

Op die manier is het mogelijk om code uit te voeren en het apparaat over te nemen, of om een reload teweeg te brengen. De kwetsbaarheid is volgens Cisco publiekelijk bekend, maar het bedrijf zegt niet op de hoogte te zijn van aanvallers die er actief gebruik van maken.

Cisco heeft een lijst met kwetsbare apparaten gepubliceerd en schrijft dat het lek vanaf versie 6.2.2 in de zogenaamde FTD-software aanwezig is, omdat in die versie een remote access vpn-functie werd geïntroduceerd.

Reacties (29)

[wei9ojcqw89]

Je kunt webvpn uitschakelen door de volgende commando's toe te passen:
conf t
no webvpn

Neemt niet weg dat je als nog moet updaten. En dat je wellicht geen VPN verbinding meer kan maken.

[Reactie gewijzigd door wei9ojcqw89 op 23 juli 2024 09:35]

[ieperlingetje]

Maar dan werkt de ssl vpn (anyconnect) ook niet meer, dus uitschakelen is niet zomaar een optie.

[dezejongeman]

even een kleine nuance site to site vpn;s werken dan wel gewoon. het gaat puur om client en clientless vpn voor thuiswerk/remote werk oplossing.

voor verschillende major versie releases zijn er al sinds november patches en andere van gister. het kan dus zijn dat je jou unit al hebt bijgewerkt. volg gewoon de link van tweakers waar de releases mooi in een tabelletje staan.

wat betreft updaten. er is zoals altijd een reboot vereist. 1 is geen dus bij een failover setup heb je bij het juist uitvoeren nagenoeg geen impact.

[Frituurbaas]

En dat je geen vpn verbinding meer hebt via de firewall van je werkgever

[194673]

Je kan altijd tijdelijk terugschakelen op IPSEC verbindingen als je echt je firewall niet kan updaten.

Over het algemeen draait men echter in fail-over setup, dus 0 downtime upgrades gedurende productie uren moet prima mogelijk zijn.

[hoberion]

niet helemaal waar, je sessie gaat wel even down maar reconnect weer

als je een ping laat lopen zie je dat die niet meer werkt, na het commando nogmaals uit te voeren wel weer

zelfde voor streaming radio zagen we.

bron: vandaag de update doorgevoerd.

[194673]

Dan heb je de fail-over niet goed geconfigureerd staan. Als je de configuratie goed uitvoert dan heb je een sessiontable sync tussen de 2 ASA's. Afhankelijk van de down detectie timers kan het zijn dat je iets aan traffic mist omdat hij de deadtimer moet afwachten, deze timers zijn overigens ook te tweaken. Als je een failover forceert via het 'failover' (active ASA) of 'failover active' (standby ASA) commando dan zou er op wellicht een paar packetdrops na geen sessionloss mogen plaatsvinden.

[ipsec]

Vergeet de wr mem niet, anders ben je na een reload weer terug bij af

[Frituurbaas]

Kunnen ze die update pushen, of moeten alle familiebedrijfjes die zo'n firewall hebben staan zelf zorgen dat het geïnstalleerd wordt? Iets dat ze zelf niet kunnen, mooie business voor de lokale IT-onderhoudsmonteur!

[Koffiebarbaar]

Cisco firmware updates moet je zelf installeren.
Er zijn zat oplossingen die dat wel doen dus als je tegen dit probleem aanhikt als familiebedrijfje moet je eens met je "system integrator" gaan praten.
Cisco hardware hoort m.i. niet echt thuis in een onbeheerde context, heeft erg snel de neiging om gigantisch achterhaald te raken met een bloedgang.
Op dat soort locaties zou ik eerder kiezen voor een linux box met een update en reboot script. Daar moet je dan misschien af en toe naar kijken omdat het in storing valt om één of andere reden maar dan heb je in ieder geval geen lek die ongezien, jaren in je hardware blijft zitten omdat er gewoon niemand naar kijkt.

[Reactie gewijzigd door Koffiebarbaar op 23 juli 2024 09:35]

[the_stickie]

ik volg je wel dat Cisco apparatuur zeker degelijk beheerd moet worden... maar geldt dat niet voor àlle IT apparatuur. Ikzelf geloof niet zo in "configure and forget", en al helemaal niet als de basis een linuxdoosje is. Uiteindelijk zal die evenzeer beheerd (en geupdated) moeten worden.

[Koffiebarbaar]

Niets is honderd procent unmanaged. Zeker waar. Maar op een Linux doos kan je updates en reboots gewoon automatiseren in onderhoudswindows. Stukje monitoring voor de uptime en je komt toch best een heel eind.

[Armin]

Mijn ervaring is dat de remote-beheer functies van routers/linux-dozen/etc niet zelden de bron is van veel hacks.

In principe is een firewall-kastje juist vaak set-and-forget indien je ook echt alle beheer en andere leuke extern gerichte functies uitzet.

Maar ja, met een VPN-doos is dat evident per definitie niet mogelijk.

[mrdemc]

Als je lokaal een machine plaatst die aan de hand van een automatische taak de updates doet, bijv. Wat met de controller van Unifi kan, kun je veilig en geüpdatet blijven en als er onverhoopt iets mis gaat merk je dat snel genoeg. Maar ben je in ieder geval mbt lekken veilig omdat je de laatste versie hebt. Als deze controller dan zijn status naar buiten pusht zodat je weet dat ie geüpdatet blijft heb je ook geen ingang hier vandaan. Geen remote beheer nodig en dat is volgens mij wat @Ton Deuse bedoeld.

[witchdoc]

Ik vermoed dat mensen niet blij zouden zijn als Cisco remote firewalls gaat upgraden.

[GB2]

De Meraki lijn geeft wel deze mogelijkheid, vraag is alleen wil je dat, gaat hij down en komt hij niet meer up dan kan je alsnog langs gaan.

[Koffiebarbaar]

In IT land hoor je dit argument vaker maar ik denk dat dat met de nodige voorzorg een behoorlijk overschaald probleem is.
Dit kan natuurlijk gebeuren, maar ik fiets op servers ook gewoon remote updates naar binnen gevolgd door reboots en dat is de afgelopen 10 jaar feitelijk één keer misgegaan op een manier dat ik echt op pad moest. En dat bleek puntje bij paaltje een hardware issue.

In datacenters heb je vaak remote hands en ook kan je bij een bedrijfje een werknemer wel vragen even een apparaat fysiek te powercyclen. Daar raken sommige IT'ers van in de stess maar daar heb ik persoonlijk iig niet zo'n last van.

[Reactie gewijzigd door Koffiebarbaar op 23 juli 2024 09:35]

[sambalbaj]

Ah daarom was PIA VPN gisteren zo actief de nieuwe versie van de Windows-client aan het pushen.

[dezejongeman]

dat staat hier los. het gaat hier specifiek om de software die op de firewall draait en geen software die gebruikt wordt om met de firewall te connecteren.

[Solonaise]

Ben benieuwd of niet meer vendoren hier last van hebben. In ieder geval goed van Cisco dat de update zonder Smartnet (gratis) beschikbaar gesteld wordt.

(Bron: https://tools.cisco.com/s...ry/cisco-sa-20180129-asa1
Customers who purchase directly from Cisco but do not hold a Cisco service contract and customers who make purchases through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should obtain upgrades by contacting the Cisco TAC: http://www.cisco.com/en/U...o_worldwide_contacts.html)

Van andere kant, overal waar software actief is zullen beveiligingslekken blijven ontstaan. Transparantie is dan ook van veel grote belang zoals Cisco en andere vendoren tegenwoordig ook communiceren.

[Reactie gewijzigd door Solonaise op 23 juli 2024 09:35]

[MisteRMeesteR]

Op de Cisco website:

The customer can also use the show asp table socket command and look for an SSL and a DTLS listen socket on TCP port 443. An SSL and DTLS listen socket on TCP port 443 must be present in order for the vulnerability to be exploited.

Zou het aanpassen van de WebVPN port (== SSL Listening port) dan de oplossing zijn? Zo zwart/wit zou een aanval toch niet zijn?

conf t
webvpn
port 12345
end
wr mem

[Reactie gewijzigd door MisteRMeesteR op 23 juli 2024 09:35]

[robvanwijk]

Zou het aanpassen van de WebVPN port (== SSL Listening port) dan de oplossing zijn? Zo zwart/wit zou een aanval toch niet zijn?

Vrees dat dat niet zal helpen:

Een aanvaller kan alleen van het zogenaamde double free-lek gebruikmaken als de webvpn-functie is ingeschakeld op de ASA-netwerkapparatuur. Dit is mogelijk door gebruik te maken van speciale xml-pakketten, aldus Cisco.

Klinkt als een fout in de XML-parser (of code op een hogere laag, waar die speciale XML zorgt voor "onverwachte" data). Het lijkt mij zeer onwaarschijnlijk maar, ik heb geen manier om het zeker te weten dat de bug met een ander poortnummer opeens niet meer op zou treden. Ik vrees dat je dan eerder met security through obscurity bezig bent.

[MisteRMeesteR]

Oh eens hoor Maar als ik de tekst van de Cisco website letterlijk opvat..

[dezejongeman]

Ieder merk heeft lekken, alleen is cisco zo vriendelijk het te vermelden en hoe ze opgelost kunnen worden. menig fabrikant kan nog wat van die transpirantie leren.

[194673]

Mwa, in de security wereld kom je er echt niet mee weg om dingen onder de pet te houden. Elke vendor die ik ken die firewalls leveren hebben allemaal een proces zoals Cisco om lekken aan te kaarten en gepatched te krijgen. Met transparantie in die professionele markt zit het tegenwoordig echt wel goed.