Haftanın Hackleri : NodeJS İstek Kaçakçılığı, Paypal 2FA Bypass Yöntemi ve Dahası

“Haftanın Hackleri” başlığı ile yayınladığımız yazılarda bu hafta Black Hat USA 2016 & DEF CON 24 etkinliklerinden çıkardığımız notları sizlerle paylaştık. Sosyal medyada bu yazıyı #haftaninhackleri etiketi ile tartışabilirsiniz, bize sorularınızı sorabilirsiniz.

“Haftanın Hackleri” başlığı ile yayınladığımız yazılarda bu hafta NodeJS İstek Kaçakçılığı, SOH Karakterleriyle Kaynak Kod Elde Etme, Sosyal Medyadaki Parmak İziniz ve Paypal 2FA Bypass Yöntemi başlıklı konulara değindik. Sosyal medyada bu yazıyı #haftaninhackleri etiketi ile tartışabilir, sorularınızı bize sorabilirsiniz.

Bu hafta web güvenliğinde dikkatimizi çeken konular:

NodeJS İstek Kaçakçılığı

Modern tarayıcıların HTTP Kaçakçılığı gibi saldırılara neden olabilen yeni satır karakteri gibi geçersiz karakterleri denetlediği bilinmektedir. Node.js istek kaçakçılığının ortaya çıkma sebebi ise Node HTTP istemcisinin path konusunda işi biraz daha gevşek tutmasından yararlanılarak oluşturulmasıdır. Yani saldırının özü, kuralların path için yumuşatılmış olmasından kaynaklanıyor. HTTP Kaçakçılığı hakkında da bilgi verecek olursak şöyle diyebiliriz: İlk cihaz vasıtasıyla ikinci cihaza bir istek kaçırma amacıyla iki HTTP cihazı (genellikle bir frontend proxy ya da HTTP aktif olan güvenlik duvarı ile bir backend web sunucusu) arasında RFC uyumluluğu olmayan HTTP isteklerinin parse edilmesindeki uyumsuzluğun suistimal edilmesi saldırısıdır.

Path hakkındaki serbestliği göz önünde tutulursa, saldırının nasıl gerçekleştiği, aşağı yukarı tahmin edilebilir. Söz konusu serbestlikten yararlanarak path dizisine tab ve yeni satır karakterleri eklenebilmektedir. Bu durum birden fazla HTTP isteği yapılmasına olanak sağlıyor. Verilen bilgilere göre Node.JS İstek Kaçakçılığı, V0.12-V6.20 (stable) sürümlerinde test edilmiş.

Apache.org’a yapılacak örnek bir istek için düzenlenen path şöyle olabilir. Burada /security_report.html’e istek yapılmıştır:

path: "/security_report.html\tHTTP/1.1\r\nHost:\thttpd.apache.org\r\nContent-Length:\t0"

Sonuç ise şu şekilde:

$ nc -l 127.0.01 8080
GET /security_report.html    HTTP/1.1
Host:    httpd.apache.org
Content-Length:    0

Ayrıca Node HTTP Client’nin Keep Alive metodu aktif olarak bir agent göndereceğini; kullanıcıların timeout window ve Keep Alive metodu aktif olan hedef sunucu bünyesinde istek yapmaları halinde aynı TCP bağlantılarını kullanacaklarını unutmamak gerekir. Yetkilendirme bilgisinin bu istekler vasıtasıyla gönderilmesi sonucunda bir saldırgan anlatılan saldırı yöntemini geliştirerek kullanıcılara ait hassas bilgileri ele geçirebilir.

Fixlenme aşamaları, gerekli önlemler gibi daha fazla ayrıntıyı buradan edinebilirsiniz: https://blog.tarq.io/node-js-request-smuggling

SOH Karakterleriyle Kaynak Kod Elde Etme

JSP ve INC uzantılı dosyaların kaynak kodlarının elde edildiği bu hack hikayesinde JSP dosyalarının sistemde işlenebilir olması, sunucuda Apache ve Tomcat’in kullanıldığı tahminine neden olmuş. Ayrıca dosyaları Tomcat ve httpd arasında dağıtmak için bazı modüllerin kullanılmış olabileceğinden de bahsedilmiş ki bu durum, bir Connector (bağlayıcı) ya da bir Handler (eylemci) kullanılması koşuluyla, rotalamaya düşük sıralı ASCII karakterler ekleyerek JSP veya INC dosyasının kaynak kodunu elde edebilmeyi mümkün hale getiriyor.

Saldırı amacıyla yapılan ilk adımda dosya uzantısının sonuna bazı karakterler eklenmiş. Yapılan bu işlemin ardından bir stack trace’nin ortaya çıkması ya da bir web güvenlik duvarının çalışması beklenirken bu davranışlardan hiçbirinin oluşmaması, ilk olarak saldırının başarılı olmadığı izlenimini verse de umulandan farklı olan şu hata mesajının ekrana yansıması zafiyetin tespitine dair bir işaret konumunda:

