Nieuws
image

Lek in SSL VPNs bedreigt zakelijke gebruikers

woensdag 2 december 2009, 13:54 door Redactie, 5 reacties

Het Amerikaanse Computer Emergency Readiness Team waarschuwt voor een beveiligingslek in SSL VPN producten van meerdere aanbieders, waardoor aanvallers VPN sessie tokens kunnen stelen en de inhoud kunnen wijzigen van cookies, scripts of HTML content van alle sites die via het VPN zijn opgevraagd. De kwetsbaarheid "breekt" de fundamentele beveiliging van browsers. Dit stelt aanvallers in staat om via het SSL VPN de authenticatie te omzeilen of andere web-gebaseerde aanvallen uit te voeren. Dit zorgt ervoor dat de same origin policy beperking die in alle browsers aanwezig is, niet meer werkt.

Een aanvaller kan bijvoorbeeld toetsaanslagen opslaan terwijl een gebruiker op een webpagina zit. Omdat alle content met de rechten van het web VPN domein draait, zijn mechanismen die "domain-based content restricties" bieden, zoals de security zones van Internet Explorer en de Firefox uitbreiding NoScript, te omzeilen.

Oplossing
Op dit moment is er nog geen oplossing voor het probleem beschikbaar, maar systeembeheerders kunnen wel verschillende "workarounds" toepassen, zoals het herschrijven van URLs alleen voor betrouwbare domeinnamen toestaan, de netwerkverbinding van de VPN server tot vertrouwde domeinen beperken en het uitschakelen van "URL hiding features". Het gaat onder andere om de apparatuur van 3Com, Alcatel-Lucent en Cisco.

De illustratie aan de rechterkant die de aanval demonstreert, is afkomstig van Logica. Tijdens een audit in de Juniper SSL VPN oplossing werd het probleem ontdekt.

Reacties (5)
02-12-2009, 14:15 door Anoniem
kan iemand mij aub een situatie voor schetsen, hoe een aanvaller dit eventueel voor elkaar kan krijgen.
02-12-2009, 15:21 door Ethical_Hacker
Door Anoniem: kan iemand mij aub een situatie voor schetsen, hoe een aanvaller dit eventueel voor elkaar kan krijgen.


Zie de afbeelding die erbij staat.
02-12-2009, 20:58 door Anoniem
ja maar, wat als je een UTM hebt? die scanned toch het dataverkeer, dus ook HTTP, en dan komt die malicious code helemaal niet je netwerk binnen...
de junipers zijn ook UTM's dus ook ik vraag mij af hoe dut dan mogelijk is als je scanning aan hebt staan...
03-12-2009, 18:45 door Anoniem
UTM's kunnen weliswaar SSL-'forwarding' maar een beetje 0_day krijg je er wel door. UTM is kastje rond standaard AV product, immers. Met deze MITM moet je alleen de data injecten waarin je creatieve code zit. De lijst met getroffen devices is imposant, en de bron (US-CERT) zeer geloofwaardig en het lek zelf maakt ook duidelijk dat er slordig omgegaan is de normale beveiliging rond https cookies. Deze zijn immers normaliter domeingebonden en hier blijkbaar niet. Het probleem zit dus juist in die ssl_forwarder. Als je de verschillende domeinen federeert met ADFS of OpenSSO, dan kun je zonder dit gat werken, op een andere manier ga je dit niet kunnen oplossen. Logisch dus dat de vendors over het algemeen nog geen fix hebben.
06-01-2010, 08:47 door Anoniem
zie ook: http://kb.juniper.net/KB15799
Mvgr
Walter
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.

Zoeken
search