A method and system for testing the password security of an RTSP protocol

Abstract

This invention relates to a method and system for testing the cryptographic security of the RTSP protocol in the field of network security assessment technology. Addressing the inefficiency of existing testing tools caused by the password attempt lockout mechanism of surveillance cameras, this invention utilizes idle and interconnected IP addresses within the same intranet segment to construct an address pool, and divides the IP sub-pools according to the target number. Idle IP addresses are mapped to the MAC addresses of the test host through ARP spoofing, and then TCP packets with forged source addresses are constructed using raw sockets. Whenever the number of attempts for a single IP reaches the lockout threshold, the system switches to the next idle IP address to continue testing, eliminating the lockout waiting time. This method combines ARP spoofing technology with raw sockets to achieve source address masquerading and dynamic rotation at the link and network layers, overcoming the forced waiting time caused by source IP-based lockout strategies, achieving efficient cryptographic security assessment, and supporting multi-target parallel testing.

Description

Technical Field

[0001] This invention relates to a method and system for testing the cryptographic security of the RTSP protocol, belonging to the field of network security testing technology. Background Technology

[0002] Real-Time Streaming Protocol (RTSP) is a widely used streaming media control protocol for network cameras. It operates on TCP port 554 and uses request methods such as DESCRIBE and PLAY to establish and control the video stream. RTSP supports both Basic and Digest authentication. Digest authentication, following RFC 2617, uses the MD5 algorithm to hash parameters such as username, password, realm, and nonce to generate a response value. Mainstream camera devices from Hikvision, Dahua, and Uniview all support this authentication method.

[0003] Surveillance cameras generally have a password attempt lockout mechanism: after a number of consecutive erroneous authentication requests from the same source IP address, subsequent authentication requests from that source IP address will be temporarily rejected. A typical configuration is to lock for 5 minutes after 5 consecutive erroneous attempts.

[0004] Existing RTSP password security testing tools (such as Hydra) use a single, fixed source IP address to send authentication requests. Due to the aforementioned locking mechanism, each time a locking threshold is reached, it must wait for unlocking before continuing, resulting in extremely low testing efficiency. Furthermore, existing tools do not utilize the large number of idle and interconnected IP address resources on the internal network; the locking threshold is not configurable, making it unable to adapt to the differentiated security policies of different vendors; and their multi-target parallel processing capabilities are insufficient, making it difficult to efficiently test cameras deployed in batches on the internal network. Summary of the Invention

[0005] The purpose of this invention is to propose a method and system for testing the cryptographic security of the RTSP protocol, aiming to solve the problem of low efficiency caused by the fixed source IP address locking mechanism in existing RTSP protocol cryptographic security testing tools.

[0006] To achieve the above objectives, the present invention is implemented using the following technical solution:

[0007] In a first aspect, the present invention proposes a method for testing the cryptographic security of the RTSP protocol, comprising:

[0008] S1: Construct a pool of free IP addresses;

[0009] S2: Obtain the authentication parameters and manufacturer fingerprints of each target camera, wherein the manufacturer fingerprints are used to determine the locking threshold of the target camera;

[0010] S3: Divide the idle IP address pool into IP sub-pools equal to the number of target cameras, wherein each IP sub-pool contains at least one IP address;

[0011] S4: Assign the target cameras to the corresponding IP sub-pools; for each target camera, select an idle IP address from the IP sub-pool in sequence, send an ARP Reply data packet to the target camera, establish an ARP mapping relationship between the idle IP address and the local MAC address, and repeatedly send ARP Reply data packets at a preset time interval to maintain the mapping validity;

[0012] S5: Based on the ARP mapping relationship, construct IP packets using raw sockets and establish a TCP connection, wherein the source address of the IP packet header is set to the idle IP address and the destination address is set to the IP address of the target camera;

[0013] S6: Initiate an authentication request to the target camera based on the TCP connection. If authentication fails, determine whether the current number of authentication attempts has reached the lock threshold.

[0014] If the locking threshold is reached, the ARP Reply packet is sent to the target camera to clear the previously established ARP mapping relationship between the idle IP address and the local MAC address, and the system switches to the next idle IP address in the IP sub-pool, returning to step S4 to continue testing;

[0015] If the lock threshold is not reached, try the next password with the current free IP address. If the lock is released, start the next round of testing from the first position of the sub-pool, and repeat S4-S6 until the password dictionary is exhausted or authentication is successful.

