Bu gönderi Zero Day Initiative ekibinin araştırma sonuçlarını Türkçe okuyucular ve Türk güvenlik araştırmacıları için çeviri niteliğinde olması için hazırlanmıştır. Daha fazla bilgi sahibi olmak isteyenler aşağıdaki link üzerinden ZDI sayfasına ulaşabilir. Teşekkürler.
This post has been prepared to translate the research results of the Zero Day Initiative Team for Turkish readers and Turkish security researchers. If you want more information you can reach the ZDI page via the link below. Thanks.
https://www.zerodayinitiative.com/
Apache Log4j API, aramalarda değişken değiştirmeyi destekler. Ancak, hazırlanmış bir değişken, kontrolsüz özyinelemeli (recursive) ifadeler nedeniyle, uygulamanın çökmesine neden olur. Arama komutları üzerinde kontrolü olan bir saldırgan kötü niyetli bir arama değişkeni oluşturabilir ve bu da Hizmet Reddi (DoS) saldırısına neden olur. Bu, 2.16.0'a kadar olan Log4j sürümlerinde test edilmiş ve onaylanmıştır.
#ApacheLog4j API supports variable replacement in calls. However, a prepared variable will crash the application due to uncontrolled recursive statements. An attacker with control over search commands can create a malicious search variant, which causes a Denial of Service (DoS) attack. This has been tested and validated on Log4j versions up to 2.16.0.
Güvenlik Açığı
Bir değişken "StrSubstitutor" sınıfı tarafından değiştirildiğinde, özyinelemeli (recursive) olarak replace() sınıfını çağırır. Ancak, iç içe geçmiş değişken değiştirilen değişkene referans verdiğinde, özyineleme aynı dizeyle çağrılır. Bu, sunucuda sonsuz bir özyinelemeye ve DoS koşuluna yol açar. Örnek olarak, Model Düzeni ${ctx.apiversion} Bağlam Araması içeriyorsa ve atanan değeri ${${ctx.apiversion}} ise, değişken yinelemeli olarak kendisi ile değiştirilir.
#Vulnerability
When a nested variable is substituted by the StrSubstitutor class, it recursively calls the substitute() class. However, when the nested variable references the variable being replaced, the recursion is called with the same string. This leads to an infinite recursion and a DoS condition on the server. As an example, if the Pattern Layout contains a Context Lookup of ${ctx.apiversion}, and its assigned value is ${${ctx.apiversion}}, the variable will be recursively substituted with itself.
Şimdi hızlıca kod akışına bakalım ve nasıl gerçekleştiğini görmüş olalım.
Now let's take a quick look at the code flow and see how it happens.
Denemek isterseniz, log4j sürüm 2.16.0 ile derlenmiş, log4j-vulnerable-app.jar adlı tipik bir güvenlik açığı bulunan uygulama oluşturabilirsiniz. Uygulama, bir arama (${ctx:apiversion}) içeren özel bir kalıp düzeni ile yapılandırılır. Uygulama, bunu bir HTTP sunucusuna uygular ve alınan X-Api-Version başlığını, Thread Context Map'teki apiversion değişkeninin değeri olarak ayarlar. Daha sonra, iletiyi günlüğe kaydeder.
If you want to try it, you can create a typical vulnerable application named log4j-vulnerable-app.jar compiled with log4j version 2.16.0. The application is configured with a custom pattern layout that includes a call (${ctx:apiversion}). The application applies it to an HTTP server and sets the received X-Api-Version header as the value of the apiversion variable in the Thread Context Map. It then logs the message.
Güvenlik açığı bulunan uygulama, hedef sunucuda aşağıdaki gibi çalıştırılabilir:
The vulnerable app can be run as follows on the target server:
java -jar log4j-vulnerable-app.jar
burada isterseniz python kodunuzu da çalıştırabilirsiniz.
If you want you can run python scripts too. :)
python test.py client host
Komut dosyasını çalıştırdıktan sonra, güvenlik açığı bulunan uygulamaya X-Api-Version başlığı ${${ctx:apiversion}} değerine ayarlanmış bir HTTP isteği gönderilir. İletiyi günlüğe kaydetmeye çalışırken, güvenlik açığı bulunan uygulama aşağıdaki yığın izlemesiyle çökecektir
Upon running the script, an HTTP request with the X-Api-Version header set to a value of ${${ctx:apiversion}} will be sent to the vulnerable application. When attempting to log the message, the vulnerable application will crash with the following stack trace:
Bu hata için 18 Aralık 2021'de Apache tarafından bir yama yayınlandı. Apache azaltıcı faktörleri listelese de, bu güvenlik açığının tamamen giderildiğinden emin olmak için en son sürüme yükseltme yapmakta fayda var. Bu bileşen bu hafta oldukça ilgi gördü, bu nedenle yama olsun ya da olmasın başka hataların açıklandığını görmek de sürpriz olmayacaktır.
A patch for this bug was released by Apache on December 18, 2021. While Apache does list mitigating factors, you can upgrade to the latest version to ensure this vulnerability is completely addressed. This component has received quite a bit of attention this week, so it would not be a surprise to see further bugs disclosed – with or without a patch.
Sevgiler.