Java website security attack and defense (frightening 24 hours)

  People are afraid of being famous and pigs are afraid of being strong. The same is true in the Internet field. Once you have fame and achievements in the industry, you will be attacked and cracked by yourself. It is only a matter of time before it is broken. The code is deployed on the C side. No matter how encrypted it is, the moves are fixed. Once it is seen through, it will basically be sentenced to death. Products that are heavy on the S-end are more likely to be attacked, don't they want traffic, then it's better to have their own CC, and the DOS broiler will choke you to death! As for the crack, it is the continuous station of the two sides' offense and defense. Our current product is a combination of BS and CS. In the second half of last year, we made some small achievements and word of mouth in the industry. As a result, since December last year, a wave of hackers began to continue to use Trojan horses to crack the S terminal. , For a full three months, our two sides have attacked and defended each other. Until today, we have analyzed each other's attack methods, and we are still safe for the time being! Here we mainly talk about how the opponent attacked and how we defended.
  Our S-side is based on products developed with JSP. For the cracking of such JSP and ASP dynamic products, the most effective way to attack is to use JSP or ASP Trojan. A JSP is essentially a Servlet, as long as the JSP Trojan can be kept in the In the running directory, you can do whatever you want. A JAVA.IO.RUNTIME command can basically take down all the required information of the entire server through the CMD BAT command, including creating a temporary RDP login user, so as long as your product must be done in the backend check.
  When working on BS or CS projects, there is a development principle that seems very unreasonable: "Never trust the front end". This sentence seems to be breaking the team unity, but in fact it reminds the back end to pay more attention during development. Security and exception error checking. We did Baidu traffic promotion in the early days, and we need to automate many websites. We are also a C-side, but not an official B-side. The same function can be achieved by capturing packets and simulating requests, but if the backend thinks about Front-end verification is enough. Some verifications depend on the front-end not to be done, and sometimes there will be big problems. For example, there are two very famous bugs in WeChat. Push the bug of adding an upper limit, thinking that a mobile phone can only have up to thousands of contacts, and the result is that this loophole is used to refresh friends through the address book! There is also the function of @friends in the circle of friends as expected. The WeChat front-end limit is that only @10 friends are allowed in a circle of friends. As a result, the front-end verification is bypassed, and the relevant parameters are directly changed to 3000 in the simulation request. Can @3000 friends!
Back to our own products, this wave of hackers took advantage of the fact that we did not perform a strict verification mechanism for parameters when uploading services, and directly uploaded the jsp directory to the server application directory by forging parameters. The application file directory and related information will be slowly passed away. The following is a screenshot of a jsp Trojan. You can see various methods of traversing and creating downloaded files. He only needs to access the corresponding jsp file through the domain name and pass the relevant parameters to call the corresponding method, because jsp is actually a Servlet

defense . Of course, the method of this kind of Trojan is to block the upload related loopholes, and implement a strict verification mechanism in the corresponding upload method, so this kind of Trojan is solved, and it has appeared 1-2 times in other similar places in succession. After being discovered by us, we blocked them one by one! In fact, the best way to defend against this attack method of using upload vulnerabilities to retain Trojans is to use a third-party direct transmission service, such as Alibaba Cloud's OSS service, to directly implement all upload and download services through third-party services, without intermediate There is any intermediate material left on its own server, and even direct traffic to the server will not be generated.
So I stopped for a while. When I was performing a routine inspection last night, I suddenly found that there were several jsp files in the project and the directory. It looked like a Trojan horse, so I immediately logged in to Alibaba Cloud to check and kill the Trojan horse. I was killed by the other party. At that time, I thought that this was impossible. All upload loopholes were blocked, so I immediately checked the relevant Trojan access log in the web server and found the following request log: I was


stunned for a moment, It's unlikely, and it works! Anyway, I thought about it all night, and I dreamed about the Trojan horse file in my dreams at night,
and I didn't understand how this was achieved! Since the source cannot be found, only a temporary solution can be taken. If no solution is taken, it is useless to delete a few Trojan files! With a simple analysis, you can get obvious parameter characteristics, so immediately write parameter judgments in the request filter with the team, as long as there are similar parameter characteristics, you can directly intercept and filter in the filter, and jump to the login page! I got up the next day and looked through the relevant attack logs, and sure enough, it came again. The first few were intercepted and jumped to 302 as we had imagined. It is estimated that the other party also realized that, and a test request that did not have any parameter characteristics came immediately. , the result passes normally, but does not have any effect. This wave of people probably also realized that we blocked all channels and there was no other way. They directly used the temporary user created by the Trojan file last night, so Alibaba Cloud called the police, and we killed it after 5-10 minutes. This so-called k8team user later checked and confirmed the attack method of the other party last night: the latest vulnerability of Struts! For details, please refer to the following vulnerability introduction:
http://www.chinaz.com/server/2017/0310/671333.shtml
is actually similar to the previous 2.3.15 vulnerability: you can refer to this introduction for details:
http://www. cnblogs.com/Fluorescence-tjy/p/5861970.html
The principle is to facilitate parameter escape, and then be recognized by OGNL, and then execute the respective CMD commands through java.lang.Runtime.getRuntime(). So last night's request is not difficult to understand, but I didn't expect this kind of loophole to appear in Struts again. The defense work we did temporarily last night, in fact, the principles of the methods introduced here are basically similar, the filter intercepts the parameter behavior Features, of course, have to quickly update Struts2 to a safe version!
In addition, the mobile phone must be bound to the Alibaba Cloud account, so that once Yundun recognizes the Trojan horse or calls the police, it can immediately notify you!
Finally, I will explain why this group of hackers kept attacking for more than three months before and after, and they have successfully invaded several times, but they have never cracked successfully! If it was an architectural model from a few years earlier, it would have been broken long ago! Most of the current java applications adopt a loosely coupled architecture, which splits the entire project into many independent modules for easy development. In fact, it also virtually increases the difficulty of cracking by hackers. In the past, only one module needs to be cracked, but now it may be necessary to crack 5 or more modules can be completely cracked. Although our current products do not strictly follow this method, it is basically the same idea. The entire project is divided into 5 independent modules on the S side. There are also 2 modules on the terminal, so the hackers have not been able to completely crack the existing system for so long!
I have been guarding for a whole day today, constantly analyzing the access logs, Alibaba Cloud is killing them, and the other party also gave up the attack after the last attempt at 13:45! After staying for 2 days and 1 night, I can finally go back to sleep with confidence!