[0016] If the authentication is successful, record the authentication result and end the test;

[0017] S7: Sends an ARP packet containing the correct MAC address mapping to all target cameras, restoring the ARP cache table of the target cameras to the state before the test.

[0018] Furthermore, the construction of the idle IP address pool includes:

[0019] Perform a host discovery scan on the target intranet segment to identify active hosts within the segment and exclude occupied IP addresses to obtain free IP addresses;

[0020] The idle IP addresses are verified for TCP connectivity with the target camera, and the verified idle IP addresses are added to the idle IP address pool.

[0021] Furthermore, obtaining the authentication parameters and manufacturer fingerprints of each target camera includes:

[0022] For each target camera in the target camera list, send a DESCRIBE request without authentication information;

[0023] Receive the unauthorized response returned by the target camera, and extract the authentication parameters from the WWW-Authenticate field of the unauthorized response; determine the authentication method in the authentication parameters based on the content of the WWW-Authenticate field;

[0024] Record the authentication parameters for each target camera and the vendor fingerprint information extracted from the Server field of the unauthorized response.

[0025] Furthermore, the step of constructing IP packets and establishing a TCP connection using raw sockets includes:

[0026] The TCP SYN data packet is encapsulated in a raw socket and sent to the RTSP service port of the target camera.

[0027] In response to receiving a SYN-ACK packet from the target camera based on the TCP SYN packet, an ACK packet is sent in reply, completing the TCP three-way handshake and establishing a TCP connection with the target camera's RTSP service.

[0028] Furthermore, the step of initiating an authentication request to the target camera based on the TCP connection includes:

[0029] Send a first DESCRIBE request to the target camera. The first DESCRIBE request does not contain authentication information.

[0030] Receive authentication parameters returned by the target camera;

[0031] Based on the authentication method in the authentication parameters, select the corresponding authentication processing strategy to construct a second DESCRIBE request, which contains authentication information.

[0032] Send the second DESCRIBE request to the target camera.

[0033] Further, the step of selecting the corresponding authentication processing strategy and constructing the second DESCRIBE request based on the authentication method in the authentication parameters includes:

[0034] When the authentication method is Digest authentication, the realm value and nonce value are extracted from the authentication parameters. According to RFC 2617, the username, realm, and password are concatenated into a first string and the MD5 value is calculated to obtain HA1. The request method and request URI are concatenated into a second string and the MD5 value is calculated to obtain HA2. HA1, nonce, and HA2 are concatenated and the MD5 value is calculated to obtain the response value. The username, realm, nonce, request URI, and response value are concatenated in a specified format to generate the Authorization header field.

[0035] When the authentication method is Basic authentication, the username and password are concatenated with colons and then Base64 encoded to generate the Authorization header field.

[0036] Furthermore, the method also includes:

[0037] When an ARP Reply packet is sent to the target camera to establish an ARP mapping relationship, the ARP mapping maintenance timer repeatedly sends the ARP Reply packet to the target camera at preset time intervals during the test task until the test task ends.

[0038] Secondly, this invention proposes an RTSP protocol cryptographic security testing system, including an address pool management module, an ARP spoofing module, a raw socket sending and receiving module, an RTSP protocol construction module, a lock detection and scheduling module, and an ARP recovery module;

[0039] The address pool management module is used to construct an idle IP address pool, obtain the authentication parameters and manufacturer fingerprints of each target camera, and divide the idle IP address pool into IP sub-pools equal to the number of target cameras, wherein each IP sub-pool contains at least one IP address, and the manufacturer fingerprint is used to determine the locking threshold of the target camera.

[0040] The ARP spoofing module divides the target cameras into corresponding IP sub-pools; for each target camera, it sequentially selects an idle IP address from the IP sub-pool, sends an ARP Reply packet to the target camera, establishes an ARP mapping relationship between the idle IP address and the local MAC address, so that the idle IP address in the target camera's ARP cache table corresponds to the local MAC address;

[0041] The raw socket transceiver module is used to construct IP packets and establish TCP connections using raw sockets based on the ARP mapping relationship, wherein the source address of the IP packet header is set to the idle IP address and the destination address is set to the IP address of the target camera.

[0042] The RTSP protocol construction module is used to initiate an authentication request to the target camera based on the TCP connection;

