|
|
Publicerad den 2021-12-11 21:06:29
|
|
|
|

Under de senaste två dagarna har den blivit svepen av "Apache Log4j2 remote code execution offennerability" i vänkretsen, främst på grund av Java JNDI-injektionssårbarheten i komponenten: när programmet skriver in användarens data i loggen, konstruerar angriparen en speciell begäran för att utlösa sårbarheten för fjärrkodexekvering i Apache Log4j2, och utnyttjar därmed denna sårbarhet för att köra godtycklig kod på målservern.
Inflytandeområde
Apache Log4j 2.x <= 2.14.1
JNDI (Java Naming and Directory Interface) är ett Java-namngivnings- och kataloggränssnitt som tillhandahålls av Java. Genom att anropa JNDIs API kan applikationer lokalisera resurser och andra programobjekt. JNDI är en viktig del av Java EE, det bör noteras att det inte bara inkluderar DataSource (JDBC-datakälla), utan även kan få tillgång till befintliga kataloger och tjänster såsom: JDBC, LDAP, RMI, DNS, NIS, CORBA, utdrag från Baidu-encyklopedin. Det finns många artiklar på internet om hur man åtgärdar sårbarheter och skärmdumpar av sårbarheter, men lite om hur man testar projektet för sårbarheter.Java använder Log4j2 främst för att testa kodenFöljande följer:
Enkelt uttryckt kommer Log4j2 att få tillgång till följande adress via RMI- eller LDAP-protokollet, och beroende på protokollets innehåll kan den exekvera illvilligt konstruerad kod.
Sårbarhetens existens bevisas nästan alltid på Internet genom att öppna en Windows-kalkylator, och koden är följande:
Eftersom Log4J2 använder RMI- eller LDAP-protokoll för att komma åt angriparens server, och både RMI- och LDAP-protokoll är TCP-baserade, kan vi göra det direktGenom att använda .NET för att lyssna på en TCP-port, om ett anrop till log4j2 för att skriva ut loggar får åtkomst till .NET-lyssningsporten, bevisar det att det kan finnas en sårbarhet, och om inte, är det säkert。
.NET genererar mycket små testprogram6kb, koden är följande:
Prova att använda log4j-komponenten2.14.0Versionen är tryckt och renderingen är följande:
Prova att uppgradera log4j-komponenten till2.15.0versionen, utförd igen, är effekten följande:
Efter att ha uppgraderat versionen visar det sig att efter att ha anropat utskriftsloggen,Java-programmet har inte längre åtkomst till den externa porten。
Intresserade vänner, ni kan hänvisa till följande länk för att återskapa sårbarheten och ta fram kalkylatorn.
Inloggningen med hyperlänken är synlig.
Inloggningen med hyperlänken är synlig.
Slutligen, bifoga testproceduren:
测试程序.rar
(2.66 KB, Antal nedladdningar: 1)
|
Föregående:[Verklig strid]. NET/C# Skapa en SQLite-databas och lägg helt enkelt till, ta bort, ändraNästa:CentOS systemdistribution nacos-handledning
|