Chatwoot's Misconfigured Rack_Attack.rb Does Not Appropriately Protect Against Brute Force Attacks in chatwoot/chatwoot

Valid

Reported on

Jun 10th 2022


Description

Chatwoot relies on the rack_attack.rb file to defend the application against various brute force attacks. The Chatwoot application fails to prevent brute force attacks against the listed paths when strings are appended to the end of POST directory names. Some protection still exists, primarily where more than 300 requests are made in a minute, which appears to be a default rule for the application and configuration. Provided an attacker keeps attacks within 300 per minute it is possible to bypass the configured rules.

The vulnerability was discovered in all tested directories, including:
-- /auth/sign_in.json
-- /api/v1/accounts.json
-- /super_admin/sign_in.json

As I cannot configure the environment to test the other parameters, I am unsure if they are vulnerable, however the directories do accept random strings appended to the end. NOTE - Any arbitrary add on to the end of the directory can bypass the restrictions.

Note that I have tested a possible fix for the issue locally by modifying existing rack_attack rules.

Proof of Concept

POST /auth/sign_in.json HTTP/1.1
Host: 192.168.1.3:3000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:101.0) Gecko/20100101 Firefox/101.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://192.168.1.3:3000/app/login
Content-Type: application/json
Content-Length: 74
Origin: http://192.168.1.3:3000
DNT: 1
Connection: close
Cookie: _chatwoot_session=isHDBFZBkWRHKTcjNmQPFlXVrtaswMNx7FNWeWpiULOnK%2FQakqLzHkfvY33zDMNhewz%2FBgh6VeEqUYoj3a6UA1HjD9WcQW3M0m2pM5N9Jmv88sSRp%2BiEA9dOAP9rhF3WHOIzL%2FI1BA0yWrYOMVZs6IpkAPD%2Fm3kz9E27rxzJ9%2B5fESTBmcJ0LEMT1nB8DvVRj8ULgac0RrjJOjEwySniIbg7HMOKNfP5PeF3FoodUKrhFZE%2F3SReiAt7q2FlHKVVzlwjTdjcz1sYcDTkblkVPRAFt1tYvV6oCA%3D%3D--flwWFZDdAvtdfTYe--tihOFN%2Bg9HKViJZPwD27jQ%3D%3D; user.id=eyJfcmFpbHMiOnsibWVzc2FnZSI6Ik1RPT0iLCJleHAiOm51bGwsInB1ciI6ImNvb2tpZS51c2VyLmlkIn19--d46f4e34d21234bf149d8e35067adec84d9de555; user.expires_at=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklqSXdNakl0TURZdE1UQlVNakE2TWprNk1qZ3VORGszV2lJPSIsImV4cCI6bnVsbCwicHVyIjoiY29va2llLnVzZXIuZXhwaXJlc19hdCJ9fQ%3D%3D--d6b05039464d992e99ff7641408f22cb998b6899

