OWASP Top 10 2017, Mailsploit, EV Sertifikaları ile Phishing, Google'dan ".dev" Hizmet!

OWASP Top 10 2017 Nihayet!

Her ne kadar resmi bir belge olmasa da, ilk yayınlandığı 2003 yılından bu yana OWASP Top 10 zafiyet listesi, sektörde önemli bir yer tutuyor; sektörün gündemini belirliyor.

Dört yıllık bir aradan sonra OWASP, nihayet Top 10 zafiyet listesinin güncel halini yayımladı. Hazırlık sürecinde epeyce bir tartışmayı geride bırakan Top 10 listesi, bir yönetim değişikliği ve tartışmalı birkaç maddenin listeden kaldırılması ya da revize edilmesi ile normale döndü.

Tartışmaya neden olan ilk taslak 2017 Nisan'ında yayınlandı. Özellikle A7 yani "Insufficient Attack Protection" önerisi, WAF ürünü olan Contrast Security adlı bir firmaya aitti ve özellikle de meselenin bu kısmı ile oldukça tepki çekti. Madde bir dizi değişiklikten sonra listenin 10. Maddesinde Insufficient Logging and Monitoring adı ile yer aldı. Yine A10 da yer alan API Security maddesi epey muğlak bir madde olarak ilk taslakta yer alsa da, RC versiyonunda yer almadı.

OWASP Top 10 2017 RC2, listenin 2013 versiyonundaki pek çok maddeyi korurken, web güvenliği dünyasında kendine itibarlı bir yer edinen ve yine OWASP dökümanlarında "Uyuyan Dev" olarak adlandırılan CSRF ve Open Redirection gibi zafiyetleri de, "yıldızlar da kayar, durmaz yerinde" dercesine, listeden emekliye ayırdı.

Sadece bu kadar değil. Mobil zafiyetler listesinde yıldızı parlayan Insecure Direct Object Reference (IDOR), web top 10 zafiyet listesinde Missing Function Level Access Control maddesi ile Broken Access Control maddesinde birleştirildi. A10 maddesine eklenen Insufficient Logging and Monitoring, XML External Entity ve Unsecure Deserializion ise listenin çiçeği burnunda zafiyetlerinden.

Dedik ya OWASP Top 10 zafiyetler listesi resmi bir belge değil ama sektörün nabzını tutuyor, diye. 2013 listesinde 3. Sırada yer alan XSS zafiyetinin, 2017 listesinde 7. Sıraya gerilemesinde, CSP gibi istemci taraflı kontrollerin yaygınlaşmasının ve browser XSS kontrollerinin varsayılan olarak etkin olmasının payı büyük. İşte, web uygulamalarının ekseriyle sahip olduğu güvenlik profiline dair değerli bir fotoğraf!

OWASP Top 10 2017 listesinin ayrıntılarına ulaşmak için tıklayınız.

Mailsploit

E-postalar 90'lı yıllardan 2000'li yılllara kadar pek çok sahteciliğin aracı oldu. Önceleri basit olarak From alanının değiştirilmesi ile gerçekleşen bu işlem SPF ve DKIM'ı de içine alan DMARC işlemleri sayesinde giderek daha da zor bir hal almaya başladı.

DNS kayıt tiplerinden biri olan MX kayıtları, e-postaların hangi makineler tarafından kabul edileceğini bildiriyor. SPF kayıtları ise, bu domain üzerinden e-posta gönderiminde hangi makinelerin yetkili olduğunu belirtiyor. Ayrıntılar için lütfen tıklayınız.

Dolayısıyla artık From alanına geçerli olmayan bir değer girerek email spoofing yapmak, modası geçmiş bir yöntem. Böylesi e-postaların doğrudan spam klasörünü boylayacağı bilinen bir gerçek.

E-posta servislerinin bu konuda aldığı tedbirler son kullanıcının içini biraz ferahlatsa da, 1992'lerden kalan bir RFC dökümanında unutulan bir ayrıntı sebebi ile, aralarında e-posta servisi ve e-mail istemcilerinin de bulunduğu 30 ürün ve hizmette kritik bir zafiyet tespit edildi.

Alman güvenlik araştırmacısı Sabri Haddouche'ın Mailsploit adı ile yayınladığı zafiyetin ayrıntıları şu şekilde:

