snip3r69/spring-shell-vulnSpring hat die RCE im Spring Framework bestätigt. Das Team hat soeben die Stellungnahme zusammen mit den Leitfäden zur Eindämmung des Problems veröffentlicht. Diese Schwachstelle kann nun als CVE-2022-22965 verfolgt werden.
Spring hat die RCE im Spring Framework bestätigt. Das Team hat gerade die Stellungnahme zusammen mit den Anleitungen zur Eindämmung des Problems veröffentlicht. Diese Schwachstelle kann nun als CVE-2022-22965 verfolgt werden.
Einige Informationen über die Spring4Shell-Schwachstelle und Details wurden im Beitrag Spring4Shell: Details and Exploit geteilt. Darüber hinaus hat das Sicherheitsteam von Praetorian bestätigt, dass Spring Core auf JDK9+ aufgrund eines Bypasses für CVE-2010-1622 anfällig für Remote-Code-Ausführung ist.
Ursprünglich begann es am 30. März: Die erste Mitteilung über die Schwachstelle wurde vom Leiter des KnownSec-404-Teams, Heige, angedeutet. Er twitterte die Warnmeldung "Spring core RCE （JDK >=9" zusammen mit dem PoC-Bild.
Als wir mit der Geschichte über die Schwachstelle live gingen, verschwand Heige von Twitter. Der Grund dafür ist unbekannt, aber es könnte etwas dahinterstecken.
Ende 2021 stand das Internet in Flammen, als eine Zero-Day-Schwachstelle zur Remote-Code-Ausführung, auch bekannt als Log4Shell, in Apache Log4j2 auftauchte. Die Schwachstelle wurde vom Sicherheitsteam von Alibaba Cloud entdeckt.
Heute haben Forscher eine weitere schwerwiegende Schwachstelle entdeckt, die erheblichen Schaden verursachen kann. Der Fehler wird nun als CVE-2022-22965 verfolgt; wir können ihn Spring4Shell nennen. Die Schwachstelle besteht im Spring Core bei JDK-Versionen größer oder gleich 9.0.
Spring Framework und abgeleitete Frameworks – spring-beans-*.jar-Dateien oder CachedIntrospectionResults.class
Alle unten aufgeführten Details sind inzwischen bestätigt. Ich übernehme keine Verantwortung für verursachte Schäden.
Als eines der weltweit beliebtesten leichtgewichtigen Open-Source-Frameworks für Java ermöglicht Spring Entwicklern, sich auf die Geschäftslogik zu konzentrieren, und vereinfacht den Entwicklungszyklus von Java-Unternehmensanwendungen.
Die Ausnutzung erfordert einen Endpunkt mit aktiviertem DataBinder (z. B. eine POST-Anfrage, die Daten aus dem Anfragetext automatisch decodiert) und hängt stark vom Servlet-Container der Anwendung ab. Wenn Spring beispielsweise auf Apache Tomcat bereitgestellt wird, ist der WebAppClassLoader zugänglich, was einem Angreifer ermöglicht, Getter und Setter aufzurufen, um letztendlich eine schädliche JSP-Datei auf die Festplatte zu schreiben. Wenn Spring jedoch mit dem eingebetteten Tomcat-Servlet-Container bereitgestellt wird, ist der Classloader ein LaunchedURLClassLoader mit eingeschränktem Zugriff.
In der JDK9-Version (und höher) des Spring Framework kann ein entfernter Angreifer jedoch unter bestimmten Bedingungen das AccessLogValve-Objekt und bösartige Feldwerte über die Parameterbindungsfunktion des Frameworks erlangen.
Führen Sie auf dem laufenden Server des Organisationssystems den Befehl "java -version" aus, um die ausgeführte JDK-Version zu prüfen. Wenn die Versionsnummer kleiner oder gleich 8 ist, ist das System nicht von der Schwachstelle betroffen.
Nach Abschluss der beiden oben genannten Fehlerbehebungsschritte liegt eine Betroffenheit durch diese Schwachstelle vor, wenn die folgenden beiden Bedingungen gleichzeitig erfüllt sind:
Inzwischen hat das Spring-Team die Schwachstelle behoben und die neuesten Versionen von Spring Boot 2.6.6 und 2.5.12 veröffentlicht, die von Spring Framework 5.3.18 abhängen.
Implementieren Sie auf Netzwerkschutzgeräten wie WAF eine Regel-Filterung für Zeichenfolgen wie "class.", "Class.", ".class." und ".Class." entsprechend der tatsächlichen Verkehrssituation der bereitgestellten Dienste. Testen Sie nach dem Filtern der Regeln den Geschäftsbetrieb, um zusätzliche Auswirkungen zu vermeiden.
Die vorübergehende Reparatur der Sicherheitslücke sollte in den folgenden beiden Schritten gleichzeitig durchgeführt werden:
Durchsuchen Sie die Anwendung global nach der Annotation @InitBinder, um festzustellen, ob die Methode dataBinder.setDisallowedFields im Methodenrumpf aufgerufen wird. Wenn die Einführung dieses Code-Ausschnitts gefunden wird, fügen Sie {"class.","Class. to the original blacklist ",".class.", ".Class."} hinzu. (Hinweis: Wenn dieser Code-Ausschnitt häufig verwendet wird, muss er überall angehängt werden)
Erstellen Sie die folgende globale Klasse im Projektpaket des Anwendungssystems und stellen Sie sicher, dass diese Klasse von Spring geladen wird (es wird empfohlen, sie in dem Paket hinzuzufügen, in dem sich der Controller befindet). Nachdem die Klasse hinzugefügt wurde, muss das Projekt neu kompiliert, verpackt und einer Funktionsprüfung unterzogen werden. Veröffentlichen Sie das Projekt anschließend erneut. 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 GlobalControllerAdvice{
@InitBinder
public void setAllowedFields(webdataBinder dataBinder){
String[]abd=new string[]{"class.*","Class.*","*.class.*","*.Class.*"};
dataBinder.setDisallowedFields(abd);
}
}
Aus dem Git-Repository der Spring-Projekte geht hervor, dass der Spring-Entwickler an einem Fix für die Remote-Code-Ausführungsschwachstelle arbeitet, aber wir müssen auf die offizielle Bestätigung warten.