Offensive security against no hanging fruit

In general I find offensive security to be a bit of a pre-determined successful outcome and not much of a challenge.  Given enough time you only need a single successful attack to win the game.  As amusing as it is to see remote exploits for windows rolling out faster than the patches, it's a fairly dull path to find an infinite number of ways to reach that goal.

I find spending my time in defensive security to be a much more challenging and worthwhile pursuit.  How can I defend against all known and unknown attacks or at least decrease dwell time so remediation is happening within days instead of months to years.

All that said, there is an area where the offensive and defensive side are not entirely glamorous, high publicity, or even paid attention to at all.  I am calling this no hanging fruit: it is so bad that anyone spending any time on it would find ways to compromise the entire system.  Why is this an under-reserached category?  Hardware.  We can all emulate the heck out of an OS, but fewer can decipher FCCID specs and the resulting hardware, much less build and use the equipment to intercept the faults.  Please keep in mind I don't find hardware hacking to be any harder than software hacking, but it does place a knowledge and cost burden higher than our day to day exploits.

As an amateur radio (ham radio) operator for the past 21 years, I have learned to appreciate the documentation that companies must publicly provide the FCC in the US to gain insight into the hardware.  In this post we will take a look at fccid R7PEG1R1S2 for the electrical smart meter used by Oncor across almost all of Texas.  I would direct post a link, but unfortunately we are stuck in the land of temporal post documents with no direct links.  To follow along, visit https://www.fcc.gov/general/fcc-id-search-page, Grantee Code: R7P, Product Code: EG1R1S2.  At the time of this writing I found 10 results, 9 in the 900mhz spectrum and 1 in the 2.4ghz area.  You can browse these documents to your heart's content: it's all public from the US government despite the internal company confidential labels.  As much as I love frequency counters, it is a lot easier to just grab the frequencies from a public document.

"The Gridstream RF network currently supports use of one encryption key per network. If you enable the FOCUS AX with encryption, the host must have a matching encryption key."  No, you didn't mis-read that, the public specs state that in the event that they bother to encrypt on the 900mhz bit, a single symmetric key is used for all nodes in that network.

Just some personal favorite hilarity:

• "GMT Offset: The GMT Offset in 15 minute increments. Signed.
  Valid values are -128 (0x80), corresponding to GMT-32hours to +127 (0x7F), corresponding to GMT+ 31hours" - my god must save some bytes!?!  It seems like they used some junk 1980s hardware.
• It's an FCC Part 15 Class B device and *must* not cause any harmful interference and must *accept* any harmful interference.  Most forms of jamming are illegal in this country, but I wouldn't be surprised if an early model 900mhz cordless phone left on continuously might disrupt the system.

RF Frequency Range 902.2 MHz Min, 927.9 MHz Max
RF Baud Rate 9.6 kbps Min, 115.2 kbps Max, Programmable

In my area, none of the data is encrypted and is broadcast plain-text over the air.  The configuration table in the FCC information is sufficient to pattern match and reduce that part of the data frame/packet to usable information without any reverse engineering.

Don't forget that the clocks are only accurate +/- 15 minutes.  That is when they "check-in".  Oh, part of the device is a permanent MAC, visible on the physical device.  Given the clock skew, I can only theorize what might happen if an un-official signal is sent just before the official one.  The specifications seem to indicate that the first signal would win *and* clock synchronization would then deem that node the official source.

I have in no way attempted to splice into the hardware or otherwise breach output via data communication over the AC lines.  I would think that there would be no reason to broadcast things as critical as billing data usage plain-text over the air if they were using network over AC instead.  Of course assuming competence or intent from a large corporation is a fool's errand.

I welcome any additional information in this blog or via email and am happy to supply GPG keys, if they are not readily found by interested respondents.

Happy hardware hacking!