[0043] The lock detection and scheduling module is used to determine whether the current number of authentication attempts has reached the lock threshold when authentication fails. If the lock threshold is reached, the module sends the ARP Reply data packet to the target camera to clear the previously established ARP mapping relationship between the idle IP address and the local MAC address, and switches to the next idle IP address in the sub-pool to continue testing. If the lock threshold is not reached, the module tries the next password with the current idle IP address. If the lock is released, the module starts the next round of testing from the first position in the sub-pool until the password dictionary is exhausted or authentication is successful.

[0044] The ARP recovery module is used to send ARP packets containing the correct MAC address mapping to all target cameras, restoring the ARP cache table of the target cameras to the state before the test.

[0045] Furthermore, the system also includes a password dictionary management module and a result management and reporting module;

[0046] The password dictionary management module is used to manage the loading and traversal positions of usernames and password dictionaries;

[0047] The results management and reporting module is used to record authentication results and output a password security assessment report.

[0048] Furthermore, the system also includes a multi-target parallel controller for managing parallel testing tasks of multiple target cameras.

[0049] Compared with the prior art, the present invention has the following beneficial effects:

[0050] 1. This invention switches to the next IP address after completing a password attempt within the locking threshold range for each available IP address, eliminating the forced waiting time caused by the locking strategy. Under stable ARP mapping conditions, the test rate can be nearly N times that of the single-IP method, where N is the number of available free IPs. Test requests are distributed from multiple IPs, and the security logs show multi-source, scattered accesses, making it less likely to trigger alarms based on IP aggregation.

[0051] 2. Since multiple devices, such as cameras, are likely to use the same password in an intranet environment, this invention can initiate probe requests to multiple target devices simultaneously based on the same password during IP rotation, realizing parallel detection of multiple targets. The total throughput of the test increases linearly with the number of target devices.

[0052] 3. This invention utilizes existing idle IP addresses on the intranet, eliminating the need to deploy proxy servers or VPNs, and requiring no modification to the local network configuration.

[0053] 4. The locking threshold, IP pool size, authentication method, ARP mapping maintenance interval and other parameters of this invention can all be configured, and adaptive locking threshold adjustment is supported, which can be adapted to cameras of different manufacturers and models.

[0054] 5. After the test is completed, the target camera's ARP cache is restored to the state before the test, and the network layer topology is automatically restored without causing a lasting impact on the target network. Attached Figure Description

[0055] Figure 1 This is a flowchart of the RTSP protocol cryptographic security testing method proposed in this embodiment;

[0056] Figure 2 This is a structural diagram of the RTSP protocol cryptographic security testing system proposed in this embodiment. Detailed Implementation

[0057] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit the present invention or its application or use.

[0058] Example 1:

[0059] This embodiment proposes a method for testing the cryptographic security of the RTSP protocol, such as... Figure 1 As shown, it includes the following steps:

[0060] S1: Perform host discovery scanning on the target intranet segment, identify active hosts within the segment, exclude occupied IP addresses, verify the TCP connectivity of the remaining free IP addresses with the target camera, and add the verified free IP addresses to the free IP address pool.

[0061] S2: Perform RTSP service probing on the target camera list, send an unauthenticated DESCRIBE request to obtain the authentication parameters in the 401 response, determine the authentication method based on the WWW-Authenticate field, and record the authentication parameters and vendor fingerprints for each target. The vendor fingerprint is obtained by analyzing the Server field, authentication domain name (realm), default URL path, and other feature information in the RTSP response message to identify the vendor to which the target device belongs, and then obtain the account lock-in threshold of the device of that vendor. This provides a decision basis for the timing of dynamic IP rotation. For example, the lock-in threshold may be different for different brands of cameras. Dahua and Hikvision usually set it to 5 times.

[0062] S3: Divide the idle IP address pool into a corresponding number of IP sub-pools according to the number of target cameras. Each target independently uses the allocated sub-pool to perform password tests in parallel.

[0063] S4: For each target camera, select an idle IP address sequentially from its IP sub-pool, construct an ARP Reply packet and send it to the target camera, establish a mapping relationship between the idle IP address and the local MAC address, so that the idle IP address in the target camera's ARP cache table corresponds to the local MAC address; at the same time, start an ARP mapping maintenance timer, repeatedly send the ARP Reply packet to the target camera at preset time intervals, maintain the validity of the ARP mapping until the test task of the idle IP address ends;

