Uzaktan kod çalıştırma (RCE) nedir, neden en tehlikeli açık türüdür?

Uzaktan kod çalıştırma (RCE, Remote Code Execution), saldırganın başka bir yerdeki bir sisteme kendi komutlarını çalıştırtabilmesi demek. Bir web sunucusunda, bir e-posta cihazında, bir güvenlik duvarında ya da bir telefonda RCE açığı varsa, saldırgan oraya fiziksel olarak dokunmadan o sistemi kendi bilgisayarı gibi kullanabiliyor. Bu yüzden güvenlik dünyasında RCE açıkları en ciddiye alınan açık türü.

Diğer açık türlerini düşünün. Bir bilgi sızdırma açığı saldırgana bazı verileri gösterir. Bir hizmet engelleme açığı sistemi bir süreliğine çökertir. Bir yetkilendirme açığı saldırganın görmemesi gereken bir sayfaya ulaşmasını sağlar. RCE ise bunların hepsini kapsayabilir, çünkü sistemde kod çalıştırabilen biri, o sistemin yapabildiği her şeyi yapabilir. Zafiyet tablomuzdaki 9 ve üstü puanların büyük çoğunluğunun bu türden olması tesadüf değil.

Mantık hep aynı

RCE açıkları farklı biçimlerde ortaya çıksa da arkasındaki mantık hep benzer. Uygulama dışarıdan gelen bir veriyi işlerken bir hata yapıyor ve bu veri, programın çalıştırdığı bir komuta ya da koda dönüşüyor. Saldırgan da isteğini buna göre hazırlıyor. SQL injection, XSS ve hatta prompt injection de aynı ailenin üyeleri: Hepsinde sorun, verinin bir anda komuta dönüşmesi. Fark, komutun nerede çalıştığında. SQL injection’da veritabanında, XSS’te kurbanın tarayıcısında, RCE’de ise doğrudan sunucunun kendisinde.

Kod çalıştıktan sonra ne olur?

Kod bir kez çalıştığında gerisi saldırganın amacına kalıyor. Sitede yazdığımız olaylarda tekrar tekrar gördüğümüz bir sıra var:

İlk adım, kalıcılık. Saldırgan, açık kapatılsa bile geri dönebilmek için sisteme bir arka kapı bırakıyor. Bu çoğu zaman bir web kabuğu oluyor: sunucuda duran ve saldırganın tarayıcıdan komut göndermesine izin veren küçük bir dosya. Nextcloud saldırılarında saldırganlar uygulamanın klasörüne shx ile başlayan PHP dosyaları bıraktı. BeyondTrust saldırılarında ise SAWFLY adlı, beklenen parametre gelmediğinde “sayfa bulunamadı” yanıtı vererek kendini gizleyen bir web kabuğu kullanıldı.

İkinci adım, yetki yükseltme ve bilgi toplama. Saldırgan sistemdeki parolaları, erişim anahtarlarını ve yapılandırma dosyalarını topluyor. Bunlar çoğu zaman başka sistemlerin kapısını açıyor.

Üçüncü adım, ağda ilerleme. Ele geçirilen sunucu, kurumun iç ağına açılan bir köprü oluyor. Saldırgan oradan diğer sunuculara, veritabanlarına ve kullanıcı bilgisayarlarına uzanıyor.

Son adım, amaca ulaşma. Amaç casusluksa veriler sessizce dışarı çıkarılıyor. Amaç para ise fidye yazılımı kuruluyor ya da AhsayCBS saldırılarında olduğu gibi sunucuya kripto para madencisi yerleştiriliyor.

Kod hangi yetkiyle çalışıyor?

RCE açıklarında hasarın büyüklüğünü iki şey belirliyor. Birincisi, saldırının giriş gerektirip gerektirmediği. Giriş gerektirmeyen bir RCE, internetteki herkesin deneyebileceği bir açık demek. FortiMail ve Citrix NetScaler açıklarının CVSS puanının 9’un üstünde olmasının nedeni bu. İkincisi, kodun sistemde hangi kullanıcıyla çalıştığı.

Zammad saldırısı bunu iyi gösteriyor. İlk açık saldırgana sunucuda kod çalıştırma imkânı verdi, ama sadece Zammad’ın kendi kullanıcısının yetkisiyle. Saldırgan ikinci bir açıkla bu kullanıcıyı root yaptı ve sunucunun tamamını ele geçirdi. Uygulamaları root yetkisiyle değil, kendi sınırlı kullanıcılarıyla çalıştırmak bu yüzden önemli. İkinci adımı zorlaştırıyor, saldırganı en azından bir açık daha bulmak zorunda bırakıyor.

