Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to analyze two vulnerabilities in RDG

2025-01-19 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Network Security >

Share

Shulou(Shulou.com)05/31 Report--

In this issue, the editor will bring you an analysis of how to carry out the two loopholes in RDG. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

Remote Desktop Gateway, or remote Desktop Gateway (RDG), formerly called "Terminal Services Gateway", or remote Desktop (RDP), is a Windows server component that provides routing capabilities. In the application scenario of RDG, users do not need to connect directly to the RDP server, but directly connect to the gateway. After successful authentication of the gateway, the gateway forwards RDP traffic to the address specified by the user, so the gateway is actually a proxy here. At this time, only the gateway needs to open the external network, and all other RDP servers can be protected by the firewall. Because the attack surface of RDP is larger, we need to set up the RDG environment correctly to significantly reduce the possible attack surface.

In the January 2020 security update, Microsoft fixed two vulnerabilities in RDG. The assigned vulnerability numbers are CVE-2020-0609 and CVE-2020-0610, both of which may allow an attacker to implement pre-authenticated remote code execution on the target device.

Version difference analysis-before and after repair

Before doing vulnerability analysis, we need to analyze the differences between pre-and post-fix versions of the affected DLL.

After analysis, it is found that only one of the functions has been modified. First, RDG supports three different protocols, namely HTTP, HTTPS, and UDP. The updated function is mainly responsible for dealing with the UDP protocol. In general, we can compare the pre-update and post-update functions, but this function has a very large amount of code and has a number of changes. Therefore, we directly give the pseudo code corresponding to this function, and delete some unrelated code:

The UDP protocol processed by RDG allows a message with a large amount of data to be divided into multiple independent UDP packets. Because UDP belongs to a connectionless protocol, the order in which messages arrive is variable. The function of this function is to reorganize messages to ensure that each message is in the correct location. Each message contains a Header that contains the following field data:

Fragment_id: the specific position of the message in the sequence

Num_fragments: the total number of messages in the sequence

Fragment_length: the length of message data.

The message handling function uses the Header data of the message to ensure that the received messages are reorganized in the correct order. However, there is a vulnerability in the implementation of this function, so an attacker will be able to exploit this vulnerability to carry out attacks.

CVE-2020-0609 analysis

The memcpy_s () function copies each segmented data (fragment) to an offset address in the reassembly buffer, which is allocated on the heap, and the offset for each segment is obtained by fragment_idx 1000. However, the boundary-checking logic here does not take into account the offset. Here we can assume buffer_size= 1000, and then we send a message containing two segments.

1. The first segmented message (fragment_id=0) is 1 in length. At this point, this- > bytes_written equals 0, so you can pass the boundary check.

2. The code writes 1 byte of data to the buffer address with an offset of 0, bytes_written+ 1. The second segmented message (fragment_id=1) is 998 in length, where this- > bytes_written= 1 and 1 + 998 < 1000, so it can pass the boundary check.

3. The code writes 998 bytes of data to a buffer address with an offset of 1000 (fragment_id*1000), causing 998 bytes to be written after the end of the buffer.

It is important to note that the messages here do not necessarily arrive in order. If we send the fragment_id=65535 in the first message, it will be written to the address with an offset of 65535x 1000, which is 65534000 bytes after the end of the buffer. An attacker can modify the fragment_id to write up to 999 bytes of data to any address with an offset of 1 to 65534000 after the buffer. Compared with the traditional linear heap overflow vulnerability, this vulnerability is more flexible. An attacker can take advantage of this vulnerability not only to control the size of the data written, but also to control where the data is written. If combined with other techniques, attackers will be able to achieve more accurate data writes to avoid unnecessary data crashes.

CVE-2020-0610 analysis

The class object in the figure above contains an array of 32-bit unsigned integers, where each array element corresponds to 1 segmented data. When a segmented data is received, the corresponding data value changes from 0 to 1. When all elements are set to 1, the code completes the message reorganization operation and starts processing the complete message. This array can hold up to 64 elements, but fragment_id values range from 0 to 65535. The only validation that the code performs is to make sure that the fragment_ id value is less than num_fragments, but the latter can also be set to 65535. Therefore, we can set fragment_id to any value between 65 and 65535, so that we can write 1 (TRUE) outside the data boundary. You may find it difficult to implement remote code execution by setting only 1 value to 1, but even a small change can have a huge impact on the normal behavior of the program.

Loophole mitigation

If the user does not install a vulnerability fix, the attacker will be able to exploit the vulnerability. Therefore, users can also directly disable the UDP transport feature, or use a firewall to block the UDP port to solve this security problem.

Vulnerability detection tool

Rdg_scanner_cve-2020-0609: [click I get]

How to detect Example: python3 rdg_scanner_cve-2020-0609.py 192.168.1.1 on UDP 3391Example2 python3 rdg_scanner_cve-2020 24 # vuln scan for cve-2020-0609 on UDP 3391Example2 python3 rdg_scanner_cve-2020-0609.py 192.168.1.1 check webpage for RD gatewayExample3: python3 rdg_scanner_cve-2020-0609.py 192.168.1.1Example4: python3 rdg_scanner_cve-2020-0609.py fakewebsiteaddress.comExample5: python3 rdg_scanner_cve-2020-0609.py as15169Example6: Python3 rdg_scanner_cve-2020-0609.py file:hostfile.txtusage: rdg_scanner_cve-2020-0609.py [- h] [--port PORT] [--webcheck] [--verbose] targetNo installation required.Debian/Kali needs: apt-get install python3-netaddr this is what the editor shares with you on how to analyze two vulnerabilities in RDG. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Network Security

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report