UPNP is interpreted as follows: For a private computer, BitComet's UPnP function can make the NAT module of the gateway or router do automatic port mapping, and map the port that BitComet listens to from the gateway or router to the intranet computer.
The network firewall module of the gateway or router starts opening this port to other computers on the Internet.
NAT traversal technology allows web applications to detect whether they are behind a UPnP-capable NAT device. These programs then get a shared global routable IP address and configure port mapping to forward packets from NAT external ports to the internal ports used by the application – all automatically, without the need for users to manually map ports or do anything else. NAT traversal technology allows network devices or peer-to-peer applications to communicate with the outside world through NAT gateways by dynamically opening and closing communication ports with external services.
In other words, it can be summarized as follows: the conversion efficiency of simple NAT is not high, and if UPNP technology is launched, the efficiency of NAT data conversion can be improved.
Sounds like a good thing. But what ???
UPNP has serious shortcomings: Here's an excerpt:
The first flaw is that the use of buffers is not checked and restricted. External attackers can gain control privileges of the entire system through this! Since the UPnp function must use the computer's ports to work, an attacker who gains control may also use these ports to achieve the attacker's goal. The consequences of this defect are very serious, no matter which version of the Windows system, as long as UPnP is running, there is this danger! But strictly speaking, this is not entirely a problem with the UPnP technology itself, but more of a programming oversight.
The second flaw is related to the working mechanism of UPnP. The defect exists in the "device discovery" phase when UPnP is working. Discovering a device can be divided into two situations: if a UPnP-capable computer boots successfully and connects to the network, it will immediately send a "broadcast" to the network, notifying the UPnP device on the network that it is ready, and at the programming level, the broadcast content is an M-SEARCH (message) instruction. The broadcast will be "heard" by all devices within the "sound reach". And feedback its relevant information to the computer for subsequent control purposes.
Similarly, if a device is just connected to the network, it will also send a "notification" to the network that it is ready to accept control from the network, which is a NOTIFY indication at the programming level. It will also be accepted by all computers within the "sound reach" range. The computer will "sense" that the device has "reported to itself". In fact, NOTIFY instructions are not only sent to computers, but can also be heard by other network devices. It is in the above-mentioned broadcast and listening that there is a problem!
If a hacker sends a NOTIFY instruction to a user's system, the user's system will receive this NOTIFY instruction and connect to a specific server under its instructions, and then request a download service to the corresponding server - download the content of the service to be executed. The server will of course respond to this request. The UPnP service system will explain the description of the device, requesting more files to be sent, and the server will need to respond to those requests. In this way, a "request-response" cycle is formed, which occupies a large amount of system resources and causes the UPnP system service speed to slow down or even stop. So, this flaw will make a "denial of service" attack possible!
In fact, in other words, the UPNP function is constantly consuming its own network resources during the use stage, and when the network resources of the device are exhausted, there will be a phenomenon of suspended animation. Just look at the above information. |
Posted on 10/12/2017 8:58:01 AM
|
|
|
|