Bulut ve sanallaştırma ortamlarında bu katmanlara bir yenisi ekleniyor. Bir sanal makinede kod çalıştıran saldırgan, o makinenin içinde hapsolmuş durumda. Ama Ekim ortasında Linux çekirdeğinde kapatılan ve PwnEscape adı verilen açık gibi, sanal makineden ana sunucunun belleğine uzanmaya izin veren açıklar, bu duvarı da delebiliyor. Bu yüzden katmanlı savunma, yani her katmanın kendi başına bir engel oluşturması, RCE’ye karşı en sağlam yaklaşım.

RCE nereden çıkar?

Uzaktan kod çalıştırmaya giden yollar farklı olabiliyor. Sitede yazdığımız açıklar dört farklı yolu gösteriyor.

Girdi doğrulama ve komut enjeksiyonu. Citrix NetScaler’daki açıkta sorun, gelen verinin yeterince denetlenmemesi. Nextcloud açığında da uygulama, gelen istekteki metinle bir kabuk komutu oluşturuyordu. Bu türe işletim sistemi komut enjeksiyonu deniyor ve en eski, en iyi bilinen RCE türlerinden biri.

Bellek hataları. Apple’ın CoreGraphics açığı bir bellek hatası: Özel hazırlanmış bir dosya, programın ayrılan alanın dışına yazmasına yol açıyor. C ve C++ gibi belleği programcının yönettiği dillerde yazılmış yazılımlarda sık görülüyor. NGINX’te kapatılan açıklar ve Chrome’un her ay kapattığı açıkların büyük kısmı bu türden.

Dosya yazma. FortiMail açığı doğrudan kod çalıştırmıyor, saldırgana sisteme istediği dosyayı yazma imkânı veriyor. Ama doğru yere yazılan bir dosya, sistem onu çalıştırdığında kod çalıştırmaya dönüşüyor. Dizin aşımı (path traversal) açıkları bu yüzden çoğu zaman RCE’ye kapı aralıyor.

Güvensiz veri çözme ve şablon motorları. SharePoint’teki ToolShell açıklarında sunucu, dışarıdan gelen bir veri nesnesini kontrol etmeden açıyor ve bu nesnenin içine gizlenmiş kod çalışıyor. Benzer bir mantık şablon motorlarında da var. Magento’daki BlockStrap açığında e-posta şablonlarını işleyen motor, içerideki bir ifadeyi ikinci kez işlerken onu komut olarak çalıştırabiliyor.

Nasıl korunulur?

Korunmanın yolu tek değil, çünkü RCE’ye giden yollar da tek değil. Ama birkaç ilke hepsine karşı işe yarıyor:

• Yamaları hızlı kurun. RCE açıklarının yaması çıktığında saldırı kodunun ortaya çıkması günler, bazen saatler alıyor. Özellikle internete açık sistemlerde ve KEV listesindeki açıklarda bekleme lüksü yok.
• İnternete açıklığı azaltın. Yönetim arayüzlerinin internete açık olmaması, giriş gerektirmeyen RCE’lerin büyük kısmını etkisiz bırakıyor. İnternetten görünmeyen bir arayüze, açık ne kadar ciddi olursa olsun dışarıdan saldırılamaz.
• Uygulamaları sınırlı yetkiyle çalıştırın. Bir web uygulamasının root ya da yönetici yetkisine ihtiyacı yok. Kod çalışsa bile saldırgan sınırlı bir alanda kalmalı.
• Sistemleri ayırın. İnternete açık bir sunucunun iç ağdaki her sisteme ulaşabilmesi gerekmiyor. Ağı bölümlere ayırmak, ele geçirilen bir sunucunun köprü olmasını zorlaştırıyor.
• Değişiklikleri izleyin. Web klasörlerinde yeni ortaya çıkan dosyalar, beklenmedik süreçler ve sunucudan dışarıya giden olağandışı bağlantılar, RCE’nin kullanıldığının ilk işaretleri oluyor.

Bir RCE açığı yama çıkmadan kullanılmaya başladıysa, yani bir sıfırıncı gün söz konusuysa, üreticinin geçici önlemleri ilk savunma hattı oluyor. Yamayı kurduktan sonra da sistemin daha önce ele geçirilip geçirilmediğine bakmak gerekiyor, çünkü yama açığı kapatır ama saldırganın bıraktığı arka kapıyı silmez.