[0064] S5: Construct an IP packet using a raw socket, set the source address of the IP header to the current free IP address, set the destination address to the target camera IP, encapsulate a TCP SYN packet and send it to the RTSP service port of the target camera through the raw socket, receive the SYN-ACK packet returned by the target, reply with an ACK packet to complete the TCP three-way handshake, and establish a TCP connection with the RTSP service of the target camera.

[0065] S6: On the established TCP connection, first send an unauthenticated DESCRIBE request to obtain the authentication parameters of the current session, and then construct a DESCRIBE request containing authentication information: For Digest authentication, extract the realm and nonce values ​​from the authentication parameters. According to RFC 2617, concatenate the username, realm, and password into a first string and calculate the MD5 value to obtain HA1. Concatenate the request method and request URI into a second string and calculate the MD5 value to obtain HA2. Concatenate HA1, nonce, and HA2 and calculate the MD5 value to obtain the response value. Concatenate the username, realm, nonce, request URI, and response value in the specified format to generate the Authorization header field. For Basic authentication, concatenate the username and password with a colon and then Base64 encode them to generate the Authorization header field. Determine the authentication result based on the response status code: status code 200 indicates successful authentication, and status code 401 indicates authentication failure.

[0066] S7: If authentication is successful, record the authentication result and end the test;

[0067] If authentication fails, determine if the number of password attempts for the current idle IP address has reached a preset lockout threshold:

[0068] If the locking threshold is reached, send an ARP Reply packet to the target camera to clear the ARP mapping relationship between the previously established free IP address and the local MAC address, and switch to the next free IP address in the IP sub-pool, then return to step S4 to continue testing;

[0069] If the lock threshold is not reached, try the next password with the current free IP address. If the lock is released, start the next round of testing from the first position of the sub-pool, and repeat S4-S7 until the password dictionary is exhausted or authentication is successful.

[0070] S8: After all IP addresses in the sub-pool have completed one round of attempts, send a probe request to the target camera to check whether the lock is released. If a 401 is returned, it is determined that the lock has been released. Start the next round of testing from the first position of the sub-pool until the password dictionary is traversed or successful authentication is detected.

[0071] S9: After the test process is completed, send an ARP packet containing the correct MAC address mapping to all target cameras to restore the ARP cache table of the target cameras to the state before the test.

[0072] Example 2:

[0073] This embodiment proposes an RTSP protocol cryptographic security testing system based on Embodiment 1, such as... Figure 2 As shown, it includes an address pool management module, an ARP spoofing module, a raw socket transceiver module, an RTSP protocol construction module, a lock detection and scheduling module, a multi-target parallel controller, a password dictionary management module, and a password dictionary management module.

[0074] The address pool management module is used to perform host discovery scanning on the target intranet segment, build and maintain a pool of free IP addresses, and support the allocation of sub-pools according to the target number.

[0075] The ARP spoofing module is used to construct ARP Reply packets and send them to the target camera. It establishes a mapping relationship between idle IP addresses and the local MAC addresses, maintains the mapping validity at preset intervals, and restores the target ARP cache table after the test is completed.

[0076] The raw socket transceiver module is used to construct and send raw IP / TCP data packets, implement TCP three-way handshake and RTSP request transmission and reception with the source address being an idle IP address. The automatic response of the operating system protocol stack to the idle IP address needs to be disabled to avoid connection interference.

[0077] The RTSP protocol construction module is used to construct an RTSP DESCRIBE request containing Basic or Digest authentication information. It re-acquires the authentication parameters of the current session each time the TCP connection is re-established and parses the response status code.

[0078] The lock detection and scheduling module is used to manage password attempt counting, IP handover scheduling, and lock status detection;

[0079] The multi-target parallel controller is used to manage parallel test tasks, sub-pool allocation, and dictionary traversal synchronization for multiple targets.

[0080] The password dictionary management module is used to manage the loading and traversal of usernames and password dictionaries; the result management and reporting module is used to record authentication results and output password security assessment reports.

[0081] Example 3:

[0082] This embodiment, based on Embodiment 1, provides a specific application scenario to further illustrate the execution flow of the method in a real system.

[0083] Within the same intranet, there is a high probability that cameras of the same model and with the same password will be deployed. Parallel testing was conducted on 10 target cameras within the 192.168.1.0 / 24 network segment.

