Omitir el cifrado del lado del cliente para leer archivos internos del servidor de Windows

Dec 01 2022
Hola, una vez más, soy yo abhishekmorla. Este blog trata sobre cómo se puede romper el cifrado del lado del cliente con el análisis del código fuente y cómo leer los archivos internos del servidor de Windows, es decir, LFI, pero después de pasar por alto una capa de cifrado. Entonces, se me ocurrió con un programa digamos sub.

Oye, una vez más soy yo abhishekmorla,

Este blog trata sobre cómo se puede romper el cifrado del lado del cliente con el análisis del código fuente y cómo se pueden leer los archivos internos del servidor de Windows, es decir , LFI , pero después de pasar por alto una capa de cifrado .
Entonces, se me ocurrió un programa, digamos sub.domain.com y las credenciales se proporcionan en el alcance.

Durante el inicio de sesión, descubrí que estaba encriptando el nombre de usuario y la contraseña.

y más tarde, descifrar el nombre de usuario para mostrarlo en la interfaz.
después de buscar en Google, obtuve este hermoso blog de Sameer Bhatt " https://bhattsameer.github.io/2021/01/01/client-side-encryption-bypass-part-1.html ", después de revisarlo.
En primer lugar capturé la solicitud de inicio de sesión en el eructo y comencé a buscar las variables en las fuentes, si la aplicación usa alguna función javascript del lado del cliente para cifrar el nombre de usuario y la contraseña, después de buscar algunas palabras clave, se me ocurrió una función llamada encryptData () que utiliza CryptoJS .

y la aplicación no solo usa cifrado simple, han implementado una clave, iv, modo y relleno de acuerdo con la documentación dehttps://cryptojs.gitbook.io/
Ahora mi objetivo principal es encontrar la clave, los valores iv para cifrar/descifrar con éxito nuestros valores, comencé a profundizar más en las fuentes y luego se me ocurrió otra variable llamada fotograma clave, que se usó en la parte de descifrado. y esa es la clave secreta codificada utilizada para la clave y los valores iv

Finalmente pude encontrar que la clave y los valores iv no son más que CryptoJS.enc.Utf8.parse ("secret_key").
Instalé localmente el paquete npm y construí la misma función utilizada en el código fuente,

const key = CryptoJS.enc.Utf8.parse("secret_key");
  const iv1 = CryptoJS.enc.Utf8.parse("secret_key");
  const encrypted = CryptoJS.AES.encrypt("C://Windows//System32//drivers//etc//hosts", key, {
    keySize: 16,
    iv: iv1,
    mode: CryptoJS.mode.CBC,
    padding: CryptoJS.pad.Pkcs7
});
console.log(encrypted+""); // will give the encrypted value

  console.log("For decryption : ");
  var cipher = "KSxIfH6RWYGA==";
    const plainText = CryptoJS.AES.decrypt(cipher, key, {
        keySize: 16,
        iv: iv1,
        mode: CryptoJS.mode.CBC,
        padding: CryptoJS.pad.Pkcs7
    });
    console.log(plainText.toString(CryptoJS.enc.Utf8)); // will give the decrypted value

y ahora la parte interesante,
después de un escaneo de eructos, se me ocurrió un archivo llamado " ViewDocumentFile " que tiene un parámetro de ruta que toma un valor cifrado, después de descifrar con nuestro archivo JS anterior, se encontró que es una ruta de un png que es D:\\website\\logo.png ,

Busqué en Google algunas cargas útiles de LFI basadas en Windows y obtuve C://Windows//System32//drivers//etc//hosts , hice el cifrado y lo pasé al parámetro de ruta y boom, podemos leer archivos internos simplemente rompiendo algo de cifrado.

y así es como la lectura de archivos JS es una parte importante de la prueba. (una lección que aprendí de una conferencia de seguridad).

¡gracias por leer!

LinkedIn:https://www.linkedin.com/in/abhishekmorla/

Twitter:https://twitter.com/abhishekmorla