Bir e-posta mesajında tüm alanlar için ASCII değer girilmesi bekleniyor. From alanı da bu alanlardan biri.

1992 yılında yayınlanan RFC-1342 ise ilginç bir ayrıntı içeriyor. Mailsploit zafiyeti de bu ayrıntıyı kullanıyor:

Yukarıdaki metne göre, bu spesifikasyonu implemente etmek isteyen araçlar, header alanlarında kullanılacak non-ASCII karakterleri eklemeden önce uygun bir biçimde encode etmeli. Yine bu spesifikasyona bağlı çalışacak e-posta okuyucuları da encode edilen kısımları görür görmez ve bunları olduğu gibi göstermek yerine, decode etmeli ve o şekilde göstermeliler.

Aşağıdaki şekilde kullanılabilir:

=?utf-8?b?[BASE-64]?=
=?utf-8?Q?[QUOTED-PRINTABLE]?=

Bir kısım e-posta okuyucusunun ve e-posta servisinin penaltıya düştüğü nokta tam da burası.

non-ASCII karakter içeren e-posta headerlarının decode edilirken null byte gibi, new line gibi karakterlerin encode edilmiş halleri de bu decode işleminden nasibini alıyor ve fonksiyonlarını bir tamam yerine getiriyor. Bunun sonucu olarak da null byte, new line gibi karakterlerin From alanına eklenmesi, gönderici e-posta adresi görüntülenirken domain kısmının ignore edilmesine zemin hazırlıyor.

Araştırma sonucu yayınlanan metinde bulgular şu şekilde özetleniyor:

• iOS'da Null Byte injection kulanılabiliyor.
• Email(name) alanı üzerinden zafiyete maruz kalabiliyor.

Yukarıdaki her iki vektörün birleştirildiği bir payload ile tüm OS cihazları bu saldırıdan nasibini alıyor:

From: =?utf-8?b?${base64_encode('[email protected]')}?==?utf-8?Q?=00?==?utf-8?b?${base64_encode('([email protected])')}[email protected]

Encoding işleminden sonra payloadın aldığı son hal:

From: =?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=@mailsploit.com

Yukarıdaki header alanı Mail.app tarafından decode edildiğinde, aşağıdaki hali alıyor:

From: [email protected]\0([email protected])@mailsploit.com

Söz konusu mail macOS ve iOS'da [email protected] adresinden geliyor şeklinde gözükecek.

Perdenin arkasında olan ise:

• iOS nullbyte'dan sonraki her şeyi geçersiz sayıyor (\0 karakterinden sonraki kısım.)
• macOS null byte'ı ignore ediyor, fakat parserdaki bir problem nedeniyle, geçerli e-posta adresi ile ilk karşılaşmasında (format olarak geçerli), işlemi durduruyor.

Peki e-posta servislerinin tedbirleri neden burada işe yaramadı?

Görüntülerken [email protected] adresini gösterseler de DKIM ve SPF doğrulamaları yine @mailsploit.com domaini üzerinden, yani orjinal domain üzerinden yapılıyor.

Sadece Spoofing mi?

Maalesef değil. Aynı zamanda XSS payloadları da encode edilip, From kısmında kullanılabiliyor. Dolayısıyla decode edildikten sonra doğrudan From kısmındaki değeri gösteren bir dizi servis de bu XSS saldırısından etkilenmiş oluyor.

Örneğin HushMail ve Open Mailbox servisi bunlardan birkaçı:

From: =?utf-8?b?c2VydmljZUBwYXlwYWwuY29tPGlmcmFtZSBvbmxvYWQ9YWxlcnQoZG9jdW1lbnQuY29va2llKSBzcmM9aHR0cHM6Ly93d3cuaHVzaG1haWwuY29tIHN0eWxlPSJkaXNwbGF5Om5vbmUi?==?utf-8?Q?=0A=00?=@mailsploit.com

Aşağıdaki şekli alıyor:

From: [email protected]<iframe onload=alert(document.cookie) src=https://www.hushmail.com style="display:none"\n\[email protected]

Zafiyetin ayrıntıları için Mailploit için hazırlanan sayfaya göz atabilirsiniz.

Phishing'de Yeni Bir Yöntem: EV Sertifikaları

