How do I kill Newman K1 in seconds?

If the website itself does not contain significant high-risk vulnerabilities, the business logic process vulnerabilities will surely become the most difficult. Looking at the various business process vulnerabilities, we can see that they are different from high-risk vulnerabilities: (1) the performance of the problems is diverse, unable to be standardized, and standardized repair; (2) the process of proof or impact is often easier to be perceived by users, so it is easier to describe and report to the media, resulting in more adverse effects; (3) others ...... From a few days of tracking, Newman made a lot of architectural and even technical preparations for this K1 seckilling, technicians even performed a server maintenance on Sunday close to. We can say for sure that we are very careful and really want to be fair. However, unfortunately, business logic vulnerabilities have ruined all our dreams. Even though I was given to dummies, I thought the vulnerabilities were okay-_-|. In this practice, TK's Thoughts on "unknown attack, unknown attack" and backend defense from the perspective of front-end attackers have also benefited you a lot. Although we do not discuss the impact of such a flash sales strategy on the Enterprise, we can say that companies do not want to do flash sales on their own. There are many problems. This flash sale only uses the browser + front-end js simple script (you can't laugh at me and write your script poorly ......). For more information, see the following section. Detailed Description: (PS: Newman, please fix this major vulnerability before reading this article; otherwise, this hole is not repaired: WooYun: webpage injection on the Newman mobile phone website can cause second kill plug-in (or user address leakage) "> WooYun: Injection on the Newman mobile phone website can cause second kill plug-in (or user address leakage )) ==================================== root cause: www.newman.mobi's tangle of business systems and improper procedures can be found from the bottom of www.newman.mobi, the user's order and product management adopts the changed ecshop, the second kill project "Midday City" adopted a streamlined phpcms. The logic of the two is passed through some shared sessions and caches. Another bright spot that everyone may not think of is the use of redis as a cache and k-v Storage (in fact, I'm amazed that traditional enterprises dare to use nosql ). The above architecture shows that programmers are still well-developed, and those who have worked on program integration are not very easy (so seriously suggest not to speculate ). But the problem is that too much attention to the architecture may lead to improper integration of the program, resulting in the emergence of the Maginot Line of Defense-you think everyone will go through the set channel, and people can copy another path to achieve their goal. Of course, this combination is not ruled out because of the tangle of the business system-I can't stop old projects ?! Therefore, programmers are miserable and often faced with historical issues. Of course, the attacker can ignore this. If the goal is achieved, it will be OK. So how many channels are there in the business logic vulnerability that caused this flash sale? The answer is: two. ======================================== Problem Analysis: the logic "generate the Newman K1 order" has two completely different channel channels: the second kill channel logic is exposed too early, the verification code can be used multiple times, and there is no limit on the number of retries. The new-1 second kill was publicized a few days ago. For this reason, many people ran to the second kill channel for second kill, but, no verification code is required. In fact, the logic of k1's second kill has hidden the page, but the key logic has been commented out. In addition, the "qiangflow. php" appears in the annotation logic, indicating that the ecshop channel is to be followed, and the relationship with Channel 2 is indirectly shown. Although the logic was replaced with the official version in the early morning of June 4.1, the general logic was not changed, so the semi-automatic seckilling script was modified on the bus at work. This semi-automated second-kill script is used to input the verification code and repeat it to quickly submit the preemptive placement. As long as the verification code is entered correctly and the region is not refreshed, it can be used multiple times, and the program does not seem to limit the number of retries. Therefore, the logic of the channel attack is to reach, pull the verification code once, enter the verification code, and wait. However, the Newman programmer has done a wonderful job here, but he has to say that the defense is quite effective: The verification code is blank without the second kill time. This should be an attempt to defend against automated verification code Cracking in advance, and also lead to subsequent attacks. Due to channel 1's high concurrency congestion, coupled with improper server configuration, the verification code may be 502 for multiple times, the attack may fail due to slow retrieval ...... The idea is beautiful, and the reality is miserable... Channel 2 problem: the logic channel for purchasing ecshop products is still valid, and there is no limit on the number of retries. Channel 2 is actually found on channel 1. On the second kill page of Channel 1, click the product image to jump to another page. To be more specific, in the-3-31 and earlier flash sales, they all completed the jump to Channel 2. Channel 1 is only responsible for the display operation: http://www.newman.mobi/default.php?m=default&c=shop&a=item&id=xx This page can also kill the product in seconds. The submission channel is the product purchase channel of ecshop, and there is no limit on the number of retries, so it will bypass the backend restrictions of the flash sales program using the lite version phpcms; more importantly, the restrictions on repeated submission logic are placed at the front end, which is very simple. Attackers like the following: Therefore, the hypothetical Channel 2 attack method, at that day, the second page of Channel 2 will be opened directly. Then, at, the cTime will be reset to-100000, And the addToCart will be submitted again. However, the high concurrency problem caused this channel to almost crash ...... ======================================= Other questions: (1) the redis port exposes the redis port 6379 that can access www.newman.mobi and bbs.newman.mobi. You can telnet to manage the operation. However, before and after on January 1, March 31, 2013, online switch seems to have switched to another port with auth (this is the reason that "server maintenance was performed on Sunday near ). This is the output of the monitor before the switch: (2) mysql port is exposed to the outside, and leave a high-Permission unrestricted connection account to undertake WooYun: the injection of the Newman mobile phone official website can cause the second kill plug-in (or user address leakage) "> WooYun: Injection on the official website of the Newman mobile phone can cause the second kill plug-in (or user address leakage). After more detailed analysis, it is found that the mysql port is exposed to the outside world, and leave an extremely dangerous high-Permission unrestricted connection account: 'newtest' @ '% '. Although you cannot know the password, if you have enough time or are a departing employee, you may be able to know what the password of this account is, and damage the database without your knowledge. (3) The lite versions of phpcms and ecshop do not disable errors. Attackers can use this to learn about the system operation. Preparations: (1) register two test accounts (2) install the chrome browser and install the plug-in Tampermonkey (3) Compile the test script, then, insert the Tampermonkey to the page of the corresponding channel as <script>. Channel 1 ( http://www.newman.mobi/miaosha/ ), The key point is how to automatically pop up the verification code and automatically submit again. For the code, see: http://t.cn/zTAyftL Channel 2 ( http://www.newman.mobi/default.php?m=default&c=shop&a=item&id=xx ), The key point is how to cancel the addToCart retry limit. For the code, see: http://t.cn/zTAyfty Actual Situation (Channel 1): It is very tragic that, before and after the arrival of the Channel 1, the peak congestion caused many times of 502 Bad gateways. Therefore, it takes 10 seconds to obtain the verification code. Therefore, even if you submit the verification code, it is no longer possible... actual Situation (Channel 2): the programmer apparently considers Channel 2, so the page with id = 72 is directly blocked. But ....... I can open the page with id = 55. As a result, the process continues. The tragedy is that channel 1 obviously affects Channel 2, and the following error occurs many times: Is this a problem? Or does the programmer directly disconnect this channel from the database source? After repeated failures, I gave up and thought all attack cases would fail to be tested... However, after more than 20 minutes, after the congestion condition is better, the system will return to Channel 2 for automatic retry. The result will be displayed at the prompt "sorry, this product has been dismounted" many times ...... Actually succeeded ...... However, I have no idea whether the order can be successfully passed. White hats can only be tested here. You cannot determine whether the order is valid until the vulnerability is submitted.




Solution:

Looking back, Newman has a defense that is worth learning from, that is, it did not release the verification code within the second kill time (displayed as blank ). This attempt to defend against automated verification code Cracking in advance is worth noting. However, I am confused about the effect of most of Channel 1's logic. On the other hand, the frequent connection failures of 502, database, and redis on the server under high concurrency have more or less blocked the Front-End scripting attack. I don't know whether this is a good thing or a bad thing-_-|. But from the programmer's point of view, so many failures may be caused by the complexity of the architecture and the avalanche under high concurrency. Newman's IT engineers should fully assess whether such an architecture is true or not. Return to the topic. To address these problems, my personal suggestions are as follows: (1) Unified second kill channel. Now it is obvious that there are multiple channels in order to do the activity, and they should be unified at the key points (especially the second kill request points. (2) retry restrictions must be imposed on key operations and must be imposed on the server. (3) The verification code is used once, whether correct or not. (4) The code should not be deleted. Do not just comment on it as OK. There are version control such as svn, for fear of code loss... suggestions for other problems: (1) ip address access restrictions on redis port and mysql port (2) Delete the newmantest account or Apply ip address restrictions (3) display of more errors on the screen (including php errors and mysql errors)
</Script>