{"email":"joe@mayorsec.com","password":"Password123!","sso_auth_token":""}
POST /super_admin/sign_in.json HTTP/1.1
Host: 192.168.1.3:3000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:101.0) Gecko/20100101 Firefox/101.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://192.168.1.3:3000/super_admin/sign_in
Content-Type: application/x-www-form-urlencoded
Content-Length: 234
Origin: http://192.168.1.3:3000
DNT: 1
Connection: close
Cookie: _chatwoot_session=1eo0NEleyD9vD3SZGSC5fmQ8%2FqjqauSZabHRTb79DXjlOr4U8zLfpx%2BWEarESorlTjxkoyywq1dQuYez%2BflouTKpf1kCnbrgpQUO0Ejxp2WcS4eX1xfvCwTmQ6mC3FplGhEhGxMYFiyUycwvh7%2Ba5gsmDLSlyNmLBQX%2FdzZY4VSgqJOvP2ttep5hMRorsoSsqBW4z8Sf6u5rCRGJxpMxCS2rL%2BgzCNpurXoswGmIVZ5soMtONk9x7wt42fynVbd2v5ukPwmf%2B%2BneGCXv6QUOI2TbXF7wC18NtKNjtEekVAP2kX8ZkyIS%2B%2FadCrtVcFVg6N4ZLwf7OK2VTiXuHynATmNbjQ2XFUhA0nH7b9yweJ8fGRpUfSv0E8Qpl%2F6r1uQCgdsVTx%2BXjtTpi0gVAIV%2F2%2BqDSzxQmD%2BR5AJQ7KZGnpYFNVYA1Nhje6i8zCwYzd9fTCTjd%2Bh2NZ4tvN6kpQ%3D%3D--7VQsNUvJAAZPOI0f--W7uERdZvn2dJqbk%2FLiftLg%3D%3D; user.id=eyJfcmFpbHMiOnsibWVzc2FnZSI6Ik1RPT0iLCJleHAiOm51bGwsInB1ciI6ImNvb2tpZS51c2VyLmlkIn19--d46f4e34d21234bf149d8e35067adec84d9de555; user.expires_at=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklqSXdNakl0TURZdE1UQlVNakE2TWprNk1qZ3VORGszV2lJPSIsImV4cCI6bnVsbCwicHVyIjoiY29va2llLnVzZXIuZXhwaXJlc19hdCJ9fQ%3D%3D--d6b05039464d992e99ff7641408f22cb998b6899; cw_d_session_info={%22access-token%22:%225KrfuMPZEbhzLOJ6cgSUdA%22%2C%22cache-control%22:%22max-age=0%2C%20private%2C%20must-revalidate%22%2C%22client%22:%22FyV_LCCm8MdrctlhgnT6Tg%22%2C%22connection%22:%22close%22%2C%22content-length%22:%22595%22%2C%22content-type%22:%22application/json%3B%20charset=utf-8%22%2C%22etag%22:%22W/%5C%227dd1dcb51fcc95eae77b2ec9c6ad96ce%5C%22%22%2C%22expiry%22:%221660161568%22%2C%22referrer-policy%22:%22strict-origin-when-cross-origin%22%2C%22token-type%22:%22Bearer%22%2C%22uid%22:%22joe@mayorsec.com%22%2C%22x-content-type-options%22:%22nosniff%22%2C%22x-download-options%22:%22noopen%22%2C%22x-frame-options%22:%22SAMEORIGIN%22%2C%22x-permitted-cross-domain-policies%22:%22none%22%2C%22x-request-id%22:%22b90b4747-6fea-44e2-a677-ebe87930ab16%22%2C%22x-runtime%22:%220.249821%22%2C%22x-xss-protection%22:%221%3B%20mode=block%22}
Upgrade-Insecure-Requests: 1

authenticity_token=WWh5xWO3jgXwVKZb3zWM94qL52osMpbCpFFeuxRsdlgb%2B7OtMdtb%2F4FjNpY68ZA4Q67TDc0iV6OsDsS5O4d8OQ%3D%3D&super_admin%5Bemail%5D=JOANNE%40mayorsec%2ecom&super_admin%5Bpassword%5D=Password123%21&super_admin%5Bremember_me%5D=0 
POST /api/v1/accounts.json HTTP/1.1
Host: 192.168.1.3:3000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:101.0) Gecko/20100101 Firefox/101.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://192.168.1.3:3000/app/auth/signup
Content-Type: application/json
Content-Length: 144
Origin: http://192.168.1.3:3000
DNT: 1
Connection: close
Cookie: _chatwoot_session=pOArRsb8vDx6%2FpQuywQLE3E0lznJlbGrnqLLNMT9ySqt7YR4eh%2BSdWTMW6dmES79X13k5aCblM30KNbNhw7mCnpqV26eYv2LrM6XrnIu8KDwl3pubsrWEKxO0iM%2F6uUxdnY3J2Qryff78SF8vn7HPkYvS00yyAQ6JFGAcOlUL38tU7C1LxVmlLPo958m47gmGwgYruLnFPn7Rur9Oz6NMTVlmLe2maTpqv4TFB%2FvKc6kP38fZunPGVeRxPwKasUAE4%2BXyUJkb5Z6MXhrqi8PENPlbkQ1dDkFRQ%3D%3D--Cu1By7B2Un6rncH9--wgscGhl5IJUSIrAiD5e0AQ%3D%3D

