MicrosoftCorrect me if i am wrong, but the main issue with the TokenCacheModule is probably a hash-collision attack (3. ISS-Authentication Bypass) as described here: https://devco.re/blog/2022/08/18/lets-dance-in-the-cache-destabilizing-hash-table-on-microsoft-iis/
essentially giving you unlimited chances to guess user credentials / brute force credentials..
The version fixed in 2022 probably fixes that username/password is compared instead of two times the username, so its much more unlikely to get a cache hit, but essentially there is no rate limit for that, so an attacker could just run brute-force / wordlist attacks against known usernames in order to try to get an collision with an existing session.
The main purpose of the TokenCacheModule is probably to not perform authentication for each and every request but instead do it once and if the hash matches re-use the cached token..
The correct fix here would be to fix the TokenCacheModule to use a better hash function / use a larger hash to make collisions highly unlikely and rate-limited the number of requests for cache-misses, so it can´t be abused by brute-forcing credentials to hit a valid cache entry...
I guess the Exchange team isn´t able to patch this, as it´s part of IIS, so they choose to recomment to just disable the Module via the CVE Mitigation script.
However this leads to potential performance issues, as know each and every request to the Exchange has to be authenticated instead of using cached token, that´s probably why BastiMS experiences performance issues / hanging Outlook clients..
From an Exchange team perspective: Is the IIS Team working on a fix of the TokenCacheModule which we can expect in the foreseable future?
