open source

Açık Kaynak Kodlu Yazılımlara Güvenlik Açısından Katkı Sağlamak

by

Bir uygulamanın açık kaynak kodlu olmasının bir çok artısı bulunmaktadır. Bu artıların en başında ise güvenirlilik ve geliştirilebilirlik gelmektedir. Bizim için en önemli olan konu ise tabiki de güvenlik.

2005 yılından bu yana adını en fazla duyduğum ve hemen hemen hepsini kullandığım popüler açık kaynak kodlu web uygulamalarına baktığımız;

  • WordPress
  • Joomla
  • PhpBB
  • PHP-NUKE ( hatırlayanlar ? )

Aklıma gelmekte. 2005 yılından bu yana açık kaynak kodlu web uygulamalarında güvenlik zafiyetleri tespit etmeye çalışmaktayım ve bu süreçte neler öğrendiğimi, bana ne gibi katkılar sağladığını ve en önemlisi bir çok insan tarafından kullanılan bir yazılıma nasıl katkı sağlayabildiğimden bahsedeceğim.

Açık Kaynak Candır

Kodlarını okuyamadığımız bir sistemi kullanmak tabikide güvenlik gerekçesiyle yanlıştır. Bir çok yazılım geliştirici veya güvenlik araştırmacısı tarafından kodları analiz edilen bir yazılımda güvenlik açıklarının tespiti ve bu açıklıkların kapatılması son derece hızlı olmaktadır. İnternet dünyasına damga vuran OpenSSL Heartbleed zafiyetinin kapatılması adeta bir kaç saat almıştır. Bir çok insanın “OpenSSL açık kaynak kodlu olmasaydı zafiyette tespit edilemezdi..” dediğini buradan görür gibiyim. İnanın OpenSSL açık kaynak kodlu olmasaydı heartbleed zafiyeti black hat hacker’lar tarafından gene tespit edilmiş olacaktı. Hatta ve hatta bu zafiyeti kapatana kadar günler haftalar geçecekti.

Bir zafiyeti giderebilmek veya zafiyeti tespit edebilmek için onlarca insanın bir anda açık kaynak kodlu bir projede source code “audit” yaptığını gördük. Benim için bu tavır, zamanını bu işe ayıran insanların olması çok önemli bir durum. Hatta ve hatta bir başka örnek vermek isterim; twitter üzerinde gördüğüm bir grup maddi kaygıları olmadan tüm WordPress plug-in’lerinde zafiyet araştırması yapıp bulguları bildirmeye başladılar. Düşünüyorumda şimdiye kadar en az 3-4 sızma testinde firmanın blog sayfasında ki güncellemesi yapılmamış plug-in sayesinde hedef network’e erişim sağlamıştık. Bunları sızma testlerinde biz yapabiliyorsak, black hat’lerin ne kadar zaman önce bunları yapmış olabileceğini düşünün.

Tüm bu anlattıklarımın neticesinde, açık kaynak kodlu bir projenin parçası olmak, en azından anladığım en iyi iş olan “güvenlik” alanında zafiyetler bulup bunları bildirmek beni gerçekten mutlu etmiştir.

Açık Kaynak Kod Okumak İnsanı Geliştirir

Beni en çok geliştiren noktanın bu olduğunu düşünmekteyim. Kod okumanın insana ne kadar katkı sağladığını anlatabilmem mümkün değil ama şu örneği vermek isterim, 2004-2006 yılları arasında PHP dilini bilmiyor olmama rağmen gaza gelip phpBB ve Jommla/Mambo’nun tüm kaynak kodlarını okumuştum. Günde 15 saat süren bu işkencenin ardından elde tutulur hiçbir şey görememiştim. Sanki hiçbir şey anlamamışım gibi geliyordu. Aradan 7-8 ay geçtikten sonra okuduğum o tüm kodların aklımda yer edindiğini ve bana neler kattığını fark ettiğim bir süreç yaşamıştım. Çünkü ilk defa işe yarar bir proje yazmaya çalışıyordum.

Açık Kaynak Kodlu Yazılımlara Güvenlik Noktasında Katkı Sağlamak

Açık kaynak kodlu projelere güvenlik bakış açısıyla katkı sağlamak veya sağlamaya çalışmak her güvenlik uzmanının yapması gerekenler şeylerden birisi olduğuna inanıyorum. Ancak ve ancak bu şekilde insan kendisini iyi düzeyde geliştirebilmektedir.

Örneğin geçtiğimizde günlerde pull request gönderdiğim bir projeden bashedebiliriz. Concrete5 popüler Top 10 açık kaynak kodlu web yazılımlarından bir tanesi. Kaynak kod analizi araçlarından bir tanesi üzerinde performans çalışması gerçekleştirmekteyim. Kendi yazdığım bir çok  test-case’ler de başarısız olan bu kaynak kod analizi yazılımını bir de gerçek hayat uygulamaları ile test etmek istedim. Bu noktada daha önceden bildiğim bir yazılım olan Concrete5’i tercih ettim. Yazılım bir çok güvenlik açığı bulduğunu söyledi, hepsini tek tek analiz ettiğim içlerinden bir tanesinin doğru olduğunu fark ettim ve ilgili PHP dosyasını açıp okuduğumda basit bir Reflected XSS zafiyeti vardı.

