Security.TXT, Self XSS+oAuth = Good XSS, Web Mining ve dahası

İyi Niyetli Hackerlara Yol Gösterin: Security.txt

Bounty programlarında olmayan web uygulamalarında zafiyet tespit eden hackerların yaşadığı en önemli sıkıntılardan biri, tespit ettikleri zafiyeti bildirebilecekleri iletişim kanalı bulamamaları. Çoğunlukla tespit edilen zafiyetler bu sebeple rapor edilemiyor.

İşte bu motivasyonla hazırlanan Security.txt adındaki taslak metin, web sitelerine, güvenlik politikalarını araştırmacılara duyurabilecekleri bir yol öneriyor.

Web kök dizininizde konumlandıracağınız bir Security.txt dosyası ile uygulamalarınızda bulunan zafiyetlerin hangi kanaldan size bildirilebileceği, şayet plain text olarak bildirilmesini istemiyorsanız, açık anahtarınızın URL'i, hangi domainlerin rapor scope'una dahil olacağından, zafiyetin kamuya açık olarak duyurulup duyurulmamasını isteyip istemediğinizi bu text dosyasında belirtebilmeniz mümkün.

Dosya case-insensitive yani küçük-büyük harf duyarlılığı olmaksızın 4 adet direktif içerebilir. Direktifler ve alabilecekleri değerler : (iki nokta) ile ayrılmaktadır.

Bir Security.txt dosyasında 4 adet direktif tipi olmasına rağmen, bu direktiflerle herhangi bir kısıt olmaksızın istediğiniz sayıda ayrıntı tanımlayabilirsiniz.

Örneğin Contact direktifi ile birlikte, zafiyet bulunması durumunda, hangi kanaldan sizinle iletişim kurulacağını belirtebilirsiniz.

Contact: [email protected]
Contact: +1-201-555-0123
Contact: https://example.com/security

Encryption direktifi ile, zafiyet bildirimleri için açık anahtar adresinizi belirtebilirsiniz.

Encryption: https://example.com/pgp-key.txt

Açık anahtarın kendisi yerine URL'i paylaşmak Security.txt 'yi temiz ve okunaklı tutmak açısından mantıklı. İleride bu Security.txt dosyası bounty servisleri tarafından parse edilecek olursa, olası hataları da engelleyecektir.

Açık anahtar güvenli bir bağlantı üzerinden servis edilmeli.

Zafiyetin duyurulması konusundaki izin ve sınırları da Security.txt dosyasında Disclosure talimatı ile belirtebilirsiniz.

Disclosure: Full | Partial | None

Üç farklı değer alabilen bu direktifte, Full seçeneğini kullandığınız takdirde zafiyet ayrıntılarının tamamının kamuya açık paylaşılabileceğini, Partial ile buna kısmen müsaade ettiğinizi, None seçeneği ile de hiçbir şart altında kabul etmediğinizi belirtebilirsiniz.

Hata avcılarının tek motivasyonlarının bounty olduğunu düşünüyorsanız yanılıyorsunuz. Onur listesinde kendilerine tahsis ettiğiniz mütevazi bir köşe ile gönüllerini fethedebilirsiniz. Security.txt'de Hall-of-Fame ya da daha önceki araştırmacıların yer aldığı sayfalarınızın linklerine yer vererek, bu centilmen hata avcısını ağırlayacağınız köşenizden haberdar edebilirsiniz.

Acknowledgement: https://example.com/hall-of-fame.html

Güvenlik açısından birkaç noktaya da temas edilen taslak metinde, hassas bilgilerin Security.txt ile ifşa edilmemesi gerektiğine ve sistem üzerinde sınırlı yetkiye sahip bir saldırganın, Security.txt dosyasını değiştirebildiği takdirde zafiyet raporlamaları kendi kontrolündeki adreslere yönlendirilebileceği belirtiliyor.

Taslak metnin tamamı için lütfen tıklayınız.

Reklamlar Bitti - Şimdi Mining Zamanı!

En popüler Torrent sitelerinden biri olan The Pirate Bay'ın, ziyaretçilerinin CPU'larını kullanarak bir kripto para türü olan Monero ürettiği tespit edildi.

Ziyaretçilerin onayı olmadan denenen bu yöntem ile rahatsız edici reklamlara bir son vermek istediğini belirten The Pirate Bay, bu vesile ile gelir modellerinin geleceği konusunda da yeni bir tartışma başlattı.

Monero adlı kripto para üretiminde Coin Hive isimli servisi kullanan The Pirate Bay, gelen tepkiler üzerine açıklama yaparak, kullanıcıların görüşlerine müracaat etti. CPU gücünün yalnızca yüzde 20-30 'luk bir diliminin kullanıldığına dikkat geçen site, bu işlemin sadece bir browser tabı ile sınırlı olduğunu belirtti.

AdBlocker ile rahatsız edici reklamlara karşı bir silahı olan son kullanıcı bu yeni gelir modelinde kendini nasıl koruyacak? Bunun yolu webin doğasını anlamakla mümkün. Şimdilik okurlarımıza NoScript isimli browser pluginini öneriyoruz.

Browser Security White Paper

Web güvenlikçisinin başucu kitaplarına yenileri eklendi: Browser Security White Papers. Alman güvenlik şirketi Cure53 ve X41 D-Sec GmbH tarafından Google sponsorluğunda hazırlanan araştırmalar, client-side güvenliğin yapı taşlarını ayrıntıları ile açıklıyor. Her iki döküman, ayrıca bu özelliklerin Chrome, IE Edge ve MSIE browserlarındaki karşılaştırmalı metriklerini de sunuyor.

Safari ve Firefox browserların karşılaştırma metriklerine dahil edilmemesi ise dikkat çekici.

