Live data from Hacker News

Mirai Botnet Client, Echo Loader and CNC source code

github.com

21–30 of 51 posts

Re: Mirai Botnet Client, Echo Loader and CNC source code

#22
post #17

This thing's strategy for finding machines to take over is so simple it's embarrassing. It tries to open an unencrypted Telnet connection to random IP addresses. If it gets a response, it tries the following username/password combinations: root xc3511 root vizxv root admin admin admin root 888888 root xmhdipc root default root juantech root 123456 root 54321 support support root (none) admin password root root root 1…

Oh crap. That has like two of my passwords in there.

Re: Mirai Botnet Client, Echo Loader and CNC source code

#23
post #7

Earlier quoted context omitted.

Thanks. Question for the C folks. The author seems to have reimplemented functions such as strlen, memcpy, and atoi in 'bot/util.h' instead of using the stdlib. Anyone know why? https://github.com/0x27/linux.mirai/blob/master/mirai/bot/ut...

Because you cannot rely on some chintzy IoT device to have dynamically loadable libraries. In all likelihood, they don't. But let's assume they do have loadable stdlib, would would you trust the integrity of your botnet to dozens of poorly designed IoT devices?

Don't most of these IoT devices usually run Linux though?

Re: Mirai Botnet Client, Echo Loader and CNC source code

#24
post #17

This thing's strategy for finding machines to take over is so simple it's embarrassing. It tries to open an unencrypted Telnet connection to random IP addresses. If it gets a response, it tries the following username/password combinations: root xc3511 root vizxv root admin admin admin root 888888 root xmhdipc root default root juantech root 123456 root 54321 support support root (none) admin password root root root 1…

I cannot wait for some type of top-down pressure to force IoT developers to take security seriously. The movement has been pushed into overdrive thanks to insane levels of competition where you either crush your R&D into the smallest breakneck period or you live to see your creation being sold for half of what your budget can allow by other firms lifting your efforts while you're still at the workbench.[1]

I've been getting cozy with Shenzhen-based hardware accelerators for the past year as part of a personal side-venture and I have not seen a group so pressured to deliver a product as fast as possible with security being a casual afterthought. To get a decent taste of what it's like, I wholeheartedly recommend WIRED's Future Cities documentary on Shenzhen and the companies that dwell there.[2] Their struggles for ephemeral market-share are endemic of the entire community that's taken over embedded hardware for the past few years.

The saddest aspect of it all is that this market competition isn't benefiting the consumer. IoT devices are coming out of the factories poorly engineered, badly maintained for far too short of a time, and as we've learned from this attack, being used as vectors for network intrusion and distributed censorship. Even arduino founder Massimo Banzi's widely-lauded IoT Manifesto[3] fails to approach any comprehensive statement regarding a dev's responsibility to build in some level of security to their devices.

It just isn't part of the fast-and-loose culture that has been bred by trend-setting companies with unlimited budgets making bad decisions from the very start.[4] In addition, the if-you-can't-beat-'em-join-'em attitude the West has taken towards churning out hardware devices as fast as they can before jumping to the next IoT piece of junk before the ripoffs can hurt them is really disappointing as it prevents any considerable effort from going into a device pre-and-post release.

All in all, the IoT community is not going to change their priorities unless someone very powerful forces them to and it can't happen soon enough.

[1] http://qz.com/771727/chinas-factories-in-shenzhen-can-copy-p...

[2] https://www.youtube.com/watch?v=SGJ5cZnoodY (This is over an hour long but very worth it)

[3] https://create.arduino.cc/iot/manifesto/

[4] https://techcrunch.com/2014/01/06/nest-4-0-firmware-battery-... & again in 2016 http://www.nytimes.com/2016/01/14/fashion/nest-thermostat-gl... I'm not going to even touch the dropcam and IoT smoke detector.

Re: Mirai Botnet Client, Echo Loader and CNC source code

#25
post #17

This thing's strategy for finding machines to take over is so simple it's embarrassing. It tries to open an unencrypted Telnet connection to random IP addresses. If it gets a response, it tries the following username/password combinations: root xc3511 root vizxv root admin admin admin root 888888 root xmhdipc root default root juantech root 123456 root 54321 support support root (none) admin password root root root 1…

What's up with 7ujMko? That one seems really secure.

Re: Mirai Botnet Client, Echo Loader and CNC source code

#26
post #25
post #17

This thing's strategy for finding machines to take over is so simple it's embarrassing. It tries to open an unencrypted Telnet connection to random IP addresses. If it gets a response, it tries the following username/password combinations: root xc3511 root vizxv root admin admin admin root 888888 root xmhdipc root default root juantech root 123456 root 54321 support support root (none) admin password root root root 1…

What's up with 7ujMko? That one seems really secure.

Hardcoded in some "firmware example" supplied by the vendor, someone REd the firmware and published the password on his blog, and then it was discovered by the author(s) of this malware.

Re: Mirai Botnet Client, Echo Loader and CNC source code

#27
post #25
post #17

This thing's strategy for finding machines to take over is so simple it's embarrassing. It tries to open an unencrypted Telnet connection to random IP addresses. If it gets a response, it tries the following username/password combinations: root xc3511 root vizxv root admin admin admin root 888888 root xmhdipc root default root juantech root 123456 root 54321 support support root (none) admin password root root root 1…

What's up with 7ujMko? That one seems really secure.

It's a simple pattern on a QWERTY keyboard. 7UJM and MKO are each on a diagonal path.

Re: Mirai Botnet Client, Echo Loader and CNC source code

#28
post #25
post #17

This thing's strategy for finding machines to take over is so simple it's embarrassing. It tries to open an unencrypted Telnet connection to random IP addresses. If it gets a response, it tries the following username/password combinations: root xc3511 root vizxv root admin admin admin root 888888 root xmhdipc root default root juantech root 123456 root 54321 support support root (none) admin password root root root 1…

What's up with 7ujMko? That one seems really secure.

It doesn't matter how "secure" a password is if it's known. Quite a few vendors ships devices with a common factory password, stated in the manual. And people put those on ther internet.

Re: Mirai Botnet Client, Echo Loader and CNC source code

#29
post #9
post #7

Earlier quoted context omitted.

Thanks. Question for the C folks. The author seems to have reimplemented functions such as strlen, memcpy, and atoi in 'bot/util.h' instead of using the stdlib. Anyone know why? https://github.com/0x27/linux.mirai/blob/master/mirai/bot/ut...

I believe not all embedded systems have the c stdlib.

Not the reason. Especially when the author includes headers like: #include #include #include #include #include #include #include #include

Re: Mirai Botnet Client, Echo Loader and CNC source code

#30
post #23

Earlier quoted context omitted.

Because you cannot rely on some chintzy IoT device to have dynamically loadable libraries. In all likelihood, they don't. But let's assume they do have loadable stdlib, would would you trust the integrity of your botnet to dozens of poorly designed IoT devices?

Don't most of these IoT devices usually run Linux though?

Sure, but many of them only contains a static busybox binary and no libc.
Post reply on HN