I must have missed when de facto definition of MCU started including being on the network and doing crypto :-)
Kirby64 3 minutes ago [-]
IoT devices typically run on MCUs and they have WiFi connections, often. The price of MCUs with WiFi has gone down dramatically. Often $5 or less for a MCU capable of WiFi and usually Bluetooth. Think, ESP32-S3 and such.
tomku 52 minutes ago [-]
Your device would also have to be pretty recent to ship any of these certs in a frozen cert store as they were only generated in April/May of 2025.
jauntywundrkind 16 minutes ago [-]
Of all the places for what is otherwise eMudhra's epic fail, various MCUs was the one place I thought perhaps there'd be some silver lining. Some interesting and good, for the hackers: to get to have some chance to see what their devices are doing, to man-in-the-middle those conversations home those devices in our homes are doing, and see what they are saying.
tl;dr: MCUs are space-constrained and often don't include root certs that aren't used by the one host they talk to.
In my experience it's equally likely they just don't do validation to begin with. For example, my Elk M1XEP (physical security system's Ethernet expander) runs a configuration server with and without TLS. They recommend with, but it uses a self-signed certificate, and the crappy VB.NET configuration program doesn't validate the cert in any way, so it can be trivially MITMed. The Elk M1XEP also can connect to a user-chosen alarm monitoring service ("central station") over the Internet. I don't think it uses TLS at all for this. I think there's optional shared secret auth/encryption?
sterwill 37 minutes ago [-]
Over a decade ago, I created an AWS ELB to serve a production API. It was HTTPS-only, using an Amazon-signed certificate served from ACM for my employer's domain. Right after deployment, logs showed a regular pattern of 404s trying to POST/PUT to my API at paths I didn't support. Thousands of requests per hour, and they continued for days. It didn't look like a DoS--the paths looked like someone else's API.
I got curious what all the traffic was, so I added a route to the API that saved some of the uploaded data. It was live home surveillance video and photos! Indoors, outdoors, baby monitors, living rooms, etc. It was pretty easy to find which vendor's hardware was doing this (from headers, paths, watermarks) and I reached out to their security contact to let them know what I found. They responded generically but didn't seem to care that much.
In short, because HTTPS was required, and an ELB gets assigned IPv4 addresses arbitrarily, I can only conclude that a whole fleet of home security cameras were sold across the US that hard-coded the IP address of their cloud server and had certificate validation disabled.
hasheddan 1 hours ago [-]
This is unfortunately accurate, sometimes due to real constraints and more often due to loose threat models. I am hopeful that more open source firmware options (e.g. Zephyr RTOS) and more software investment from silicon vendors is helping to change the status quo. That being said, we are still a long way away from a "Let's Encrypt movement" for embedded devices.
wolrah 16 minutes ago [-]
> sometimes due to real constraints
IMO this should always be pushed back against, because it's not a valid excuse. If the hardware is too constrained to support appropriate security then that hardware is not appropriate for the application (or no longer appropriate for the application, as the story often goes).
elevation 39 minutes ago [-]
> physical security system
> can be trivially MITMed
Crazy how poor security can be even from a purported security vendor.
Rendered at 18:09:18 GMT+0000 (Coordinated Universal Time) with Vercel.
This fact alone though makes that very unlikely.
https://news.ycombinator.com/item?id=50166579 - “eMudhra intermediate CA compromise” - 947 points | 19 hours ago | 408 comments
https://news.ycombinator.com/item?id=50177916 - "Eight Bits of Trust; eMudhra's CA keys cracked in milliseconds" - 604 points | 7 hours ago | 270 comments
In my experience it's equally likely they just don't do validation to begin with. For example, my Elk M1XEP (physical security system's Ethernet expander) runs a configuration server with and without TLS. They recommend with, but it uses a self-signed certificate, and the crappy VB.NET configuration program doesn't validate the cert in any way, so it can be trivially MITMed. The Elk M1XEP also can connect to a user-chosen alarm monitoring service ("central station") over the Internet. I don't think it uses TLS at all for this. I think there's optional shared secret auth/encryption?
I got curious what all the traffic was, so I added a route to the API that saved some of the uploaded data. It was live home surveillance video and photos! Indoors, outdoors, baby monitors, living rooms, etc. It was pretty easy to find which vendor's hardware was doing this (from headers, paths, watermarks) and I reached out to their security contact to let them know what I found. They responded generically but didn't seem to care that much.
In short, because HTTPS was required, and an ELB gets assigned IPv4 addresses arbitrarily, I can only conclude that a whole fleet of home security cameras were sold across the US that hard-coded the IP address of their cloud server and had certificate validation disabled.
IMO this should always be pushed back against, because it's not a valid excuse. If the hardware is too constrained to support appropriate security then that hardware is not appropriate for the application (or no longer appropriate for the application, as the story often goes).
> can be trivially MITMed
Crazy how poor security can be even from a purported security vendor.