How I Made My Camera into a DDoS Cannon
While researching this Dahua password disclosure vulnerability, I stumbled on another flaw in the Dahua IP cameras. Combined with the password disclosure, it demonstrates how multiple vulnerabilities can be leveraged together to create a much bigger problem. Such a flaw is not normally that big by itself. It is a post-authentication bug. But considering that these cameras most likely will not have the password disclosure bug fixed, you might as well consider this vulnerability a pre-authentication vulnerability as well.
The bug resides in the processing of the Transport header during an RTSP stream negotiation. The Transport header lets the RTSP client tell the server a set of options about the stream it's about to subscribe to. It'll ask for encapsulation (TCP/UDP and RTP header info), destination information (receiving port and IP), and other assorted streaming information.
A standard RTSP Transport header
Above is a standard RTSP SETUP method from VLC. You can see the client specifying that the stream is sent "unicast" and the client port range to receive the streamed data. The streamed data is assumed to be encapsulated as UDP with an RTP header. What other streaming options can be sent? Let's have a look at the RFC for RTSP.
If you look in there, you'll see an option to specify the destination IP address and a warning that the server should first authenticate the user and then log any attempts before directing media traffic to an IP not identified as belonging to the client.
Always authenticate and log
Redirecting RTP streams for denial of service (DoS) is nothing new for streaming protocols like RTSP and SIP. However, it's been a long time since I've found a new streaming server that has this vulnerability. And initially this one didn't work either. That is until I noticed another option for the Transport header:
Rolling the dice, I changed my Transport header to multicast instead of unicast as the destination. However, I did not specify the destination address as an actual multicast address, but instead as a unicast destination. The resulting Transport header looked like this:
Change the destination
And success! We are flooding our packets to our victim (198.18.0.50) instead of back to our originating source (192.168.1.1):
I combined this flaw with the password hash leak vulnerability and built a DDoS flooder that would:
1. Connect to the camera
2. Create a new user
3. Use that new account to create multiple RTSP sessions
4. Create multiple RTSP/RTP streams to flood my victim
Using this proof of concept (PoC), I generated a 40 megabits/second flood from one camera, a 445x multiplier. This type of attack is not as common as a DNS or NTP reflection attack, but it is very effective for generating large amounts of data. RTSP does require a TCP session that would leak a booter’s IP address, which they might not want to share. However, only the camera owner would be capable of harvesting that detail, and not the intended victim, making attribution difficult. We're not sharing the details of how to gain administrative access to these cameras publicly right now, but we've already seen active scanning attempts on our honeypots for these cameras.