HTTP ERROR: 400
Problem accessing /password.jsp%00. Reason:
    The request contains an illegal URL

Genelde apache httpd’nin yapılan bir istekte yukarıdaki gibi değil aşağıdaki gibi bir hatayı yansıtması beklenirdi:

Not Found
The requested URL /password.jsp was not found on this server.

Dolayısıyla yapılan istek sonucunda dönen hata mesajının httpd’den değil bağlayıcıdan kaynaklandığını anlayabiliyoruz. Çünkü bağlayıcılar düşük sıralı ASCII karakterlerinin kullanıldığı böyle durumlarda, beklenmeyen davranışlar oluşmasına yol açabilmektedir.

Tomcat bağlayıcılarıyla alakalı bir bilgiye göre SOH (start of header, 0x01) karakteri kullanılarak veri akış rotalaması manipüle edilebiliyor. Açığın özü bu karakterlerle ilgiliyken saldırının adımlarını baştan itibaren şu şekilde sıralayabiliriz: Önce Apache httpd’ye istek gönderilir. Httpd, isteğin Tomcat’a iletilmesi için kendi eylemcisi ya da filtresini kullanır. Tomcat, JSP dosyasını açmak için kendi eylemcisi ya da filtresini kullanır. Sonrasında Tomcat, istenen dosyanın içeriğini, “.jsp%01” uzantısıyla istekte bulunduğumuz httpd’ye iletir. Nihayetinde httpd, “.jps%01” uzantısını kendi dosya eylemcisinin uzantılar listesinde bulamadığından dosyayı düz metin olarak servis etmeye karar verir. Bu da saldırganın kaynak koda erişebilmesi anlamına gelir. Aynı aşamalar sistemde bulunan INC dosyaları için de geçerlidir.

Açığın fixlenmesi hakkında bilgi almak ve diğer ayrıntılara göz atmak için bağlantıya tıklayabilirsiniz: http://secalert.net/#scl-soh

Sosyal Medyadaki Parmak İziniz

Birçok büyük web platformu, bu sitelere giriş yapıp yapmadığınız bilgisini, izniniz olmadan sızdırır. Bu durum, herhangi bir web sitesinin sizin hangi platformda oturum açtığınızı tespit etmesine izin verir. Profile Hijacking, Phishing, Clickjacking vb. birçok saldırı için zemin hazırlamaktadır.

Açıklama

En bilindik bazı web platformları, kullanıcının servise login olup olmadığı bilgisini saldırganın suistimal edebileceği bir login mekanizmasına sahip.

Zafiyet yıllardır biliniyor olmasına rağmen birçok şirket bunu düzeltmedi. Exploit oldukça basit ve fixlemesi de kolay. Öncelikle facebook.com'u inceleyerek zafiyetin nasıl çalıştığı konusunda bir fikir edinelim.

Login yönlendirme mekanizması nasıl çalışıyor?

İlk olarak oturum yönlendirme mekanizmasını anlamamız gerekiyor. Öncelikle şu adresi ziyaret edin:

https://www.facebook.com/bookmarks/pages

Eğer bu URL'yi Facebook'a giriş yapmadığınız bir tarayıcı sekmesinde açarsanız, aşağıdaki URL'nin olduğu oturum açma ekranına yönlendirileceksiniz.

https://www.facebook.com/login.php?next=https%3A%2F%2Fwww.facebook.com%2Fbookmarks%2Fpages

URL'nin “next” parametresinden sonraki kısmını not edin:

https%3A%2F%2Fwww.facebook.com%2Fbookmarks%2Fpages.

Bu URL, ilk ziyaret ettiğiniz ve oturum açtıktan sonra yönlendirildiğiniz adrestir. Eğer login URL'sine zaten oturum açtığınız bir tarayıcı sekmesinde girerseniz, login ekranına düşmeden yönlendirilirsiniz. Bu nedenle URL iki farklı şekilde sonuç döndürmektedir:

• Giriş yapıldıysa: URL'nin “next” parametresinden sonra gelen bölüm
• Giriş yapılmadıysa: Login ekranı

Same Origin Policy'yi Bypass Etmek

Yukarıdaki URL bize nasıl yardımcı olabilir? Same Origin Policy facebook.com domaini dışındaki domainlerden, istek sonuçlarının okunmasını engellemektedir fakat https://facebook.com için aynı şey geçerli midir?