[0084] In this embodiment, 192.168.1.100 is selected as a typical case of a single target to conduct a detailed password security assessment. In this embodiment, the maximum number of password attempts for each IP address is preset to be the same as the camera locking threshold, which is 5 times.

[0085] 1. Address Pool Construction

[0086] The Nmap tool was used to perform an ARP host discovery scan on the 192.168.1.0 / 24 network segment, identifying 10 online hosts containing the target camera. The remaining 245 unused IPs were used as candidate free addresses. For each candidate IP, a loopback reachability verification was performed: a TCP SYN packet was constructed using the free IP as the spoofed source address and sent to 192.168.1.100:554. If the local machine received a SYN-ACK response from the target, it meant the packet sent by the free IP could be correctly routed back to the local machine by the target, and it was added to the available address pool; otherwise, it was discarded. The final available address pool was used for subsequent testing.

[0087] 2. Target Detection

[0088] Sending an unauthenticated DESCRIBE request to 192.168.1.100:554: DESCRIBE rtsp: / / 192.168.1.100:554 / cam / realmonitor?channel=1&subtype=0 RTSP / 1.0. The server returns a 401 Unauthorized response. By parsing the WWW-Authenticate field in the response header, the realm="IP Camera" and nonce value are extracted, thus confirming that the target device uses the Digest authentication method.

[0089] 3. ARP spoofing and TCP connection establishment

[0090] Construct an ARP Reply packet with op=2, the target MAC address is the camera's MAC address, the source protocol address (psrc) is set to the first free IP address in the address pool, 192.168.1.X, and the source hardware address (hwsrc) is set to the local machine's MAC address, and send it to 192.168.1.100.

[0091] When constructing an ARP Reply packet, the opcode field op is set to 2 to identify the packet as an ARP reply, the target MAC is set to the camera's MAC address, the source protocol address (psrc) is specified as the first free IP address in the address pool, 192.168.1.X, and the source hardware address (hwsrc) is set to the local MAC address. The packet is then sent to 192.168.1.100, thereby forging the binding relationship between the free IP and the local MAC address to the target device.

[0092] The camera updates its ARP cache, mapping 192.168.1.X to the local MAC address. Simultaneously, an ARP mapping sustain timer is started, repeatedly sending the ARP Reply packet to the camera every 60 seconds to ensure the mapping remains valid during the test.

[0093] A raw IP packet is constructed, and its IP header information is set, specifying the source address as 192.168.1.X, the destination address as 192.168.1.100, and the protocol type as TCP. Then, a TCPSYN packet is encapsulated inside this IP packet, where the destination port in the TCP header is fixed at 554, and the source port is randomly generated by the system. The constructed complete packet is then sent out through the created raw socket. At this point, the camera returns a SYN-ACK response to the local machine based on the spoofed ARP cache. After capturing this SYN-ACK packet in user space, the local machine actively constructs and sends an ACK packet, thus completing the three-way handshake with the camera.

[0094] 4. Password Attempts

[0095] On an established TCP connection, the RTSP protocol construction module ② first sends an unauthenticated DESCRIBE request to re-acquire the realm and nonce parameters of the current TCP session (this step is performed every time a TCP connection is rebuilt to obtain the latest nonce), and then constructs a Digest authentication request:

[0096] On an established TCP connection, firstly, an unauthenticated DESCRIBE request is sent to re-acquire the realm and nonce parameters of the current TCP session. This step is performed every time the TCP connection is rebuilt to obtain the latest nonce value. Then, a Digest authentication request is constructed based on the obtained realm and nonce parameters.

[0097] HA1 = MD5("admin:IP Camera:password")

[0098] HA2= MD5("DESCRIBE:rtsp: / / 192.168.1.100:554 / cam / realmonitor?channel=1&subtype=0")

[0099] response = MD5(HA1 + ":" + nonce + ":" + HA2)

[0100] The above response is appended to the Authorization header and sent. If a 200 OK response is returned, authentication is successful, the valid password is recorded, and the test ends; if a 401 response is returned, the next password is retrieved from the current position in the password dictionary, a new TCP connection is established, and this step is repeated.

[0101] 5. IP handover and rotation mechanism

[0102] Since the maximum number of password attempts is the same as the camera lock threshold, there is no need to wait for the camera to actually return a lock response. After each source IP address completes 5 password attempts, an IP switch is triggered immediately, avoiding the waste of waiting time after the IP enters the locked state.

