SSL VPN sistemlerde MITM tehlikesi

SSL VPN sistemler son yillarin en moda uzaktan erisim yontemi olma yolunda hizla ilerliyor. Kullanirken ya da satarken hep esnekliginden, kolay kullanimindan ve nasil uygulamalari guvenli hale getirip sorunsuz bir sekilde uzaktan sirkete ait her islemi guvenli sekilde yapabilecegimizden bahsederiz fakat barindirdigi riskleri hep gozardi ederiz.

Kullanım oranı ve kullanım rahatlıgı gozonunde bulundurulursa dogru yapilandirilmamis SSL VPN sistemlerin  ciddi MITM riskleri ile karsi karsiya oldugunu soyleyebiliriz.

Aslinda MITM(ortadaki adam) saldirisi tum uygulamalar icin basbelasi bir saldiri yontemi fakat is SSL olunca biraz degisiyor. Zira SSL’in insanlari rahatlatan bir yani var. “Ne olacak ki nasil olsa sifreli gidiyor trafigim, istedigim yerden baglanirim sirkete ve gider finans tablosunu update ederim, maillerime bakarim:) …”. Bir de ustune elimize tutusturduklari sifre ureticiler olunca ultra guvenlik hissi ile uzaktan her tur islemi yapar hale geliyoruz.
Yukarda anlattiklarim aslinda cogumuzun orada  burda, halka acik yerlerde sahit oldugu tablolar.

Gecenlerde bir egitim sirasinda (burasi benim sirketimle alakali degil, senaryodur) canım sıkılıp arka sıralarda birinin sirketteki sunucusuna “telnet” ile baglandigini gorunce hey arkadas! gel beraber bir test yapalim dedik…

Arkadas(X firmasi calisani) SSL VPN icin cagirdigi sayfada gelen sertifika uyarisini yes diyerek gecti ve user/pass bilgilerini elindeki token araciligi ile girdi. Sonrasinda ssh ile yonetilemeyen sistemine telnet ile baglanarak komutlar calistirmaya basladi…

Baglantiyi koparip tekrar baglanmasini rica ettim, ben de bu arada ilgili aksiyonlari alarak arkadasin trafigini uzerimden gecirdim. Tekrar SSL VPN sayfasini cagirdi ve yine benzer sertifika uyarisi aldi, uyariyi yes diyerek gecti. Sonrasinda user/pass+pin bilgilerini girince sistemden gecersiz user/pass hatasi aldi. (Bu hatayi almasinin sebebi benim ssl baglantisinda araya girip user/pass +pin bilgisini alip ayni hizda SSL vpn baglantisini kurmamdan kaynaklaniyor;).

Hata alinca tekrar user/pass+pin bilgisini girip sistemlerine ulasmaya devam etti.

Bu arada ne oldu?

Ayni kullanici hesabi ile iki farkli kullanici sisteme dahil olmus oldu. Ve bu iki kullanici ayni agda oldugu icin biri digerinin ulastigi tum servislere ek mitm saldirisi gerceklestirerek ulasabilir oldu.

Burada temel problem SSL VPN cihazi icin uretilen sertifikanin self signed olmasi(Dolayisi ile kullanici her login aninda gecersiz sertifika uyarisi aliyor, ek olarak sisteme sertifikayi trusted tanitmadiysa). Kullanici her zaman uyari aldigi icin araya giren sahsin urettigi sertifikayi incelemeden kabul ediyor ve baglanti bilgileri baskalarinin eline geciyor.

Eger sunucu tarafinda istemcinin sertifikasi da kontrol edilse boyle bir problem yasanmaz fakat kullanilan urunlerin cogunda bu ozellik yok.

Aslinda piyasadaki cogu SSL VPN sistemi bu tip saldirilari anlamsiz kilacak secenekler sunuyor ama bu tip ozellikler ya kullanilmiyor ya da eksik yapilandirildigi icin calismiyor.

Mesela baglanan kullanicinin bilgisayarinda bazi degerler kontrol edilerek sirket bilgisayari olup olmadigi belirlenebilir, ayni anda bir kullanici icin tek bir ip adresi atanabilir ve baglanan ip adreslerine gore erisim haklari tanimlanabilir…