Cure53'ün hazırladığı metinde ise bunun açıklaması olarak sunulan gerekçe ise doğrusu tatmin etmiyor:

2011 yılından beri yapılan en ciddi araştırma olarak göz dolduran çalışma, uzun bir süre başucu kaynaklarımız arasında yer alacak gibi görünüyor.

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

Tarayıcınızdan İşletim Sisteminize Erişin

Tarayıcınızdan işletim sisteminize erişmek ister miydiniz? Bu site sayesinde mümkün!

Haberimize konu olan site tarayıcıdan ister kullanıcı arayüzü isterseniz konsol olarak ulaşabileceğiniz Linux, Windows 2000 ve FreeDOS dağıtımlarını sunuyor. Üstelik RAM vb ayarlamaları da yapabilmek mümkün. Teknik detaylar için https://bellard.org/jslinux/tech.html

Ichidan - Dark Web'i Aydınlatan Fener!

Güvenlik camiasının Google'ı shodan.io web sitesinin bir benzeri Tor network için oluşturulmuş durumda.

Servis ".onion" uzantılı web sitelerini crawl ederek, açık servisleri olup olmadığını, şayet açıksa hizmet veren servisin bilgilerini topluyor.

Ichidan adı ile bilinen web sitesi Tor networkünü incelemek isteyenler için önemli bir araç olacaktır.

Japonca'da ilk adım, başlangıç anlamına gelen Ichidan 'ın sitesine erişmek için, ichidanv34wrx7m7.onion adresini kullanabilirsiniz.

SSRF-Testing

SSRF zafiyeti ile ilgili bir çok farklı test ortamı oluşturan Predrag Cujanović, bu çalışmasını Github reposu üzerinden bizlerle paylaşıyor.

Cujanović çalışmasında test ortamlarını hazırlarken kendi üretkenliğinin yanı sıra, yapılan sunumlardaki örnekleri incelemek, bug bounty kapsamında bulunan güvenlik açıklarını incelemek gibi yöntemler izleyerek zafiyet test kapsamını geniş tutmuştur.

Kendinizi SSRF konusunda test etmek isterseniz mutlaka göz atın deriz.

Self-XSS'i oAuth ile İstismar Etmek

Bir sistemde Self-XSS bulduğunda omuzları düşenlerden misiniz? Diyelim ki profil editleme fonksiyonunda bir XSS var, gizli soruya cevap olarak verdiğiniz girdiye XSS payloadu enjekte edebiliyorsunuz. Fakat bunu sizden başka kimse göremeyecek.

Şanslıysanız ve sitede login CSRF var ise, kendi kontrolünüzdeki bir hesaba login olunmasını zorlayarak bunu tetikleyebilirsiniz. Fakat ya yoksa?

Tüm olanaklar tükenmiş gibi görünebilir ama bunun böyle olmadığını düşünen Pakistanlı bir güvenlik araştırmacısı,Shawar Khan, farklı bir senaryo ile hayal dünyamızın sınrılarını genişletti.

Dropbox, firma hesapları ile Dropbox accountlarının dosya paylaşımında bulunduğu bir özellik sunuyor. Bu özelliği inceleyen araştırmacı bir kaç eksik tespit ediyor.

Tespit ettiği en önemli noktalardan birisi, dosya yüklerken dosya adları yerine XSS payloadları kullanabiliyor oluşu. Pek çok XSS payloadu deneyen araştırmacı, sadece img tagi ile XSS payloadını enjekte edebilmesinden hareketle sistem tarafında img tagını gözden kaçıran bir blacklist olduğu görüşünü belirtiyor.

Fakat yüklediğiniz bu dosyayı ancak kendi dashboard’unuzda görebileceksiniz. Yukarıda da zikrettiğimiz gibi, kullanıcıya XSS payload ile isimlendirilen dosyayı yüklemesini istemek abesle iştigal olacaktır, diğer yandan sizin hesabınıza giriş yapmasını istemek de öyle.

O takdirde kullanıcıyı ziyareti ile birlikte sizin Dropbox hesabınız ile oturum açmaya zorlayan bir mekanizma kurmalısınız. Maalesef bu Login CSRF değil.

Bu noktada Khan'ın hedef sitenin oAuth implementasyonunda tespit ettiği bir konfigürasyon hatası devreye giriyor.

Uygulamanıza Dropbox ile erişmenizi sağlayan bir oAuth isteğini bu aşamada kullanabiliyorsunuz:
https://www.dropbox.com/oauth2/authorize?response_type=code&client_id={Client_ID}&redirect_uri=https://site.com/path/to/api/oauth

Yetkiyi verdiğiniz takdirde aşağıdaki gibi bir istek Dropbox tarafından tetiklenecek:

GET /path/to/api/oauth?code={TOKEN_HERE} HTTP/1.1
Host: site.com
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://www.dropbox.com
Cookie: _ga=[removed]; io=[removed]; session=[removed]; session.sig=[removed]
Connection: close

Yukardaki isteğe yakından bakıldığında istek içindeki tek doğrulama mekanizmasının token olduğunu görebiliriz. Saldırgan token paremetresini URL üzerinden kontrol edebileceğinden ve burada CSRF ataklarına karşı harici bir önlem alınmadığından, ilgili istek saldırı amaçlı istismar edilebilir. Yani aşağıdaki linki hedef kişiye göndererek sizin elde ettiğiniz oturumla Dropbox gezinimine devam etmesini sağlayabilirsiniz:

https://site.com/path/to/api/oauth?code={TOKEN_HERE}

Böylece adında XSS payloadu olan dosya da dashboard da gözükmüş ve XSS tetiklenmiş oluyor.

Yazının ayrıntıları için, Shawar Khan'ın blogunu ziyaret edebilirsiniz.