{"account_name":"KATHRINE","user_full_name":"KATHRINE","email":"KATHRINE@mayorsec.com","password":"Password123!","h_captcha_client_response":""}

Impact

Impact varies for each individual vulnerability in the application. For generation of accounts, it may be possible, depending on the amount of system resources available, to create a DoS event in the server. These accounts still need to be activated; however, it is possible to identify the output Status Code to separate accounts that are generated and waiting for email verification.

For the sign in directories, it is possible to brute force login attempts to either login portal, which could lead to account compromise.

Joe Helle
6 months ago

Researcher


I would also request that this finding to receive CVE status IF accepted.

Joe Helle modified the report
6 months ago
Joe Helle
6 months ago

Researcher


Image evidence available here - https://themayor.notion.site/Rack_Attack-rb-Issue-3adb70ea251649d69af0e7822a23f493

Joe Helle modified the report
6 months ago
Joe Helle modified the report
6 months ago
Joe Helle modified the report
6 months ago
Joe Helle submitted a
6 months ago
Joe Helle
6 months ago

Researcher


Commit removed until I hear from the maintainer.

Joe Helle modified the report
6 months ago
Joe Helle modified the report
6 months ago
Joe Helle modified the report
6 months ago
We have contacted a member of the chatwoot team and are waiting to hear back 6 months ago
Joe Helle
6 months ago

Researcher


Please note that I do have a locally confirmed fix for the issue once accepted.

Joe Helle modified the report
6 months ago
We have sent a follow up to the chatwoot team. We will try again in 7 days. 6 months ago
Joe Helle modified the report
6 months ago
Joe Helle modified the report
6 months ago
Joe Helle modified the report
6 months ago
Joe Helle modified the report
6 months ago
We have sent a second follow up to the chatwoot team. We will try again in 10 days. 5 months ago
We have sent a third and final follow up to the chatwoot team. This report is now considered stale. 5 months ago
Sojan Jose modified the Severity from Critical to Low 5 months ago
Sojan Jose validated this vulnerability 5 months ago
Joe Helle has been awarded the disclosure bounty
The fix bounty is now up for grabs
The researcher's credibility has increased: +7
Joe Helle
5 months ago

Researcher


Hi @maintainer. What is the justification for the massive reduction in criticality? @admin this is one of those times that I brought up in a Issues post where the modification is not appropriate.

Joe Helle
5 months ago

Researcher


https://www.cvedetails.com/cve/CVE-2022-29084/

https://www.cvedetails.com/cve/CVE-2021-41435/ - unrestricted log in attempts based on a programmatic error

https://www.cvedetails.com/cve/CVE-2018-5469/

Yes, there are scores that are also lower than these. But the issues with the application programmatically, and the amount of APIs that are vulnerable, we're factored into the score.

@admin I have pending disclosures on this platform for the same issue, and the maintainer agreed with the high rating as well. I mean no disrespect here, but the significant differences in severity rating is not only infuriating, it's boggling. There needs to be a way for industry professionals who do this every day to have some amount of say in this process. It's not just a score applied to get the most money I can.

Jamie Slome
5 months ago

Admin


Just marking this as in discussion via LinkedIn 👍

We have sent a fix follow up to the chatwoot team. We will try again in 7 days. 5 months ago
Joe Helle
5 months ago

Researcher


@admin Just FYI with another publicly disclosed Rack Attack vulnerability. Note that the maintainer was happy to discuss the score, and we settled on 8.2 with CVE to follow. Note that the Chatwoot finding here is more severe as Chatwoot's misconfiguration affects authentication, whereas the disclosure below affected password resets and other functions such as ticket submissions.

https://huntr.dev/bounties/d914fd3c-9c48-4d4e-a3b2-6b8d09b0f229/

Jamie Slome
5 months ago

Admin


@Sojan - would be good to understand the reasoning around the reduction in severity, but also, do you have any qualified thoughts on the new references provided by @dievus?

Joe Helle
5 months ago

Researcher


https://huntr.dev/bounties/3055b3f5-6b80-4d47-8e00-3500dfb458bc/

Joe Helle
5 months ago

Researcher


