Bu makalede, bir hacker’ın özel temasının kaynak kodunda NextCloud’un WordPress web sitesinde bir uzaktan kod yürütme (RCE) bulduğu kritik bir hata raporu hakkında konuşacağız. PHP’de güvenli olmayan seansizasyon kullanma konusunda uyarıcı bir hikaye döndürür ve kaynak kodu da kullanılabilir olduğunda hataların canlı web hedeflerinde nasıl sıklıkla bulunduğuna dair bir başarı öyküsü anlatır.
Güvensiz firalizasyon nedir?
Web uygulamalarının genellikle arka uç sunucusunda form ve kullanıcı verileri gibi değişkenler olarak kullanılmak üzere yapılandırılmış bilgileri geçmesi gerekir. Bunları arka uç programlama dilinin kolayca kullanabileceği formatlarda serileştirmek uygundur, ancak bu veriler kullanıcı girişi tarafından kontrol ediliyorsa genellikle tehlikeli olabilir. Bu aynı zamanda güvensiz seansizasyon olarak da bilinir.
Güvensiz sealizasyon, kullanıcı tarafından kontrol edilen serileştirilmiş veriler güvenli olmayan bir şekilde yüklendiğinde, RCE ve bir saldırganın sunucuda kod çalıştırarak web uygulamasına tam erişim sağlayabilmesine yol açtığında meydana gelir. Bu, savunmasız web hizmetinin ve ilişkili verilerin (potansiyel olarak hassas müşteri bilgileri dahil) bütünlüğü, gizliliği ve mevcudiyetinin risk altında olduğu anlamına gelir. Bu hata sınıfını test etmek ve iyileştirmek, bilgisayar korsanlarına uygulamanın veri modelini, teknoloji yığınını ve hatta bazen kaynak koduna erişimi iyi bir şekilde anlamasını sağlar.
Uzak Kod Yürütülmesinin İş Etkisi
- Veri ihlali: Saldırganlar, kuruluşunuzun web sunucularına RCE üzerinden eriştiklerinde, Web uygulamasının aynı bağlamında ve iznine sahip verilere erişebilirler. Bu, hassas müşteri kimlik bilgileri, PII (kişisel olarak tanımlanabilir bilgiler) ve bulut sağlayıcıları ve ödeme ağ geçitleri gibi önemli üçüncü taraf hizmetler için API anahtarlarına erişim anlamına gelir. Bu, finansal zarar, itibar hasarına ve düzenleyici uyumsuzluktan kaynaklanan yasal sorunlara yol açabilir.
- Hizmet Bozukluğu: Saldırganlar ayrıca web sitenizin kullanılabilirliğini bozmak için RCE’den kazanılan erişimi de kullanabilir. Bu bir kapatma veya hatta tahribat şeklinde olabilir. Web uygulamasının işletmenize kritikliğine bağlı olarak, bu ciddi finansal kayıplara ve itibar hasarına neden olabilir.
- Müşterilere zarar: Web Skiming gibi popüler saldırılar, müşteri kredi kartları ve kişisel bilgiler gibi ödeme bilgilerini çalmak için tasarlanmış skimmer’leri dağıtmak için WordPress’teki RCE güvenlik açıklarını kullanır. RCE yoluyla tehlikeye atmak, saldırganların keyfi senaryolar ve ziyaretçilerin yürüttüğü diğer kötü amaçlı yazılımlar enjekte edebileceği ve kendi müşterilerinize zarar verebileceği anlamına gelir.
Ayrıntılar: Hata Raporu
Bu özel durumda, hata NextCloud’un web sitesinde geliştirdikleri özel bir tema aracılığıyla bulunan bir RCE idi. Bilgisayar korsanı Lukas Reschke, nedenin çerezlerden kullanıcı girişi olmadığını açıklayan çok özlü bir rapor yazdı ve GitHub taahhüdlü bir permal bağlantısında tam olarak savunmasız kod satırını sağladı. Bir bakalım:
işlev nc_change_nf_default_value ($ default_value, $ field_type, $ field_settings) { if (isset ($ _ kurabiye[‘nc_form_fields’])) { |
Bu işlev form alanlarında bir şey yapıyor gibi görünüyor, ancak form alanları NC_Form_Fields adlı bir çerezde kullanıcı girişi tarafından kontrol ediliyor ve Lukas, serialize etme çağrısı yoluyla, içinizdeki alanlara, içinizdeki alanlara erişti.
Lukas ayrıca, NextCloud-Theme’nin büyük kod tabanında, aynı güvenlik açığını da içeren ayrı bir yerden bahsetti ve bize tüm kod tabanında serialize edilmeden anahtar kelimeyi arayarak bulduğunu ima etti:
$ pref_lang = ”; |
Serialize olmayan işlev için PHP belgelerine bir göz atalım:
Depolanmış bir gösterimden bir PHP değeri oluşturur. Değerleri depolamanın ve almanın ve bunları farklı işlevler ve sayfalar arasında geçirmenin uygun bir yoludur (örneğin, kullanıcılara bir form sunar, doldurmalarını ve geri göndermelerini sağlar). Belgeler ayrıca, bir hacker nesne en iyi hale getirme sırasında kod yükleyebilir ve yürütebileceğinden, güvenilmeyen kullanıcı girişini serialize () ‘e geçirmemesi için kırmızı bir afişte belirtilir.
İstismar
Ve yürütme için yük kodu tam olarak Lucas’ın yaptığı şeydir. WordPress örneğinde kurulduğu için Monolog çalıştığı gadget zincirinin bazı yüklerini test etti. Gadget’lar, çalışma koduna ve yüklü kütüphanelere ait işlevlerin amaçlanan bir etki elde etmek için kullanıldığı dönüş odaklı bir programlama (ROP) kavramıdır. Onun yüküne bir göz atalım:
Bu, Lukas’ın NC_Form_Fields’e koyduklarının base64 kod çözülmüş değeridir:
O: 37: “Monolog \ Handler \ fingerscrossedHandler”: 4: {s: 16: “*pasptrulevel”; i: 0; s: 10: “*işleyici”; r: 1; s: 9: “*tampon”; A: 1: {i: 0; a: 2: {i: 0; s: 2: “id”; s: 5: “seviye”; i: 100;}} s: 13: “*işlemciler”; a : 2: {i: 0; s: 3: “POS”; i: 1; S: 6: “Sistem”;}} |
Bu kod çözülmüş yükün okunması, serileştirilmiş değişkenlerin dahili PHP yapısını ortaya çıkardı.
PHP seansizasyon yükleri oluşturmak için popüler bir araç PHPGGC’dir. Bu repo’nun hızlı bir şekilde araştırılması, monolog kullanan birden fazla RCE zinciri ortaya çıkardı:
Aslında, PHPGGC’yi Monolog/RCE7 seçeneğiyle çalıştırmak, Lukas’ın sahip olduğu gibi görünen bir yük üretir:
git klonu https://github.com/ambionics/phpggc |
O: 37: “Monolog \ Handler \ fingerscrossedHandler”: 4: {s: 16: “*pasptrulevel”; i: 0; s: 10: “*işleyici”; r: 1; s: 9: “*tampon”; A: 1: {i: 0; a: 2: {i: 0; s: 2: “id”; s: 5: “seviye”; i: 0;}} s: 13: “*işlemciler”; a : 2: {i: 0; s: 3: “POS”; i: 1; S: 6: “Sistem”;}} |
Bir ROP aracı olarak istismar edilebilmek, bu durumda Monolog’da bir güvenlik açığı değildir, sanki birisi serialize yoluyla keyfi sınıflar yükleyebilirmiş gibi, kod yürütmek için birçok başka yol kullanabilirler. Bu durumda, Monolog sınıfı FingerscrossedHandler yapıcısı, arayanın, örneğin komutları yürüten sistem gibi keyfi bir işlevin çağrılmasını sağlayan bir parametre, $ işleyici içeriyordu.
Monolog kurulmamış olsa bile, bir WordPress web sitesinde güvensiz seansizasyon yoluyla RCE için çok sayıda araç kullanılabilir. WordPress’in kendisinde gadget’lar var:
Bilgisayar korsanları PHP Secute Secure Sesürleştirme Hatalarını Kaynak Kodda Nasıl Bulur?
Benzer hataları kapsamda başlatmak için, bilgisayar korsanları olarak “kaynak kodu” hedeflerine sahip arama programları ile başlayabiliriz:
Ardından, bir teknoloji olarak PHP olan hedeflere göre filtreleyebiliriz:
Ardından, programların kapsamlarına bakın ve tüm kaynak kodu indirin. Şimdi Ripgrep kullanarak bu komutla hepsini grep edebilirsiniz:
Şimdi sonuçlara bakın ve kullanıcı girişlerini bulun. Serialize etmek için iletilen kullanıcı girişini bulma işlemini hızlandırmak için, isteklerden güvensiz kullanıcı girişi içerebilecek PHP özel değişkenleri olan $ _Cookie, $ _GET, $ _POST ve $ _Request gibi anahtar kelimeler ekleyebilirsiniz:
rg ‘serialize.*(Çerez | GET | Post | İstek).*’. |
Regex’imizin doğru olduğunu doğrulamak için bazı savunmasız kodlara sahip bir test.php dosyası yapabiliriz:
Echo serialize ($ _ al[‘id’]); |
$ rg ‘serialize.*(Çerez | GET | Post | İstek).*’. |
PHP serileştirilmiş çerezleri dinamik olarak bulmak
HTTP geçmişinde PHP serileştirilmiş çerezleri bulmak için, Java koduna göre HTTP trafiğini filtrelemek için “Bambas” adlı yeni özelliği ile busık kullanabiliriz. Tüm istek ve yanıt gövdesi bize maruz kaldığından, her çerez boyunca döngü yapabilir ve potansiyel olarak PHP serileştirilmiş verileri içerip içermediğini kontrol edebiliriz.
Bunu yapmak için Burp’un Proxy’sine gidin -> HTTP geçmişi ve filtre ayarlarına tıklayın:
Şimdi “Bambda modu” nu tıklayın ve bu Bambda snippet’ine yapıştırın, ardından Uygula’yı tıklayın:
if (requestResponse.FinalRequest (). Hasheader (“çerez”)) { String Cookievalue = kv.split (“=”)[1]; |
Esasen, istek başlığındaki her çerez değerini döndürür ve normal bir ifade kullanarak düz metin veya Base64 kodlu PHP serileştirilmiş nesne modellerini kontrol eder. Regex, birçok varyasyon olan çok çeşitli PHP serileştirilmiş yükleri yakalamak için basit bir desen kullandığından yanlış pozitif olacağına dikkat edin.
Ve bunun gibi, test edebileceğimiz şüpheli görünümlü baz64 kodlu çerez değerlerine sahip NC_Form_Fields içeren üç istek bulduk.
İyileştirme
Güvensiz sealizasyonun neden olduğu RCE’den kaçınmak için, geliştiriciler, serialize etme gibi tüm güvensiz işlevlerin tüm örneklerini, nesnelerin içerebileceği konusunda daha katı olan daha güvenli kodlama teknikleriyle değiştirebilir. Bu, NextCloud’un, hata raporundan sadece birkaç gün sonra, bu özel güvenlik açığı için derhal ortaya çıkardığı yama:
Geliştiriciler, RCE için yüklenebilecek keyfi kod içeremeyen JSON_DECODE ile güvensiz işlevin yerini aldı. Lucas’ın bu hatayı bulmasına izin veren kaynak kodunun kullanılabilirliğinin, geliştiricilerin bir yama ile yanıt verebileceğini de büyük ölçüde geliştirdiğine inanıyoruz, çünkü bilgisayar korsanının bu hatanın her örneğinin kodda tam olarak nerede olduğunu vurgulamasını sağladı, NextCloud’un yönlendirdi. Yama çabaları.
Çözüm
Serialize to Serialize için tek bir işlev çağrısı, bir saldırganın web sunucusunda bir kabuk kazanma potansiyeli ile tüm web sitesini RCE’ye açtı. PHP’de bu güvenlik açığı sınıfını bulmak kapsamdaki kod tabanları arasında zor değildir ve ikisi de bunun için bir çalışma yükü oluşturmaz; Aslında, bilgisayar korsanı Lucas’ın sadece PHP’de değil, herhangi bir dil için kaynak kod varlıklarında hata bulmak için harika bir yaklaşım olduğunu vurgulamaktadır. Tehlikeli işlev çağrıları için grepping, kullanıcı tarafından kontrol edilen girdi alarak, daha sonra canlı bir hedefe karşı güvenlik açığını doğrulamak ve son olarak sunucuda zararsız bir komut yürüterek güvenlik etkisini göstermekle başlar.
HackerOne ile kuruluşunuzu güvensiz firalizasyondan koruyun
Bu, güvensiz bir firalizasyon kırılganlığının tehlikeli etkisinin sadece bir örneğidir ve bir saldırganın sömürülmesinin ne kadar kolay olduğu. Hackerone ve etik hackerlar topluluğumuz, organizasyonların, bir hizmet olarak (PTAA’lar), kod güvenlik denetimi veya diğer çözümleri, saldırganın bir keşfetme konusundaki zihnini göz önünde bulundurarak, bu hata ödülünü ve diğer güvenlik açıklarını belirlemelerine ve iyileştirmelerine yardımcı olmak için en iyi donanımlıdır. güvenlik açığı.
En iyi 10 Hackerone güvenlik açıklarının etkisi hakkında daha fazla bilgi edinmek için 7. yıllık Hacker Powered Güvenlik Raporunu indirin veya kuruluşunuzdaki güvensiz seansizasyon güvenlik açıklarını almaya başlamak için hackerone ile iletişime geçin.