[0103] When switching IPs, an ARP Reply is sent to the next available IP address 192.168.1.51. A new IP-MAC mapping is established in the camera's ARP cache. There is no need to actively clear the old entries. The old entries will expire naturally after their Time To Live (TTL) expires. This does not affect the testing of the new IP. At the same time, the forged source address is updated, and the TCP three-way handshake is re-completed with the new IP. The next password is then retrieved from the current interrupted position in the password dictionary for testing.

[0104] During IP switching, an ARP Reply is sent to the next available IP address, 192.168.1.51, establishing a new IP-MAC mapping in the camera's ARP cache. There's no need to actively clear old entries; they will expire naturally after their Time-to-Live (TTL) expires, without affecting testing with the new IP. Simultaneously, the forged source address is updated, and the TCP three-way handshake is re-completed with the new IP. The next password is then retrieved from the password dictionary at the point of interruption to continue testing.

[0105] 6. Continuous testing and multi-round mechanism

[0106] The password dictionary is traversed in order, and each IP continues to traverse from the position where it was interrupted last time. Each IP can switch after a maximum of 5 attempts. In theory, a single round of traversal of all available IPs can complete 245×5=1225 password attempts. The actual value depends on the number of available IPs in the address pool.

[0107] If the password dictionary capacity exceeds the number of attempts per round, the system automatically enters a waiting phase after all available IPs have completed one round of use. Once the earliest used IP is unlocked, the next round of password traversal begins from that IP, continuing until the password dictionary traversal is complete or the correct password is found. Compared to waiting for a single IP to unlock, this system utilizes multiple idle IPs to handle test requests in parallel, significantly reducing waiting time. The actual effective testing efficiency is approximately several times the number of available IPs compared to the single-IP method.

[0108] Since this embodiment uses a parallel mode to test 10 targets, the number of password attempts per round can be increased to 245×5×10=12250, further improving testing efficiency.

[0109] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims. All of these forms are within the protection scope of the present invention.

Claims

1. A method for testing the cryptographic security of the RTSP protocol, characterized in that, include: S1: Construct a pool of free IP addresses; S2: Obtain the authentication parameters and manufacturer fingerprints of each target camera, wherein the manufacturer fingerprints are used to determine the locking threshold of the target camera; S3: Divide the idle IP address pool into IP sub-pools equal to the number of target cameras, wherein each IP sub-pool contains at least one IP address; S4: Assign the target cameras to the corresponding IP sub-pools; for each target camera, select an idle IP address from the IP sub-pools in sequence, send an ARP Reply data packet to the target camera, and establish an ARP mapping relationship between the idle IP address and the local MAC address; S5: Based on the ARP mapping relationship, construct IP packets using raw sockets and establish a TCP connection, wherein the source address of the IP packet header is set to an idle IP address and the destination address is set to the IP address of the target camera; S6: Initiate an authentication request to the target camera based on the TCP connection. If authentication fails, determine whether the current number of authentication attempts has reached the lock threshold. If the locking threshold is reached, the ARP Reply packet is sent to the target camera to clear the ARP mapping relationship between the previously established free IP address and the local MAC address, and then the system switches to the next free IP address in the IP sub-pool and returns to S4 to continue testing. If the lock threshold is not reached, try the next password with the current free IP address. If the lock is released, start the next round of testing from the first position of the sub-pool, and repeat S4-S6 until the password dictionary is exhausted or authentication is successful. If authentication is successful, record the authentication result and end the test; S7: Sends an ARP packet containing the correct MAC address mapping to all target cameras, restoring the ARP cache table of the target cameras to the state before the test.

2. The RTSP protocol cryptographic security testing method according to claim 1, characterized in that, The construction of the idle IP address pool includes: Perform a host discovery scan on the target intranet segment to identify active hosts within the segment and exclude occupied IP addresses to obtain free IP addresses; The idle IP addresses are verified for TCP connectivity with the target camera, and the verified idle IP addresses are added to the idle IP address pool.

3. The RTSP protocol cryptographic security testing method according to claim 1, characterized in that, The acquisition of authentication parameters and manufacturer fingerprints for each target camera includes: For each target camera in the target camera list, send a DESCRIBE request without authentication information; Receive the unauthorized response returned by the target camera and extract the authentication parameters from the WWW-Authenticate field of the unauthorized response; record the authentication parameters of each target camera and the manufacturer fingerprint information extracted from the Server field of the unauthorized response.

