from SANS Internet Storm Center, InfoCON: green
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
23/tcp open telnet security DVR telnetd (many brands)
80/tcp open http Boa HTTPd 0.94.14rc21
1025/tcp open NFS-or-IIS?
9000/tcp open tcpwrapped
56575/tcp open unknown
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: http://ift.tt/29y3h4Z , vulndb has a larger write-up here: http://ift.tt/29EM3pv
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 "1.1.1.1" ip address with default sized icmp echo requests would be:
curl -kis http://ift.tt/29y3epT
The first few characters are the escape sequence: %1b%5d%32%3b
The string "ping -t 1.1.1.1" 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:
- Scan your network, look for vulnerable services like this. NMAP will do the job with some legwork, tools like Nessus or OpenVAS will make it easier and smack you with the proverbial "LOOK HERE" two-by-four.
- Put vulnerable things that can't be fixed and can't easily be replaced (like these cameras) into a DMZ or a "jail" VLAN, and don't give that subnet access to anything on the inside network.
- Restrict access to these cameras to VPN or internal access only (you can reach them, they can't reach you).
- If you have a vendor monitoring your cameras, do the VPN thing with them also. If you MUST give them direct access, only allow their IP or subnet. (But also start looking for a different security monitoring vendor if you have to do this)
- Most important of all, try to head this stuff off at the pass. Scan new gear during the evaluation phase. If it doesn't pass your assessment for some reason, phrase your report in business terms, outlining the real risks to the business. You can't get buy-in from the folks who make these decisions by saying "No, but it's too complicated for me to explain it to you, just No.".
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!
===============
Rob VandenBrink
Compugen