^ Just an authentication endpoint as opposed to two authentication endpoints and other APIs as is the issue here.

We have sent a second fix follow up to the chatwoot team. We will try again in 10 days. 5 months ago
We have sent a third and final fix follow up to the chatwoot team. This report is now considered stale. 4 months ago
Sojan Jose
4 months ago

Maintainer


@joe @jamie, I missed out on the conversations over this thread. As per the security policy of chatwoot https://github.com/chatwoot/chatwoot/blob/develop/SECURITY.md we don't consider DOS attacks into the vulnerability program. But we wanted to appreciate the effort put forward into this report.

The system is also configured with 300 requests per minute limit, so the team didn't feel this was a critical vulnerability.

Joe Helle
4 months ago

Researcher


The issue isn’t denials of service. No appropriate security policy anywhere would allow 300 login attempts per minute, in an environment where an attacker can otherwise bypass your hard coded rules, which is the case here.

You’ll have to forgive me for feeling like this being the exact definition of a bug hunter finding a 100% valid bug in your code that has real world implications, backed up by other reports with the exact same issue, at a far higher criticality.

Joe Helle
4 months ago

Researcher


@admin so what do we do here?

Joe Helle
4 months ago

Researcher


Sorry the last message cut off.

  • The finding has nothing to do with denial of service.
  • I have other valid reports on this platform with less impact and higher criticality that have been validated and agreed upon by developers/maintainers
Joe Helle
4 months ago

Researcher


You guys literally just disclosed a High finding with account brute force and rated it at a High. https://huntr.dev/bounties/6-chatwoot/chatwoot/, which was for a completely different issue evidently.

And I can tell you right now that your rack attack fix for that report likely doesn't fix the issue found in mine.

Sojan Jose
3 months ago

Maintainer


@Joe Helle Internally, when we receive security reports, we classify the priority based on how quickly we have to address it. ( create a hotfix, fix it in the next release, and keep it in the backlog for a future release ) etc. While validating the report, we updated the severity to reflect our internal tracking; there was no other ill intent. The ability for the maintainers to update the severity was introduced by huntr only a few months back. ( hence the disparity between the report /6-chatwoot/chatwoot/ )

The team reviewed this report and realized we could have handled this instance better. Therefore, we will revert the severity to high. We want to reiterate our appreciation for your efforts and apologize for the frustration caused.

To enhance transparency, We will update our security report guidelines with more details about the internal process and discuss the severity with the reporter in instances where we decide to update it.

Sojan Jose
3 months ago

Maintainer


@Jamie Slome, I can't find an option to bump up the severity. Could you please help us with that?

Joe Helle
3 months ago

Researcher


Thank you for that @sojan. I appreciate your transparency and working with me on the issue.

In the meantime, your updated Rack Attack file is vulnerable to the attack outlined in this report. The issue is that you are using absolute directory paths (i.e. req.path ==). I just pulled this from the 2.8.1 hotfix.

 throttle('accounts/ip', limit: 5, period: 5.minutes) do |req|
    req.ip if req.path == '/api/v1/accounts' && req.post?
  end

This would be better suited to use req.path.starts.with?(<directory path>). I'm not a Ruby developer so I don't know exactly why, but the engine is processing the path with the characters appended to the end. Since the Rack config uses absolute paths, the engine isn't recognizing it as a protected API call.

I worked a similar vulnerability with an organization using a similar configuration. You can see how they implemented a working fix here - https://github.com/zammad/zammad/blob/e30aefa465ad395dd68677d0599ea3da53df4a5b/config/initializers/rack_attack.rb#L14.

I will submit my recommended fix through the dashboard here for your review. Thank you Sojan.

Joe Helle submitted a
3 months ago
Jamie Slome
3 months ago

Admin


Happy to update the severity to High 👍

@Sojan - can you please provide the CVSS vector you would like me to use?

https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator

Joe Helle
3 months ago

Researcher


Any update here @sojan ?

Sojan Jose
3 months ago

Maintainer


@jaime @joe let me know if the vector looks good

CVSS v3.1 Vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L

Sojan Jose
3 months ago

Maintainer


