fofa query a random point of a virtual simulation training system, there are multiple unauthorized, logical vulnerabilities, and there is a file upload vulnerability leads to getshell, retrieved almost a dozen schools in use
It feels easier to start with a virtual simulation system, a system that may be used by many schools
fofa syntax
1. Check digit multiplexing leads to bypassing audit login
This logic flaw is pretty outrageous, haven't come across it before
Provide account registration function, after registration, you can use the account password to log in (need to audit), you can also cell phone verification code to log in directly, but if you do not register to fill out the complete information, the account directly logged in the account is a guest account, there is no authority
First register an account 10086/test123456_
Register here to fill in the information, you need to get a cell phone verification code (later inadvertently found that there is no verification code here)
Login with registered account password, prompting that the account is under review, unable to login
When the audit is not passed, login with the verification code of the cell phone number, click to get the verification code will be prompted to have been registered, and will not send the verification code again
However, the verification code can be reused, and you can log in directly with the code you just registered with.
Successful login, click on the upper right corner to enter the teaching space, successful access, permission check is OK!
leaks
findsomething found an interface /pubapi/userinfo that literally looks at user information
access, return no user id, meaning that the lack of user id parameters, common general is id, uid, uuid, userId, userid, xxid these
Splice on the uid=, returned the user_token of the user, and tested the id is sequential, that is to say, through this interface can be traversed to obtain the user's token of the whole station
The token is used for authentication, so it's easy to say, look for the interface and then add the obtained token for utilization
Unauthorized creation/uploading of hands-on training resources
Looking at the burp request packet, there is an authentication field Authorization
Throw it to jwt to decrypt it, there's not much valuable information, here uid=0 should be a default value
The value of Authorization was found to be passed/pubapi/authorizeThe access_token returned by the interface
An interface for creating hands-on training resources was found, prompting theRequires UtGuess Ut is user_token.
Add the Ut field with the value that was just passed through the/pubapi/userinfoThe token of the teacher's account that was obtained, created successfully
Sending it again reveals that the labid is sequential and can be traversed
View user hands-on training resources
/eapi/console/myresource?type=1&page=1&limit=20
Replace the token with whichever user's can see which user's resources and ids
Unauthorized deletion of hands-on training resources
Since the labid is sequential, this causes traversing the recourseid to delete all resources
/eapi/console/delrecourse?type=1&recourseid=
Deleting a non-existent one will result in a deletion failure
3. Bucket traversal
The interface to get user_token above returned the address of the avatar, which was found to be the storage bucket
Accessing the url and deleting the path behind the domain leaks all the keys to the storage bucket
The key splice to the back allows access to view/download the file
/{key}
When you go to the backend, there is an upload course standard in the course creation function point.
Uploaded php, no filtering, directly uploaded successfully and returned the file address
Access to the returned address, parsed successfully
I found a total of three upload interfaces in the backend, some of which do filtering and some of which don't
No illegal infiltration