Well, crap, you had the same thing when RedHat 7 was new. new RedHat 6 installs that went online were getting pwned in just a few minutes. The exploit scripts were open source even then.
As a person just starting to explore ip cameras, can anyone suggest any resources to tell if my cameras are already infected? If so, what to do? If they are only accessible locally, within the home's local intranet, it that safer?
Any tips on how to do this (for those of us not educated in monitoring traffic)?
I'm writing personal home automation stuff and will be wiring up a handful of IoT SmartPlugs.
With all this IoT stuff i'm starting to wonder if buying a 2nd router to isolate the IoT, or perhaps a "really good" router with features designed for monitoring IoT.
Regardless, this is a problem i won't be able to ignore. So any advice is appreciated :)
Bridge two network interfaces on a computer, then run Wireshark on the bridged interface. Connect one side of the bridge to the main network, the other side to the IoT network.
Or, if you have a non-switching hub, you can use that instead of a PC with two NICs.
>The safest thing to do for home routers is to kill UPNP
No no no!!!! This is going about it completely the wrong way and is setting us up for failure come IPv6 (if it's not already a thing for you).
We need half-decent security practices not a temporary workaround that requires user intervention.
In this case a randomly generated password printed somewhere inside the device's box or on the device itself is enough to stop Mirai and similar dumb botnets.
An internet that requires devices to be publicly exposed to the entire internet, and directly addressable at all times, is not an internet I want to participate in.
You WILL negotiate a firewall, before learning anything about the devices I use.
ESPECIALLY if I am prevented from knowing their internals, whether by willful disclosure or unlawful reverse engineering.
I wouldn't/don't mind better research/work into better permission systems for OS's/processes; allowing the user control over what gets exposed to incoming connections and what is allowed to make outgoing connections is fine and good.
NAT, and uPnP, is not that. In the case of uPnP: if uPnP was SOP, wouldn't the camera (needing to be "remotely accessible" because the Internet of Crap) just make the requisite uPnP calls, likely making everything accessible?
NAT, in particular, is terrible. Trying to explain to a normal user how to establish NAT port-forwarding for devices or applications is a UX nightmare. NAT, in particular, kills off entire classes of protocol design, necessitating hacking around NAT by routing traffic through untrustable third-party servers.
NAT is further not a firewall: one anything inside your NAT gets remotely exploited, and everything else is wide open. (And that's at best; depending on the protocol in use, you might not even need remote code execution.)
(And uPnP's support in my experience has been utterly pathetic.)
Of course, I'm being a little cheeky, but ah, my sentiment of digging a moat around a house with an unlocked door is an idea I'll always keep in my back pocket, and show no hesitation in applying a ridiculous solution to a ridiculous problem.
Obscurity and inscrutability certainly will never supplant the Objective Ideological Truth that "Security" tries to be, but it's often useful as a source of leverage when all other leverage would be denied to you.
You could never ever claim to endorse obscurity for its own sake during a daily stand-up or a conference call, because people woud rip you to shreds for any number of valid reasons, but when push comes to shove, and you find yourself on the losing side of someone else's moral hazard, being able to throw a smoke screen up, where a brick wall would be preferred, is sometimes all you can do.
Low end business gear is universally shit. My comcast business router is absolutely awful. I need to get around to putting it in bridge mode and putting a real router behind it. The best thing it could possibly be for me is a coax to ethernet paperweight.
Low end business hardware is just consumer hardware with "business" written on the box and a couple of strings changed on the web interface.
I won't even buy an AP unless it has a DD-WRT/OpenWRT/Tomato image. I've had way too much pain with whatever shit the vendor crapped into the box before they shoved it out the door.
I keep seeing DD-WRT/Tomato/OpenWRT coming up in these discussions; how about an option you could actually deploy to home or business customers and be proud of it.
> The best thing it could possibly be for me is a coax to ethernet paperweight.
This is great! Maybe we can repackage old Wi-Fi routers and sell them as connected IoT paperweights! Makes about as much sense as every other IoT device on the market.
> My home "router" doesn't even have fucking bridge mode.
Maybe you mean your modem? Bridging a router doesn't make much sense... since it's not a router then.
Although I suppose you could have one of those dreaded "combo" modem/router things ISP's peddle these days. There certainly should be a bridge option in that case, and you're rightfully mad if it doesn't!
I mean one of these dreaded combo modem/router thingies, hence the quotes. There is no bridge mode, and I cannot turn off NAT. It's also doubles as a completely fucked up DNS server which I have to override for resolv.conf.
I did this recently at home (saves money after owning it for a year, as it's "paid off" then in monthly modem rental fees), and although I have problems with the level of control my ISP has over the modem (there's no configurations or login, you activate it on their network and they control it fully), it's now just a "dumb modem" and does nothing else.
Then you knowingly bought a combo shitbox. There have always been quality consumer wireless access points, modems, and routers available, but you chose to buy the combo shitbox.
Mikrotiks are an amazing value! Usually they are way over spec'ed for their intended purpose as well, which means you're getting even more bang for your buck.
They have models for home users, businesses, all the way up to ISP "carrier grade" equipment.
They used to be difficult to configure (you needed to know quite a bit about networking and how Mikrotik's do things, since they originally targeted only WISP and more traditional ISP customers), but that's changed significantly in the past few years. They have 1-click setup wizards now, so even people with no networking experience can get up and running quickly, just like your run-of-the-mill Netgear router.
Also, you can run RouterOS (the OS on Mikrotiks/Routerboards) on x86 hardware, so you can build your own router if you have the need.
WebFig, GUI WinBox, and SSH/Telnet feature parity and a config I can export and read as text, fully featured boxes with gigabit for ~$50 USD, need I go on?
Even so, I'd setup my own router/firewall and handle the ISP supplied device as essentially untrusted. It won't be pretty, but its at least tolerable solution until you can work out a better setup.
not saying its the case for you, but it might be interesting to some:
some ISPs don't allow you to enable the bridge mode on the management website of the device. you need to logon to their website with your service account and either open an actual ticket or go through an automated process to "unlock" bridge-mode.
its kinda silly but understandable, as you need to have some understanding of networking for this but most people dont have any at all. and incorrectly configured bridge mode kills any chance of internet for consumers.
While you're correct that there are ways to prevent this kind of thing happening, how many end consumers will do it? I think it was a valid experiment, he got it out of the box and did a minimal setup to prevent his network from being compromised, but not the "IoT" device per-se, and then just waited on the bait to catch something.
I think they mean that he didn't take reasonable precautions to prevent it being hacked, but as you said that's because most users won't take those precautions either. The intention was for this to get hacked though.
This is why the appliance market - Dropcam in this case - is often safe from the DIY enthusiast market. Setting these up is one hurdle. After that's done there's any combination of: network maintenance, security patches, updates, hosting a local server, DNS, troubleshooting etc.
For some people, it's just worth $150 + 10/mo to not have something else to think about.
So I'm in the business of wheeling and dealing in these things.
It's common knowledge in the industry that all of these devices likely have government backdoors or (likely deliberate) critical security flaws at any moment.
Virtually all CCTV hardware comes from ruthless and unregulated Chinese markets where the goal is to obfuscate the price (and source) as much as possible, to prevent price discovery by the end user and allow 2-4x markups on the equipment by the integrator.
Usually these manufacturers will sell to separate companies for their name brand, off-brand, and offer custom branding to distributors.
Due to the obfuscstion of manufacturing source, and at the same time a desire to "stand out" amonst the rest, the industry is rife with knockoffs, third-shift products, stolen technology, unauthorized distribution, you name it.
As an example: Every single Hikvision camera on amazon.com is an illegal sale and void of any official support from Hikvision. Go ahead and try to call them with a serial number for a product you bought on amazon and see what happens. It doesn't matter that the company selling the product on amazon is also named Hikvision (its an imposter).
Point being, the surveillance camera market is so rife with corruption that you generally accept that everything is compromised.
But none of it matters, because as long as the features work and the equipment is reliable, you simply throw it all behind an isolated network and call it a day.
I don't understand how the bot net found his camera so instantly when he turned it on or installed it. Within moments/seconds, it was attempting to infiltrate a brand new device.
You might be too young to remember Blaster Worm. There was a time in 2003-2004 you couldnt install Windows XP/2000 when directly connected to the internet (no nat/firewall), you got infected (= reboot after 60 seconds) as soon as install process fired up RPC service.
I don't get it: how does the attacker initiate contact with a 192.168.0.0/16 address? Is part of the installation instructions "On your WAN router, DNAT your external address and a port to your internal address and telnet port."?
I work for an ISP. I fired up a capture one day out of curiosity and instantly saw thousands of packets per second destined for 23/TCP across our address space. There's a LOT of these compromised devices out there that are just constantly scanning the entire IPv4 address space.
Back when I had an ISDN connection, I'd see 5-10 attempts a day (and I would sometimes send emails to the abuse@ address for that IP range). Now I see 5-10 a second and it's pointless to try and stop them at the source.
I'm somewhat curious if all those attempts count against my data cap.
"Back when I had an ISDN connection, I'd see 5-10 attempts a day (and I would sometimes send emails to the abuse@ address for that IP range). Now I see 5-10 a second and it's pointless to try and stop them at the source."
There is nothing inherently wrong with port scanning and it should not, by default, be considered "abuse".
> I'm somewhat curious if all those attempts count against my data cap.
I don't see why they wouldn't. IP (which is really the layer ISPs should operate at) does not distinguish between packets that you have "requested" and unsolicited packets, being connectionless protocol and all.
You can have the same problem with any OS that you install that is connected to the Internet before the updates are applied (ie: getting a compromised computer in a a few minutes, being Windows or Linux)
Symantec Endpoint Protection has portscan detection & blocking, but this is a managed instance on a corporate laptop, so I don't have access to the logs to drill in to what was intercepted.
Having traffic from the router blocked was a PITA though!
And that's why I'd rather build my own security camera using an RPi and its infrared camera module. I can even make it weather-resistant by picking/3D-printing the correct enclosure.
It's like the old days of installing XP from a CD and then putting it online to get patches. You would have half a dozen viruses on the box before you finished connecting to Windows Update.
Take a look at Axis Secure Remote Access solution for a way to avoid port forwarding (with its issues) and still get remote access, basically no configuration at all except from actually initially adding the camera to your site.
Only works on Axis cameras though with Axis client software I should mention.
Take a look at Blue Iris (unfortunately Windows only). It supports almost every camera imaginable, and has the benefit that it runs on a single Windows server you can secure, while it pulls camera feeds directly from the cameras over your private network. You can still download a mobile app and connect securely to the video server to browse recordings or watch live feeds.
I much prefer this model, because then I don't have to trust all these terrible cameras; simply isolate them on a private wifi network that only your Blue Iris server can reach.
That's essentially using their servers as a middle-man. Which raises the question: why would one trust Axis to build servers that withstand attacks but not to build cameras that do the same?
It's still end-to-end encrypted though. Going through their servers it is in case peer-to-peer isn't possible to setup, otherwise it's a direct encrypted link between you and your camera (with client+server certificate validation) without any mediator servers.
Regarding servers vs cameras: To oversimplify; servers can have exponentially more capacity. Either how, in this case, the traffic is encrypted in each end so there's nothing to be done by "the middle man servers", they can't decrypt anything cause they don't possess the keys.
Also to have an external backup of the video feed.
Otherwise, if you get robbed, and they happen to steal your NAS, you've lost the main reason to have a security camera in the first place - to identify the perp.
I purchased a TP-LINK camera and didn't want to use their cloud, so I made it ftp images to a Raspberry Pi and then forward them to me via a Telegram Bot. I've been pondering getting OpenWRT on the camera and then running the bot directly on it; I'm not sure it's feasible.
People don't care. They don't think anybody else is going to be interested in watching their cameras, and it doesn't even cross their mind that a camera could be vulnerable to an exploit. They don't even know what an exploit is. Once they can see their camera from their phone, they don't care what else is happening.
https://github.com/jgamblin/Mirai-Source-Code/blob/6a5941be6...