Add DoS Exploits

[sol-vin]

Hi,

I am a security researcher who has been working with Xiongmai brand cameras, which use the same "Sofia" protocol.

I found a number of exploits relating to DoS issues with the actual protocol. I reported one but I am still working on reporting the others as I am not sure if they are related or the result of another issue.

You can read some better in-depth documentation on the exploits and protocol at http://0x42424242.in/xiongmai.

First, there is a REALLY juicy DoS revolving around the size integer in the command packets. It seems it casts a UInt32 to an Int32 and so values above 0x80000000 make the camera crash for around 120 seconds. This could either be an integer overflow or maybe they mishandled an error or something, unfortunately I haven't been able to get remote GDB working so it's anyone's guess.

This exploit is particularly awesome because it can be done unauthenticated, using the login command. Link to code for exploit

There are another two, which may be related to each other. One involves an issue surrounding nested types not being traversed properly. Some commands have a structure like

{
  "Name": "OPMonitor",
  "OPMonitor":  {
    "Action": "Claim",
    "Action1":  "Start",
    "Parameter":  {
      "Channel":  0,
      "CombinMode": "NONE",
      "StreamType": "Main",
      "TransMode":  "TCP"
    }
  },
  "SessionID":  "0x0000000007"
}

But if we replace one of the nests with a non nested type this blows everything up.

{
  "Name": "OPMonitor",
  "OPMonitor":  0
  },
  "SessionID":  "0x0000000007"
}

You can also crash the camera/dvr buy sending a message with just "" inside. Probably related but I can't check yet :(

[tothi]

read your blog, nice work, grat! i was always focusing on RCE. any chance to turn DoS to RCE?

[sol-vin]

Thanks! It's possible but I don't have the remote debugger working yet on my camera models. (I have yet to try your telnet exploit but it seems it should work, mine has that exact weird port open.)

I would imagine the size issue I mentioned might end up as an RCE, but obviously it might require some other way to get the code in the device (heap grooming or whatever, IDK), mostly because I'm pretty sure the program doesn't commit the message field to memory if the size field is huge like that. I'm pretty sure it crashes because a function that was supposed to take a UInt32 takes an Int32 instead and screws everything up, probably an unhandled error or something.

I just recently got all the parts to fix my work computer so I'll probably look into it a bit on the RCE. If you got some time, if you wouldn't mind trying my size exploit on one of your camera with the debugger detached and send me the results , I'd be eternally grateful. I'd recommend using the Login command for this as you don't even need to login. I really just want to know if it's a seg fault, mishandled error, or whatever.

Generally though, I don't look for RCE, but I have found a number of other exploits that might be of interest if these get patched. Most of the issues I found revolve around the camera giving out all information necessary to impersonate it, then using that to get the password from a connecting client. I'm not sure if it's as bad as my other exploit for VStarCam which did the exact same thing, but with the potential to do it over the built in DDNS system. I never tested anything on the external servers (trying not to go to jail lol), but I can tell by looking at the communications between the camera and the DDNS, it's not good. Luckily the Xiongmai/HiSilicon/Huawei devices don't give out the DDNS information (from what I can tell) without needing authentication first, although they are pretty shady themselves.