4. The RTSP protocol cryptographic security testing method according to claim 1, characterized in that, The process of constructing IP packets and establishing TCP connections using raw sockets includes: The TCP SYN data packet is encapsulated in a raw socket and sent to the RTSP service port of the target camera. In response to receiving a SYN-ACK packet from the target camera based on the TCP SYN packet, an ACK packet is sent in reply, completing the TCP three-way handshake and establishing a TCP connection with the target camera's RTSP service.

5. The RTSP protocol cryptographic security testing method according to claim 1, characterized in that, The step of initiating an authentication request to the target camera based on the TCP connection includes: Send a first DESCRIBE request to the target camera. The first DESCRIBE request does not contain authentication information. Receive authentication parameters returned by the target camera; Based on the authentication method in the authentication parameters, select the corresponding authentication processing strategy to construct a second DESCRIBE request, which contains authentication information. Send the second DESCRIBE request to the target camera.

6. The RTSP protocol cryptographic security testing method according to claim 5, characterized in that, The step of selecting the corresponding authentication processing strategy and constructing the second DESCRIBE request based on the authentication method in the authentication parameters includes: When the authentication method is Digest authentication, the realm value and nonce value are extracted from the authentication parameters. According to RFC 2617, the username, realm, and password are concatenated into a first string and the MD5 value is calculated to obtain HA1. The request method and request URI are concatenated into a second string and the MD5 value is calculated to obtain HA2. HA1, nonce, and HA2 are concatenated and the MD5 value is calculated to obtain the response value. The username, realm, nonce, request URI, and response value are concatenated in a specified format to generate the Authorization header field. When the authentication method is Basic authentication, the username and password are concatenated with colons and then Base64 encoded to generate the Authorization header field.

7. The RTSP protocol cryptographic security testing method according to claim 1, characterized in that, The method further includes: When an ARP Reply packet is sent to the target camera to establish an ARP mapping relationship, the ARP mapping maintenance timer repeatedly sends the ARP Reply packet to the target camera at preset time intervals during the test task until the test task ends.

8. A cryptographic security testing system for the RTSP protocol, characterized in that, It includes an address pool management module, an ARP spoofing module, a raw socket transceiver module, an RTSP protocol construction module, a lock detection and scheduling module, and an ARP recovery module; The address pool management module is used to construct an idle IP address pool, obtain the authentication parameters and manufacturer fingerprints of each target camera, and divide the idle IP address pool into IP sub-pools equal to the number of target cameras, wherein each IP sub-pool contains at least one IP address, and the manufacturer fingerprint is used to determine the locking threshold of the target camera. The ARP spoofing module is used to divide the target camera into the corresponding IP sub-pool; for each target camera, an idle IP address is selected sequentially from the IP sub-pool, and an ARP Reply data packet is sent to the target camera to establish an ARP mapping relationship between the idle IP address and the local MAC address, so that the idle IP address in the target camera's ARP cache table corresponds to the local MAC address; The raw socket transceiver module is used to construct IP packets and establish TCP connections using raw sockets based on the ARP mapping relationship, wherein the source address of the IP packet header is set to the idle IP address and the destination address is set to the IP address of the target camera. The RTSP protocol construction module is used to initiate an authentication request to the target camera based on the TCP connection; The lock detection and scheduling module is used to determine whether the current number of authentication attempts has reached the lock threshold when authentication fails. If the lock threshold is reached, the module sends the ARP Reply data packet to the target camera to clear the previously established ARP mapping relationship between the idle IP address and the local MAC address, and switches to the next idle IP address in the sub-pool to continue testing. If the lock threshold is not reached, the module tries the next password with the current idle IP address. If the lock is released, the module starts the next round of testing from the first position in the sub-pool until the password dictionary is exhausted or authentication is successful. The ARP recovery module is used to send ARP packets containing the correct MAC address mapping to all target cameras, restoring the ARP cache table of the target cameras to the state before the test.

9. The RTSP protocol cryptographic security testing system according to claim 8, characterized in that, The system also includes a password dictionary management module and a result management and reporting module; The password dictionary management module is used to manage the loading and traversal positions of usernames and password dictionaries; The results management and reporting module is used to record authentication results and output a password security assessment report.

10. The RTSP protocol cryptographic security testing system according to claim 8, characterized in that, The system also includes a multi-target parallel controller for managing parallel testing tasks from multiple target cameras.

Images