Webinar: OWASP Ankara web uygulama sızma testlerinde ZAP kullanımı

Web uygulamalarının güvenlik seviyesinin değerlendirilmesi ve iyileştirilmesi için en etkili yöntemlerden birisi sızma testleridir.

14 Nisan 2020 günü düzenleyeceğimiz webinarda açık kaynaklı OWASP Zed Attack Proxy (ZAP) aracının web uygulaması sızma testlerinde kullanımına bakacağız. Webinarda başta aşağıdaki konular olmak üzere elimizden geldiğince uygulama yapacağız:

• Web uygulaması sızma testi süreci
• OWASP sızma testi rehberi
• Web uygulaması sızma testi kontrol listesi
• OWASP Zed Attack Proxy (ZAP)
• ZAP ile keşif çalışmaları
• ZAP ile pasif tarama
• ZAP ile aktif zafiyet taraması
• Bulguların değerlendirmesi
• OWASP Top 10
• Kurumsal zafiyet yönetimi döngüsü

Webinar tarihi: 14 Nisan 2020, Cuma 
Webinar saati: 14:00 
Kimler katılmalı: Web uygulama güvenliği konusunda nelere dikkat edilmesi gerektiğini, test sürecinin nasıl yürütüldüğü ve teknik bulguların nasıl ele alınması gerektiğini mrak eden herkes. 

Kayıt için: https://forms.gle/PLZskhXpu5DmohX79

Katılım bağlantısı webinar başlamadan 1 saat önce kayıt için kullanılan e-posta adresinde iletilecektir. 

Sorularınız için basaranalper@gmail.com

Webinar OWASP Ankara tarafından düzenlenmektedir.

OWASP (Open Web Application Security Project) yazılım güvenliğini iyileştirmek için çalışan, kar amacı gütmeyen bir kuruluştur.

Zoom Kullanıyorsanız Dikkat!

Geçtiğimiz hafta Zoom videokonferans sisteminin Facebook’la veri paylaştığına dair bazı haberler çıkmıştı, meğer dertlerimiz yeni başlıyormuş. 

Uzaktan/evden çalışmaya başladığımızdan beri dünya genelinde çok popular olan Zoom’la ilgili güvenlik sorunlarına her gün bir yenisi ekleniyor gibi. Geçen yılın haziran ayında ortaya çıkan ve Zoom’u etkileyen güvenlik zafiyetini çok azınız duymuş olabilir, malum o günlerde evlere hapsolmamıştık. Bu hafta 2 yeni güvenlik açığından faydalanan istismar kodunun duyurulması pek çok kuruluş için can sıkıcı olabilir. Ayrıntılarına https://objective-see.com/blog/blog_0x56.html adresinden ulaşabileceğiniz güvenlik açıkları, görüşmelerin uçtan uca şifreli olmadığının ortaya çıkmasıyla birleşince oldukça sıkıntılı bir tablo belirmektedir.

Dünyanın en popüler videokonferans çözümlerinden biri haline gelen Zoom’un kullanıldığı sistem üzerinde komut çalıştırmaya imkan veren güvenlik açıklarının nasıl istismar edilebildiğini uzun uzun anlatmış. Görünen o ki Zoom’un MAC işletim sistemine kurulum için kullandığı teknik MAC işletim sistemini hedef alan zararlı yazılımlarla aynı. MAC’te virüs olmaz diyen tanıdığınız varsa bu fırsatla onunla da bir konuşmak isteyebilirsiniz.

Zoom özelinde bugüne kadar karşılaşılan güvenlik sorunları şunlar oldu;

• Uyarı vermeden Facebook’la veri paylaşması
• MAC işletim sistemine kurulum tekniğinin zararlı yazılımlarda görülenlere yakın olması
• “Zoombombing” ile davetli olmayan kişilerin görüşmelere katılması
• Uçtan uca şifreli olamadığının ortaya çıkması

Kullanım kolaylığı açısından bakıldığında faydalı gibi duran Zoom kullanırken aşağıdaki konuları hatırlamakta fayda var;

1. Sosyal medya paylaşımlarınızda toplantı numarasının görünmemesine dikkat edin. Bunu okuyanların paylaştığını sanmıyorum ama çalışanlarınız “#evdencalis”, “#workathome” veya “#homeoffice” gibi minnoş hashtaglerle bu paylaşımları yapıyor olabilir. 
2. Toplantılara giriş kodu ekleyin. Mümkünse giriş kodunu davet maili ile değil, SMS gibi farklı bir platform üzerinden paylaşım. 
3. “Bekleme odası” seçeneğini aktif hale getirin.