SOP, HTML sayfalarını kısıtlamaktadır ancak diğer origin'lerden gelen resimlerin bitlerinin istemci tarafında çalıştırılmasına izin verir. Bu yüzden eğer next parametresinden sonra gelen kaynak bir imaj ise, bunu kendi sitemiz üzerinden okuyabiliriz. Facebook, URL'deki next parametresinden sonraki bölümün https://facebook.com ile başlayıp başlamadığını kontrol eder, ayrıca Facebook open redirection’a karşı bir tedbir almış durumda. Böylelikle bize gerekli olan, facebook.com'daki bir imajdır. Gayet kolay görünüyor değil mi? Aslında pek de öyle değil, çünkü Facebook neredeyse bütün imajları CDN sunucuları altındaki fbcdn.net domaininde barındırıyor. Buna karşın neredeyse her web sunucusunda bulabileceğiniz bir imaj var: favicon.ico!

Alttaki URL, oturum açtıktan sonra favicon ile birlikte next parametresinin nasıl olduğunu gösteriyor:

https://www.facebook.com/login.php?next=https%3A%2F%2Fwww.facebook.com%2Ffavicon.ico

Bu URL çok ilginç bir özelliğe sahip:

Oturum açıldıysa: favicon resmi döndürülür.
Oturum açılmadıysa: Giriş ekranına döndürülür.

Bu URL'yi <img> tag'ı ile kendi web sitemizde kullanabiliriz:

<img src="https://www.facebook.com/login.php?next=https%3A%2F%2Fwww.facebook.com%2Ffavicon.ico">

<img> tag'ının özelliği:

Oturum açıldıysa: favicon imajı alınır, başarılı olarak yüklenir ve onLoad çağrısı tetiklenir.
Oturum açılmadıysa: Giriş ekranı alınır, imaj yüklemesi başarısız olur ve onError çağrısı tetiklenir.

Dolayısıyla aşağıdaki URL, exploit’in son durumunu oluşturur:

<img onload="alert('logged in to fb')" onerror="alert('not logged in to fb')" src="https://www.facebook.com/login.php?next=https%3A%2F%2Fwww.facebook.com%2Ffavicon.ico">

Diğer Platformlar

Bu mekanizma neredeyse bütün büyük web platformlarında çalışır, çünkü bu platformların kendilerine ait login endpoint'inde bir yönlendirme parametresi mevcuttur ve kendi favicon'larını domain'leri altında barındırmaya ihtiyaç duyar.

Güncellemeler

• 7/10/2016 - Instagram kendi root domainlerinden favicon'u silerek CDN altında barındırmaya başladı.
• 14/10/2016 - Stackoverflow bu durumu fixledi.
• 14/10/2016 - Firefox kendisine ait olan default tracking protection blacklist'e göre fixledi.

Daha Gelişmiş Ataklar

Bu atak, Deanonymization atağı, Clickjacking, Profilejacking veya Phishing gibi kullanıcının hangi servise giriş yaptığı bilgisi bulunduğunda daha zararlı olabilecek ataklar için bir basamak olabilir.

Korunma

İlk olarak, üçüncü parti çerezleri pasif duruma getirin.

Bunun yanısıra kendinizi bu saldırıdan korumak Privacy Badger veya uMatrix gibi tarayıcı eklentilerini kurabilirsiniz.

Konuyla ilgili daha fazla bilgiye ulaşmak isterseniz, Hackernews’deki veya Reddit’teki konuları takip edebilirsiniz.

Paypal 2FA Bypass Yöntemi

Bu haftaki hack haberlerimizin sonuncusu da, otelde telefon sinyalinin zayıf olduğu durumda Paypal ile ödeme yapması gereken Henry Hoggard isimli bir güvenlik araştırmacısı tarafından gerçekleştirilen 2FA’ı bypass etme yöntemi.

Öncelikle Paypal’a geçerli kullanıcı adı ve parolasıyla giriş yapıyor. Daha sonra 2FA kısmına geldiğindeyse başka bir yolu seçerek güvenlik soruları kısmına atlıyor. Burada ise gizli sorulara herhangi bir cevap veriyor ancak proxy yoluyla bu sorulara verdiği yanlış cevapları içeren parametreleri HTTP isteği içerisinden siliyor.

selectOption=SECURITY_QUESTION&securityQuestion0=test&securityQuestion1=test&jsEnabled=l&execution=e2s1&_sms_ivr_continue_btn_label=Continue&_default_continue_btn_lbl=Continue&_eventID_continue=Continue

Bu şekilde yapmış olduğu istek sonucunda ilginç bir şekilde hesabının doğrulandığına dair bir cevapla karşılaşarak ödemesini gerçekleştiriyor.

Detaylı bilgi için Henry Hoggard’ın bloğundaki yazısına göz atabilirsiniz: https://henryhoggard.co.uk/blog/Paypal-2FA-Bypass

Emre İyidoğan & Zeynep Ersinadım