İstatistikler web sitelerinde SSL/TLS kullanımının günden günde arttığını gösteriyor. Her iki taraf da bu yükselen trende dikkat kesilmiş durumda. Örneğin arama motorları, güvenli bağlantı kullanan sitelere sıralamada daha iyi konum vaad ederken, oltalama siteleri de göz boyamak için sitelerinde sertifika kullanıyorlar.

Web siteleri için üç tip sertifika mevcut: DV (Domain Validation); hali hazırda kullandığımız bu blogun sertifikası buna bir örnek, OV (Organization Validaton) ve EV (Extended Validation). OV ve DV sertifikaları birbirine çok benzemektedir. Her iki sertifikada da adres çubuğunda, genellikle sol tarafta yeşil bir kilit görünür. Belki görünümün bu benzerliği nedeniyle OV sertifikalarının tercih edilmediğini söyleyebiliriz. Zira DV ve OV sertifikaları arasında bir fiyat farkı var.

EV sertifikaları ise, adres çubuğunu yeşile boyayan, sadece girdiğimiz sitenin adresini değil, aynı zamanda siteye sahip olan kurum ve ülke ibarelerinin de yer aldığı bir sertifika türü.

Sadece arayüzdeki bu albeni yüzünden EV sertifikası almak isteyen dostlarımızı, IE 11 ve Edge ile baş başa bırakarak, arayüz konusunda tarayıcılar arasındaki tutarsızlıkların nasıl bu gerekçenin parlayan cilasını kazıdığına dikkat etmelerini öneriyoruz. Zira tarayıcılar arasında EV sertifikaların gösteriminde tutarsızlıklar mevcut.

Fakat EV'nin diğer artıları da var. Örneğin daha önce yine Haftanın Hackleri'nde konu ettiğimiz Revocation mekanizmasını, EV sertifikalar söz konusu olduğunda es geçebilmek mümkün değil!

Meraklısı için Scott Helme'in 4 Aralık'ta kaleme aldığı yazı pek çok teknik ayrıntıyı irdeliyor.

EV sertifkaları almak biraz daha zor görünmesine rağmen, iki araştırmacı EV sertifikalarını nasıl kolaylıkla aldıklarını ve EV sertifkalarının vaad ettiği güvenlik mekanizmasını kullanarak nasıl phishing saldırılarının daha inandırıcı hale gelebileceğini gösteriyorlar.

Deneylerden ilki James Burton tarafınan gerçekleştiriliyor. James Burton sadece 40 Pound'luk bir harcama ile kurduğu Identity Verified isimli şirket için, Symantec'den EV sertifikası başvurusu yapıyor. Üstelik Symantec'in bir aylık ücretsiz kampanyasından faydalanarak.

Identity Verified şirketi üzerine EV sertifikası alan Burton, Safari tarayıcılarındaki UI özelliğinden faydalanarak, EV sertifikasının nasıl da kullanıcıyı aldatabileceğini gözler önüne seriyor.

Nedeni ise gayet basit; IOS ve OSX üzerinde, Safari browserlarda şayet ziyaret edilen site EV sertifikasına sahip ise, şirketin adı tüm adres çubuğunu kaplayacak şekilde gözüküyor. Adres çubuğunda, yeşil renkte Identitify Verified yazısını gören ve söz gelimi Gmail.com 'un kopyalanmış içeriği ile karşılaşan kullanıcı, gerçek ile düzmece olanı birbirinden ayırmada oldukça zorlanacak gibi görünüyor. Hem de güvenlik için ekstra özellikler sunan EV sertifikasını rağmen!

Firefox ve Chrome'da ise durum daha farklı:

EV sertifikaları ile ilgili diğer bir deney ise Ian Carroll 'a ait. Ian, James'den farklı olarak daha farklı bir yöntem deniyor.

EV sertifikalarının adres çubuğundaki gösteriminde firma adı ve ülkeye yer verilmesinden hareketle Ian, Colliding entity dını verdiği yöntemi bizzat araştırmasını yayımladığı https://stripe.ian.sh/ sitesi üzerinden gözler önüne seriyor.

https://stripe.ian.sh/ 'de girdiğinizde adres çubuğunda Stripe Inc, US ibarelerini göreceksiniz. Site tarafından kullanılan EV sertifikası Comodo'ya ait. James 'in deneyinde uyanık davranan Comodo, Identify Verified için şirket adı çok jenerik bir ada sahip diyerek sertifika imzalamamıştı. Burada karşımıza çıkması sürpriz oldu. Ama suç tabii ki Comodo'nun değil.