We have added a fix for the same in https://github.com/chatwoot/chatwoot/commit/9525d4f0346a2fdac13a0253f9180d20104a72d3

which will be available with our upcoming release.

Joe Helle
3 months ago

Researcher


Awesome. I’ll look at it soon. @admin when you correct the score can you also please refund me the point that was taken? And will the score correction appropriately set the bounty amount?

Thanks!

Joe Helle
3 months ago

Researcher


Will also need CVE assigned

Joe Helle
3 months ago

Researcher


@sojan I agree with the CVSS.

Have you tested the fix with the way I've been exploiting it? My biggest concern would be the use of regular expression that it looks like you've defined here as I didn't do much testing beyond the ".extension" add-ons I was using. Regex has a way of being bypassed, so I would definitely want to make sure you've tried a variety of injections at the end, especially characters like %.

Joe Helle
3 months ago

Researcher


I did just test with the change and it appears to work, but again, using regex can open up new challenges. But from my perspective and a few minutes of testing it appears to be functioning as you would expect.

Jamie Slome
3 months ago

Admin


Hey all, happy we have found a pathway forward here :)

Firstly, the CVSS vector provided @sojan results in a critical score (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L) of 9.4. If you are happy with this, I will proceed to update the severity. We will also make sure to bump the bounty back to the relevant severity bracket.

Regarding the CVE, @sojan, are you happy for a CVE to be published for this report?

Jamie Slome
3 months ago

Admin


I am following up on the above, as you previously mentioned that the severity should be increased to High. Just double checking whether it should be High or Critical, given the CVSS vector string you provided results in Critical.

Joe Helle
2 months ago

Researcher


Hi there @maintainer @admin. Just wanted to follow up on this as several weeks have passed since the last updates.

Joe Helle
2 months ago

Researcher


@sojan any update?

Joe Helle
a month ago

Researcher


@jamie @admin they have patched and made the fix live for this as far as I can find. As this is a managed Huntr project can you please help mediate here. The rating should have been increased, and as such this should be eligible for a bounty payout.

Additionally, can I get the point back that was initially removed with the incorrect CVSS assessment on their end?

Thank you.

https://github.com/chatwoot/chatwoot/blob/develop/config/initializers/rack_attack.rb

Joe Helle
a month ago

Researcher


Here's the commit - https://github.com/chatwoot/chatwoot/commit/9525d4f0346a2fdac13a0253f9180d20104a72d3

Sojan Jose
a month ago

Maintainer


@jamie Please go ahead. @joe, sorry for missing out on the notifications on this.

Sojan Jose marked this as fixed in v2.10.0 with commit 9525d4 a month ago
The fix bounty has been dropped
This vulnerability has been assigned a CVE
rack_attack.rb#L52 has been validated
rack_attack.rb#L57 has been validated
rack_attack.rb#L85 has been validated
rack_attack.rb#L46 has been validated
rack_attack.rb#L76 has been validated
rack_attack.rb#L67 has been validated
rack_attack.rb#L62 has been validated
Joe Helle
a month ago

Researcher


Thank you @sojan

@admin can we please get the CVE ID and scoring updated please? I'd love to finally get this one paid out and behind us. Thank you.

Pavlos
a month ago

Admin


Hey Joe! As soon as Sojan publishes this report a CVE will be assigned :)

Joe Helle
a month ago

Researcher


@pavlos was the score going to be changed too? Everything still shows low.

Joe Helle
a month ago

Researcher


@admin @pavlos it's now been posted and there is no severity increase nor bounty payment. Can we please remedy this?

Joe Helle
a month ago

Researcher


@jaime @joe let me know if the vector looks good

Per @sojan,

CVSS v3.1 Vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L

Per @jamie Hey all, happy we have found a pathway forward here :)

Firstly, the CVSS vector provided @sojan results in a critical score (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L) of 9.4. If you are happy with this, I will proceed to update the severity. We will also make sure to bump the bounty back to the relevant severity bracket.

Regarding the CVE, @sojan, are you happy for a CVE to be published for this report?

Sojan Jose published this vulnerability a month ago
Ben Harvie
a month ago

Admin


This report has now been remedied as requested, happy hunting:)

to join this conversation