<? 
defined('C5_EXECUTE') or die("Access Denied.");
if (isset($_REQUEST['themeID'])) {
	// internal theme
	$url = REL_DIR_FILES_TOOLS_REQUIRED . '/themes/preview_internal?random=' . time() . '&themeID=' . intval($_REQUEST['themeID']) . '&previewCID=' . intval($_REQUEST['previewCID']) . '&ctID=' . intval($_REQUEST['ctID']);
} else {
	$url = REL_DIR_FILES_TOOLS_REQUIRED . '/themes/preview_external?random=' . time() . '&themeCID=' . intval($_REQUEST['themeCID']) . '&previewCID=' . intval($_REQUEST['previewCID']) . '&themeHandle=' . $_REQUEST['themeHandle'] . '&ctID=' . intval($_REQUEST['ctID']);
}
?>
<iframe id="previewTheme<?=time()?>" height="100%" style="width:100%; border:0px; " src="<?=$url?>"></iframe>

Zafiyet olan satıra erişilebilmesi için themeID isimli değişkenin var olmaması gerekmekte. Bu durumda encode edilmeyen $_REQUEST[‘themeHandle’] parametresi ekrana yazdırılmakta ve XSS zafiyeti meydan gelmekte.

Bu zafiyeti kapatarak projeye github üzerinden pull request gönderdikten 5-6 dakika sonra bir yorum geldi.

What about using h() instead of htmlentities()?

Ben zafiyeti gidermek adına built-in PHP fonksiyonlarından bir tanesini kullanmıştım. Ama gelen yoruma göre Concrete5 kendi framework’ünde h() adında bir fonksiyon tanımlayarak bu encoding işlemini gerçekleştirmekteymiş. Ardından bu fonksiyonun tanımlandığı yere gidip kodları okuduğumda framework bazlı bir tasarımda encoding işlemine daha farklı nasıl yaklaşılabildiğini gördüm ve açıkcası IntelRAD olarak hizmet verdiğimiz bazı projelerde değişiklik yapma ihtiyacı duydum.

Sonuç olarak Concrete5 projesinde bana ait bir kod bulunmakta ve daha da önemlisi belkide gelecekte bir concrete5 web sitesi yönetcisine gelebilecek phishing saldırısına engel olmuş bulunmaktayım. Bu benim için son derece mutluluk verici..

Tabi her güvenlik açığını pull request ile göndermeniz yanlış olacaktır. Kritik bir güvenlik açığı varsa bu durumda tüm internet dünyasına bunun var olduğunu, tam olarak nerede olduğunu belirtmiş olursunuz. Bu olayın bire bir aynısını geçtiğimiz aylarda yaşadım. Bu durumda teknik bir detay belirtmeden github üzerinde issue açılması ve iletişim adresi istenilmesi gerekmekte.

Bonefire v.0.7.1 Reinstall Admin Account Exploit

Proje yöneticisi açtığım issue üzerinde mail attı. Sürecin sonunda https://github.com/ci-bonfire/Bonfire/commit/9cb76c66babf89952c3d48279b026c59e198f46e bu commit’i gerçekleştirerek aşağıda yorumu yazmış bulunmakta.

Can’t believe we missed this, but thanks to Mehmet Dursun for reporting it and doing so in a very ethical manner.

No-CMS 0.6.6 rev 1 – Admin Account Hijacking / RCE Exploit via Static Encryption Key

https://github.com/goFrendiAsgard/No-CMS/issues/98 açtığım issue’da gerçekleşen konuşmadan tam olarak 2 saat sonra https://github.com/goFrendiAsgard/No-CMS/commit/39d6ed327330e94b7a76a04042665dd13f2162bd bu commit gerçekleşti ve zafiyet giderildi. Not olaraksa aşağıda yorum yapılmıştı..

Very good write up. I never know about it before.
I guess, for temporary fix, I can change the static-encryption-key mechanism.
But a real fix should be done by changing the CodeIgniter mechanism.
Thanks Mahmet. I’m glad you are the one who find this :)

Tüm bunların sonunda, bilgi ve tecrübe olarak ne kadar çok şey öğrendiğimi fark etmiş bulunmaktayım. Özellikle güvenlik uzmanı olarak geliştiricilerin düşünme yapısı, kod yazarken akıllarında oluşan akış diyagramlarını anlayabilme noktasında çok farklı şeyler tecrübe etmiş oldum.

Sonuç; açık kaynak kod CAN’dır.