Videokonferans için alternatif olarak JITSI (https://jitsi.org/) gibi açık kaynaklı alternatifleri de kullanabileceğinizi hatırlatmak isterim.

OWASP Ankara Webinar: Kuruluşlar daha açık, saldırılar daha etkin

Son zamanlarda yaşananlar pek çok kuruluşu uzaktan çalışmaya mecbur bıraktı. Bu süreçte internete açık olmadığı için "güvenli" olduğu düşünülen pek çok sistem ve uygulama doğrudan internete açılmış oldu. 

3 Nisan 2020 günü düzenleyeceğimiz webinarda aşağıdaki konuları ele alacağız;

1. Son 1 ayda yaşanan saldırılar
2. Uzaktan çalışmanın getirdiği değişiklikler
3. Uzaktan çalışma güvenliği (NIST Standartlarının kısa sunumu)
4. API güvenliği (API veya ara katman mimarisi için kullanılan çözümlerin güvenliği)
5. Uzak masaüstü (RDP) güvenliği
6. soru - cevap 

Webinar tarihi: 3 Nisan 2020, Cuma 
Webinar saati: 11:30 

Kayıt için:  https://forms.gle/pn4My8VcBwn5k89Y8    

Katılım bağlantısı webinar başlamadan 1 saat önce kayıt için kullanılan e-posta adresinde iletilecektir. 

Sorularınız için basaranalper@gmail.com
Webinar OWASP Ankara tarafından düzenlenmektedir.

OWASP (Open Web Application Security Project) yazılım güvenliğini iyileştirmek için çalışan, kar amacı gütmeyen bir kuruluştur.

Kısa fıkra: "Açık kaynaklı yazılımlarda arka kapı olmaz"

Geçtiğimiz hafta Windows sistemlere bulaşmış olabilecek zararlı yazılımları ve izinsiz erişimleri tespit etmeye yardımcı olabilecek çok basit bir uygulamayı ücretsiz yayımladım. (Uygulamanın ayrıntılarına https://sparta.com.tr/rontgen/ adresinden ulaşabilirsiniz.) Sonrasında çıkan 1-2 trolün söylediklerini ciddiye aldığımdan değil, açık kaynak yazılımların güvenlik seviyesine bakmak için iyi bir fırsat olduğu için yazıyorum.

“Açık paketlerde problem yok” yazmış mesela bir tanesi… Açık kaynaklı yazılımlara yerleştirilen arka kapılara bakalım öyleyse.

Güvenlikle ilgili başımıza dert olan birkaç hurafeden biridir bu. “Linuxlara virüs bulaşmaz” ve “MAClere kimse virüs yazmıyor” gibi bilimsel herhangi bir temele bağlayamadığımız konulardan birisi.

Açık kaynak kodlu yazılımlar daha mı güvenilir?

Genel algı bu yazılımların kaynak kodlarının açık olması sebebiyle pek çok kişi tarafından denetlendiği, dolayısıyla arka kapı yerleştirmenin mümkün olmadığı yönündedir. Ne yazık ki bu tezi çürütecek pek çok olay yaşandı. Bunlar phpmyadmin gibi çok geniş bir kullanıcı sayısına sahip yazılımları da etkiledi, daha az bilinen ssh-decorator Python kütüphanesini de etkiledi. Öncelikle herhangi bir açık kaynak yazılım projesine arka kapı eklenmesinin çok zor olmadığını kabul etmek gerekir. Dolayısıyla konu eklenen arka kapının tespit edilememesine geliyor. 

Açık kaynak kodlu yazılım projelerini iki ana gruba ayırabiliriz; ürün ve modül. “Ürün” olarak adlandırabileceklerimiz tek başına kullanılan yazılımlardır (örn: ProFTD, VSFTP veya PHPmyAdmin). “Modül” dediklerimse yukarıda sözünü ettiğim “ssh-decorator” gibi tek başına kullanılmayan ancak başka kodlar içerisine dahil edilenlerdir.

2018 yılında açık kaynaklı event-stream Javascript kütüphanesine bir arka kapı yerleştirildiği ortaya çıktı. Olay ortaya çıktığında event-stream kütüphanesi 2 milyondan fazla yazılım içerisinde kullanılıyordu. Açık kaynak yazılımın güvenliğine ayrıca dikkat edilmesi gerektiğine dair önemli bir nokta çünkü bunların bir kısmı bizim “ticari” olarak nitelendirdiğimiz yazılımların içerisinde. Yazılım geliştiriyorsanız veya size özel bir yazılım geliştiriliyorsa bunun içerisindeki açık kaynak yazılım oranını takip etmenizde fayda var. Böylece, en basiti GitHub’da bedava olan kodlara mı para veriyorsunuz yoksa gerçekten size özel mi yazılıyor görebilirsiniz. Bu konuda “açık kaynak kod oranı tespit hizmeti” veriyoruz ve bir müşterimizde açık kaynak kod oranı %90’nın üzerinde bir projeye rastladık. Bunun yanında bünyenizde kullanılan yazılımların içerisinde ortaya çıkması muhtemel bir güvenlik açığının da sizi nasıl etkileyeceğini takip etme şansınız olur. Biraz önce sözünü ettiğimiz event-stream kütüphanesi kuruluşunuzun bünyesinde bulunan açık kaynaklı veya ticari lisanslı herhangi bir yazılım içerisinde kullanılmış mı mesela?

Arka kapılar yazılımlardaki tek tehlike mi?

Asıl sorun daha büyük; yazılım hataları. Açık kaynak veya ticari lisanslı olsun yaızlımı geliştirenlerin tamamen iyi niyetli olduklarını düşünelim. Yaızlımın tasarlanma aşamasından geliştirmesine kadar pek çok noktada hatalar yapıldığını görüyoruz. Bunların sonucunda yazılımlarda güvenlik açıkları ve çeşitli hatalar meydana gelmektedir. Çok büyük açık kaynak kodlu projelerde birden fazla yazılımcının çalıştığını görebiliriz ancak daha küçük modüllerde genellikle tek kişinin ve günlük mesaisinin dışında kalan zamanlarda çalıştığı bir senaryo daha gerçekçi oluyor. Bu durumda insanın aklına şu geliyor; onlarca yazılımcısı, test mühendisi ve güvenli yazılım geliştirme süeci ve yatırımı olan Microsoft hata yaparken bu arkadaşların hata yapma ihtimali yok mu gerçekten? Elbette var ve genelde yazılım test konusuna ağırlık verilmediği için basit hataların (örn. Tanımlanmış değişkenin kod içerisinde hiç kullanılmaması, girdinin temizlenip çıktının temizlenmemesi, vb.) daha sık görülmesi muhtemeldir. Hataların bir kısmının yine yazılım geliştirme hijyen kurallarına uymamaktan kaynaklandığını görebiliyoruz (örn. Sınıfların tek bir işlev yapması, controller sınıflarının olmaması, vs.). 

2018 yılında BitPay ve CoPay kriptopara cüzdanı uygulamalarında kullanılan bir NodeJS kütüphanesinin arka kapı barındırdığı açıklanmıştı. Yazılım tedarik zincirimizin oluşturduğu riskleri değerlendirmezsek bizlerin de, özellikle yerli ve milli yazılım geliştirme konusunda gelişmeler yaşanırken, başını ağrıtabilecek bir konu haline gelebilir. Bu örnekte NodeJS kütüphanesine eklenen zararlı kod parçası sıradan bir arka kapı değil, özellikle kriptopara cüzdanı uygulamalarında kullanılması halinde devreye girmek üzere planlanmış bir arka kapıydı. Özetle birisi şunu düşünmüş: “Ticari lisanslı kriptopara cüzdanları var, bunlardaki paraları çalmak lazım. Bunun için ben arka kapıyı açık kaynak koldu bileşene yerleştireyim, nasılsa fark etmezler”. Kısmen haklıymış diyebiliriz çünkü arka kapının tespit edilmesi 3 aydan fazla sürmüş ve bu arada kriptopara cüzdanlarının 5.0.2 ile 5.1.0 arasındaki sürümlerini etkilemiş.

Nasıl oluyor da gözden kaçıyor?

Yukarıda verdiğim kriptopara cüzdanı örneğinde kullanılan arka kapı kodunun “okunabilir” formata getirilmiş hali aşağıda;

… Evet? Binlerce satırlık açık kaynak kodlu bir proje içerisinde hemen göze çarpacağını iddia edemezsiniz herhalde. Kaynak kod içerisine yerleştirilecek arka kapılar hayal ettiğimiz gibi “GET” veya “POST” olarak gönderilen bir HTTP talebinden biraz daha farklıdır. Bu da arka kapıları tespit etmeyi oldukça zorlaştırıyor. Üstelik proje içerisinde özellikle kaynak kod incelemesi yapmaya gönüllü olmuş kimse yoksa zaten tespit edilmesi neredeyse imkânsız. Bu kodu herhangi bir projenin Türkçe dil desteği paketine rahatlıkla yerleştirebiliriz. (Laf aramızda İstihbaratta çalışsam gece gündüz bu işle uğraşan bir ekibim olurdu ki hiç değilse belli başlı açık kaynaklı yazılımların kullanıldığı sistemlere erişimimiz olsun).

Açık kaynaklı yazılımların güvenliği

Açık kaynak kodlu bir yazılım kullanıyorsanız veya kuruluşunuza özel yazılımlar geliştiriliyorsa, bütçenizin el verdiği ölçüde, aşağıdaki kontrol maddelerini yerine getirmeye çalışmakta fayda olur;

• Açık kaynak kod kullanım oranını takip edin
• Kullanılan açık kaynak kod parçalarının envanterini tutun
• Güvenli yazılım geliştirme prensiplerine uyun
• Kaynak kod analizi yapın
• Yazılım testlerini yapın
• Güvenlik testlerini yapın
• Güncellemelerden sonra testleri tekrarlayın

Yazılım güvenliği teoride basit pratikte neredeyse imkansıza yakın bir konu olarak gündemimizde olmaya devam edecek.

 

TUBITAK Zararlı Yazılım Analizi Platformu

TÜBİTAK BİLGEM Siber Güvenlik Enstitüsü zararlı yazılım analizi platformunu duyurdu.

"Cuckoo kurmuşlar ya bişi diil" tarzı küçümsemeler yapanlar olacaktır elbette ama bunu genel şuursuzluklarına veriyorum. Kendine "DDoS uzmanı" diyenlerin "sunucunun fişini çekin" önerisinde bulunduğu ve "uzman" arkadaşların "eniştemin görücesinin Erzurumlu bir bacanağı var. Onun da çalıştığı yerde dahi heykır bir çocuk varmış. Heykır çocuk diyesiymiş ki yakında Türkiye'nin önemli kurumlarına çok büyük saldırı olacakmış." türü kıllandırmalarının olduğu bir ortamda bu tür gereksiz yorumları duymamayı çabuk öğrenip işin özüne odaklanmanın bir yolunu bulmanız gerekiyor. Aksi takdirde önemli adımları kaçırabilirsiniz.

Bence TÜBİTAK'ın Cuckoo kurması önemli bir adım. Her şeyden önce Türkiye'de zararlı yazılım faaliyetlerinin şimdiye kadar olmadığı kadar yakından takip edilmesine imkan sağlayacaktır. Buraya zararlı yazılım numuneleri yüklendikçe trendler ve istatistikler da gelişecek. Platformun aktif olarak kullanıldığını ve ilgi gördüğünü varsayarsak, bundan bir kaç yıl sonra "Salı öğleden sonraları Türkiye'deki kamu kurumlarının en çok fidye yazılım saldırısına maruz kaldıkları zamandır" gibi çok faydalı istatistikler de gelişecektir.
Bu projede çalışan herkese teşekkür ederim.

Platformu nasıl kullanıyoruz? 
https://zar.sge.gov.tr adresini ziyaret ettiğimizde bizi aşağıdaki ekran karşılıyor;

 Deneme amaçlı bir Wannacry fidye yazılım örneği yükledim.

Analiz biraz zaman aldığı için daha önce yüklenmiş başka bir zararlı yazılım örneğinin sonuç raporuna bakacağız. Yüklenen zararlı yazılım örneklerini "Uploaded Samples" sekmesinden "Analysis Report" olarak ilgili örneğin karşısında bulabilirsiniz.

Şüpheli dosyaları yükledikten sonra analiz raporunda bazı noktalara bakmakta fayda var.

Öncelikle raporun "İmzalar" başlığı bizim için önemli. İncelediğim örnekte (https://zar.sge.gov.tr/UploadedSamples/RaporGoster?cuckooTaskId=4390) aşağıdaki imzalar görünüyor;

Bunlar;

• Yüklenen dosyanın Virustotal üzerinde birden fazla antivirüs tarafından zararlı olarak tanımlanması. 
• Uygulamanın içerisinde şifreli veya sıkıştırılmış veri bulunması
• İnternet tarayıcısından bilgi çalması
• Windows başlatıldığında çalışacak biçimde kurulması.

"Statik Analiz" ve "Davranış Özeti" kısımları ise bize zararlı yazılımın davranışları hakkında bilgi verirken aynı zamanda bu zararlı yazılımı başka sistemler üzerinde tespit etmemizi sağlayacak önemli ipuçları veriyor. 

Zararlı yazılım analizi konusunda işinize yarayabilecek bazı araçları ele aldığım bir sunumu https://www.slideshare.net/AlperBasaran/zararl-yazlm-analizi-zet adresinden indirebilirsiniz. 

Virustotal'in tek başına kullanımı konusunda https://sibersavascephesi.com/mac-virusu-ve-virustotal-kullanimi/ adresindeki yazının faydası olacaktır. 

Kolay kullanılan, amaca hizmet eden bir uygulama gibi duruyor, devamının da aynı şekilde gelmesini dilerim. 

"Heykır" arkadaşlara ufak bir not:

Aşağıda görüldüğü gibi bazı XSS girişimleri olmuş. 

Sayfada giriş fonksiyonu olmadığı için XSS bulunsa bile ne işe yaracağını ben anlayamadım. Fikrinizi almak isterim gerçekten. Sonuçta aşağıdaki gibi bir şey olacak, XSS'in oturum çerezlerini çalmak için kullanılabileceğini biliyoruz ama, dediğim gibi sayfada giriş ekranı yok. Anlamadım gerçekten... Yardımcı olabilir misiniz?