Haftanın Hackleri: SSL Trafiği Dinlenme Sıklığı, Chrome Gizlilik Sorunu ve WAF Atlatma
Yakın zamanda yayınlanıp ilgimizi çeken içeriklerin tanıtımını yaptığımız Haftanın Hackleri serimizin bu bölümünde: Chrome Desktop üzerindeki gizlilik sorunu, SSL trafiğinin ne oranda dinlendiği ve veri formatı karmaşıklığını kullanarak WAF atlatma yönteminden bahsettik.
SSL Trafiğinin Dinlenme Sıklığı ve Güvenlik Açısından Oluşturduğu Tehlikeler
Google ekibinden Elie Bursztein 8 milyar bağlantıyı izleyip, şifrelenmiş web trafiğinin (HTTPS) dinlenme yaygınlığını nasıl analiz ettiklerini şu blog yazısında açıklamış. İncelemenin detayları ise yine aynı kişiler tarafından yazılan şu akademik çalışmada mevcut.
Elie bu analizin açıklamasını 4 ana başlıkta sunuyor:
- Şifrelenmiş web trafiği nasıl dinleniyor?
- HTTPS trafiğini dinleme ne kadar yaygın?
- Güvenli web iletişimini kim, neden dinliyor?
- HTTPS trafiğini dinlemenin güvenlik açısından sonuçları nelerdir?
İlk bölümde MITM (Man in the Middle,yani ortadaki adam) saldırılarının nasıl gerçekleştiği açıklanıyor. İkinci bölümde ise izlenen 8 milyar bağlantının sonucunda elde ettikleri grafikleri işletim sistemi, tarayıcı gibi gruplanarak sunulduğunu görüyoruz.
Üçüncü bölümde web trafiğine yapılan tüm müdahalelerin hepsinin kötü amaçla yapılmadığının altı çiziliyor. Web trafiğinin güvenliği geliştirme ve kötü amaçlı faaliyet gerçekleştirme olmak üzere birbirine zıt iki farklı sebepten kaynaklanabileceğinin altı çiziliyor.
Güvenliği geliştirme maksatlı; Anti-virüs çözümleri ve bazı kurumsal güvenlik duvarları web trafiğini inceleyebilirler. Buradaki amaç kötü amaçlı yazılımları engellemek veya veri sızıntısı gerçekleşmesinin önüne geçmektir.
Kötü amaçlı faaliyetler için; Web trafiği dinlendiğinde ise amaç mevcut trafiğe reklam enjekte etmekten, gizli verileri çalmaya uzanan geniş bir yelpazedeki tüm zararlı aktiviteleri içerebilir.
Yazının en çarpıcı bölümlerinden biri şüphesiz araştırmacıların browserların SSL el sıkışma süreçlerinin finger printleri ile ilgili bir database hazırlayıp, bu yolla güvenli bağlantının dinlenip dinlenmediğini tespit edebilen yaklaşımları. Özellikle akademik çalışmada ayrıntılarına değinilen bu işlem, güvenli bir web’e bizi bir adım daha yaklaştıracak gibi görülüyor.
Son bölümde ise güvenli bağlantıya yapılan müdahaleler sonucunda ortaya çıkabilecek güvenlik sorunlarından bahseden araştırma, bunun sebebi olarak güvenli bağlantıya müdahale edildiğinde uzak sunucu ile aradaki bağlantının daha güvensiz (daha düşük bir şifrelemeyle) kurulması olduğunu tespit ediyor.. Bu da MITM gibi saldırılara yol açılmasına sebep olabiliyor.
Araştırmadaki çarpıcı verilerden biri de güvenli bağlantılar %4 ile %10 arasında değişen bir oranda dinlendiğinin tespit ediliyor oluşu.. Ayrıca işletim sistemlerinden ayrı bir sertifika güven zincirine sahip olan Firefox'un diğer ürünlere nazaran daha pozitif bir sonuçla kendini göstermesi de dikkate değer ayrıntılardan.
Yapılan araştırmayı özetlemeye çalıştık daha fazla detay için Elie’nin blog yazısını okumanızı öneriyoruz:
https://www.elie.net/blog/security/understanding-the-prevalence-of-web-traffic-interception
HTML5 Video/Audio API & Google Chrome Desktop’da Yaşanabilecek Gizlilik Sorunu
AOL geliştiricilerinden Ran Bar-Zik geçtiğimiz ay Google Chrome Desktop üzerinde HTML5 Video/Audio API kullanımından kaynaklı bir gizlilik sorunu olduğunu yayınladığı bir blog post ile duyurdu.
HTML5 Video/Audio API sayesinde JavaScript kodu ile kullanıcının mikrofonuna ve kamerasına erişmek mümkün oluyor. Bunun için ekstra üçüncü parti bir uygulama veya eklenti kurmaya gerek duymuyoruz.
Websitesi bu API’ı kullanmak istediğinde tarayıcı aşağıdaki gibi bize bir bildirim gösteriyor. Aynı lokasyon ve bildirimlerde olduğu gibi kamerada da izin verirsek web sitesi bu özelliği kullanabiliyor.
(Google Chrome Desktop sürümüne ait ekran görüntüsü)
Kullanıcıdan bir kez izin alındığı takdirde, devam eden API kullanımları için tekrar kullanıcı iznine başvurulmuyor. Bunun yerine API'nın aktif ve ilgili aygıt (mikrofon, kamera) üzerinde dinleme işlemi yaptığını belirten ikonlar tarayıcı ekranının başlığında gözüküyor.
(Yukarıda hem Firefox’un hem de Chrome’un kayıttaki görünümlerini görüyorsunuz. )
Eğer kullanıcı yanlışlıkla izin verme gibi bir işlem yaptıysa veya bir kere izin verdikten sonra kaldırmayı unutmuşsa bu gösterimlerle kullanıcının durumu fark etmesi amaçlanıyor. Yani kullanıcının bilgisi dışında bir dinleme işleminin bu yolla engellenmesi amaçlanıyor.
Buraya kadar her şey normal ve bir problem yok gibi gözüküyor öyle değil mi? İşte tam bu kısımda Ran Bar-Zik bu dinleme işlemi konusunda kullanıcıyı bilgilendiren ikonun dinleme işlemini yapan sayfanın başlık kısmının olmadığı (headless) bir pop-up olarak açıldığında gözükmediğini fark ediyor. Bu durum sadece Chrome için geçerli Firefox’da böyle bir durum yok.
Hatta Ran Bar-Zik ufak bir demo bile hazırlamış:
https://internet-israel.com/internet_files/webrtc/index.html
Ran Bar-Zik bu problemi Google’a bildirmiş fakat bu problem yüksek öncelikli olarak sınıflandırılmamış. Bunun anlamı yakın zamanda bu konuyla ilgili bir düzeltme göremeyebiliriz.
Detaylı bilgi için Ran Bar-Zik’in blog yazısına göz atabilirsiniz:
https://medium.com/@barzik/the-new-html5-video-audio-api-has-privacy-issues-on-desktop-chrome-5832c99c7659
Veri Formatı Karmaşasından Yararlanarak NGFW/WAFs Atlatmak
Bir önceki “Haftanın Hackleri” yazısında Ivan Novikov’un libinjection kütüphanesinin nasıl bypass edildiğiyle (atlatıldığına) ilgili yazısını paylaşmıştık. Bu hafta ise başka bir bypass yöntemi ile ilgili yazısı ilgimizi çekti.
Ağ güvenlik çözümlerinin gelen verinin hangi formatta olduğunu (JSON/Base64/XML vb.) anlaması ve ilgili formata göre parse etmesi analitik olarak çözülemeyen bir sorundur. Burada uygulanan çözümlerin birçoğu basitleştirilmiş yöntemler kullanıyor.
Bu yöntemlerden birincisi Content-Type header bilgisini kontrol etmektir. Bu yöntem başta makul gelebilir fakat kullanıcıdan gelen bilginin bir saldırı içerip içermediği analizini yaparken yine kullanıcıdan gelen Content-Type bilgisine güvenmek mantıklı olmayacaktır. Bunu tavukları yiyip yemediğini tilkiye sormaya benzetebiliriz. Sonuç olarak Content-Type header bilgisinin saldırgan tarafından kolayca değiştirilebileceğini biliyoruz.
Genellikle gelen veri en uygulanabilir formatta parse edilecektir. Bu da saldırı tespit sistemlerini atlatmak için yeni fırsatlar oluşturur. Bunu sömürebilmek için hem düzgün yapılandırılmış bir veri formatı ,JSON gibi, hem de hala geçerli bir payload’ı ,SQL Injection gibi, aynı anda kullanan bir payload oluşturulmalıdır.
Aşağıdaki örnekte hem geçerli bir JSON verisi hem de SQL Injection payload’ını görebilirsiniz:
Saldırı tespit etme mantığı her anahtar ve değere ayrı ayrı uygulanacaktır. Örnekten hareketle payload JSON konteksti için tehlike arz edebilecek bir veri içermemektedir. Fakat kendisini yorumlayan alt sistem için, yine örnekten hareketle database, açık ki bu saldırı bir SQL injection payloadıdır.
Bu aldatmaca payloadları sanki XML verisiymiş gibi kamuflaj etmede de kullanılabilir. Örneğin aşağıdaki payload hem geçerli bir XML belgesidir hem de SQL Injection’dır.
Detaylı bilgi için Ivan Novikov’un yazısına göz atabilirsiniz :
https://medium.com/@d0znpp/bypassing-ngfw-wafs-using-data-format-obfuscations-188351ea9e73