600 pts
@ilektrojohn identified that GitHub.com’s SAML implementation did not fully revoke the ResponseID set on SAML Response messages to prevent replay attacks. While this attribute was not checked, other mitigations were in place to prevent these attacks. However, to futher protect against replay issues, we made changes to revoke ResponseIDs found in previously received SAML Response messages.
5,000 pts
@jkakavas identitifed that GitHub Enterprise did not require all assertion elements within an SAML response to be signed. By exploiting a discrepency between what signature within a SAML response was validated and what assertion element was used from the SAML response for authentication, it was possible to use a previously signed SAML response to authenticate as an arbitrary user.
We fixed this issue by performing much stricter validation of SAML signatures, ensuring all assertion element within a SAML response have been properly signed. This issue has been fixed in GitHub Enterprise 2.8.7, 2.7.11, 2.6.16, 2.5.21, and 2.4.23.
10,000 pts
@jkakavas discovered a bug with the signature checking in GitHub Enterprise’s parsing of SAML responses. SAML uses cryptographic signatures to verify the authenticity of a SAML response. However, the signature validation logic was skipped due to a bug in our lookup of the public key associated with the SAML provider. This could have allowed an attacker to construct a SAML response that could arbitrarily set the authenticated user account.
We addressed the issue by fixing the bug related to the way we were looking up the SAML provider’s public key. In addition, we updated our test suite around this functionality and changed the signature validation logic to “fail closed” if a similar bug occurred in the future. This issue has been fixed in GitHub Enterprise 2.8.6, 2.7.10, 2.6.15, or 2.5.20 (version 2.4.X was not affected).
