In case you needed yet another example of why your IoT devices shouldn’t be exposed to the internet, a large swath of Hikvision IP Cameras have a serious RCE vulnerability. CVE-2021-36260 was discovered by the firm Watchful_IP in the UK. In Hikvision’s disclosure, they refer to the problem as a command injection vulnerability in the device’s web interface. The vuln is pre-authentication, and requires no user interaction. This could be something as simple as a language chooser not sanitizing the inputs on the back-end, and being able to use backticks or a semicolon to trigger an arbitrary command.
Now you’re probably thinking, “I don’t use Hikvision cameras.” The sneaky truth is that a bunch of cameras with different brand names are actually Hikvision hardware, with their firmware based on the Hikvision SDK. The outstanding question about this particular vulnerability is whether it’s present in any of the re-labelled cameras. Since the exact vulnerability has yet to be disclosed, it’s hard to know for sure whether the relabeled units are vulnerable. But if we were betting…
Linux Malware on Windows
In retrospect it should probably be obvious, but the Windows Subsystem for Linux was destined to be yet another vector for infection for Windows machines. It’s finally happened in the wild, and Black Lotus Labs has the scoop. The actual malware sample is a Python script compiled into an ELF binary, designed to run inside the WSL environment. From there, it makes calls out to the Windows API. The advantage of using WSL for malware is that this escape detection by most of the security products on the market.
OMIGOD — That Didn’t Take Long
Last week we talked about the simple-to-exploit vulnerability in the Open Management Infrastructure, commonly installed on Linux VMs hosted in the Azure cloud. Botnets are already scanning the internet for vulnerable machines, and installing malware. The primary payload seems to be a Mirai variant, which among other things closes the vulnerable ports upon infection. Even though your VM doesn’t currently expose OMI to the internet, it may already be compromised. According to Caddo Security, there still haven’t been any automatic updates pushed to fix vulnerable servers, so unless a VM was manually updated last week, it should probably be assumed to be compromised at this point if it has OMI installed. This has the potential to be quite a big problem.
Smartphone Audit
How much do you trust your smartphone? How about a smartphone made by Chinese companies? The National Cyber Security Center of Lithuania had this question, and audited popular international phones made by Huawei, Xiaomi, and OnePlus. All three brands are produced by companies based in China, so there are some understandable concerns about potential spyware. If you think this is overly paranoid, go read about Project Rubicon.
The conclusions? Xaiomi devices are actively running spyware and have censorship tools built-in, although they are not actively blocking anything in international models. Huawei doesn’t seem to be quite so malicious, though it doesn’t get a complete pass. The problem here is the app store that ships with those phones. AppGallery is Huawei’s Play Store replacement, and it will helpfully fetch apps from a multitude of third party app stores. It does this quietly, so it’s very hard to determine if you’re actually getting the official version of an app, or a shady repackage from an obscure repository. The only brand to emerge clean is OnePlus, which isn’t terribly surprising. Read the full paper, available here as a PDF.
Bad OMENs
Many HP computers ship with the OMEN Gaming Hub, an all-in-one tool for managing hardware settings, among other things. This tool consists of a user-mode application, and a Windows driver running in the kernel. The front-end application makes IOCTL calls to the driver, which acts as a proxy to forward the calls to various hardware and software endpoints. The problem is that those calls are very flexible, and don’t have sufficient fine-grained controls to prevent abuse. Any application can make those calls, adding to this recipe for disaster. It’s not quite as easy as shift-right-clicking on a file chooser dialog, but it is as easy as a few lines of code added to the msrexec project. Put simply, arbitrary writes to MSRs (Model Specific Registers) means ring 0 code execution. After a botched patch attempt, HP has released properly fixed OMEN packages.
VoIP DDoS Ransom
Asking for a ransom to call off a DDoS attack is nothing new, but recently a new kind of target was attacked. VoIP.ms is a telecom provider offering VoIP services, and they’ve been effectively shut down by a DDoS attack. The attackers claim to be REvil, but that is likely a misdirect. Too many elements are unlike the way REvil operated. For instance, the initial ransom demand was delivered over pastebin, and only asked for a single Bitcoin. That has since been elevated to 100 Bitcoins.
While VoIP.ms has contracted Cloudflare to mitigate the attack and get their website operational again, this has done little to get actual VoIP services running again. Attacking VoIP networks this way is a very new attack, and providers like Cloudflare don’t yet have mitigations ready to go. If such attacks continue, I’m sure DDoS protection will soon be available.
Record DDoS
And we’ve just set a new record, and not one of those to be proud of. A new botnet, dubbed Mēris, has topped out at 21.8 million requests per second, so far. It’s likely that it’s capable of more. This is an application attack, rather than a raw bandwidth attack, meaning that the emphasis is on flooding the target with bogus requests.
When looking at the traffic sources, Qrator found a couple of odd similarities. Almost all of the IPs had ports 2000 and 5678 open, a sign of Mikrotik devices. The current theory is that the botnet is almost entirely made up of Mikrotik routers. The last known remotely exploitable flaw in these devices was CVE-2018-14847, fixed back in 2018. The number of devices in this botnet is suspiciously similar to the number of vulnerable devices exposed to the internet in 2018. It’s not clear exactly what has happened, but the official theory is that these devices were compromised in 2018, “fixed” with an automatic update, but still effectively compromised. This is still an ongoing story, we’ll try to update you if more is discovered.
Treat cameras like Windows XP and never allow them anywhere near an outside network, period.
Oh, you mean in the same VLAN as the Windows 10( now 11 ) machines ?
I’ll never understand the demented mind of a hacker to cause common people trouble. Can they just pool their resources and expose coverups, and other like documents from the government officials instead. Ya know, make the world a better place with their skills.
Do you understand $$$ ??? It is always about money. These people are being paid, some quite well. You can get them to work for you, too. Just cough up the money and they will do it.
who’s the bad guy here? The one that delivers an underdeveloped piece of software and asks for money, or the one that delivers a very sophisticated piece of software and does it for fun?
Some hackers do, which is how the list of CVE’s is populated… Maybe even most ‘hackers’ are, it doesn’t take many scumbags in it for themselves to make a great deal of trouble, and then there are the state sponsored ones…
You also have to look at how well leaking stuff or even founding sites that let others leak does for you – cover-ups and the like are generally done by powerful folk that have the ability to crush you effortless if they really want to.
One gets them money. The other would get them assassinated, like the journalist who exposed the Panama papers.
“The sneaky truth is that a bunch of cameras with different brand names are actually Hikvision hardware, with their firmware based on the Hikvision SDK.”
The vast majority of OEM versions of IP cams is wholly done by the supplier.
Very few companies use their own software on the vendor hardware. They just faff around changing the GUI and the product name in a lame attempt to disguise the original, but they are never very good at it – for the same reason they are doing an OEM in the first place.
So yes, pretty much 100% this fault is in all of the OEM’s of Hikvision.
IPVM maintains a big list. In US they are required to disclose if they use Dahua or Hikvision. Also those brands are banned for Federal agency use. Some companies add so many layers of obscurity by lengthening their supply chain that they actually claim the camera is a rebadge of a company out of Vietnam not Hikvision or Dahua. However, they both have the same source for silicon and software, just different markings on the components. It’s quite a mess, one must buy a product from one of the half of dozen highly reputable, also more costly, camera manufactures to avoid all this.
2 potential sources of vulnerability – one from the supplier and one by the OEM trying to implement their half-ass GUI.
Oh yes. Make my mistake the OEMs really have no freaking clue what they are doing for majority of the companies you see installed all around you. It’s a very bad sign when your transferred from installer support to a so called developer and then proceed to teach them how to use Debian Linux when their NVRs and cameras are both based on a Debian build. Not talking advanced stuff, simple folder traversal to find a file, open it in nano and read back what it says to the person on the phone. A simple readme file that was missing on the unit I was servicing, should be easy for anyone that develops for Linux.
The VOIP ransom has a distinct Dr. Evil vibe instead of REvil.
“And if we are not paid one bitcoin”
(holds pinky to mouth)
(everyone looks at the hacker)
“I mean one hundred bitcoins!“
If they didn’t receive ransom of 1 bitcoin, chances of getting 100 is even less.
On the other hand, a victim that was willing to pay is more likely to pay again.
Dunno. Microsoft has this kind of Midas touch. Under their breath, even Linux develops vulnerabilities it hadn’t in the first place.
Well said (written)!
Pauper Sadim touch: everything they lay a finger on turns to crap.
Anti-Midas. All they touch turns into shit.
I recall a mining company (Central Queensland) that wanted a camera set up so that their (non-technical) investors could go to a website and see what was happening on the site.
I’m a bit hazy on the exact details of what they were after… but a HikVision camera was procured and installed on site, with a 4G router “dialling home” over the Internet to a VPS in Sydney.
Muggins had the job of setting it up… they wanted the camera’s full UI available. The camera’s UI was only half-working in browsers other than Internet Explorer — fun to test because I run Linux on my workstation.
I figured, put it behind a HTTPS forward proxy, so that at least the credentials would be encrypted: no dice, the web interface expected to talk to all sorts of weird and wonderful ports to communicate with the camera.
I tried various solutions to try and make the interface work, but in the end, we were forced to just port-forward all the various ports to the Big Bad Internet.
The AU$8000 camera was compromised by malware within a fortnight. I’ll never touch another HikVision product.
If you ever run into this again, Zoneminder is the way to go.
Bit of a mess to get working and keep working. That’s why I usually grabbed a working image, and hoped for the best. You can always try Blue Iris.
Shinobi is a good one as well.
When it comes to IOT I am starting to think that if it isn’t 100% FOSS and powerful enough to run BSD, so that you can build it yourself, then it is just a matter of time before it is giving you some sort of grief.
I have been enjoying the proliferation of code for the RPI and watching some ecosystems start to take shape.
I have had it in my mind for a while that is would be really cool to build a compute module board for a camera, but the missing piece for me is a way to get two-way audio and have several endpoints tied to a central voice assistant like Mycroft.
Really sucks that the pandemic made me all this free time but I can’t buy things due to rolling shortages.