Bunun haricinde mutlaka ve mutlaka yapilmasi gereken: ssl vpn sistemlerine ip uzerinden degil de gecerli bir sertifikasi olan hostname uzerinden baglanmak ve kullanicilari sertifika hatasi aldiklarinda islem yapmamalari gerektigi konusunda egitmek/uyarmak.

Bu yazi bir arastirmaya degil, gercek sistem uzerinde yapilan calismaya binaen yazilmistir. Dolayisi ile kullanilan urun, urunde bulunan ve aktif edilmemis/yanlis ayarlanmis konfigurasyonlar gozoununde bulundurulmamistir.

This entry was posted in Misc, VPN, Wireless Security. Bookmark the permalink.

6 Responses to SSL VPN sistemlerde MITM tehlikesi

  1. zapatov says:

    hocam yazılarını çok beğeniyorum. teşekkürler

  2. paz says:

    Anladığım kadarıyla, daha doğrusu ekrandan gördüğüm kadarıyla kullanıcı browserına proxy olarak kendi proxy ni girmissin , doğal olarak kullandığın proxy (burp sanırım)kendi SSL sertifikasını kullanıcı karşısına çıkarıcaktır.
    Yalnız bunu MITM olarak sölemek zor , çünkü SSL VPN yapıcak kullanıcın makinasında proxy tanımı yapıyorsun yani RaW olarak(Sniff) bunu yapsan ok , fakat bu şekilde her SSL kullanan uygulama için aynı risk mevcut..

    Şöle , örnek olarak SSL li bir uygulamada aynı yöntem ile kullanıcı browser ayarlarında kendi proxyni tanımlarsan yine şifresini falan görürsün :))

  3. Huzeyfe ONAL says:

    Evet ekran goruntusunu almak icin lokal makinemi kullandim fakat buna gerek yok. Proxy kullanan birinin trafigini uzerinize aldiginizda bu trafigi istediginiz gibi yonlendirebilirsiniz.

    Daha dogrusu soyle soyleyelim, trafigi uzerinizden gecirebiliyorsaniz iptables(Linux) vs ile istediginiz porta yonlendirip(bu portta Burp vs calisiyor olabilir) bilgileri alabilirsiniz.

    Aslinda yonlendirme yapmaya gerek yok. Ettercap’a bir ssl filtresi yaparak parolayi alabilir ve ayni anda kullanicinin baglantisini sonlandirabilirsiniz.

    Zaten sorunun tum ssl uygulamalar icin gecerli oldugunu belirtmistim ama SSL VPNler icin biraz daha tehlikeli.

  4. paz says:

    Ettercap olursa sanırım ettercap CP tarafı ile SSL handshake yapıyor oluyor, Bunu CP anlayabilir belki.. bu durumda ortadan girmek , akan SSL trafiğinde zor gibi connection başlangıcı sırasında araya girmek gerekiyor proxy veya diğer şekilde..

    Checkpoint in SSLVPN ‘inde 1 sene önce bir XSRF açığı çıkmıştı, diğer vendorlarda bu şekilde olabilir gibi geliyor. Güzel çalışma ..

  5. Huzeyfe ONAL says:

    Cp anlayamaz zira CP tarafi istemci sertifika kontrolu yapmiyor. Yapsa zaten(MSN’nin login asamasi gibi) bu tip problemler yasanmaz.
    Ortadan girmek akan ssl trafiginde zor degil, hatta diger protokoller kadar kolay. Trafigi bir sekilde L2 seviyesinde uzerinizden gecirebilirseniz her turlu islemi yaparsiniz.

    Ettercap’in kodlarina ya da plugin yapisina bakacak olursaniz demek istedigimi daha net anlarsiniz.

  6. paz says:

    encypt trafiği ettercap decrpt etmek için bir şekilde mevcut session ı tekrardan başlatmak durumda kalıcağını düşünüyorum ,L2 seviyesinde sniff yapılsa bile, buda session uın tekrardan kurulması anlamına geliyor, kullanıcıların azıcık uyanık olması gerekiyor) veya mutual olarak SSL destekleyen bir SSL VPN çözümü kullanılması gerekiyor..

Leave a Reply

Your email address will not be published. Required fields are marked *

5 × 4 =