This could be bad...

[Teken]

It can be done easily with the cc1111emk USB dongle.

 

I already have Python scripts that allow you to send commands in hex similar to the raw PLM interface.

 

Wrapping this as a network service making and presenting a PLM like interface over TCP would be straight forward.

 

EVIL Pete,

 

Just to clarify are you saying the use of the cc1111emk USB dongle will allow RF 2 way interaction with an (existing PLM) or the latter which is (IF) some enterprising person was able to create a software PLM they could also use the cc1111emk USB dongle to mimic the same as a real hardware PLM?

[larryllix]

Development of an Insteon monitor with minimal hardware would be an awesome project! Obviously some hardware to input RF or clean up powerline signals would be needed.

 

It would nice to observe some of this traffic from another vantage point possibly proving some other problems Insteon may have created.

 

I did this with X10 and it allowed me to troubleshoot some networking problems much easier. I also found old modules I had forgotten I had plugged in.

[MikeD]

I'll have the code up in a day or so now that I'm back from defcon.

 

Effectively Insteon's documentation for their RF protocol is bullshit and not even close to what is really used.

 

I've reverse engineered the actual protocol, documented it, and wrote proof of concept set of tools.

 

These tools consist of a few programs & scripts to allow anyone to intercept and/or transmit commands effectively circumventing Insteon's security model of needing to know the node address or being paired.

 

With a good antenna Insteon devices can be communicated with at a fair distance.

 

The security risk for the end user obviously depend on what you use Insteon for. if you have just lights, your threat profile is minimal.

 

I would not advise connecting locks or alarm systems as Insteon is showing to be the weakest link in the chain

Thanks for the motivational information. I have been thinking about replacing the IOLinc that controls my garage door with a Z-Wave controller for a while. I just ordered this Z-Wave garage door controller http://products.z-wavealliance.org/products/1298 from Amazon and will be replacing the IOLinc. According to the documentation it has the 'Z-Wave Plus' or 'Gen 5' chipset. Should be here on Friday for installation this weekend.

 

~Mike

[MWareman]

Interesting. With software, this could also enable a Rpi to represent any number of virtual devices and any type of device - each with a link to a physical PLM, and be a first class citizen in the ISY device/scene tree.

[evilpete]

EVIL Pete,

 

Just to clarify are you saying the use of the cc1111emk USB dongle will allow RF 2 way interaction with an (existing PLM) or the latter which is (IF) some enterprising person was able to create a software PLM they could also use the cc1111emk USB dongle to mimic the same as a real hardware PLM?

 

To be clear the the cc1111emk (with software) can be equivalent of an  Insteon 2448A7 Portable USB Adapter  but with the ability receive and send arbitrary packets over RF, you will need an AP or dual-band device to relay the packets onto the powerline.

 

