As KrebsOnSecurity observed over the weekend, the source code that powers the “Internet of Things” (IoT) botnet responsible for launching the historically large distributed denial-of-service (DDoS) attack against KrebsOnSecurity last month has been publicly released. Here’s a look at which devices are being targeted by this malware.
The malware, dubbed “Mirai,” spreads to vulnerable devices by continuously scanning the Internet for IoT systems protected by factory default usernames and passwords. Many readers have asked for more information about which devices and hardware makers were being targeted. As it happens, this is fairly easy to tell just from looking at the list of usernames and passwords included in the Mirai source code.
In all, there are 68 username and password pairs in the botnet source code. However, many of those are generic and used by dozens of products, including routers, security cameras, printers and digital video recorder (DVRs).
I examined the less generic credential pairs and tried to match each with a IoT device maker and device type. As we can see from the spreadsheet above (also available in CSV and PDFformats), most of the devices are network-based cameras, with a handful of Internet routers, DVRs and even printers sprinkled in.
I don’t claim to have special knowledge of each match, and welcome corrections if any of these are in error. Mainly, I turned to Google to determine which hardware makers used which credential pairs, but in some cases this wasn’t obvious or easy.
Which is part of the problem, says Will Dormann, senior vulnerability analyst at the CERT Coordination Center (CERT/CC).
“Even when users are interested in and looking for this information, the vendor doesn’t always make it easy,” Dormann said.
Dormann said instead of hard-coding credentials or setting default usernames and passwords that many users will never change, hardware makers should require users to pick a strong password when setting up the device.
Indeed, according to this post from video surveillance forum IPVM, several IoT device makers — including Hikvision, Samsung, and Panasonic — have begun to require unique passwords by default, with most forcing a mix of upper and lowercase letters, numbers, and special characters.
“As long as the password can’t be reversed — for example, an algorithm based off of a discoverable tidbit of information — that would be a reasonable level of security.” Dormann said.
Some readers have asked how these various IoT devices could be exposed if users have configured them to operate behind wired or wireless routers. After all, these readers note, most consumer routers assign each device inside the user’s home network so-called Network Address Translation (NAT) addresses that cannot be directly reached from the Internet.
But as several readers already commented in my previous story on the Mirai source code leak, many IoT devices will use a technology called Universal Plug and Play (UPnP) that will automatically open specific virtual portholes or “ports,” essentially poking a hole in the router’s shield for that device that allows it to be communicated with from the wider Internet. Anyone looking for an easy way to tell whether any of network ports may be open and listening for incoming external connections could do worse than to run Steve Gibson‘s “Shields Up” UPnP exposure test.
HELP! I NEVER CHANGED THE DEFAULT PASSWORD!
Regardless of whether your device is listed above, if you own a wired or wireless router, IP camera or other device that has a Web interface and you haven’t yet changed the factory default credentials, your system may already be part of an IoT botnet. Unfortunately, there is no simple way to tell one way or the other whether it has been compromised.
However, the solution to eliminating and preventing infections from this malware isn’t super difficult. Mirai is loaded into memory, which means it gets wiped once the infected device is disconnected from its power source.
But as I noted in Saturday’s story, there is so much constant scanning going on for vulnerable systems that IoT devices with default credentials can be re-infected within minutes of a reboot. Only changing the default password protects them from rapidly being reinfected on reboot.
My advice for those running devices with the default credentials? First off, make sure you know how to access the device’s administration panel. If you’re unsure how to reach the administration panel, a quick search online for the make and model of your device should reveal an address and default credential pair that can be typed or pasted into a Web browser.
If possible, reset the device to the factory-default settings. This should ensure that if any malware has been uploaded to the device that it will be wiped permanently. Most devices have a small, recessed button that needs to be pressed and held down for a several seconds while powered on to reset the thing back to the factory default settings.
When the device comes back online, quickly fire up a Web browser, navigate to the administration panel, enter the default credentials, and then change the default password to something stronger and more memorable. I hope it goes without saying that any passwords remotely resembling the default passwords noted in the image above are horrible passwords. Here’s some advice on picking better ones.
Unfortunately, many of these devices also require periodic software or “firmware” updates to fix previously unknown security vulnerabilities that the vendor discovers or that are reported to the hardware maker post-production. However, relatively few hardware makers do a good job of making this process simple and easy for users, let alone alerting customers to the availability of firmware updates.
“When it comes to software updates, automatic updates are good,” Dormann said. “Simple updates that notify the user and require intervention are okay. Updates that require the user to dig around to find and install manually are next to worthless. Devices that don’t have updates at all are completely worthless. And that can be applied to traditional computing as well. It’s just that with IoT, you likely have even-less-technical users at the helm.”
Only after fixing any problems related to default credentials should readers consider checking for firmware updates. Some hardware makers include the ability to check for updates through a Web-based administration panel (like the one used to change the device’s default password), while others may only allow firmware updates manually via downloads from the manufacturer’s site.
Firmware updates can be tricky to install, because if you fail follow the manufacturer’s instructions to the letter you may end up with little more than an oversized paperweight. So if you decide to go ahead with any firmware updates, please do so carefully and deliberately.
BUT WAIT, THERE’S MORE
Several readers have pointed out that while advising IoT users to change the password via the device’s Web interface is a nice security precaution, it may or may not address the fundamental threat. That’s because Mirai spreads via communications services called “telnet” and “SSH,” which are command-line, text-based interfaces that are typically accessed via a command prompt (e.g., in Microsoft Windows, a user could click Start, and in the search box type “cmd.exe” to launch a command prompt, and then type “telnet” <IP address> to reach a username and password prompt at the target host).
The trouble is, even if one changes the password on the device’s Web interface, the same default credentials may still allow remote users to log in to the device using telnet and/or SSH.
Brian Karas, a business analyst with IPVM — a subscription-based news, testing and training site for the video surveillance industry — said in his experience often times IP camera users can change whatever settings they want in the device’s Web interface, but that’s no guarantee the changes will affect how the device can be accessed via Telnet or SSH.
“The problem is there’s no hard and fast rule,” Karas said. “What often happens is Telnet and SSH are an operating system-level login, and the [Web interface] tends to be more of an application level login. Sometimes changing a password on one changes the password on the other, but more often the Web [interface] is completely different, and changing the password there may not change the underlying password” needed to access the device remotely via SSH and Telnet, he said.
Case in point: In February 2016 I published This is Why People Fear the Internet of Things, which examined a whole slew of IP cameras sold by Chinese Web camera giant Foscam that — by default — included a feature which would quietly phone home to a vast peer-to-peer (P2P) network run by the company. As I explained in that piece, while the Web interface for those P2P cameras included a setting allowing users to disable the P2P traffic, disabling that option didn’t actually do anything to stop the device from seeking out other Foscam P2P cameras online.
Interestingly, Karas said he’s been pressing Dahua — whose IoT devices are heavily represented in the above default password list — to tell him how many of their devices are vulnerable. Karas said Dahua told him that although the company’s newest models didn’t have this problem, the company was preparing to launch a trade-in program for customers with default-insecure devices.
“They didn’t give me a straight answer on this one, but that that tells me is they have a whole bunch of devices that may not be firmware updatable, which means they can’t make those devices more secure without swapping out the underlying hardware.”
Update, 8:30 p.m. ET: Added final section with the sobering caveat that all of this hassle in changing the default passwords and updating the firmware may not actually solve the problem for many (if not all) of the affected devices.
The link to the “ShieldsUP!” test leads to an example result page not the test itself, just so you know.
Thomas, on Steve’s page, click on the represented image, it will open/download the .exe file for your usage. 🙂
Not so. Click on one of the 3 sample screen shots, and that will trigger the download. You have to run the .exe file as “administrator” in order for it to work properly.
The correct Gibson test is here, which will test the vulnerability of whatever is facing the internet (like your router). The link Brian provided is to a downloadable exe file that only test the Windows machine which runs it. The real Shields Up! page is here:
https://www.grc.com/shieldsup
I’m not very knowledgeable in hardware/firmware, but can someone explain why these IoT devices don’t force the user to set a password manually? Or generate one for you and maybe store the password in some way to be later accessed by the client/company?
Because it would cost more to add the feature and to provide customers with technical support when they forget the password. Vendors want things to work out of the box. It took many years before router suppliers provided unique passwords, because simple was easier.
Laziness, cheapness, etc. The market doesn’t reward security, it rewards price and speed.
It takes time and effort to write and fully test code that forces you to change your username and/or password on boot. Time that could easily be spent shipping the product and bringing in revenue.
Storing the passwords unhashed (so they can later be retrieved in plain-text) is a bad, bad thing.
Forcing users to change them… well, this will just annoy the users and slow sales. Users [seems to] hate security or they just can’t understand it and the risks involved.
One better approach would be to generate them dynamically during the manufacturing process and print them on a label attached to the devices, but that adds to the cost of the devices. And these are [usually] kind of cheap devices.
That’s how my Wi-Fi router came from the factory. It had a sticker with a user name and password on it that I immediately changed upon installation.
Daniil, provisioning (the process of taking into action) is very mundane, expensive and time-consuming process. It can be more or less controlled for large installations in industrial or office environment for B2B cases. But when it comes to personal / home level, things get significantly worse – simple people perceive electronics more as single goods (irons, radios, lamps) which does not need any installation. There is existing design theme about it, perfectly described in book with self-explaining title “Don’t make me think!”. Consumerism is legalized way to excuse masses from doing wrong.
Excellent follow up article Brian! I hope the world appreciates all your hard work.
Brian, I think this topic should be your new area of expertise. Skimmers and IOT. Good stuff. Thanks
You don’t have to quickly reset the admin creds, just disconnect the wan port, take your time and do it right and then reconnect (if we’re talking router here).
This. Secure your device/computer/dongle before exposing it.
Many people using these devices don’t realize the risk and are unlikely to disconnect or otherwise take action. Cameras were the bulk of the devices from Krebs’ data, people put these online to be able to remote view something, I expect. If it is hackable, so what? User doesn’t care if people can look at his garage/living room. Being used to attack websites isn’t something a typical user would know about, and possibly would not care.
Excellent and useful information.
I would suggest using an ID different from the default as another layer of protection for routers (few will bother changing the default ID). Turning off the ability of a router to return a “ping” from outside (often represented as “wping=off”) is more important. Most attackers first use a “wping” to see if a router exists at a given address. If the “wping” is not acknowledged, the attacker will not know the router is there.
Steve Gibson’s “Shields Up”, which you suggested, will tell if your router has “wping” active.
The list of manufacturers and hardware types was quite useful, and your suggestions to be sure to change all default passwords will take those who heed your advice out of the “low hanging fruit” category.
Those who run “Shields Up” may have the minds open to many vulnerabilities on their own equipment they had never considered. I ran it in January and got another router since I could not turn off certain ports.
Thanks again for your excellent work in all aspects! Each of us must make sure we are not a part of the problem by implementing some simple security measures like unique passwords.
I wonder how much work it would take for the manufacturer to generate a different password per device & include that with the device ?
I guess they would just need something on the production line to track what password was setup
The good WiFi APs/routers/modems/repeaters do this these days.
The bigger problem is everything else.
Writing the manuals to explain the instructions. Getting it translated into the extra languages supported by the manufacturer.
And of course, dealing with confused/upset users.
They’d also have to ensure that firmware updates are still able to reset the device to the per-device default password.
And then they need a policy for what happens when the sticker is scratched off/worn-out and the user loses the per-device password. Is it a brick? Or do they keep a database?
They “best” version I’ve seen is the one where you’re encouraged to enroll the device into a web management service (Apple’s iTunes, Google Accounts, Microsoft Accounts, BlackBerry ID) which enables you to reset your device’s password. But this requires someone to maintain and secure a very valuable (target rich) service and for people to trust it. And realistically, the average user doesn’t register their printer/camera upon purchase, so they’re unlikely to register their thermostat/dishwasher.
In additional to the measures suggested here, another thing users can do to help mitigate exposure is frequently change your public IP address. This can usually be accomplished by spoofing the MAC address of the router connected to your ISP.
If you use Apple hardware you cannot do this but Netgear, D Link and most others allow this to be done . . .
The only issue with this approach is that the system will just get re-scanned, and if vulnerable, will simply be compromised again, or it will just reach out to the C2 and continue operating as part of the botnet from the new IP address.
Interesting list. I’m a little surprised to see Xerox printers but then again………….
As a car owner, it’s my responsibility to get it registered and do maintenance or have maintenance done on it if I can’t do it myself. When I have a mechanic work on it (because my apartment lease is typical and disallows doing any car maintenance), it is my responsibility to understand (learn) enough of how a car functions to understand what is going on with it trouble-wise and so understand the mechanic when he makes repairs for me. This is what we’ve become too mentally lazy to do in most areas of life. I don’t have to be a mechanic to understand broadly what a cars major components are & how they function and interact.
In what way is that any different from the responsibility to take care of one’s IoT devices? It isn’t. Yet, if one must go to the website to download a firmware upgrade (think, “get an oil change”), that becomes too much to bother with. It’s a case of, “Once you do it, you discover how it really isn’t a big deal.” Automatic updates can be very disruptive because suddenly something stops working as expected and there is little or no indication why. Part of the key to dealing with this is being aware that automatic updates may be happening. That’s just part of learning how one’s IoT device (car) works. I don’t use automatic updates, but instead check periodically the same as I check my tires regularly. I don’t enjoy checking for updates; it’s just a responsibility so I get it done every so often. It’s like pulling weeds.
I work in IT, which is another reason I don’t like taking care of my computer at home, like pulling weeds. We in IT where I work have some interaction with the public, though we are not supposed to. Our IT department is not in public services. Still, our CSR’s will sic customers on us. (There’s real trouble when they give our phone numbers to the public and we get calls asking for help with home computers.) We have public WiFi available and the CRS’s are supposed to help people with that.
In my years, I’ve seen various people in the workplace who refuse–deliberately refuse–to learn how to use their work tools, that is, their computers. They don’t need to dismantle a hard drive to understand that that the long-term storage on the hard drive is not the same as the machine’s running memory (RAM). Here are a couple examples. These have been who call us and cannot communicate for a service request because they refuse (again, deliberately) to learn that copying files within a machine between disks/usb/optical is NOT up-/down-loading. Up and down loading are pushing or pulling across a network. So, when someone says they can’t download a file, it’s 100 questions just to find out that what they mean is that they aren’t permitted to run a software installation from a CD/DVD. If you apologize that you didn’t understand the initial complaint because you thought they were just copying a file over the network, you get derided and scolded that what it’s called doesn’t matter. You’ll get the same reaction to, “Oh, do you mean the ?” So much for communication as a job requirement! These are not hard concepts! In 2008, I dealt with a career admin assistant who had 10 years of experience in her then-current position, who never used folders for her documents on the computer. She couldn’t understand the hierarchical tree structure of folders containing files/documents and folders. When migrating her data during a hardware change, she asked me, politely, to create folders and organize her hundreds of files into them because they’re on the computer and computers were IT’s job. She was only in her early 40’s, so don’t tell me it’s a generational thing. The examples are to demonstrate that the real problem is people refusing their responsibility to learn things.
That reminds me, saying it’s a generational thing misses the point I’m making while making excuses. I’ll deal with people’s ability to learn on an individual basis.
In dealing with the public, I’ve had a few customers THROW their devices at me because they’re having trouble with our Wi-Fi. Most often it’s malware on someone’s laptop interfering with their connection. Customers having trouble on our Wi-Fi are an extreme minority of our customers. In reality, part of the trouble is often Apple’s, Microsoft’s, & Google’s insistence on violating the security of private networks. Figuring out what Apple is doing to maintain the “it just works” deception takes some effort. Ultimately, our public users believe it is our responsibility to run their devices for them AND believe they have no responsibility to learn how to use their own devices. Some of this is trained in by a phenomenon from Apple which caters to the most infantile least common intelligence (removing as much responsibility to learn as possible, even working against it). That design has been emulated by others. Have you seen the videos of babies using an iPad? Remember Will.I.Am’s gushing over the iPad that it was a device with no instruction manual that everyone knew how to use? (With the advent of newer gestures, that’s no longer true. “Oh, I double tap the home button to get this function? Swipe with how many fingers, from which direction, and in the middle or on edge?” Like DOS commands, there’s no intuitive way to know these.)
Mr. Krebs’ article has pointed out that some interfaces for IoT devices don’t make the most crucial settings readily available, such as burying the password change or not offering updates within the interface. Those become irrelevant with a clientele that doesn’t bother looking very far into their own devices in the first place. Ownership involves responsibility, which most often involves learning. The problem with IoT devices not having their default passwords changed starts with the buyers, regardless of how many screens down the web interface that change is made. Manufacturers could do better to help their customers by putting that up front in a first use situation (or reset). If a home router or camera would not function until a password is set from within the LAN, prohibiting the top 25 hackable passwords, then the manufacturers face a backlash from those who are too lazy to learn the task, but not not too lazy to get on YELP and scream about inconvenience using the enormous bandwidth required to type via speech-to-text (it sends uncompressed audio over the web). I hope you see the point.
That reminds me, I’m a few miles overdue for an oil change.
Sorry for the bad edits. There’s one near the end. It should be “…and scream about the inconvenience while using the enormous bandwidth required to…”
While I don’t know that I disagree with your ideal world….
As a consumer, if I buy a knife, a pan, or a tea kettle (actually, I need to buy one of these), I expect it to just work. If there’s a recall, I expect it to make my local news outlet. Sure there is an instruction manual but I generally have no interest in reading it. Usually, the manual has technical specifications (don’t heat to 600F, don’t scrub with sharp bristles, don’t use acid to clean), but usually they’re standard disclaimers and not worth reading.
The cheese grater might be dangerous (it is), but, operation is fairly apparent.
When I bought a model rocket, I didn’t have to register it. There were instructions (don’t launch if from a backyard/near trees/powerlines).
I’ve never owned a lawn mower, but you don’t have to register one.
Bicycles don’t require registration in most regions, although you can certainly get injured/cause injuries while using them.
Registration is a very messy area. Vendors love registries when it enables them to market future products. But customers don’t like the hassle, especially when they’re no apparent value for them.
Consider something simpler: your fruits, vegetables, and meats. They can kill you. Typically because they’re carrying E-coli or salmonella. We don’t require customers to register their fruit/vegetable/meat purchases, and we allow them to pay with cash. But we do require the vendors and merchants/resellers to track shipments. So when a “defective” batch (watermelon or otherwise) is discovered, the FDA or someone can issue a recall + notice.
Note that if I buy tomatoes and they go bad (because I didn’t eat them soon enough), the producer is unlikely to let me trade for a replacement.
The vendors of IoT devices (and cell phones for that matter) mostly treat them like vegetables, once they’re sold, they don’t see any financial reason to continue investing in them. The consumer can come back and buy a newer tomato.
Heck, Verizon is trying to get out of investing in its POTS (copper) lines….
timeless,
Change the food “registration” to “inspection”, ands food is inspected. It’s also subject to recall by sellers. Local health department inspectors and USDA inspectors have food safety regulations. There are forced recalls and business temporary shutdowns impacting the food industry and opened food servers (restaurants and fast food).
Right, that’s sort of my point.
I was responding to a model that required the consumer to deal w/ the problem:
Mike wrote:
> As a car owner, it’s my responsibility to get it registered …
Food is managed by overseers of the suppliers, not the consumer.
FWIW, there are “inspections” of most devices, but they’re typically for radio emissions aspects. Emissions are simple: devices aren’t allowed to emit outside certain bands and must tolerate interference. This doesn’t require one to see the source code for a device, just to run it through its paces for an extended period to prove its general behaviors (and there’s a threat of recall if it is later found to emit in violation under other conditions).
The problem with detailed inspection is that digital devices aren’t like foods. They take arbitrary channeled inputs and produce arbitrary channeled outputs. They can be stateful, stateless, or intentionally random.
Take the problem associated with this article. You can’t just ask “does a switch properly allow TCP/IP traffic to flow?” to determine if it’s “good” per the definition people want here. Well, for a truly unmanaged switch, “maybe”. But say you replace “switch” with “router”.
The first question is “how to test” a system in an automated manner.
There’s absolutely no way to usefully test arbitrary different user interfaces (each router has one).
Worse, consider that switch. What if it has a bug where a certain packet causes it to crash:
Patch Cisco ASA ASAP: DNS, DHCPv6, UDP packets will crash them [1]
You can’t usefully test all possible packets.
The best approach would be a code audit. But code is proprietary. Even food isn’t required to include complete ingredient lists (see “spices”/”flavors”, “colors” and “preservatives”).
[1] http://www.theregister.co.uk/2015/10/23/cisco_asa_patches/
When I buy a steak from the market, I’m expected to understand (as a matter of common sense) that it needs to be cooked. That if I were to eat it raw, I would very likely get sick. I am also expected to refuse rotted meat.
When I buy a tea kettle, it is generally expected that I would have the sense to not actually buy it if it has rust holes in the bottom.
I’m generally expected to maintain proper air pressure in my bicycle tires. If the tires on that bicycle are slashed out of the box, then I am taking it back to the store and if that just isn’t an option then I am expected to put new tires on it.
I see nothing unreasonable about these expectations. This is not only what should be seen as common sense but is also part of what gives us a civilized human culture.
As a cyclist, and occasional driver, and as a pedestrian…
1. Cyclists (especially occasional cyclists), people don’t maintain the air in their tires.
2. Car drivers don’t keep their headlights, tail lights, brake lights, or turn signals in working order
We do have laws wrt cars being in “good working order”, but they aren’t enforced.
Most places don’t have laws wrt bicycle operation, some have laws about headlights/taillights/bells/reflectors, but they’re also not particularly enforced (and I haven’t heard of any about tire inflation).
As a home-owner, occasional cook, and occasional guest:
People aren’t even particularly careful about whether their pots are rusted, their tiles are slightly broken, etc.
“Home inspections” generally exist, but the rules behind them tend to be very strange (they’re only supposed to find visual defects, and they generally carry little-to-no liability to the inspector).
Laws are hard to write (the people who write them tend to really not understand what they’re trying to regulate — thus garbage in->garbage out) and hard to enforce. They’re especially hard to do at the consumer level. They’re slightly better at the corporate level (as long as the companies don’t play shell/country games).
Another good article Brian.
If you notice most of those manufactures build their products in mainland China where a lot of ongoing cyber-attacks originate from, doesn’t that make you wonder?
If IOT ever gets properly regulated, default passwords are the first things which should go. Make every device get a unique password by default and put it on a sticker on the device.
First! 😉
Now on topic:
Root/dreambox is used for not alone dreambox sat./cable receivers but also for VU+ and many if not all other Enigma and Enigma2 linux OS based sat receivers. It is “baked” into the images that run on it.
It’s in openPli, Blackhole, etc.
This should be a ‘sticky’ warning on the manufacture supported forums.
The malware abuses root passwords hardcoded by device producers for undocumented telnet service. You should not confuse it with default user credentials for web interface. Changing the default password in web interface does not affect the hidden root telnet password at all. In order to prevent further infections you should instead telnet to your device using one of these passwords, and then change OS root pass using passwd. Storing it persistantly after reboot may not be simple for all devices.
For example, some routers use credentials stored on config files for their web portal access and common passswd file for telnet and ssh. SomeIoThings just let you telnet from Wan interface making more dificult for a normal user to change passwords.
I like this Gibson guy. Still living in the 90s (no sarcasm).
The bottom of https://www.grc.com/default.htm just screams “It’s the 90s again! Live with it or leave!”
Heh. Steve Gibson’s a guy who’s fundamentally sound at the kernel layer, so to speak, but ends up being kooky at the UI layer. He’s got his heart in the right place, but his id takes that, adds a serving of self-righteousness as well as a lack of insight into his own shortcomings, and punts it out as an insufferable man who knows some things, but tries to come off as knowing more than he really does.
The Register.co.uk has had some things to say about him. So has the VMyths site. And Attrition.org’s page is pretty harsh:
http://attrition.org/errata/charlatan/steve_gibson/
Gibson’s done good with his freeware as well as the Shields Up site for beginners/untrained users, but unfortunately he’s also overreached in too many things he’s done. This doesn’t impugn the Shields Up site at all (although I’ve long since switched to using other tools for those kinds of results), but it does mean that people should be careful about separating the solid work he’s put out from the more crank-level stuff he’s done.
Wow these guys are on their game. Going after streaming video products like those cameras is a fantastic spot to attack from. Those axis ones are capable of HD video output. So they could take over the firmware, or just point a 10-15mbps video stream at you instead. Streaming/IP video products tend to sit on fat pipes to carry out their tasks and are perfect as they usually have weak user/pass for whoever the people managing them or setting them up. Coming from an IPTV background, I’m not shocked! Would love to chat about what kind of capabilities those weak and often insecure systems would hit you with!
Since now, it has only been done at telnet level, via custom-compiled apps.
But, as you pointed out, there are still some “goodies”… I doubt you can force a video stream to a point, but you can force them to try to connect to an IP/service like they would to a NAS & try to upload [for example].
If i have remote access to your sat reciever i can not only watch/stream/record and zap to any channel, i can also “share” your smartcard.
I could potentially collect a few different providers (CAID’s) on several sat boxes (with say sky Uk, Italy, germany) and reshare your providers card to other people for say 10 bucks a month.
So they could all watch all channels of all those providers.
If i was a real no-gooder i would even use your box as central server, so you would basically host my payed for cardshare service. And if anybody finds out, you’re screwed, specially since the “peers” mostly get a ‘free pass to start’…
Just google cardshare.
>This cardsharing happens all over the world, on both share (i share my card with you, you with me) and payed share (you pay me 10 bucks, you get to watch, well about every channel you can receive) level.
This has grown due to the copyright restrictions made by copyrighttrolls/the copyright lobby.
Since dreambox, (in EU it was for years no 1 selling sat box) VU+ (now top selling box) and all modern linux (enigma2 mostly) use that same password, both in factory OS Image (nobody uses that) and all other images like OpenPLI, blackhole, OpenViX and many more use it, i say this is a pretty big one.
my 2 cents
Trust me, you can send unwanted video at anyone. I used to do it occasionally for work and testing purposes while at home. I’d forward something like port 9999 UDP from my firewall into my PC and tune it with something like VLC. udp://:9999 to open a listening socket. Then from work, fire off a stream to my home IP on port 9999. Guess what happens when you send more bits than your cable modem supports? You can’t do anything, you DOS’d yourself. In that case I would have to call the office, have someone either physically unplug it or log in and turn off the stream. IP cameras, streaming video solutions or just unix boxes with netcat. It’s the old school 1:1 attack, not an amplification of any kind but it’s more than you can deal with and they are certainly on fat pipes.
As far as securing your IoT device is concerned, I’d suggest you unplug it from the Internet before you reset it to factory defaults and change the password. You shouldn’t have to hurry up while reconfiguring it. Once you’re logged in, you could also take a look around and disable features (or is it bugs these days?) you don’t need. Then you can plug it in to the Net again and be, well, reasonably safe.
+1
Actually, some of those DAHUA passwords affect more than just DVRS -they also affect NVRs (recorders for IP Cameras), HCVR (Hybrid / Analog HD DVRs), VDPs (Video Door Phones)
“vizxv” is a fixed password (can only be changed via firmware modification)
“7ujMko0admin” is a dynamic password and it’s based on admin user’s password; thus, the devices affected by this “flaw” are those with default credentials used.
“root/hi3518”: if i remember well, this is a password for [most of] devices based on HiSilicon’s 3518
Please also add “admin/7ujMko0admin” combo to that list.
Also, newer devices have the telnet service disabled by default, but can be enabled via an URL command.
Would be also interesting to find out if all the manufacturers involved are still available. And how many have released the source codes under GPL.
So how does liability play into this?
If my IoT device assists in bringing down a high value website because it was hacked am I liable in the US?
Would it be similar to someone uninvited drowning in my swimming pool?
Perhaps this answers my question as a maybe…
If it was a child using the IoT device and it was an Attractive Nuisance. It would be interesting to find out more about this from a lawyer with experience in this tort law.
https://en.wikipedia.org/wiki/Attractive_nuisance_doctrine
That’s why you never leave default passwords on Internet enabled Devices…. Easy job for the malware creators and easy money, so take the extra time to write down a secure password.
I work in the physical security industry. It’s not just clueless end users who don’t know how to disable UPnP–it’s also clueless contractors forwarding ports because “the customer wants remote access” and their networking knowledge stops at basic SOHO router config. And now they have a rooted Chinese DVR sitting on their private network.
Scary stuff.
I’m more interested in the 2 main parts you left out Brian:
1) How did they scan\find\login to these devices in the first place? Is it just big sweep across swathes of public IP’s using http trying every conceivable login.html page until they get a response? How did they know which port? Or Did they use a search tool like shodan to find these devices first? Do these devices leak something out that allows them to be identified\fingerprinted?
2) Did they collect Ip’s of infectable devices first (how?), and then launch an attack across these IP’s using the assumed method (http and the usual ports etc. and credentials)? Or did they simply sweep all these IP’s AND try all the ports AND the login combinations until they were in? (in one step)
I think you’ll find these questions at least partially addressed in the update I just added to the end of the piece. Turns out, changing the default credentials in the web interface — while still a good security precaution — may not fix the underlying problem.
Brian, something is not right.
“They didn’t give me a straight answer on this one, but that that tells me is they have a whole bunch of devices that may not be firmware updatable, which means they can’t make those devices more secure without swapping out the underlying hardware.”
I think 90% of their older firmware(s) can be patched. The hardware has nothing to do with the Linux-based OS, unless there is a big sale pitch around.
We’ve been developing patches with customized “root” passwords for DAHUA devices for quite a time and, as far as it goes, it well applies to devices more than 5-6 years old.
We’ve also developed patched to disable, at OS level, the “telnet” feature.
I think it’s something like “they do not want to” not “they can’t”. And maybe, just maybe, it’s a “state-wide” “don’t want to”.
You’re getting into companies that have never really been forced to think about legacy support for what they release. Lots of these network gear, IP camera, and similar companies have long had a model of release new features and new models as priority. They need you to want ot buy new, they can’t afford infrastructure (people and process) to look for issues or even validate what people are finding or saying, even if they can fix the issue in the latest product/release and QA it effectively, there has likely never been resources to go back and fix it across all models. Consumer grade is a very different model than enterprise and cost reflects it. Sure, the enterprise product is really expensive to start with, it also comes with yearly maintenance and both of those costs afford that company to spend time on the product, to make sure you can upgrade to the latest firmware/software and to deal with security. Flip that to the cheap brand where you’re under a few hundred dollars per device. By the time you bought it they were already working on the new models and are likely only dealing with absolulte PR catastrophes affecting brand name or brand loyalty. There’s no time/money or resources to look at, fix or test fixes with those margins and that kind of focus. It’s a shift in the industry, it should happen but most of us have been involved enough with these companies directly or as a customer that we know it’s not going to. Build it cheap, add features fast, they’ll buy new stuff has long been the motto for most providing these and it’s going to be us voting with our wallets on best practices that shifts that. Unfortunately, I don’t think most of those companies have realized that or they have but haven’t seen a profit shift because of it yet. It won’t change until their profits slip and they can see it is directly tied to patching/security. It’s starting but a long long way to go.
Well, some devices allow users to turn on/off any remote access on the WAN/LAN interface, the WAN being the important one here. If that’s not possible then a user who’s lucky enough to have firewall capabilities built-in into their device would have to block telnet/SSH traffic coming in on the WAN interface. My message to an average user: Good luck!
You might want too look here at the 400 node live scanner: intel.malwaretech.com/mirai.html
Just came by on twitter, https://twitter.com/MalwareTechBlog/status/782970159594168320
I would have to test to be sure but changing your password on at least most enigma sat boxes should change the password for tellnet and FTP.
If you was to count all sat boxes dreambox, VU+ and others have sold, it is in the 9 figure range..
If i can help with sat box testing let me know.
It’s important to note that you can disconnect routers from the internet by literally unplugging the connection to the internet and still retain access to the device through the local network, meaning that you can reboot it and change credentials before going online. In fact, you can do that for all your IoT devices, configuring them on a local network that’s not connected to the Internet at all before deploying them on a live network.
So, how do you change the system level passwords, eg re telnet, ssh?
It totally depends on the device. For some (as noted), the user password is the root password, for others, there’s an admin page just for such things, for others you might have the ability to run shell commands, for others you might need to connect to the shell as admin and change them directly.
If you’re really unlucky, the password isn’t changeable — I’m not sure if any of the devices here are that bad, but it wouldn’t shock me.
Also, you might be able to disable telnet+ssh+ftp+whatever via an admin/services page, and that /might/ be good enough too.
“there is so much constant scanning going on for vulnerable systems”; third para after HELP! …
It seems to me that this activity is not appreciated by some respondants.
Watching packets coming from the raw Internet show that traffic directed to one’s IP address on port 23 (telnet) is constantly dribbling in from all over the world; mostly from countries that don’t aggressively pursue the bad guys.
Steve Gibson’s writings about 3 dumb routers may be a good starting point for distancing IOT devices from direct surveillance & DDOS participation.
For modestly tech-savvy users, free Sophos UTM or pfSense offer vastly superior abilities to block unwanted traffic and/or to pass only necessary ports.
Articles from the likes of Bruce Schneier are aiming the resonsibilities away from end users and toward manufacturers and to fixing Inet design weaknesses. For now, though, end users need a lot of help.
Thanks, Brian, for your efforts toward improving experiences on the Inet and beyond.
In the case of routers and firewalls, the simplest way of protecting them (well, a good start at least) is to ensure that admin login is possible only from the local side (LAN)… which should be the default anyway.
Unfortunately this doesn’t help other IoT devices.
most of the problem with this IOT is that they may have a backdoor root username and password. I read that somewhere, maybe a previous Krebs article.
In that case, having a personal username and password is futile.
The average person doesn’t want to, or care to dig into the fine details of securing a network, blacklisting or adding device communications to a blackhole. They want ease, simplification. Items sell better that way, and when the associated documentation gets too deep and the customers eyes roll to the back of their head, its not going to get done.
Easiest way to see if the devices are trying to communicate to an outside entity is to allow the device to communicate with something, like a wireless entry point, switch or otherwise. With the suspect device being the only one able to communicate on it, it will assist in seeing if they try to phone home. So, if it is a wired camera and dvr, plug the dvr cat 5 outbound connection into the switch and have a laptop with wireshark up. Then power up the dvr and see what is going on. It won’t help if there is a built in, unknown maintenance cycle which may occur say every month or particular day of the month. The owners manual may offer a hint whether this is done.
The problem with all of this is, there isn’t any so-called universal requirement for companies to follow. Most of them are out of the country you reside in. Better yet, if they buy devices that are not assembled and put them together, or, simply buy a complete product and simply re-brand it, they probably do not care to go the extra mile to ensure there is no back door or is within compliance to every single country they ship to. People like low prices, and easy to set up devices. As long as the device serves its purpose, they probably don’t give a damn whether its sitting in the corner spewing spam out their wireless connection.
The people behind these attacks are using trivial devices to do these attacks. They too do research and see how long its going to take to clean up a section of the devices that are vulnerable. When this section is cleaned up, I am sure they will be using something else such as the PC and server botnets available. Once thats cleaned up, they will attack the 2-3 year old “new iot” identified vulnerabilities and the cycle will continue. Remember people like things up and running – set it and forget it….The forget it includes patches and firmware upgrades.
Traffic no matter what type needs to be routed. Figure out a way to keep the DDoS far enough away from the attacked entity and the problem will be solved. Having the good guys jumping through hoops to fix issues that companies have created is foolish. All the information is within packets, sniff whats bad and reject. In todays mindset, its probably “not that easy”, but this is one solution that would work if some research company wants to make it happen.
Please check that the link to “Shields Up” UPnP exposure test leads to https://www.grc.com/su/upnp-rejected.htm
It is interesting that the GRC perspective focuses on WinXP (mainly due to this being 15 years ago), meanwhile we are all dealing with this issue at a time when so few people are using XP. Even though there are still plenty of XP machines out there, the lions share of the problem (if not the entire problem) has nothing to do with XP at all. The whole thing has gone so far beyond that.
In as far as the focus of this Krebs article…..
Where has all the effort in ‘updating’ gone? It seems to me that the REAL problem was never fixed by any update is it moves upward and onward with even the newest (supposedly most modern) equipment and devices.
Is this a Windows problem or is it a Linux problem? Is this more about end user apathy or manufacturer negligence? I’m alot more inclined to think it just simply is too many people focusing too heavily on the wrong thing while refusing to focus at all on the right thing.
This is not an OS issue. Unless you are counting embedded oses. This is more of a BIOS issue. Now, which languages are BIOS? Actually, only one, because everything derives from one, and flavors are set from there. All compile down to a basic set of controls.
Scapegoating clouds the issue. It’s here and now, how do you stop it. Be aware it’s around.
GRC and XP, so 90ish? He is a decent security researcher. He has got to have a system vulnerable to everything, too find out what is new out there. And good tools, never go out of date.