Contournement du chiffrement côté client pour lire les fichiers internes du serveur Windows

Dec 01 2022

Hé, encore une fois, c'est moi abhishekmorla, Ce blog explique comment on peut casser le cryptage côté client avec l'analyse du code source et pouvoir lire les fichiers internes du serveur Windows, c'est-à-dire LFI, mais après avoir contourné une couche de cryptage.Alors, je suis venu avec un programme disons sous.

Hey, encore une fois c'est moi abhishekmorla,

Ce blog explique comment on peut casser le cryptage côté client avec l'analyse du code source et pouvoir lire les fichiers internes du serveur Windows, c'est-à-dire LFI , mais après avoir contourné une couche de cryptage .
Donc, je suis venu avec un programme, disons sub.domain.com et les informations d'identification sont fournies dans la portée.

Lors de la connexion, j'ai constaté qu'il cryptait le nom d'utilisateur et le mot de passe

et plus tard, déchiffrer le nom d'utilisateur pour l'afficher dans le frontal.
après quelques recherches sur Google, j'ai eu ce magnifique blog de Sameer Bhatt " https://bhattsameer.github.io/2021/01/01/client-side-encryption-bypass-part-1.html ", après l'avoir parcouru.
Premièrement capturer la demande de connexion dans le burp et j'ai commencé à rechercher les variables dans les sources, si l'application utilise une fonction javascript côté client pour chiffrer le nom d'utilisateur et le mot de passe, après avoir recherché quelques mots-clés, j'ai trouvé une fonction appelée encryptData () qui utilise CryptoJS .

et l'application n'utilise pas seulement un cryptage simple, ils ont implémenté une clé, iv, un mode et un rembourrage conformément à la documentation dehttps://cryptojs.gitbook.io/
Maintenant, mon objectif principal est de trouver la clé, les valeurs iv afin de réussir à chiffrer/déchiffrer nos valeurs, j'ai commencé à creuser davantage dans les sources, puis j'ai proposé une autre variable appelée keyframe, qui a été utilisée dans la partie déchiffrement. et c'est la clé secrète codée en dur utilisée pour les valeurs de clé et iv

J'ai finalement pu découvrir que les valeurs key et iv ne sont rien d'autre que CryptoJS.enc.Utf8.parse("secret_key").
J'ai installé localement le package npm et construit la même fonction utilisée que dans le code source,

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

et maintenant la partie intéressante,
après une analyse de burp, je suis venu avec un fichier appelé " ViewDocumentFile " qui a un paramètre de chemin qui prend une valeur cryptée, après décryptage avec notre fichier JS ci-dessus, il a été constaté qu'il s'agit d'un chemin d'un png qui est D:\\website\\logo.png ,

J'ai cherché sur Google certaines charges utiles LFI basées sur Windows et j'ai obtenu C://Windows//System32//drivers//etc//hosts , j'ai fait le cryptage et je l'ai passé dans le paramètre path et boum nous pouvons lire les fichiers internes simplement en cassant un certain cryptage.