<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Kirby — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/vendors/kirby/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata — refreshed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Wed, 03 Jan 2024 12:00:00 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/vendors/kirby/feed.xml" rel="self" type="application/rss+xml"/><item><title>Kirby CMS Missing Authorization Vulnerability</title><link>https://feed.craftedsignal.io/briefs/2024-01-kirby-auth-bypass/</link><pubDate>Wed, 03 Jan 2024 12:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-kirby-auth-bypass/</guid><description>Kirby CMS versions before 4.9.0 and between 5.0.0 and 5.3.3 contain a missing authorization vulnerability, allowing authenticated Panel users to access site model, user, and role information without proper permission checks, potentially leading to unauthorized information disclosure.</description><content:encoded><![CDATA[<p>Kirby CMS, a file-based content management system, has a missing authorization flaw that allows authenticated users to access sensitive site, user, and role information without the necessary permissions. This vulnerability affects installations where there are potentially untrusted authenticated users. The issue stems from the lack of permission settings controlling access to the site model, users, and user roles. Specifically, the permissions <code>site.access</code>, <code>user.access</code>, <code>users.access</code>, <code>user.list</code>, and <code>users.list</code> were missing. This vulnerability was reported by @HuajiHD and patched in Kirby versions 4.9.0 and 5.4.0. Sites that explicitly intend all authenticated users to have read access to all site, user, and role information are not affected.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker obtains valid credentials for a user account with access to the Kirby Panel.</li>
<li>The attacker authenticates to the Kirby Panel using their credentials.</li>
<li>The attacker crafts a request to access the site model data. This could involve accessing specific API endpoints related to site configuration.</li>
<li>The attacker sends a request to list all users within the Kirby CMS.</li>
<li>The system, lacking proper authorization checks, returns the requested site model and user list data to the attacker.</li>
<li>The attacker sends a request to list existing roles, their names, descriptions, and configured permissions.</li>
<li>The system returns the requested role information, again bypassing intended permission restrictions.</li>
<li>The attacker gains unauthorized knowledge of the site structure, user accounts, and role permissions, which can be used to escalate privileges or further compromise the system.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation of this vulnerability allows an attacker with low-privilege Panel access to enumerate users, roles, and site configurations. This information can be used to identify privileged accounts, understand the site&rsquo;s structure, and potentially escalate privileges by exploiting other vulnerabilities or misconfigurations. This impacts all Kirby sites using versions &lt;= 4.8.0 and versions &gt;= 5.0.0 and &lt;= 5.3.3 where authenticated users are not fully trusted.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Upgrade to Kirby version 4.9.0 or 5.4.0 or later to patch the vulnerability as described in the advisory.</li>
<li>Review user roles and permissions after upgrading to ensure appropriate access controls are in place.</li>
<li>Monitor web server logs for suspicious requests targeting user and role enumeration endpoints after deploying the below rules.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>authorization</category><category>privilege-escalation</category><category>web-application</category></item></channel></rss>