Impact
What kind of vulnerability is it? Who is impacted?
Due to a bug in ASF code, introduced in version V5.2.2.2, the program didn't adequately verify effective access of the user sending proxy (i.e. [Bots]) commands. In particular, a proxy-like command sent to bot A targetting bot B has incorrectly verified user's access against bot A - instead of bot B, to which the command was originally designated. This in result allowed access to resources beyond those configured, being a security threat affecting confidentiality of other bot instances.
A successful attack exploiting this bug requires a significant access granted explicitly by original owner of the ASF process prior to that, as attacker has to control at least a single bot in the process to make use of this inadequate access verification loophole. Such access is impossible to obtain without prior ASF owner's consent, therefore vastly limiting potential damage that can be done.
While majority of users run ASF in single-user scenario, not being directly affected, those that share access to their bots, or run bots for other people, should consider upgrading ASAP.
Patches
Has the problem been patched? What versions should users upgrade to?
The issue is patched in ASF V5.2.2.5, V5.2.3.2 and future versions.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
Since successful attack requires explicit permission granted, the security threat doesn't apply to people that are the sole owners of all bots that are running as part of ASF process, that is, without having any other (human) users configured as masters, operators or family sharing. It's also a recommended workaround for the problem in case you're unable to upgrade to newer version, that is, ensuring that no other people are configured to access any declared bots, as it removes the attack vector entirely.
While not strictly a workaround, if your users already can access all of the bots (owning master permission), then there is nothing further to exploit either.
References
Are there any links users can visit to find out more?
The issue was originally introduced in #2501.
The problematic code was fixed in #2509.
Originally reported by @TheRhanderson on our ASF Discord server (not linked here).
For more information
If you have any questions or comments about this advisory:
TheRhanderson Analyst
JustArchi Analyst
Impact
What kind of vulnerability is it? Who is impacted?
Due to a bug in ASF code, introduced in version V5.2.2.2, the program didn't adequately verify effective access of the user sending proxy (i.e.
[Bots]) commands. In particular, a proxy-like command sent to botAtargetting botBhas incorrectly verified user's access against botA- instead of botB, to which the command was originally designated. This in result allowed access to resources beyond those configured, being a security threat affecting confidentiality of other bot instances.A successful attack exploiting this bug requires a significant access granted explicitly by original owner of the ASF process prior to that, as attacker has to control at least a single bot in the process to make use of this inadequate access verification loophole. Such access is impossible to obtain without prior ASF owner's consent, therefore vastly limiting potential damage that can be done.
While majority of users run ASF in single-user scenario, not being directly affected, those that share access to their bots, or run bots for other people, should consider upgrading ASAP.
Patches
Has the problem been patched? What versions should users upgrade to?
The issue is patched in ASF V5.2.2.5, V5.2.3.2 and future versions.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
Since successful attack requires explicit permission granted, the security threat doesn't apply to people that are the sole owners of all bots that are running as part of ASF process, that is, without having any other (human) users configured as masters, operators or family sharing. It's also a recommended workaround for the problem in case you're unable to upgrade to newer version, that is, ensuring that no other people are configured to access any declared bots, as it removes the attack vector entirely.
While not strictly a workaround, if your users already can access all of the bots (owning master permission), then there is nothing further to exploit either.
References
Are there any links users can visit to find out more?
The issue was originally introduced in #2501.
The problematic code was fixed in #2509.
Originally reported by @TheRhanderson on our ASF Discord server (not linked here).
For more information
If you have any questions or comments about this advisory: