Bu bölümde, PHP, Ruby ve Java deserializasyonundan örneklerle bazı yaygın senaryoları nasıl sömürdüğünüzü öğreteceğiz. Güvensiz deserializasyonu sömürmenin aslında birçok insanın düşündüğünden çok daha kolay olduğunu göstermeyi umuyoruz. Bu, blackbox testi sırasında bile önceden oluşturulmuş gadget zincirlerini kullanabilirseniz geçerlidir.
Güvensiz deserializasyonu nasıl tanımlanır?
Güvensiz deserializasyonu tanımak, whitebox veya blackbox test yapmış olmanıza bakılmaksızın oldukça basittir.
Denetim sırasında, web sitesine iletilen tüm verilere bakmalısınız ve serileştirilmiş veri gibi görünen her şeyi tanımlamaya çalışmalısınız. Serileştirilmiş veri, farklı dillerin kullandığı biçimi bildiğiniz takdirde nispeten kolayca tanımlanabilir. Bu bölümde, hem PHP hem de Java serileştirmesinden örnekler göstereceğiz. Serileştirilmiş veriyi tanımladıktan sonra onu kontrol edip edemediğinizi test edebilirsiniz.
Tavsiye
Burp Suite Professional kullanıcıları için, Burp Scanner, serileştirilmiş nesneler içerdiği görünen HTTP iletilerini otomatik olarak işaretleyecektir.
PHP serileştirme biçimi
PHP, genellikle insan tarafından okunabilir bir dize biçemi kullanır; harfler veri türünü temsil ederken sayılar her girişin uzunluğunu temsil eder. Örneğin, aşağıdaki özelliklere sahip bir User nesnesini düşünün:
$user->name = "carlos";
$user->isLoggedIn = true;
Serileştirildiğinde, bu nesne şöyle görünebilir:
O:4:"User":2:{s:4:"name":s:6:"carlos"; s:10:"isLoggedIn":b:1;}
Bu şu şekilde yorumlanabilir:
O:4:"User" - 4 karakterlik "User" sınıf adına sahip bir nesne
2 - Nesnenin 2 özelliği bulunuyor
s:4:"name" - İlk özelliğin anahtarı 4 karakterlik "name" dizesidir
s:6:"carlos" - İlk özelliğin değeri 6 karakterlik "carlos" dizesidir
s:10:"isLoggedIn" - İkinci özelliğin anahtarı 10 karakterlik "isLoggedIn" dizesidir
b:1 - İkinci özelliğin değeri boolean değeri true'dur
PHP serileştirmesi için kullanılan yerel yöntemler serialize() ve unserialize() yöntemleridir. Kaynak kod erişiminiz varsa, unserialize() yöntemini kodun herhangi bir yerinde aramaya başlamalı ve daha fazla inceleme yapmalısınız.
Java serileştirme biçimi
Java gibi bazı diller, ikili serileştirme biçimlerini kullanır. Bu daha zor okunabilir, ancak bazı belirgin işaretleri nasıl tanıyacağınızı bildiğiniz sürece serileştirilmiş verileri hala tanıyabilirsiniz. Örneğin, serileştirilmiş Java nesneleri her zaman aynı baytlarla başlar ve bu baytlar hexadecimal olarak ac ed olarak kodlanır ve Base64'te rO0 olarak temsil edilir.
java.io.Serializable arabirimini uygulayan herhangi bir sınıf serileştirilebilir ve deserializasyon yapılabilir. Kaynak kod erişiminiz varsa, InputStream'dan veri okumak ve deserializasyon yapmak için kullanılan readObject() yöntemini kullanan kodları göz önünde bulundurmalısınız.
Serileştirilmiş nesneleri manipüle etme
Bazı deserializasyon zafiyetlerini sömürmek, serileştirilmiş bir nesnede bir özelliği değiştirmek kadar kolay olabilir. Nesne durumu saklandığı için serileştirilmiş veriyi inceleyerek ilginç özellik değerlerini tanımlayabilir ve düzenleyebilirsiniz. Daha sonra kötü amaçlı nesneyi web sitesine deserializasyon süreci aracılığıyla iletebilirsiniz. Bu, temel bir deserializasyon saldırısı için ilk adımdır.
Genel olarak, serileştirilmiş nesneleri manipüle etme konusunda iki yaklaşımınız vardır. Nesneyi doğrudan bayt akışı biçiminde düzeltebilir veya ilgili dili kullanarak yeni nesneyi oluşturup serileştirebilirsiniz. İkincisi, ikili serileştirme biçimleriyle çalışırken genellikle daha kolay bir yaklaşımdır.
Nesne özelliklerini değiştirme
Saldırgan verileri değiştirirken, saldırgan geçerli bir serileştirilmiş nesneyi koruduğu sürece deserializasyon süreci, değiştirilmiş özellik değerlerine sahip bir sunucu tarafı nesnesi oluşturacaktır.
Basit bir örnek olarak, bir web sitesini düşünün ki bu site, bir kullanıcının oturumuyla ilgili verileri bir çerezde saklamak için serileştirilmiş bir Kullanıcı nesnesi kullanıyor. Bir saldırgan, bu serileştirilmiş nesneyi bir HTTP isteğinde fark ederse, aşağıdaki bayt akışını bulmak için bu nesneyi çözümleyebilir:
O:4:"User":2:{s:8:"username";s:6:"carlos";s:7:"isAdmin";b:0;}
isAdmin özelliği açık bir ilgi noktasıdır. Bir saldırgan, özelliğin boolean değerini 1 (true) (doğru) olarak değiştirebilir, nesneyi yeniden kodlayabilir ve mevcut çerezini bu değiştirilmiş değerle üzerine yazabilir. İzole bir şekilde bu hiçbir etki yapmaz. Ancak, web sitesinin mevcut kullanıcının belirli yönetici işlevlerine erişip erişmediğini kontrol etmek için bu çerezi kullandığını varsayalım:
$user = unserialize($_COOKIE);
if ($user->isAdmin === true) {
// yönetici arayüzüne erişime izin ver
}
Bu zafiyetli kod, verilerin saldırgan tarafından değiştirilmiş isAdmin özelliği de dahil olmak üzere çerezden gelen verilere dayalı bir User nesnesi oluşturur. Serileştirilmiş nesnenin doğruluğu hiçbir noktada kontrol edilmez. Bu veriler ardından koşullu ifadeye geçirilir ve bu durumda kolay bir ayrıcalık yükseltmeye izin verir.
Bu basit senaryo doğada yaygın değildir. Ancak bu şekilde bir özellik değerini düzenlemek, güvensiz deserializasyon tarafından açığa çıkarılan büyük miktardaki saldırı yüzeyine erişimin ilk adımını gösterir.
Veri türlerini değiştirebileceğinizi öğrendik, ancak beklenmeyen veri tiplerini sağlamak da mümkündür.
PHP tabanlı mantık, farklı veri tiplerini karşılaştırırken (==) kullanılan gevşek karşılaştırma operatörünün davranışı nedeniyle bu tür manipülasyona özellikle savunmasızdır. Örneğin, bir tamsayı ile bir dize arasında gevşek bir karşılaştırma yaparsanız, PHP, dizeyi tamsayıya dönüştürmeye çalışır, yani 5 == "5" ifadesi true olarak değerlendirilir.
Alışılmadık bir şekilde, bu, bir sayı ile başlayan herhangi bir alfasayısal dize için de çalışır. Bu durumda, PHP, başlangıçtaki sayıya dayalı olarak tüm diziyi bir tamsayı değerine etkili bir şekilde dönüştürür. Dizinin geri kalanı tamamen yok sayılır. Bu nedenle, 5 == "bir şeyin 5'i" pratikte 5 == 5 olarak işlenir.
Bu daha da garipleşirken bir dizeyi tamsayı 0 ile karşılaştırmak düşünüldüğünde:
0 == "Örnek dize" // true
Neden? Çünkü dizide bir sayı yani 0 rakamı yoktur. PHP, bu tüm diziyi tamsayı 0 olarak işler.
Kullanıcı tarafından denetlenebilir verilerle birleştirildiğinde bu gevşek karşılaştırma operatörünün kullanıldığı bir durumu düşünelim. Bu potansiyel olarak tehlikeli mantık hatalarına neden olabilir.
$login = unserialize($_COOKIE)
if ($login['password'] == $password) {
// başarıyla giriş yap
}
Saldırgan, beklenen dize yerine tamsayı 0 içeren bir şifre özniteliğini değiştirdiğinde, koşul her zaman true dönecek şekilde saklandı. Şifre, bir sayı ile başlamadıkça, koşul oturum açma atlamasına olanak tanır. Unutmayın ki bu yalnızca deserializasyon veri türünü koruduğu için mümkündür. Kod doğrudan istekten şifreyi alırsa, 0 bir dizeye dönüştürülür ve koşul false olarak değerlendirilirdi.
Herhangi bir serileştirilmiş nesne biçiminde veri türlerini değiştirirken, serileştirilmiş verilerdeki tür etiketlerini ve uzunluk göstergelerini de güncellemeyi unutmamanız önemlidir. Aksi takdirde, serileştirilmiş nesne bozulur ve deserializasyon yapılamaz.
Doğrudan ikili biçimlerle çalışırken, BApp mağazasından temin edilebilen Hackvertor uzantısını kullanmanızı öneririz. Hackvertor ile serileştirilmiş verileri bir dize olarak değiştirebilirsiniz ve otomatik olarak ikili verileri günceller, konumları uygun şekilde ayarlar. Bu size manuel çaba tasarrufu sağlayabilir.
Uygulama işlevini kullanma
Sadece özellik değerlerini kontrol etmekle kalmayıp, bir web sitesinin işlevi aynı zamanda deserializasyon nesnesinden gelen veriler üzerinde tehlikeli işlemler de gerçekleştirebilir. Bu durumda, güvensiz deserializasyonu kullanarak beklenmeyen verileri iletebilir ve ilgili işlevselliği kullanarak zarar verebilirsiniz.
Örneğin, bir web sitesinin "Kullanıcıyı Sil" işlevinin bir parçası olarak, kullanıcının profil resmi, $user->image_location özniteliğindeki dosya yoluna erişilerek silinir. Bu $user, serileştirilmiş bir nesneden oluşturulmuşsa, bir saldırgan, image_location'ı herhangi bir dosya yoluna ayarlanmış bir değiştirilmiş nesneyi ileterek bunu sömürdü. Kendi kullanıcı hesabını silerken bu keyfi dosyayı da silecektir.
Bu örnek, saldırganın kullanıcı tarafından erişilebilir işlev aracılığıyla tehlikeli bir yöntemi manuel olarak çağırmasına dayanır. Ancak, güvensiz deserializasyon, verileri otomatik olarak tehlikeli yöntemlere ileten saldırıları oluşturduğunuzda çok daha ilginç hale gelir. Bu, "sihirli yöntemlerin" kullanılmasıyla mümkün olur.
Sihirli yöntemler
Sihirli yöntemler, belirli bir olay veya senaryo gerçekleştiğinde açıkça çağırmak zorunda olmadığınız özel bir yöntem alt kümesidir. Bunun yerine, belirli bir olay veya senaryo meydana geldiğinde otomatik olarak çağrılırlar. Sihirli yöntemler, farklı dillerde nesne yönelimli programlamanın yaygın bir özelliğidir. Sihirli yöntemler bazen yöntem adını çift alt çizgi ile ön eklemek veya çevrelemek suretiyle gösterilir.
Geliştiriciler, bir sınıfa sihirli yöntemler ekleyebilirler, böylece karşılık gelen olay veya senaryo meydana geldiğinde hangi kodun çalıştırılması gerektiğini önceden belirleyebilirler. Sihirli bir yöntemin ne zaman ve neden çağrıldığı yöntemden yönteme farklılık gösterir. PHP'deki en yaygın örneklerden biri __construct() sihirli yöntemidir ve bu yöntem, sınıfın bir örneği oluşturulduğunda otomatik olarak çağrılır, Python'daki __init__ gibi. Genellikle bu tür kurucu sihirli yöntemler, örneğin öznitelikleri başlatmak için kod içerir. Ancak geliştiriciler, sihirli yöntemleri istedikleri herhangi bir kodu çalıştırmak için özelleştirebilirler.
Sihirli yöntemler yaygın olarak kullanılır ve başlı başına bir güvenlik açığı temsil etmezler. Ancak, bu yöntemleri çalıştıran kodun saldırgan tarafından denetlenebilir verileri işlediği durumlarda tehlikeli hale gelebilirler, örneğin serileştirilmiş bir nesneden gelen veriler.
Bu bağlamda en önemlisi, bazı dillerin deserializasyon süreci sırasında otomatik olarak çağrılan sihirli yöntemlere sahip olmasıdır. Örneğin, PHP'nin unserialize() yöntemi, bir nesnenin __wakeup() sihirli yöntemini arar ve çağırır.
Java deserializasyonunda aynı şey, nesnenin başlangıç bayt akışından veri okumak ve serileştirilmiş bir nesneyi "yeniden başlatmak" için kullanılan ObjectInputStream.readObject() yöntemi için de geçerlidir. Bununla birlikte, Serileştirilebilir sınıflar, kendi readObject() yöntemlerini şu şekilde bildirebilir:
private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException
{
// uygulama
}
Tam olarak bu şekilde bildirilen bir readObject() yöntemi, deserializasyon sırasında çağrılan bir sihirli yöntem olarak davranır. Bu, sınıfın kendi alanlarının deserializasyonunu daha yakından denetlemesine izin verir.
Bu tür sihirli yöntemlere sahip sınıfları dikkatle incelemeniz önemlidir. Bunlar, nesnenin tamamen deserialize edilmeden önce serileştirilmiş nesneden web sitesinin koduna veri aktarmanıza olanak tanır. Bu, daha gelişmiş saldırılar oluşturmanın başlangıç noktasıdır.
Keyfi nesneler enjekte etme
Güvensiz deserializasyonu sadece web sitesi tarafından sağlanan nesneyi düzenleyerek sömürmenin mümkün olduğunu gördük. Ancak keyfi nesne türlerini enjekte etmek, çok daha fazla olasılığı açabilir.
Nesne yönelimli programlamada, bir nesnenin kullanabileceği yöntemler sınıfına bağlıdır. Bu n
edenle, bir saldırganın hangi nesne sınıfının serileştirilmiş veri olarak iletilmekte olduğunu manipüle edebilirse, deserializasyon sonrası ve hatta deserializasyon sırasında hangi kodun çalıştırılacağını etkileyebilir.
Deserializasyon yöntemleri genellikle deserializasyon işleminin neyi deserialize ettiğini kontrol etmez. Bu, herhangi bir serializable sınıfın nesnelerini iletebileceğiniz ve nesnenin deserializasyonuyla etkili bir şekilde keyfi sınıf örnekleri oluşturabileceğiniz anlamına gelir. Bu, bir saldırganın keyfi sınıf örnekleri oluşturmasına olanak tanır. Bu nesnenin beklenen sınıf olmaması önemli değildir. Beklenmeyen nesne türü, uygulama mantığında bir istisna oluşturabilir, ancak kötü amaçlı nesne bu zamana kadar zaten oluşturulmuş olacaktır.
Bir saldırganın kaynak koduna erişimi varsa, tüm kullanılabilir sınıfları detaylı olarak inceleyebilir. Basit bir saldırı oluşturmak için, sihirli deserializasyon yöntemlerini içeren sınıfları ararlar ve bunların herhangi birinin denetlenebilir veriler üzerinde tehlikeli işlemleri gerçekleştirip gerçekleştirmediğini kontrol ederler. Saldırgan daha sonra bu sınıfın serileştirilmiş bir nesnesini kullanarak sihirli yöntemini bir saldırı için kullanabilir.
Bu deserializasyon sihirli yöntemler içeren sınıflar ayrıca "gadget zinciri" olarak bilinen bir dizi yöntem çağrısını içeren daha karmaşık saldırılara başlamak için kullanılabilir.
Gadget zincirleri
Bir "gadget", bir saldırganın belirli bir hedefe ulaşmasına yardımcı olabilecek uygulamada var olan bir kod parçasıdır. Bir bireysel gadget, kullanıcı girdisiyle doğrudan zararlı bir şey yapmayabilir. Ancak saldırganın amacı, girdilerini başka bir gadget'a iletecek bir yöntemi çağırmak olabilir. Bu şekilde birden fazla gadget'ı birleştirerek, saldırgan girdilerini maksimum zarar verebilecek tehlikeli bir "sink gadget" içine iletebilir.
Anlaşılması önemlidir ki, diğer bazı saldırı türlerinin aksine, bir gadget zinciri, saldırgan tarafından oluşturulan zincir yöntemlerinin bir yükü değildir. Tüm kod zaten web sitesinde mevcuttur. Saldırganın kontrol ettiği tek şey, gadget zincirine iletilen verilerdir. Bu genellikle deserializasyon sırasında çağrılan bir sihirli yöntem kullanılarak yapılır ve bu bazen bir "başlatma gadgetı" olarak bilinir.
Gerçek dünyada, birçok güvensiz deserializasyon açığı yalnızca gadget zincirleri kullanılarak sömürülebilir. Bu bazen basit bir bir veya iki adımlık bir zincir olabilir, ancak yüksek riskli saldırıları başarıyla gerçekleştirmek için daha karmaşık bir nesne oluşturma ve yöntem çağırma dizisi gerekebilir. Bu nedenle gadget zincirleri oluşturabilme, güvensiz deserializasyonu başarılı bir şekilde sömürmenin temel yönlerinden biridir.
Önceden oluşturulmuş gadget zincirleri ile çalışma
Manuel olarak gadget zincirlerini tanımlamak oldukça zorlu bir süreç olabilir ve kaynak kod erişimi olmadan neredeyse imkansızdır. Neyse ki, ilk olarak deneyebileceğiniz önceden oluşturulmuş gadget zincirleri ile çalışmanız için birkaç seçenek bulunmaktadır.
Başka web sitelerinde başarılı bir şekilde sömürülmüş önceden keşfedilmiş zincirleri sağlayan bir dizi araç mevcuttur. Kaynak koduna erişiminiz olmasa bile, bu araçları kullanarak göreceli olarak az çaba harcayarak güvensiz deserializasyon açıklarını tanımlayabilir ve sömürebilirsiniz. Bu yaklaşım, sömürülebilir gadget zincirlerini içeren kütüphanelerin yaygın olarak kullanılmasının bir sonucudur. Örneğin, Java'nın Apache Commons Collections kütüphanesindeki bir gadget zinciri bir web sitesinde sömürülebilirse, bu kütüphaneyi uygulayan başka herhangi bir web sitesinin de aynı zinciri kullanarak sömürülebilir olabileceği anlamına gelir.
ysoserial
Java deserializasyon için bu tür bir araç olan "ysoserial" bulunmaktadır. Bu araç, hedef uygulamanın kullandığını düşündüğünüz bir kütüphandaki sağlanan gadget zincirlerinden birini seçmenizi ve çalıştırmak istediğiniz bir komutu iletmeyi seçmenizi sağlar. Ardından seçilen zincire dayalı uygun serileştirilmiş bir nesne oluşturur. Bu hala belirli bir deneme ve hata gerektirir, ancak kendi gadget zincirlerinizi manuel olarak oluşturmaktan çok daha az iş yoğundur.
Not
Java'nın 16 ve sonraki sürümlerinde, ysoserial'ı çalıştırmak için Java'nın komut satırı argümanlarını ayarlamalısınız. Örneğin:
java -jar ysoserial-all.jar \
--add-opens=java.xml/com.sun.org.apache.xalan.internal.xsltc.trax=ALL-UNNAMED \
--add-opens=java.xml/com.sun.org.apache.xalan.internal.xsltc.runtime=ALL-UNNAMED \
--add-opens=java.base/java.net=ALL-UNNAMED \
--add-opens=java.base/java.util=ALL-UNNAMED \
[payload] '[command]'
ysoserial'daki tüm gadget zincirleri, keyfi kod çalıştırmanıza olanak tanımaz. Bunun yerine, diğer amaçlar için kullanışlı olabilirler. Örneğin, aşağıdakiler gibi bazıları, güvensiz deserializasyonu hızlı bir şekilde neredeyse her sunucuda tespit etmenize yardımcı olabilir:
1. **URLDNS zinciri**, sağlanan bir URL için DNS sorgusu tetikler. En önemlisi, hedef uygulamanın belirli bir güvensiz kütüphane kullanmasına bağlı değildir ve her bilinen Java sürümünde çalışır. Bu, tespit amaçları için en evrensel gadget zinciri yapar. Trafikte bir serileştirilmiş nesne görürseniz, bu gadget zincirini kullanarak Burp Collaborator sunucusu ile DNS etkileşimi tetikleyen bir nesne oluşturmayı deneyebilirsiniz. Eğer bu gerçekleşirse, hedefinizde deserializasyonun gerçekleştiğinden emin olabilirsiniz.
2. **JRMPClient**, başlangıç tespiti için kullanabileceğiniz başka bir evrensel zincirdir. Bu, sunucunun sağlanan IP adresine bir TCP bağlantısı kurmaya çalışmasına neden olur. Unutmayın ki bir alan adı yerine ham bir IP adresi sağlamanız gerekiyor. Bu zincir, DNS sorguları dahil tüm çıkış trafiğinin firewall ile korunduğu ortamlarda kullanışlı olabilir. İki farklı IP adresi ile yükler oluşturmayı deneyebilirsiniz: yerel biri ve firewall ile korunan harici biri. Uygulama yerel bir adres için hemen yanıt veriyorsa, ancak harici bir adres için yanıtta gecikme oluyor ve bu nedenle yanıtta bir gecikme oluyorsa, bu gadget zincirinin çalıştığını gösterir çünkü sunucu firewall ile korunan adrese bağlanmaya çalıştı. Bu durumda, yanıtlar arasındaki ince zaman farkı, sunucuda deserializasyonun olup olmadığını tespit etmenize yardımcı olabilir, hatta kör durumlarda bile.
3. **PHP Generic Gadget Chains (PHPGGC)** gibi, güvensiz deserializasyon açıklarına sıkça rastlayan çoğu dil için benzeri kanıt-of-konsept araçlar bulunmaktadır.
Not
Önemli bir not olarak belirtmek gerekir ki, güvensiz deserializasyon açığı, web sitesinin kodunda veya kütüphanelerindeki gadget zincirinin sadece varlığı değil, kullanıcı tarafından kontrol edilebilir verilerin deserializasyonudur. Gadget zinciri, enjekte edildikten sonra zararlı verilerin akışını manipüle etmenin bir yolu sadece. Bu ayrıca güvenilmeyen verilerin deserializasyonuna dayanan çeşitli bellek bozulma açıklarına da uygulanır. Başka bir deyişle, bir web sitesi, her olası gadget zincirini kapatmayı başarsa bile hala açık olabilir.
Belgelenmiş gadget zincirleri ile çalışma
Hedef uygulamanın kullandığı çerçeve içinde bilinen gadget zincirlerini sömürmek için özel bir araç her zaman mevcut olmayabilir. Bu durumda, manuel olarak uyarlayabileceğiniz belgelenmiş saldırıları bulup bulunmadığınızı görmek her zaman değerlidir. Kodu ayarlamak, bazen dil ve çerçeve hakkında temel bir anlayış gerektirebilir ve bazen nesneyi kendiniz serileştirmeniz gerekebilir, ancak bu yaklaşım, sıfırdan bir saldırı oluşturmaktan çok daha az çabadır.
Hazır kullanılabilecek bir gadget zinciri veya belgelenmiş bir saldırı bulamazsanız bile, kendi özel saldırınızı oluşturmanıza yardımcı olabilecek değerli bilgilere sahip olabilirsiniz.
Kendi saldırınızı oluşturma
Hazır gadget zincirleri ve belgelenmiş saldırılar başarısız olduğunda kendi saldırınızı oluşturmanız gerekecektir.
Kendi gadget zincirinizi başarıyla oluşturabilmek için neredeyse kesinlikle kaynak kod erişimine ihtiyacınız olacaktır. İlk adım, bu kaynak kodu inceleyerek deserializasyon sırasında çağrılan bir sihirli yöntem içeren bir sınıfı tanımlamaktır. Bu sihirli yöntemin yürüttüğü kodu değerlendirin ve kullanıcı tarafından kontrol edilebilir özelliklerle doğrudan tehlikeli bir şey yapmadığını görmek için kontrol edin. Her ihtimale karşı bu her zaman kontrol edilmeye değer bir adımdır.
Sihirli yöntem tek başına sömürülemiyorsa, gadget zincirinizin başlatma gadgeti olarak görev yapabilir. Başlatma gadgetinin çağırdığı yöntemleri inceleyin. Bunlardan herhangi biri kontrol ettiğiniz verilerle tehlikeli bir şey yapar mı? Yapmazsa, bunların ardışık olarak çağırdığı her yönteme daha yakından bakın ve böyle devam edin.
Bu süreci tekrarlayarak erişebildiğiniz değerleri izleyin ve ya bir çıkmaza ulaşana kadar ya da kontrol edilebilir verilerinizin iletildiği tehlikeli bir "sink gadget" belirleyene kadar devam edin.
Uygulama kodu içinde gadget zinciri oluşturmayı başarılı bir şekilde nasıl gerçekleştireceğinizi çalıştıktan sonra, bir yük içeren serileştirilmiş bir nesne oluşturmanız gereken bir sonraki adım, kaynak koddaki sınıf bildirimini incelemek ve isteğiniz için gereken uygun değerlere sahip geçerli serileştirilmiş bir nesne oluşturmaktır. Daha önceki laboratuvarlarda gördüğümüz gibi, bu, dize tabanlı serileştirme formatlarıyla çalışırken oldukça basittir.
Java deserializasyon saldırısı oluştururken olduğu gibi, bir dizi işlem yaparken, özellikle mevcut bir nesneye küçük değişiklikler yaparken, baytlarla doğrudan çalışmaktan rahat hissedebilirsiniz. Ancak tamamen yeni bir nesneyi geçirirken gibi daha büyük değişiklikler yaparken, bu hızlı bir şekilde uygulanamaz hale gelir. Verileri kendiniz oluşturmak ve serileştirmek için hedef dilde kendi kodunuzu yazmak genellikle çok daha basittir.
Kendi gadget zincirinizi oluştururken, bu ek saldırı yüzeyini kullanma fırsatlarını ararken ikincil güvenlik açıklarını tetiklemek için bu ek saldırı yüzeyini kullanma fırsatlarına dikkat edin.
Kaynak kodunu dikkatlice inceleyerek, yüksek riskli saldırılar dahil olmak üzere uzun gadget zincirlerini keşfederek genellikle uzaktan kod çalıştırmayı içerebilecek yüksek riskli saldırıları oluşturmanıza olanak tanıyan daha uzun gadget zincirlerini keşfedebilirsiniz.
PHAR (PHP Archive) ile deserializasyonu nasıl sömürüleceğini incelemeye başladık. Ancak PHP'de unserialize() yönteminin açık bir şekilde kullanılmadığı deserializasyon açıklarını sömürmeyi incelemek bazen mümkün olabilir.
PHP, farklı protokolleri işlerken dosya yollarına erişmek için kullanabileceğiniz bir dizi URL tarzı sarmalayıcı (wrapper) sunar. Bunlardan biri phar:// sarmalayıcısıdır ve PHP Archive (.phar) dosyalarına erişim için bir akış arabirimi sağlar.
PHP belgeleri, PHAR manifest dosyalarının serileştirilmiş meta veriler içerdiğini göstermektedir. Önemli olan, phar:// akışına herhangi bir dosya işlemi uygularsanız, bu meta verilerin örtük olarak deserialization işlemine tabi tutulacağıdır. Bu, bir phar:// akışının, bu akışı bir dosya sistemi yöntemine iletebiliyorsanız, güvensiz deserializasyonu sömürmek için bir vektör olabilir demektir.
Açıkça tehlikeli dosya sistem yöntemleri, örneğin include() veya fopen() gibi yöntemler, web sitelerinin kötü niyetle kullanılma potansiyelini azaltmak için karşı önlemler uygulamış olabilirler. Ancak file_exists() gibi çok açık olmayan yöntemler, aynı şekilde korunmayabilirler.
Bu teknik aynı zamanda PHAR'ı sunucuya nasıl yükleyeceğinizi de gerektirir. Örneğin bir resim yükleme işlevselliği kullanmak bir yaklaşım olabilir. Eğer bir PHAR'ı basit bir JPG gibi taklit eden bir poliglot dosya oluşturabilirseniz, web sitesinin doğrulama kontrollerini bazen atlayabilirsiniz. Daha sonra web sitesini bu poliglot "JPG" dosyasını bir phar:// akışından yüklemeye zorlayabilirseniz, PHAR meta verileri aracılığıyla enjekte ettiğiniz herhangi zararlı veri deserializasyon işlemine tabi tutulacaktır. PHP bir akışı okurken dosya uzantısı kontrol edilmediğinden, dosyanın bir görüntü uzantısı kullandığı önemli değildir.
Nesnenin sınıfı web sitesi tarafından desteklendiği sürece, bu yöntemi kullanarak __wakeup() ve __destruct() sihirli yöntemleri bu şekilde çağrılabilir ve bu teknikle bir gadget zincirini başlatmak potansiyel olarak mümkün olur.
Hafıza bozulmalarını kullanarak deserializasyonu sömürmek, gadget zincirlerinin kullanılmadığı durumlarda bile mümkündür. Diğer her şey başarısız olursa, genellikle halka açık belgelenmiş hafıza bozulma açıkları bulunur ve bu açıklar güvensiz deserializasyon üzerinden sömürülebilir. Bu tür açıklar genellikle uzaktan kod yürütme fırsatları sunar.
Deserializasyon yöntemleri, PHP'nin unserialize() gibi, bu tür saldırılara karşı nadiren korunurlar ve büyük bir saldırı yüzeyini ortaya koyarlar. Bu, genellikle doğru bir açık olarak kabul edilmez çünkü bu yöntemler aslında kullanıcı tarafından kontrol edilebilen girişleri işlemek için tasarlanmamışlardır.
Bu tür saldırılar genellikle güvenlik araştırmacıları tarafından yayınlanan ve yamalanmış olmayan, yani düzeltilmemiş hafıza bozulma açıklarını hedefler. Bu açıklar, hedef uygulamanın belleğini yanıltmak veya istismar etmek için kötü amaçlı olarak tasarlanmış özel verilerin kullanılmasını içerebilir. Bu, deserializasyon işlemi sırasında verilerin bellekte nasıl işlendiğini etkileyebilir ve sonuç olarak saldırganın uzaktan kod yürütmesine yol açabilir.
Bu tür saldırılar, güvenlik araştırmacılarının ve saldırganların belgelenmemiş veya yamalanmamış hafıza bozulma açıklarını keşfettikleri ve bu açıkları kötü amaçlı olarak kullanarak uygulamalarda kod yürüttükleri karmaşık saldırılara yol açabilir. Bu tür saldırılar için çeşitli araçlar ve yöntemler bulunmaktadır ve genellikle güvenlik açığına dayanan yamalar yayınlanana kadar işlerler.
Sonuç olarak, güvensiz deserializasyon sadece gadget zincirlerini kullanarak değil, aynı zamanda hafıza bozulmalarını kullanarak da istismar edilebilir. Bu, uygulamanın deserializasyon işlemini yürütürken dikkatli bir şekilde incelenmesi ve korunmasız hafıza bozulmalarının kullanılabileceği durumların belirlenmesi gerektiği anlamına gelir.
Kaynak: Exploiting insecure deserialization vulnerabilities | Web Security Academy
Güvensiz deserializasyonu nasıl tanımlanır?
Güvensiz deserializasyonu tanımak, whitebox veya blackbox test yapmış olmanıza bakılmaksızın oldukça basittir.
Denetim sırasında, web sitesine iletilen tüm verilere bakmalısınız ve serileştirilmiş veri gibi görünen her şeyi tanımlamaya çalışmalısınız. Serileştirilmiş veri, farklı dillerin kullandığı biçimi bildiğiniz takdirde nispeten kolayca tanımlanabilir. Bu bölümde, hem PHP hem de Java serileştirmesinden örnekler göstereceğiz. Serileştirilmiş veriyi tanımladıktan sonra onu kontrol edip edemediğinizi test edebilirsiniz.
Tavsiye
Burp Suite Professional kullanıcıları için, Burp Scanner, serileştirilmiş nesneler içerdiği görünen HTTP iletilerini otomatik olarak işaretleyecektir.
PHP serileştirme biçimi
PHP, genellikle insan tarafından okunabilir bir dize biçemi kullanır; harfler veri türünü temsil ederken sayılar her girişin uzunluğunu temsil eder. Örneğin, aşağıdaki özelliklere sahip bir User nesnesini düşünün:
$user->name = "carlos";
$user->isLoggedIn = true;
Serileştirildiğinde, bu nesne şöyle görünebilir:
O:4:"User":2:{s:4:"name":s:6:"carlos"; s:10:"isLoggedIn":b:1;}
Bu şu şekilde yorumlanabilir:
O:4:"User" - 4 karakterlik "User" sınıf adına sahip bir nesne
2 - Nesnenin 2 özelliği bulunuyor
s:4:"name" - İlk özelliğin anahtarı 4 karakterlik "name" dizesidir
s:6:"carlos" - İlk özelliğin değeri 6 karakterlik "carlos" dizesidir
s:10:"isLoggedIn" - İkinci özelliğin anahtarı 10 karakterlik "isLoggedIn" dizesidir
b:1 - İkinci özelliğin değeri boolean değeri true'dur
PHP serileştirmesi için kullanılan yerel yöntemler serialize() ve unserialize() yöntemleridir. Kaynak kod erişiminiz varsa, unserialize() yöntemini kodun herhangi bir yerinde aramaya başlamalı ve daha fazla inceleme yapmalısınız.
Java serileştirme biçimi
Java gibi bazı diller, ikili serileştirme biçimlerini kullanır. Bu daha zor okunabilir, ancak bazı belirgin işaretleri nasıl tanıyacağınızı bildiğiniz sürece serileştirilmiş verileri hala tanıyabilirsiniz. Örneğin, serileştirilmiş Java nesneleri her zaman aynı baytlarla başlar ve bu baytlar hexadecimal olarak ac ed olarak kodlanır ve Base64'te rO0 olarak temsil edilir.
java.io.Serializable arabirimini uygulayan herhangi bir sınıf serileştirilebilir ve deserializasyon yapılabilir. Kaynak kod erişiminiz varsa, InputStream'dan veri okumak ve deserializasyon yapmak için kullanılan readObject() yöntemini kullanan kodları göz önünde bulundurmalısınız.
Serileştirilmiş nesneleri manipüle etme
Bazı deserializasyon zafiyetlerini sömürmek, serileştirilmiş bir nesnede bir özelliği değiştirmek kadar kolay olabilir. Nesne durumu saklandığı için serileştirilmiş veriyi inceleyerek ilginç özellik değerlerini tanımlayabilir ve düzenleyebilirsiniz. Daha sonra kötü amaçlı nesneyi web sitesine deserializasyon süreci aracılığıyla iletebilirsiniz. Bu, temel bir deserializasyon saldırısı için ilk adımdır.
Genel olarak, serileştirilmiş nesneleri manipüle etme konusunda iki yaklaşımınız vardır. Nesneyi doğrudan bayt akışı biçiminde düzeltebilir veya ilgili dili kullanarak yeni nesneyi oluşturup serileştirebilirsiniz. İkincisi, ikili serileştirme biçimleriyle çalışırken genellikle daha kolay bir yaklaşımdır.
Nesne özelliklerini değiştirme
Saldırgan verileri değiştirirken, saldırgan geçerli bir serileştirilmiş nesneyi koruduğu sürece deserializasyon süreci, değiştirilmiş özellik değerlerine sahip bir sunucu tarafı nesnesi oluşturacaktır.
Basit bir örnek olarak, bir web sitesini düşünün ki bu site, bir kullanıcının oturumuyla ilgili verileri bir çerezde saklamak için serileştirilmiş bir Kullanıcı nesnesi kullanıyor. Bir saldırgan, bu serileştirilmiş nesneyi bir HTTP isteğinde fark ederse, aşağıdaki bayt akışını bulmak için bu nesneyi çözümleyebilir:
O:4:"User":2:{s:8:"username";s:6:"carlos";s:7:"isAdmin";b:0;}
isAdmin özelliği açık bir ilgi noktasıdır. Bir saldırgan, özelliğin boolean değerini 1 (true) (doğru) olarak değiştirebilir, nesneyi yeniden kodlayabilir ve mevcut çerezini bu değiştirilmiş değerle üzerine yazabilir. İzole bir şekilde bu hiçbir etki yapmaz. Ancak, web sitesinin mevcut kullanıcının belirli yönetici işlevlerine erişip erişmediğini kontrol etmek için bu çerezi kullandığını varsayalım:
$user = unserialize($_COOKIE);
if ($user->isAdmin === true) {
// yönetici arayüzüne erişime izin ver
}
Bu zafiyetli kod, verilerin saldırgan tarafından değiştirilmiş isAdmin özelliği de dahil olmak üzere çerezden gelen verilere dayalı bir User nesnesi oluşturur. Serileştirilmiş nesnenin doğruluğu hiçbir noktada kontrol edilmez. Bu veriler ardından koşullu ifadeye geçirilir ve bu durumda kolay bir ayrıcalık yükseltmeye izin verir.
Bu basit senaryo doğada yaygın değildir. Ancak bu şekilde bir özellik değerini düzenlemek, güvensiz deserializasyon tarafından açığa çıkarılan büyük miktardaki saldırı yüzeyine erişimin ilk adımını gösterir.
Veri türlerini değiştirebileceğinizi öğrendik, ancak beklenmeyen veri tiplerini sağlamak da mümkündür.
PHP tabanlı mantık, farklı veri tiplerini karşılaştırırken (==) kullanılan gevşek karşılaştırma operatörünün davranışı nedeniyle bu tür manipülasyona özellikle savunmasızdır. Örneğin, bir tamsayı ile bir dize arasında gevşek bir karşılaştırma yaparsanız, PHP, dizeyi tamsayıya dönüştürmeye çalışır, yani 5 == "5" ifadesi true olarak değerlendirilir.
Alışılmadık bir şekilde, bu, bir sayı ile başlayan herhangi bir alfasayısal dize için de çalışır. Bu durumda, PHP, başlangıçtaki sayıya dayalı olarak tüm diziyi bir tamsayı değerine etkili bir şekilde dönüştürür. Dizinin geri kalanı tamamen yok sayılır. Bu nedenle, 5 == "bir şeyin 5'i" pratikte 5 == 5 olarak işlenir.
Bu daha da garipleşirken bir dizeyi tamsayı 0 ile karşılaştırmak düşünüldüğünde:
0 == "Örnek dize" // true
Neden? Çünkü dizide bir sayı yani 0 rakamı yoktur. PHP, bu tüm diziyi tamsayı 0 olarak işler.
Kullanıcı tarafından denetlenebilir verilerle birleştirildiğinde bu gevşek karşılaştırma operatörünün kullanıldığı bir durumu düşünelim. Bu potansiyel olarak tehlikeli mantık hatalarına neden olabilir.
$login = unserialize($_COOKIE)
if ($login['password'] == $password) {
// başarıyla giriş yap
}
Saldırgan, beklenen dize yerine tamsayı 0 içeren bir şifre özniteliğini değiştirdiğinde, koşul her zaman true dönecek şekilde saklandı. Şifre, bir sayı ile başlamadıkça, koşul oturum açma atlamasına olanak tanır. Unutmayın ki bu yalnızca deserializasyon veri türünü koruduğu için mümkündür. Kod doğrudan istekten şifreyi alırsa, 0 bir dizeye dönüştürülür ve koşul false olarak değerlendirilirdi.
Herhangi bir serileştirilmiş nesne biçiminde veri türlerini değiştirirken, serileştirilmiş verilerdeki tür etiketlerini ve uzunluk göstergelerini de güncellemeyi unutmamanız önemlidir. Aksi takdirde, serileştirilmiş nesne bozulur ve deserializasyon yapılamaz.
Doğrudan ikili biçimlerle çalışırken, BApp mağazasından temin edilebilen Hackvertor uzantısını kullanmanızı öneririz. Hackvertor ile serileştirilmiş verileri bir dize olarak değiştirebilirsiniz ve otomatik olarak ikili verileri günceller, konumları uygun şekilde ayarlar. Bu size manuel çaba tasarrufu sağlayabilir.
Uygulama işlevini kullanma
Sadece özellik değerlerini kontrol etmekle kalmayıp, bir web sitesinin işlevi aynı zamanda deserializasyon nesnesinden gelen veriler üzerinde tehlikeli işlemler de gerçekleştirebilir. Bu durumda, güvensiz deserializasyonu kullanarak beklenmeyen verileri iletebilir ve ilgili işlevselliği kullanarak zarar verebilirsiniz.
Örneğin, bir web sitesinin "Kullanıcıyı Sil" işlevinin bir parçası olarak, kullanıcının profil resmi, $user->image_location özniteliğindeki dosya yoluna erişilerek silinir. Bu $user, serileştirilmiş bir nesneden oluşturulmuşsa, bir saldırgan, image_location'ı herhangi bir dosya yoluna ayarlanmış bir değiştirilmiş nesneyi ileterek bunu sömürdü. Kendi kullanıcı hesabını silerken bu keyfi dosyayı da silecektir.
Bu örnek, saldırganın kullanıcı tarafından erişilebilir işlev aracılığıyla tehlikeli bir yöntemi manuel olarak çağırmasına dayanır. Ancak, güvensiz deserializasyon, verileri otomatik olarak tehlikeli yöntemlere ileten saldırıları oluşturduğunuzda çok daha ilginç hale gelir. Bu, "sihirli yöntemlerin" kullanılmasıyla mümkün olur.
Sihirli yöntemler
Sihirli yöntemler, belirli bir olay veya senaryo gerçekleştiğinde açıkça çağırmak zorunda olmadığınız özel bir yöntem alt kümesidir. Bunun yerine, belirli bir olay veya senaryo meydana geldiğinde otomatik olarak çağrılırlar. Sihirli yöntemler, farklı dillerde nesne yönelimli programlamanın yaygın bir özelliğidir. Sihirli yöntemler bazen yöntem adını çift alt çizgi ile ön eklemek veya çevrelemek suretiyle gösterilir.
Geliştiriciler, bir sınıfa sihirli yöntemler ekleyebilirler, böylece karşılık gelen olay veya senaryo meydana geldiğinde hangi kodun çalıştırılması gerektiğini önceden belirleyebilirler. Sihirli bir yöntemin ne zaman ve neden çağrıldığı yöntemden yönteme farklılık gösterir. PHP'deki en yaygın örneklerden biri __construct() sihirli yöntemidir ve bu yöntem, sınıfın bir örneği oluşturulduğunda otomatik olarak çağrılır, Python'daki __init__ gibi. Genellikle bu tür kurucu sihirli yöntemler, örneğin öznitelikleri başlatmak için kod içerir. Ancak geliştiriciler, sihirli yöntemleri istedikleri herhangi bir kodu çalıştırmak için özelleştirebilirler.
Sihirli yöntemler yaygın olarak kullanılır ve başlı başına bir güvenlik açığı temsil etmezler. Ancak, bu yöntemleri çalıştıran kodun saldırgan tarafından denetlenebilir verileri işlediği durumlarda tehlikeli hale gelebilirler, örneğin serileştirilmiş bir nesneden gelen veriler.
Bu bağlamda en önemlisi, bazı dillerin deserializasyon süreci sırasında otomatik olarak çağrılan sihirli yöntemlere sahip olmasıdır. Örneğin, PHP'nin unserialize() yöntemi, bir nesnenin __wakeup() sihirli yöntemini arar ve çağırır.
Java deserializasyonunda aynı şey, nesnenin başlangıç bayt akışından veri okumak ve serileştirilmiş bir nesneyi "yeniden başlatmak" için kullanılan ObjectInputStream.readObject() yöntemi için de geçerlidir. Bununla birlikte, Serileştirilebilir sınıflar, kendi readObject() yöntemlerini şu şekilde bildirebilir:
private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException
{
// uygulama
}
Tam olarak bu şekilde bildirilen bir readObject() yöntemi, deserializasyon sırasında çağrılan bir sihirli yöntem olarak davranır. Bu, sınıfın kendi alanlarının deserializasyonunu daha yakından denetlemesine izin verir.
Bu tür sihirli yöntemlere sahip sınıfları dikkatle incelemeniz önemlidir. Bunlar, nesnenin tamamen deserialize edilmeden önce serileştirilmiş nesneden web sitesinin koduna veri aktarmanıza olanak tanır. Bu, daha gelişmiş saldırılar oluşturmanın başlangıç noktasıdır.
Keyfi nesneler enjekte etme
Güvensiz deserializasyonu sadece web sitesi tarafından sağlanan nesneyi düzenleyerek sömürmenin mümkün olduğunu gördük. Ancak keyfi nesne türlerini enjekte etmek, çok daha fazla olasılığı açabilir.
Nesne yönelimli programlamada, bir nesnenin kullanabileceği yöntemler sınıfına bağlıdır. Bu n
edenle, bir saldırganın hangi nesne sınıfının serileştirilmiş veri olarak iletilmekte olduğunu manipüle edebilirse, deserializasyon sonrası ve hatta deserializasyon sırasında hangi kodun çalıştırılacağını etkileyebilir.
Deserializasyon yöntemleri genellikle deserializasyon işleminin neyi deserialize ettiğini kontrol etmez. Bu, herhangi bir serializable sınıfın nesnelerini iletebileceğiniz ve nesnenin deserializasyonuyla etkili bir şekilde keyfi sınıf örnekleri oluşturabileceğiniz anlamına gelir. Bu, bir saldırganın keyfi sınıf örnekleri oluşturmasına olanak tanır. Bu nesnenin beklenen sınıf olmaması önemli değildir. Beklenmeyen nesne türü, uygulama mantığında bir istisna oluşturabilir, ancak kötü amaçlı nesne bu zamana kadar zaten oluşturulmuş olacaktır.
Bir saldırganın kaynak koduna erişimi varsa, tüm kullanılabilir sınıfları detaylı olarak inceleyebilir. Basit bir saldırı oluşturmak için, sihirli deserializasyon yöntemlerini içeren sınıfları ararlar ve bunların herhangi birinin denetlenebilir veriler üzerinde tehlikeli işlemleri gerçekleştirip gerçekleştirmediğini kontrol ederler. Saldırgan daha sonra bu sınıfın serileştirilmiş bir nesnesini kullanarak sihirli yöntemini bir saldırı için kullanabilir.
Bu deserializasyon sihirli yöntemler içeren sınıflar ayrıca "gadget zinciri" olarak bilinen bir dizi yöntem çağrısını içeren daha karmaşık saldırılara başlamak için kullanılabilir.
Gadget zincirleri
Bir "gadget", bir saldırganın belirli bir hedefe ulaşmasına yardımcı olabilecek uygulamada var olan bir kod parçasıdır. Bir bireysel gadget, kullanıcı girdisiyle doğrudan zararlı bir şey yapmayabilir. Ancak saldırganın amacı, girdilerini başka bir gadget'a iletecek bir yöntemi çağırmak olabilir. Bu şekilde birden fazla gadget'ı birleştirerek, saldırgan girdilerini maksimum zarar verebilecek tehlikeli bir "sink gadget" içine iletebilir.
Anlaşılması önemlidir ki, diğer bazı saldırı türlerinin aksine, bir gadget zinciri, saldırgan tarafından oluşturulan zincir yöntemlerinin bir yükü değildir. Tüm kod zaten web sitesinde mevcuttur. Saldırganın kontrol ettiği tek şey, gadget zincirine iletilen verilerdir. Bu genellikle deserializasyon sırasında çağrılan bir sihirli yöntem kullanılarak yapılır ve bu bazen bir "başlatma gadgetı" olarak bilinir.
Gerçek dünyada, birçok güvensiz deserializasyon açığı yalnızca gadget zincirleri kullanılarak sömürülebilir. Bu bazen basit bir bir veya iki adımlık bir zincir olabilir, ancak yüksek riskli saldırıları başarıyla gerçekleştirmek için daha karmaşık bir nesne oluşturma ve yöntem çağırma dizisi gerekebilir. Bu nedenle gadget zincirleri oluşturabilme, güvensiz deserializasyonu başarılı bir şekilde sömürmenin temel yönlerinden biridir.
Önceden oluşturulmuş gadget zincirleri ile çalışma
Manuel olarak gadget zincirlerini tanımlamak oldukça zorlu bir süreç olabilir ve kaynak kod erişimi olmadan neredeyse imkansızdır. Neyse ki, ilk olarak deneyebileceğiniz önceden oluşturulmuş gadget zincirleri ile çalışmanız için birkaç seçenek bulunmaktadır.
Başka web sitelerinde başarılı bir şekilde sömürülmüş önceden keşfedilmiş zincirleri sağlayan bir dizi araç mevcuttur. Kaynak koduna erişiminiz olmasa bile, bu araçları kullanarak göreceli olarak az çaba harcayarak güvensiz deserializasyon açıklarını tanımlayabilir ve sömürebilirsiniz. Bu yaklaşım, sömürülebilir gadget zincirlerini içeren kütüphanelerin yaygın olarak kullanılmasının bir sonucudur. Örneğin, Java'nın Apache Commons Collections kütüphanesindeki bir gadget zinciri bir web sitesinde sömürülebilirse, bu kütüphaneyi uygulayan başka herhangi bir web sitesinin de aynı zinciri kullanarak sömürülebilir olabileceği anlamına gelir.
ysoserial
Java deserializasyon için bu tür bir araç olan "ysoserial" bulunmaktadır. Bu araç, hedef uygulamanın kullandığını düşündüğünüz bir kütüphandaki sağlanan gadget zincirlerinden birini seçmenizi ve çalıştırmak istediğiniz bir komutu iletmeyi seçmenizi sağlar. Ardından seçilen zincire dayalı uygun serileştirilmiş bir nesne oluşturur. Bu hala belirli bir deneme ve hata gerektirir, ancak kendi gadget zincirlerinizi manuel olarak oluşturmaktan çok daha az iş yoğundur.
Not
Java'nın 16 ve sonraki sürümlerinde, ysoserial'ı çalıştırmak için Java'nın komut satırı argümanlarını ayarlamalısınız. Örneğin:
java -jar ysoserial-all.jar \
--add-opens=java.xml/com.sun.org.apache.xalan.internal.xsltc.trax=ALL-UNNAMED \
--add-opens=java.xml/com.sun.org.apache.xalan.internal.xsltc.runtime=ALL-UNNAMED \
--add-opens=java.base/java.net=ALL-UNNAMED \
--add-opens=java.base/java.util=ALL-UNNAMED \
[payload] '[command]'
ysoserial'daki tüm gadget zincirleri, keyfi kod çalıştırmanıza olanak tanımaz. Bunun yerine, diğer amaçlar için kullanışlı olabilirler. Örneğin, aşağıdakiler gibi bazıları, güvensiz deserializasyonu hızlı bir şekilde neredeyse her sunucuda tespit etmenize yardımcı olabilir:
1. **URLDNS zinciri**, sağlanan bir URL için DNS sorgusu tetikler. En önemlisi, hedef uygulamanın belirli bir güvensiz kütüphane kullanmasına bağlı değildir ve her bilinen Java sürümünde çalışır. Bu, tespit amaçları için en evrensel gadget zinciri yapar. Trafikte bir serileştirilmiş nesne görürseniz, bu gadget zincirini kullanarak Burp Collaborator sunucusu ile DNS etkileşimi tetikleyen bir nesne oluşturmayı deneyebilirsiniz. Eğer bu gerçekleşirse, hedefinizde deserializasyonun gerçekleştiğinden emin olabilirsiniz.
2. **JRMPClient**, başlangıç tespiti için kullanabileceğiniz başka bir evrensel zincirdir. Bu, sunucunun sağlanan IP adresine bir TCP bağlantısı kurmaya çalışmasına neden olur. Unutmayın ki bir alan adı yerine ham bir IP adresi sağlamanız gerekiyor. Bu zincir, DNS sorguları dahil tüm çıkış trafiğinin firewall ile korunduğu ortamlarda kullanışlı olabilir. İki farklı IP adresi ile yükler oluşturmayı deneyebilirsiniz: yerel biri ve firewall ile korunan harici biri. Uygulama yerel bir adres için hemen yanıt veriyorsa, ancak harici bir adres için yanıtta gecikme oluyor ve bu nedenle yanıtta bir gecikme oluyorsa, bu gadget zincirinin çalıştığını gösterir çünkü sunucu firewall ile korunan adrese bağlanmaya çalıştı. Bu durumda, yanıtlar arasındaki ince zaman farkı, sunucuda deserializasyonun olup olmadığını tespit etmenize yardımcı olabilir, hatta kör durumlarda bile.
3. **PHP Generic Gadget Chains (PHPGGC)** gibi, güvensiz deserializasyon açıklarına sıkça rastlayan çoğu dil için benzeri kanıt-of-konsept araçlar bulunmaktadır.
Not
Önemli bir not olarak belirtmek gerekir ki, güvensiz deserializasyon açığı, web sitesinin kodunda veya kütüphanelerindeki gadget zincirinin sadece varlığı değil, kullanıcı tarafından kontrol edilebilir verilerin deserializasyonudur. Gadget zinciri, enjekte edildikten sonra zararlı verilerin akışını manipüle etmenin bir yolu sadece. Bu ayrıca güvenilmeyen verilerin deserializasyonuna dayanan çeşitli bellek bozulma açıklarına da uygulanır. Başka bir deyişle, bir web sitesi, her olası gadget zincirini kapatmayı başarsa bile hala açık olabilir.
Belgelenmiş gadget zincirleri ile çalışma
Hedef uygulamanın kullandığı çerçeve içinde bilinen gadget zincirlerini sömürmek için özel bir araç her zaman mevcut olmayabilir. Bu durumda, manuel olarak uyarlayabileceğiniz belgelenmiş saldırıları bulup bulunmadığınızı görmek her zaman değerlidir. Kodu ayarlamak, bazen dil ve çerçeve hakkında temel bir anlayış gerektirebilir ve bazen nesneyi kendiniz serileştirmeniz gerekebilir, ancak bu yaklaşım, sıfırdan bir saldırı oluşturmaktan çok daha az çabadır.
Hazır kullanılabilecek bir gadget zinciri veya belgelenmiş bir saldırı bulamazsanız bile, kendi özel saldırınızı oluşturmanıza yardımcı olabilecek değerli bilgilere sahip olabilirsiniz.
Kendi saldırınızı oluşturma
Hazır gadget zincirleri ve belgelenmiş saldırılar başarısız olduğunda kendi saldırınızı oluşturmanız gerekecektir.
Kendi gadget zincirinizi başarıyla oluşturabilmek için neredeyse kesinlikle kaynak kod erişimine ihtiyacınız olacaktır. İlk adım, bu kaynak kodu inceleyerek deserializasyon sırasında çağrılan bir sihirli yöntem içeren bir sınıfı tanımlamaktır. Bu sihirli yöntemin yürüttüğü kodu değerlendirin ve kullanıcı tarafından kontrol edilebilir özelliklerle doğrudan tehlikeli bir şey yapmadığını görmek için kontrol edin. Her ihtimale karşı bu her zaman kontrol edilmeye değer bir adımdır.
Sihirli yöntem tek başına sömürülemiyorsa, gadget zincirinizin başlatma gadgeti olarak görev yapabilir. Başlatma gadgetinin çağırdığı yöntemleri inceleyin. Bunlardan herhangi biri kontrol ettiğiniz verilerle tehlikeli bir şey yapar mı? Yapmazsa, bunların ardışık olarak çağırdığı her yönteme daha yakından bakın ve böyle devam edin.
Bu süreci tekrarlayarak erişebildiğiniz değerleri izleyin ve ya bir çıkmaza ulaşana kadar ya da kontrol edilebilir verilerinizin iletildiği tehlikeli bir "sink gadget" belirleyene kadar devam edin.
Uygulama kodu içinde gadget zinciri oluşturmayı başarılı bir şekilde nasıl gerçekleştireceğinizi çalıştıktan sonra, bir yük içeren serileştirilmiş bir nesne oluşturmanız gereken bir sonraki adım, kaynak koddaki sınıf bildirimini incelemek ve isteğiniz için gereken uygun değerlere sahip geçerli serileştirilmiş bir nesne oluşturmaktır. Daha önceki laboratuvarlarda gördüğümüz gibi, bu, dize tabanlı serileştirme formatlarıyla çalışırken oldukça basittir.
Java deserializasyon saldırısı oluştururken olduğu gibi, bir dizi işlem yaparken, özellikle mevcut bir nesneye küçük değişiklikler yaparken, baytlarla doğrudan çalışmaktan rahat hissedebilirsiniz. Ancak tamamen yeni bir nesneyi geçirirken gibi daha büyük değişiklikler yaparken, bu hızlı bir şekilde uygulanamaz hale gelir. Verileri kendiniz oluşturmak ve serileştirmek için hedef dilde kendi kodunuzu yazmak genellikle çok daha basittir.
Kendi gadget zincirinizi oluştururken, bu ek saldırı yüzeyini kullanma fırsatlarını ararken ikincil güvenlik açıklarını tetiklemek için bu ek saldırı yüzeyini kullanma fırsatlarına dikkat edin.
Kaynak kodunu dikkatlice inceleyerek, yüksek riskli saldırılar dahil olmak üzere uzun gadget zincirlerini keşfederek genellikle uzaktan kod çalıştırmayı içerebilecek yüksek riskli saldırıları oluşturmanıza olanak tanıyan daha uzun gadget zincirlerini keşfedebilirsiniz.
PHAR (PHP Archive) ile deserializasyonu nasıl sömürüleceğini incelemeye başladık. Ancak PHP'de unserialize() yönteminin açık bir şekilde kullanılmadığı deserializasyon açıklarını sömürmeyi incelemek bazen mümkün olabilir.
PHP, farklı protokolleri işlerken dosya yollarına erişmek için kullanabileceğiniz bir dizi URL tarzı sarmalayıcı (wrapper) sunar. Bunlardan biri phar:// sarmalayıcısıdır ve PHP Archive (.phar) dosyalarına erişim için bir akış arabirimi sağlar.
PHP belgeleri, PHAR manifest dosyalarının serileştirilmiş meta veriler içerdiğini göstermektedir. Önemli olan, phar:// akışına herhangi bir dosya işlemi uygularsanız, bu meta verilerin örtük olarak deserialization işlemine tabi tutulacağıdır. Bu, bir phar:// akışının, bu akışı bir dosya sistemi yöntemine iletebiliyorsanız, güvensiz deserializasyonu sömürmek için bir vektör olabilir demektir.
Açıkça tehlikeli dosya sistem yöntemleri, örneğin include() veya fopen() gibi yöntemler, web sitelerinin kötü niyetle kullanılma potansiyelini azaltmak için karşı önlemler uygulamış olabilirler. Ancak file_exists() gibi çok açık olmayan yöntemler, aynı şekilde korunmayabilirler.
Bu teknik aynı zamanda PHAR'ı sunucuya nasıl yükleyeceğinizi de gerektirir. Örneğin bir resim yükleme işlevselliği kullanmak bir yaklaşım olabilir. Eğer bir PHAR'ı basit bir JPG gibi taklit eden bir poliglot dosya oluşturabilirseniz, web sitesinin doğrulama kontrollerini bazen atlayabilirsiniz. Daha sonra web sitesini bu poliglot "JPG" dosyasını bir phar:// akışından yüklemeye zorlayabilirseniz, PHAR meta verileri aracılığıyla enjekte ettiğiniz herhangi zararlı veri deserializasyon işlemine tabi tutulacaktır. PHP bir akışı okurken dosya uzantısı kontrol edilmediğinden, dosyanın bir görüntü uzantısı kullandığı önemli değildir.
Nesnenin sınıfı web sitesi tarafından desteklendiği sürece, bu yöntemi kullanarak __wakeup() ve __destruct() sihirli yöntemleri bu şekilde çağrılabilir ve bu teknikle bir gadget zincirini başlatmak potansiyel olarak mümkün olur.
Hafıza bozulmalarını kullanarak deserializasyonu sömürmek, gadget zincirlerinin kullanılmadığı durumlarda bile mümkündür. Diğer her şey başarısız olursa, genellikle halka açık belgelenmiş hafıza bozulma açıkları bulunur ve bu açıklar güvensiz deserializasyon üzerinden sömürülebilir. Bu tür açıklar genellikle uzaktan kod yürütme fırsatları sunar.
Deserializasyon yöntemleri, PHP'nin unserialize() gibi, bu tür saldırılara karşı nadiren korunurlar ve büyük bir saldırı yüzeyini ortaya koyarlar. Bu, genellikle doğru bir açık olarak kabul edilmez çünkü bu yöntemler aslında kullanıcı tarafından kontrol edilebilen girişleri işlemek için tasarlanmamışlardır.
Bu tür saldırılar genellikle güvenlik araştırmacıları tarafından yayınlanan ve yamalanmış olmayan, yani düzeltilmemiş hafıza bozulma açıklarını hedefler. Bu açıklar, hedef uygulamanın belleğini yanıltmak veya istismar etmek için kötü amaçlı olarak tasarlanmış özel verilerin kullanılmasını içerebilir. Bu, deserializasyon işlemi sırasında verilerin bellekte nasıl işlendiğini etkileyebilir ve sonuç olarak saldırganın uzaktan kod yürütmesine yol açabilir.
Bu tür saldırılar, güvenlik araştırmacılarının ve saldırganların belgelenmemiş veya yamalanmamış hafıza bozulma açıklarını keşfettikleri ve bu açıkları kötü amaçlı olarak kullanarak uygulamalarda kod yürüttükleri karmaşık saldırılara yol açabilir. Bu tür saldırılar için çeşitli araçlar ve yöntemler bulunmaktadır ve genellikle güvenlik açığına dayanan yamalar yayınlanana kadar işlerler.
Sonuç olarak, güvensiz deserializasyon sadece gadget zincirlerini kullanarak değil, aynı zamanda hafıza bozulmalarını kullanarak da istismar edilebilir. Bu, uygulamanın deserializasyon işlemini yürütürken dikkatli bir şekilde incelenmesi ve korunmasız hafıza bozulmalarının kullanılabileceği durumların belirlenmesi gerektiği anlamına gelir.
Kaynak: Exploiting insecure deserialization vulnerabilities | Web Security Academy