Stripe Inc'i görünce aklınıza Delaware'de kurulan ödeme sistemi firması mı geldi? Maalesef hayır! Bu Ian'ın Kentaki'de kurduğu bir şirket :) Sadece eyalet farklı. Birleşik Devletler'in en önemli farkı bu. Her biri bir ülke büyüklüğünde, onlarca eyalete sahip olması. (Elli eyalet ve bir federal bölge. Fazla bilgi göz çıkarmaz :) )

Safari tarayısının davranışına yukarıda zaten değinmiş idik. Tüm adres çubuğunu kaplayacak şekilde EV sertifikasının ait olduğu şirket ve ülke bilgisi gösteriliyor.

Ama bu defa diğer tarayıcılariçin de durum yukarıdaki kadar avantajlı değil. Çünkü Chrome ve Firefox da EV sahipliği olarak Stripe Inc, US bilgilerini gösterecek.

Anlaşılan son kullanıcının işi oldukça zor.

Ian 'ın araştırmasına ulaşmak için lütfen tıklayınız.

Google'dan ".dev" Hizmet!

Google'ın, web sitelerinin artan bir oranda güvenli bağlantı SSL kullanmalarında yadsınamayacak katkıları var. Örneğin, Google 2010 yılında e-posta hizmeti Gmail'e ulaşımda, varsayılan olarak SSL kullanmaya başladı. 2014 yılında SSL kullanan sitelerin arama sonuçlarında daha iyi sıralara taşıyacağını vaad etmesi kullanım oranının artmasını tetikleyen önemli bir hamle idi. Yine 2016 yılında ücretsiz sertifika sağlayan Let's Encrypt'in altın sponsoru olması en büyük katkısı olarak anılabilir.

Yine bu yılın başlarında HTTP sitelere erişimde "Not Secure" uyarısı vermeye başlayarak, güvenli bağlantıların kullanıcı gözünde de-facto hale gelmesinde dev bir adım attı.

Bütün bu katkılarını, yepyeni bir hamle ile taçlandıran Google, HSTS preload desteğini tüm .dev uzantılı domainlere getireceğini duyurdu. Böylece .dev uzantılı domain sahipleri preload başvuruları yapmakla uğraşmak zorunda kalmayacak. HSTS ve preload konusundaki ayrıntılara Türkiye'de HTTP Güvenlik Headerlarının Kullanımı başlıklı yazımız vasıtası ile erişebilirsiniz.

Özetleyecek olursak, güvenli bağlantıların en büyük penaltısı, MiTM saldırıları ile daha güvensiz bir protokole downgrade edilebiliyor olmaları. Bu sebeple sitemize yönelen tüm trafiğin güvenli bağlantı üzerinden olmasını zorlamalıyız. Yanı sıra sitemizle kurulacak olan güvenli bağlantı girişimlerinde geçersiz bir sertifika sunulduğu takdirde, kullanıcının tarayıcı tarafından verilecek uyarılara rağmen güvensiz iletişime devam edememesini sağlamalıyız. HSTS işte bu konuda imdadımıza yetişiyor. Sağladığı özelliklerden ilki, HSTS talimatı browsera set edildiğinde, kendisinin bellekte saklanacağı süre boyunca (max-age seçeneği kullanılarak ayarlanıyor.), tarayıcıdan yönelen tüm isteklerin güvenli bağlantıya, yani HTTPS'e dönüştürülmesini ve geçersiz sertifika ile karşılaşılması durumunda ziyarete devam edilememesini sağlıyor.

Teoride her şey çok güzel. Peki bağlantıyı dinleyen bir saldırgan HSTS headerının set edilmesini engellerse? Bu gayet mümkün! Çünkü HSTS gibi teknolojiler TOFU, Trust on First Use metodolojisine dayanıyor. Yani ilk bağlantıda güvenli bir biçimde bu headerın set edilmesi gerekiyor. TOFU bu sistemin yumuşak karnı. Buradan doğacak riski de engellemek için tarayıcılara içkin olarak gelen preload listeleri yordamıyla, işimizi şansa bırakmaktan kurtuluyoruz. Sitemizi preload listesine ekleyerek, sitemizle daha önce hiç bağlantı kurulmamış ve HSTS talimatı alınmamış bile olsa, ilk bağlantının güvenli bir yoldan kurulmasını sağlıyoruz.

