[
https://issues.apache.org/jira/browse/KNOX-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Hanicz updated KNOX-3416:
-------------------------------
Description:
Reported by n0mi1k Security
The KnoxSSO WebSSO endpoint reads the originalUrl request parameter (already
decoded once by the servlet container) into a value it validates against the
redirect whitelist and then emits to the Location header, but the whitelist
check decodes the value a SECOND time and derives the host to match from that
double-decoded string, while the value actually sent to the browser is the
once-decoded original — so a crafted originalUrl passes the whitelist as a
trusted host yet redirects the browser to a different, attacker-chosen host.
Concretely, RegExUtils.checkBaseUrlAgainstWhitelist calls URLDecoder.decode a
second time and checks new URL(decodedURL).getHost(), so
originalUrl=[https://<trusted-knox-host>:443%[email protected]|https://%3Ctrusted-knox-host%3E:443%[email protected]/]/
decodes once (container) to
[https://<trusted-knox-host>:443%[email protected]|https://%3Ctrusted-knox-host%3E:443%[email protected]/]/,
the whitelist decodes it again to
[https://<trusted-knox-host>:443/@evil.example|https://%3Ctrusted-knox-host%3E/@evil.example]/
whose host is the trusted Knox host (whitelist PASS), but the emitted Location
keeps the %2f so the browser parses the host as evil.example. There is no
userinfo guard on this path (Urls.containsUserInfo exists in the codebase and
is applied on another redirect path, but not here), and the redirect whitelist
is auto-derived by default when knoxsso.redirect.whitelist.regex is unset, so
this is a default-configuration bypass of the SSO redirect control; a victim
who follows a crafted KnoxSSO link is authenticated and then redirected to the
attacker's origin (a related KnoxSSO URL-parsing redirect issue is the same
class as CVE-2021-42357).
> KnoxSSO redirects to untrusted site
> -----------------------------------
>
> Key: KNOX-3416
> URL: https://issues.apache.org/jira/browse/KNOX-3416
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Affects Versions: 2.1.0, 3.0.0, 3.1.0
> Reporter: Tamás Hanicz
> Assignee: Tamás Hanicz
> Priority: Blocker
> Fix For: 3.0.0, 3.1.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Reported by n0mi1k Security
>
> The KnoxSSO WebSSO endpoint reads the originalUrl request parameter (already
> decoded once by the servlet container) into a value it validates against the
> redirect whitelist and then emits to the Location header, but the whitelist
> check decodes the value a SECOND time and derives the host to match from that
> double-decoded string, while the value actually sent to the browser is the
> once-decoded original — so a crafted originalUrl passes the whitelist as a
> trusted host yet redirects the browser to a different, attacker-chosen host.
> Concretely, RegExUtils.checkBaseUrlAgainstWhitelist calls URLDecoder.decode a
> second time and checks new URL(decodedURL).getHost(), so
> originalUrl=[https://<trusted-knox-host>:443%[email protected]|https://%3Ctrusted-knox-host%3E:443%[email protected]/]/
> decodes once (container) to
> [https://<trusted-knox-host>:443%[email protected]|https://%3Ctrusted-knox-host%3E:443%[email protected]/]/,
> the whitelist decodes it again to
> [https://<trusted-knox-host>:443/@evil.example|https://%3Ctrusted-knox-host%3E/@evil.example]/
> whose host is the trusted Knox host (whitelist PASS), but the emitted
> Location keeps the %2f so the browser parses the host as evil.example. There
> is no userinfo guard on this path (Urls.containsUserInfo exists in the
> codebase and is applied on another redirect path, but not here), and the
> redirect whitelist is auto-derived by default when
> knoxsso.redirect.whitelist.regex is unset, so this is a default-configuration
> bypass of the SSO redirect control; a victim who follows a crafted KnoxSSO
> link is authenticated and then redirected to the attacker's origin (a related
> KnoxSSO URL-parsing redirect issue is the same class as CVE-2021-42357).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
