The announcement writes the authentication bypass and marks it as 9.8 points, should we stop this kind of temporary login function first?
Do not stop in one fell swoop, but first judge three things: whether the site is using this kind of temporary login function, whether the entrance is accessible to the outside, and whether there is an alternative normal path. The core of bypassing authentication is 'no need to prove identity to enter', which has a greater impact than overwriting, and the disposal rhythm should be arranged according to this nature, not just looking at the score number.
The difference between bypassing authentication and overwriting
Exceeding authorization is 'the identity is true, but the permissions are used too much', bypassing authentication is 'not passing the identity verification at all'. The consequence of the latter is directly the loss of the background entry, and the actions that can be performed usually include reading and modifying content, changing configurations, and issuing tasks. The wording in the public announcement can be used as a sample: A temporary login plugin of some content management system was determined to have a bypassing authentication issue in a certain version and before, rated at the highest level, with a score of 9.8, indicating a low exploitation threshold and an impact scope covering the default installation.
Distinguishing between the two also affects the troubleshooting method: to exceed authorization, you need to look at the role and permission matrix, and to bypass authentication, you need to see which path can bypass the verification and what can be obtained after bypassing.
Three risks of temporary login feature
The reason for the existence of this kind of function is often that "operations or customer service needs to temporarily log in to the background to check", so the risks are concentrated in three points:
- Applicant entity: who can initiate a temporary channel. If it can be triggered by an interface or form, the attack surface is on the Internet.
- Validity period: how long does the voucher survive. Whether it is a few hours or a few minutes, the consequences of exploitation are a level apart.
- Protection level: in addition to the one-time credential, whether it is subject to secondary verification and source restriction constraints.
The most frequently relaxed in the three is the validity period, and the most frequently omitted is the second verification. The design should default to short duration, single use, and immediately invalid after use, and limit the executable scope to read-only or specified columns.
The first three steps taken after seeing the high-risk score
| Judgment item | Issues to be confirmed | Corresponding action |
|---|---|---|
| Whether in use | Is the temporary login a regular operational means or a legacy | Close the entry directly if not used, and limit the processing time if used |
| Whether accessible from the outside | Is the entry a public network path or accessible only within the internal network | Converge the exposed range and limit the front-end access |
| Is there an alternative path | Can an audited account and permission group replacement be used instead | Replace shared temporary channels with group permissions |
Discuss the disposal method only after completion: if possible, upgrade; if not, first shut down the function or limit the entrance, instead of hurrying to modify the code to bypass the problem.
Shut down or set a deadline, grade according to business impact
Not all high-risk announcements point to
Make sure to confirm if there are any side effects when disabling: if the temporary channel has been relied on by the customer service process, directly closing it will lead to a backlog of work orders. At this point, it should first provide an audited alternative account, and then close the old channel.
The approach of closing up the background authentication and session management.
The means of closing up determine whether there are any available actions at the time of the incident. Four basic configurations:
- Authentication methods are concentrated on server-side verification, the login chain uses JWT signed tickets to avoid spreading the verification logic among plugins and templates.
- The certificate can be centrally rotated. When the program is upgraded, the site signature key must be rotated synchronously and the administrator's password must be changed, only the program is upgraded without changing the certificate, and the forged path is still usable; v3.6.6 also fixed the SQL injection in the list sorting parameters and the login certificate of the site switch can be forged, which exactly shows that these two things should be done together.
- The session can be forcibly invalidated. One-time tickets are discarded after use, and abnormal logins can be offline in batches.
- The entrance has anti-automation protection. The backend and sensitive form access verification code verification are used to prevent brute force and script刷 interfaces.
The site-wide high-risk operation should set the exposure range according to the capability domain, multi-site management, backup and upgrade should be turned off by default, and explicit enablement and approval records should be left when needed. In the event of an incident, it should be able to immediately confirm who has made changes.
Common questions
Q: Is it necessary to immediately shut down and upgrade the service if the rating is high?A: First, check if it is in use and whether it is accessible from the outside. If the function is not enabled, the entry can be closed; if it is in use and accessible via the public network, it needs to be addressed immediately. Upgrade first if possible, and if not, temporarily offline the function.
Q: Is changing the administrator password enough?Answer: Not enough. Issues involving certificate forgery involve the signing and issuance stages, only changing the password without moving the signature key and old sessions, the attack path has not converged.
Question: How do you know if it has been exploited?Answer: Check the background sessions at abnormal times in the login and operation logs, successful login records from unexpected sources, and whether the time of content or configuration changes falls near the announcement window; if an anomaly is found, first check the files and data with recoverable backups.