After the background login credentials are forged, what to rotate first and what to change next.
After finding that the back-end login credentials can be forged, what should be rotated first and then changed? The sequence is to rotate the signature key first, then change the admin password, and finally close the entry and authorization interface. This kind of problem is different from 'password guessed': forgery uses the signature logic, as long as the key does not change and the old ticket is still accepted, no matter how many times the admin password is changed, it cannot stop the party that has already obtained a valid ticket.
AnQiCMS fixed this type of issue in v3.6.6. The original site switch login signature combined the admin password hash with the randomly filled in string by the caller, the random string can be repeatedly generated, the ticket never expires, and there is no check on the account status or the number of errors. Once the password hash leaks, it is equivalent to long-term password-free login. After the fix, it changed to a one-time ticket issued by the server: valid for 120 seconds, valid for one use and then expires, and also added account status checks and IP error locking shared with password login.
Why rotate the signature key first
The upgrade only closed the 'new forged' path and did not revoke the 'already issued' achievements. The signature key is the trust root for all historical tickets, and as long as it does not change, the credentials obtained by the attacker before may still be valuable. Therefore, the first action after the upgrade is to rotate the signature keys of all sites to make the old signatures invalid, rather than changing the password first.
In the multi-site scenario, it is necessary to rotate site by site. In a site matrix that uses the same set of signature configurations, if only one is rotated, the other sites will still retain the trust roots that can be replayed, which is equivalent to doing nothing.
Then change the scope of the administrator password.
Password modification should cover all administrator accounts, not just the account used when a problem is discovered. The criteria for judgment range is "who has backend write permissions": super administrators, site administrators, and authorized sub-accounts to maintain content all count. The one-time password modification should also require accounts to log out from multiple devices at the same time to avoid old sessions continuing to exist after the password is changed.
This step is placed after the key rotation because the reverse order will result in an empty window where the "password has been changed, but the old ticket is still valid".
| sequence | Action | The standard for completion of judgment. |
|---|---|---|
| First | Upgrade to the fixed version | The version number matches the repair version, and the cross-site jump function is normal. |
| then | Sign key rotation per site. | All old signature tickets are invalidated. |
| After | Change all admin passwords and force re-login | All admin account sessions will be reconstructed |
| Supplement | Review login audit and exceptional accounts | No unfamiliar accounts or sessions during abnormal hours |
| Collect | Narrow down the exposure range of high-risk operational domains | Confirm the default closed state for cross-site operations |
What are the entry and form layers to collect?
The forgery of credentials belongs to the authentication layer issue, but the disposal needs to be considered with the surrounding. AnQiCMS has built-in JWT authentication, content sensitive word filtering and anti-crawling interference code, used to prevent SQL injection and XSS attacks - these two are exactly the common preliminary means to obtain password hashes, the list sorting parameter injection fixed in v3.6.6 is also a type of SQL injection. The reCAPTCHA verification code on the form side is aimed at machine batch attempts, which is not at the same level as credential forgery, but both contribute to the 'reducing the number of possible entry points' thing.
Check the interface and tool surface as well: domains for high-risk operations such as backup, upgrade, and multi-site operations are closed by default at the station level. After an incident, confirm that these domains have not been temporarily opened and then forgotten to close.
How to determine if it has been exploited
Three clues are worth reviewing: Are there successful logins during non-human hours in the login log; are there any unfamiliar administrators in the background account list; have there been newly added scheduled tasks or abnormal script files on the site? If any of these are hit, the handling cannot stop at upgrades and replacements, and a persistent investigation should be conducted according to the intrusion response, and a trusted backup should be used to restore.
Common questions
Question: Is it okay to only upgrade and not rotate the keys?Answer: No. The upgrade has closed the new forged path, but the long-term tickets that have been issued depend on the old trust root, and not rotating is equivalent to leaving the door open for old credentials.
Question: Why do we need to change all accounts' passwords at the same time?Answer: The input of the forged link may come from sensitive data of any account, and changing only one account will leave an available bypass.
Question: How to avoid the recurrence of similar issues?Answer: Incorporate version security updates into a fixed rhythm, and check for