A recent story making the rounds in both the infosec and public press is the recent use of internet-connected security cameras as a base for DDOS attacks. They don't have a lot of CPU, but they're linux platforms that are easily hackable, never get updated and usually have good bandwidth available to them.
This shouldn't come as any surprise to folks who are in the security business, or those who do any kind of a product eval before they plug new gear into their network. I see security cameras on network assessments and penetration tests regularly. A simple NMAP -sV scan (to show service versions) will typically light up a security camera as:
PORT STATE SERVICE VERSION
The give-away is that Boa web server. For some reason, security camera vendors seem to have standardized on this as their web service. Or more likely, one vendor has, and they're selling the chipset to everyone else to put inside of their cases.
Let's take a look at that. The Boa project has an active website (www.boa.org), and version 0.94.14rc21 is listed as the latest development release, complete with signatures. Sounds great so far right? Except when we look at the code, it was posted Feb 2005 (yikes!). It looks like this project is no longer seeing active development (as of 11 years ago!). So even if the vendor supplies updates and you apply them, there's no fixing the web portal that faces the network - and so often the public internet.
A quick google shows that this version of the web server is subject to a command injection vulnerability, as described in CVE-2009-4496. Exploit-db has an example curl one-liner that demonstrates this: https://www.exploit-db.com/exploits/33504/ , vulndb has a larger write-up here: https://vuldb.com/?id.51542
Nessus has identified this remote code exec issue for years (plugin 47463).
Shodan identifies 936,736 of these servers on the public internet - because of course it's just too much trouble to VPN in to view the video footage on your ATMs or other physical assets
So a DDOS really is that simple. Just using a curl script, you can start a "ping -t" or "ping -t -l 1000" against your victim (I picked 1000 just to prevent any packet loss due to fragmentation prevention). With a few thousand camera devices, you have what the victim will perceive as a sophisticated DDOS attack. Your curl string to attack a test "188.8.131.52" ip address with default sized icmp echo requests would be:
The first few characters are the escape sequence: %1b%5d%32%3b
The string "ping -t 184.108.40.206" is represented in hex as: 70%69%6e%67%20%2d%74%20%31%2e%31%2e%31%2e%31
The string terminates with: %07%0a
Wireshark catches the icmp echo requests (replies are filtered out) - yes, this did work first time for me:
That aside, what folks are missing in all of this is that these cameras are usually connected on the inside, trusted network, right there next to the servers. Folks seem to find it too much trouble to make a DMZ for these things. So the majority of these cameras make dandy pivots inbound to the customer's servers and workstations - your command string isn't restricted to "ping", you can run anything you want on the box (that the web service has rights too). From the public internet, you could easily craft an inbound proxy or relay, giving you full access to the internal network - or at least long enough to establish a more "reliable" reverse shell or vpn solution. Or just use teamviewer or logmein if you have that kind of access, you're less likely to trigger an IPS if you use the same tools that the IT group uses!
The remediation for this? There are a number of things you can do, depending on your situation:
As always, preventing these problems before they occur is the easiest way to deal with them. You won't catch them all, but hopefully you'll catch things like this!
If you find one of these cameras on your network, please let us know in our comment section! Or better yet, if you have a network-connected security camera that has a different web server, please share the server and version in our comments!
Jul 8th 2016
2 years ago