-
Notifications
You must be signed in to change notification settings - Fork 672
Description
Hello, I tried to contact the developers of your product but did not get a response, so I decided to raise the vulnerability to you in the issue, hoping that you can fix it as soon as possible to avoid a wider impact of the vulnerability.
Principle of the vulnerability
Gitblit uses file storage to manage user information, passwords, account types, and permissions. When a user with low privileges modifies their information, if they use line breaks and space characters, they can create new users or assign higher
higher privileges.
The relevant code logic is in the write
function of com.gitblit.ConfigUserService
. The reason for the problem is that gitblit does not do a checksum on the characters entered by the user, and malicious characters are printed directly in the file, causing gitblit to parse the file incorrectly when reading it.
The location where users are saved is in data/users.conf.
The default users.conf is as follows.
[user "admin"]
password = admin
role = "#admin"
role = "#notfederated"
The user name is admin, the password is admin, and the user's permissions are admin permissions, and the file will change as the user logs in. After logging in once the file reads
[user "admin"]
accountType = LOCAL
cookie = aad70b95ca5ffe59c88cd567b91999b263acb659
emailMeOnMyTicketChanges = true
password = PBKDF2:$0$33c135e0e31a085587920e0981401bc34169cc1460a321d8f748969939383ce76c403eda5015281d2ff3b2203c5c2397154662b3219ba979476d9e7bc47c29f9
role = "#admin"
role = "#notfederated"
If there is a new user, a new user will be created below the user, and which will be accompanied by the user's emailAddress information, if the attacker in the modification of their own emailAddress, the emailAddress set to [email protected]\n\trole = "#admin"\n[user "other"]
,you can modify the permissions of their own user to admin.
Vulnerability recurrence
- The attacker has an account with no privileges, username
test
, passwordtest1
, and privilegesNone
, and the current users.conf is.
[user "admin"]
accountType = LOCAL
cookie = aad70b95ca5ffe59c88cd567b91999b263acb659
emailMeOnMyTicketChanges = true
password = PBKDF2:$0$33c135e0e31a085587920e0981401bc34169cc1460a321d8f748969939383ce76c403eda5015281d2ff3b2203c5c2397154662b3219ba979476d9e7bc47c29f9
role = "#admin"
role = "#notfederated"
[user "test"]
accountType = LOCAL
cookie = 513b0430e84cbccad003a3b8e5c614797a311e70
emailAddress = [email protected]
emailMeOnMyTicketChanges = true
password = PBKDF2:$0$ec5a6828b39c0ec958c7f70861b0bbc7aa3b74e45ebfe8a0ffc0689923b517e96a8d8039392631369b6cd2d6742771d582f0e4cb24c254cdbdc126c7ebcd88f4
role = "#none"
-
After logging in, click on Profile->Preferences in order
Turn on burpsuite's blocking feature, click Save, and block the request with burpsuite.
Modify the value of emailAddress%3Atext to [email protected]\n\trole = "#admin"\n[user "other"]
after url encoding. The[user "other"]
at the end of the payload is to avoid the impact of the original role = "#none".
The encoding can be done using burpsuite's Decode function
- After modifying the request body and sending the request, users.conf changes to the following state.
You can see that the test user has become admin privileges. Refreshing the page, at this point the test user has full access to gitblit, and can see all Git repositories and manage all users and teams