360MeshFire Team: CVE-2 0 1 6-5 6 9 6 TCP bypass attack analysis and reproduce it-vulnerability warning-the black bar safety net

2016-09-01T00:00:00
ID MYHACK58:62201678614
Type myhack58
Reporter 佚名
Modified 2016-09-01T00:00:00

Description

! 0x01 vulnerability background 8 on 1 0-1 2, USENIX Security Conference, University of California, Riverside and the US Army research laboratory 6 the researchers uncovered about the RFC 5 9 6 1 security vulnerability. To prevent “blind in-window”attack, RFC5961 the introduction of Challenge ACK mechanism, but the Linux kernel in the implementation of the RFC document introduces a vulnerability that an attacker can use the vulnerability through the bypass attack accurately infer TCP connection port number, SEQ number and ACK number, in order to achieve TCP Reset attacks and data injection attacks. In order to better understand the CVE-2 0 1 6-5 6 9 6, I think we need to back out the vulnerability of the historical reason. In RFC5961(August 2 0 1 0)occurs before, is TCP the wild times. blind in-window attacks has been for the TCP Protocol the main attack means. The TCP Protocol itself in the design time and does not take full account of its security, TCP security depends on its connection to the non-deterministic, whether the attack succeeds depends largely on the attacker can predict the TCP sequence number and the port number, once the forgery packet sequence number falls into the window, the attacker can go to inject the malicious link or directly reset the connection. The serial number is a 3 2-bit random number, there 4 0 multi billion possible, the port number 6 5 5 3 5 May, the combination of this design can be within a certain range defense against TCP denial of service and injection attacks. In RFC5961 before the advent of the Linux tcp stack is doing: When a strip has been properly established link receives a syn packet, it will do this: if the syn packet in the seq in the legal window, The receiving side reset connection else The recipient sends an ack packet When a strip has been properly established link receives a RST packet, will do this: if the RST packet in the seq in the legal window The receiving side reset connection else The recipient sends an ack packet If you want to prevent data injection, will do this: 1. seq within the legal scope of 2. ack number must be valid range: [SND. UNA-(231-1,THE SND. NXT] The SND represents the sending party, the UNA indicates that the transmission is not acknowledged the received seq NXT represents the next to send the packet of seq More than one such logic will find a very obvious problem that I, as a bypass attack, I'm blind guess a source address, a source port and a seq number, bring this packet to the server, if this link on the server just there, and seq number also just in the legitimate within the window, then the connection will be the server reset, refused to attack successfully; But if I didn't guess? Didn't guess? Didn't guess? Okay, didn't guess that I'll continue to back guess the chant, I put the address of the 0-2 5 5, port 1-6 5 5 3 5, seq from 0-4G hair again, I'm a machine is not enough, I'm looking for a hundred station to send the attack packets. As a result, there will certainly be a lot of connecting strokes, and then to be reset off. In fact, this is the so-called blind in-window attacks, the legitimate window comfortably. However, RFC5961 appeared. RFC5961 appears, like the darkness in a light, illuminating the entire TCP Protocol stack, also brighten up the Linux system to a great future. RFC5961 of the TCP Protocol stack processing makes the following recommendations: When a strip has been properly established link receives a syn packet, should do this: Does seq do check directly reply to a challenge ack to the source end of the if the received source terminal sent the reset packet The receiving side reset the connection, else The receiving side discards the syn packet If the source end is indeed lost the connection information, to the re-beginning that of a new one, then after receiving the challenge packet, the original server will send RST packet to confirm the current connection need to be closed. When a strip has been properly established link receives a RST packet, it should do this: if seq == expect to receive value The receiving party disconnected elif seq in the active window The recipient sends a challenge packet else The receiving side discards the packet, ignore If you want to prevent false data injection, it should be done: The receiving end receives the ACK packet, to confirm the legitimacy of the condition: 1. seq within the legal scope of 2. if the ack number in the [SND. UNA-MAX. SND. WN, SND. NXT】 (Note: MAX. SND. WND indicates the recipient can see the sender's maximum window range) then Confirm a legitimate packet elif ack number in the rest of the range: [SND. UNA −(2 3 1 − 1), SND. UNA − MAX. SND. W ND) then Need to send a challenge packet ! The above is RFC5961 of the TCP Protocol stack on how to modify the proposed recommendations. Can be clearly seen, when increasing the source confirmed that after the process, the syn packet is the bypass attack has become impossible, because you can not receive the challeng ack. You only fully Monte address+port+seq value can be reset off of a connection, which greatly increases the cost, blind in-window attacks become very difficult. In the prevention of data injection aspect, RFC5961 before the mechanism of ACK range is relatively large, relatively easy to can hit the effective range. RFC5961 the proposed mechanism, although not completely eliminate, but greatly reduces packet is successfully injected, lifting the attacker's cost, in itself, is also a defensive one. Here, we should think RFC5961 should be made a lot of good advice, why is the bypass attack again becomes possible? In RFC5961 shows a section on the challenges of packet throttling mechanisms to prevent excessive challenge Pack affect system performance, it is precisely this proposal that lead to the linux kernel in strict compliance with the agreements do after implementation, the trigger this vulnerability: Package check strictly, will lead to trigger more challenge packs. In order to reduce the CPU and bandwidth loss, REF5961 recommended the introduction of challenge packet throttling mechanisms: limiting the unit time interval, the challenge Pack.

[1] [2] [3] next