|
|
Publisert 2021-12-11 21:06:29
|
|
|
|
I løpet av de siste to dagene har den blitt sveipet av "Apache Log4j2 remote code execution vulnerability" i vennekretsen, hovedsakelig på grunn av Java JNDI-injeksjonssårbarheten i komponenten: når programmet skriver inn dataene brukeren legger inn i loggen, konstruerer angriperen en spesiell forespørsel for å utløse sårbarheten for fjernkodekjøring i Apache Log4j2, og utnytter dermed denne sårbarheten til å kjøre vilkårlig kode på målserveren.
Innflytelsesområde
Apache Log4j 2.x <= 2.14.1
JNDI (Java Naming and Directory Interface) er et Java-navne- og kataloggrensesnitt levert av Java. Ved å kalle JNDIs API kan applikasjoner finne ressurser og andre programobjekter. JNDI er en viktig del av Java EE, det bør bemerkes at det ikke bare inkluderer DataSource (JDBC datakilde), men kan også få tilgang til eksisterende kataloger og tjenester som: JDBC, LDAP, RMI, DNS, NIS, CORBA, utdrag fra Baidu Encyclopedia.
Det finnes mange artikler på Internett om hvordan man kan fikse sårbarheter og skjermbilder av sårbarheter, men lite om hvordan man tester prosjektet for sårbarheter.Java bruker hovedsakelig Log4j2 for å teste kodenSom følger:
Enkelt sagt vil Log4j2 få tilgang til følgende adresse via RMI- eller LDAP-protokollen, og avhengig av innholdet i protokollen kan den utføre ondsinnet konstruert kode.
Eksistensen av sårbarheten bevises nesten alltid på Internett ved å åpne en Windows-kalkulator, og koden er som følger:
Siden Log4J2 bruker RMI- eller LDAP-protokoller for å få tilgang til angriperens server, og både RMI- og LDAP-protokoller er TCP-baserte, kan vi gjøre det direkteVed å bruke .NET til å lytte på en TCP-port, hvis et kall til log4j2 for å skrive ut logger får tilgang til .NET-lytteporten, beviser det at det kan foreligge en sårbarhet, og hvis ikke, er det sikkert。
.NET genererer svært små testprogrammer6kb, koden er som følger:
Prøv å bruke log4j-komponenten2.14.0Versjonen er printet, og gjengivelsen er som følger:
Prøv å oppgradere log4j-komponenten til2.15.0versjonen, utført igjen, er effekten som følger:
Etter å ha oppgradert versjonen, oppdages det at etter å ha kalt utskriftsloggen,Java-programmet har ikke lenger tilgang til den eksterne porten。
Interesserte venner, dere kan bruke følgende lenke for å gjenskape sårbarheten og åpne kalkulatoren.
Innloggingen med hyperkoblingen er synlig.
Innloggingen med hyperkoblingen er synlig.
Til slutt, legg ved testprosedyren:
测试程序.rar
(2.66 KB, Antall nedlastinger: 1)
|
Foregående:[Faktisk kamp]. NET/C# Opprett en SQLite-database og legg bare til, slett, modifiserNeste:CentOS systemutrullings-nacos-veiledning
|
Vert|
Publisert 2021-12-13 13:37:35
|
Publisert 20.12.2021 kl. 23:09:51
|
