Move Over Dahua, Xiongmai Is The Real Botnet King
From a recent report by Flashpoint
Manufacturer of Upstream Devices Identified
While investigating the recent large-scale DDoS attacks against targets including Krebs On Security and OVH, Flashpoint identified the primary manufacturer of the devices that utilize the default username and password combination known as root and xc3511, respectively. These types of credentials exist all across the Internet and are commonly used via Telnet to access numerous types of DVRs. In fact, countless DVR manufacturers buy parts preloaded with Linux and rudimentary management software from a company called XiongMai Technologies, located in Hangzhou, China. This company sells white-labeled DVR, NVR and IP Camera boards and software to downstream vendors who then use it in their own products. Altogether, over five-hundred thousand devices on public IPs around the world appear susceptible to this vulnerability.
... In fact, the majority of media coverage surrounding Mirai has outed Dahua products as a primary source of compromised devices. However, Flashpoint’s analysis on the attack data shows that while Dahua devices are indeed being compromised, a very large percentage of these IP involved in the DDoS attacks were hosting XiongMai Technologies-based products. The Dahua devices were identified early because of their distinctive interface and recent use in other botnets.
Well... Damn.
Here I was ready to take all the shots necessary for my team >.>
That doesn't mean we can relax though. I'm still gonna hammer Dahua to get on a gigantic cybersecurity kick...in addition to making sure their smart codec isn't some weird proprietary isolated thing... and adding Control4 compatibility across the board.
Dahua...can you please hire more programmers and get your code on GitHub?
*sigh*
Good find, good share.
Some more info on XiongMai. The reason why XiongMai is so poorly known is that they provide modules / kits like so:
Here's a list of their IP All-In-One IP camera modules.
XiongMai, according to the people I spoke to, is the biggest provider in this space, and the most common provider for small 'manufacturers' / 'assemblers' that want a low cost / simple option.
What I have not figured out is how to determine who is using XiongMai (has to be a lot but not sure who). One person suggested tracking down MAC addresses / OUIs. I did a reverse OUI lookup with a few variants of XiongMai's name but did not see any matches.
Anyone have any input of who's using XiongMai?
I can help with that. We are using XM solutions for OEM. Any info can be useful - welcome to ask.
Sergey, thanks!
1. Why us XM vs others? In general, just curious to understand their value proposition?
2. Are you concerned about the security flaws that Flashpoint is reporting with XM software?
1. Historically. Our market is well-controlled with Hik, Dahua is not so noticeable. Also there are a lot of cheap solutions - most based on XM or Longse products. It is big success to know the real manufacture-developer, not assembling one. 4 years ago we made such analysis and start to work with XM. Reasons:
- Price. Is really compatible for low-cost products. 2 years ago they begin to make good mid-range IPC. According comparison for IP price is 25-30% lower than Hik, AHD is 5-10% lower than Hikvision Hiwatch TVI.
- Completed system - most part of our clients are end-to-end system users, it's easier for them
- Absolutely denial of cooperation with Hik, as they control our market. 8 OEM-partner of Hik seems to me enough reason for such conclusion
- Most important for me personally - possibility to influence on the process - what sensor to choose, what ISP/CPU to choose, which housing is necessary for us - all of this we can ask to make.
- Quality reasons - much higher that Longse, price is almost the same
2. We met this problem - last year a lot of FWs were with opened Telnet port. But we insist to fix it asap. Now - i think this problem is solved. But! I know 100% that some assembling companies who use XM modules make OEM-FWs with opened telnet. May be just forgot to close, but who knows;)
Sergey, great, very informative!
Did they provide you with firmware development SDKs or give you their source code so you could be more than just assembly? Are you reliant on them for firmware releases/development?
For hardware part we have no human resources to make something own, that's why we ask them to change, update or fix anything we want. But I heard from assembling factories who used XM modules, they provide also tools for FW changing. Also my familiar programmer told that XM FWs are very easy to open and understandable, and he can make any change he need.
For software development we have some own products, and we have experience with their SDK. Last years XM is moving up to API CGI interfaces, what makes software development easier.
From my point FW is not the most important think you take into consideration when take decision about cooperation. Of course it is necessary to protect system and avoid different backdoors.. But.. I'm pretty sure that all, absolutely all manufactures have such kind of backdoors.
Also, market of surveillance devices is moving to the low-cost solutions. Even AXIS, Panasonic and Samsung now feels strong competition from "downstairs". Are you sure that these factories will pay more attention to make products more safe? I don't think so.
But.. I'm pretty sure that all, absolutely all manufactures have such kind of backdoors.
Uh oh, here we go :)
So to recap, your policy is that Cybersecurity is best left to be the integrators' responsibilities.
Mine is that all levels need to be involved as far as it is possible and reasonable.
I would like to see a top down push for accountability, rather than an approach where everything is coming from the bottom.
- Manufacturer creates secure firmware that enforces secure setup procedures and does not allow defaulted settings.
- Manufacturer distributes firmware to distributors on a regular basis OR maintains a properly accessible database of firmware to keep up with new features and adapt to security breeches
- Distributors notify integrators and installers of firmware updates and ensure that end-users are not victims of integrator carelessness and assist them with setting up remote system management with secure credentials
- Integrators do their jobs and ensure that the networks themselves are secure and installed well. Try not to use zip ties to secure cameras, like...seriously.
Dahua really has been surpassed by XiongMai, take a look at this copy:
After the speech, discussion went into a climax state, wonderful summit forum ignited the sparks of thinking. The president of Hikvision Yangzhong Hu, CEO of Dahua LeiLiang, Chairman of Chuanggao security ChenLi, Chief engineer of Shideanlegrand were discussing fiercely around the theme of “ how to play when the intelligent household into <free> mode”. For the market of intelligent household is mess, what is the real meaning to the users?
The president of Hik and CEO of Dahua were fiercely sparking in a climatic discussion?
About how to play in the household? Sounds interesting.
Longse / Cantonk just sent a mailer emphasizing supporting XiongMai (XM):
Cantonk IP Camera Advantage:
*Hikvision & XM private protocol support
What I am not sure about is whether Longse / Cantonk uses XiongMai. Also, not sure how Longse / Cantonk is allowed to support Hikvision's private procotol. Any one with info here?
SDK from Hik and XM is opened. Protocol description can be collected from XM directly. Anyone can use it to integrate private protocol. I suppose, the same with Hik
Longse / Cantonk just sent a mailer emphasizing supporting XiongMai (XM):
Longse's sense of timing is impeccable.
John,
Test results from 3 different XM camera modules might shed some light on why you couldn't find XM in the OUI database.
Each camera module tested identified its vendor as H264DVR while the OUI lookup did not.
Model OUI Company (as per Wireshark OUI Lookup Tool)
IPG-50H10-S 00:12:13 Metrohm AG
IPG-53H20-S 00:3E:0B "No Matches"
IPG-54H20PL-S 00:12:15 iStor Networks, Inc.
3 different modules with 3 different OUIs and none of them registered to XM.
(Note that even though the modules were obtained from 3 different sources, all 3 modules were received complete with attached XM part numbers, model numbers and bar codes.)
#2, very helpful, thank you!
Btw, do you know of any easy way to buy XM camera modules online? I google'd around and found one listing on aliexpress so far but not much overall.
I'm not the original poster, but do you want camera modules rather than complete cameras? Many of the cheap chinese cameras are based on these modules, so finding them is easy. Here are two I got from amazon:
https://www.amazon.com/gp/product/B00M932IG0/ref=oh_aui_search_detailpage?ie=UTF8&th=1
https://www.amazon.com/gp/product/B00KA4M4WS/ref=oh_aui_search_detailpage?ie=UTF8&psc=1
... and two others from aliexpress:
You can find several others by looking for cameras that support the "xmeye" app.
XM camera modules are easy to find on eBay also - there are many vendors. Searching for the XM model number will give you some direct hits. Searching for the SoC & imager part numbers (which you can get from the XM website) will give you many more.
Does anyone have an explanation for the XM OUIs?
Even if XM is actually manufacturing for Metrohm AG and iStor Networks (and therefore allowed to use their OUIs), what would be the explanation for the unlisted OUI (00:3E:0B)?
Can't explain OUIs of XM products, but several times we met different cameras or DVRs with same Mac. This situation occurs once per 2 months.
Also, in our FWs we change H264 title with our own title.
Else some info. As far as I know, some factories has licence from XM and can make their own products according this licence. Products are full compatible, but still not XM-produced. How they proceed QC in this case..?
several times we met different cameras or DVRs with same Mac
Sergey, do you mean literally the same exact MAC address that theoretically should be unique?
Yes, that's the point. We asked R&D department to make special unique FW to fix this bug
Any idea how they did that? Are they making them up? Seems like an easy thing to avoid?
Have no idea.. For example, when we met the same situation with TVT products, the only way to fix was to send mainboard of DVR back to factory..
So TVT was also shipping products with the same MAC address to you?
Our cooperation with TVT was not so deep, but even in such conditions we have now 2 DVRs with same Mac. We noticed this when our client tried to add these DVRs into VMS software (original TVT software).
My words are shocking?:)
Lol, yes, they are. Just seems too easy to avoid.
Related, started a new discussion How Can a Manufacturer Ship 2 Devices With The Same MAC Address?
Newest Discussions
| Discussion | Posts | Latest |
|---|---|---|
|
Started by
Thomas MCVEY II
|
5
|
less than a minute by Undisclosed Integrator #2 |
|
Started by
John Honovich
|
27
|
10 minutes by Undisclosed Manufacturer #1 |
|
Started by
Brian Rhodes
|
15
|
32 minutes by Chris Hammond |
|
Started by
John Honovich
|
28
|
about 5 hours by Undisclosed Manufacturer #11 |
|
Started by
Ross Vanderklok
|
2
|
about 4 hours by Undisclosed End User #1 |