It's what we all assumed, but quietly hoped wasn't quite this bad.

Lazy makers of home routers and the Internet of Things are reusing the same small set of hardcoded security keys, leaving them open to hijacking en masse, researchers have warned.

In other words, if you can log into one gizmo remotely, you can probably log into thousands upon thousands of others – even devices from a different manufacturer.

Infosec biz Sec Consult says it studied 4,000 embedded devices from 70 hardware makers, and found that many products are sharing the same hardwired SSH login keys and server-side SSL certificates.

As a result, potentially millions of gadgets can be logged into by miscreants, or their builtin HTTPS web server connections silently decrypted by man-in-the-middle attackers, using these keys and certificates once they are extracted from their firmware.

The problem, says Sec Consult, lies in the way many IoT and networking gear vendors develop and deploy their products. Chipmakers will often provide a software development kit with their silicon for product manufacturers to adapt for their particular applications.

Unfortunately, hardly anyone changes this source code, not even the security keys or certificates included as examples. What we all end up with is gadgets with logins stashed in flash ROMs, and the keys known to anyone with the ability to extract the data.

"The source of the keys is an interesting aspect. Some keys are only found in one product or several products in the same product line. In other cases we found the same keys in products from various different vendors," Sec Consult noted.

The keys, certs and source code can come from "white-label devices produced by different vendors; hardware, chipset or SoC vendors' software development kits; or board support packages."

The infosec biz gave these examples of shared secrets in multiple devices:

A certificate issued to a Broadcom email address is used in firmware from Actiontec, Aztech, Comtrend, Innatech, Linksys, Smart RG, Zhone and ZyXEL. This certificate is found in a Broadcom SDK. The affected vendors used it as a basis to develop their own firmware. More than 480,000 devices on the web are using this single certificate.

A certificate issued to Multitech in Bangalore, India is used in firmware from Aztech, Bewan, Observa Telecom, NetComm Wireless, Zhone, ZTE and ZyXEL. This certificate can be attributed to a Texas Instruments SDK for ADSL2+ routers. Over 300,000 devices on the web are using this certificate. A SSH host key can be attributed to this SDK as well.

A certificate issued to "MatrixSSL Sample Server Cert" is used in WiMAX gateways from Green Packet, Huawei, Seowon Intech, ZTE and ZyXEL. All affected devices use the same code base, which is likely developed by ZyXEL. At least 80,000 devices on the web are using this certificate.

None of this will be a shock to many of you – anyone who's come close to a system-on-chip knows a lot of consumer-grade firmware is rushed, insecure, and rarely patched after release.

For now, it's fun marveling Sec Consult's statistics: roughly 580 private keys were found distributed over all the analyzed devices, and at least 230 are in use in the wild on the internet, we're told. The study was carried out by Stefan Viehböck, a senior security consultant at Vienna-headquartered Sec Consult.

The HTTPS certificates are used to secure the builtin web-based configuration interface provided by some devices. The SSH keys are typically used to log into gadgets remotely, and control them completely via a command line.

Sec Consult said the millions of vulnerable devices include wireless broadband gateways, network routers, and IP-enabled appliances. The biz reckons they have the server-side certificates for nine per cent of all HTTPS-serving hosts on the 'net, and the keys to six per cent of SSH hosts.

The research outfit has urged device vendors to give each individual device they sell securely random cryptographic keys, generated in the factory or on first boot up.

As for the insecure equipment and gadgets in the wild right now, what's being done about them?

"We have worked together with CERT/CC to address this issue since early August 2015," Sec Consult said.

"CERT/CC made great efforts to inform affected device vendors, chipset manufacturers and affected ISPs. Some vendors have responded and have started to implement fixes. CERT/CC informed major browser vendors as well. This vulnerability is tracked as VU#566724. Several CVE-IDs have been assigned as well."

Keep a look out for those firmware updates; if your vendor is any good, working patches might well arrive before the heat death of the universe. ®