Preload listesine başvurmak birkaç adım gerektiriyor. Üstelik yeter şartlara sahip olmanız halinde bile tarayıcının bir sonraki sürümü ile dağıtılacak listede yer alacağınız için, bu yeni sürüm yayınlanana kadar risk devam ediyor. İşte Google artık beklemeye son veriyor. Domain, subdomain ve TLD'ler için HSTS desteğini, .dev TLD'si için kendisi browserlarına ekliyor.

Aslında bu ilk değil. 2015 yılında Google yine kendisine ait olan bir TLD olan .google 'ı da preload listesine aldı.

Internal test ortamlarında .dev uzantılarını kullanan okurlar belki bu habere üzülecekler ama, yavaş yavaş kullandıkları .dev uzantısını bu işler için rezerve edilen aşağıdaki TLD'lerden birine taşıyabilirler:

• .test
• .example
• .invalid
• .localhost

Haberin ayrıntılarına ulaşmak için lütfen tıklayınız.

Recon her yerde!

Recon, reconnaissance'ın kısaltılmış hali. Keşif manasına geliyor. Hedef ile ilgili olabildiğinde bilgi toplanan fazı temsil ediyor. Sıkı bir pentestin en önemli aşaması olduğunda konunun tüm uzmanları hemfikir.

Picus Security'de Attack Developer olarak çalışan dostumuz Evren Yalçın, pentest tecrübelerinden damıttığı çok özel ayrıntıların paylaşıldığı bir yazı yayımlandı. Recon is Everywhere başlıklı yazı, meraklısı için faydalı ipuçları içeriyor.

Evren ayrıntılara düşkün bir sanat adamı olarak, ki kendisi sinema alanında ihtisas sahibidir, yazısına Görünmeyen Gorilla (Invisible Gorilla) deneyinden alıntı yaparak başlıyor.

Evren'in birkaç küçük spoiler'ı mazur göreceğini düşünerek yazımıza devam edelim.

Şirket Logoları

Bir firmanın sahip olduğu diğer web sayfalarını da merak ediyor musunuz? Bazen şirketlerin bile sayısını bilmediği web siteleri vardır. Kampanya siteleri, ortaklıklarla ya da ürünler ile ilgili siteler. Kurumlara ait, isimleri meçhul olan nice siteyi, Google'ın grafik arama özelliğini kullanarak bulabilirsiniz. Nasıl mı? "Fotoğraflarda Ara" seçeneğinden, firma logosunu kullanarak. İsimleri meçhul olsa da, firmaya ait pek çok sitede bu logoların bulunması kuvvetle muhtemel.

Copyright@

Yine arama motorları vasıtası ile "© 2017 Company Name" şeklinde arama yapılarak, ilgili siteleri keşfedebilirsiniz.

Humans.TXT

Haftanın Hackleri yazı dizisinde daha önce Security.TXT taslağından söz etmiş idik. Humans.TXT, "güzel bir eser bana müessiri hatırlatır" diyenlere ithaf edilen farklı bir standart. Sayfanın creditsini merak ediyorsanız humans.txt ne güne duruyor? Evren ise, deformasyon profesyonelinin(mesleki dezenformasyon) canlı bir örneği olarak, yeni bilgiler peşinde. Pekala humans.txt'yi kullanarak, recon aşamasında farklı bilgilere ulaşabileceğimizi bizlere gösteriyor.

Reverse Analytics

Geri dönüşümler yaptığımız reklam harcamaların sağlamasının yapıldığı noktalar. Analitik servisleri bu konuda çok güzel araçlar sunuyor. Sayfalarımızı bu tarz hizmetlerle entegre etmemiz ise sayfalarımıza, ürünlerimize atanan ve bize has anahtarlar vasıtası ile oluyor. UA anahtarları bunlardan biri.

UA anahtarlarını kullanarak, aynı anahtarı kullanan sitelere erişebilirsiniz. http://www.gachecker.com/ ve http://moonsearch.com/analytics/ sitelerini ziyaret ederek elde ettiğiniz UA anahtarları ile sorgulama yapabilirisiniz.

Evren'e ufuk açıcı yazısından ötürü tebrik ve teşekkürlerimizi sunuyoruz.

Evren'in yazısına ulaşmak için lütfen tıklayınız.