TL;DR- A vulnerability in theFIMER React 2 hybrid inverterlets anunauthenticated attacker send commandsstraight to internal components (Supervisor, Inverter DSP, and others) remotely - no credentials needed. The root cause: a simple misconfiguration. The potential fallout:physical damageto the device, permanentDenial-of-Service(DoS),financial loss, and evenrisk to the lives of grid techniciansworking on-site. FIMER is an Italian manufacturer of solar inverters, and the device that caught our attention was their hybrid inverter, the React 2. A quick primer: an inverter converts DC to AC and back; ahybridinverter also handles DC-DC conversion, which matters if you want to store solar energy (DC) directly into batteries (DC). The React 2 is an all-in-one photovoltaic hybrid inverter and high-voltage lithium-ion Battery Energy Storage System (BESS), and it can be bundled with one to three battery packs. Going in, we assumed the Battery Management System (BMS) would be the highest-value target. Can you blame us? Batteries can literally catch fire. What we found instead was a device with far more moving parts than we expected. Beyond a BMS per battery pack, the React 2 packs: All of it talks over CAN bus and RS485. The reference docs hint at an additional DSP per battery pack, and the firmware suggests a separate "charger" component alongside the BMS - we didn't get to those this time around. Meanwhile, the Buildroot system alone runs a small fleet of services: two separate Modbus server implementations, a free@home service, a web app, a REST API, and more, all talking to each other internally over ZeroMQ. Our Binary Ninja project ended up with analysis databases for 63 ELFs - and that's before counting the other controllers and DSPs. That's a lot of surface area for a device most people assume is about as dangerous as a toaster. But a toaster can only burn down your house. A hybrid inverter in this class (3.6/5.0 kW) can damage itself, your appliances, and the grid - and put the people servicing it at real risk. This research had several breakthroughs, and thefirst one was a simple misconfiguration. Some of the REST API endpoints the device serves require authentication. FIMER implemented this using Nginx'sauth_requestdirective: Nginx forwards the request to an authentication endpoint, which validates the auth headers and sets headers likeuserandrolebefore passing the request down to its destination. Some of you have probably already paused to stare at that config, hunting for the misconfiguration. Go ahead - you might find one. But don't hold your breath. The one we found is somewhere else. The service that actually handles the requestslistens on0.0.0.0:1978! That's right - send your request toport 1978 instead of 443, and youskip authentication entirely. Instead of listening only to localhost (i.e., requests that already passed through Nginx's auth check), the service listens on all interfaces. You can see this in the service's init script,/etc/init.d/S41rest_resources_poco. This immediately raised information-disclosure concerns. But the device also exposes Modbus, which is unauthenticated by design, so info disclosure alone isn't the headline here. What did catch our attention was a specific endpoint:/v1/directmethod/command. It's aPUTrequest with a JSON body containingmethodandpayload.methodcan be one of three values:READ_FLASH,CAN_CALLBACK, orAURORA. READ_FLASH, true to today's running theme, is less interesting than it sounds. The other two are a different story - both let you send CAN messages to internal components. CAN_CALLBACKdoes what it says: it invokes a callback via a CAN message. Its payload is capped at two bytes, though, and part of that is consumed by the callback index - not much room to do anything meaningful. AURORAis the real prize. Aurora is FIMER's proprietary protocol, a holdover from when the company was still PowerOne, predating even their Modbus support. It was originally designed for interoperability between FIMER/PowerOne devices over RS485. This endpoint lets you send Aurora commands over CAN bus instead - with a 7-byte limit, since one byte of the 8-byte CAN payload is reserved for FIMER's own internal-communication protocol (more on that later). This is where the real work started. What can you actually send in these messages? What's listening on the other end? And what can you make it do? To answer that, we had to pull the thread from both directions: first, by analyzing the firmware of the component we'd already been examining, to understand the CAN message format and find every Aurora command it issues; second, by digging through the firmware of the other internal components to identify the recipients and enumerate every command they implement. FIMER distributes firmware packages in two formats:benandtib. We believebenstands for "binary encoded." The format is simple: a 0x200-byte header followed by arbitrary data.tib, by contrast, is a flat archive format. The firmware updat...