In fact for "fun"  I just ordered a EZ430-Chronos-915 ( http://www.amazon.com/gp/product/B00DK2D8WW ) since it's based on the same chipset as the dongle and thus would be somewhat trivial to run a script ( in the watch ) that can send Insteon commands. 

 

 

Development of an Insteon monitor with minimal hardware would be an awesome project! Obviously some hardware to input RF or clean up powerline signals would be needed.

 

It would nice to observe some of this traffic from another vantage point possibly proving some other problems Insteon may have created.

 

That pretty much already done,  for receive only you can use a  $15 rtl_sdr  dongle and software demodulator

 

The current output is something to the effect of :

 

Flag   To        From      cmd   crc padding

C3 : 11 0D 27 : 01 00 00 : 11 80 F8 00 00 AA

41 : 80 25 13 : 11 0D 27 : 11 01 8C 00 00 AA

0B : 69 54 17 : 80 25 13 : 13 00 C3 00 00 AA

[Teken]

 

To be clear the the cc1111emk (with software) can be equivalent of an  Insteon 2448A7 Portable USB Adapter  but with the ability receive and send arbitrary packets over RF, you will need an AP or dual-band device to relay the packets onto the powerline.

 

In fact for "fun"  I just ordered a EZ430-Chronos-915 ( http://www.amazon.com/gp/product/B00DK2D8WW ) since it's based on the same chipset as the dongle and thus would be somewhat trivial to run a script ( in the watch ) that can send Insteon commands. 

 

 

 

That pretty much already done,  for receive only you can use a  $15 rtl_sdr  dongle and software demodulator

 

The current output is something to the effect of :

 

Flag   To        From      cmd   crc padding

C3 : 11 0D 27 : 01 00 00 : 11 80 F8 00 00 AA

41 : 80 25 13 : 11 0D 27 : 11 01 8C 00 00 AA

0B : 69 54 17 : 80 25 13 : 13 00 C3 00 00 AA

 

 

 

EVIL Pete,

 

You're just killing me . . . 

 

I can't wait to see the video presentation on this exploit and much thanks for taking the time to share the back ground on this endeavor. 

[LeeG]

That will not work on the new I2CS devices.  They have link requirements the I1 and I2 devices do not have.

[stusviews]

That will not work on the new I2CS devices.  They have link requirements the I1 and I2 devices do not have.

 

Thus, the reason for I2CS. Thanks, Lee

[evilpete]

EVIL Pete,

 

You're just killing me . . . 

 

I can't wait to see the video presentation on this exploit and much thanks for taking the time to share the back ground on this endeavor.

 

Personally I don't think the talk when that great, I was not as animated as I normally am on stage.

 

I'll have the slides up tomorrow on github with some of the demo code.

 

I'm interested in seeing what people do with these resources.

 

Network Insteon bridges/relays, server signaling, etc...

[evilpete]

That will not work on the new I2CS devices.  They have link requirements the I1 and I2 devices do not have.

  

Thus, the reason for I2CS. Thanks, Lee

I2CS offers no protection from layer 2 protocol spoofing and injection.

 

In other words the ability to send & receive arbitrary packets includes the ability to intercept & impersonate any other device.

[Teken]

  

I2CS offers no protection from layer 2 protocol spoofing and injection.

 

In other words the ability to send & receive arbitrary packets includes the ability to intercept & impersonate any other device.

 

EVIL Pete,

 

Could you please expand on that line of thought and explain how your technique circumvents the iCS2 protection method.

[evilpete]

That will not work on the new I2CS devices. They have link requirements the I1 and I2 devices do not have.

EVIL Pete,

 

Could you please expand on that line of thought and explain how your technique circumvents the iCS2 protection method.

Background :

 

 

 

I2cs requires a device to be linked as a responder before it will accept commands.

To link a device physical access and/or knowledge of the INSTEON address of a device is required

As a security precaution, Insteon PLM firmware masks address of unknown/unpaired devices to prevent discovery and PLM’s firmware always inserts the true PLM ID number in the From Address field of messages that it sends

Since the Insteon protocol is unencrypted and unauthenticated anyone with layer 2 ( the Data link layer) access can circumvent *any* of these restrictions.

 

That is they have the ability to read the full contents of any message/packet ( and see the full address of even non paired devices ) as well as send with any ID in the Address fields of the message/packet

 

Thus to circumvent I2cs restrictions all you have to do is intercept a message/packet then programmatically link to that device ( no physical access needed )

 

Alternatively after you intercept a message/packet you can impersonate a paired device and do anything you want.

[Teken]

Background :

 

 

 

I2cs requires a device to be linked as a responder before it will accept commands.

To link a device physical access and/or knowledge of the INSTEON address of a device is required

As a security precaution, Insteon PLM firmware masks address of unknown/unpaired devices to prevent discovery and PLM’s firmware always inserts the true PLM ID number in the From Address field of messages that it sends

Since the Insteon protocol is unencrypted and unauthenticated anyone with layer 2 ( the Data link layer) access can circumvent *any* of these restrictions.

 

That is they have the ability to read the full contents of any message/packet ( and see the full address of even non paired devices ) as well as send with any ID in the Address fields of the message/packet

 

Thus to circumvent I2cs restrictions all you have to do is intercept a message/packet then programmatically link to that device ( no physical access needed )

 

Alternatively after you intercept a message/packet you can impersonate a paired device and do anything you want.

 

 

EVIL Pete,

 

Much thanks for the insight and clarification on how the I2CS data packet is intercepted and managed. A little bit of spit balling here so bare with me if you will.

 

Lets assume there is no encryption being considered for the next generation of Insteon devices. How would you update the existing Insteon protocol to make it harder for someone like you to flesh out the required data to circumvent and take control of said device(s)??

 

I believe you're in a good position to offer a counter measure or at least provide some insight as to how you would stop a person such as yourself from doing the same.

 

To catch a thief you must either think like a thief or use a thief to aid in the capture.

 

Ha . . . 

[MWareman]

To me its easy to fix the main issue - require the user to hit a button on the device before it will accept a link request.... Like zwave.

 

However, is there any protection from discovering the current PLM ID and a device ID and sending commands 'from' the PLM that the device would accept? How do you protect against this method being used to add new links? I can't see any way around some form of cryptographic message authentication with a key exchange during initial linking so that devices could ignore invalid messages.

[larryllix]

To me its easy to fix the main issue - require the user to hit a button on the device before it will accept a link request.... Like zwave.

 

However, is there any protection from discovering the current PLM ID and a device ID and sending commands 'from' the PLM that the device would accept? How do you protect against this method being used to add new links? I can't see any way around some form of cryptographic message authentication with a key exchange during initial linking so that devices could ignore invalid messages.

I believe one of the techniques was to just impersonate an existing link. An increase in initial contact security would be worthless.

 

As long as the communications are unscrambled this problem will never go away without redesigning the whole Insteon protocol and tossing all devices.

 

One of the stronger security items already existing may be that Insteon is synced with the 60Hz. I am not sure how important this is to the originator of the command signal.

 

An Insteon modem running off a 12vdc car battery, parked outside your house, may not be able to sync with you existing house system 60Hz without some fairly sophisticated equipment to lock in and remember the phasing associated with monitored signals.

[MWareman]

Communications don't need to be scrambled (encrypted) to solve this, but they do need signing to ensure authenticity, so messages cannot be faked. This can be done without a button - each device needs to contain a unique private and public key pair. The public key is sent to a device during initial linking (stored with the link record) and then the sending device of any message signs all messages with the private key. Devices can then verify and reject messages with an invalid or no signature.

 

Yes, I'm aware that the same algorithms are used for signing and encryption, but only message signing is needed to solve this.

 

Encryption is possible with this as well - the sending device simply signs the outgoing message using its private key, then encrypts using the public key of the expected receiving device (from the original link record). Easy enough. However broadcast and group messages still need to be supported, and this is not trivial with an encrypted payload.

 

On the 60Hz thing - this is a wireless vector, using your dual band devices to do the sync work for the attacker.

[Teken]

One of the stronger security items already existing may be that Insteon is synced with the 60Hz. I am not sure how important this is to the originator of the command signal.

 

An Insteon modem running off a 12vdc car battery, parked outside your house, may not be able to sync with you existing house system 60Hz without some fairly sophisticated equipment to lock in and remember the phasing associated with monitored signals.

 

 

On the 60Hz thing - this is a wireless vector, using your dual band devices to do the sync work for the attacker.

 

As Michael indicated and EVIL Pete alluded to using a RF device which can be powered by anything will supersede the need for a 120 VAC power line device.

 

I am still looking forward to seeing the recorded video and presentation of this effort.

[BCreekDave]

Has the video ever been made available or is this thread basically a non-issue?  For a single family type of home, it seems like with the limited RF range of insteon as an attack point it would take someone sitting right outside your home trying to gain entry.  For an apartment dweller, maybe that's more of a concern.  Or did I miss the point?

[Teken]

Has the video ever been made available or is this thread basically a non-issue?  For a single family type of home, it seems like with the limited RF range of insteon as an attack point it would take someone sitting right outside your home trying to gain entry.  For an apartment dweller, maybe that's more of a concern.  Or did I miss the point?

 

I have looked over the last few months and to date I have not been able to find the video for EVIL Petes demo. Perhaps he can chime in when DEFCON will make that video available for the general public to view.

[apnar]

FYI - I decided to give evilpete's code a try.  I wrote up a how-to here for anyone interested:

 

http://forum.universal-devices.com/topic/17474-how-to-receive-send-log-spoof-all-insteon-rf-traffic/

[Teken]

For those who wanted to see the DEFCON video you may view it here via this link: 

 

I can't honestly say the information that was presented was anything earth shattering to me. The initial presentation did high light that the white paper spec were off when compared to real life. But, that in it self isn't something that would cause me too much concern with regard to security.

 

It came across as another lazy, inept, ability from Smartlabs to communicate and document the real world technical specifications as they are.

 

Nothing earth shattering here as we have all seen this for ten years where they don't offer any insight about new product API's or even engage their largest supporter which is UDI.

 

This was seen on the latest Alert Module, Morning Lock, etc.

Again piss poor communications is par for the course here . . .

 

As the presentation went on I was disappointed in the fact nothing was shown to the audience besides commentary about data that was captured on the screen? I can't honestly say I was moved in the least from this presentation never mind parts of the presentation were near impossible to hear as EVIL Pete did not have a working microphone for about 3-5 minutes.

 

Later when he did have a microphone it didn't really show me anything a lay person would expect. It seemed there were a whole bunch of nerds sitting in a room chatting about how some elements were not accurate, or simply done poorly.

 

Again, lazy, inept, and zero communication and lack of accuracy of documentation has been known and continues to be seen even today?!?

 

Nothing new here . . .

 

What I was expecting to see is a real world demo of a MS sending a on / off signal event. In turn EVIL Petes little dongle would capture the data packet live on the screen. From there he would discuss what had happen and what next steps could be taken to spoof or duplicate said data packet.

 

All I saw was some kind of half assz lock demo that didn't do anything because half the parts were not present to complete the demo?? There was no lamp or other Insteon gear as far as I could see being used for linking / pairing, or otherwise?

 

Then there were segments of ramblings which for me made no real difference about Manchester encoding etc. That portion again made no difference to me at all because the lack of attention or detail has been known for ages.

 

The only take aways from this presentation was that there is no real encryption in the protocol which was shown in the demo screen. Perhaps I was expecting a lot more from this video but I can't lie I wasn't at all impressed with the presentation and it didn't show anything to me at least from a lay persons perspective of something being hacked.

 

EVIL Pete, 

 

My humble suggestion is that you create a new video showing in simple terms a Insteon RF broadcast is being intercepted. Next this data is captured on the terminal screen and explain in detail what that data is. Finally, use the RF dongle to actuate several dual band devices while the data stream is captured in the terminal window.

 

This in my mind would show the audience what can and is being done. I guess maybe seeing other DEFCON presentations which had solid presentations made this one seem off and lack luster.

 

I hope you are able to make up another video so the content and hack can be shown to all.

[jerlands]

Around 33 minutes in I think he makes his point "Insteon has paired up with Nest, Google and other big partners to be the baseband communication between that and other devices in your house."  Insinuating this weak link could be used to exploit anything else connected with it.  That issue is what I think needs to be explored and demonstrated.

 

 

 

Jon...

[larryllix]

A lot of effort went into to reverse engineering the protocol levels. This is awesome and could help future developers to make use of Insteon equipment.

 

Disputing a "white paper", as gospel, demonstrates confusion. It is never intended to be a spec for a product, only a concept.

However, it does show some laziness and/or deception, on Insteon's part, possibly to protect their engineering time, since patents are not effective.

[evilpete]

.

 

EVIL Pete, 

 

My humble suggestion is that you create a new video showing in simple terms a Insteon RF broadcast is being intercepted. Next this data is captured on the terminal screen and explain in detail what that data is. Finally, use the RF dongle to actuate several dual band devices while the data stream is captured in the terminal window.

 

This in my mind would show the audience what can and is being done. I guess maybe seeing other DEFCON presentations which had solid presentations made this one seem off and lack luster.

 

I hope you are able to make up another video so the content and hack can be shown to all.

Thank you for your honesty

 

Yes I agree I could have done better, for some reason I couldn't find my groove and bring out my my inter Mussolini on onstage ( and having hardware problems right before the top certainly didn't help).

 

[it's been over a decade since I presented on stage]

 

The important part is I got the information out there, I plan to clean up the reference source when I have time these days I'm a bit distracted working on another projects